要件と機能の関連を保つテンプレート

品質の鍵は上流工程にあり

　SIer業界において、生産性向上は永遠のテーマです。そのための施策としてよく行われるのがドキュメントの標準化です。もちろん、弊社においても実践しており、その一環として業務システムの開発ドキュメント標準テンプレート「DUNGEON（ダンジョン）」を作成しています。DUNGEONは現場主体で作成しており、そのノウハウが凝縮されているのが特徴です。2005年に連載「即活用！業務システムの開発ドキュメント標準化」（http://www.thinkit.co.jp/free/project/4/1/1.html）にて紹介したところ、大変好評でした。

　その後もこのDUNGEONは、現場で鍛え続けて進化しています。そこで、再度そのノウハウを「すぐに使えるテンプレート」として紹介することになりました。対象は業務システムをウオーターフォールで開発するSEを想定しています。今回は、その第一弾として、「要件一覧」と「機能一覧」について解説します。

　プロジェクトの失敗原因を分析すると、上流工程に問題があることが多いことがわかります。これは顧客から要件を十分に聞き出せない、または聞き出した要件を仕様としてドキュメントに落とし込めないまま下流工程に進んだため、手戻りが多発するパターンです。

　上流工程の品質を高めることで、下流工程もスムーズに進められるのは誰もがわかっていることですが、改善対策が後手に回っているSIerも多いのが実情です。その原因は、上流工程では業務知識、IT知識、コミュニケーション能力などの高いスキルが求められるため、属人的になりやすく、そのノウハウを社内で共有するのは難しいと考えられているからです。

　しかし、上流工程でも納品物は明確です。納品物のドキュメントに記載すべき項目が枠として漏れなく用意されていれば、そこを埋めるために動くべき行動はおのずと見えてきます。つまり上流工程においても、標準テンプレートによってゴールを見せることで、属人化のリスクを抑えることができるのです。

　では、どのようなテンプレートを用意すれば上流工程の品質を改善できるのでしょうか？

システム開発のトレーサビリティ

　近ごろ、内部統制や世間でのさまざまな不祥事の影響か、「トレーサビリティ」という言葉をよく耳にします。トレーサビリティとは「追跡可能性」のことです。例えば、ある特定の加工食品に問題があった場合、その加工食品と同じ日付の材料を使った製品がいくつあり、どこに出荷されているかなどを簡単に追える仕組みです。

　システム開発においても同様にトレーサビリティは必要です。図1にあるとおり、顧客の要件がどの設計書に記載されているか、どの機能に実装されているかをすぐに追える状態のことです。

　例えばユーザーから受注入力画面への仕様変更要求があった場合、もちろんその画面は修正しますが、実はその変更が売上入力画面や帳票にも影響を及ぼす、といったことが把握できなければ不具合や手戻りにつながってしまいます。

　また上流工程は、これから作成するシステムを顧客に説明し、システムの完成イメージを共有する場でもあります。そのためには顧客が望む要件が、どの機能に実装されるのか説明できる資料が必要です。

　以上の観点から、DUNGEONのテンプレートでは、上流工程で使用するドキュメントに、このトレーサビリティを意識した機能改善を追加しています。

　次は、上流工程で使われるドキュメントフォーマットを見ながら説明します。