要件定義の要、機能一覧をどう作る？PMとしての実践記録

はじめに

システム開発における要件定義工程は、プロジェクトの成功を左右する重要なフェーズです。この工程では、顧客の業務プロセスや課題を深く理解し、それを解決するための具体的なシステム要件を整理します。その中でも、機能一覧の作成は、仕様の土台を築くうえで欠かせない工程です。

今回は、複雑な書類処理や高い正確性が求められる業務向けシステムのプロジェクトで、私が実際に機能一覧作成を通じて得た気づきや改善の工夫をご紹介します。

なぜ機能一覧が重要なのか？

機能一覧を作成することには、プロジェクトを円滑に進めるうえで多くのメリットがあります。

たとえば、以下のような点が挙げられます。

顧客と開発チームの認識を一致させる
要件の漏れや誤解を防ぎ、システム全体の品質向上につながる
スケジュールやコストをより正確に見積もるための基盤となる

機能一覧は、ただのリストではなく、関係者全員が共通の理解を持つための“言語”のような役割を果たします。特に、複数の担当者が関与し、書類作成や承認などのプロセスが複雑な業務を扱うシステムでは、少しの認識のズレが大きな手戻りにつながる可能性があります。このような現場では、機能の抜けや仕様の曖昧さが致命的になるため、あらかじめ整理された機能一覧を用意しておくことが、プロジェクト成功の大前提になります。

私自身、これまでさまざまな業界のプロジェクトでPM（プロジェクトマネージャー）として機能一覧の作成に携わってきました。その中でも、今回担当した、複雑な契約文書の作成業務を支援するシステム開発では、従来のやり方では通用しない場面も多く、顧客からの鋭い指摘や高い期待に直面することが多々ありました。

こうした実践を通じて、機能一覧を「作る」から「伝える」ためのツールへと発想を変える必要性を感じました。本記事では、そのような経験を踏まえながら、どのように機能一覧を構成し、注意すべき点を整理していったのかをご紹介したいと思います。

機能一覧作成の手順と今回の実践

機能一覧を作成する際には、一定の流れに沿って丁寧に進めることが、精度の高いシステム設計につながります。ここでは、筆者がこれまでのプロジェクトで活用してきた基本的な手順に加え、今回の案件で実践した具体的な工夫についてご紹介します。

①要件の収集：現場の声と課題の把握から始める

まず最初に行うのは、システムに対してどのような機能が求められているのかを把握することです。顧客へのヒアリングや、すでに存在している業務資料・過去の仕様書などを通じて情報を集めます。特に注目すべきは、業務フローの全体像や、現在困っていること・手作業で対応しているような業務上の課題です。こうした背景を理解することで、本質的に必要な機能が見えてきます。

②機能の分類：似た目的の機能をグルーピング

収集した要件を基に、機能をグループ化します。今回のプロジェクトでは、事前に顧客側で整理した機能一覧が提示されていたため、その資料をベースに機能の分類を行いました。

ただし、そのまま採用するのではなく、目的や動作の観点から見直しも行いました。顧客の理解しやすい構成にすることを意識し、後のレビュー工程がスムーズになるよう配慮しています。

③機能の詳細化：「誰が」「何をするか」を明確に

機能がある程度整理されたら、次は各機能について、どのように動作するのかを具体的に記述していきます。ここでは「誰が」「何をするのか」という視点を含めることで、役割分担やワークフローが分かりやすくなります。

④レビューと修正：第三者の視点で見直す

詳細化した機能一覧は、必ず顧客や関係者と共有し、意見をもらうようにします。この段階で、想定外の視点からのフィードバックや、曖昧な部分の指摘が得られることが多く、結果として品質が高まります。

⑤優先順位付けと見積もりの実施：現実的な実施計画へとつなげる

最後に、整理された機能に対して優先順位を付け、どの順番で実装していくかを決めます。あわせて、それぞれの機能にかかる作業量や工数を見積もることで、スケジュールや費用の計画も立てやすくなります。

今回のプロジェクトでも、上記の手順を踏みつつ、プロジェクト固有の対応をいくつか行っています。

まず、顧客側で事前に整理された機能一覧が提示されていたため、その内容を基に分類を行いました。その際、内容だけでなく、「どのような粒度や表現で書かれているか」といった資料の特徴にも注意を払い、顧客の目線に合わせた構成にすることを意識しました。これにより、レビュー時のコミュニケーションが円滑になり、認識のズレを最小限に抑えることができました。

また、最終的な費用見積もりを効率よく行うために、機能一覧を再編成しました。各機能について「具体的に何を開発するか」を明示し、対応する工数や費用を算出しやすい形式にまとめました。この工夫により、開発側の工数が算出しやすくなり、同時に顧客が納得しやすい見積もりが提示できるようになったと感じています。

実際のプロジェクトで直面した課題とその改善プロセス

さて、要件定義工程における資料作りは、私自身、過去のプロジェクトでも経験があるので、今までの知見を活かして取り組みました。

ところが、作成した機能一覧を顧客に共有したところ、期待していたような反応は得られませんでした。

顧客からは次のような質問が挙がり、機能一覧のわかりにくさを指摘されました。

この機能は、どのロールの人が使うのか？
どの条件でこの機能が有効になるのか？
ステータスの種類や定義は？

こうした指摘の背景には、顧客が網羅的かつ明確な機能一覧を求めていたという事情があります。

今回の顧客は、これまでSIer（システムインテグレーター）とともにシステム開発を進めてきた企業でしたが、SIerの人員不足やリソースの限界により、弊社に依頼が来た背景があります。SIerとの経験を持つ顧客は、要件定義やレビューに慣れており、特に機能一覧に対して正確性と網羅性を強く求めていたことが、上記のような指摘につながりました。

こうした状況を踏まえ、以下の見直しを実施しました。

①分類の見直し

初版では顧客が提示した構成を踏襲したため、分類が不明瞭でした。

これを契約書作成の業務フローに基づく分類に再構築することで、機能の網羅性と一貫性を確保しました。

②「誰が使うか」の明示

各機能に対して、利用者の役割や立場を明記しました。「誰がこの機能を使用するのか」がすぐに把握できるよう、チェックリスト形式で機能一覧の中に盛り込むことで、顧客が機能一覧を迅速に理解できるようにしました。

③用語の定義を明確化

例えば「ステータス」という概念について、初版では明確な定義がなかったため、条件や状態を具体的に記載しました。この変更により、顧客が機能一覧をもとに議論を進めやすくなりました。

これらの修正により、顧客レビューでは具体的な質問や優先順位の議論が行われるようになり、プロジェクト全体の方向性を共有することができました。