連載
» 2010年05月19日 12時00分 公開

プロジェクト管理インタビュー:失敗しない要件定義、3つのポイント

ITシステムに求める要件が多様化、複雑化の一途をたどっている近年、要件定義の難易度もいっそう増している。そうした中でも、確実かつ効率的に要件定義を行うためには具体的にどうすればよいのだろうか? プライスウォーターハウスクーパースの?岡充宏氏に話を聞いた。

[@IT情報マネジメント編集部,@IT]

難易度が増している要件定義

 かつてITは、企業の業務を効率化してコストを削減するための手段として用いられていた。システム化の対象となる業務は、会計や人事など、ある程度定型化されたものがほとんどだった。だが今日、ITに求められる役割は効率化だけにとどまらない。ビジネスの「スピード」「精度」「利益」の向上に直結するような効果、ひいては経営戦略により深くコミットしたITの在り方が求められている。ITが担うべき役割は広く、そして複雑になっているのだ。

 こうした中、さらに重要性を増しているのがシステム開発における「要件定義」だ。むろん、かねてから指摘されてきたことではあるが、定型的な業務だけではなく、企業や業務によってさまざまに形が異なる非定型業務もシステム化の対象となっている今日、「システムで何を実現するかを明確化すること」の重要性は、従来以上に強く認識しておかなければならない。

 だが、要件が複雑化、あいまい化の一途をたどっている中で、要件定義の難易度も増している。そうした中でも要件定義を成功裏に収めるためには、どのようなことに留意すればよいのだろうか? また、プロジェクトマネージャにはどのようなマネジメントスキルが求められるのだろうか? コンサルタントとして、数々の要件定義に携わってきたプライスウォーターハウスクーパースの杦岡充宏氏に詳しく話を聞いた。

要件定義の前にやるべきこと

 杦岡氏は、これまでの自身の経験から、要件定義がうまくいかないパターンを3つに分けて説明する。

ALT プライスウォーターハウスクーパース
杦岡(すぎおか)充宏氏

 「まず1つ目が、いつまでたっても要件定義の作業が終わらないパターン。当初は3カ月で要件定義を終える予定だったものが、1年もかかってしまったことがあった。2つ目は、予定通りに要件定義フェイズを終えたものの、その内容が粗すぎて後工程で要件の抜けや漏れが見つかるというパターン。そして3つ目が、何でもかんでも要件に盛り込んでしまい、いつまでたっても終わらないケースだ。特に、システムの作り手側が顧客の言うことをうのみにして、そのすべてを要件に盛り込んでしまった結果、システムのアーキテクチャやプロジェクトの工数に無理が生じる、ということが往々にして起こる」(杦岡氏)

 中でも2つ目、「要件の“抜け”や“漏れ”」が発生するケースが非常に多いという。設計工程や製造工程で要件定義の漏れをユーザー側から指摘された結果、仕様が膨れ上がり、作業の手戻りも発生、プロジェクトは火の車……。最もひどいケースでは、ユーザー受け入れテストの段階になって初めて要件の漏れが見つかることもある。読者の中にも、このような痛い経験をした方は少なくないだろう。

 こうした事態に陥ることを防ぐために、杦岡氏は「要件定義の開始前にやるべき重要なことがある」という。

 「要件定義を始める前に、まずはIT部門とユーザー部門の間で、“システム導入によって解決すべき業務課題”を明確化し、共有しておかなくてはいけない。具体的には、システムのグランドデザインや企画書の作成などを行う。部門間のセクショナリズムを廃して、ユーザー側が期待するレベルと、IT側が想定するレベルをきちんとすり合わせ、プロジェクトの目的とゴールを定義する。こうしたことを行わずに要件定義を始めても、プロジェクト本来の目的を忘れた“システム化のためのシステム”になってしまい、本当に必要な要件が抜け落ちてしまう危険性が生じる」(杦岡氏)

要件定義フェイズにおけるプロジェクトマネジメント

 では、要件定義を進めるに当たり、プロジェクトマネジメントの観点からはどんなポイントに留意すればよいのだろうか? 杦岡氏は、まず「要件定義プロセスには、“設計・開発などで行うWBSに基づいたプロジェクトマネジメント”は通用しないと理解しておくべきだ」と指摘する。

 WBSに基づいたマネジメント手法は、「管理対象(成果物)と、そのための作業内容が決まっている」ことを前提としている。それゆえに定量的管理が可能になる。だが、要件定義は「管理対象(成果物)と作業内容そのものを決める」プロセスである。 ゆえに「何を、どう作るのか」を十分に深慮するようリードするマネジメントが肝要であり、要件定義書の本数など、そもそも定量的な観点で管理できるものではないのだ。

 杦岡氏は「一般的なプロジェクトマネジメントと同じ感覚で、定量的な観点だけで管理していたために、内容的に不十分な要件をそのまま後工程につなげてしまうケースが多い」と警鐘を鳴らす。

 このほかにも「アウトプットの平準化」「体制作り」という2つのポイント挙げる。アウトプットの平準化とは、換言すれば要件定義作業の「属人化」を排するということである。例えば、ある人が書いた要件定義書は非常に丁寧だが、別の人が書いたものは粗い。あるいは、あるチームが作成した仕様書は細かいところまで規定されているが、別のチームが作成したものは大ざっぱ――このように、担当者やチームによって成果物のクオリティや粒度がバラバラだと、雑な作業によって要件漏れが発生しやすくなるだけではなく、そうした成果物を受け取るユーザー側も混乱してしまい、ますます要件定義の質が低下してしまう。プロジェクトマネージャは、ドキュメントのフォーマットを統一するなどして、こうした問題を未然に防ぐ手だてを講じるべきだという。

柔軟な体制作りと歩み寄りを

 一方、プロジェクトの体制作りも要件定義の成否を左右する重要なポイントとなる。通常、要件定義はユーザー部門とIT部門、そして場合によってはSIerやITベンダなどのパートナー企業も交えて行われる。この2者、ないし3者間の関係性は、企業の状況やプロジェクトの内容によってさまざまな形が考えられる。

 例えば、ユーザー部門は多くのスキルセットと人員を保有しているが、IT部門はそれらが貧弱なケースがある。あるいは、ユーザー部門にスキルがなく、IT部門にスキルが集中しているケースもあるだろう。後者の場合、ユーザー部門は独力で自分たちの要件をまとめ上げるスキルを持ち合わせていないことがほとんどだ。にもかかわらず、IT部門やパートナー企業は「要件定義はユーザーの責任。われわれは言われたものだけを作る」と、突き放した態度を取ることが少なくない。

 これは、自分たちの身を守るためのリスクヘッジとしては間違いではないだろうが、「プロジェクトを成功に導くための本質的な対処」には程遠い。杦岡氏は次のように提言する。

 「ユーザー部門とIT部門、互いの現状におけるスキルセットと人員ボリュームのバランスによって、どちらがどう歩み寄ればよいのか自ずと見えてくるはずだ。また、外部のパートナー企業などに求める支援の質も、それによって決まってくる。こうした“現状”を考慮した体制と、それに基づいた作業の進め方を考えることが重要だ」

 例えば、ユーザー部門に要件定義スキルが不足している場合、IT部門やパートナー企業からユーザー部門に要員を派遣する、あるいは、コンサルタントのような第三者をプロジェクトに加える。プロジェクトマネージャは、このように各関係者の状況を考慮し、それに最適な体制作りをリードする必要があるのだ。むろん、そうした体制作りの一環として、ユーザー部門をはじめ、プロジェクトチーム外部のステークホルダーと密にコミュニケーションを図ることも忘れてはならない。そうしたパートナーシップを築くことが、“後工程でひっくり返されない”要件定義書の完成につながるのだ。

 いずれにせよ、要件定義で最も重要なポイントはIT側がユーザー側のレベルに合わせて、柔軟かつ積極的に歩み寄ることといえよう。杦岡氏も次のように締めくくった。

 「要件定義で最も大事なのは『顧客の立場でものを考えられるか』――これに尽きると思う」

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ