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

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

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

©OPENLOGI Inc. Confidential  目的  • 過去のエンジニア組織での失敗を振り返って、今現在オープンロジではどうしているかをお話します    • 現在、CTO/VPoE・EM等のロールでエンジニア組織のマネジメントをして
いる方は、同じ失敗する前に参考にしていただければ幸いです    • 同じ失敗を今している人は飲みに行きましょう。DMください(笑)    

©OPENLOGI Inc. 失敗その①  繰り返される立て直し 

©OPENLOGI Inc. Confidential  立ち直しのプロとして活躍  • 炎上プロジェクトの立て直し  ◦ 計画時に想定していた予算・期間内での開発が不可能な状態  ◦ お客様の期待と現実のプロダクト・開発進捗に大きなギャップ 
• 1年半リリースが遅れた開発プロジェクトを半年でリリースまでもっていった  • 立て直し人材として高く評価され、炎上プロジェクトの立て直しをしては次のプロジェクトへ…という形で、プロジェクトを転々としていた 

©OPENLOGI Inc. 失敗 

©OPENLOGI Inc. Confidential  炎上プロジェクトが無くならない  • いくら立て直しをしても、炎上プロジェクトが増え続けて無くならなかった  • エンジニア組織も疲弊、私も疲弊して耐えられなくなった 

©OPENLOGI Inc. Confidential  余談：立て直しでやることは単純  • 炎上プロジェクトの原因の大半は、明確にすべきことが曖昧になっていること  • 例えば  ◦
最終成果物のイメージがお客さまと合っていない  ◦ 開発が間に合わないと分かっているのに、期日の調整や対応策を明確にしていない  ◦ 課題やタスクの分解が甘くて、何をするのか明確ではない  • やるのは曖昧なことを明確にしていくこと  • 曖昧なことを発見するたびに明確にし続ける 

©OPENLOGI Inc. Confidential  余談：立て直しでやることは単純    • ただし、マイナススタートなので…  ◦ いろんな人の負の感情が噴出する  ◦
長時間労働になりがち  • 強いメンタルと長時間労働を乗り切る体力さえあればなんとかなる  • 単純ではあるが、簡単ではない 

©OPENLOGI Inc. 振り返り 

©OPENLOGI Inc. Confidential  なぜ炎上するのか？  • 本当にプロジェクト単位での失敗か  • 経営レベルでの意思決定の可能性あり  • 例えば 
◦ 1. 現場の実情とかけ離れた新技術の全社導入  ◦ 2. 開発途中の大規模社内フレームワークの全社導入  ◦ 3. どれだけプロジェクトを改善して、エンジニアを増やしても開発が遅れ続ける  • プロジェクト単位が原因ではないので、再発し続ける 

©OPENLOGI Inc. Confidential  健全な組織へ  • CTO/VPoEが経営層にいて、できること・できないことを明確に経営に説明して、エンジニア組織の力を超過した開発をしないようにする  • ビジネス・開発の信頼関係をつくる  ◦
経営がエンジニアリングを一定理解していて、任せてくれる、信じてくれる  ◦ そのためのインプットもやる  ◦ エンジニア組織がきちんとプロダクトをリリースしていく  • 健全な組織をつくりたいなと思って、VPoEになった       

©OPENLOGI Inc. 失敗その②  権限と責任以上のことをやる 

©OPENLOGI Inc. Confidential  エンジニア組織以外の課題  • エンジニア組織の課題の原因が、実は経営・ビジネスの課題というケースがある  • 例えば  ◦
1. エンジニアのモチベーションが下がっている  ◦ 2. 開発したサービスが使われていない  ◦ 3. そもそもの事業方針が間違っているのでは？  • なんとか解決しようと画策する  ◦ プロジェクトのMTGに入って課題を説明  ◦ 事業部長に課題を説明  ◦ 経営層に課題を説明 

©OPENLOGI Inc. Confidential  煙たがられて終わる  • 経営層・事業部長に煙たがられる  • かなりの労力と時間をつかったのに課題も解決されない 

©OPENLOGI Inc. Confidential  経営・ビジネスとの視点の違い  • 経営層や事業部長は、エンジニアとは違った視点でサービスを見ている  ◦ 株主・投資家からの意見  ◦ 中長期の成長戦略 
◦ 予算計画  ◦ 部下の育成  • 懸念した通り、サービスは成長しないかもしれないが、別の視点では正しく見える  • 経営層・事業部長と私も目線を合わせる必要があった 

©OPENLOGI Inc. Confidential  横やりに見える  • 事業部長としては頑張って立案・調整して、経営層と合意も取った事業戦略・計画のはず  • その苦労を知らない外野からの意見に聞こえる 

©OPENLOGI Inc. Confidential  経営・ビジネスと同じ目線を  • 自分でやり切るか？  ◦ 権限・責任を越えプロジェクトに介入して課題を解決する  ◦ ただし、時間と労力が膨大にかかる 
• 課題だけレポートして任せるか？  ◦ CTO/VPoEとしてのエンジニア組織の仕事に集中する  ◦ 経営層に課題はしっかりレポートしておく、時間はかかるかもしれないが解決する可能性はある  • 経営・ビジネス・エンジニアが相互に理解をして、同じ目線で、一丸となってプロダクトをつくっていくことにオープンロジではチャレンジしている 

©OPENLOGI Inc. Confidential  カルチャーをつくる  • オープンロジのバリュー「Active Dialogue」  ◦ 立場に関係なく意見を言い合える。他部署の議論に積極的に参加することが奨励されている 
◦ 政治や根回しが一切ない  ◦ 一つのプラットフォームを全員でつくる事業なので、壁をつくらないことが非常に重要 

©OPENLOGI Inc. 失敗その③  現状否定の方針発表 

©OPENLOGI Inc. Confidential  現状の課題をまとめた方針発表  • 新しい組織にVPoEとしてジョイン  • 最初は下記の課題があるように見えた  ◦ 負債化した自社フレームワーク 
◦ プロダクトの方向性があいまい  ◦ マネジメントと採用が機能していない  ◦ エンジニアが足りない    • 今後の方針を示すために、課題をまとめた資料をエンジニア全員の前で発表 

©OPENLOGI Inc. Confidential  VPoEとしての信頼を失う  • 賛同するメンバーも一定いたが、古株のメンバーから反発があった  • 反発があるので、メンバーが課題解決に動きたくても動けない  • 賛同するメンバーを増やすため、自分がリファラルして協力者を採用する 
• リファラルで採用したエンジニアが、周りからは坂井派閥に見え、「坂井さんが何かたくらんでいる」等の陰謀論も聞こえた 

©OPENLOGI Inc. Confidential  先人への敬意がなかった  • 過去の積み上げがあって今のプロダクト・組織がある  • もちろん課題はあるが、それは当時の制約の中での最善を尽くした結果  ◦ 立ち上げ時期は、サービスのPMF、スピードが最優先 
◦ 人員も不足しており、すべてに手が回るわけではない  • 先人の頑張りを考慮せず、課題に対して「誰も何もしてない」「戦略がない」等の否定的で責める言葉を使ってしまった 

©OPENLOGI Inc. Confidential  メンバーとの認識ギャップ  • メンバーとの課題の認識に大きくギャップがあった  • 長く同じに組織にいると、課題があることが当たり前になってしまい、課題だと感じなくなってしまう  ◦
中国のことわざ「魚の目に水見えず、人の目に空見えず」  • ギャップを埋めずにいきなり全体発表してしまった    現状の課題  認識している  課題 

©OPENLOGI Inc. Confidential  先人への敬意と1on1  • 先人が築き上げてきたことには敬意をもつ  ◦ 立ち上げ時期は大変。それを乗り越えたことがすでにすごい  ◦ 否定ではなく、承認から 
• 全体に発表する前に、メンバーと課題の認識ギャップが大きい場合は関係者を集めたMTGや、1on1を挟んで個別にギャップを埋めていく。その後、全体発表をする  • オープンロジでは、全体会、TGIF、各種定例、1on1等の社内のコミュニケーションを整理して、仕組み化して運用している 

©OPENLOGI Inc. Confidential  優秀なマネージャーを採用  • 優秀なマネージャーを採用  • CTO/VPoE/EM含めて全員が面接でA〜S評価  • エンジニア組織のネガティブポイントも伝えて、現状を理解した上で、内
定承諾  • 優秀で主体性もあるので、ミッションをすり合わせて自由にやってもらう 

©OPENLOGI Inc. Confidential  成功体験をつくらなかった  • 私の1社目が自立性をかなり求めるカルチャーの会社だったので、優秀な人は放っておいても成果を出すと思っていた  • 会社の外にでると、かなり特殊なカルチャーだった   

©OPENLOGI Inc. Confidential  なぜ放っておいてはいけないか  • マネージャーは、過去の組織でのハイパフォーマー  • 過去の組織で培った自分の成功パターンをもっている  • 成功パターンが違う組織でそのまま通用するか？ 
◦ 全く同じ組織ではないので、チューニングする必要がある  ◦ チューニングは簡単ではない  ▪ プロダクト開発の優先順位の把握  ▪ エンジニア組織内の人間関係の把握  ▪ 他部署との関係性の把握  • チューニングするのは受け入れる側の仕事 

©OPENLOGI Inc. Confidential  早期の活躍の大事さ  • 早期に成功体験をつませることが重要  ◦ エンジニアは成長を求めている  ▪ 開発者体験が良い会社にもつ印象のトップ
79%は「エンジニアとして成長できそう」  ▪ 成功体験を積んで成長したいと思っている  ◦ 成果を出すことで、周りからの信頼を得る  ▪ 信頼がないと、大きな施策が進めづらい  • 「ハイパフォーマーはストレス耐性は高いが、自分が活躍できないことへの耐性は弱い」  ※  ※（出典：一般社団法人日本CTO協会開発者体験ブランド力調査レポート2022 https://drive.google.com/file/d/1i0lpIC5WSRk4ghKSIhRFbuQR3S7uvyjH/view）

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

©OPENLOGI Inc. Confidential  失敗しても前に進みましょう  • 組織マネジメントの力は失敗して、伸びると思っている  • 経験しなければ分からない、ハードなことも多い     
• オープンロジでは過去の失敗ふまえて、エンジニア組織をつくっています  • We are hiring！ 

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

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

More Decks by Kenji Sakai

Featured

Transcript