Interview
システム開発における「要件定義」の重要性:株式会社ビープラウドの佐藤氏に聞く
株式会社ビープラウド
公開日
2025.02.12

企業のDX(デジタルトランスフォーメーション)推進が加速する中で、システム開発の成否を左右する「要件定義」の重要性がますます高まっています。しかし、要件定義は多岐にわたる要素を調整しながら進める難解なプロセスであり、多くのプロジェクトがこの段階でつまずいているのも事実です。そこで今回は、システム開発における豊富な経験を持つ株式会社ビープラウドの代表取締役、佐藤治夫氏に、要件定義における重要な要素、具体的な進め方について詳しくお話を伺いました。
佐藤 治夫
株式会社ビープラウド 代表取締役
2006年株式会社ビープラウドを設立、代表取締役に就任。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践。開発者のためのドキュメントサービスTRACERY(トレーサリー)(https://tracery.jp/)運営のオウンドメディア「TRACERY Lab.(トレラボ)(https://tracery.jp/articles/)」で、これまで培ってきた要件定義のノウハウを発信。
要件定義における重要な要素
撮影場所:WeWork 丸の内北口
インタビュアー: 要件定義を進める上で、特に重要な要素は何でしょうか?
佐藤氏: 要件定義のスタート地点で最も重要なことは、システム開発の目的と実現したい価値を明確にすることです。事業レベルで、どのような価値を実現したいのかを、関係者間でしっかりと合意しておく必要があります。目的が曖昧なまま進めてしまうと、途中でブレが生じ、最終的に価値を生み出さないシステムになってしまう可能性があります。
インタビュアー: システム開発の目的と価値を明確にすること、ここがまさに難しいポイントかと思いますが、御社ではどのように進めているのでしょうか?
佐藤氏: ビジネスアナリシスの手法である「匠Method」という手法を用いて、価値の可視化に取り組んでいます。 ステークホルダーが集まり、「この価値概念が実現した場合、どの程度のインパクトがあると思うか」をあらわすポイントをステークホルダーのそれぞれが提示します。それが出揃ったあとで「なぜそのポイントを付けたのか」を議論し、認識を擦り合わせます。このプロセスを繰り返すことで、価値の評価に対する認識のズレが解消され、要求が徐々にブラッシュアップされていきます。
引用元:Value Metricsの4つの効果〜匠Method Value Metricsとゴール記述モデルによるモデルの検証その1
インタビュアー: 価値が曖昧な場合は、まずそこから整理するということですね。
佐藤氏: そうですね。また、ポイントについて「私はこういう価値があると思います」と価値の評価理由を議論したり、価値の説明を価値概念として書いていくことで、単に価値を評価するだけでなく、新たな価値を発見していくことにも繋がると考えています。
インタビュアー: その他に重要な要素はありますか?
佐藤氏: はい、ステークホルダーを漏れなく洗い出すことも非常に重要です。システムに関わる全ての人々、例えば経営層、現場担当者、開発チームなどの意見を把握し、それぞれの立場にとって何が価値なのかを明確にしておく必要があります。もし、ステークホルダーにとっての重要な価値がシステムに反映されない場合、後々になってプロジェクトが頓挫してしまうリスクが高くなってしまいます。
要求分析と優先順位付け
撮影場所:WeWork 丸の内北口
インタビュアー: 要求分析を進める上で、重要なポイントは何でしょうか?
佐藤氏: ビジョンから業務、ITレベルまでの要求をツリー状に整理していくことが重要です。どの機能を開発するかという優先順位を付ける際に、上位の目的や価値とどのように繋がるのかを明確にすることで、優先順位付けが容易になります。
インタビュアー: 要求を構造化することで、優先順位もつけやすくなるんですね。
佐藤氏: はい。さらに、価値だけではなく、IT要求や活動もポイントで評価することによって要求の妥当性も検証できるようになります。たとえば、価値のポイントよりも活動のポイントが低い場合、それは要求が十分に抽出されていない可能性があり、精度の低い業務要求をあげているのではないかと判断できます。
引用元:Value Metricsの4つの効果〜匠Method Value Metricsとゴール記述モデルによるモデルの検証その1
顧客とのコミュニケーションにおける工夫
インタビュアー: システム開発の経験があまりないお客様とのコミュニケーションで、工夫されていることはありますか?
佐藤氏: 業務フローのレベルで合意形成を図ることが有効なアプローチだと考えています。具体的には業務プロセスを可視化することです。業務フロー図を使って、いつ、誰が、どのように業務を行うのかなど5W2Hの内容を明確にします。その上で、システムを導入する前と後で、業務がどのように変わるのかを比較し、新たな価値が生まれるかを確認し、合意形成を図ることが大事だと捉えています。
引用元:業務フロー図で見える化する業務プロセスからシステム要件への道筋
インタビュアー: 現状の業務整理やあるべき姿のフローの整理部分は粒度や品質の部分のコントロールが難しいですが、機能要件に落としていくためには非常に重要なステップですよね。
佐藤氏: そうですね。要件定義は地道な仕事も多いですし、要件をまとめていくのには一定の時間がかかります。そのため、コアとなる業務から優先的に着手し、全体像を把握することを意識して進めています。また、お客様も他部署の業務について細かい内容を把握していないことも多いので、業務プロセスを俯瞰してステークホルダー全員であるべき姿を議論すること自体に価値があると思っています。業務の可視化は手間がかかることも多いですが、非常に大事なプロセスですね。
要件定義における役割分担
インタビュアー: 要件定義を進める上で、どのような役割分担が必要でしょうか?
佐藤氏: ビジネスを理解するビジネスアナリスト、データ設計や、インフラや性能などの非機能要件を検討するアーキテクト、UIをデザインするUIデザイナーなど、様々な役割が必要です。
インタビュアー: システム開発を行う上では、事業側の視点とIT側の視点双方を抑えながら進めていく必要がありますよね。
佐藤氏: そうですね。ビジネス側の視点から要件を理解し、システムとの橋渡しをする役割を担う人材がなかなかいないのが世の中の現状だと思っています。システムにおけるステークホルダー間のトレードオフを正しく理解し、ビジネス要求からシステム要求に落とし込むためには、システム開発の豊富な知識や経験があることをベースとして、ビジネスサイドの視点を持っていることが求められますね。
引用元:要件定義の難しさ
要件定義の変遷と今後の展望
インタビュアー: 要件定義の考え方や進め方は、昔と比べてどのように変化してきたと思いますか?
佐藤氏: 従来の要件定義では、文書ベースで要件定義を行うことが一般的でした。大量のドキュメントを作成し、文章で要件を詳細に記述していました。しかし、文書だけでは、関係者間で認識のずれが生じやすく、コミュニケーションコストが高いという問題があります。そのため、モデルベースで、図を使って要件定義を行うことが多くなりつつあると思います。
インタビュアー: モデルベースのメリットは何でしょうか?
佐藤氏: 文章よりも図の方が、情報が伝わりやすく、合意形成がしやすいというメリットがあります。特に、複雑なシステムや業務プロセスを扱う場合、図を用いることで、全体像を把握しやすくなり、議論がスムーズに進みます。また、 図で表現することで、文章だけでは気づきにくい矛盾点や不整合を早期に発見できる点もよいと考えています。システムの構造やデータの流れを図で可視化することで、論理的な矛盾やデータの不整合を容易に発見し、要件の品質をあげていくことができます。
インタビュアー: 今後のシステム開発において、生成AIはどのような役割を果たすと思いますか?
佐藤氏: 生成AIは、設計や実装の領域で、先行して活用が進んでいます。今後は、要件定義のベースとなる叩き台を作成するなど、より上流の工程で活用されるようになると思います。生成AIの発展により、1人ができることのカバー範囲は広がるかもしれませんが、要件定義自体の重要性は変わらないと考えています。何を開発するのか、どのような価値を生み出すのかを明確にすることは、システム開発において最も重要なことであり、今後もこの点は変わらないでしょう。
撮影場所:WeWork 丸の内北口
おわりに
今回は、株式会社ビープラウドの佐藤氏に、システム開発における要件定義の重要性について、詳しくお話を伺いました。要件定義は、システム開発の成否を左右する非常に重要な工程です。今回のインタビュー記事が、読者の皆様のシステム開発の一助となれば幸いです。
ご協力いただいた企業様
株式会社ビープラウド
Pythonを主力技術とし、Webシステムや機械学習システムの開発、数理最適化コンサルティングを提供。IT勉強会支援プラットフォームやオンライン学習サービスも展開し、技術者コミュニティの活性化と人材育成に貢献。
