非エンジニアの上司に技術を伝えるための読書

この記事は約 5 分で読めます。

「技術的に正しい」だけでは通らない

リファクタリングの提案が却下された。技術的負債の解消に工数を割きたいが、上司は「新機能の開発を優先してほしい」と言う。自分の説明が悪いのか、上司が技術を理解していないのか。

多くの場合、問題は両方にあります。しかし、上司の技術理解を変えることはできません。変えられるのは、自分の説明の仕方です。

エンジニアの説明が伝わらない理由

エンジニア同士の会話では、技術用語が共通言語として機能します。「このモジュールは凝集度が低い」と言えば、相手は問題の本質を理解します。

非エンジニアの上司に同じことを言っても伝わりません。「凝集度」という言葉を知らないからです。しかし、問題はそこではありません。上司が知りたいのは「凝集度が低いこと」ではなく、「それがビジネスにどう影響するか」です。

「このモジュールの凝集度が低いため、新機能の追加に通常の 3 倍の工数がかかっています。リファクタリングに 2 週間投資すれば、以後の機能追加が半分の工数で済みます」。これなら伝わります。

説明力を鍛える 3 つの読書ジャンル

1. ビジネス書を 1 冊読む

エンジニアがビジネス書を読む目的は、ビジネスの知識を得ることではありません。「ビジネスパーソンがどういう言葉で考えているか」を知ることです。

ROI、コスト削減、リスク軽減、市場投入速度。上司はこれらの言葉で意思決定をしています。技術的な提案を、これらの言葉に翻訳できれば、通る確率が上がります。

2. 技術書の「まえがき」を集中的に読む

優れた技術書の「まえがき」には、その技術がなぜ重要なのかがビジネス視点で書かれています。著者は、技術に詳しくない読者にも価値を伝えるために、まえがきで平易な言葉を使います。

エンジニアリングマネジメントの本は、技術とビジネスの橋渡しをする表現の宝庫です。

3. 文章術の本を 1 冊読む

技術文書の書き方ではなく、一般的な文章術の本です。「結論を先に述べる」「具体的な数字を使う」「相手の関心事から話を始める」。これらの原則は、上司への説明にそのまま使えます。

翻訳のフレームワーク

技術的な内容を非エンジニアに伝えるとき、以下のフレームワークで翻訳します。

1. 影響: これを放置すると何が起きるか (ビジネスへの影響)
2. 提案: 何をすべきか (具体的なアクション)
3. コスト: どれくらいの時間・費用がかかるか
4. リターン: 投資に対して何が得られるか

技術的な詳細は、聞かれたら答える程度で十分です。最初から技術の話をすると、上司は 30 秒で興味を失います。

読書で得た知識を説明に活かす実例

「データベースのインデックスを追加したい」という提案を考えます。

技術者向け: 「このクエリはフルテーブルスキャンになっていて、レコード数の増加に伴い O(n) で遅くなります。複合インデックスを追加すれば O(log n) に改善できます」

上司向け: 「お客様が商品を検索するときの待ち時間が、ユーザー数の増加に伴って長くなっています。今は 3 秒かかっていますが、半年後には 10 秒を超える見込みです。データベースの設定を 1 日で調整すれば、検索を 0.1 秒以下に短縮でき、この問題を恒久的に解消できます」

同じ内容を、相手の関心事に合わせて翻訳しているだけです。この翻訳力は、技術書とビジネス書の両方を読むことで鍛えられます。

関連記事

• なぜあの人は説明がうまいのか - 言語化力を鍛える読書
• 技術書の要約を書く技術 - 3 分で伝える力

まとめ

非エンジニアの上司に技術を伝えるには、技術用語をビジネスの言葉に翻訳する力が必要です。ビジネス書で上司の思考言語を学び、技術書のまえがきで翻訳の手本を見つけ、文章術の本で伝え方の原則を身につける。影響・提案・コスト・リターンのフレームワークで話せば、技術的な提案が通る確率は格段に上がります。