「ドキュメントを作る人」から「設計できる人」へ──上流人材の思考法

上流工程で求められる“設計思考”とは何か？

上流工程では、見栄えの良いドキュメントを作ることが目的ではありません。
求められるのは、情報を整理し、関係者の意図を構造的に翻訳できる力です。

多くのプロジェクトで見られるのは、テンプレートを埋めることに終始し、「なぜこの構造なのか」「誰の意図を反映しているのか」が語られないまま進む現場。
そうしたドキュメントは、どれほど整っていても“動かない設計”に終わります。

本記事では、筆者の経験をもとに「ドキュメント職人」から一歩抜け出し、設計できる上流人材に変わるための思考法と実践のコツを整理します。

「ドキュメント職人」が陥りがちな3つの罠

丁寧に文書を作っても、成果につながらない。
その背景には、次のような“形式依存の罠”があります。

罠	内容	よくある影響
① フォーマット信仰	既存テンプレートをそのまま使い、目的を考えない	書類は整っていても議論が進まない
② 情報過多のドキュメント	“抜け漏れ”を恐れて全て書く	本質が埋もれ、読み手が迷子になる
③ 記述優先・構造欠如	テキストで説明しすぎ、構造を描かない	フローや依存関係の理解に時間がかかる

これらの罠に共通するのは、「正しさ」に囚われて「構造」を見失っていることです。
要件定義書は“事実”ではなく、“意図の設計図”である──この視点が欠けると、
上流工程の議論は流れ始めません。

真の上流人材に求められる“構造化”と“意図の翻訳力”

上流工程で求められるのは、文書の巧拙ではなく、情報を構造的に整理し、異なる立場の人々の言葉を相互に“翻訳”できる力です。
この二つが備わることで、プロジェクトの軸が初めて通ります。

構造化：情報を「整理」ではなく「設計」する

構造化とは、情報を要素と関係性に分解し、どの粒度で意思決定すべきかを明確にする思考法です。
言い換えると「整理」ではなく「設計」です。

たとえば筆者が関わった自治体システムの案件で、
現場担当者から「申請処理をもっと早くしたい」という要望が出たことがありました。
当初はシステム側のレスポンス改善（画面表示速度やサーバー負荷）を想定していましたが、ヒアリングを重ねるうちに、根本原因はまったく別の場所にあることが分かりました。

質問を投げかけながら、要望をこう分解していきました。

ステップ	質問	得られた回答	そこから見えた構造
① 目的確認	「どの処理を早くしたいですか？」	「申請が承認されるまで時間がかかる」	実は“画面”ではなく“承認経路”がボトルネック
② 主体の特定	「その承認は誰が行っていますか？」	「3段階の決裁が必要で、課長が出張中だと止まる」	ヒト起因の待機時間
③ 制約確認	「承認を並列化したり代理承認は可能ですか？」	「制度的には可能」	改善余地あり

こうして初めて、「遅い」の本質がシステム性能ではなく、業務承認プロセスそのものの滞りであることが明確になったのです。
結果、改善施策は「承認権限の委譲＋自動リマインド通知」に変わり、処理時間は平均3日から1日に短縮されました。

意図の翻訳力：異なる文脈をつなぐ橋を設計する

上流工程で議論が噛み合わない最大の理由は、関係者が同じ言葉を使っていても、意味していることが違うからです。

経営層はROI（投資対効果）で語り、業務部門は現場の手間で語り、エンジニアはAPIやテーブル構造で語る。
全員が「要件」「改善」「コスト」という言葉を使っているのに、頭の中で思い浮かべているものはまったく別物です。

筆者が関わったある基幹システム刷新プロジェクトでも、“意図の翻訳”ができていなかったことで要件定義が何度も空転しました。

ケース：業務部門の「CSV出力したい」要望

ある業務担当者が「データをCSVで出したい」と言いました。
エンジニアは「CSV出力機能を作る」というメモを取り、すぐ仕様化。
しかし、いざ実装してみると誰もその機能を使わない。

確認すると、担当者が本当にやりたかったのはこうでした。

「毎月の実績を上司に報告するために、数字を見やすく整形したい」

つまり、欲しかったのはCSVではなく「報告レポートの体裁」。
データをエクスポートする機能そのものより、“見せ方”を自分で調整できる柔軟性を求めていたのです。

翻訳のプロセス：質問で“意図”を掘り出す

筆者は次のように会話を進めました。

ステップ	質問	意図	得られた気づき
① 背景の確認	「CSVにしたいのはなぜですか？」	機能ではなく目的を聞く	月次報告資料の作成が目的
② 使う場面を想定	「どのタイミングで誰に共有していますか？」	利用文脈の特定	毎月初めに上司へメール送付
③ 不満点を特定	「今の運用で何が一番面倒ですか？」	改善すべき本質を掘る	グラフや書式を毎回Excelで整える手間

このやりとりから導いた要件は、「データ出力」ではなく「定型レポート出力＋レイアウト設定機能」。
仕様を見直すと、利用率は8倍に増え、現場の満足度も大きく上がりました。

翻訳力とは「言葉を換える力」ではなく「目的を再構成する力」

ここで重要なのは、「CSV」を「レポート出力」に言い換えたことではありません。
要望の“言葉”ではなく、“背景の意図”を設計の単位に変換したことです。

意図の翻訳力とは、表面上の要件を一度分解し、関係者全員の目的が交わる構造に再構成する力です。
翻訳とは、言葉を置き換えることではなく、異なる文脈を同じ構造にマッピングする行為なのです。

上流人材はドキュメントを書くとき、「この項目は誰の意図を反映しているか」「どの層の目的に属するか」を必ず意識しています。
その意識があるだけで、レビューの議論が“言葉の解釈”から“目的の整合性”へと変わります。

設計できる人が実践している3つの思考法

「設計できる人」は、会議やレビューでの立ち振る舞いが根本的に違います。単にドキュメントを書くのではなく、議論を設計しながら意思決定の質を上げています。以下の3つの思考法は、現場でそのまま使える実践型のフレームです。

1.「前提」を言語化して共有する

要件定義の初期フェーズで多くの齟齬が起こるのは、「当たり前」と思っている前提が人によって違うからです。
筆者が関わったある企業内システムでは、「請求書の自動発行」という要件をめぐり、開発側は“請求データをPDF化してメール送信”を想定していましたが、経理部門は“紙の押印を省略せず、ワークフロー承認後に発行”を前提にしていました。

このズレに気づいたのは、筆者が「“自動発行”とはどの時点を指しますか？」と質問したときです。たった一問で、仕様の焦点が「システム機能」から「運用ルールの見直し」へと変わりました。
前提を言語化するというのは、相手の頭の中にある「見えない制約」を引きずり出し、合意の土台を作る行為です。設計できる人は必ず“定義会話”から始めます。

2.「意図」を図で示す

文章で説明しても理解されにくいものは、構造で示す方が早い。
たとえば業務フローの見直しミーティングで、口頭で「このプロセスを並列化できます」と言っても、関係者はそれぞれ違う並列イメージを思い描きます。筆者は、ホワイトボードに現行フローをその場で描き、「ここで承認待ちが発生し、平均2.4日ロスしています」と数値を添えて示しました。

すると、誰もが「ボトルネックはここだ」と即座に理解しました。その後はMiro上で新旧フローを並べ、並列化による処理短縮効果を視覚化。合意までの時間は、従来の1/3に短縮されました。

設計できる人は、言葉で説明するよりも、図で“考えさせる場”を設計するのです。

3.「問い」を設計に埋め込む

良い設計は、読む人に考えを促す“問い”を含んでいます。
筆者はレビュー用のドキュメントに「この仕様変更は他システムに影響しますか？」「想定外入力が発生した場合、誰が対応しますか？」などの問いをコメントとして残します。
これは単なるチェックリストではなく、次のアクションを引き出す“トリガー”です。こうした問いが散りばめられた設計書は、読むたびに新しい視点を生み出します。

つまり、設計とは完成物ではなく、チームの思考を前進させる「仕掛け」なのです。設計できる人は、ドキュメントを“答えの一覧”ではなく、“問いのプラットフォーム”に変えます。

この3つの思考法は、どれも特別な才能ではなく訓練で身につけられるものです。前提を明確にし、意図を図に落とし、問いを設計に埋め込む──この3ステップを日常業務に組み込むだけで、チーム全体が“設計脳”に変わっていきます。

チーム全体を“設計脳”に変えるリーダーシップ

設計思考をチームに根づかせるリーダーは、メンバーに“考え方”を共有する時間を惜しみません。タスクの指示ではなく、「なぜそう設計するのか」「どの構造を優先すべきか」という判断のプロセスを一緒に言語化していきます。

筆者が以前担当したプロジェクトでは、設計書の品質にばらつきがありました。あるメンバーは業務フロー中心、別のメンバーは機能単位で詳細化しており、同じ要件でも粒度が揃わない。これではレビューやテスト設計で混乱します。そこで筆者は、チーム全体に「設計レビューの型」を導入しました。

1.レビューの目的を「正誤」から「意図理解」に変える

毎週のレビューで、単に不備を指摘するのではなく、「なぜこの構造にしたのか」を必ず本人に説明してもらいます。
最初のうちは「こう書くのが正しいと思ったから」といった答えが多かったのですが、数回繰り返すうちに「このプロセスを先に出す方が例外処理を減らせる」といった設計意図の説明が出始めました。

意図を説明する習慣がつくと、チーム全体が自然と“構造で語る”文化に変わります。

2.「図で議論する」文化を定着させる

言葉だけの議論は、想定がずれても気づきにくい。
そこで、打ち合わせでは必ずMiroやホワイトボードを開き、議論の内容をその場で図にします。
メンバーが説明するときに「ちょっと描いてみよう」と促すだけで、話の抽象度が下がり、議論の精度が上がります。
会議後にはその図を共有フォルダに残し、「どの構造を採用したか」を履歴として残す。

結果、仕様変更の経緯が明確になり、他チームとの認識齟齬が激減しました。

3.成功事例を「テンプレート」化して再利用する

一度良い設計ができたら、それを個人の成果で終わらせない。

設計ドキュメントをテンプレート化し、他メンバーが参照できるようにします。筆者のチームでは、ユースケース図・状態遷移図・エラーフロー図などを「プロジェクト共通フォルダ」に保存し、次回以降はその構成をベースに再利用。
結果、レビュー時間が約40％短縮されました。

重要なのは「テンプレートを作る」ことではなく、良い設計の意図をチームの思考資産として残すことです。

4.会話のレベルを「操作」から「設計」に引き上げる

リーダーが“設計脳”を育てたいなら、普段の会話のレベルを変えることが最も効果的です。
「この画面どうしますか？」と聞かれたら、「この画面は誰がどんな判断をするために必要？」と聞き返す。
質問の単位を操作から構造に変えるだけで、メンバーの思考の焦点が変わります。これは日々の雑談や相談の中でもできます。

リーダーの問い方が変われば、チームの考え方も自然と変わります。

このような積み重ねが、「チェックリストで動くチーム」から「意図で設計するチーム」への転換を生みます。設計書を残すことよりも、設計思考を共通言語にすることこそが、上流リーダーの本質的な役割です。