ソフトウェア開発プロジェクトは予測精度との戦い

はじめに

ソフトウェア開発で「予測」という言葉を使うと、だいたい工数やスケジュールの話になる。

何日で終わるのか、何人必要なのか、いつリリースできるのか。もちろんそれらも大事だし、無視できるものではない。

ただ、自分がソフトウェアを作ってきた中で強く感じているのは、開発という行為そのものが、最初から最後まで一貫して「予測との戦い」だということだ。

しかもそれは、未来を正確に当てるという意味での予測ではない。未来に起きそうな変化や問題に対して、どれだけ対応できる余地を残せているか、という意味での予測だ。

この記事では、「予測精度」という言葉を軸に、ソフトウェア開発で自分が何を考え、何と戦っているのかを書き残してみたい。

予測とは、未来を当てることではない

まず最初に整理しておきたい。

ここで言う予測は、占いや未来予知のようなものではない。ソフトウェア開発において、未来を完璧に当てることはほぼ不可能だ。

要件は変わるし、使われ方も変わる。データは増えるし、環境も変化する。問題は「当たらない」ことではない。当たらなかったときに、何もできなくなることだ。

自分が考える予測とは、未来に起きそうなことを想像し、そのときに現実的に選べる手段を残しておくことだ。

この「選べる状態」をどこまで維持できているか。それが、開発における予測精度だと思っている。

予測精度は、要求の捉え方から始まっている

予測というと、設計や実装の話だと思われがちだが、実際にはもっと手前から始まっている。要求をどう捉えたか、という段階ですでに予測は始まっている。

例えば、隣の家の田中さんがこんな相談をしてきたとする。

不在時に、飼っている犬が家でどんな行動をしているか監視したい

これが要求だ。

ただ、この言葉をそのまま受け取って実装を考え始めるのは、かなり危険だと思っている。

本当に欲しいのは常時監視なのか、異常が起きたときに気づければ十分なのか、単に不安を解消したいだけなのか。この段階では、まだ分からないことだらけだ。

要求は、往々にしてぼんやりしている。そして、表に出てきた言葉と、実現したいことの本質は一致しないことが多い。

ここをどう分析するかで、後の選択肢の広さは大きく変わってくる。

要求を分析すると「意図」が見えてくる

要求をそのまま実装に落とすのではなく、「なぜそれが欲しいのか」を考える。そこから見えてくるのが意図だ。

田中さんの例で言えば、

• 犬の安全を確認したい
• 異常があればすぐ気づきたい
• 常に映像を見たいわけではない

といった意図が浮かび上がるかもしれない。

この意図が言葉として残っているかどうかで、その後の判断のしやすさは大きく変わる。

意図は、判断のたびに立ち戻るための基準点になる。

意図がなければ、判断は積み重ならない

判断だけが存在し、その判断をなぜ行ったのかという意図が共有されていない状態は、かなり危険だ。

なぜその設計にしたのか、なぜその実装を選んだのかが分からなければ、後から見直すこともできないし、別の選択肢と比べることもできない。

判断同士が衝突したときに、どちらを優先すべきかを決めることも難しくなる。

意図があって初めて、優先度が生まれる。

優先度は、未来の衝突に備えるためのもの

ソフトウェアが複雑になるほど、判断は必ず衝突する。

性能を優先するのか、拡張性を取るのか、実装コストを抑えるのか。その場その場で考えて決め続けるのは、正直かなりしんどい。

意図がはっきりしていれば、「何を守るための判断なのか」が見えてくる。優先度とは、未来に起きる判断の衝突に備えて、あらかじめ軸を用意しておくことだと思っている。

選択肢が残っている状態こそ、予測できている状態

ここで言う選択肢とは、単なる思いつきの案ではない。

技術的に可能で、業務的に許容され、時間やコストの制約の中で現実的に選べる解決ルートのことだ。

田中さんの犬監視システムで言えば、

• カメラで常時監視する
• 動きがあったときだけ通知する
• センサーだけで異常を検知する

といった選択肢が考えられる。

意図と優先度が整理されていれば、これらを冷静に比較できる。逆に意図が曖昧なままだと、「とりあえず全部やる」か「一番楽な案を選ぶ」しかなくなる。

それは選択肢が多い状態ではなく、選択できなくなっている状態だ。

判断とは、選択肢の中から一つを選ぶこと

判断とは、何かを決める行為だが、何もないところから選んでいるわけではない。

意図と優先度によって生まれた選択肢の中から、一つを選び取る行為。それが判断だと思っている。

この構造ができていれば、判断は勘や勢いに頼らなくて済む。そして、この構造そのものが予測精度の正体だ。

品質は、予測精度の結果として現れる

品質は、テスト工程だけで作られるものではない。

どんな要求をどう解釈したか、どんな意図を置いたか、どんな優先度を選んだか、どんな選択肢を残したか。これらの積み重ねの結果として、最終的な品質が現れる。

予測精度が低ければ、突発的なタスクに追われ、時間が削られ、品質が落ち、完成が遠のく。最悪の場合、プロジェクトは完成しないまま終わることもある。

予測精度と、判断のサイクルの話

アジャイルのように、素早くプロトタイプを作り、確認し、修正を短いサイクルで繰り返す手法は、事前の思考だけでは予測精度を高めきれない領域がある、という前提に立ったアプローチだと思っている。

不確実性が高く、どれだけ考えても見えない部分に対して、時間とフィードバックを味方につけ、別の観点から解決を試みるやり方だ。

ただし、だからといって事前の予測や判断が不要になるわけではない。

予測精度を高める試みと、判断のサイクルを早める試みは、どちらか一方を選ぶものではない。現時点では、この二つを同時に適用し、予測精度を高めながら、判断のサイクルも早めていくのが、最も現実的で強いやり方だと考えている。

おわりに

完璧な予測はできない。それでも、予測しようとし続けなければ、プロジェクトは簡単に制御不能になる。

ひとりで日曜プログラミングをする分には、おそらく無意識に頭の中で全部やっていることで、おそらく特別なことではない。しかしチームで開発をするとき、何かを分担するとき、チーム全員がちゃんと予測できているか、予測できるだけの体制を構築できているかを注視する必要があると考えている。