見積もりができない。どうする？
見積もりって大事ですよね。見積もりは何のために行なうものでしょうか？開発が終わるかどうかの見立てを立てたい。そうですね、たいてい使えるお金と時間には制約があるので、やろうとしていることが本当に完了できるのか、誰しもが把握しておかなければならないことでしょう。それに、開発チームにとってはペースを掴むためにも見積もりは必要ですね。
では、見積もりが出来ないような場合、一体どうすれば良いでしょうか。「どうすれば」の前に、そもそも「見積もりが出来ない」とはどういう時でしょう。
例えば、何をつくるべきかいまひとつ理解できていない状況なのかもしれません。そうならば、プロダクトバックログの詳細化に取り掛かりましょう。
いや、つくるべきものは分かっている。それこそ受け入れ条件も分かっている。でも、どう作ればいいか分からないような状況かもしれません。そうならば、方式の検討や設計が足りていないのでしょう。
実は、外部サービスとの連携が肝で、コードを書いて動かしながら理解を深めつつ、分かったことからどうつくるべきか検討しなければならないような状況かもしれません。もちろん、時間に追われながら。
見積もりをしない。で、大丈夫だっけ？
さて、「どうすれば」の作戦を立てましょう。現時点で、分かっていることもあるからとにかく見積もりを一回してみる？ありかもしれません。チームにとって、分からないことが何なのかも見えてくるでしょう。ただし、見積もりはタダではなく、相応の時間を費やすことになります。ほとんどあてにならない見積もりのために、です。
「見積もりをしない」という選択肢があります。やってみないと分からない状況下で、無理に見積もりを立てるより、できるところから始めようというわけです。目の前にあるプロダクトバックログを一個一個倒していくことに集中する。できそうな気がします。
しかし、冒頭であげた問題があります。「終わる見立てが立たない」ことと、「チームがペースを掴めない」ことです。終わる見立てが立たないことに、ステークホルダーは納得してくれるでしょうか。チームがペースを掴めないまま、「ずっと頑張る」で疲弊してしまうことはないでしょうか。
OODAループを開発に適用する。
見積もりをしない開発の問題を解消するための作戦を立てましょう。見積もりをしないので、Planが立たないため、PDCAでは適応できません。参考になるのは、OODAという考え方です。
「OODAループは、朝鮮戦争の航空戦についての洞察を基盤にして、指揮官のあるべき意思決定プロセスを分かりやすく理論化したものである。すなわち、監視（Observe）- 情勢判断（Orient）- 意思決定（Decide）- 行動（Act）のサイクルを繰り返すことによって、健全な意思決定を実現するというものであり、理論の名称は、これらの頭文字から命名されている」(Wikipedia より)
目の前の状況を捉えることに集中し、その状況に適した行動を取っていく。行動の結果から、展開される状況から次の行動をまた判断していく進め方です。
開発に適用する場合の要点をまとめてみました。なお、チームをリードする役割にある人、あるいはステークホルダーに説明責任がある人が、これらの要点を押さえて運用していく必要があります(以下、運用者と呼ぶことにします)。また、ここで想定している開発チームは、開発者が4-5名程度です。
(1) 基本は、反復開発。
そもそもですが、反復的な開発を前提とします。特にイテレーションの単位は、1週間以下が望ましいと思います。2週間だと状況の判断が間延びして、状況に対する対処が遅れ気味になる恐れがあるでしょう。
(2) 十分に、対話する。
開発チームのメンバー同士が対話するのは勿論として、この開発スタイルの運用者が対話や観察を通じて、各メンバーの状況を把握し、客観的に状況判断することが必要です。目の前のプロダクトバックログを倒すことに集中し始めると、全体の進行把握やペースの判断が開発チームでは取りづらくなります。客観的に見て、オーバーワークになっていないか、迷走していないか、冷静に判断する役割が必要です。
なお、状況を把握するにあたって、ファイブフィンガーによる表明もおすすめです。自分たちのいまの状況を、立てる指の本数によって表現するワークです。5本なら楽勝、1本なら絶望的、などのように。詳しくは書籍「リーン開発の現場」の第6章 プロジェクトのゴールを追え！を参考にして下さい。
ただし、チームがたとえ4本、5本をあげようとも、客観的な状況判断が求められる運用者は自分なりの評価も行なうようにしてください。チームが楽観視している時こそ、運用者は悲観的な見方からプランB(バックアッププラン)を検討しておくべきです。
(3) 初期の設計・実装を、全員で行なう。
プランニングがないため、開発する上で必要な共通認識を作ったり、認識の齟齬を防いだりする機会が無いまま進んでしまうことになります。冒頭であげたように「どう作るべきか分からないためにコードを書いて考える」状況にあるため、初期段階の設計や実装をメンバー個別に行なうのは難しく(分業ができない)、全員であたるのが効果的です。一箇所に集まって全員で同時にあたるため、理解がずれたままにはなりくく、チームの意思決定も瞬間的になります。
(4) 集結と散開を、繰り返す。
1週間単位で、イテレーションの成果をチームでレビューし、次のイテレーションでとりかかるべきプロダクトバックログを分け合います。(3)「初期の設計・実装を、全員で行なう。」の初期段階を脱するまでは、チーム全員で一つずつプロダクトバックログアイテムを倒すことになりますが、プロダクトの土台が完成した状態、つまり必要な方式の検討があらかた整った段階では、手分けしてプロダクトバックログにあたることも可能です。
リモートワークを取り入れる場合は、1週間単位で集結(レビュー&手分け)と、散開(各自頑張れ)を繰り返す開発に移行します。この開発スタイルに限ったことではありませんが、受け入れ条件の整備と、完成の定義を共通理解としておくことは、前提になるでしょう。
(5) ステークホルダーと、状況を同期する。
運用者の重要な役割に、ステークホルダー、ビジネスのオーナーに状況を同期することがあげられます。(2)「十分に、対話する」のとおり、対話できている運用者ならば、ステークホルダーに詳細かつ正確に、状況を伝えることができるはずです。運用者にはステークホルダーへの透明性を担う責任があります。
状況把握した上でステークホルダーからもたらされる意向のうち、チームと共有するべきことがあれば (4)の集結時に伝えるようにします。運用者はいわゆる伝書鳩でしょうか？そうですね、チームとステークホルダーの通信手段と言えます。ただし、チームへの不必要なプレッシャーを遮断し、ステークホルダーへの透明性を確保するためのリソースを代替する、役割を担います。
(6) 実績と目論見を、あわせる。
見積もりができない開発なので、暗がりの中をライトで照らしながら一歩一歩進むようなものではありますが、ビジネスの目標から期限の設定はあることでしょう。イテレーション単位でチームの成果を測り続けることで、着地の予測が少しつずつできるようになってきます。希望する着地を越えないのか、越えるにしてどのくらい越えるのか。(5)のステークホルダーとの同期の中で、常に見立てを共有するようにしましょう。
(7) 斥候を、置く。
斥候とは、偵察のことです。進行方面の状況を偵察しつつ、警戒する任務のことを一般的には言います。このお話はソフトウェア開発ですから、斥候を置くとはどういうことでしょうか。特定のプロダクトバックログを倒すことに軸足を置くのではなく、チームの中を自在に動き回る役割になります。課題を抱えているメンバーを発見したらこれを支援し、また仕様があいまいになっていて前に進めないでいればこれを明らかにし、といった具合です。
開発するプロダクトに最も精通しているメンバーをむしろ、空けるようにして動きを取りやすい状況をつくる方が、どこでどんな困ったことが起きるか予測しにくい開発では効果的でしょう。
こうした、活動と意思決定の速度を優先した戦い方を「機略戦」と呼ぶそうです。アジャイルソフトウェア開発は機略戦の思想を既に織り込んだスタイルと言えますが、より不確実性の高い、見積もりも使い物にならない状況下で取る開発のスタイル「機略型のアジャイル開発」としてご紹介しました。
(写真：https://ja.wikipedia.org/wiki/OODA%E3%83%AB%E3%83%BC%E3%83%97#/media/File:OODA.Boyd.svg)
4
取り消す
この記事に共感したら、何度でも押してこの記事のポイントをみんなでアップしよう。