Press "Enter" to skip to content

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング、読了。著者は元ミクシィの執行役員・アーキテクトで、現在はCTO支援を行っている広木大地さん。

ハカルスのステークホルダの1人からお勧めされたこともあって読んでみたんやけど、タイトルから連想する内容からは大幅に外れて、本書の大半はエンジニア間のコミュニケーションの取り方について書かれてます。

特に「あー、それそれ」と持ったのが、わりと経験豊富なエンジニアが新人や学生に対して「分かった?」と最後一言付け加える口癖。自分もこれって前から意味がないと思ってました。教えられた人が分かったかどうかをその場で確認するのは無理で、後日になって、本人が「自分の言葉で」教えられたことを説明できる、もしくは実践できるようになった時点でしか、確認する方法はないです。

なのに、エンジニアの中には逐一相手に「分かった?」と確認する人がいる。残念やけど、これは自分から見て、コミュニケーションスキルのレベルが1つ下の人の特徴的な行動パターンやと思ってます。

このブログでも何度か書いた気がするけど、自分がアメリカの大学でComputer Scienceを学んで1番印象深かったのは、理系の学生であってもSpeech Communication(日本語で言うところのコミュニケーション学)の授業を必須で取らせること。40歳過ぎた今でも時々夢に見るくらい、自分にとっては恐怖の授業やったのを覚えてます。

相手に対する話し方のパターンをおおまかに4つに分類して、それぞれの手法を実際に自分のネタを使って話す。もちろん英語で。長い時には1時間くらい。アメリカ人の聴衆の前で。母国語が英語でないとか、英語が苦手とか、そんなんもう関係あらへん。当時、英語が全然話せへんかった自分にとっては、そりゃあ地獄ですわ(笑)

ただし、そのおかげで日本に帰ってきてからは、新卒エンジニアのわりには人を説得するのが得意というか、相手の思惑をくみ取るのが上手いというか、ずっと心の中では「日本人って、なんでこんなに話すのが下手なんやろう」と思ってました。いや、ほんまに。

CTOの役割っちゅーのは、ベンチャーと大手企業でかなり違うけど、1つだけ確実に言えるのはプロダクトやサービスを作ることが「CTOの仕事ではない」ということ。自分の周りのベンチャーでも、CTOの仕事をプロダクト・サービス・研究開発だと勘違いしている人がけっこういるんやけど、それはVP of Product/Service/Engineeringの仕事です。

CTOの仕事は、プロダクト・サービス・研究開発に対して最高責任を負う人を探してきて、雇用して、維持して、エンジニアリングチームを正しく機能させること。そして、CTOはエンジニアではなく、経営陣の1人です。経営陣のなかで、たまたま一番技術に詳しい人を便宜上CTOと呼んでいるだけであって、経営陣の間では「経営」の話しかしません。つまりビジネスの話です。技術の話は経営陣ではしません。

CTOという人物は、この経営陣とエンジニアの間に立って翻訳を行う人のことを言います。経営陣に対しては経営の言語だけを使い、エンジニアに対してはエンジニアの言語だけを使います。なので、CTOには相応のコミュニケーションスキルが求められます。

よそのベンチャーでも、稀に経営陣が集まる場でCTOが延々と技術的な話をしている場に出くわすことがあるんやけど、それはもう自分から見たらCTOが1ランク下のVP of Engineeringの仕事をやっているようにしか見えへんわけです。

そういうCTOはいつまでたってもプロダクト・サービス・研究開発から自分の手が離れないので、会社の成長に必要な「次の一手」に取り組む余裕がない。結果、経営陣ともかみ合わない状態が続く、ということになります。下手をすると、「うちのCEOは技術のことが全然分かっていない」などと、雇用される側の立場のような意見を言ったりします。これは経営陣のメンバーとして失格です。

上記はあくまで自分個人のCTOの定義です。自分が元CTOだということで、けっこう辛口なコメントを書いたけど、これからCTOを目指す人、現在CTOをやっている人、CTOの仕事の中身を理解したいと思っている経営者にはお勧めの一冊やと思います。