CTOとはいったいなんだったのか
こんにちは。元クロコスCTOの sotarok です。
元というのは、「クロコス」という会社が吸収合併にされてなくなったからですね。
「CTOとはどういう人だ」という話は、ここ1−2年ホットで、定期的に話題になります。自分の元上司であるグリーふじもとさんやnaoyaさんをはじめ、立派な諸先輩方が語ってくれているところではあります。
よりまとまった話をわかりやすく聞くには彼らの話を聞いてみるというのが良いかもしれませんね。GREEのエンジニアブログとか、wadapのブログとか、WEB+DBとか。
で、まあとはいえ、CTOというのをやってみた身として、自分なりに思っていることを、自分の言葉でまとめておくことをやってみようかな、と思っていたのでせっかくなのでブログに書いてみようと思います。
ただし、はじめに言っておきますがCTOとはこうでなければいけないとか言うつもりはありません。自分が意識していることとか、こういう風に振る舞いたいなと思っているようなことです。正解・不正解のある世界でもないし、考えは変わり続けるからまた3年後あたりには違う事を言っているかもしれませんね。
きめることとか
大事な仕事を大きく3つにまとめてみると、CTOの仕事というのはざっくり言うと
- 決めること
- 推進すること
- 変えること
だと思っています。また、それを何段階か目線をあげて、
- ビジネス目線 (会社にとって必要なこと)
- エンジニア目線 (エンジニアにとって必要なこと)
の両方のバランスを取ることが重要です。
いいね、それでいこうと言う
「決めること」、というのはイメージが湧きやすいかと思います。 CTO目線で「技術選定をする」(インフラを決める、ミドルウェアを決める、開発言語を決める、フレームワークを決める...など) というのはよく聞きますし、それを決めてくれるのがCTOだ、と思っている人も多そうです。時代の流れ、会社の状況、市場環境など、複数の要因に左右される不確定な世の中で、的確な選択をし続けていくことの難しさは誰もが感じていると思います。これは重要な仕事で、とても難しいです。
また、メンバーから意見やアイデアが上がってくることも多いのですが、そこが1つのポイントだと思っていて。
実は、「こうしたら良いと思うのだけど」と言えても、「これでいこう」と言える人がそう多くありません。
- 「いいね、それでいこう」
と言えるかどうかなのかな、と思っています。
どうやって推進するか
実は「決める」というのがどういうことか、というところに、「推進」「変える」というところが含まれている、と認識すると良いのかなと。
「決める」ことは、それ自体ができても、それだけで終わらないのですよね。
なので「推進すること」は、決めたことをきちんと実行できるようにアレコレ手を打っていくことだと思います。
決めてメンバーに落としたら勝手にやってくれることもあるかもしれないし、それでうまくいかないこともあるかもしれません。
- 決めたことをきちんと推進していくこと、リードすること
- あるいは推進していくチームや仕組みを作ること
- あるいはたまにはルールを作ること
- あるいは他の経営陣を説得すること
など、必要に応じて様々やることがあります。推進する体制を構築していくことが必要です。
それはいつやめるのか
「変えること」とはどういうことかというと、一度決めたことを 変える、ということです。これも重要な仕事だと思っています。
例えばルールや技術選定など、様々な領域において「それは今も必要なのか」「それを決めた時の状況と今がマッチしているだろうか」という本質を考え、
- 廃止
- 変更
など、何かを決められる立場だからこそ、変えることもしなければいけません。多くのメンバーは、その時にイケてない現状を変えてくれるのを待っているはずですよね。
コツとしては、決めたときに「それを見直すルール」を考えておくというのが良いと思っています。例えば3ヶ月で一旦みんなに話を聞いてみる、Xヶ月に1度技術振り返りの会を開く、など。誰もが言い出せる雰囲気をいかに作るか、重要ですよね。
甘ったれない
もう一つ、自分が新人時代に、その会社を辞めるときにCTOに言われたことがあり、その言葉は今でも胸に突き刺さっていて、常に振り返る機会を与えてくれています。
「おまえは甘ったれだからな」
甘ったれ、といわれて当時の自分には理解できませんでした。「甘ったれてねーし」と。w
エンジニアリングでは正しいことを言ってるつもりだったし、それなりに新しい風をもたらしただろうし、、
まあでも、要はそういうことではなかったんですよね。
今考えるとやっぱり当時は甘ったれだったし、今はそうならないように意識していることがあります。
最後の砦と覚悟
昔、大きなバージョンの移行の仕事があった時に、自分と先輩がそれを担当してやっていました。対象となっていた事業はかなり大きな売上もあったので、障害を起こしたときの影響が大きく、その事業に関わるメンバーと連携して移行を進めなければいけなかったのですが、そのときの何かの会話で、自分と先輩に対して、上長に、
「これ失敗したとき責任どうやってとるの。」 *1
というような内容を言われたことがあるんですよね。
この時、自分は、答えに詰まってしまったんですよね。あれ、これ確かに責任とれるのか?と。
そのとき先輩が、
「責任は僕が取ります。クビにしてもらってもいいです」
と言ったんですよね。
これは極端な話だし、実際、会社は最終的にその人を守ってくれる (ことも多い) し、個人でX千万円の穴埋めをするのは不可能な話です。クビにしても多分意味がないですし。
でも要はその覚悟でやるのか、というところです。
最後の責任は誰かにとってもらいたい、という気持ちではダメだってことですよね。
CTO になって斬新だったのは、自分より上に責任をとってくれる人がいない状況を経験したことかもしれません。あの感覚は新鮮だったし、緊張感もありました。
いやもちろん、CTOになったからといって誰も助けてくれないなんてことはないですよ。チームメンバーは優秀だったし、みんなが助けてくれてなんとかできることもたくさんあります。
だけど気持ちの上ではやっぱり「最後の砦」でなければ、という意識は嫌でも身についたな、と思っています。
愚痴ってれば誰かに届くという幻想
もう1つ、
これはもうあまり多く語る必要もないんですが、愚痴を言っていれば偉い人のどこかに届いてそれがなんとなく解決されるんじゃないか、という幻想があったりします。
メンバーだったらまだ良いのだけど、やっぱり上に立つ立場の人は総じてそうもいかない、ということですね。
愚痴愚痴しているCTOの元で働きたくないですもんね。
そういう意味で、最後の砦というのは、別に単に技術的なモノのみの話ではないし、やっぱりメンタル的にもチームに良い力をもたらしたいよね、というのがあると思います。
と。そのあたりを総じて、甘ったれないでやる、ということになるかなーと今の自分では思っています。
もちろんまだまだ足りないことがあって「甘ったれ」と思われていることがあるかもしれませんが、まあ、それはそれで。。
またがんばりますw
強いチームを作る
あるときに気づいたのが、「自分がバリバリの活躍をして個人としてパフォーマンスを発揮する」ことよりも「最強のチームを作ってチーム全体のパフォーマンスを最強にする」ほうが会社にとって、成功する近道なのではないか、というところです。
自分が設計をする、コードを書く、運用をするということに対してその 1 OR 0
に関しては、正直どちらでもよくて、
強いチームを作るにあたってそれが必要ならそれをやるし、それ以外のところがより必要ならそれをやる
でしか無いと思っています。
もちろん、自分がプレイヤーとなって、それを含めてチームである、も真です。そういうやり方をする人もいます。
結局、ここ最近の自分は、しばらくエンジニアリングよりもマネジメントをやっていたわけですが、コード書くとやっぱり楽しいなーと思う一方、そこをやって他の事がおろそかになってしまうよりも、このチームでいかに成功できるのか、そこに導けるほうが楽しいとも思ったからです。
幸い、自分のチームには、同じように「チームとして強くなるためには」を考えて色々トライしてくれる人が揃っていました。おかげ本当に助けられたことも多くて感謝しかないですが。
だけど、やっぱり会社ってのはチームでやるものだし、それで「1人でやるよりも大きな成果をあげる」べきだし、それを成し遂げるためにはチームをうまく回すための人の存在は重要な要素の1つだろうな、と思うわけです。
もちろん CTO ではない人がそこをやっている会社も多く存在するわけですが、特に CTO には、開発組織に対してそういう関わり方が求められる場面が多いだろうな、と思っています。
最後に
いやーこうまとめてみると、ホント自分にできていないことが沢山あってほんとうに難しいなと思います。
一言で言うと、多分ふじもとさんの言う「技術的視点で経営にコミットする」ということなんですよね。
自分もまだまだですが、これからも自分も成長し、会社を成長させていきたいと思っています。
最後に、この場でのご報告になってしまい恐縮ですが、本日最終出社としてヤフー株式会社を退職いたします。ありがとうございました。
これからも「肉とビールとパンケーキ」をよろしくお願いします!
*1:詳細忘れましたがそんなニュアンス、ごめんなさい。あと、この時の上長を批判する意図は一切ありません、念のため