海と山が好き

海と山が好きだけど埼玉に住むおっさんが遭遇したアジャイルとかのはなし

見積もりを振り返らない

やってみたら大きかったので、ストーリーポイントを見直してもいいですか?

見積もりの精度を上げるにはどうしたらいいですか?

いい加減飽きたんやそのやりとり。


例えば、通勤にかかる時間は?って聞かれると、

各工程を積み上げて計算→誤差多い

昨日とどれくらい違う?→たぶん一緒

じゃあ毎日ずっと一緒?→たぶんね。でもたまに遅れる。早くなることより遅れることの方が多い。

っていうのはなんとなくわかる気がする。

個別のアイテムは誤差が出る。開発は複雑度が高いのでたまに地雷を踏むのでハマる?すると想定よりも時間がかかる。山手線が止まるのと一緒。

これを誤差がなくなるには?とか、地雷を全て見つけてから見積もりをしては?とやりたがる人がいるが、おすすめしない

なぜなら、完璧な見積もりなんて存在しないし、意味がない。なんならネガティヴな効果さえ生んでしまう

ネガティヴな効果=コブラ効果、グッドハートの法則に代表されるような観察者効果。 見積もりと合うことが求められるなら、死ぬほどサバ読んで使い切るのが関の山。それを求める阿呆はいないけど、結果そうなる。

測りすぎ――なぜパフォーマンス評価は失敗するのか?


見積もりは完璧にいかない。上振れもあるし下ぶれもある。

これは確率密度分布で理解すると手っ取り早い。

確率密度関数は、どの値になる可能性がどの程度の確率か、の分布を示したもの。

よく言われる?のは↓の正規分布のもの。

f:id:Bashiko:20210210020036p:plain:w300

どのあたりに分布するかはわかるが、実際にどこの値をとるかは蓋を開けるまでわからない。シュレーディンガーの見積もり。

ソフトウェアの見積もりは Putnam モデルから言われるとレイリー分布に従うとか言われる。要はロングテールがあるよね(課題が見つかったりしてどハマりしたら割と無限に時間が溶けるよね)って話。

Putnam model - Wikipedia

レイリー分布はこんな形 f:id:Bashiko:20210602041546p:plain

ここで見積もりが実績と必ず乖離する理由が現れる

電車で何時間かかる?と聞かれたときには、"いつも"何時間くらいかかるか、を返すことが多いと思う。

それは統計で言えば 最頻値 になる。

この絵でいえばピーク部分が最頻値。

ところでじゃあその確率次第(見積もりだしね)の結果、やってみた結果を見てみるとどうなるかというと、それぞれの工程は最頻値を取りながらもトータルとしては 期待値 に落ち着く。

レイリー分布の期待値は、\sigma\sqrt{\pi/2}

一方、最頻値は \sigma

なので、期待値は常に最頻値、これくらいかかると見積もった値に対して、 \sigma\sqrt{\pi/2}/\sigma = \sqrt{\pi/2} \approx 1.25 と、25%上振れする。

f:id:Bashiko:20210602044349p:plain

僕らは、最頻値で見積もり、現実は平均値でやってくる

この2割の上振れを踏まえてキャパシティに組んでおく必要が出てくる。(積み上げ見積もりの場合)

ちなみに、この不思議な2割という数値は、ウォーターフォールのPMだろうがスクラムマスターだろうがだいたい取っておかないといけないと思うという直感の数値と一致する。なんとも不思議というか必然というか。

積み上げるとバッファが必要とは書いたが、アイテムによっては山の左側、つまり予想より早く終わることも起こりうる いくつかのアイテムの実績を集めると、上振れしたものと下振れしたものが合わさって出てくる。 全てのアイテムの合計を行うと、これらの見積もりとの乖離が相殺する。意外とこの数値はブレない。 (期待値同士の比較になるため。)

(まあ実際には、確率密度関数の最頻値=見積もりより低くなることは少ないことが多いのでより高く上振れする。パーキンソンの法則が働くので)

要はアイテムの見積もりはそこそこダイナミックにブレるが、それらを足し合わせたベロシティはそんなにブレない、ということになる。


じゃあ手取り早くやるにはどうしたらいいか、って考えると、ベロシティで見積もるのが手取り早そう。

例:段ボールにMサイズのみかんが何個入りますか?

っていう問題に対して、

  1. みかんのサイズを分析し、充填率を分析し、何個入るか考える

  2. 何箱か実際に詰めてみて、どれくらい実際に入るのか確かめて、平均値採用する

という2つのアプローチのどちらが効率が良いかと言われると、間違いなく後者でしょう。

なお前者のアプローチを採用した場合、待っているのは予実の乖離の分析なぜなぜ祭りと完璧な精度を求める箱詰め予測のプロフェッショナルの道。いいからコードを書けこの管理屋が。

というわけで、積み上げてどれくらいできるよね、って見積もるよりも、実績をベースに見積もった方がまだマシそう。理性主義は現実見てから唱えてくださいね、ってなる。


そもそも見積もりなんて、作る価値があるかを判断するために、価値に見合うだけのコストで収まるかが知りたいから必要とされる。

無駄なコストを抑えるための見積もりに無駄なコストを掛けてたら本末転倒以外の何物でもない。

ましてや本質的にブレるのが見積もりであるのに、見積もりがなぜブレたのか、を考えるのは考えるのは大した意味が無い。

マネジメントしているつもりになっていてやることがなくなる人ほどそういうことをし始める。

サイコロを振ってなぜ1が出なかったのか?って考えてるのと同じで正直アホだと思う。


当然実績ベースで見積もったところで結果はブレるかもしれないが、そこを気にしていてもしょうがない。

唯一精度を上げる方法があるとしたら、全ての見積もりサイズを同程度にしておく。小さくしておく。くらいしかない。(唯一のまともなアドバイス


そもそもスプリントの精度ってなんのために必要なのか、っていうと答えられないことが多いんじゃ無いかなって気はする。

スプリントが達成できたかどうかは、計画したアイテムが終わったかどうか、ではなく、計画したアイテム(と、計画していなかったけど必要だとわかったアイテム)を通じて、インクリメントが結果としてスプリントゴールを満たしているかどうかしかない。

スプリントゴールは各 PBI とは別に、それらの PBI を通じて ”どんな状態を実現したいのか” で表現されているとわかりやすいのだと思う。

作戦目標をスプリントゴールだとすれば、各 PBI はそれぞれの作戦過程における戦術目標に相当する。

戦術目標を全て満たしたとしても、作戦目標を達成するかどうかは怪しい。

なぜなら作戦立案時から状況が変わっているかもしれないし、立てた作戦が間違っているかもしれないから。

なので、戦術目標(PBI) をクリアーしながら、作戦目標を達成できるかを評価し続けないと危ない。これはデイリースクラムでやればいいと思う。

これは長そうだしいつか別に書く。多分。知らんけど。

ふりかえりのマンネリ感に向けて

ふりかえりにマンネリ感がある

っていう話を聞いた。

確かに感じるところもある気がする。

これに対してどうしたらいいのか。

なぜそうなるのか。

----

どういう状態なのか?

  • ふりかえりはやっているが・・・ってスクラムマスターがボヤく。
  • スクラムチームはふりかえりのやり方に満足している。が、周囲からの評価はイマイチ

----

 そもそもまずいことなのか?

ふりかえりの目的、というかレトロスペクティブの目的。

プロセスなどを検査し、適応する。

なんかこれ自体はできている気はする。でもイマイチらしい。

----

似たような話題がスプリントにもあった気がする

スクラムガイド2020 版で導入された、「プロダクトゴール」

ともすれば毎スプリントごとに何かを作る野菜切り係となってしまうスクラム

短期的な目標だけではなく、長期的な達成目標を設定しましょう、っていうやつ。

XP だと四半期サイクル、みたいな

日々の目の前のことだけじゃなく、長期的な目標が見えていることで、何に目を向ければわかるようになる。

ビジョンとかダイレクションとかで仕事の内容については語られることが多い気はする。

これがあるので森羅万象から自分たちが向かう方向が見えて、何を見て何を対応するのか日々判断できるようになる

----

これと同じことがチームにもあればいいんじゃないだろうか

要は、チームとしても、チームの長期的な目標を掲げる

要はミッションステートメントでしょ?はいそうです。

チームに名前をつけて、どういうチームになるのかを明確にする。

(あとはもちろん、人をコロコロ入れ替えない。)

自分たちがどういうチームになるのか。具体的に書いても面白いかもしれない。

小さいことから始めるなら、テックブログ書いて PV 何件、とかでも。

GitHub 年収予測でチーム総額がいくらになるとかだとちょっとアレかも。

 

----

これをやるとどうなるのか

自分の見ているチームでは、これをやることを提案してみよう。

(失敗したらひっこめよ)

観測範囲では、きちんとこういった目標を設定しているチームは士気が高い。

というか、やっていて士気が低いとか、戦闘力が低いチームは見たことがない。

あ、作りっぱなしでふりかえることのないチームはそうじゃないかも。

これはプロダクトゴールでも一緒なんだろうけど。

 

反復型開発とアジャイルは違う

反復型開発 イコール アジャイル開発ではないよね、という話

顧客価値の最大化を狙うとすると、思い込みで開発するよりも、より顧客について学習した状態で何を作るかを判断した方がいい。

そうなると、「何を作ればいいか」を継続的に探す必要が出てくる。

とはいえ仕様書で何を作ればいいかがわかるかというと、それも無理ゲーな話(できると思っているアタマユルイ人はいる)

となると、動くソフトウェアで触って確かめないといけない。

となると、動くソフトウェアを継続的に作る必要がある。継続的にドメインを学習するために。

#継続的にソフトウェアを作る上で、小さいタイムボックス&バッチで作るか、フローで作るかは選択の余地があり

そのため、アジャイル開発ではあるが、反復型開発ではない、というパターンは上記が実現できないので、おそらくない。

結果として、アジャイル開発であるなら、反復的に開発することが必要になる。


一方で、反復的に開発するというのは、コストがかかる。

ビルドの手間、リグレッションテスト、デプロイの手間、手戻りの際の管理の煩雑さ、漸進的な設計、、、

これらのものが意外とコンピュータリソースやクラウドやツールで何とかなってきたので、反復型開発が「ペイしやすく」なってきたので、反復型開発がしやすくなって気はする。

反復型開発のメリットは、アジャイル開発が実現できるだけではない。

スコープでコントロールするスタイルでトカゲの尻尾切りでプロジェクトをローンチできる。

いらない機能を作り込む代わりにコストと納期が伸びるのと、いらない機能を作らない代わりにコストと納期を約束できます、というのでは後者が望まれる場面も多い。

この場合は「要件定義」とかいうフェーズを済ませてしまう人も多い。

ヒアリングした結果のうち、優先度が高いものから反復的に作っていきましょう。

最悪の場合、作った結果を見てもらうこともない。

見てもらわないとなると、何のために反復型開発をしているのか、となるが、PJ をコントロールしやすくするため、となる。

金と納期は決まったから、最初に聞いた内容からできることだけ作ろうぜ。と。

それのどこが顧客の方を向いているのか、全く理解できない。ただのコントロール力不足じゃないですかね。

で、どうなるかというと、3割くらいは、検収・ユーザーテストで要件不足に気がつき炎上する。

こういうケースをアジャイル開発と呼んでいるケースが多く、「やっぱりアジャイルってさ〜」っていう人が割といる。いいかげんアジャイルアジャイル言われて久しいし。

いやアジャイルじゃなくてただの劣化スパイラルじゃないのそれ、と。RUP ですらないだろと。

反復型開発がアジャイル開発だ、と思っている人には、アジャイル開発がダメに見える。

アジャイル開発をしている人には、それってアジャイル開発じゃないよね、と見える。

側から見ると、アジャイルをやっている人は成功している物だけをアジャイル開発と呼んでいる、ように見えてしまう。

反復型開発はアジャイル開発の一側面であって全てではない、というのを理解していない人が多いので、名前も悪いよな、とか思いながらコーヒー飲んでいます。

漸進的探索とか目的に近い名前をつけておいた方が良いんだろうな、という気持ち。

『プロダクトマネジメント』を読んで

プロダクトマネジメント』原題: Escaping The Build Trap を読みました。

良書でした。同時にビルドトラップを生み出す組織構造にも興味が沸いてきました。 

翻訳は安心と信頼の Ryuzee さん。 -> Ryuzee.com

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

  • 作者:Melissa Perri
  • 発売日: 2020/10/26
  • メディア: 単行本(ソフトカバー)
 

 

原題にも書かれている ”ビルドトラップ” とは、プロダクトを作ることが目的化している状態のこと。

一見プロダクトを作るということは正しいように見える。だってプロダクトで儲けてるんだし。

でもビジネスの目的はプロダクトを作ることではなく儲けること。

儲けるということは顧客が対価を支払うということになる。

ここでプロダクトが差し出す対価とは顧客の問題がプロダクトによって解決され流ことになる。

この辺りはジョブ理論の影響を受けていそう。

ジョブ理論 イノベーションを予測可能にする消費のメカニズム (ビジネスリーダー1万人が選ぶベストビジネス書トップポイント大賞第2位! ハーパーコリンズ・ノンフィクション)

つまりビジネスの目的は、顧客の目的を解決することであって、プロダクトを作ることではない。

 

一方で、プロダクトを作ろうとする圧力は必ず生まれる。

そしてなんのためにプロダクトを作るのか、という観点が失われると、機能の開発が目的化する。

機能が増えれば品質を確保するためのコストは上がり、使いやすさは低下し、ユーザー離れを起こしかねない。

この辺りは実はアジャイル開発が苦手にしている分野だと思う。

(解決しようとしていない、と言った方が正しそう)

スクラムで言えば、初めにバックログありき。でプロセスが描かれる。

バックログを価値に変換するためにスクラムを組んだりして価値を届ける。価値。価値がある、はず。きっと。

 

この辺りを明確にアジャイル開発は語っていないことが多い。

なんせアジャイル ”開発” だし。どちらかというとリーンスタートアップとかデザイン思考とかが色強め。

アジャイル開発は改善も組み込まれているので簡単にベロシティは上がっていく。

ベロシティが上がると嬉しいことに(罠)、機能がたくさん作れる。やったね!

でもアジャイル開発がなぜ必要なのか、という資料に9999%の確率で現れる Chaos レポートの、64% の機能は使われていません!という事実。(ちょっと古いけど。)

 ベロシティをあげると、これらのゴミ、もとい使われない機能を実装できることになる。本末転倒では?

 

”開発” というスコープに視野を狭めてしまうと、非常にこういった罠にハマってしまいやすい。

本書ではそうなってしまう理由を解説している。

要は顧客の問題を理解しないまま作ることが目的化してしまうという。

プロダクトマネジメントは顧客のないを解決しなければいけないのか、プロダクトの機能の Why に集中すべし。とのこと。

顧客に会って、顧客の行動を観察して、何を解決しなければいけないのか、また、今わかっていないことはなんなのか、次にやることはなんなのか、という型を提示し、事例で示している。非常にわかりやすい。

この型を通じて活動することで、Unknown unknowns が見えてくることになる。

この領域がないと断じて作り始めてしまうと、顧客が求めていないものを作ることになり、ビルドトラップにはまる。

(あれ、これってなんかウォーターフォールみたいだな。ウォーターフォールって究極のビルドトラップなのかも。)

 

また、この書は明らかにプロダクトマネージャ、プロダクトオーナー向けの本だが、同時にエンジニアやデザイナー向けの本でもあると思った。

イソップ寓話でいうところのダメなレンガ職人になっていないかを常に考えないといけない。

というか、「これを作って」って言われたら、いつだって、「なんで?」って聞き返さないといけない。

何を解決したいからこれが欲しいの?」がわからないまま、表面的に言われたものを作ったところで、使い物になる可能性は低い。だってわかってないんだから完了条件満たしてるかわからないじゃない。

「完了条件は Acceptance Criteria に書いておいて下さい。」とか言い出す人もいる。きっといる。間違いなくいる。今脳裏に3人くらい浮かんだ。

その発想はおそらく、”個人との対話よりもツールやプロセスを重視” している。態度がプロダクト開発に向いてない。

Outside-in 志向で仕事をする。最終形から逆算して必要なものを作る、という発想でものを作らないと、言われたものを作る思考になりやすい。

会話が面倒だからって言われたものだけを作ろうとするといつまで経っても「仕様変更が多すぎてクソだわうちの客」とか愚痴り続ける人生になりそう。

少し触れられているが、「何をするか」を指示するのではなく、「何を解決したいか」を提示し、どうそれを実現するかは任せてしまえ、とある。

個人的にはチケットは状態で定義せよとスクラムチームに言っているのと同じ内容だったので安心した。

エンジニアとしても、Why を理解し要とすると最終的には顧客の何を解決するのか?に行き着く。結果、ドメインに踏み込んだ理解をする形になる。

ここまでくれば次にドメインの構造が見えてくるから、まともな設計もできるようになってくる。結果として変更しやすく理解しやすく、説明不可能なロジックが生まれなくて済む。割と。まあ勘違いしてたなら直せばいいし。

 

この本の面白いところは、組織としてプロダクトマネジメントを阻害する要因にも触れている点で、プロダクト企業の経営層にいる人は常に自分たちがこの状態に陥っていないか、PdM が顧客と話しているか、上司の顔ばっかり見ていないかを常に考えるべしという警鐘にもなっている。リーンエンタープライズにも少し近しいところはある。

組織として、戦略として、プロダクトマネジメントを据え置く上でどう構えるのか、どう構えるのが NG なのか、この辺りは組織論としても非常に興味深かった。

(ツリー構造の組織だと途端に顧客を見なくなるフォースが起動するから正直うまくいくのかなーという気はしなくもない。)

 

改めて、良いものを作るためには何を作るべきでないのか、を理解しないといけないなあと思わされる本だった。

 

----

 

この本を読んだ直後に社内で新サービスの話が出たときに、作る前からビルドトラップが生まれていてうーんこれは意識しないと本当に自然にハマってしまうんやなあと納得した。怖い怖い。

改めて考えてみると、「なぜそれを作るのか」を理解していないならそれは “エンジニア“ ではなく“コーダー“ なのかもしれない。(個人の感想です)

 

ーーーー

思い返してみると、5年くらい前か?新しくチームを立ち上げると言うので PMO(という名の何でも屋)で PL サポートした際に、前任者は言われたことを言われた通りにやる人間でクビになっていた。後任として入ったら、頼んだことをそのままやってくれず質問を返してくるのに答えてると自分が理解してないことが分かったのでよかった、ってだいぶ長い付き合いになった案件があった。

ビルドトラップもあんなもんなのかもしれない。言われた通りやるのって楽なんだけど。

でも考えてみると、目的を理解して仕事をしましょう、って新人研修あたりで言われるよな・・・・・・・(オチなし)