システム開発、成功と失敗の分かれ道システムを開発する際、「要求仕様文書」をいかにしてまとめるかが成功と失敗の分かれ道であるといえます。なぜなら、「要求仕様文書」によって新システムに盛り込むべき機能をユーザーと開発者の両者が理解できるようになるからです。これが十分でないと、品質、納期、コストの問題にはねかえってきます。
要求仕様をまとめきれないと、その影響は上流工程だけでなく、開発などの下流工程にも現れ、手戻りによる納期遅延やコスト超過などを引き起こします。さらには、システム導入後の品質の低さとして顕在化し、最悪の場合、取引ミスや不具合対応によるコスト増加や業務スピードの低下など、企業に大きなダメージを与えかねません。
システム開発を取り巻く状況最近、システム開発を取り巻く状況が次のように変化してきています。
- 従来の開発に比べ、期待される開発工期が相対的に短い
- 要求仕様が固まっていない状態で開発を始めねばならないケースが多い
- 要求の追加・変更が開発中にも継続的に発生する
- 利用すべき技術や製品が次々に登場・改訂される中で開発しなければならない
これにより、要求仕様の難しさは以前と比べ格段に増しています。例えば、
- ITと経営戦略の密接度の高まりにより、既存業務のシステム化と比べて、要件が見えにくくなっており、上流工程で決めなければいけないことが複雑化かつ増加していること
- 単一部門の業務効率化から、ERPやSCMなどのような部門／企業横断型へのシフトにより、要件を決める利害関係者が増加傾向にあること
- システム関連業務のアウトソーシング化の進展により、ユーザー企業内にITと業務の両方に精通した人材が減少したこと
- 短納期・低コストプロジェクトの増加により、要求仕様まとめに十分時間を取れなくなったこと
などが挙げられます。
要求仕様定義力の向上こうした状況の中で、効率よく、かつ、高品質に要求仕様をまとめるための取り組みは以前にも増して重要性が高まってきています。
また、問題意識の高まりを踏まえて、近年、要求工学への期待が高まり、ユーザー企業におけるシステム開発プロセス改革（多くは要求仕様定義などの上流工程の改革に取り組んでいる）などといった要求仕様定義力向上に関する取り組みが進みつつあります。
ユーザー企業が抱える、要求仕様定義に関するよくある課題として、次のようなものが挙げられます。
- 要求仕様では何をどのようなレベルで定義しなければならないかの認識が人により異なる（または分からない）
システム開発や要求仕様定義を経験したことのないユーザーにとっては、何をすべきかまったく分からないですし、経験者であっても個人が経験してきた過去のプロジェクトに依存してしまいます。 一般論としての要求仕様定義の方法論は、前述のとおり最近は世の中に多く存在するため参考にできるかもしれませんが、そのまま流用できるわけではありません。なぜならば、要求仕様定義などの上流工程は、個々の企業のシステム開発における決裁プロセスと密接に関連するため、何をどこまで定義すべきかは企業により異なるからです。 - 要求仕様書の書き方やレベルが人によりバラバラである（または、作成しなければならない成果物のイメージがわかない）
要求仕様定義書を作成したことのないユーザーにとって、どのようなフォーマットに、どのような書き方で作成すればよいかは、まったく分からないと思われます。また、人により要求仕様定義書のフォーマットがバラバラだと、参照しにくいだけでなく、記載される要素やレベルなどもバラバラになり、要件の抜け漏れが発生しやすくなります。 - ユーザー、情報システム部門（または開発ベンダー）の責任や役割分担が不明確である
責任の所在が不明確であることにより、各メンバーが何をすべきかが不明確になります。そのため、情報システム部門や開発ベンダー任せになりがちになったり、その場しのぎの結論を出したり、要件を保留したままにしておくといったような弊害が発生することもあります。 - 利害関係者をうまく巻き込めない
最近のシステム開発は利害関係者が増加傾向にあるため、利害関係者の巻き込みが以前にも増して困難になってきています。利害関係者を巻き込まずに要求仕様定義を行うことは、要求仕様定義の品質の低下や後の手戻りを招くことになります。
要求仕様定義の標準化これらの課題の対策として、要求仕様定義の標準化を行う企業が増えつつあります。標準化の内容としては、次のようなものが挙げられます。
- 要求仕様で定義すべき事項の標準化
要求仕様定義のどの段階で、何をどのようなレベルで定義し、どのような成果物が必要となるかを明文化します。
ただ、要求仕様をまとめるべき事項というのは、新規でシステムを開発する場合と既存のシステムを修正開発する場合では異なりますし、開発形態（Webシステム、パッケージ導入、メインフレームなど）や開発対象（アーキテクチャー、アプリケーションなど）によっても異なってくるため、それらに応じた要求仕様定義項目の定義が望ましいです。
また、今まで行ってきた要求仕様定義プロセスを可視化するだけでなく、この機会に一般的な方法論や要求工学などを参考にプロセス自体を見直すとよいでしょう。 - 責任／役割分担の標準化
要求仕様定義書の作成責任を明文化します。業務プロセスやシステム機能などの業務／機能要件はユーザー部門、システム構成などのアーキテクチャー要件などは情報システム部門を責任者にするのが一般的かと思われます。
ただし、アーキテクチャー要件の前提となる、信頼性やパフォーマンスといった非機能要件は業務要件と密接に関連するため、ユーザー部門を責任者にするなどの注意が必要です。その際、ITに精通していないユーザーは非機能要件を自分自身で定義することが困難のため、情報システム部門に検討のサポートを役割として定義するなどの工夫が必要となります。 - 要求仕様書の雛形の標準化
要求仕様書の雛形を作成し、共有します。雛形は、それを元に記入すれば成果物が作成できるように電子ファイルで提供することが望ましいです。また、雛形は、具体的なサンプルを記入した雛形を提供することがポイントです。これがないと、定義すべき事項は分かるが、記載のレベル感が分かりづらくなってしまいます。 - 承認プロセスの標準化
要件に対する承認プロセスを明文化します。ただ、承認者となる利害関係者はシステムにより異なるため、ここでは、プロジェクトの最初の段階で利害関係者を認識し、検討に巻き込むこと、承認者とすることをルールとして定めることにより、利害関係者を巻き込みやすくするなどの対応が考えられます。
ユーザー企業における要求仕様定義力の向上は、要求仕様標準を一度作成するだけでは達成できません。実際のプロジェクトに適用し、継続的な見直しによる改善を行い、改訂していくことが必要です。さらに、プロジェクトで作成した要求仕様書をナレッジとして蓄積し、再利用することにより、さらなる要求仕様定義力の向上が可能になっていくことでしょう。
 |
新しくシステムを構築したい、現行システムは課題が多いので見直したい、という 状況があっても、第三者にもわかるように構築企画や要求仕様を文書にまとめあげ るのは意外と難しいようです。当セミナーでは、いわゆる上流工程の勘所をご紹介 します。 |
注：本連載「匠のキャリアへ」記事に関しましては、IT業界に特化したキャリア紹介業務を行う、テクノブレーン（株）のキャリアコンサルタントにより、業界の現場をリードする方々のキャリア・ノウハウを匠と称して記事紹介させて頂いております。読者の方々へエンジニア・アーキテクトとしてのキャリアビジョンを築くご参考になる記事として、ご愛顧頂けましたら幸いです。
