ソフトウェア開発においてプロトタイプを実装し、要所要所で確認していくことの重要さを改めて感じたので反省を書いておく。
要は、対象の開発領域で確実にこうすれば要件を満たせるという確信がない状態でリリースを目指して実装することは危険であるということ。なぜなら、不明瞭だった部分を実際に見ていくと根本的にやり方を変えないといけなくなる可能性があるから。それが、先にどのくらい時間がかかる見積もりをしていたときだった場合に問題になる。
例えば、N くらいで終わるという見積もりで Z くらいの時間をかけたのに、根本的な設計ミスや考慮漏れで N くらいで終わると見ていたタスクがいつ終わるか結局わからなくなってしまう。不明瞭さは Z の時間をかけてなくなったものの、また計画を練り直す必要があり、成果物を待ってた側とリリースタイミングが合わず信用を失うかもしれない。
ある程度大きい A というタスクを 時期を見立てて 完了にするためには、A を完了するにあたって不明瞭な部分を考えうる限りすべて上げてそれらを先に潰す必要がある。それまで A が完了する時期は考えない。というより考えられない。不明瞭な部分がある場合はどのくらい時間がかかるか見積もれないため。不明瞭な部分にざっと見積もりをつけることは可能だが、あてにしないように合意しておきたい。どのくらい時間をかけるかは場合によって決めておくのはありかと思う。締切がないときにタスクについての時間は無限に投資されてしまいがちであるため。(パーキンソンの法則より(第1法則: 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する))
こういった問題を回避するために、スクラムにはスパイクという考え方がある。
リリース可能なプロダクトを作るのではなく、質問に答えたり情報を収集したりすることを目的とした作業。
スパイクを有効に使いつつ、タスクの完成度を高めていくには以下のように進めていけばいいと考えている。
- 設計作業
-
設計内で不明瞭なことがあれば調査する(スパイク)
- 使ったことはないが有用そうなツールやサービスをとりいれるときなど
-
設計が正しいか最低限確かめられるモノを作る(スパイク)
- 設計したものを最低限組み合わせてやりたいことが実現できるか
-
本実装作業
- スパイクで実装した部分をリファクタしたり、本筋に沿って作業を行う
上記のように進めることで、本実装作業 前にできるだけ手戻りが発生しないようケアをすれば、本実装作業時に不安を抱えずに安心してコーディングを進めていけるはずだ。
正直、今更書くのも恥ずかしい限りだが意識していないと確認や実現を詰める作業を怠って 本実装作業 に進んでしまいがちなので書いた。
エンジニアリングにおいて、不明瞭なことは作業を終わらせるにあたってのリスクなのでリスクを洗い出して事前に潰すという当たり前が今になってもできていないことが反省である。
改めて書くと、ボリュームのあるタスクについては不明瞭な部分やリスクを列挙して潰しておくことがマスト。
- 非機能要件
-
ライブラリの挙動
- 導入予定のものだが、要件を満たせるかわからない
-
設計で描いたものを動かしたとき実際に要件を満たせるか
- プロトタイピング
-
実装において難しそうな部分
- プロトタイピング
これらを解決するタスクを作って、実行し、レビューを繰り返して堅実に大本のタスクを終わらせる山を登っていく。