ウォーターフォール型では、手戻りの発生時に影響が大きくなる。手戻り作業を防止するには、頻繁に確認しながら開発を進めるとよい。アジャイル開発のプラクティスを参考に、手戻り作業を防止する手法を紹介する。

今回のポイント
  • 仕様の共有はコミュニケーションを重視し、認識の違いによる手戻りを防止する。
  • 開発中に仕様確認の機会を頻繁に設けて開発を進める。
  • 手戻り作業を防止するには、「反復」「イテレーション計画」「イテレーションレビュー」というプラクティスが有効である。

 本連載は、ウォーターフォール型の開発プロセスにアジャイル開発のプラクティスを部分的に組み込み、プロジェクトに潜む様々なムダを排除する「ハイブリッドアジャイル」を提案している。今回は、システムエンジニアの立場から、ソフトウエア開発における手戻り作業の防止方法を解説する。

従来の開発手法では手戻りのリスクが大きい

 システム開発においてしばしば問題になるのが、手戻り作業だ。手戻りが発生すれば、スケジュール通りにリリースできず、余計なコストや時間がかかってしまう。

 現在、多くの開発現場ではウォーターフォール型の開発手法が利用されているが、この手法は手戻りのリスクが大きいと言える。それは、(1)仕様を事前に確定してしまうので曖昧さが残ってしまう、(2)バトンリレー型の伝達によって仕様の食い違いが発生してしまう、(3)ドキュメントベースで開発を進めるので操作性の検討が不足してしまう、(4)ユーザー側のテストを開発終了後に行うので手戻りの工数が拡大してしまう、といった問題があるからだ。まず、ウォーターフォール型の開発で発生する主な手戻り作業の原因と、その解決策について説明する。

 (1)の仕様が事前に確定してしまう問題を見てみよう。ウォーターフォール型の開発手法は、上流工程で仕様を確定させる。ところが、完璧な仕様を作成するのは難しい。いくら時間をかけて仕様を考えても、機能不足やユーザーの想定外の操作に対する処理の不備、条件による仕様の検討不足、などは発生してしまう。結局、どんなに仕様作成に時間を費やしても、曖昧な部分は残ってしまうのだ。そして、曖昧な仕様は次工程の担当者に引き渡される。

 ウォーターフォール開発では、自身の担当工程が終わり、次工程の担当者に引き継ぎが完了したら、その後に仕様の間違いや抜けに気付くことはあまりない。後工程の人から問い合わせがあれば考える程度だ。しかも何か問題が発生すれば、次工程の者が指摘してくれるだろう、と淡い期待さえしてしまう。

 ところが、次工程の開発者は仕様に書いてあることを信じて開発する。仕様通りに開発すれば文句は言われないと思うからだ。仕様に疑問点が生じた際は、間違っていないかを気にして問い合わせることはあるだろう。ただし、こういう仕様の方がよいのではないか、と改善策を提案することはない。自分のミスにならないように仕様が正しいかどうかを確認するだけだ。

 仕様作成者は間違いがあっても次工程の人が気付いてくれるだろうと考え、次工程の開発者は仕様は正しいので、その通りに作れば問題は発生しないだろうと考える。このように、お互いが仕様を人任せにしてしまい、トラブルにつながるといったことは多々ある。これが、ウォーターフォールの仕様の曖昧さが招く問題だ。

 続いて、(2)のバトンリレー型の問題点を説明する。ウォーターフォール型では、要件定義者から設計者、設計者からプログラマといった具合に、作業が後工程に引き継がれる場合が多い。そのため、要件定義や設計、プログラミングの各工程で担当者は変わる。

 担当者が変われば、認識の違いによる仕様の食い違いが発生してしまう。食い違いが発生したまま後工程に伝えられ、完成物は当初の仕様とは異なったものになる。いわば、仕様の伝言ゲームだ。伝達する回数が多ければ多いほど、食い違いの発生リスクは高くなる。

 例えば、図1の上を見てほしい。要件定義では「AAA」という仕様だったのが、基本設計や詳細設計といった各フェーズで伝達する仕様に食い違いが生じる。その結果、製造後には「BBB」という違った仕様で完成する。これでは「AAA」の仕様に作り直すための手戻り作業が発生してしまう。

図1●バトンリレーによる認識の食い違い
[画像のクリックで拡大表示]

 図1の中央は、基本設計と詳細設計と製造が同一人物の場合である。要件定義者からのバトンリレーが1回になるため、認識の食い違いは発生しにくい。それでも、「AAA」の仕様に作り直すために手戻り作業が発生してしまう。

 (1)の仕様の曖昧さや、(2)の認識の食い違いを防止するには、各工程の担当者が常に一緒に開発を進めるのがよい。図1の下の状態である。バトンリレーではなく二人三脚のように進めるのだ。このような開発体制を敷くことで、開発者は曖昧な仕様を担当者にすぐに確認できる。仕様の食い違いも発生しなくなり、手戻り作業も発生しづらくなる。

 ただし、要件定義の担当者が常にプロジェクトに張り付くのは現実的に難しい。そこで、できるだけ短い間隔で確認ポイントを設ける。ここで仕様の食い違いが発生していないかを確かめるわけだ。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は登録月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら