秋のブログ週間2026 の11/11 真野さんの記事を公開する

source/_posts/2026/20261026a_秋のブログ週間2026.md

@@ -42,6 +42,6 @@ lede: "秋のブログ週間とは2020年から始まったブログリレーの
 | 3週目     | 🌰     |                                      |
 | {% thumb 20261109a %} 11/9 月  | 高嶋 ありさ | [エンジニアが『「なぜ」と聞かない質問術』を読んでみた](/articles/20261109a/) |
 | {% thumb 20261110a %} 11/10 火  | 井上 拓  | [シンギュラリティの記事を見るたび不安になったので、自分の思考を蒸留→AI化して、仕事がどう変わるか試してみた](/articles/20261110a/) |
-| 11/11 水  | 真野 隼記  | 調整中 |
+| {% thumb 20261111a %} 11/11 水  | 真野 隼記  | [お客様の前に立つフロント人材になるために、技術以外の最小構成](/articles/20261111a/) |
 
 いつもはコードが本文に書かれていることも多いフューチャー技術ブログですが、この連載はスマホ片手で読めるような記事成分を高めたいと思います。約2週間、どうぞお付き合いください。

source/_posts/2026/20261111a_お客様の前に立つフロント人材になるために、技術以外の最小構成.md

@@ -0,0 +1,135 @@
+---
+title: "お客様の前に立つフロント人材になるために、技術以外の最小構成"
+date: 2026/11/11 00:00:00
+postid: a
+tags:
+  - コンサルティング
+  - 会議
+  - 資料作成
+categories:
+  - Business
+series: "秋のブログ週間2026"
+thumbnail: /images/2026/20261111a/thumbnail.jpg
+author: 真野隼記
+lede: "お客様の前に立ってプロジェクトを自律的に進めるために、技術のほかに何が必要か、会議でのやり取りとプロジェクト全体視点でのやり取りの2つの層に分けて整理しました。"
+---
+<img src="/images/2026/20261111a/top.jpg" alt="" width="1920" height="1072">
+
+[秋のブログ週間2026](/articles/20261026a/) の記事です。
+
+## はじめに
+
+TIG（Technology Innovation Group）の真野です。
+
+フューチャーでは、お客様との会議に出て、プロジェクトを提案・推進することを「フロントに立つ」と呼ぶことがあります[^1]。お客様と直接やり取りすることはITコンサルタントの成長に不可欠ですし、マネジメント目線でも組織のスケールなどのため、できれば多くの人にフロントを任せたいと考えています。
+
+[^1]: 初めて聞いたときはReactとかのフロントエンドの話かな？と思いました。今でもややこしいなと思います。◯◯さんは「フロント対応」ができそう？みたいな言い方だと、お客様と上手く話せるタイプであるかを問われています。この時、フロントエンドは画面開発ができるかと表現されることが多いです。
+
+ところが、技術力が十分で丁寧に話すけれど、お客様の前に立たせるとうまくいかないことがあります。
+
+本記事では、お客様の前に立ってプロジェクトを自律的に進めるために、技術のほかに何が必要か、私見をまとめました。
+
+## 前提
+
+当たり前といえば当たり前ですが、お客様から見ると、プロジェクトの実作業でだれがどれだけ手を動かしたかは基本的に見えません。インターフェースは、会議資料とそれを説明する姿くらいなので、会議での印象≒その人の評価が実情でしょう。真面目なメンバーほど、時間のほとんどを実作業に使い、会議の準備は直前に済ませがちです。その結果、実力より過小評価されることもあり、もったいないと感じます。
+
+本記事では、こういった課題感に対して、信頼の積み上げ方について話します。
+
+## フロントに求められる力の層
+
+お客様の前に立つ人に求められる力は、人によって流派が異なりますが、私は3階層への分類派です。1層目は技術力というか実作業を遂行できる能力です。これは本記事ではすでに一定以上、身についている前提として扱います。
+
+<img class="bordered" src="/images/2026/20261111a/front-layers.png" alt="" width="1920" height="1008" loading="lazy">
+
+2層目は、担当領域のタスク粒度で正しく報告/相談/確認などができ、上長のマネジメント関与を減らし自律的に動けるレベルです。3層目はもう少し視座を上げ、プロジェクト全体視点でメタ的なプロセス定義（プロジェクト計画など）も考えられつつ推進できるように成長したレベルです。2層目だけだとたまにワンショットならともかく、プロジェクト期間のどこかでフォローが必要になる確率が上がるイメージです。
+
+それぞれの層で私が重視するスキルをまとめました。2層目から3層目の順に身につけていくイメージです。2層目のスキルは、会議の準備で使う順に並べています。
+
+<img class="bordered" src="/images/2026/20261111a/skill-tree.png" alt="" width="1920" height="1091" loading="lazy">
+
+これに沿って各スキルを説明します。
+
+## 2層目: 会議でのやり取り
+
+基本レベルである2層目は、会議の中でお客様と相談や報告をやり取りし、判断できる材料を出して合意を取る力です。まずはここからです。
+
+### コンテキストの目線合わせ
+
+コンテキスト整理は、目的、前提、これまでの経緯を整理して認識を合わせることを指すとします。わざわざ書かなくても？と思われがちですが、いきなり細部から話しはじめてしまい、「何の話だっけ？」となるパターンは想像より多いです。説明する相手は多忙なので、文脈の提供は丁寧過ぎるくらいに行い、相手の興味を引き出す必要があります。
+
+資料の導入パート以外でも、「これまでの資料から〇〇と理解していますが、今回もこの前提でよいですか？」と差分を確認する形にすると、認知負荷や対処時間を圧縮できるので必須スキルです。過去の議事録や資料はAIに読み取れるようにMarkdown化などしておき、背景はすぐ取得できるようにまとめておきましょう。
+
+### 論点化
+
+論点化は、作業の中から、お客様に相談すべきことを切り出すことを指すとします。「データカタログの表示項目、3案持ってきましたがどれを選びますか？」みたいなテーマから、選択肢を選ぶために必要な問いみたいな感じです。
+
+本人は今週の作業報告のつもりなのに、掘り下げると、お客様に相談しておかないとまずい話だと分かる場面がよくあります。個人的には、資料の最後に「何か気になる点があればコメントください」と書いてあると怪しいサインだなと思っています。
+
+自分では作業報告だと思っていても、案外、認識合わせすべきネタが見つかることは多いです。ざっくり4つくらいのパターンがあるかなとおもっています。
+
+<img class="bordered" src="/images/2026/20261111a/report-or-consult.png" alt="" width="1920" height="1509" loading="lazy">
+
+上記の観点で何かしら項目が出てきたとしたら、作業報告ではなくなるので、相手が理解しやすい形で判断材料を提示する必要が出てきます。逆に本当に報告にしかならないものであれば、会議で時間を取るほどのことなのか？という話にも繋がるので、さほど時間を掛けずさらっと流して相手の時間を奪わないようにすべきでしょう。
+
+### 翻訳
+
+技術的な意思決定をするためには、技術の評価をお客様の判断軸に翻訳し、推奨を添えて、お客様が決められる状態を作ることが必須です。これの難しいポイントは、技術的に正しく評価することと、合意形成に向けてそれをビジネス的に解釈可能な形に翻訳することの2つを、同時にこなす必要がある点です。
+
+<img class="bordered" src="/images/2026/20261111a/two-mountains.png" alt="" width="1920" height="999" loading="lazy">
+
+*要求工学知識体系（REBOK）などの界隈でツインピークスモデルと呼ばれるもの*
+
+これについては、要素を分解したガイドラインを作成中なので、お楽しみに。
+
+### ストーリー化
+
+コンテキスト整理して、論点化して、翻訳までできているのであれば、そのまま並べれば大体なんとかなります。とはいえ、どこかで突っかかるポイントもあると思うので、相手が理解しやすい流れに調整するとベターです。便宜的にストーリー化と呼びます。
+
+逆に、聞けば考えはあるものの、何を言いたいか分からない資料も、レビューでよく見かけます。例えば、ページの上に「AはBという進め方をしています」と1行だけ書いてあり、その下に構成図がドーンと貼ってある。報告なのか相談なのかも、どこを見ればよいのかも分かりません。
+
+だいたい、リード文に次の要素を追加すれば改善できますし、ストーリーもそれほどバリエーションはないです。
+
+1. **なんのために行うか**
+このページが共有、承認、相談のどれなのか。なぜ今日それが要るのか。例: 「来週から外部システムとの結合テストの準備に入るので、今週中にエラー時の再送ルールを決めておく必要があります」
+2. **何をやろうとしているか**
+そもそもの業務の目的と、前回どこまで合意していたか、全体の計画に対して今どこにいるか。たとえば「現場の二重入力をなくすための連携機能で、前回は夜間バッチ方式で進めることまで合意しました。全体計画に対しては予定どおりです」
+3. **何に困っているか**
+進める中でぶつかった制約や、A案とB案の間の迷い。困っていることがないなら、議題から外しましょう
+4. **どうしたか、どうしたいか**
+「B方式で設計しました」で終わらせず、「〇〇という弱みがありますが、B方式で進めてよいか確認させてください」のように、問いを作ることでもあります
+
+資料作成のスキルに組み込んでおき、ポン出しレベルから1～4が入るようにしておきましょう。資料全体の流れの型や、ページ単位の書き方は、以前「[資料作成のポイント（定例、課題解決用）](/articles/20220628a/)」にまとめたので、あわせて参考にしてください。
+
+## 3層目: プロジェクト全体視点でのやり取り
+
+3層目は、会議単発というよりもう少し視座を上げます。そもそも、どう進めるのが良いのか？などに踏み込めると、より高い次元の関係性にステップアップできると感じます。
+
+### 計画策定
+
+計画が無いと、常にベストエフォートで働くことになるか、実は彼我の戦力差からどうがんばってもゴールにたどり着けないことが後で分かるというリスクが生まれます。経験上、後々後悔するのは計画時の考慮漏れですね..。
+
+基本的にはゴールから逆算して引きます。タスクを並べると「10月は現状調査、11月は課題整理」とかですが、これはゴールではなくタスクであり、「11月末に、来期の予算申請に添付できるアーキテクチャ方針が合意されている」のように、成果として示せる状態から逆算します。範囲から外した項目も表から消さず、いつ扱うか、なぜ今期は扱わないかを添えておきます。不確実性が高く、ゴール自体が曖昧であれば、初期の計画の合意が、すなわちスコープ交渉となりえます。
+
+<img class="bordered" src="/images/2026/20261111a/plan-backcasting.png" alt="" width="1920" height="1187" loading="lazy">
+
+さらに、計画のクリティカルポイントやリスクとその対応案を語れるとベターです。例えば、「この計画の山場は、11月第2週のセキュリティ部門との合意です。長引くと全体が遅れるので、10月中にたたき台を当てる期間を取っています」などです。そうした、作戦というか勝ち筋を掴む考え方が、スケジュールに表現されていることが重要です。
+
+### 予実管理
+
+計画と実績のズレとは大体遅延です。遅延に対してどう対処して理想形に近づけつつ現実的に着地させるかが腕の見せ所です。仮に自分の作業は順調であっても、依存する別のチームに作業遅延が見えた場合、それにどうするのか？が求められます。利用予定のSaaSの契約が遅延して環境が使えないけど、リリース日は業務都合でズラしたくない。では、どうする？みたいな正解が無い問いへの乗りこなしを、みんな注目しています。
+
+### プロセス設計
+
+プロセス設計は、何をどの場で決めていくかという、進め方を決める力です。体制図や役割分担、会議設計などが該当します。何かスムーズに決まらない時、このあたりの設計まで見直せると強いです。
+
+## おわりに
+
+お客様の前に立つためのソフトスキルを、会議でのやり取りの2層目と、プロジェクト全体視点でのやり取りの3層目で整理しました。振り返ると、実作業として設計や検証をやり切ったうえで、その結果を、計画との関係、背景とのつながり、相談すべきことの切り出し、判断の軸へと組み立て直す。そして、目の前の担当者が社内でどう説明するのかを想像して、話の筋を通す。特別な才能が要るものではなく、問いかけや手順に分解すれば、身につけていけるものだと考えています。
+
+図の右上に点線で描いたように、担当者の向こうには、最終承認先や調整先になる上司や他部署がいます。プロジェクトの範囲を超えて、この人たちまで見据えてやり取りできるように動くなど、まだ上の世界はありますが、最低限ラインを超えて打線に立てば、自ずと磨かれる部分も多いと感じます。
+
+本記事の内容は、[ソフトスキルガイドライン](https://future-architect.github.io/arch-guidelines/documents/forSoftSkill/softskill_guidelines.html)とも重なります。ソフトスキルガイドラインは、アーキテクトが技術の専門性をビジネスの文脈で発揮するためのスキルを、顧客理解、計画力、コミュニケーションなど14の観点で体系化したものです。そこでアーキテクトに期待する振る舞いとして挙げている「前に出て、合意形成に向けた決定事項を作れる」を、お客様の前に立つ場面に絞って、具体的な振る舞いに落としたのが本記事という位置づけです。
+
+また、このガイドラインのうち合意形成の進め方を手順に分解した派生編も作っています。年内には公開したいと考えているので、公開したらまたお知らせします。
+
+これからフロントに立つ方や、メンバーの育成に悩んでいる方の参考になれば幸いです。最後まで読んでいただき、ありがとうございました！