アジャイルソフトウェア開発宣言で示される「4つの価値」を見たとき、アジャイル開発に限らず、ウォーターフォール型開発にも活かせる部分があると感じました。
ウォーターフォールにおいて、アジャイルソフトウェア開発宣言に学べる部分を考えてみました。
目次
プロセスやツールよりも個人と対話を
ウォーターフォールではレビューや進捗会議など形式的なプロセスが重視されますが、形式に縛られすぎると本質を見失いがちです。
直接的なコミュニケーションを取り入れることで、停滞や手戻りなどの余分な時間をなくせるかもしれません。
実践例
- 設計工程で不明点があるとき、質問票だけでなく短い打合せで疑問を解消する
- レビュー会議を、形式的なインスペクションに限らず、ラウンドロビンなどにして議論を活発にする
- 進捗報告会の前に、担当者と”雑談”形式で課題をヒアリングする
包括的なドキュメントよりも動くソフトウェアを
ウォーターフォールでは詳細なドキュメントが必須ですが、それに時間をかけすぎて動作確認が遅れるとリスクが大きくなります。
早い段階でプロトタイプを作成し、顧客からのフィードバックを得るなど、テストの「シフトレフト」の考え方に近い気がしています。
実践例
- 基本設計完了後に簡易プロトタイプを作成し、顧客に画面イメージを見せる
- 結合テストの前に、小さなモジュール単位で動作確認やデモを行う
- レビューでは、可能であればドキュメントに加えて動くソフトを使って説明する
契約交渉よりも顧客との協調を
ウォーターフォールでは契約に重点を置いていますが、顧客と協力して契約を守りつつ柔軟に調整する姿勢が重要であると考えます。
契約を盾にするのはあくまで最終手段であって、基本は顧客と同じ方向を向いて開発を進めることが価値につながるのではないでしょうか。
実践例
- 要件定義の途中で顧客の追加要望が出たら、優先順位を整理して契約範囲内で調整する
- 正式に見積もりをする前に、小規模なPoCを通じて顧客に体験してもらい、合意形成をスムーズに進める
- 定例会議で進捗報告をするだけでなく、現場の声に耳を傾ける
計画に従うことよりも変化への対応を
ウォーターフォールでは計画通り進めることを重視しますが、実際には想定外のイベントが発生するものです。
かたくなに計画を守るだけではなく、特には変化を前向きに取り入れることでよい効果が生まれるかもしれません。
実践例
- 進捗遅延が発生した場合、残業で吸収するのではなく低優先の機能を後回しにする
- 法改正や市場変化で要件が変わったときは、影響を分析し、再度計画を立てる
- マスタースケジュールは大枠として保持しつつ、詳細計画は短い区切りで見直す
まとめ
日本ではまだまだアジャイルが浸透していないですが、ウォーターフォールにおいてもアジャイルの態度に学ぶべきところがあると思います。
アジャイルを採用していないからアジャイルのことを学ばないというのはナンセンスで、多角的に知識を取り入れてこそ”良い開発”ができるのではないでしょうか。
コメント