～「失敗」から学ぶエンジニア組織論～　CTO尾藤とVPoEの坂井が語る、組織づくりに必要なこと【イベントレポート】

こんにちは！オープンロジ採用広報担当です。
今回は、先日行われた弊社主催の「CTO・VPoEぶっちゃけトーク！　〜失敗から学ぶエンジニア組織論〜」のイベントレポートをお届け📦三

イベント内では弊社のバリュー、「Active Dialogue - 対話し、議論を通じて、解決する -」、「Positive Reflection - 振り返り、学びを得て、成長する -」に基づき、
元ウノウ・UUUM・Repro各社でCTOを経験した尾藤と元メディアドゥVPoEの坂井が過去の組織作りでの生々しい失敗経験をぶっちゃけながら（笑）、今どのように組織づくりをしているかを語りました。

今回の記事はそのイベントで語られたことをほぼ盛り込んだ、気合いの入った9000字レポートです！笑

現在組織づくりに取り組んでいて、
「どうしたらエンジニア組織の現状を経営陣・ビジネス組織に理解してもらえるんだろう…」
「ハイパフォーマーを採用したはずなのにどんどん辞めていく…」
「マネジメントを任されたけど、何を意識すべきなんだろう…」
などのお悩みを抱えている方や、
純粋にオープンロジのマネジメントメンバーがどんな経験をしてきて、今どんなことを考えているのかが知りたい方は、是非記事を最後までご覧いただけたら幸いです😊

それでは、Let’s Go～！！🏃

💡この記事でわかること
・オープンロジのCTO、VPoEが経験してきたマネジメント関連の失敗と、そこからの学び
　→炎上プロジェクトが立て続く原因
　→経営層やビジネス組織との溝とその埋め方
　→ハイパフォーマーが早期退職する原因とその防ぎ方
　→組織マネジメントのために意識すべきこと

登壇者

尾藤 正人 （@bto）　株式会社オープンロジ 執行役員 CTO
大学在学中にVine Linux SPARC版を開発。卒業後IPA未踏ユースソフトウェアに採択。（Zynga Japan）ウノウ株式会社の初期メンバーとして参画し、CTOを4年半務め、2011年に株式会社スングーラ代表取締役社長就任する。2015年からUUUM株式会社のCTOとして未上場からIPOまで牽引し、2021年6月にはRepro株式会社の執行役員CTOに就任。 2022年8月に株式会社オープンロジに入社。2023年2月、同社CTOに就任。その他、個人で技術顧問、エンジェル投資、未踏ジュニアPMなどに従事する。

坂井 健治 （@saka0ken）　株式会社オープンロジ 執行役員 VP of Engineering
慶應大学卒業後、ワークスアプリケーションズにてECサイトのパッケージソフトの新規開発や運用保守を担当。4年目から新製品の開発マネージャーとして30人の組織のマネジメントに従事。2017年にメディアドゥに入社。VPoEとして100名のエンジニア組織のマネジメント・採用に携わる。 2021年7月にオープンロジ入社。VPoEを務める。

当日のアジェンダ

19:15~19:30 開場（オンライン）19:30~19:40 オープニング19:40~20:00 坂井による「失敗から学ぶエンジニア組織論」20:00~20:20 尾藤による「CTO奮闘記」20:20~20:40 QA20:40~20:50 クロージング

VPoE坂井の「失敗から学ぶエンジニア組織論」

失敗事例その①：原因が特定できず、繰り返された炎上プロジェクト

当時私はプロジェクトの立て直しが得意でした。実際に一年半リリースが遅れた開発プロジェクトを半年でリリースまでもっていくなど、プロジェクトの立て直しをしては次のプロジェクトへ、という形で転々としていたのですが、

結果、ずっと炎上プロジェクトがなくならず、エンジニア組織も私も疲弊して耐えられなくなりました。

その後、炎上プロジェクトがどうして無くならなかったのか振り返ってみると、
「プロジェクト単位での失敗ではなく、経営レベルでの意思決定に原因があったのでは」と考えています。

（例）
・現場の実状とかけ離れた新技術の全社導入
・開発途中の大規模社内フレームワークの全社導入（フレームワーク自体のキャッチアップのコストやバグ発生時の影響度が全社レベルになってしまう）

→どれだけプロジェクトを改善して、エンジニアを増やしても開発が遅れ続けてしまう…
→プロジェクト単位が原因ではないので、再発し続ける…

この経験をふまえ、私は「健全な組織」をつくりたいと思い、
「健全な組織」をこう考えるようになりました。

【健全な組織とは】
・CTO/VPoEが経営層にいて、できること/できないことを明確に経営に説明し、エンジニア組織の力を超過した開発をしない
・ビジネス・開発の信頼関係がある状態にする

失敗事例その②：経営層との視点の違いに気づかず、煙たがられる

事例①のように、エンジニア組織の課題の原因が経営層とビジネス側にあることはよくある話だと思います。

とあるプロジェクトで、エンジニアのモチベーションが下がっていました。
原因を確認した所、「開発したサービスが使われていないから」ということがあったんですね。
そこでどうしてそうなってしまったのかを考えてみると、「そもそも事業方針が間違っているのでは？」ということが上げられました。

私はそれを解決しようとして事業側の人や経営層にもMTGの時間をもらって課題を説明したりしたのですが、結局煙たがられて終わってしまったんです。かなりの労力と時間を使ったのに課題も解決されなくて…

振り返ってみると、「経営・ビジネスとの視点の違い」があったと思っています。

【経営・ビジネスとの視点の違いとは】
・経営層や事業部長は、エンジニアとは違った視点でサービスを見ている（株主、投資家からの意見、中長期の成長計画、予算計画etc…）
・サービスは成長しないかもしれないが、別の視点では正しく見える

私自身も執行役員としてやってきて分かるようになりましたが、この時私は
「事業側・経営層とも目線を併せる必要があった」んですね。

私たちもプロダクトを開発してる時に全く関係なさそうな立場からこうですね、と言われるとイラっとすることがあると思います。
事業側や経営層としても、頑張って立案・調整して合意をとった戦略や計画があったはず…

オープンロジでは経営・ビジネス・エンジニアが相互に理解をして、同じ目線で一丸となってプロダクトをつくれるよう、尾藤や私が一緒に経営層へエンジニアのことを説明したり、ビジネスやドメイン知識のキャッチアップをしたりして調整をしています。

また、その中でも重要だと考えているのが「カルチャーをつくる」ことだと思っています。
オープンロジは一つのプラットフォームを全員で創る事業であるため、壁を作らないことが非常に重要です。
オープンロジには「Active Dialogue - 対話し、議論を通じて、解決する - 」というバリューがあり、立場関係なく意見を言い合える・他部署の議論に参加することが推奨されるというカルチャーが浸透しています。

このカルチャーが浸透していることもあり、社内政治や根回しが一切ありません。やりたいことに集中できている、という感覚があります。

失敗事例その③：先人への敬意「ゼロ」な現状否定の方針発表

過去、私が前職にVPoEとしてジョインした時のお話です。
入社した当時、組織には色々な課題がありました。負債化した自社フレームワーク、プロダクトの方向性が曖昧、等…

それを踏まえ、課題をまとめた資料をエンジニアの前で発表したところ、VPoEとしての信頼を失いました。

発表した課題に対して賛同してくれるメンバーは一定数いたのですが、古株からかなり反発を食らったのです。先人たちへ持つべき敬意が足りていなかったわけですね。

【先人へもつべき敬意】
・過去の積み上げがあって今のプロダクト・組織がある
・課題はあっても、それは当時の制約の中で最善を尽くした結果。
　立ち上げ時期は、サービスのPMF、スピードが最優先。
　人員も不足しており、全てに手が回るわけではない。
＝それを乗り越えたことが既にすごい。否定ではなく、承認から。

メンバーとの認識ギャップもあったと思っています。
長い間同じ組織にいると、課題だと思うことが当たり前になってしまって課題だと感じなくなることがあります。
そういう認識のギャップを埋めずにいきなり全体発表してしまったのも、失敗した点でした。

この経験からオープンロジでは、全体会やTGIF、各種定例、1on1等のコミュニケーションを整理、仕組化してギャップが起きないように運用をしています。

失敗事例その④：釣った魚に餌やらず、退職

とあるタイミングで、CTO、VPoE、EM含めた全員が面接で高評価を付ける優秀なマネージャーを採用できたことがありました。もちろんエンジニア組織の現状を理解してもらい、ギャップが無い状態で内定承諾していただきました。

ただ、結果その方はあまり活躍できずに１年程度で早期退職となってしまいました。ポテンシャルはあって優秀だったはずなのに…

これを振り返ると、彼らに成功体験をつくってあげられなかったことが原因だと考えています。

マネージャーは過去の組織でのハイパフォーマーです。過去の組織で培った自分の成功パターンは持っていますが、その成功パターンが違う組織でそのまま通用するわけではありません。チューニングの必要があります。ただ、そのチューニングは簡単ではなく、チューニングのために様々な情報を把握する必要があります。

チューニングするのは受け入れる側の仕事です。
個人的に弊社のCFOから言われてそうだな、と思ったことがあります。それは

「ハイパフォーマーはストレス耐性は高い。ただ、自分が活躍できないことへの耐性はすごく弱い」ということ。

【早期の活躍の大事さ】
・エンジニアは成長を求めている
　→成功体験を積んで、成長したいと思っている
・成果を出すことで、周りからの信頼を得る
　→逆に信頼が無いと、大きな施策が進めづらい

オープンロジではしっかりとオンボーディングを設計しています。
計画をつくり、メンターやトレーナーがついたり、勉強会を開催したり、オンラインランチを開催したり。
色々な方向で早期活躍を支援するようにしています。

CTO尾藤の「CTO奮闘記」

失敗事例その①：正論を振りかざし、人望を失った1回目のCTO時代

初めてCTOになった時、私は世間知らずで結構とがっていました。笑
周りの失敗やミスを強く責めたり、正論を振りかざしたり…
当時は自分でもガリガリ開発をしていたこともあり、マネジメントはほぼやらず、実質テックリードのような感じでした。
当時は自分が正しいと思っていたし、周りが上手くいかなかったら周りが悪いとずっと思っていて。

ただ、その会社を辞めた後に振り返って考えてみた時、
自分のそのスタンスが原因で人望を失い、人が自分から離れていったのだということを感じました。

私は、非常に深く反省をして、アンガーマネジメントに着手をしました。
怒らないように自分をコントロールすることは実はそんなに簡単ではなくて、5~6年はかかりましたね。
やっぱり怒って損することはあっても得することってほぼ無くて、
やっても意味がないことはしないようにしていかないといけないですよね。

失敗事例その②：ビジネスサイドとの大きな溝を作ってしまった2回目のCTO時代

2回目にCTOになったときは、しっかりマネジメントに向き合いました。
結果ここでのマネジメントはうまくいったと思っています。当時の会社は営業が強い会社でしたが、かなり技術力の高い組織をつくれたのではと思っています。

ただ、開発組織の立ち上げはうまくいったのですが、徐々にビジネスサイドとの溝が大きくなってしまいました。

エンジニアの技術的な事情を理解してもらうのが難しくて、独立国家のようになってしまったんです。エンジニアにとってはいい環境であっても、結局事業に対して貢献できていなければ意味がありません。ビジネスサイドとエンジニアサイドがタッグを組んでいくことが非常に重要だなと痛感しました。

とはいえ、ここで得られたものは非常に大きいものでした。
スキル的な所で言うと、この時期に初めてちゃんとマネジメントに向き合ったので、マネジメントを軸とした組織の立ち上げと運用はほとんど身につきました。
非IT系の職種との向き合い方やコミュニケーションのとり方も、失敗を積み重ねながら身に着けていきました。

スキル＝良質な成果を一定の再現性をもって出せる能力

ちなみに、ここで自分自身が大きく成長できたとお伝えしましたが、そもそも成長するにはそれなりのやり方があると考えています。

私は成長とは
・スキルを身に着けること
・できないことができるようになること
だと思っています。

では、スキルとは何なのか？
私は「良質な成果を一定の再現性をもって出せる能力」だと考えています。

例えば良質な成果＝ホームランなら、
これが1000回に1回打てたらまぐれですよね。
10回に1回打てるようになれば、スキルだと思います。
要は、良質な成果を出すだけではなくて、それが一定の再現性をもって出せるかどうかが、スキルだと思っています。

ここで問題：出力を安定させる（スキルを得る）ためには

唐突ですがこれは何でしょう？笑

正解はRSフリップフロップというものなんですが、
とある婚活アドバイザーによると、ITエンジニアの将来性が知りたい場合はこれを理解しているか聞くと良いそうです。要は計算機科学（基礎）を理解していない人は将来性が…ということですね。笑

（それがどこまで本当かどうかは別として笑）

簡単に説明すると、SRというのが入力、Qが出力でQ＋が入力に対しての出力の変化です。 上の二つ、SとRに何も入力が無い状態、この時はすべてのQが０でも１でもずっと０と１の状態を維持するんですよね。 真ん中をみると、R＝リセットに１が入ると現在の状態が０か１でも、必ず０が出力されます。 最後に、セットに１が入ると現在の状態０でも１でも必ず１が出力されます。

何が言いたいかというと、これは１ビットメモリなんですよね。
Sをセットすると１ビットセットされて、
Ｒをセットすると０が保存されて、
何も入力されないと今の状態が保存されます。
上の論理回路の出力が、下の難路回路に入力されていて、
下の論理回路の出力が、上の難路回路に入力されています。

論理回路を設計する時に、出力を入力する解が非常によく使われているのですが、
なぜこういうことをやっているかというと、
“出力を入力させる”ことで、“出力を安定させる”ことにつながるから
なんですよね。

制御回路の基本的な構造って、究極に簡略化すると、

「何らかのデータに対して処理をすると結果が出る、
その結果を安定的に出すためには出力を入力にフィードバックする必要がある」

これが制御回路の基本的な考え方です。

なので、スキルを身に着けるためには何が必要かというと、

・実践してみる
・実践した結果を振り返り、分析する
　→うまくいったことや行かなかったことを言語化し、自分の引き出しのなかに入れておく
・再度修正した内容を実践し、再現性を上げていく

これは世の中的には経験学習と呼ばれていますが、経験学習が本当に実践できている人は実は少ないと思っています。

経験学習で得たスキルを活かした、3回目のCTO

2回目のCTOで経験学習を通してスキルを身に着けて、3回目のCTOになりました。
ここでの開発組織は既に一定の規模のものでしたが、これまでの学びを元に、再現性高く組織を作ることができました。

組織開発はシステム開発と似ている

私は組織づくりをする時、システム開発の考え方をかなり取り入れています。

・単一責任の原則
・SPOFの解消
・共通処理のモジュール化
・フレームワークの導入　etc…

ただし、組織づくりする時とシステム開発する時の決定的な違いというのもあって、

コンピューターは書いたプログラム通りに動きますが、
一方で人は思うように動かないんですよね。

逆に捉えると、「チームのメンバーを上手くマネジメントすることができれば、システム開発のノウハウが組織づくりに応用できるはず」です。

マネジメントのために意識していること

その①：視覚的に、直観的に

じゃあどうしたらチームのメンバーに動いてもらえるのか？ということですが、
そもそも人の脳みそは私はバグっていると思っていて（笑）
人間の進化の歴史の中は狩猟民族としての文化が圧倒的に占めていて、基本的に生き残るために視覚的にかつ直観的に短時間で物事を判断するようにできているんですよね。

要は、論理的に考えてるように思えて実は論理的に考えられていることはかなり少ないはず、ということです。
なので、まずは視覚と直観に訴えるための資料作りや情報のインプットが必要だと思っています。

その②：認知バイアスをうまく活用する

それから、私は物事を進めるときに「損失回避バイアス＝不確定状況下において、損失を回避する意思決定をする」というのをよく使うんですけど、
要は私が相手に何か判断してもらおうと思った時には、相手に対してメリットも示すけど、デメリットも示すようにしています。

これをうまく活用すると、物事がかなり進めやすくなります。

その③：説得には2つの腹落ちが必要

また、人を説得する時には一つの腹落ちが必要という話もあります。

坂井さんの失敗談に否定的な言葉を使って感情的な反発を食らった話がありましたが、人に対して何か説得をするときは論理的な腹落ちと感情的な腹落ちの二つを満たす必要があります。

論理的な腹落ちだけ求めても、感情的に納得いかなければ反発が起きて物事が通らないですし、感情的な腹落ちだけを求めても感情論にしかならないので納得してもらえません。
どんなに正しいことを言っていても相手の感情をケアするようなコミュニケーションをとらなければ絶対にうまくいかないので、何か話すときは両方をみたしているかどうかというのを必ず考える必要があると思っています。

まとめ：組織づくりのために意識すべきこと

まとめとして、私は

・視覚や直観に働きかけるための資料作りや情報のインプット
・相手にとってのメリット・デメリットの提示
・論理的腹落ちと感情的腹落ちを意識

こういうことをすると、組織を上手くマネジメントできるようになると思っています。

そして、人を上手くマネジメントすることが実現できれば、システム開発組織の知識を応用して、組織づくりを進めることができます。

私が組織づくりをするときはこのような感じで進めるようにしています。

質問コーナー

※今回はいくつか頂いたものの中からピックアップしてお届けします🎁✨

Q.　オープンロジではCTOとVPoEのすみ分けはどのようにしていますか？

坂井「一般的なすみ分けですね。組織、特に採用は私（VPoE）が担当で、技術の方は尾藤さんが担当しています。」

Q.　マネジメントではないエンジニアとして、組織がダメに感じたら辞める以外にできることは何かないでしょうか？

尾藤「一言で回答するのは難しいですが、”自分が良い状態に変えられる環境なのか”は一つポイントとしてあると思います。変えられるやり方があるならトライしたほうがいいですね。
トライすることによって自分自身も経験できますし、新しいスキルも身につく可能性があります。自分が改善に寄与できるのかの観点で判断するのはいいんじゃないかと思います。
できる範囲でやってダメだったら辞めて違う会社に行くのがいいんじゃないでしょうか。」

Q.　ハイパフォーマーを採用する際は選考時に再現性を見る、ということをたまに聞くのですが、受け入れ側のチューニングとのバランスをどうやって考えているか知りたいです。

坂井「可能な限り再現できるかはエンジニアだったらコーディング試験をしたり、技術的な質問をしたりしてはかります。マネジメントでも実際にエンジニア組織の課題を並べて見せて、どういう優先順位で、とか、ディスカッションをしてみて再現性があるのかを見ます。

ただ、その人と実際は一緒に仕事をしているわけではないので、全く同じ環境を体験するのは限界があると思います。なのでできる限りの再現性の部分は見て、あとは受け入れてから、責任をもって面倒を見る、ということだと思います。」

Q.　技術的な実現方法について、エンジニアに任せるべきかCTO（またはマネージャー）が判断すべきかの判断基準があれば教えてください。

尾藤「私は、原則任せればいいと思っています。最終的な責任を自分が持てばいいので。

技術選定をする時であれば、技術的な実現方法もそうですが、あまりにも最先端すぎて攻めた内容になっているとか、その技術が5~10年メンテナンス性高くいることができないとか、そういう風に大きく外さなければOKという基準で判断していますね。」

Q.　根回しや政治が無い組織はどうすると生まれるのでしょうか？

坂井「私が思っていることは2つで、

1つはカルチャーですね。弊社のActive Dialogueのように、何か形式主義的ではないオープンな場をつくれる何かを設けて、それを浸透させていく。
2つ目はそれ以前の話で、権威主義的な人を採用しないことですね。そういう人がいると根回しが蔓延してしまうので。

オープンロジの場合は社会に貢献したい人が多いです。必然的にそういう志向の人は自分が良ければいいみたいな行動をしないので、目線が合いますね。なのでそういう人を採用しています。」

Q.　正社員と業務委託のメンバーで価値観や価値観や意識のずれがあったりすることはありますか？また、ずれを生じさせないためにはどのような取り組みをされていますか？

坂井「正社員と業務委託はそもそものモチベーションのポイントが違うので、価値観や意識のずれがあることを許容してあげることが必要かなと思います。」

尾藤「私は正社員とか業務委託の枠組みは関係ないと思っています。価値観や意識のずれがあることも問題ではないかなと。

人それぞれ価値観や意識が違うのは当たり前の話だし、結果が出ていればそれはそれで問題ないともいえると思います。価値観の違いや意識の違いを受け入れることが多様性だと思っていて、違いをうまく吸収して、どうやったら会社に対して貢献できるのかの方法を考えるのが建設的だと思いますね。」

結び

いかがでしたでしょうか？

イベント中に呟かれた「#OPENLOGI_Techtalk」には
「『気づいていないことに気づけない』は深い」
「『ハイパフォーマーはストレス耐性は高いが、自分が活躍できないことへの耐性は弱い』が金言過ぎる」
「先人へのリスペクトめっちゃ大事」
などの反応もあり、参加された皆様に有意義なお時間をお届けすることができた様子✨

この記事の内容も、皆様にとって良いインプットとなることを願っています😊

そして、今回のイベントに登壇したVPoE坂井とCTO尾藤は、この学びを元に、現在のオープンロジの開発組織をより良くしてくれています。
内容を見て、彼らの組織づくりや今後の組織にご興味をお持ちいただけた方、一緒にエンジニア組織を盛り上げたいと思ってくださった方、純粋にオープンロジにご興味を持って下さった方は、尾藤や坂井とのカジュアル面談もWelcomeです！！🌟

是非、弊社👉採用ページ👈または　話を聞きたい　より、お気軽にご連絡下さい📝
※メッセージ内に「ぶっちゃけトークの記事を見た！」と記載いただけると嬉しいですm(__)m

皆様からのご連絡、お待ちしています！🎁