「仕様がわからない」と「仕様が決められない」は意味が違う

TL上で目についたこのスライド「ウォーターフォール開発／スパイラル開発／アジャイル開発　お金と契約にまつわる本当の話」を見ながら考えたこと。「仕様がわからない」ことと「仕様が決められない」ということは違う。この二つは区別しなければいけないと思った。

あなたは、これから開発するシステムの要件や仕様を(事前に)100%決定する事が出来ますか？

ウォーターフォール開発／スパイラル開発／アジャイル開発　お金と契約にまつわる本当の話 from Masahiko Satoh

この一連のスライドはとても興味深かったのだけども、24枚めのスライドですこし違和感を感じた。ウォーターフォール型開発プロジェクトへの分岐条件が「あなたは、これから開発するシステムの要件や仕様を(事前に)100%決定する事が出来ますか？」という点にひっかかったのだ。

• アジャイル開発プロセスの本質の一つに「意思決定を出来るだけ先延ばしにする」があるので、意思決定出来るかどうかを第1分岐に持ってくることは正しいような気がする
• この問いが成立する前提の一つに、「作り出すソフトウェアの全体像や難しさは全て把握している」というものがあるのではないかと考えた
  • 全体像がわかっている上で、「A案かB案かを選ぶことを先送りする(あとで考える)」のは良いのだけれども、A案もB案も考えられない状態は話にならない。要は「わかっているのか」どうかということだ。
  • 例えば法制度などが密接に関わる重要なソフトウェアをつくることを考える。制約事項や外部との関係性(全貌)がまったくわからない状態で「100%決定する事ができない⇒反復開発かアジャイル」というのは違う気がする。先延ばしして良いのは意思決定だけであって、リスクの有無が分かる程度に全貌の「仕様がわかっている」必要があるのではないだろうか
• 逆に「仕様がわからない」システムを作るときに、意図的にウォーターフォール型開発プロセスを戦略的に選択するということもあると思う。不明な問題領域を段階的詳細化によって明らかにしていく必要があれば、むしろウォーターフォール型のプロセスのほうが向いているように思う。利点は「学習する時間と余裕」が得られる事だ

計画駆動リスクとアジャイルリスク

アジャイルと規律という、ウォーターフォール型に代表される計画駆動型のプロセスとアジャイル型プロセスのバランスについて書かれた本では、両プロセスの選択をリスク分析によって決定するように説明している。詳細は同書を参照。

• アジャイルリスク
  • 規模(スケーラビリティ・重要度)の問題
  • シンプルな設計が採用できるか。YAGNIを採用できるか
  • アジャイル手法のスキルを持った要員が十分いるか
• 計画駆動リスク
  • 要求や外部環境が安定しているか
  • 迅速な成果の必要性を求められていないか
  • 創発的な要求を対象としていないか
  • 計画駆動手法のスキルを持った要員が十分いるか

結局はどっちでやってもそれぞれリスクがあるので、リスクベースでどういった開発プロセスを採用するかをプロジェクトごとに評価すべきなのだ。
現在やっているソフトウェア開発プロジェクトがうまくいっていないという理由だけで、開発プロセスをスケープゴートにして、アジャイル型の開発プロセスを採用してもうまくいかないだろう。