シリーズ: 超上流から攻めるIT化の原理原則17ヶ条
- 『超上流から攻めるIT化の原理原則17ヶ条』は、要件定義に取り組む全ての人に読んでほしい実践ガイド
- ユーザとベンダの想いは相反する〜 超上流から攻めるIT化の原理原則17ヶ条/ 原理原則その1（本記事）
TRACERYプロダクトマネージャーの haru です。
システム開発では、ビジネス側と開発側が協調し、ビジネス価値の創出に向けて動くことが求められます。
特に要件定義では、この協力関係が成功の鍵を握ります。
そのためには、まず相互理解が欠かせません。ビジネス側と開発側がお互いの考えていること、背景や価値観、そして日々の業務への理解を深めることが、協力の第一歩となります。
本記事では、『超上流から攻めるIT化の原理原則17ヶ条』の第1条『ユーザ*1とベンダ*2の想いは相反する』を読み解いていきます。
ユーザとベンダの想いはなぜ相反するのか
『ユーザとベンダの想いは相反する』の原則は、システム開発において、ビジネス側（ユーザ、発注側）と開発側（ベンダ、受注側）が持つ責任の違いにより、相反する思惑が生まれ、衝突しやすい現実を示しています。
ビジネス側と開発側の責任の違いとは、それぞれの役割において、QCD（品質、コスト、期限）のどれを優先するかが異なる点です。
QCD（品質・コスト・期限）は密接に関連し、トレードオフ*3という関係にあります。たとえば、品質を向上させれば費用が増加し、期限が延びます。一方、期限を短縮したり費用を削減したりすると、品質が犠牲になります。また、費用を抑えながら品質を維持しようとすれば、結果として期限が延びます。
たとえビジネス側と開発側が「ビジネス価値の創出」という共通の目的を共有していたとしても、QCD（品質、コスト、期限）のトレードオフにより相反する思惑が生じることがあります。また、同じビジネスや開発の中でも、何を優先すべきかで意見が対立する場合があります。
下表に、要件定義における、ビジネス側と開発側の責任*4と義務*5、想いをまとめました（IPAが公開しているPDFの6ページの図を元に作成）。
下図は、上記の表における両者の想いの相反関係を示したものです。
図に示された相反関係の一例として、要件や見積の品質（Quality）を時間をかけて高めようとすると（図の左側）、期限（Delivery）に間に合わないリスクや費用（Cost）の増大が発生すること（図の右側）が挙げられます。
これらの相反関係を理解し、調整することが、プロジェクト成功の鍵となることを『超上流から攻めるIT化の原理原則17ヶ条』の第1条『ユーザとベンダの想いは相反する』は示しています。
行動規範
『超上流から攻めるIT化の原理原則17ヶ条』の第1条には、ビジネス側と開発側の相反する想いを解決するための行動規範として、以下の3つが挙げられています。
- 発注者・受注者は、お互いの責任、義務、想いを知る
- 発注者は受注者との役割分担を明確にし、プロジェクトに積極的に参画する
- 発注側業務部門も、"システム開発"を理解する
これらの行動規範を見ると、その内容は発注者側（ビジネス側）に偏りが見られます（発注者側が3つ全て、受注者側が1つに該当。超上流から攻めるIT化の原理原則17ヶ条（原理原則と行動規範の一覧）参照のこと）。
これは、過去に発注者側が要件定義段階から開発を受注者側に丸投げして問題が発生する事例が多く見られたことが背景にあります。第1条はこのような状況を改善するため、発注者側が積極的に取り組むことで、発注者と受注者が対等な関係を築くことを主に目指した原則でといえるでしょう。
ただし、この原則は発注者側だけが一方的に努力することを意味するものではありません。発注者と受注者の双方がそれぞれの役割と責任を理解し、協力して課題に取り組むことが求められます。互いに主体性を持つことで、より良い開発プロセスと成果が実現できます。
以下に、行動規範のそれぞれについて説明します。
発注者・受注者は、お互いの責任、義務、想いを知る
ビジネス側と開発側でQCD（品質・コスト・期限）の何を重視するかによって、取るべき行動や考え方がどのように変わるのかを理解することから始める必要があります。
お互いの想い（下図のAとB）を率直に話し合い、相手の立場を理解した上で、両者が共有できる価値を見出す姿勢が求められます。この共通の価値（AとBからCを生み出す）を追求することで、真の協力関係を築くことができるのです。
これは、単に妥協点を探ることではなく、双方の強みを活かし合い、新たな可能性を見出すことを意味します。
発注者は受注者との役割分担を明確にし、プロジェクトに積極的に参画する
この行動規範は、以下の2つの内容に分けられます。
- 発注者は受注者との役割分担を明確にする
- 発注者は、プロジェクトに積極的に参画する
それぞれ、以下に説明します。
発注者は受注者との役割分担を明確にする
要件定義におけるビジネス側と開発側の役割分担を曖昧にしてしまうと、タスクが宙に浮き、結果としてスケジュールの遅延やコストの増大といった深刻な問題を引き起こします。
役割分担の例を以下に示します。
ビジネス側の役割
- ビジネス目標の設定
- ユーザーのニーズを集める
- 必要情報の提供
- 優先順位の決定
- ステークホルダーの調整・合意形成
- 予算管理
開発側の役割
- 要件の文書化*6
- コスト見積もり
- スケジュール作成
- 技術的リスクの評価
- モックアップやプロトタイプの作成
役割分担を明確にすることで、責任の所在が明確になり、効率的なコミュニケーションが実現します。また、双方が主体的に取り組む姿勢を持つことで、課題の早期発見や迅速な対応が可能になり、プロジェクトの成功率が向上します。
発注者は、プロジェクトに積極的に参画する
開発プロジェクトを成功させるためには、ビジネス側が主体的に参加することが欠かせません。
よくある例としては、ビジネス側のプロジェクト担当者が多忙を極め、開発側の質問に対する回答が遅れたり、ミーティングの設定もままならないという状態です。
こうした状況が続くと、要件定義フェーズの進行が大きく停滞する恐れがあります。たとえば、ビジネス側の担当者が多忙で詳細な説明を提供できない場合、開発チームが「想定で進めざるを得ない」状況に陥りがちです。その結果、後に判明した要件のズレや仕様の抜け漏れが手戻りを引き起こし、プロジェクト全体のスケジュールが破綻する事態を招きます*7。
ステークホルダー間での意思決定が遅れることも、要件定義での典型的な課題です。特に、意思決定者が明確に定義されていない場合や、承認プロセスが煩雑すぎる場合、プロジェクトが一向に前に進まない状況に陥ります。
ビジネス側に専任の担当者を置くことが理想ですが、開発側からの質問に迅速に答える仕組みを整えたり、スケジュールにミーティングを組み込み、開発側とのコミュニケーションを密にすることで、上記のような問題が発生するリスクを下げることできます。
一方で開発側は、ビジネス側がプロジェクトに積極的に関与できるよう支援する必要があります。必要な情報や技術的な内容、要件の具体的な選択肢とそれぞれのリスクを、ビジネス側が理解しやすい形で伝えることで、円滑な意思決定を促し、要件定義をスムーズに進めることができます。
発注側業務部門も、"システム開発"を理解する
ビジネス側は、システム開発には一定の時間がかかるという基本的な性質を理解することが重要です。「これくらいならすぐにできるだろう」といった誤った認識を持つと、予算や期間を見誤るだけでなく、お互いの不信感を招くことにもつながります。システム開発には、影響範囲や技術的リスクの調査、設計、実装、レビュー、テストといった多くのプロセスが含まれます。これらの内容を理解することで、現実的なスケジュールや予算を検討することができます。
また、開発側にもビジネス側の仕事を理解する姿勢が求められます。たとえば、業界や業務に関する知識、顧客ニーズ、組織の意思決定プロセスなどを把握することで、より適切で効果的なシステムを提案できるようになります。
最後に
システム開発、特に要件定義においては、ビジネス側と開発側が協力し、ビジネス価値の創出に向けて共に取り組むことが不可欠です。
そのためには、ビジネス側と開発側がそれぞれの責任や義務から生じる想いを深く理解し合うことが重要です。
この原理原則を理解し、実践することで、より良いシステム開発を実現し、プロジェクトの成功を確実なものにできるでしょう。
*1:システムを使って事業を行なう会社などの組織のこと。システムの使用者や顧客の意味ではない。
*2:システムやソフトウェア、ハードウェアを提供する企業や組織のこと。顧客の要件に基づいて製品やサービスをカスタマイズしたり、導入支援を行ったりすることもある。
*3:「何かを選ぶと別の何かを諦めざるを得ない、つまり「あちらを立てればこちらが立たず」という状況。
*4:責任と義務は似た意味を持つ言葉であるが、ここでは「品質」「期限」「費用」に対して、それぞれの立場で果たすべき役割として「責任」を用いる。「要件の品質に責任を持つ」「開発費用に責任を持つ」「リリース期限に責任を持つ」など。
*5:ここでは、「責任」を実現するためのつとめ、行動を示す。
*6:業務要件はビジネス側、システム要件はシステム側という役割分担もあり得る
*7:このような状況で開発側が責任を問われると、対応が難しくなる可能性があります。それを防ぐために、『原理原則［9］ 要件定義は発注者の責任である』という重要な指針が示されています。この原則に書かれている通り、要件定義はビジネス側の責任であり、開発側は支援する立場であることを、要件定義開始前に合意しておくと良いでしょう。
