技術的には正しい説明をしているのに、会議室の空気がまったく動かないことがあります。
経営層やビジネス側への説明では、丁寧に話すほど相手の目が泳いでいくという場面がよく語られます。
事業部や経営層への説明を任され始めて、「技術の話を、どう言い換えれば通じるのか」と迷ったことはありませんか？
技術的負債の返済計画をどう説明するかは、別の記事で扱いました。
見積もりの幅の伝え方も、同じく個別の記事にまとめてあります。
その二つの手前には、どの場面にも共通する「何を・どの順番で・どの単位で話すか」という型があるように思います。
私自身もテックリードを目指して学んでいる途中なので、足場にするのは先人が公開している一次情報です。
翻訳は「言い換え」ではなく「判断材料への組み替え」
専門用語をやさしい言葉に置き換えるだけでは、説明を薄めることにもなりかねません。
手がかりになるのが、アーキテクトのグレゴール・ホープ氏が 2017 年に Martin Fowler のサイトへ寄稿した「The Architect Elevator」です。
同氏は会社を一棟のビルにたとえ、実装が動く「機関室」から、経営陣が戦略を決める「ペントハウス（最上階）」までをエレベーターがつないでいると描きました。
アーキテクトの仕事は、その間を素早く行き来して、事業の戦略と技術の実装をそろえることです。
印象的だったのは、役員会議であるアーキテクトがアーキテクチャとは何かをうまく説明できず、聞き手が首をかしげ始めたときの一言でした。
同氏が「アーキテクチャとは、オプションを売ることです」と言い換えると、役員たちはすぐに関心を示したそうです。
金融のオプションは、将来あらかじめ決めた条件で売り買いできる権利のことです。
さらに一人の役員は、変動の大きい市場ほどオプションの価値が上がるという金融の知見を当てはめ、先の読めない環境ほどアーキテクチャの選択肢は価値を増すと自ら結論づけています。
ここで起きていたのは、用語をやさしくしたことではなく、相手がすでに使っている判断の枠組みに話を載せ替えたということです。
経営の側が日々扱っているのは、お金・時間・リスク、そしてどの選択肢を取るかという判断です。
技術の話も、この単位に組み替えて初めて判断材料になるのではないでしょうか。
順番は「結論 → 根拠 → 求める判断」
単位をそろえたら、次は話す順番です。
Staff エンジニア（管理職にならずに組織横断で技術を率いる上級職）の役割をまとめたウィル・ラーソン氏は、経営層への説明についてのガイド「Present to executives」を公開しています。
同氏が勧めているのが、冒頭の段落を次の四つの順で組む SCQA という型です。
- 状況（Situation）: 関係する前提は何か
- 複雑化（Complication）: 今の状況のどこが問題なのか
- 問い（Question）: 答えるべき核心の問いは何か
- 答え（Answer）: その問いへの、いまの最善の答えは何か
元になっているのは、バーバラ・ミント氏の著書『The Pyramid Principle』にある、個々の論点より先にそれらをまとめた結論を示すという考え方です。
同じガイドは、学校で教わる発表の仕方は経営層向けにはほぼ丸ごと間違ったやり方だ、とまで書いています。
背景から積み上げて最後に結論を出す順番は、相手がいちばん知りたい答えを最後まで待たせることになるからです。
例えば、架空のケースに SCQA を当てはめると次のようになります。
- 状況: 来期、決済まわりに三つの機能追加が予定されている
- 複雑化: 今の作りでは、障害が起きたときの切り戻しに時間がかかる
- 問い: 機能追加の前に、切り戻しを速くする改修を入れるべきか
- 答え: 一つ目の機能と並行して、改修を先に入れることを提案する
冒頭のこの四行だけで、相手は「何を決めればよいか」を最初に受け取れるわけですね。
ガイドには、答えを持たずに問いだけを持ち込まないこと、という注意も並んでいました。
自信がなくても、いまの最善の答えを置いてから意見をもらうほうが、会話は前に進みます。
技術の数字を「事業が選べる形」に置き換える
三つ目の工夫は、技術の数字そのものを、事業の側が選べる形にして渡すことです。
分かりやすい手本が、Google が公開している SRE（信頼性をエンジニアリングで守る考え方と職種）の本にある「Embracing Risk」という章です。
同書は、サービスを 100% 落ちないようにすることは、ある地点を超えると利用者にとってもむしろ悪い目標になると述べています。
信頼性 99% のスマートフォンを使う利用者には、サービス側の 99.99% と 99.999% の違いは分からない、というのがその理由です。
しかも極端な信頼性は、新機能を届ける速さを縛り、コストを大きく押し上げます。
そのうえで同書が示すのは、四半期にどれだけ落ちてよいかの目標（SLO＝サービスレベル目標）を、何を作るかに責任を持つプロダクトマネジメントの側が決める形です。
目標から逆算した「使ってよい失敗の量」がエラーバジェットで、同書はこれが開発側と SRE の交渉から政治的な駆け引きを取り除くと説明しています。
可用性という技術の数字が、「どこまでの不安定さを受け入れて、その分の速さを買うか」という事業の選択に変わったわけです。
リスクの話も、同じ要領で分解できそうです。
米国立標準技術研究所（NIST）の用語集の risk の項は、リスクをおおむね「起きたときの悪影響」と「起こりやすさ」の関数として定義しています。
「脆弱なライブラリが残っている」とだけ伝えるより、どれくらい起こりそうか、起きたら何が止まるかに分けたほうが、優先するかどうかを相手が自分で判断できるようになります。
テックリードの役目は、目標を一人で決めることではなく、選べるメニューを作って渡すところまでなのです。
翻訳でつまずきやすい落とし穴
型を知っていても、つまずきやすい場面は残ります。
説得しに行ってしまう
ラーソン氏のガイドで意外だったのは、経営層との場の目的を「相手の考えを変えること」に置いていない点でした。
むしろ相手の視点をできるだけ多く引き出すことが目的で、考えを変えさせに行くと頑なな人に見えてしまう、と書かれています。
フィードバックとは決して戦わず、反対なら関連するデータを一つか二つ添えたうえで手放す、というのが同氏の勧めです。
同氏は、ほぼすべての決定がその後の 2 年で何度も見直される、とも書いており、一度の場で勝ち切る必要はないと分かります。
上の階に居ついてしまう
ホープ氏は、最上階の眺めを気に入って降りてこなくなるアーキテクトにも触れていました。
技術の移り変わりが速い今、それではすぐに腕が通用しなくなる、という指摘です。
同氏の結論は、エレベーターを上り下りし続けることだけが、最上階と機関室をつなぐ方法だ、というものでした。
最後に
技術の話を経営の言葉に翻訳するとは、用語をやさしくすることではなく、相手の判断の単位に組み替えることです。
単位はお金・時間・リスク・選択肢にそろえ、順番は結論から組み、技術の数字は相手が選べる形にして渡します。
冒頭で挙げた負債と見積もりの記事も、この型を個別の場面に当てはめた例として読み直せます。
まずは次の説明の冒頭を、SCQA の四行で書き出してみるところから始めようと思います。
以上です。
コメントを残す