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

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

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

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

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

先に結論を書くと、やることは「技術用語をビジネスの言葉に翻訳する」の一点です。影響・提案・コスト・リターンの順に並べ替えるだけでも通り方は変わります。そのための語彙をどこから仕入れるか、という話をこれからします。

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

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

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

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

ただし、この形をそのまま使うときの前提が 1 つあります。数字は自分が測ったものでなければなりません。この記事に出てくる 3 倍・2 週間・半分は文型を示すための仮の値です。工数の実績を残していないなら、まず直近の数件の作業時間を記録するところから始めてください。根拠を聞かれて答えられない数字を一度出すと、次の提案から数字ごと疑われます。

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

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

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

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

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

技術書の「まえがき」には、その技術がなぜ必要になったのかが、本編より平易な言葉で書かれていることが多くあります。著者はそこで、まだその技術を知らない読者に価値を伝えようとしているからです。本編の解説文よりも、まえがきの言い回しのほうが上司への説明に流用しやすいのです。

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

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

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

翻訳のフレームワーク

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

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

技術的な詳細は、聞かれたら答える程度で十分です。最初から技術の話を始めると、判断に必要な情報が出てくる前に相手の集中が切れます。

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

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

技術者向け: 「このクエリはフルテーブルスキャンになっていて、レコード数の増加に伴い O(n) で遅くなります。複合インデックスを追加すれば探索側は改善しますが、更新のたびに索引の同期コストが乗るので、書き込みの多いテーブルでは効果と代償を測ってから決めます」

上司向け: 「お客様が商品を検索するときの待ち時間が、データの増加に伴って長くなっています。今の実測は 3 秒で、この増え方が続けば来期には体感で止まって見える水準に達します。検索用の索引を作る作業に 1 日いただければ、いま計測できている範囲では 1 秒未満まで戻せます。データがさらに増えたときは再点検が必要です」

同じ内容を、相手の関心事に合わせて翻訳しているだけです。技術者向けの説明にある計算量の話が消えたわけではなく、待ち時間と作業日数という形に置き換わっています。この翻訳力は、技術書とビジネス書の両方を読むことで鍛えられます。

もう 1 つ知っておいたほうがいいのは、翻訳しても通らない提案があることです。予算の締めや他部署との約束が理由なら、説明の精度を上げても結論は動きません。却下されたときは「伝わらなかったのか、伝わったうえで順番の問題なのか」を聞いてください。後者なら、次に空く枠を確認して提案を保留するほうが早く済みます。

関連記事

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

まとめ

非エンジニアの上司に技術を伝えるには、技術用語をビジネスの言葉に翻訳する力が必要です。ビジネス書で上司の思考言語を学び、技術書のまえがきで翻訳の手本を見つけ、文章術の本で伝え方の原則を身につける。影響・提案・コスト・リターンの順で話せば、少なくとも「何を判断すればいいのか分からない」という理由で保留されることはなくなります。