シェア
はてブ
Will Larson氏の著作『エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか』が5月30日に発売されました。翻訳者は、エンジニア向けPodcast「fukabori.fm」を主催する岩瀬義昌さん。岩瀬さんは、原著の『An Elegant Puzzle: Systems of Engineering Management』を読み、Xにて「あまりにも最高」と絶賛。その後、自ら編集者にコンタクトを取り、日本語への翻訳を担うことになりました。
岩瀬さんが、「エンジニアのマネジメントに少しでも関係する人には絶対読んでおいてほしい」と言うほどの書籍。その概要や魅力を、岩瀬さんご本人に直接お伺いしました。
|
岩瀬 義昌（いわせ・よしまさ） 東京大学大学院学際情報学府を修了後、東日本電信電話株式会社に就職。大規模IP電話開発に携わった後、2014年より現職であるNTTコミュニケーションズにてソフトウェアエンジニア、テックリードとしてWebRTCプラットフォームの開発に従事する。その後、人事として全社の人材開発・組織開発を推進し、同社のR&D組織に移る。アジャイル開発・プロダクトマネジメントの全社支援を経て、現在は生成AIチームのエンジニアリングマネジャーおよびエバンジェリスト。個人事業主としても活動しており、2021年よりストックマーク株式会社 Co-VPoE。 |
テックリードになってからエンジニアマネジメントに興味を持ち、本書に出会う
――岩瀬さんは、いつ頃からエンジニアマネジメントに興味があったのでしょうか？ これまでのキャリアとともに教えて下さい。
30代でテックリードになった頃からチームを意識するようになり、マネジメント寄りの思想が増えてきたのだと思います。20代の若手メンバーが多いチームだったので、彼らが力を発揮したほうが、チームのアウトプットが出ると強く感じ始めたんですね。
一方、私が所属するのは大きな企業なので、組織をまたぐと、どうしても縦割りの文化などが生まれます。その中でうまくやる方法を考えるうち、組織的な話にも興味を持ち始めたんです。
組織は、ハードとソフト、とカテゴリ分けされることがあります。ハードは組織デザインや戦略などである一方、ソフトは人間同士の関係性や文化のような部分です。最初に興味を持ったのはソフト方面でしたが、結局両方やらなくてはいけないとわかり、両方に足を突っ込んでいったという状況です。
社内でHR（人事部）に異動したときには、エンジニアの採用戦略で尽力したいと思ったのですが、コロナ禍と被ってしまい、関係性や働き方などソフトの方を優先しました。もともとリモートワークに長けたチームの出身だったのと、好きなGitlabの働き方を真似て仕事していたので、詳しかったこともあります。
――そんな中で、『エレガントパズル』の原著に出会ったんですね。きっかけや、読んだときの印象を教えていただけますか。
出会ったきっかけは全く覚えていないのですが、読み始めると著者の主観がたくさん書かれていて非常に興味深かった。これまでのマネジメントの本は、ドラッカーの『マネジメント』に代表されるように、アカデミックな印象のものや、汎用的なものが多い。でもこの本は、UberやStripeといったユニコーン企業を基にしたエンジニアマネジメントの実践知が書かれています。著者の主観によるものなので、正解なのか判断つかない内容もある。ただ、だからこそ日本ではなかなかないタイプの本だと感じて、すごく刺激的だった覚えがあります。
必ずしも賛同できない部分もあるのですが、それを差し引いてもすぐに使えるトピックが多い。エンジニアマネジメントは答えがないものだと思っているので、ある状況における手数が増えるのは本当にありがたい。人がひとり変わっただけでチームの雰囲気ががらりと変わることはザラ。新しい状況に立ち向かうときに、自分の道具箱にたくさんツールが入っていればいろいろな手が打てますよね。
――「面白い！」と思ってすぐに「翻訳したい」と思ったのですか？
そうですね。2022年に読んだ本の中でもっともよかったので、日本で出版されていないことが国自体の損失だと感じました。僕自身は他の翻訳も手掛けていたので、自分で翻訳して日本でも出版したほうがいいと思ったのです。
当時は、Will Larson氏は他の著書も翻訳されていなかったので、「もしかしたら自分が読めない言語に翻訳されたくない」というタイプの著者なのかと勘繰っていました。でも、同氏の2冊目の著書である『スタッフエンジニア』という本が日本で出版されたため、それなら1冊目である『エレガントパズル』も出せるだろうと、編集者にコンタクトを取ったんです。その3か月後くらいに翻訳できる旨の連絡をいただき、翻訳がスタートしました。
目標設定の悩み解決や、採用プロセスの変更など、実践で役立った
――初めて読んだ際に、特に響いた部分をいくつか教えていただけますか。
原著を読んだ当時は、僕自身が「目標設定って何だろう」と大変悩んでいた時期。そこにちょうど目標設定のやり方が書かれていたので、非常に腑に落ちてそのまま実践しました。今もずっとこのルールで書いています。
具体的に言うと、本書には「良いゴール」と「悪いゴール」が示されています。例えば、単なる数字だけのものは悪いゴール。なぜなら、野心的なのか、必須なのかわからないから。よいゴールは次の4つの組み合わせになっている必要があります。
- ターゲット：到達したい場所
- ベースライン：現在の場所
- トレンド：現在の速度
- タイムフレーム：変化の期間
さらに、「良いゴール」と判断する方法も書かれています。次の2つの質問をすればいい。
- その領域をあまり知らない人でも、ゴールの難易度を感じとれるか
- ゴールの達成を後から評価できるか
書籍の中ではゴール設定についてさらなる記述があります。目標設定は、多くの方が悩んでいると思いますが、しっかりと言語化してくれる人はなかなかいない。とても使える部分ではないでしょうか。ちなみに僕は、自分の目標設定にも活用しています。組織にも個人にも使えるツールです。
――それはどんな方でも使えそうなノウハウですね。エンジニアマネジメントならではのトピックで、印象に残った部分はありますか。
システムは、必ずマイグレーションをしなくてはならないタイミングがやってきます。理由はその都度変わりますが、たとえばユーザー数の増加でシステム変更を余儀なくされる場合や、サポートの終了やバージョンアップであるEOLによる場合があります。
著者はマイグレーションにすごくこだわりがあるようで、技術的負債は、最終的にはマイグレーションでしか回収できない、という意図のことも書いています。個人やチーム単独で減らせる技術的負債がほとんどなくなったとき、残った技術的負債を解決するのはマイグレーションです、という理屈です。
ところが、マイグレーションは下手にやると失敗します。上手くいかないマイグレーションで残骸が残ってしまうと、悪い経験が記憶に残り、エンジニアが「マイグレーションしたくない」と言い出す状況にもなり得ます。
マイグレーションは数年単位で実施する必要があり、さらに大きなシステムの場合はエンジニアだけでなく実務の方々も関わる。そのため、困難な意思決定がたくさんあるのですが、意思決定のやり方や著者の経験がしっかりと書かれていて参考になります。
僕自身は、この本を読んだ後にはマイグレーションを経験していませんが、過去の記憶をたどって「このように意思決定されていたんだ」と理解できましたね。
――その後実践したわけではなくても、意思決定する人の考えが想像できるのはいいですね。
そうなんです。先ほど説明した目標設定以外に、本書を読んで実践したものもまだあります。
採用プロセスにファネルメトリクスという手法があり、自然応募やダイレクトスカウト、リファラルなど、さまざまな流入経路からの応募を数字で表し、一次面接、二次面接で通過した人数、不採用の人数などを定量化していくのです。それまでは、しっかりとしたメトリックスを出していなかったのですが、数値化することでボトルネックが明らかになり、改善箇所が定まりました。社内のことなので具体的には言えないのですが、ボトルネックを改善して採用にかなり役立ちました。
また、本書をきっかけに実践したわけではないですが、実践していたことがそのまま書籍に書かれており、非常に嬉しかったトピックもありました。僕はこれまで５〜６年ほど勉強会を続けてきて、最終的に行きついた形式があった。それが、本書の「学習コミュニティ」に書かれている内容とまったく同じでした。つまり、同じ結論に至っていたんです。
著者自身、勉強会の主催でさまざまな失敗体験を経てきたと書かれていて、その点も僕と同じ。「プレゼンの時間を短くして、後半でディスカッションをしたほうが参加者の学びが高まる」といったいくつかの条件が書かれています。これから勉強会をやろうとしている方や、今まさに悩んでいる方などは、参考になるでしょうね。
――ちなみに、あまり参考にならないという部分もあったのでしょうか。
UberやStripeなど、著者が経験したようなハイパーグロースは、日本ではなかなかないと思います。ベンチャーキャピタルの投資額などは桁が違いすぎるため。また、マネジメントの本としては、日本の大企業は古くからある企業であっても使える内容はあるものの、どうしても受け入れられない部分もあると思います。
自分のコンテキストに読み替えないと、上手くいかないケースもあると思います。自分なりにカスタマイズして使ってもらえばいいのではないでしょうか。
ツールボックスに入れておくために、知ることが大事
――本当にたくさんのトピックがありますが、どのような読み方がお勧めですか？
本書では組織をシステムとして捉えていて、エンジニアマネジメントを「ハード」と「ソフト」で分けたときの「ハード」の面が中心に書かれています。すぐに実践できるテクニックもありますが、すぐには使えないけどツールボックスに入れておきたい、というものもある。一読した後になんとなくのインデックスを頭の中に作っておき、何かあったらその都度開くといいのではないでしょうか。「何が書いてあるか」を把握しておけば、必要になった時に開いてすぐ使えます。
一度も通読していなくても、章ごとにパートが分かれているので、その部分だけ読んでも十分に使えます。例えば、採用のトピックなら6章にしっかり書かれているので、そこを先に読めばいい。著者のブログを集めた本なので、前の章から論理的につながるような構成ではなく、スナップショット的に、どこから読んでもわかるように書かれています。
――どのような職種や立場、組織規模の方に向いているのでしょうか？
まず、エンジニアマネジメントに片足でも突っ込んでいる方なら、絶対に読んでおいてほしい本ですね。すぐ使えると思います。
できれば、マネジメントされる側のエンジニアにも読んでほしい。マネージャーが考えていること、苦しんでいることがよくわかるでしょう。将来自分が直面するだろう課題を先に知れるということでもあります。
加えて言うなら、エンジニアリング組織がステークホルダーとなるような組織の人たち。例えばスタッフ部門や経営企画など、エンジニアマネジメントの実態を知りたい人が読むといいのでは。苦労しているポイントや、語彙がつかめると思います。対応している組織の解像度がすごく上がるので、やりやすくなるのではないでしょうか。
組織規模で言うと、これから立ち上がるスタートアップで、数十人から100人に増えるタイミングなどでエンジニア組織を作ろうと考える人は「どハマり」すると思います。とはいえ、僕が務めるのは、グループあわせて社員が数万人という企業。それでも使える内容ばかりだと感じたので、結論、規模に関わらず広く使えるのではないでしょうか。
難しい英語表現が多く、翻訳の作業には大きな苦労が
――これだけ広い内容ですが、翻訳するのに苦労した点はありましたか？
実は、苦労しかなかった、と言っても過言ではないかもしれません。著者の書く英語自体がとても難しかったんです。原著で読む際は、大意をつかんで読んでいくので感じなかったのですが、翻訳は緻密に日本語に直していかなくてはいけない。まったく別のゲームをやっているようでした。
たまたま翻訳していた当時、たまたまオンライン英会話をやっていたので、ネイティブの方に文章の意味をいくつか聞いたことがありますが、そこでも講師から「僕もわからない」と言われたくらい。どうしてもわからない箇所は、著者に直接に質問をしました。「確かにこれは抽象的だ」と返信をもらったことも。僕はこれまでも書籍の翻訳をしたことがありますが、その本の英語はとてもわかりやすかったので、こういった苦労はなかったです。
――ほかに、工夫した点などはありますか？
英語の本を翻訳する時、英語のままやカタカナにして残す場合も多いと思うのですが、できるだけ日本で使われている言葉に直したり、説明を加えたりするようにしました。読みながら調べたり原著をたどったりするのは煩わしいので、できるだけこの本だけを読んで理解してほしかったんです。
加えて、日本語に訳すだけでなく、咀嚼して読みやすい言葉にする作業も大変でした。この辺りは僕だけでなく編集の方にもたくさん直していただきました。
――会社に勤めながら書籍の翻訳をするのは大変な作業だと思いますが、どのように時間を捻出されているのでしょうか？
僕はいわゆる夏休みの宿題をためちゃうタイプで、締切が近づくとパフォーマンスが上がるんです。だから、細切れに締め切りを作って自分を追い込み続けるようにしました。自分で締め切りを作ったり、編集の方に決めてもらったり。
平日は仕事があるので、だいたい休日に作業します。ただ、家族と外出することも多いので、帰ってきてからすぐにパソコンに向かってスタート。「この音楽をかけたらすぐに作業する」といったパブロフの犬のような条件付けもしていました。
僕の作業が終わり、あとは編集の方にお願いするだけ、となった時には、開放感からSwitchのゲームをやり続けていましたよ（笑）。
具体から抽象まで、エンジニアマネジメントのハード部分を網羅
――これまでいろいろお伺いしてきましたが、総括すると本書でどのようなことが学べるのでしょうか。
多岐にわたるため総括するのが非常に難しいのですが、例えば、組織でチームを作るときの人数の決め方といったすぐに使えるものから、後継者を育成する際のサクセッションプランニングという長期的なものまで紹介されています。
ほとんどのマネージャーは、たくさんの課題を抱えています。その中で優先度を付けたり、問題となっている箇所の当たりを付けたりするのは難しい。その際に有用なシステム思考の説明にもページが割かれています。
抽象的なトピックも多いですが、すぐに使える具体的なものもふんだんに紹介されています。逆に言うと、エンジニアマネジメントの「ソフト」部分、例えばチームビルディングの話などはそれほど書かれていません。つまり、ハード面ではかなりの部分を網羅しているのではないでしょうか。システムとして組織や人を捉え、どう扱うか――経験豊富な著者によるひとつの「解」が書かれています。
取材・執筆：栃尾江美
