一番手強い相手は、技術を知らない人ではない。
半端に齧っている人だ。
本部長はシステム部長を兼任していて、技術をある程度理解している。「わかっている」と思っているから、こちらの説明に反論してくる。完全に知らない人より、ずっと難しい。
でも逆に言うと、理屈を通せば動く。お金も出してくれる。ベンダーからの教育費、AIツールの契約、Claude Codeの早期導入——システム部には投資してくれてきた。
「どう伝えるか」を考え続けてきた3年間の話を書く。
技術の話をしても伝わらない、は半分正しい
「コードが汚い」「テストカバレッジが低い」——こういう言葉が経営層に届かないのはわかってた。
ただ、本部長の場合は少し違う。技術の言葉で話すと「それは知ってる」という顔をしてくる。で、独自の解釈を加えてくる。噛み合わないのは言語の違いというより、「自分はわかってる」という前提がお互いにある状態でのすれ違いだ。
そこからやり方を変えた。技術の話をするなら、必ず数字か事業への影響とセットにする。「こういう問題がある」ではなく「この問題を放置すると、こういうリスクがある。直すとこれだけ変わる」という構造で話す。
内製化500万円削減の伝え方
ベンダー依存から内製化を進めた結果、外部委託費が年間500万円以上削減できた。この数字を本部長に報告したとき、技術の話は一切しなかった。
「NestJSでAPIを内製化した」ではなく「外部委託費を年間500万円削減。機能追加のリードタイムも3週間から3日になった。今後は自社でコントロールできる」。
What（何が変わったか）、How much（いくら変わったか）、So what（今後どうなるか）。この3点セットで話すと、意思決定者が動きやすくなる。
本部長は数字に反応する人間だ。感覚で話しても動かないが、根拠があれば納得する。
社長に直接呼ばれた日
ある日、グループ会社の社長から直接呼び出された。
グループ全体のITをまとめられたら、という話だった。今のチームはグループの一社を担っているが、グループ全体に横展開できる体制を作れないか、という構想だ。
その場ではまだ具体的な動きにはなっていない。次のステップはシステム開発の事業化、という話がある。
ただ、あの呼び出しは自分にとって意味があった。「技術と経営の間に立てる人間として認識されている」ということが、はっきりした瞬間だったから。
3年間、翻訳係をやり続けてきた結果が、ああいう形で出てきたのかもしれないと思っている。
伝わらないときの3つの軸
実際に使っている整理の仕方を書いておく。
数字で語る
「開発速度が上がった」は伝わらない。「リリースサイクルが月1回から週1回になった」なら伝わる。定量化できないものも、近似値を出す。精度より「オーダーがわかること」の方が経営判断には使える。
リスクで語る
「今はたまたま動いているが、放置するとこうなる」が刺さる。規制産業なら行政指導のリスク、スタートアップなら属人化による退職リスク。最悪のシナリオを具体的に描くことで、予防投資の価値が伝わる。
ビジョンで語る
コストとリスクだけだと守りの議論になる。「この基盤を整えると、来年この機能を外部なしで開発できる」という攻めの文脈も必要だ。
資料は「5分で決めてもらえるか」が基準
経営層向けの資料は、What・Why・いくら・いつまでが1枚で見えること。詳細は別添にする。
「この資料を見た人が5分で意思決定できるか」を毎回自分に問う。エンジニアとして作りたい資料と、意思決定者が必要な資料は全然違う。
翻訳できることが、今の自分の場所になった
技術を経営言語に変える作業は、最初は「仕方なくやっていること」だった。
今は、これが自分のポジションの核だと思っている。技術だけわかる人はいる。経営だけわかる人もいる。両方の言葉を話せる人間が間にいると、チームが動く速度が変わる。
孤独な役割だけど、必要とされている。それは確かだ。
関連記事: