技術調査にどれだけの時間を使えばいいのだろう問題
おはこんばんはー。りょくちゃです。
技術調査にどれだけ時間をかけていいのかわかりません。とにかく調査したいことがわかるまで調べると思ったより時間がかかって、プロジェクトの締め切りに間に合わなくなるのが不安です。
このエピソードはチームリーダー目線だと感じますが、開発者の方なら技術調査は見積ることが難しい作業なので、困ったことはないでしょうか。
技術調査に時間を使いすぎちゃうとコストに影響が生まれます。つまり、技術調査は見積ることが難しい作業がコストに与える影響に常に気を配ることになります。
コストを気にせず技術調査を十分に行うと、調査で発見したかった情報を見つけられない場合、投資対効果の低い活動になります。
逆にコストを気にして技術調査をあきらめると、見積りが困難になったり不確実性が残るので、デリバリーの予測可能性が低下します。
というわけで、コストを気にしながら技術調査の撤退ラインを見極める活動が方針になります。
4つの知
ここで技術調査という作業がどうして見積ることができないのかを説明するために、4つの知を紹介させてください。
既知の既知―別名、事実。誰でも仕事をする上で知っておくべき知があるけど、それについて知っている状態。いつでも活用できる。
既知の未知―別名、疑問。時間や場所に到達してなかったり、物理的・現象的に実現してない段階。努力と注意で事実にできる。
未知の既知―別名、直感。知っているつもり。これを信じると、ちょっと危なっかしい。まず、知の所在を突き止めてから努力と注意で疑問→事実にできる。
未知の未知―別名、発見。自分で認識してないから発見すると驚く。一見して関係ないと思っていたことを分析しているときに発見することもある。狙って知ることのできない知。自分の知らないものは膨大。でも、知るとカイゼン、クリエイティブやイノベーションの足掛かりになる。
技術調査は見積もってもどれだけの時間を使えば調査が終わるのか見当がつかないのが厄介なところです。なぜかというと、どれだけ時間を使えば調査が終わるのかの知識が既知の既知になっていないからです。
どれだけの時間を使えば調査が終わるのかは人によって既知の未知か未知の既知に分類される問題になると思うんですけど……。どちらにしても、その分類なら知らないことの所在を明らかにして知らないことを明らかにするアプローチを考えます。
既知の既知にして嬉しいのは、なんと言ってもチームの予測可能性が向上することですね。
技術調査をチームの活動に取り込んで予測可能性を向上させる
それじゃあ、技術調査みたいなどれだけ時間を使えばいいのかわからない仕事をプロジェクトの計画づくりにうまく盛り込んで予測可能性を向上していきます。
自分のいつもやるやり方の場合「何がわかれば見積もれるか」に基づいて調査タスクを作ります。この調査タスクにはスパイクというかっこいい名前がつけられています。
スパイクは学習が成果物になっているので、学習したいことを明確にゴールにします。学習するか時間が来たら調査は終了。タイムボックス化した学習セッションで調査するのがポイントです。
簡単に言うなら、時間を区切って調査して時間が来たら成果を確認、引き続き調査するか、撤退するかを判断していきます。こうすることで、必要以上に時間をかけずに「どれだけの時間を使えば調査が終わるのか」を既知に近づけていくことができます。
そんなスパイク。プロセスに実装するなら、スパイクアイテムをPBLに作ります。2, 3時間でタイムボックスを設定し、学習が達成されない場合、引き続き学習するかはPOに判断してもらいます。
今回は時間がどれだけかかるかわからない技術調査を計画づくりに落とし込む方針について取り扱ってみました。実装方法はスクラムをやっている前提で書いているので、自分たちにあった実装方法を方針に沿って模索してみてください。皆さんのチームで参考になれば嬉しいです。では、また次回！