はじめに
SUZURI事業部 事業部CTOの黒瀧です。この度、Will Larson氏の著書「The Engineering Executive’s Primer」（日本語版「エンジニアリング統括責任者の手引き」）の翻訳レビューに、私とkenchanで参加しました。
効果的なバリューの3つの条件とGMOペパボのエンジニアバリュー
書籍には、組織の意思決定やマネジメントに役立つ実践的な知見が多数盛り込まれていますが、特に印象的だったのは第5章の「効果的なバリューを作る」です。この章で述べられているリバーシブル（Reversible）、適用可能（Applicable）、正直（Honest）の3つの条件は、効果的なバリューを策定・運用する上で不可欠だと著者は述べています。
今回は、この3つの観点からGMOペパボのエンジニアバリューを見つめ直し、今後のEngineering All Handsや日々のエンジニアリングにどう活かしていくべきかを改めて考えてみました。
リバーシブル（Reversible）
効果的なバリューは、異なる視点や反対の視点から見ても意味を失わず、複数の実行可能なアプローチの中から行動を導くものであるべきです。GMOペパボのエンジニアバリューは、この「リバーシブル」性を備えていると考えます。
- 「すべてが自分ごと」：これは「他人の課題は他人ごと」という考え方と対極にあり、チームや組織全体の課題に積極的に関わることを促します。このバリューがあるからこそ、私たちは部署の壁を越えて協力し、より大きな成果を目指すことができます。
- 「最高・最速の両立」：これは「最高品質だけを追求して遅くなる」または「最速だけを追求して品質が下がる」という状況を避け、その両方を高いレベルで目指すという、一見相反する目標を両立させるための指針です。このバリューが、私たちのサービス開発において、周りの変化に柔軟に対応しつつ、ユーザーに届けることに繋がっています。
- 「アウトプット前提」：これは「インプットばかりでアウトプットしない」という状態と対極にあり、常に具体的な成果を生み出すことを意識します。これは、私たちのミッションである「人類のアウトプットを増やす」をエンジニアリングの現場で実践するための重要な指針です。
これらのバリューは、単なる理想ではなく、具体的な行動選択の方向性を示していると言えるでしょう。
適用可能（Applicable）
バリューは関連する意思決定の多くに適用でき、それらの意思決定の質を高めるものである必要があります。何か判断に迷ったときは「最近、インプットが多いけど、アウトプットできていないな…アウトプット前提で考えよう！」のようにバリューを意識することで、日々のプロダクト開発、事業開発において適用できると考えています。
- 新しい技術導入の検討時：「最高・最速の両立」の観点から、その技術がユーザー体験の向上と開発スピードのどちらに貢献するかを評価します。
- チーム間の連携が必要な課題解決時：「すべてが自分ごと」の精神で、自分の担当範囲を超えて積極的に関与し、協力体制を築きます。
- 新しい表現やアイデアの創出時：「アウトプット前提」のバリューが、試行錯誤のプロセスを加速させ、具体的な成果へと繋げます。
これらのバリューは、個々のエンジニアが日々の業務で多様な意思決定をする際に、事業の拡大やユーザー体験の最大化に繋がる判断を促す羅針盤として育てていきたいと考えています。
正直（Honest）
組織の実際の行動を正確に記述していること。理想的すぎると、現実との乖離から真面目なメンバーを苦しめることになると著者は述べています。
GMOペパボのエンジニアバリューは、私たちの実際の行動や文化を色濃く反映していると自負しています。私たちは常にユーザーへの最高の体験を追求し、チームや会社全体の課題に「自分ごと」として向き合い、そしてアウトプットを通じて価値を生み出すことを重視してきました。もしバリューが現実と乖離していると感じるならば、それはバリューを変える前に、まず実際の行動を変える必要がある、とLarson氏は述べています。
私たちのバリューは、これまでのペパボのエンジニアリング組織が築き上げてきた文化と、私たちが目指す未来に向けて、日々の開発においてさらに意識すべきものだと再認識しました。
エンジニアリング戦略を立ててみた
技術責任者の @kenchan です。翻訳レビューに参加させていただいた時期は、新しい仕事として技術部の部長に就任した直後でした。新しい仕事で四苦八苦している中で、なにかすぐに役立ちそうなことはないかと読みはじめたところ、3章に書かれている「エンジニアリング戦略を立てる」は これだ！ と思える内容ですぐに実践してみました。
診断・基本方針を定める
該当の章におけるエンジニアリング戦略は、現状の診断を行い、それを根拠とした方針を定め、その方針に沿うために全員に徹底してほしい一貫した行動を示すことであるとされています。エンジニアリング戦略を共有するにあたり、私自身が部署移動直後だったこともあり、まずは私視点での「診断」と「基本方針」を示してチームメンバーから見えている世界と一致しているかの意見を求め、「一貫した行動」はこれから決めていこうと考えました。
その際に共有したのは以下のような内容です。
- 診断
- 技術部および各チームに求められている業務範囲とレベル、またそれらの現実的な状況
- チーム構成と人数比、直近の入退社の傾向から今後の人員計画の予測
- 各事業の予算計画・成長目標
- 会社やグループにおける注力領域
- 部門のエンゲージメントサーベイの傾向
- 基本方針
- 注力事業へのインフラ業務の割合を増やす
- インフラコスト管理(FinOps)の改善とコスト削減目標の達成
- 採用計画の共有とリファーラル採用への注力
文章にすることのよさ
書籍に掲載されていた3ページにわたるエンジニアリング戦略の例を読み、戦略伝達の手法について考えさせられました。
私はこれまで、戦略のように複雑な概念を伝えるには、図表を多用したスライドが最も効果的だと考えていました。しかし、その事例を読み、文章として体系的に記すことの利点にも気づかされました。 書籍の記述は、スライドで語られるべき内容のいわば「完全版」のようであり、思考の背景や詳細な文脈まで深く理解できるという利点がありました。一方で、図があればより直感的に理解できたであろう部分も存在します。
この経験から、戦略を効果的に伝えるためには、要点を視覚的に示すスライドと、その論拠や詳細を補完する文章の両方を準備することが理想的であるという結論に至りました。
おわりに
「エンジニアリング統括責任者の手引き」は、各章を読んでいて参考になることが非常に多い書籍です。3章を読むことで戦略をどのように考えて立てればよいのかのヒントが得られました。また、第5章を読みながらペパボのエンジニアバリューを見つめ直すことで、これからのエンジニアリング組織の未来に向け、まずは自分自身がバリューを体現していこうと強く思うことができました。
翻訳レビューという貴重な機会をいただき、ありがとうございました。