開発するシステムでお客様が実現したいことを明確化する「要件定義」は、プロジェクトの要となる重要な工程の一つです。要件定義の成否はプロジェクトの成功に大きく影響するため、この工程をいかにうまく進めるかがエンジニアにとって腕の見せ所にもなります。
これまでさまざまなプロジェクトをマネジメントしてきた経験を基に、要件定義の成否を分けるポイントや、うまく進めるためのコツなどをご紹介します。

プロフィール

▼Yusaku.Tの過去の記事はこちらから

要件定義の成否がプロジェクトの成功を左右する

エンタープライズソリューション本部では、さまざまな業界のお客様の基幹システムや業務システムの開発／保守を行っています。その中で、私が所属するGlobal Bridge部では、大規模から中小規模のプロジェクトまで幅広く手掛けており、対象は基幹系からWeb系、スマホアプリ、SaaSなどのパッケージ導入まで多岐にわたります。

これらのプロジェクトのいずれにおいても、要件定義は最も重要な工程の一つです。ご存じのとおり、要件定義とはお客様が実現したいことを摺り合わせて言語化し、システム開発後の業務を明確にイメージしていただく工程です。開発側の観点でも重要であり、要件定義の結果は、その後の設計や開発などプロジェクト全体の進め方やスケジュールの根拠になるほか、費用の見積もりを提示する前提条件ともなります。要件定義がうまくできるかどうかが、プロジェクト全体の成否に大きくかかわるのです。

要件定義の対象には、大きく「機能要件」と「非機能要件」の2つがあります。機能要件とは、システムの機能や画面など目に見える部分が中心であり、お客様にとっては比較的イメージしやすい要件です。それに対して、非機能要件とはシステムの性能など目に見えないものが中心であり、多くのお客様にとってイメージしづらい要件です。

▼Global Bridge部についての紹介記事はこちらから

システム完成後の業務を具体的にイメージしてもらうことが大切

私の経験では、非機能要件をうまく引き出して摺り合わせられるかどうかが一つの鍵になります。例えば、出来上がったシステムの性能などに関して、お客様が支障を感じなければ問題はないのですが、「画面を操作した際に処理が重たく感じるので改善したい」などとなった場合、予定していたスケジュールや費用での対応が難しくなることがあります。

機能要件についても、開発後に「こういう機能が欲しい」といった追加要求が発生することがあります。要件定義は完成したシステムがない状態で行うため、お客様は新しいシステムを使った業務の流れをイメージしきれない場合が少なくありませんし、ヒアリングする側の伝え方や理解力も重要です。これがうまく擦り合っていないと、出来上がったシステムを触っていただいた際に問題が生じやすいと感じています。

例えば、導入したパッケージの機能で要件を満たせると考えていたが、実際にお客様に触っていただいて発生した追加要望がパッケージの制約などから開発が難しい、ある程度の開発期間が必要といったことがあります。その場合、スケジュール内でどこまで対応するかを調整したり、いったんリリースした後の保守／開発の中で機能を追加したりといった対応を行います。

とにかく明確に─要件定義の成否を分けるポイント

要件定義がうまくいったケースについて、その大きな要因を考えてみると、やはり新しいシステムを使った業務を具体的にイメージしていただけた場合です。プロジェクトによりケースバイケースですが、要件定義の段階や、その後の設計の早い段階でプロトタイプ的な画面を用意し、完成後のシステムのイメージを明確化するといったプロセスを踏むと成功率が格段に上がりますね。

非機能要件については、情報処理推進機構（IPA）が定める非機能要求事項などに基づいて定義します。各項目がどういった意味を持ち、それを満たせない場合はどのような影響があるのかをお客様にご説明し、どの程度の要求レベルを満たすのかをしっかりと摺り合わせします。非機能要件は高い要求を満たそうとすれば多くの工数とコストがかかるため、プロジェクトやシステムの特性に応じて重要な項目に重点を置くなど、バランスを取りながら定義していきます。

要件定義の際にお客様との間で特に齟齬が生じやすいのは、業務的にイレギュラーなフローや発生頻度が少ない業務パターンです。メインの業務フローはお客様もイメージしやすく、その部分はうまく回ることが確認できても、後々の受け入れテストなどで特殊な業務パターンをテストした際、それが要件として挙がっておらず、実装予定に含まれていなかったといったことが起こりえます。

また、大規模なシステムの開発では、プロジェクトで対応する範囲を明らかにすることも大切です。周辺の他システムとデータ連携を行う場合、こちら側のシステムではデータを出力して所定の場所に保管するところまで責任を持つといった責任分界点を明確にしておかないと、後々、他システムも含めて業務全体を回した際に問題が生じる可能性があります。

プロジェクトのキーマンをうまく巻き込むには

要件定義も含めて何か問題が生じた際、私はなるべく巻き込むべき人を巻き込むようにしています。プロジェクトに閉じたかたちでリカバリーするのがベストですが、それに固執しすぎると問題が大きくなってしまうことがあります。上長に確認のうえ、他チームのスペシャリストなどに必要に応じてスポットで入ってもらうなどの手段を早めに検討するよう気を付けています。

また、要件定義はお客様とともに進めることが前提です。多くのお客様は既存業務をこなしながら新システムの要件の摺り合わせに時間を割くことになります。その時間を確保していただくために、プロジェクトが立ち上がったタイミングで「これくらいの期間で、これくらいの時間を想定しています」といったことを事前にお伝えするようにしています。

要件定義の結果は、最終的にお客様側の意思決定者に対面や書面でのレビューを受けて承認していただきます。ご担当者が多忙でレビューの時間をとれない場合、その後のスケジュールが全て遅延してしまいます。大規模なプロジェクトになるとお客様側の意思決定者も上層の方となり、多忙によりプロジェクトの定例会に出席できないケースが増えてきます。その場合は別途、ステークホルダー向けの会議を開いて月次などで進捗をご報告し、最終的な意思決定／承認の場も別途設けるといったことを行います。

組織的な対応で要件定義の質をさらに高める

要件定義の失敗を防ぐには、組織的な対応も有効です。エンタープライズソリューション本部では専任のPMO組織を置き、各プロジェクトの全体計画や要件定義の内容をチェックしています。これらのレビューを受けることで、過去に組織が携わった類似プロジェクトの成功や失敗の経験から、何に気を付けるべきかといった観点を得ることができます。

▼エンタープライズソリューション本部のPMO組織についての紹介記事はこちらから

また、要件定義ではお客様の業務や業務用語に関して十分な知識を持つことも重要です。過去に扱った経験のある業界でも、お客様によって業務や用語が異なる場合があります。そのときは、チーム内で業務／用語の整理を行い、プロジェクトの早い段階でお客様に業務／用語について確認するよう心掛けています。

パーソルクロステクノロジーはプライムベンダーとして多種多様な業界のシステムを手掛けており、お客様と直接折衝しながらシステムを作っていきたいというエンジニアには特にフィットする職場です。

人材の特性や志望に応じた部署間の異動も積極的に行っており、たとえば「Web系の仕事をしたくて入ったけど、スマホアプリにも取り組んでみたい」となったら、それを重点的に担当している部署に異動するといったこともやりやすい企業文化があります。
エンジニアとしてさらなる成長と活躍の場を求めている方は、ぜひ私たちと共に仕事をしませんか。

パーソルクロステクノロジーでは幅広いポジションで積極的に採用中！
超上流から関われるプライム案件にジョインしていただけるエンジニアを募集しています。
企画から保守運用まで一気通貫で関われるSIerの組織で、エンジニアとしてのキャリアアップを目指しませんか？
現在募集中の職種は、以下リンクの事業領域「システムインテグレーション」をご覧ください。