やってみないと分からないタスクは、その前に「調査タスク」を実行する
ソフトウェアの開発では往々にして、「やってみないと分からない」ことが飛び出してくる。必ずしもエンジニアの勉強不足とは限らない。新規性のある事業をやっているなら、業界に知見の少ない技術に手を出すこともあるだろう。加えて、ソフトウェアは他の業界とくらべて発展途上だ。日進月歩で進化している技術もあるから、未知の部分は必ず発生すると言ってもいい。
「やってみないと分からない」のは、開発チームが使おうとしている技術やツール、サービスに対する知識や経験が不足しているからだ。しかし、これ自体は悪いことではない。この問題にどうやって向き合うか、そのアプローチが大切になる。
スクラムで開発している場合は、未知のものがあるユーザストーリーは、ストーリーポイントの見積ができないか、極端に大きい数字になることが多いだろう。私の経験上、普段のタスクのストーリポイントが一桁前半なら、二桁のストーリポイントがつくタスクは未知の要素が含まれている可能性が高い。
解決策
未知のものがあるということを認識したら、未知の技術やツールを取り入れる前に、調査タスクを実施する。このタスクの目的は、チームに必要な知識を増やし、工数やストーリーポイントを考えられるようにすることだ。加えて、実現可能かどうかというところも考えられるような調査もする必要がある。
調査タスクに調査報告書など格式張ったものは不要だ。エンジニアたちが自分たちで工数を言えるようになっていれば良いからだ。アウトプットを作るとしたら、Qiita:Teamやesa.ioといったエンジニアたちが普段使っているナレッジベースで情報交換をするくらいがちょうどいい。できるだけ無駄なアウトプットは省こう。
ここで間違っても選んではならないのは「とりあえずやってみる」という方法だ。場当たり的に解決策だ。知識が少い状態で闇雲に進めると、最悪の場合はできずじまいで終わってしまい、時間だけ無駄にすることになる。
解決策の実施手順
- 不明な部分を明確にしリストを作る
- 調査する
- 再度見積りを実施する
ステップ1: 不明な部分を明確にしリストを作る
やろうとしているタスクにはどんな新しい技術やツールが含まれているかをリスト化し明確にする。
新しい技術やツールでなくとも、既存のコードを現在の開発チーム全員が把握できていない場合なども調査対象になる。
ステップ2: 調査する
前ステップで作成したリストを上から順に調査していき、調査結果と新しく得た知見を記録する。調査結果はチームで共有する。調査に長大な時間を掛けてはならず、見積のための知識を得ることに集中する。
調査では、簡単なコードで実験し上手くいきそうかどうかを検証するのも効果的だ。
ステップ3: 再度見積りを実施する
必要最小限の調査ができたら、タスクの見積を再度実施する。前回の見積りよりも精度が高く、自信を持てる工数になるはずだ。
この段階でも「やってみないとまだわからない」という意見がでてくるようであれば、ステップ1からやり直すことになるが、調査、分析中毒に陥いらないように注意しなければならない。