Author Archives: DeveloperTiatra

RFPの役割と「要件」の固定度が違う

日米のSIを比べるとき、技術や開発手法より先に見たほうがいいのが、調達の入り口にある文書の性格だ。日本ではRFPや要件定義書が「この通りに作ってほしい」という依頼書として機能しやすい。発注側は、社内の合意形成を経て要件を固め、予算枠を取り、調達の手続きに載せる。そのうえで、SIは提示された条件を満たす提案を作り、見積もりと体制、工程、品質計画を示して受注を目指す。ここでは要件は契約の中核であり、後工程での変更は例外として扱われやすい。

一方、米国ではRFPが「比較のための共通フォーマット」であると同時に、「まだ固まっていない現状を前提にした出発点」になりやすい。もちろん要件が明確なケースもあるが、変革案件やクラウド移行、データ活用のような領域では、最初から完全な仕様を確定できないことを前提にする場合が多い。そこでRFPは要求の一覧というより、現状の課題、制約条件、期待するビジネス成果、ガバナンス要件、意思決定プロセスなどが含まれ、SIには「一緒に解き方を設計する能力」が求められる。要件を固め切ってから発注するのではなく、固めるプロセス自体を契約とプロジェクトの中に組み込む感覚に近い。

この違いが、後々の揉めどころを左右する。日本型の前提で米国型の案件に入ると、要件が揺れるたびに“仕様追加”と捉えて関係が硬直しやすい。逆に米国型の前提で日本型の案件に入ると、要件を詰め切る前に走り出してしまい、後から「最初に合意した話と違う」と問題化しやすい。どちらが正しいかではなく、調達文書が担う役割が違うのだと理解しておくことが重要になる。

---

契約形態が生む行動原理の違い

契約形態は、現場の行動を驚くほど強く規定する。日本では固定価格に近い形での請負が根強く、納期と品質を守る責任がベンダー側に寄りやすい。結果としてSIは、見積もりの段階からスコープを厳密に定義し、リスクを織り込み、工程管理と品質保証を厚くして「失敗しない確度」を上げる方向へ力を注ぐ。ここで重要なのは、仕様変更が起きないように事前合意を徹底すること、起きた場合は合意プロセスを慎重に踏むことだ。プロジェクト管理は、仕様の安定と計画遵守に重心が置かれやすい。

米国では、時間と材料費に基づく契約や、段階契約、マイルストーン契約、場合によっては成果指標を絡めた契約など、複数の選択肢が一般的に使われる。特に不確実性が高い領域では、最初から固定価格で全体を縛るより、探索と実装を分け、価値が見えたところに投資を寄せる設計が好まれる。SI側も、変化を前提としたリスク管理に慣れており、変更を悪として封じ込めるより、変更を管理可能なイベントとして扱う。すると、現場は「要件を完璧に固める」より「短いサイクルで確かめ、正しい方向に修正する」ことに動機づけられやすい。

ただし、これは米国のほうが自由で楽だという話ではない。変化を許容する契約は、意思決定と説明責任のスピードを求める。優先順位をいつ誰が決め、何を捨て、何を足すのかを、曖昧なままにできない。逆に固定価格の契約は、合意形成に時間をかけやすい代わりに、合意の外側にある変更の扱いが難しくなる。契約形態は、プロジェクトの運営哲学そのものを決める装置だと言える。

---

チェンジオーダーの文化がプロジェクトを救う／壊す

日米の差が最も生々しく出るのが、チェンジオーダー、つまり変更管理の実務だ。日本の現場では、変更は避けたいものとして扱われやすい。発注側も、変更を出すことが「最初の詰めが甘かった」と見られることを恐れ、現場からの要望を抑え込むことがある。ベンダー側も、変更を受けると納期と品質の責任が増し、採算が崩れるため慎重になる。その結果、変更が水面下で処理され、帳尻合わせとして残業や品質リスクで吸収される、という歪みが起きやすい。

米国ではチェンジオーダーは、揉めごとの種というより、プロジェクトを健康に保つための仕組みとして運用されやすい。変更は起きるもの、起きたときに何が増え、何が減り、納期とコストとリスクがどう動くかを、手続きとして透明にする。合意の取り方が荒いという意味ではなく、むしろ合意の単位が細かく、判断の回数が多い。だからこそ、変更管理が回っているプロジェクトは強い。逆に言えば、チェンジオーダーの仕組みだけ導入しても、意思決定者が不在だったり、判断の責任が曖昧だったりすると、変更が積み上がって混乱が増えるだけになる。

日本で変更管理を機能させる鍵は、変更を“誰かの落ち度”の話にしないことだ。要件は現実とともに変わる。法規制、業務フロー、組織体制、競合環境、利用者の反応、セキュリティ要件など、変化の源泉はいくらでもある。問題は変化そのものではなく、変化の影響を見積もらず、合意せず、現場に押し付けることにある。変更を正面から扱えるようになると、プロジェクトはむしろ安定する。

---

品質保証と責任の分界線

契約とリスク配分は、品質保証の設計にも直結する。日本のSIは品質に強いと言われるが、その背景には「納めたものに対して責任を持つ」という発想がある。要件を満たし、想定外の例外にも耐え、運用で困らないように作り込む。テストも手厚く、レビュー文化も厚い。発注側もそれを期待し、受入の段取りを重視する。ここでは品質は、仕様遵守と安定稼働の担保として語られやすい。

米国の現場では、品質は重要だが、品質を保証する方法が少し違う形になりやすい。もちろんテストはする。ただし、すべてを事前に確定してから一気に受け入れるより、継続的に検証し、段階的に提供し、運用で計測しながら改善する発想が強い。品質の中心は「仕様に合っているか」だけでなく、「目的に対して機能しているか」「変化に追随できるか」「障害から回復できるか」「セキュリティ要求を満たし続けられるか」に広がる。受入条件も、納品物のチェックリストだけでなく、稼働後のSLAやSLO、監視とアラート、インシデント対応体制まで含めて設計されることがある。

責任の分界線の引き方も異なる。日本では、請負の責任が重いほど、ベンダーが“できるだけ全部を見る”方向に寄る。米国では、責任を明確に分ける代わりに、運用の計測や改善のプロセスを共同で回す方向に寄る。前者は安心感が強いが、見えない負担が積み上がりやすい。後者は合理的だが、顧客側の体制が弱いと回らない。どちらの設計が適切かは、求めるスピード、組織成熟度、規制要件、システムの重要度で変わる。

---

調達側の体制がSIを変える

契約やプロセスの違いは、発注側の組織構造の違いとも深く結びついている。日本企業では、調達、法務、情報システム、事業部門が段階的に関与し、合意形成が積み上がる構造になりやすい。合意形成が厚いこと自体は悪ではない。むしろ、説明責任と納得感を作るうえで強みになる。しかしその厚みが、意思決定のタイミングを遅らせたり、責任の所在を曖昧にしたりすると、変更管理が機能しにくくなる。現場は“誰に何を決めてもらうべきか”が見えないまま、走らざるを得なくなる。

米国企業では、プロダクトオーナーやビジネス側の責任者が、価値と優先順位の決定権を持ち、短いサイクルで判断する体制を組みやすい。法務や調達は強く関与するが、実行段階の意思決定は明確に委譲されるケースが多い。これが、変化を前提とした契約と相性が良い。逆に言えば、意思決定が委譲されないまま変化前提の契約だけ導入すると、判断が止まり、現場が空回りする。

日本で日米の差が強く感じられるのは、SI側だけの問題ではなく、発注側の体制設計が契約思想と連動していない場合が多いからだ。契約で変化を認めるなら、変化を判断する役割と権限を決める必要がある。固定価格で縛るなら、スコープを固めるための時間と人員を最初に投資する必要がある。どちらも中途半端だと、プロジェクトは苦しくなる。

---

日本で「契約起点の変革」を進める実務ポイント

ここまでの比較を踏まえると、日本のSIが次に取りうる現実的な進化は、契約と調達の設計からプロジェクト運営を改善していくことにある。アジャイルを導入する、クラウドへ移行する、内製化を支援する、といった取り組みは、契約と調達の前提が変わらなければ現場で摩擦を起こしやすい。手法の導入より前に、リスクをどう配り、変化をどう扱い、責任をどう分けるかを言語化するほうが効果が大きい。

例えば、不確実性が高い領域では、最初から全体を固定価格で縛り切らず、現状分析と設計を切り出し、段階的に契約するだけで、後半の手戻りが大きく減ることがある。逆に、要件が比較的安定している領域では、固定価格の強みを活かしつつ、変更管理のルールと受入条件を明確にし、現場が“暗黙の吸収”に追い込まれないようにするだけで、品質も生産性も上がる。運用を含む案件では、納品時点の受入だけでなく、稼働後の目標や計測、改善のサイクルまでを契約に織り込むと、SIの価値が「作る」から「良くし続ける」へ広がる。

日米SIの差は、現場の気合いや能力差ではなく、契約と調達が作る環境差として理解したほうが本質に近い。契約は現場の行動を決め、調達はプロジェクトの呼吸を決める。だからこそ、日本のSIが次のステージへ進むには、技術刷新と同じ熱量で、契約と調達の設計をアップデートする必要がある。仕様を守る強さを残しながら、変化を前提に価値を積み上げる強さを獲得する。そのための第一歩が、契約とリスク配分を“現場が回る形”に整えることなのだ。