夜9時、ベンダーからの進捗報告で「アーキ検討中、次回までに方向性共有します」と3週連続で同じフレーズ。社内からは「連携方式が未確定なら調達は回せない」と指摘され、セキュリティ部門は「レビュー対象がない」と会議をキャンセル。あなたは板挟みのまま、稟議の根拠も薄く、説明資料は毎回作り直しです。翌週、ベンダーが急に「やはりA案は難しくB案で」と方針転換。要件定義は終わっているはずなのに、手戻りだけが増えていきます。
本記事では、業務側が「技術判断ガバナンス」を握り、アーキテクチャ判断の遅延と手戻りを止めるための原理原則と、明日から使える会議術・話法・テンプレートを提示します。
Contents
ベンダー任せで技術判断が遅れ、手戻り続出の現場
プロジェクト盤に「アーキ未確定」の赤札が並び、議事録には「検討継続」「次回持ち越し」が積み上がります。具体的には、データ連携方式（バッチ/リアルタイム）、ID連携（SAML/OIDC）、復旧方式（RTO・RPO）など、システムの骨格を決める判断が先送りされがちです。業務側は「技術のことはベンダーに」と遠慮し、ベンダーは「要件次第」と受け身。結果、誰も「いつ・何を・どの基準で」決めるのかを握っていません。
この状態が続くとどう悪化するか。まず、非機能要求（速度・可用性・セキュリティなど）のすり合わせが後ろ倒しとなり、結合テスト段階で「想定性能が出ない」「監査に通らない」が発覚します。次に、追加対策の設計・調達・設定で2〜8週間の手戻りが発生し、ベンダーからは「別途費用」の見積が出ます。さらに、社内稟議は「検討中」のまま止まり、全体スケジュールは数カ月単位で遅延。最後は、現場の信頼が落ち、「やはり情シスと相談してからにして」と承認ラインが増え、会議が増える悪循環に陥ります。現場の合言葉は「決まらないから進めない」、しかし実態は「決める仕組みがない」だけです。
ベンダー任せを生む『技術判断ガバナンス』不在の背景
技術判断ガバナンスとは、技術的な意思決定を「誰が・いつまでに・どの基準で・どの手続きを通して」行うかを定め、運用する仕組みのことです。これが不在になる背景は3つあります。
- 権限の空白：業務側は「技術は設計事項」と距離を置き、ベンダーは「顧客のリスク許容度が不明」と踏み込めません。結果、責任者不在の判断が宙づりになります。
- 期限と基準の不在：判断に「締切」と「評価基準（非機能の優先度・コスト許容など）」が付いていないため、議論が回遊魚化します。先送りは最安の選択に見えますが、後戻りコストは指数的に増えます。
- 社内政治の摩擦：セキュリティ、ネットワーク、データ管理など承認主体が縦割りで、各所の「暗黙ルール」をベンダーが読めません。業務側が調整を引き受けないと、ベンダーは最も無難で時間のかかる選択に流れます。
これらはお金・時間・社内政治の三位一体です。お金は後出しの追加費用で膨らみ、時間は遅延、社内政治は承認ラインの増殖でさらに遅れます。解決には、業務側が「判断の土俵」を先に設置し、ベンダーをその土俵に上げることが不可欠です。「どう作るか」は任せても、「どう決めるか」は任せない、という切り分けが鍵です。
『技術判断ガバナンス』で主導権を取り戻す原理原則
原理は2つだけです。
1) 判断は「期限と基準」で管理する
技術判断をタスク化し、締切と評価基準を決め、見える化します。私はこれを「技術判断バックログ」と呼びます。基準は難しくありません。非機能の優先順位（例：可用性＞性能＞運用性）、コスト上限、社内規制（持ち出し不可データ等）を1枚にまとめます。期限と基準があるだけで、議論は「好み」から「条件に合う案」へ移ります。お金の観点では、早い判断で調達・環境準備が前倒しでき、待機コストが削減されます。社内政治では、承認者を事前に特定でき、根回しが効きます。
2) 判断は「選択肢とトレードオフ」を記録する
結論だけでなく、検討した選択肢と捨てた理由を残します。これは「技術判断記録（ADR: Architecture Decision Record）」と呼ばれる実務です。後で方針変更が必要になっても、当時の前提と判断基準が残っていれば、説明と再判断が速い。ベンダー変更や担当交代があっても、判断の継続性が守られます。時間の観点では再議論を短縮し、お金の観点では無駄な再検証を避けられます。社内政治では、稟議の根拠資料として強力です。
この2つを支える運用として、毎週30〜60分の「技術判断ボード（審議会）」を定例化し、バックログから上位を順に決めていきます。役割は「議長＝業務側PM」「提案者＝ベンダー」「承認者＝関係部門代表」。小さくても、回り始めればプロジェクトは前に進みます。
明日から使える！技術判断を主導する会議術と話法
まずは型を用意します。以下は最低限のセットです。
技術判断バックログ（管理表）
| No | 判断テーマ | 締切 | 提案者 | 承認者 | 判断基準（例） | 選択肢 | 状態 |
|---|---|---|---|---|---|---|---|
| 01 | データ連携方式 | 4/12 | ベンダーA | セキュリティ部長 | 可用性99.9%、RPO=0、月額≤300万円 | バッチ/API | 提案中 |
ADR（技術判断記録）テンプレ
- タイトル：データ連携方式の選定（2025-04-12）
- 背景：販売ピーク時に在庫差異が致命。RPO=0、RTO=15分が必要。
- 選択肢：A.バッチ（S3+ETL）／B.API（イベント駆動）
- 判断基準：可用性、整合性、運用負荷、コスト（月額）、導入期間
- 決定：B(API)。理由：整合性とRPO=0を満たす。コスト+15%は許容範囲。
- 影響：APIゲートウェイ導入、監視強化、開発1.5人月追加
- フォローアップ：負荷試験を4/25までに実施。費用見積の再確認。
技術判断ボード（週次）アジェンダ
1) 本日の決裁対象（上位3件）確認
2) 提案1枚（選択肢比較）×各10分
3) 承認・条件付き承認・差戻しの決定
4) 新規リスク・社内調整点の洗い出し
5) 議事・ADRのその場確定
提案1枚のフォーマット（必須要素）
| 件名 | XXX | ||
| 背景（数行） | XXXXXXXXX | ||
| 選択肢A/B/C | A案:XXXX | B案:XXXX | C案:XXXX |
| 評価表（基準×◎○△） | ×/◎/〇/△ | ×/◎/〇/△ | ×/◎/〇/△ |
| 概算コストと期間 | XXX円 XXか月 | XXX円 XXか月 | XXX円 XXか月 |
| リスクと前提 | XXX | XXX | XXX |
| 推奨案 | XXXXX(評価結果を記入） | ||
依頼メール文例
件名：[技術判断] データ連携方式 提案1枚の提出依頼（4/10締切）
本文：4/12の技術判断ボードで決裁します。評価基準は「可用性99.9%」「RPO=0」「月額≤300万円」です。A/Bの比較1枚と根拠データ（URL可）をお願いします。不足情報は本日中に列挙し、担当と期日を明記ください。
これらを準備しておくにより可能になる会話
これらを準備しておくことで、具体的には以下のような会話が可能になります。
「それは設計で後ほど」は受けません。本件はバックログNo.01、締切は今週金曜、基準は3点（可用性/整合性/費用）です。選択肢と根拠のある提案に絞りましょう。
「前提が不明」は了解です。不足前提を今ここで列挙し、誰がいつ埋めるか決めます。埋まらない場合は仮置きで判断し、ADRに明記します。
あの失敗はもうしない！技術判断ガバナンスの適用イメージ例
事例：EC新規事業で基幹ERPとD2Cサイトの在庫連携。ベンダーは「まずは動かす」で夜間バッチ、後でリアルタイム化の想定。結合テストで在庫差異が顕在化し、マーケの施策（タイムセール）が打てず、6週間の設計やり直しに。コストは+1,200万円、信頼は毀損。
この案件に、前章の型を適用します。
- バックログに登録
No.01「在庫連携方式」締切：2週後、承認者：セキュリティ/基幹/ECの各責任者。基準は「RPO=0」「RTO=15分」「ピーク500TPS」「月額≤300万円」。 - 提案1枚（ベンダー提出）
A. 夜間バッチ（S3+ETL）：コスト○、整合性△、導入○
B. APIイベント（在庫更新通知）：コスト△（+15%）、整合性◎、導入△（+2週） - 技術判断ボードでの決裁とADR
決定：Bを採用。条件付き承認として「3日間の小規模POCでTPSとレイテンシを実測、問題なければ正式決裁」。ADRに前提とトレードオフを記録。 - 2週間後の結果
POCで目標達成。調達・監視要件を同時に通し、セキュリティレビューはADR添付で一発合意。連携に関わる後工程の待機が消え、全体で4週間の前倒し。追加費用は+300万円に抑制、マーケ施策は計画通りに開始。
適用前後のイメージ
| 観点 | Before | After |
|---|---|---|
| 判断方法 | ベンダーの口頭合意、先送り | バックログ管理＋週次ボードで期限決裁 |
| 根拠 | なし、担当者の経験則 | ADRで基準・選択肢・理由を記録 |
| 期間 | 6週間手戻り | 2週間で決定＋3日POC |
| コスト | +1,200万円 | +300万円 |
| 社内調整 | 各部門バラバラ | 承認者を事前指定し一度で合意 |
このように、判断の「土俵（期限と基準）」と「記録（ADR）」を用意するだけで、業務側が主導しても十分に回ります。技術の細部は任せつつ、決め方は握る。これがベンダー任せ卒業の最短ルートです。
まとめ
- 技術判断の遅延は「決める仕組みの不在」が原因です。業務側が期限と基準を用意し、週次で決裁するだけで手戻りは激減します。
- 原理は2つ。「技術判断バックログ」で期限と基準を見える化し、「ADR」で選択肢とトレードオフを残すことです。
- 具体的な型（バックログ表、提案1枚、ボードのアジェンダ、話法）があれば、社内政治・時間・お金の三つ巴を一度に捌けます。
明日1つだけ試すなら、「技術判断ボード」を30分で立ち上げ、上位3件の判断に締切と基準を付けてバックログに載せてください。これでプロジェクトは動き始めます。
参考リンク
– The Open Group: TOGAF（エンタープライズアーキテクチャのフレームワーク） https://www.opengroup.org/togaf
– ISO/IEC/IEEE 42010: Systems and software engineering — Architecture description https://www.iso.org/standard/50508.html
– AWS Well-Architected Framework（設計原則の整理に有用） https://aws.amazon.com/architecture/well-architected/
コメント