開発ベンダーとの行き違いは要件定義で回避する【第4回】

機能要件だけでなく非機能要件も決める

　要件定義は、RFPや開発ベンダーからの提案内容を具現化することから始まります。当初は希望ベースだった機能要件や非機能要件について、より深く踏み込み、実現すべきシステムの具体的な形を作っていく作業です。

　機能要件では、まず自らが業務フローや処理フローを提示すれば、それを開発ベンダーが文章や図などを用いて表現します。その内容に関する認識に齟齬（そご）がないかどうかを確認し合意を得るという作業を1つひとつ積み重ねることで、システムの全体像が明確になっていきます。

　フローを整理する過程で「この機能を実現するために必要なデータは、どこから取得できるのか」といった点も明らかになります。これらは設計など次工程で詳細化します。

　一方の非機能要件では、自社サービスが目標とする利用者数やサービス提供時間といった可用性など、システム基盤を作り上げるための要件を議論します。開発ベンダーを信頼する必要はありますが、提案内容の実現性やコストについては徹底的に議論を尽くすべきです。

　これら機能要件と非機能要件の議論を経て作成する成果物が「要件定義書」です（図2）。発注者と開発ベンダーの双方が合意して初めて、設計などの次工程に進めます。それだけに要件定義書は、以降の全工程のベースになる非常に重要な文書だということです。

図2：要件定義書には機能要件と非機能要件を記載する

　ちなみに当社では、この要件定義のタイミングで、機能要件・非機能要件と併せてUX（User Experience：顧客体験）／UI（User Interface）も検討します。最適なUX／UIはユーザー体験を重視してこそ実現できるものです。そのためUX／UIを併せて検討することが、機能要件を洗練させ最終的なUX向上に直結すると考えるからです。

“お客様気分”ではプロジェクトの真の成功はない

　要件定義が成功するかどうかは、発注者自身の積極的な関与にかかっています。まずはキックオフミーティングを開催し、開発ベンダーと顔を合わせ、プロジェクトのゴールと工程をすり合わせながら関係者の意識を統一します。この場にはできるだけ多くのメンバーが出席し、コミュニケーションを密に図ることが重要です。ただ参加者が多い場合は、レポートラインを明確にしておきましょう。

　初期段階では会議の時間を惜しまず、開発ベンダーからの依頼事項には最大限対応することが成功への近道です。逆に開発ベンダーの対応があいまいなら、受身にならず、不明点を潰していく必要があります。

　要件定義では要望が膨らみがちです。ですが予算と期間は有限です。遅延や最終的な機能削減といった嬉しくない結果を避けるためには、決裁権を持つメンバーは必ず会議に同席し、迅速な方針決定を心がけてください。

　個々の会議については「今回は、この画面の仕様を決める」といった具体的なゴールの設定が重要です。議論が発散してもゴールに立ち戻ることで、闇雲な会議を避け、効率的にプロジェクトを推進できます。

　全工程の中で最も重要な要件定義ですが、実はこの工程が最大の関門です。それだけに発注者が“お客様気分”で受け身に構えることは百害あって一利なしです。「よく分からないから、プロである開発ベンダーにお任せします」という態度は一見、謙虚に見えるかもしれませんが実態は「当事者意識の欠如」に他なりません。開発ベンダーはITのプロではありますが、発注者のビジネスの核心部分は発注者にしかわかりません。

　だからこそ発注者が、自社サービスの未来の基盤を築く当事者として、誰よりも前のめりで議論に参加すべきです。開発ベンダーからの質問は、サービスの本質を突く重要な問いのはずです。それに対し、社内の英知を結集し全力で回答するとともに設定された期限を厳守する。この的確かつ迅速なレスポンスが、プロジェクトの質とスピードを担保します。

　もちろん、その真摯な姿勢と熱意は、開発ベンダーにも同様に求めるべきです。つまり、お互いが「発注者と業者」ではなく「成功を目指すパートナー」としてリスペクトし、時には激しく意見をぶつけ合う。この熱意ある議論の先にこそ、強固なシステム基盤が築かれ、プロジェクトを真の成功へと導くのです。