「真っ暗な世界」の「星」と「松明」

真っ暗といっても別に夢も希望無いわけではありません。可能性やリスクが渦巻くカオスな状態で良いも悪いも分からない状態です。
1年前の正解が今も正解かは分かりません。現代は依存するプラットフォームが大きく増え、人々の関心も大きく変わりました。今の正解を見つける必要があり、今は常に正解を知らないのです。この状態を「真っ暗」と表現しています。

そんな中、価値を生んでいくのに頼りになるのは手元の明かりと遠くの明かりです。
遠くの明かりは自分がどの方向を見てるか教えてくれます。星が読めれば航海が出来るのです。今どの方角に向かうのが良いかを判断することが出来ます。
具体的には、「見通しを立てる」ことです。信念とそこから生まれる仮説です。
これがあれば価値があるはずだ。こっちに向かおうと決める勇気は信念から生まれます。

向きが分かれば、そちらに歩いて行くだけです。しかし暗い足下は危険です。身の回りの状態を少しでも明るくし把握しておく必要があります。
どこまで明るくてらせるかが、手元の松明の明るさです。
ぐらい的には、現状を把握し見積もりを立てることです。今なにをすべきでなにが出来るのか? それをするにはどのような準備が必要か?
見積もりが出来ることが大切です。時には、分からないこともあるでしょう、10m先が分からなくても1m先なら読めるかも知れません、そして1m進んでみて結果から10m先の見積もりに活かします。
これを探索と呼んでいます。

アジャイルという心持ちやそれを元にした活動やプラクティスはこの様に見通しが立たない状況でムリ・ムダ・ムラを少なく、確実にゴールへ進む手段を教えてくれます。

ホームポジションは「なにも分からない私」出来ることは「探索」

さて、1か月後の世界はどうなっていますか?
わしには分かりません。ウクライナ情勢を知らなかった私にとっては突然の戦争でした。いつ来るか分からない地震に起きてから対応しています。
急に円安になりました。(22年6月時点)
これらは注意深く世界を見ている場合予測できたことなのかも知れませんが、通常わしのような一般人はそのように広くすべてを見通しているわけではないでしょう。
プロダクトも同様です。 多くの場合「前例のない」プロダクトを生み出そうとするはずです。全く新しいもの、既存のものを便利にしたものこれらは前例がないものです。似たものはあってもそのものはまだ市場にないわけです。見えてない部分が多くあり、一見「急に何かが起きる」のです。
「急に何かが起きる」と対応が後手に回ります、「急に何かが起きる」ことを減らしたいですね。なので「探索」をします。知っていること見えることを分かっていることを増やします。

これらが売れるかどうか? 人の役に立ち対価を受け取るだけの価値を持っているか? は分からない。だからこそ、探索をします。
探索は推測し、実行し、結果を検証し、学び、次の推測をしていきます。
「顧客はきっと30代だ」→「アンケート」→「40代がボリュームゾーン」→「こういう機能は少し上のレイヤーに必要なものなのか」→「マーケティン気戦略を見直そう」
的な感じです。作る物、見せ方、稼ぎ方

見積もりが100%正確になる方法

• 大前提: 「見積り対象と同じことを同じ人達と過去にやったことがある」

• 条件:

  • 前回と「同じゴール」設定

  • 前回と「同じ方法/手段」

  • 前回と「同じ人/チーム」

  • 前回と「同じ環境」

    • 経営状態

    • 市場環境

    • 組織構造

    • 技術環境

さてこの条件から乖離すればするほど見積もり精度は落ちていきます。
しかし、この条件に近づけば見積もり精度は上がります。
では、100%を達成できるでしょうか?
この中で時間とともに常に進化しているものがあります
「同じ環境」です。 市場は変化し新しい技術が生まれ、古いソフトウェアはサポートが終わります。価値感代わり、競合他社が生まれ、法律が変わり、。、、
さて、同じ環境は用意できません。
少なくとも、ここは今の環境にどれだけ食らいつくかにかかっています、そして最も予想が難しい部分でもあります。

同じ状態にしやすいものがあります
同じ人/チームです。
これらは固定可能ですそして、前回同じことをやったことのある共通認識を持ちます。
チームには、知識経験が蓄積しやすく、同じチームの状態が長いほどその量が増え、阿吽の呼吸が生まれコミュニケーションコストも下がります。

これらから分かることは、「不確定」な要素をどこまで減らせるかです。

車の運転で「いつもの道」と「初めての道」

さてこれらを運転に例えましょう。
運転でなくても徒歩でも大体同じ感覚はあると思います

「一人で」「いつもの車」で「いつものスーパー」に行く。
さて、何分でつきますか?
皆さん答えられるでしょう。

• 車の場所/ガソリンや整備状態/座席やミラーの調整ぐあい

• 道順/信号の位置

• 時間帯や曜日での混み具合

• 車の操作方法

• 天気による注意すべき点

などなど考えなくても答えが出てきます。

では、家族で初めて街のとあるショッピングモールにレンタカーで行きましょう
何分でつきますか?

Googleマップで予想時間を見てもその通り行くでしょうか?
多くの人は余裕を持って行動するでしょう。

• 道順はナビを見ながら

  • うっかり右折レーンに入るかも知れません

  • 工事しているかも知れません

• 混み具合は分からない

• 駐車場は空いているだろうか

• レンタカーで初めての車種

• 子供がおしっこしたくなるかも知れない

さていろいろと頭を使いながら運転しますね
そして予想通りの時間でつくかどうか?分かりません。
余裕を持って出たから「間に合った」ということもあるでしょう

「いつも」と「はじめて」の違いを感じられたでしょうか?
いつもは見積もりが合う条件をほぼ満たししているわけです。
それに対して初めては満たしていません。
見積もりが出来ない以外に感じたことはないでしょうか?
大きな違いはストレスです。
見積もりは会わないし道中は脳が過負荷になります。
この状態、健全ですか?

チーム運営で予測精度を上げていく

さてこの車の例は仕事も同様です。できるだけ初めてを排除し変化を小さくし脳の負荷に余裕を作りたいです。
その余裕で、予測困難な問題に対応していきたいのです。
どれだけ「いつもの」を作れるかどうかが「はじめて」に向き会い続けることに必要です。
チームをできるだけ固定し、チームでの活動を通してそこに知識や経験を蓄積していくことで、予測精度の高いチームを作っていきます。
雑にいうと「経験を積んだいつものチーム」で「初めてのこと」に立ち向かえば、見積もり精度50%は担保できるわけです。
チームの初めてを減らしましょう。

毎回初めて出なくていいものや手をかける必要のないものは多くあります。
例えば、

• ルールを決める

  • 週次の定例は決まった時間にしてアジェンダも用意しておこう

  • 困ったときの相談はこうしよう

  • 作業見積もり必要な情報をフォーマット化しよう

  • 開発時はこれを準備しよう

  • リリース後はこれをしよう

  • 報告フォーマットはこうしよう

• 自動化する

  • ソースコードの静的解析は自動化しておこう

  • プルリクが出たら自動でChatに通知しよう

  • 開発環境へのデプロイは自動にしておこう

• 振り返る/見直す

  • ルールは今の有効か? カイゼンややめることはないか?

  • チームはなにを学んだか? 次にどう活かすか?

などなどなど
多くのことは「ルーティーン」にし、出来れば自動化しておきます。
こうして空いた脳の余裕は顧客のことや機能のこと開発のことなどなどCreativeな発想に当てるのです。

いつものを増やし、予想困難な場所を減らしつつ
空いた部分を、初めてに当てていきましょう。

予測精度はあとの工程に行けば上がる

さて、この活動を通してマクロに見た予測精度の向上を図っていきたいのですが、プロジェクトの開始からリリースまでの予測精度は「不確実性コーン」というやつでグラフにされてます。

見積もりは誰がするのか

さて、ここで見積もりは誰がするんでしょうか?
答えは、そのタスクをやる人/チームです。
なぜなら「見積もりが合う条件」外の人がやっても見積もりが合う確率が下がるだけだからです。
せっかくのチームが見積もりせずに、見当違いな見積もりを渡されても達成は困難か無駄の多い結果になることが多いでしょう。
前回と「同じ人/チーム」は合わせられるはずなのでこの人達、そして実際に作業する人/チームが見積もりをしましょう。

向き合う問題の種類によって対応を変える

さて、問題には種類があります。
有名なのはクネビンフレームワークです。

なにを守るのか?

QCDS

どこまで行っても予測は外れるという前提に向き合う

さて、精度は上げることは出来ても、予測100%は無理なことは分かりましたか?
では諦めるのか? 開き直るのか? そうではないです。
これは前提です。 前提の中で「うまくやっていく」必要があります。

「経験を積んだいつものチーム」は作ることが出来そうです。
ではこのチームをうまく見積もりに使いましょう。
「経験を積んだいつものチーム」は、どれくらいの規模のタスクを達成しているでしょうか?
これを記録しておくことで、見積もりに活用します。
ここ半年は毎月平均「125kカロリー」(単位は適当です)くらいのタスクをこなしていると分かれば、その先もチームに変化がなければこのくらい捌けることが分かります。
この先の開発量が「1300kカロリー」ある(事前に見積もった結果)のであれば、10か月で達成出来そうです。(不確実性コーンの段階の見積もりかは考慮してbufferを積みましょう)
これを毎月観測し見通しに反映していけば、毎月「新鮮な見通し」が手に入ります。
不確実性コーンや経験則から見積もりも都度修正されていくでしょう。
早く細かく見通しが修正されれば、それに対して対応もしやすいです。
これをベースにスケジュールを立て、他と調整しておくのです。
前提は、見積もり会わないなので、そのときの対応も考慮しておきます。

1月15日に開発完了予定だとして

• 工期の25%をバッファに入れてプレスリリースの日を決めよう

• 毎月新鮮な見通しを立て直しているので少なくとも1か月前にはずれが分かるな、何かあっても対応できそうだ。

この様に、チーム内外で調整が出来そうです。