- Appleのエンジニアリングリーダー Michael Lopp は、プロダクトを素早く作れる時代であるほど 人間中心の運営と判断力 が重要だと強調
- 「誰が意思決定を行い、その決定をどう実行するのか？」こそが真のエンジニアリングの本質
- コードを書く能力以上に、人を中心に据えた組織とリーダーシップ が組織の成果を左右
- 彼はBorland、Netscape、Palantir、Slackなど多様な環境で得た経験をもとに、組織構造、協業文化、リーダーシップの中核能力 を具体的に提示
- 技術リーダーシップよりも 組織運営、人と人との協業、人間理解 に焦点を当てている
- このインタビューは単なる技術論ではなく、持続可能で効果的なエンジニアリング組織の設計 に集中し、プロダクトチームとの関係、人間中心の能力、優れたリーダーの条件などを 創業者と技術リーダーへの実践的な助言という形で提示
エンジニア組織の構造をどう設計するか
- 異なる業界でも共通する成功要因として エンジニアリングへの信頼、急速な成長、優秀な人材の確保 を挙げる
- これをもとに、成功するエンジニア組織を設計するための3つの実践的なヒントを提案
Tip #1: 「Wolf Time」を奨励せよ
- エンジニアの時間を 71%の実務 / 29%の自由創作時間 に分割
- 29%は「測定不能で説明不要な時間」であり、創造性と自発性が育つ空間
- Palantirでの公式化の試みは失敗 → 形式化よりも非公式な奨励と対話が効果的
- 例: 毎週金曜日に非公式なアイデア共有時間を提案
> 「この時間が認められているとチームメンバーが認識していなければ、会議の合間にこっそりやることになり、何も育たない」
Tip #2: 議論は定期的であるほどよい
- 優れたプロダクトは エンジニアリング、デザイン、プロダクト の3分野の協力から生まれる
- この協業はしばしば衝突を伴うが、その議論こそが プロダクト品質を高める核心
- 「デザインの問題か、プロダクトの問題か、機能理解の問題か」をめぐって チーム内の議論が活発であるべき
- リーダーは ボトムアップだけでなくトップダウンでも意見への異議を促す 必要がある
- 創業者と社員の間の議論が会社の方向を変える瞬間がしばしば存在する
Tip #3: 拡張可能な運営システムを構築せよ
- 優れた判断力 + 運営力 がスケーラブルなプロダクトの基盤
- 判断力とは単なる結果ではなく、「なぜそのように決めたのか」を説明できる能力
- 責任(Accountability)の意味は 「報告できるストーリー」を持つこと
- 少数の判断力を 組織全体のシステムへと拡張するには明確なプロセスが必要
- 採用プロセスを見ても運営品質は表れる（応答速度、日程の明確さなど）
- スタートアップを言い訳にプロセスを無視してはならない → 会社を作ることは、そのまま運営を作ること
エンジニアリングとプロダクトチームの関係をどう強化するか
- プロダクトチームとエンジニアリングチームの 緊張と誤解 は昔からある話だが、
質の高いプロダクトをスケーラブルに作るには、この関係を丁寧に磨くことが不可欠 である
- 悪いPM はエンジニアがプロダクトに 当事者意識なく従うだけになるようにし、
- 良いPM はエンジニアが 「なぜこれを作るのか」を十分に理解できるよう助ける
- Loppはエンジニアを 「how」の人、PMを 「why」の人 と定義
- プロダクトチームは 顧客のストーリーを伝え、どう作るかはエンジニアとデザイナーに委ねる べき
- 核心は「why」を共有すること
> PMではなくエンジニアに「なぜこの機能を作るのか？」と直接聞いてみよ
- 答えが「PMに言われたからです」なら怒りを覚える
- 本当の問題はプロダクトチームの判断が間違っていることではなく、エンジニアが文脈を理解していないこと
> 「エンジニアは手でプロダクトを作る人だ。彼らが『なぜこれを作るのか』を理解しないまま働く組織は失敗する」
- なぜSlackにはブロック機能がないのかという質問に対し、Stewartは 「情報は誰にでも見えることが重要だ」 という哲学を明確に説明
- 良いプロダクトマネージャーは 各機能やアイデアをプロダクト全体のビジョンの中で文脈化して伝える ことができなければならない
優れたリーダーとはどんな人か？
- 真のエンジニアリングリーダーシップは単なる技術的能力を超えるもの
- 「結局、リーダーシップとは人を扱う技術だ」
-
リーダーシップ特性 #1: 柔軟性(Malleability)を備えている
- リーダーは多様な性向の人々と働き、それに合わせて 自分のスタイルを調整 できなければならない
- PinterestとSlackでまったく異なるやり方でチームを率いた自身の経験を例に挙げて強調
- 新任マネージャーにはいつも同じ質問をする: 「フィードバックを受けたあと、あなたは何を変えましたか？」
- チーム編成も固定的な基準ではなく、実際に一緒に働く中で見えてくる 強みと弱みに基づいて再編成 する
- そのために彼は 6カ月ごとにリオーガナイズ を実施
-
リーダーシップ特性 #2: ストーリーテリング能力に優れている
- マイクロマネジメント に強い拒否感を示す: 「エンジニアに指図することほど苛立つことはない」
- その代わり、リーダーは 「箱(Box)とスープ(Soup)」 を提供すべきだという
- 箱: アイデアと文脈が詰め込まれた空間
- スープ: メンバーが自由に飲んだり組み合わせたりできる情報の土台
- 指示の代わりに 人を動かすストーリー を提供すれば、メンバーは自ら判断し成長する
- 一部のメンバーは「何をすればいいかだけ言ってください」と言うが、それでも結局は 自分なりの方法で解釈する
> リーダーの役割はスープを渡すこと。飲むか、何を加えるかは彼らの選択だ。
-
リーダーシップ特性 #3: メンバーの動機と目標を理解している
- リーダーはチームメンバー一人ひとりが 何によって成長し、何に動機づけられるのか を知っている必要がある
- ある例: 技術的挑戦が人生の原動力であるエンジニアには 絶え間ない問題解決の機会 を提供
- 別の例: Palantirのアシスタントは 報酬中心の動機 を明確に示した → 明確にマネジメント可能
- 核心は各人の 「たった一つの中核動機」 を把握し、そこに継続して投資すること
- そのためには 好奇心(curiosity) と 絶え間ない「なぜ？」という問い が不可欠
> リーダーは、メンバー自身も気づいていない動機を発見し、成長の機会を生み出さなければならない。
結論: 成功するエンジニアリングの本質は人間理解
- 成功するエンジニアリング組織は、円滑に機能する人間関係の力学(Human Dynamics)にかかっている
- 優れたプロダクトは 卓越した個人ではなく、うまく協業する人々の集まり から生まれる
- リーダーの役割は 組織を構成する人々に力を与えること から始まる
- 「エンジニアリングチームは、複雑で素晴らしい人間たちが織りなす巨大なタペストリー(tapestry) 」
- このタペストリーの構造と流れを理解しようとする努力こそが、プロダクトの価値が組織全体を通じて効果的に届けられるようにする鍵 である
> 「人々がどのように相互作用するのかを理解しようとする動機を持つとき、あなたの会社はプロダクトの価値をスケールして届ける準備が整うのだ。」
6件のコメント
Michael Lopp が運営する、技術リーダー向けの Slack があります。
RLS - Rands Leadership Slack
興味のある方は一度参加してみてください。現在 36,000 人以上が参加する巨大な Slack です。
参加するには、上のリンクの内容をよく読んで、Lopp にメールを送れば大丈夫です。
名前 / 職業 / なぜ参加したいのか / どこで RLS について知ったのか / 自分の LinkedIn や Twitter などのアカウント
高い金を払ってエンジニアを採用したのなら、ペンを転がすだけの立場でエンジニアをLLM扱いし、何でもぱっと作ってくれるドラえもんに命令するかのように細かいことまであれこれ指図するのではなく、自分のビジョンだけを共有して、それを実装するための工学的なアプローチこそその人の専門分野なのだから、あとは任せろということですね。
じっと聞いていると、なぜか日本の地方で一戸建てを建てたり、あるいは中古マンションをリノベーションしようとする人たちが、業者や施工会社、設計士とぶつかり合っているやり取りの流れが頭に浮かぶのはなぜでしょうか。
後者のケースは、少し文脈が違うのではないでしょうか?
戸建て住宅や築年数の古いマンションのリフォームは、
そもそもビジネスというよりは理想の実現に近い領域ですし、
建設・リフォーム業者に信じて任せた結果、ひどい目に遭うことが妙に本当に多く起きているので……
当事者が自分で作らずに誰かに任せたら、まったく同じような状況になる気がします。
どれだけ丁寧に説明しても誤解はありますし、どれだけ細かく確認したつもりでも、思い至らなかった領域が存在するものですね。
依頼主が言及していない部分を一つひとつ確認しながら作ると時間もかかってもどかしいので、専門家が判断して処理する部分がかなり多いのですが、その部分がことごとく揉め事の種になるのだと思います。
それはそれとして、SI企業にあまり痛い目に遭わされてこなかったようで、うらやましいです。
最近読んだ『モダン・ソフトウェアエンジニアリング』も思い出します。開発そのものではなく、チームや組織についても語っているんですよね。
エンジニアリングリーダーシップにはさまざまな意見や方法がありますが、本質はメンバーへの理解に基づいているという点で共通しているように思います。メンバーを理解するというのは言うのは簡単ですが、お互いのフィードバックを通じて、リーダーとメンバーの間に共感を土台とした信頼を積み重ねていく必要があるのだと思います。一度でできあがるものではないのかもしれませんね。考えさせられる良い内容をありがとうございます。