エンジニアに伝わるシステム要件定義の作り方

DX推進のお悩みで多いご相談の１つに、
「外注ベンダー・社内エンジニアに要望が上手く伝えられない」
こういった問題を抱えている企業さんが多いようです。

DXプロジェクトは大きく「企画」「推進」に分かれるのですが、
どんなに良い「企画」を考えても、エンジニアに正しく伝える「推進」が出来ないと
プロジェクト全体として失敗してしまいます。

そこで本記事では、DXプロジェクト推進のキモである
「どうやってエンジニアとコミュニケーションすると良いか？」について
詳しく解説していこうと思います。

まず、DXリーダー（プロマネ）とエンジニアが会話するフェーズは
「上流工程」と呼ばれ、大きく２種類（要件定義、基本設計）に分けられます。

１）要件定義

要件定義はプロジェクト目的を達成するためにどんなシステムが必要なのか、
DXリーダーからエンジニアへの要望を整理した資料です。

システム要件定義では主に、
「問題解決のためにどんな機能が必要か？」「いつ誰が使うのか」
といった情報が掲載されます。

２）基本設計

基本設計は、要件定義を満たすにはどんなシステムを開発すれば良いのか、
エンジニアからDXリーダへの提案資料です。

システム基本設計では主に、「画面設計」「機能設計」「データ設計」といった、
エンジニアでなくても完成像をイメージできる情報が必要とされます。

DXリーダの重要な役割として、システム開発をスタートする前に
「基本設計がシステム要件を満たしているか？」のチェックが必須です。

本記事では特に「システム要件定義」にフォーカスして、
「どのように進め、どんなスキルが必要なのか？」を体系的に整理します。

※ 基本設計チェックの解説は現在執筆中です。

まず要件定義でもっとも重要なポイントは「問題分析・相互理解」です。

というのも、弊社に相談いただく企業様にヒアリングすると
システム開発の失敗要因は２つに集約できるケースが多いです。

1. 要件定義の詰めが甘い（問題を正しく分析できていない）
2. エンジニアに要望が伝わらない（イメージと違うシステムが完成した）

つまり、要件定義の詰めが甘くて、しかもエンジニアに上手く伝えられない。
こういった非常に土台が弱い状態でプロジェクトが進められています。

問題分析は「Wny, What」で整理する

まず重要なのが「目指すゴール」を定義する問題分析です。

問題分析と言っても難しいアイディアを出す必要はなく、
大きく２種類の情報を整理すれば十分です。

1. Why：どんな問題があり、いつまでに、何を目指すのか？
2. What：課題を解決するために、どんなシステムが必要なのか？

相互理解は「要望=>要求=>要件」で深める

要件定義はビジネス側のDXリーダー（プロマネ）が主導するのですが、
エンジニアに相談しつつ「技術的には可能か？」をすり合わせる事が重要です。

理由としては、せっかくDXリーダーが企画を考えて
「このシステムが作れれば、プロジェクト成功は確実だ！」
そう思える要件定義が完成しても、それを開発するのはエンジニアです。

たとえば、完成した要件定義をエンジニアに見てもらった結果、
プロジェクト計画が崩れるような問題点が出てくるケースが多いです。
こういった金銭・時間の問題が出やすいです。

1. 「作れるけど１千万円は必要」
2. 「最短でも半年は必要」

こういった、後から問題が出てくる状況を避けるためには
段階的に「要望⇒要求⇒要件」の流れでエンジニアに相談・依頼します。

1. 要望：アイディア段階でラフに相談
2. 要求：仮案のブラッシュアップを依頼
3. 要件：開発のゴール認識を着地

ここからは、どうやって要件定義を進めたら良いのか紹介します。

具体的には、ビジネス側・エンジニア側それぞれのタスクを
５ステップに分解すると分かりやすいです。

1. ビジネス側のタスク　：①要望、③要求、⑤要件
2. エンジニア側のタスク：③検討、④提案

ステップ１：要望フェーズ

まず要望フェーズでは「こんなシステムがあったら良いな」といった、
アイディアの実現性をエンジニアに相談します。

そのためには、プロジェクトの全体像を描く必要があります。

1. 解決したい問題（現状・ゴールのギャップ）は？
2. 問題解決のために、どんなシステムが必要か？
3. 実際にシステム利用するユーザーの意見は？

2020年からのDXブーム以降、この要望フェーズで問題分析をやらずに、
思い付きだけでシステム開発をスタートしてしまう失敗が非常に多いです。

ステップ２：要求フェーズ

続いて要求フェーズでは、「システム開発の仮案」を作って
エンジニアに技術目線でブラッシュアップを依頼します。

多くの失敗ケースでは「〜〜したい」といった機能面ばかり書かれていて、
肝心の「誰が、いつ、何の目的で使うのか」とった実用性が考慮されていないです。

エンジニアが正確にシステム全体像を理解できるよう、
最初に「どんな情報が欲しいか？」を確認してから情報整理するのがベストです。

ステップ３：検討フェーズ

続いて、検討フェーズはエンジニア側のタスクです。 下記のような項目を回答してもらい、プロジェクトの実現性を判断します。

1. システム開発に必要な金額は？
2. いつごろ完成できそうか？
3. 技術的に難しい部分はあるか？

典型的に失敗するパターンとしては、
エンジニア側の「おおむね可能です」といった曖昧な回答を深掘りせず、
不明点を残したまま開発スタートしてしまう企業が多いです。

背景として、システム開発には「100%完全に作るべき部分」と
「妥協が許容できる部分」の２箇所が存在します。

ここの判断はエンジニア側には難しく、企画を作った本人が（DXリーダが）
「おおむね可能 = 妥協が必要」な部分はどこなのか、エンジニア側に確認します。

さらに補足として、可能/不可能を検討した結果として
「試しに作ってみないと分からない」といった結論になるケースも多いです。
（特にAI活用・データ分析プロジェクトに多いです）

そういった場合には、大きな予算を決める前準備として
「プロトタイプ（最小限の試作品）」を作って試すPoCフェーズを途中に挟みます。
このPoCフェーズは早くて数週間、長くても３ヶ月くらいで完了させます。

ステップ４：提案フェーズ

エンジニア側で検討フェーズが完了した後、
当初の企画に対して「どこまで実現可能か？」を提案してもらいます。

具体的には下記に関するプレゼンを受けます。

1. ビジネス要求からの変更点、代替案
2. 実装する機能、実装しない機能の切り分け
3. 開発コスト、開発期間

これらの内容を踏まえ、
プロジェクト計画が達成できそうか否かを判断します。

ステップ５：要件フェーズ

エンジニア側の提案を受け取った後、要件フェーズでは
どういったシステムを開発するのか最終決定します。

ここでは、当初のプロジェクト計画をブラッシュアップして
実行計画にまで落とし込むのがゴールです。

1. やると決めた事（開発する機能一覧・優先順位）
2. やらないと決めた事
3. システム導入後の運用フローを確定

ポイントとしては「やらないと決めた事」を明確にしておくと、
開発スタート後もエンジニア側とのコミュニケーションを円滑に回す事ができます。

また、システム完成像がイメージできるように
システム基本設計に先立って簡単な画面サンプル作っておくと
潜在ニーズの考慮モレを拾う事ができるのでオススメです。

以上が「エンジニアに伝わるシステム要件定義の作り方」でした。

繰り返しとなりますが、要件定義の５ステップは表面的なノウハウであって、
本質的なゴールは「ビジネス側・エンジニアの相互理解をつくる事」です。

常に「相手が存在する事」を前提においてコミュニケーションをとり、
「相手が知りたい情報」を提供する事がDXプロジェクト成功の近道です。

最後になりますが、DX推進では今までシステム開発に関わってこなかった
ビジネス現場のリーダなどが企画を担当するケースが多いです。

そのため「勘と経験」が不足して進め方がわからないのは仕方ない事だと思います。
この記事が、そういった方々のお役に立つことを願っています。

以上、最後までお読みいただき誠にありがとうございました。