第３回目のゲストは、ニュース配信サービスを手掛けるGunosyのCTOから、グループ全体で40以上の事業を展開するDMMのCTOに転身した松本勇気さん。同社のテックカンパニー化を牽引する松本さんは、一体どんな失敗談を明かしてくれるのだろうか。就任からちょうど１年ということで、過去の話を赤裸々に語ってくれた。

早すぎる成長がもたらした「燃え尽き症候群」

文字通りに受け止めると、失敗って「目標を達成できないこと全て」ってことになるんでしょうけれど、ことエンジニアリングにまつわる失敗は、失敗のうちに入らないと思います。エンジニアが技術的な課題を前にしたときに問われるのは、“的確かつ素早く反応するアジリティー”です。

エンジニアがそのアジリティーを発揮して課題を解決すれば、自ずと経験や成長を手に入れられるので、この手の失敗はむしろ許容されるべきものであり、あって然るべき「失敗」だと思います。そもそもバグやエラー、障害の類いは、エンジニアリングに携わっている以上避けて通れません。リカバリーしてなんぼのものだと思っています。

それで言うと、前職でCTOになった2015年から約１年掛かりで乗り越えた失敗があります。私がCTOになったのは、GunosyがIPO（新規株式上場）した直後のことでした。

創業初期のころは、自然とメンバーが一丸となってモチベーション高くプロダクト開発に打ち込んでいました。誰もが疑うことなく、「ユーザーに支持されるプロダクトをつくってサービスをグロースさせよう」という明快な目標を追いかけていたのです。しかし、IPOという大きな節目を迎えた途端、徐々に組織全体を被っていた熱量や勢いが落ちていきました。

そうですね。スタートアップ界隈に明るい人なら、一度くらい似た話を耳にしたことがあるかもしれません。創業間もなく、IPOなりバイアウトなりを遂げたスタートアップが陥りがちな落とし穴です。企業としての体裁が整うよりもはやく事業が急拡大したGunosyも、その例外ではありませんでした。

そうかもしれません。IPO以降、社内のガバナンスも強化され、以前よりも売上や利益が厳しく問われるようになると、どうしてもその変化に違和感を覚える人たちが出てきます。実際、ぽつぽつと退職者も出始めました。

アグレッシブさが息を潜め、ディフェンシブな雰囲気が蔓延し始めていました。経営陣にとって最も大きな懸念は、「エンジニアのモチベーション低下がもたらす開発スピードの鈍化」です。これを早急に解決しなければ、プロダクトの開発にも影響があるばかりか、組織の崩壊さえ招きかねません。それで私がCTOとして、組織の立て直しを図ることになりました。

いえ。開発のリードはしたことはあっても、本格的な組織マネジメントの経験はありませんでした。そもそも私は当時新卒3年目のエンジニアでしたから（笑）。とはいえ、誰かが動かなければ事態が悪化するのは明らかです。自分にできることはやろうと腹を決めましたね。

先輩CTOに諭されて気付いた、仕組みよりも大事なこと

スクラム開発に知見のある渡邊大輔さん（現ヤフー）にVPoEになってもらい、彼と二人三脚で、全メンバーと個人面談を行いました。いわゆる１on１ですね。メンバーが今どんなことに悩み、何を求め、どこに課題を感じているかを把握するためです。

はい。CTO会などを通じ様々なスタートアップのCTOに、相談に乗ってもらいました。その中で最も心に残ったのが、「エンジニア受けしそうな待遇や制度づくりを先行させてしまうと、返って反発を招くかもしれない」という助言でした。

話も聞かずに仕組みや制度だけ用意されても、ネガティブの根源の解消にはつながりませんし、喜んで受け取る人はいません。「まずは、一人一人と誠実に向き合うべきだ」と助言してくれたのが、エムスリーのグローバルCTO、ブライアン（Brian Takashi Hooper）さんでした。

彼に「きっと参考になるはずだから」とお勧めされたのが、インテル創業者のアンディー・グローブさんが書かれた『HIGH OUTPUT MANAGEMENT』（日経BP）という本。ここに１on１の重要性が強く説かれていたこともあり、見よう見まねで実践してみたのです。

急成長のツケをエンジニアに背負わせていたことを痛感しましたね。例えば、それまで深夜に緊急対応してもらっても、エンジニアの負荷を減らしたり、貢献に報いたりするような仕組みは整っておらず、不満がオリのように蓄積された状態でした。

一つ一つは小さな不満でも、積み重なると大きなストレスになってしまいます。これまでメンバーの話を傾聴する機会を持たなかったことで、こうした小さな不満を見逃してしまっていたのです。

そうですね。あとは意識的に行っていたこととして、悩みや不満を拾い上げたら、その後定期的に「解決に向けた取り組みがどんな進捗状況にあるのか」を伝えるようにしました。仮に事情があって要望に応えられない場合でも、なぜ今これができないのかをきちんと説明することで、メンバーとの信頼関係を少しずつ再構築していったのです。

他にも、コミュニケーションの密度を高めるためにミドルマネジメント職をきちんと立てるなどの取り組みをした結果、以前のような熱量やスピード感を徐々に取り戻すことができました。

創業から３年足らずでIPOまで駆け上ったわけですから、組織体制の整備が後手に回ったとしても致し方ないと思う一方で、「知識と経験があれば避けて通れたのでは」という思いもあります。そもそもメンバーの話を聞くという１on１自体、特に目新しい手法でもありませんから、予兆が見える前に徹底していたら「成長痛」を和らげることができたのではないかとも思っています。

エンジニアが安心して“失敗”できる組織をつくりたい

もちろん、役に立っています。組織規模が大きくなった分、より多くのマネジャーの助けが不可欠ですが、組織の大小によってメンバーをケアするポイントが大きく変わるわけではありませんから。やはり、会社が掲げるビジョン、ミッション、バリューと個人の気持ちやモチベーション、制度や待遇などの仕組みが一本につながって、初めて組織のポテンシャルが引き出せるんだと思います。

ごく基本的なことです。会社が掲げるビジョン、ミッション、バリューと個人の評価を紐付け、定期的に１on１を行ってマネジャーとメンバー間で共有するようにしています。定量的な評価は事前に決めたKPIに基づいて判断し、定性的な評価は１on１を通じて把握するという方法です。

具体的にいうと、失敗を許容できる環境を作り細かく沢山の挑戦を促す「Agitliy」、数値をベースに科学的に判断を下しているかを問う「Scientific」、社内外にとって魅力的な組織を目指していこうという姿勢を問う「Attractive」、自分の仕事の意義を理解し仲間とともに意欲高く仕事に取り組めているかを問う「Motivative」の４項目について、毎月決めた目標に対してどれだけ近づけたかを話し合いながら確認することで、お互いの意識をこまめに評価するようにしています。

この手の話に「飛び道具」的な手法は存在しないということだと思いますね。楽しく仕事がしたい、自分の仕事に意義を感じたい、成長したいというのは、誰しも持っている願望です。会社として、こうした願望にどう対処していくかを考えていかないと「組織的負債」は溜まる一方でしょう。その解消のために必要な労力は、おそらく技術的負債を解消するよりも大きいのではないでしょうか。

これまでの経験で、取り返しのつかない失敗は、想像するほど多くないというのが実感です。完全さを求めるあまり窮屈な思いをしているなら、さっさと失敗をした方がよほど成長できるでしょう。事前にリスクを想定して対策をイメージしておけば、最悪の状況は大抵回避できますし、失敗しなければ得られない経験だってあります。失敗を恐れて何もしないより、その失敗を糧にして前に進んだ方がよっぽど建設的です。

今、私たちは３カ年計画でDMMをテックカンパニー化する計画に取り組んでいますが、私にとって最大のミッションは、「エンジニアが安心して挑戦し、失敗できる組織」をつくることなんだと思っています。

取材・文／武田敏則（グレタケ）　撮影／竹井俊晴