Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【CTO・VPoEぶっちゃけトーク!】失敗から学ぶエンジニア組織論

Kenji Sakai
December 15, 2022
200

 【CTO・VPoEぶっちゃけトーク!】失敗から学ぶエンジニア組織論

CTO・VPoEぶっちゃけトーク! 〜失敗から学ぶエンジニア組織論〜
https://openlogi.connpass.com/event/265230/
での登壇資料です

Kenji Sakai

December 15, 2022
Tweet

Transcript

  1. ©OPENLOGI Inc.
    失敗から学ぶエンジニア組織論


    View Slide

  2. ©OPENLOGI Inc.
    Confidential

    自己紹介

    執行役員 VP of Engineering
    坂井健治
    @saka0ken
    大学卒業後、大企業向け ERPパッケージベンダーへ入社。
    ECサイトのパッケージソフトの新規開発や運用保守を担当後、 4
    年目から新製品の開発マネージャーとして 30人の組織のマネジ
    メントに従事。
    その後、VPoEとしてジョインした電子書籍の会社では、 100名の
    エンジニア組織のマネジメント・採用に従事。
    オープンロジには2021年7月にジョイン。
    趣味は池袋が聖地であるサウナとジンギスカン。

    View Slide

  3. ©OPENLOGI Inc.
    Confidential

    目的

    ● 過去のエンジニア組織での失敗を振り返って、今現在オープンロジでは
    どうしているかをお話します


    ● 現在、CTO/VPoE・EM等のロールでエンジニア組織のマネジメントをして
    いる方は、同じ失敗する前に参考にしていただければ幸いです


    ● 同じ失敗を今している人は飲みに行きましょう。DMください(笑) 


    View Slide

  4. ©OPENLOGI Inc.
    失敗その①

    繰り返される立て直し


    View Slide

  5. ©OPENLOGI Inc.
    Confidential

    立ち直しのプロとして活躍

    ● 炎上プロジェクトの立て直し

    ○ 計画時に想定していた予算・期間内での開発が不可能な状態

    ○ お客様の期待と現実のプロダクト・開発進捗に大きなギャップ

    ● 1年半リリースが遅れた開発プロジェクトを半年でリリースまでもっていっ
    た

    ● 立て直し人材として高く評価され、炎上プロジェクトの立て直しをしては次
    のプロジェクトへ…という形で、プロジェクトを転々としていた


    View Slide

  6. ©OPENLOGI Inc.
    失敗


    View Slide

  7. ©OPENLOGI Inc.
    Confidential

    炎上プロジェクトが無くならない

    ● いくら立て直しをしても、炎上プロジェクトが増え続けて無くならなかった

    ● エンジニア組織も疲弊、私も疲弊して耐えられなくなった


    View Slide

  8. ©OPENLOGI Inc.
    Confidential

    余談:立て直しでやることは単純

    ● 炎上プロジェクトの原因の大半は、明確にすべきことが曖昧になっている
    こと

    ● 例えば

    ○ 最終成果物のイメージがお客さまと合っていない

    ○ 開発が間に合わないと分かっているのに、期日の調整や対応策を明
    確にしていない

    ○ 課題やタスクの分解が甘くて、何をするのか明確ではない

    ● やるのは曖昧なことを明確にしていくこと

    ● 曖昧なことを発見するたびに明確にし続ける


    View Slide

  9. ©OPENLOGI Inc.
    Confidential

    余談:立て直しでやることは単純


    ● ただし、マイナススタートなので…

    ○ いろんな人の負の感情が噴出する

    ○ 長時間労働になりがち

    ● 強いメンタルと長時間労働を乗り切る体力さえあればなんとかなる

    ● 単純ではあるが、簡単ではない


    View Slide

  10. ©OPENLOGI Inc.
    振り返り


    View Slide

  11. ©OPENLOGI Inc.
    Confidential

    なぜ炎上するのか?

    ● 本当にプロジェクト単位での失敗か

    ● 経営レベルでの意思決定の可能性あり

    ● 例えば

    ○ 1. 現場の実情とかけ離れた新技術の全社導入

    ○ 2. 開発途中の大規模社内フレームワークの全社導入

    ○ 3. どれだけプロジェクトを改善して、エンジニアを増やしても開発が遅
    れ続ける

    ● プロジェクト単位が原因ではないので、再発し続ける


    View Slide

  12. ©OPENLOGI Inc.
    Confidential

    健全な組織へ

    ● CTO/VPoEが経営層にいて、できること・できないことを明確に経営に説
    明して、エンジニア組織の力を超過した開発をしないようにする

    ● ビジネス・開発の信頼関係をつくる

    ○ 経営がエンジニアリングを一定理解していて、任せてくれる、信じてく
    れる

    ○ そのためのインプットもやる

    ○ エンジニア組織がきちんとプロダクトをリリースしていく

    ● 健全な組織をつくりたいなと思って、VPoEになった




    View Slide

  13. ©OPENLOGI Inc.
    失敗その②

    権限と責任以上のことをやる


    View Slide

  14. ©OPENLOGI Inc.
    Confidential

    エンジニア組織以外の課題

    ● エンジニア組織の課題の原因が、実は経営・ビジネスの課題というケー
    スがある

    ● 例えば

    ○ 1. エンジニアのモチベーションが下がっている

    ○ 2. 開発したサービスが使われていない

    ○ 3. そもそもの事業方針が間違っているのでは?

    ● なんとか解決しようと画策する

    ○ プロジェクトのMTGに入って課題を説明

    ○ 事業部長に課題を説明

    ○ 経営層に課題を説明


    View Slide

  15. ©OPENLOGI Inc.
    失敗


    View Slide

  16. ©OPENLOGI Inc.
    Confidential

    煙たがられて終わる

    ● 経営層・事業部長に煙たがられる

    ● かなりの労力と時間をつかったのに課題も解決されない


    View Slide

  17. ©OPENLOGI Inc.
    振り返り


    View Slide

  18. ©OPENLOGI Inc.
    Confidential

    経営・ビジネスとの視点の違い

    ● 経営層や事業部長は、エンジニアとは違った視点でサービスを見ている

    ○ 株主・投資家からの意見

    ○ 中長期の成長戦略

    ○ 予算計画

    ○ 部下の育成

    ● 懸念した通り、サービスは成長しないかもしれないが、別の視点では正し
    く見える

    ● 経営層・事業部長と私も目線を合わせる必要があった


    View Slide

  19. ©OPENLOGI Inc.
    Confidential

    横やりに見える

    ● 事業部長としては頑張って立案・調整して、経営層と合意も取った事業戦
    略・計画のはず

    ● その苦労を知らない外野からの意見に聞こえる


    View Slide

  20. ©OPENLOGI Inc.
    Confidential

    経営・ビジネスと同じ目線を

    ● 自分でやり切るか?

    ○ 権限・責任を越えプロジェクトに介入して課題を解決する

    ○ ただし、時間と労力が膨大にかかる

    ● 課題だけレポートして任せるか?

    ○ CTO/VPoEとしてのエンジニア組織の仕事に集中する

    ○ 経営層に課題はしっかりレポートしておく、時間はかかるかもしれな
    いが解決する可能性はある

    ● 経営・ビジネス・エンジニアが相互に理解をして、同じ目線で、一丸となっ
    てプロダクトをつくっていくことにオープンロジではチャレンジしている


    View Slide

  21. ©OPENLOGI Inc.
    Confidential

    カルチャーをつくる

    ● オープンロジのバリュー「Active Dialogue」

    ○ 立場に関係なく意見を言い合える。他部署の議論に積極的に参加す
    ることが奨励されている

    ○ 政治や根回しが一切ない

    ○ 一つのプラットフォームを全員でつくる事業なので、壁をつくらないこ
    とが非常に重要


    View Slide

  22. ©OPENLOGI Inc.
    失敗その③

    現状否定の方針発表


    View Slide

  23. ©OPENLOGI Inc.
    Confidential

    現状の課題をまとめた方針発表

    ● 新しい組織にVPoEとしてジョイン

    ● 最初は下記の課題があるように見えた

    ○ 負債化した自社フレームワーク

    ○ プロダクトの方向性があいまい

    ○ マネジメントと採用が機能していない

    ○ エンジニアが足りない


    ● 今後の方針を示すために、課題をまとめた資料をエンジニア全員の前で
    発表


    View Slide

  24. ©OPENLOGI Inc.
    失敗


    View Slide

  25. ©OPENLOGI Inc.
    Confidential

    VPoEとしての信頼を失う

    ● 賛同するメンバーも一定いたが、古株のメンバーから反発があった

    ● 反発があるので、メンバーが課題解決に動きたくても動けない

    ● 賛同するメンバーを増やすため、自分がリファラルして協力者を採用する

    ● リファラルで採用したエンジニアが、周りからは坂井派閥に見え、「坂井さ
    んが何かたくらんでいる」等の陰謀論も聞こえた


    View Slide

  26. ©OPENLOGI Inc.
    振り返り


    View Slide

  27. ©OPENLOGI Inc.
    Confidential

    先人への敬意がなかった

    ● 過去の積み上げがあって今のプロダクト・組織がある

    ● もちろん課題はあるが、それは当時の制約の中での最善を尽くした結果

    ○ 立ち上げ時期は、サービスのPMF、スピードが最優先

    ○ 人員も不足しており、すべてに手が回るわけではない

    ● 先人の頑張りを考慮せず、課題に対して「誰も何もしてない」「戦略がな
    い」等の否定的で責める言葉を使ってしまった


    View Slide

  28. ©OPENLOGI Inc.
    Confidential

    メンバーとの認識ギャップ

    ● メンバーとの課題の認識に大きくギャップがあった

    ● 長く同じに組織にいると、課題があることが当たり前になってしまい、課題
    だと感じなくなってしまう

    ○ 中国のことわざ「魚の目に水見えず、人の目に空見えず」

    ● ギャップを埋めずにいきなり全体発表してしまった

    
 現状の課題

    認識している

    課題


    View Slide

  29. ©OPENLOGI Inc.
    Confidential

    先人への敬意と1on1

    ● 先人が築き上げてきたことには敬意をもつ

    ○ 立ち上げ時期は大変。それを乗り越えたことがすでにすごい

    ○ 否定ではなく、承認から

    ● 全体に発表する前に、メンバーと課題の認識ギャップが大きい場合は関
    係者を集めたMTGや、1on1を挟んで個別にギャップを埋めていく。その
    後、全体発表をする

    ● オープンロジでは、全体会、TGIF、各種定例、1on1等の社内のコミュニ
    ケーションを整理して、仕組み化して運用している


    View Slide

  30. ©OPENLOGI Inc.
    失敗その④

    マネージャーの早期退職


    View Slide

  31. ©OPENLOGI Inc.
    Confidential

    優秀なマネージャーを採用

    ● 優秀なマネージャーを採用

    ● CTO/VPoE/EM含めて全員が面接でA〜S評価

    ● エンジニア組織のネガティブポイントも伝えて、現状を理解した上で、内
    定承諾

    ● 優秀で主体性もあるので、ミッションをすり合わせて自由にやってもらう


    View Slide

  32. ©OPENLOGI Inc.
    失敗


    View Slide

  33. ©OPENLOGI Inc.
    Confidential

    早期退職に

    ● 結局あまり活躍できずに1年程度で退職

    ● ポテンシャルはあって優秀だったはず…


    View Slide

  34. ©OPENLOGI Inc.
    振り返り


    View Slide

  35. ©OPENLOGI Inc.
    Confidential

    成功体験をつくらなかった

    ● 私の1社目が自立性をかなり求めるカルチャーの会社だったので、優秀
    な人は放っておいても成果を出すと思っていた

    ● 会社の外にでると、かなり特殊なカルチャーだった


    View Slide

  36. ©OPENLOGI Inc.
    Confidential

    なぜ放っておいてはいけないか

    ● マネージャーは、過去の組織でのハイパフォーマー

    ● 過去の組織で培った自分の成功パターンをもっている

    ● 成功パターンが違う組織でそのまま通用するか?

    ○ 全く同じ組織ではないので、チューニングする必要がある

    ○ チューニングは簡単ではない

    ■ プロダクト開発の優先順位の把握

    ■ エンジニア組織内の人間関係の把握

    ■ 他部署との関係性の把握

    ● チューニングするのは受け入れる側の仕事


    View Slide

  37. ©OPENLOGI Inc.
    Confidential

    早期の活躍の大事さ

    ● 早期に成功体験をつませることが重要

    ○ エンジニアは成長を求めている

    ■ 開発者体験が良い会社にもつ印象のトップ 79%は「エンジニアと
    して成長できそう」

    ■ 成功体験を積んで成長したいと思っている

    ○ 成果を出すことで、周りからの信頼を得る

    ■ 信頼がないと、大きな施策が進めづらい

    ● 「ハイパフォーマーはストレス耐性は高いが、自分が活躍できないことへ
    の耐性は弱い」

    ※

    ※(出典:一般社団法人日本CTO協会 開発者体験ブランド力調査レポート2022 https://drive.google.com/file/d/1i0lpIC5WSRk4ghKSIhRFbuQR3S7uvyjH/view)

    View Slide

  38. ©OPENLOGI Inc.
    Confidential

    オンボーディングの設計

    の流れ

    エンジニア一人一人に、入社後1カ月、3カ月、6カ月のオンボーディング計画をつくって、早期戦力化

    1. 入社研修、Welcome Lunch(人事/各部署)など
    2. トレーナー/メンター制度
    3. 配属部署にて個々のオンボーディング計画
    4. 部署内、人事、他部署との1on1を設定
    “タテ・ヨコ・ナナメ”の育成支援
    5. 全体会議や各部定例等で積極的に情報共有
    6. 勉強会を頻繁に実施。動画やドキュメント教材も豊富
    7. オンラインランチ等、リモート下でも社内交流を促進
    8. 早期の人的関係構築を人事部/上長が積極支援
    オンボーディング
    38

    View Slide

  39. ©OPENLOGI Inc.

    まとめ


    View Slide

  40. ©OPENLOGI Inc.
    Confidential

    失敗しても前に進みましょう

    ● 組織マネジメントの力は失敗して、伸びると思っている

    ● 経験しなければ分からない、ハードなことも多い



    ● オープンロジでは過去の失敗ふまえて、エンジニア組織をつくっています

    ● We are hiring!


    View Slide

  41. ©OPENLOGI Inc.
    物流の未来を、動かす

    View Slide