PR

ドキュメントベースでは操作性の検討が不足しがち

 ウォーターフォール型の開発では、しばしばドキュメントだけで仕様を伝えている場合がある。これが、(3)の問題につながる。操作性は紙ベースの仕様書だけでは確かめづらい。実際に操作してみないと気付かないことは多いのだ。

 例えば、メニュー画面などを作成することを考えてほしい。設計者や開発者なら自身が仕様を理解しているだろう。もちろん、メニュー画面に並んでいる項目から何をどの順番で使えばよいのかを把握している。そのため、仕様通りに自分が作成した機能が動けば、それで問題ないと思ってしまう。

 ところが、初めてメニュー画面を使うユーザーはどうだろうか。メニュー画面に並んだ項目を見て、それが何の機能を表しているのか、どのような順番で作業すればよいのか、などがさっぱり分からないことがある。残念な話だが、このようなシステムは意外に多い。

 結局、解決のために詳細な操作マニュアルを付けるといった対処がなされる。しかし、利用するために大量の操作マニュアルで勉強しなければならないのであれば本末転倒だ。このようなシステムでは、リリース後にユーザーからの苦情が殺到し、操作性向上というプロジェクトを新たに立ち上げる羽目になりかねない。これは、コストと時間のムダになる。

 このようなドキュメントベースの仕様伝達による手戻り作業を防ぐためには、ユーザビリティ設計を重視して設計することと、開発途中にユーザーに実際に操作してもらう場を設けることの2点が重要である。

 続いて、(4)のユーザー側のテストを開発終了後に行う問題を説明する。ウォーターフォール型開発の一部現場では、システムが完成し、テストを終えてからユーザーに確認してもらうことがある。ところが、ユーザーのテスト段階で仕様の見直しが必要になると、基本設計にまでさかのぼって手戻り作業になってしまうことすらある。これは、大幅なコストと時間のムダにつながる。

 例えば、図2のように修正分がシステム全体の20%に相当するとしよう。この場合は、単純に考えても基本設計以降の全ての工程で20%の追加作業が必要だ。実際には、リグレッションテスト(デグレードテスト)などの全体の再テストも必要になり、それ以上の工数がかかってしまうだろう。このように開発が終了してからユーザーが最後にシステムを動かして確認するような開発プロセスでは注意が必要だ。

図2●ウォーターフォール型の手戻り作業の影響範囲
図2●ウォーターフォール型の手戻り作業の影響範囲
[画像のクリックで拡大表示]

 この問題を解決するには、変更に強い開発プロセスを整えなければならない。たとえ仕様通りに開発していたとしても問題は見つかるものと考え、仕様変更に早期に対応可能な開発プロセスにする。

イテレーションごとに確認していく

 ここまで主に4つの手戻りリスクとその解決法を説明した。これらのリスクを防止し、解決しやすくするには、アジャイル開発のプラクティスである「反復」「イテレーション計画」「イテレーションレビュー」が参考になる。

 反復(短いイテレーション)のプラクティスから説明しよう。アジャイル開発における反復では、2~4週間といったイテレーションごとに進捗などを管理する。この反復に仕様を確認する機会を設ければ、早い段階で問題に気付ける。

 ハイブリッドアジャイルの場合は、ウォーターフォール型の詳細設計工程と製造工程に相当する部分を反復(イテレーション)で行う。イテレーションごとに行うイテレーションレビューの場で、プロダクトオーナーやユーザーも参加して仕様を確認すれば、問題を早期に発見できるというわけだ。問題を発見した際も、手戻り作業は基本設計から該当イテレーションで開発した範囲だけで収められる(図3)。結合テストと総合テストは、まだ始まっていないため手戻り作業は発生しない。

図3●反復による手戻り作業の影響範囲
図3●反復による手戻り作業の影響範囲
[画像のクリックで拡大表示]

 表1は、ウォーターフォール型の開発で、総合テスト後に問題が判明した場合と、反復開発のイテレーションで問題が判明した場合の工数の比較である。各工程の工数比率は仮の値であり、手戻りの影響を全体の20%と仮定した。また、手戻りの影響は、単純に影響する各工程に20%とし、デグレードテストなど全体に対する再テストの影響は考慮していない。

表1●手戻り作業の比較
表1●手戻り作業の比較
[画像のクリックで拡大表示]

 前者は、工程の基本設計から総合テストまでが影響し、全体工数に対して18%の手戻り工数が追加となる。後者は、基本設計から製造まで工程だけに影響するが、結合テストと総合テストの手戻り作業は発生しないため12%の手戻り工数の追加となる。全体では6%の差ではあるが、ムダな工数は発生しなくなる。実際には、影響範囲の調査や手戻り作業の見積もりにかかる時間、デグレートテストなど全体に対する再テストなどもあり、6%の差だけでは済まなくなる。

 反復開発は、学習効果を生み出すことにもつながる。例えば、エラーメッセージの出し方や画面戻りの処理など、多くの場面で共通的な処理があったとする。全ての箇所を開発してから処理方式を変更することになれば、全ての箇所に影響することになる。

 しかし、反復開発で早い段階のイテレーションで処理方式を変更すれば、そこで開発チームは学習する。一度学習できれば、以降のイテレーションでは変更後の処理方式で開発できる。これで、この先に行われる変更処理を大幅に削減可能だ。このように、イテレーションごとに問題を早期に発見しやすくなるので、手戻りリスクを低くできる。