発注者の意思決定には3つのタイプがある

　システム開発を外部に委託する場合、意思決定は発注者の重要な役割です。特に多くのシステム開発プロジェクトで採用されているウォータフォール型の開発モデルでは、上流工程の意思決定に基づいて後続工程の作業が行われるため、意思決定の精度がプロジェクトの成否や成果を左右します。

　しかし、上流工程の検討事項は、プログラムのように実行して正否を確認できません。そのため、システム開発には、さまざまな開発フレームワークや分析手法があり、IT導入の目的や発注者の業務内容に合わせて活用することで意思決定の確かさを確保します。

　たとえば、業務設計には、ユースケースやシナリオを用いてシステム化範囲を記述するUMLや、業務ごとにKPIを設けて業務全体の生産性向上を図るBSC（バランス・スコアカード）、待ち行列モデルを用いた業務プロセスの生産性評価と改善効果のシミュレーションなど、さまざまなアプローチがあります。

　しかし、システム開発を外部委託しているプロジェクトの多くでは、意思決定の精度に関わる作業計画の立案から作業実施、品質管理に至るまで、ITベンダーに委ねられています。したがって、上流工程におけるITベンダーの役割とは、必要な判断材料を示すことで発注者の意思決定を促すことにあると言えます。

　筆者自身、プロジェクトに参画する際は、プロジェクトの目的に適した作業計画を検討し、作業にあたっては、発注者と十分に協議することで、発注者が納得して意思決定できるように心がけています。しかし、さまざまプロジェクトの経験から、発注者には意思決定のやり方に違いがあり、適切な作業計画や役割分担と密接な係わりがあることを実感しています。

　たとえば、あるプロジェクトでは、発注者が率先して方針を決定し、私たちは発注者の仮説を検証して妥当性や実現性を評価することで意思決定が行われました。また別のプロジェクトでは、業務部門の関係者全員の承認が求められ、私たちが立案した方針について関係者と協議を重ねることで意思決定が行われました。

　このような発注者の意思決定に至るまでの作業プロセスや役割分担の違いに着目すると、発注者には意思決定において重視している根拠や判断材料に違いがあることがわかります。筆者の経験をもとに、発注者の意思決定にみられる特徴を分類すると、下図の3つのタイプがあります。

自ら決断するデシジョン重視タイプ

　デシジョン重視タイプは、自ら率先して意思決定を行うタイプです。業務やITに関する知識があり、IT導入の目的や方策について明確なビジョンを持ち、具体的な方策を示してトップダウンで作業指示を行います。このタイプは、日常的に社内の重要な意思決定を行っている役員や事業責任者に多くみられます。

　デシジョン重視タイプの発注者は、自らの考えをもとに決断するため、他の意思決定タイプと比べると合意形成に必要なITベンダーの労力も少なくなります。また、方針立案やステークホルダーとの合意形成を主体的に行う発注者が多く、外部委託する作業範囲の削減につながるため、外注コスト（主に工数）や作業期間を圧縮できます。

　なお、デシジョン重視タイプは、自らの信念や高度な知識にもとづいて意思決定を行うため、慣習や常識にとらわれず、思い切った判断ができるのも特徴です。そのため、前例のない先進的な取り組みや業務改革を牽引する推進力があります。

　ただし、発注者の意図を正確に把握するには、同程度の知識を持ち、ビジョンを正しく理解している必要があるため、円滑にコミュニケーションできる相手を選ぶ傾向があります。


　また、このデシジョン重視タイプは、役員や事業責任者など、会社内の地位が高い場合が多いため、指示を受ける相手が萎縮して、発注者の判断や指示を無批判に受け入れてしまう傾向があります。

　そのため、発注者の独断専行が過ぎれば、実現性や妥当性の検証が不十分なまま意思決定が行われ、後工程に問題を発生させるリスクがあります。

根拠を重視するロジック重視タイプ

　ロジック重視タイプは、客観的な根拠を重視して意思決定を行うタイプです。このタイプは上司から根拠の説明を求められる機会が多い、中間管理職に多くみられます。発注者の実務責任者は、部門長やシステム責任者が担当する場合が多いため、個人的にはロジック重視タイプの発注者が最も多い印象があります。

　ロジック重視タイプの発注者は、客観的な判断材料をもとに自らの思考力にもとづいて判断します。事実関係やデータなどの根拠をもとに論理的に思考するため、先入観や慣習にとらわれことなく合理的に判断します。関係者に対しては、意思決定の経緯を順序立てて明解に説明できるため、合意形成をスムーズに進めることができます。

　合理的に判断するロジック重視タイプは、議論の勘所を想定しやすいため、提案が得意なITベンダーには合意形成が図りやすい発注者です。

　ただし、議論の目的や前提条件が曖昧だったり、発注者の問いに適切な受け答えができなかったりすると議論が発散する傾向があります。つまり、ロジック重視タイプの発注者は、同じ論理的な思考力を持つ相手でなければ議論がかみ合わず、効率良く意思決定を進めることができません。

　また、このタイプは、根拠を重視するあまり、裏付けが難しい判断を苦手とする傾向があります。たとえば、先進的な取り組みでは、根拠となるデータや事例が十分に得られなかったり、仮説を立証するために新たなデータを収集する必要が生じて時間がかかったりします。


　先進的な技術活用や独創的な取り組みにおいては、根拠が十分に得られなくても発注者自身の決断で意思決定することが必要な場面があります。過度に根拠にこだわり過ぎれば、優れたアイデアの実現や先進的な取り組みを妨げるリスクがあります。

合議を大切にするコンセンサス重視タイプ

　コンセンサス重視タイプは、ステークホルダーとの合議を重視して意思決定するタイプです。このタイプは、稟議書の決済印欄が沢山並んだ、企業風土として合議制を重視する発注者に多くみられます。また、発注担当者が業務部門の調整役として参画している場合は、担当者の一存で判断できないため、合議制によって意思決定が行われる傾向があります。

　コンセンサス重視タイプの発注者は、主体的に意思決定を行うことが少なく、関係者を集めた会議で同意を得ることで意思決定を行います。関係者の意見を尊重し、疑問点や懸念事項をしっかり話し合うため、関係者全員と強固なコンセンサスを形成できます。そのため、関係者との行き違いが少なく、後続工程を円滑に進めることが可能です。

　ただし、コンセンサス重視タイプは、関係者全員の意見を尊重するあまり、総花的な結論を導き出しやすい傾向があります。コンセンサスを図る関係者は、同じ会社の職員と言っても部署が異なれば、業務に対する価値観や課題の優先順位も異なります。そのため、関係者の意見を際限なく取り入れれば、開発スコープは拡大して開発コストの増大を招くかもしれません。


　また、コンセンサス重視タイプは、関係者全員と合意形成に慎重になるあまり、意思決定に要する打ち合わせ回数が多くなる傾向があります。打ち合わせ回数の増加は、ITベンダーの作業工数や作業期間の増加につながるため、外部委託コストの肥大化を招くリスクがあります。

　上流工程で細部まで検討を行き渡らせておくことは、システム開発における不確実性を減らす上でも決して無駄ではありません。しかし、「船頭多くして船山に上る」ということわざがあるように、関係者全員の意向を過度に尊重すれば、プロジェクト本来の目的から誤った方向に進むことになります。

【次ページ】3つのタイプを理解すると何がよいのか