GREE Engineering

CTO15年やってみた (その2) -大事にしている7つのこと-

CTO15年やってみた (その2) -大事にしている7つのこと-

ごあいさつ (読まなくてもいい前置き-1)

みなさまこんにちは、グリー株式会社でCTOをやっているふじもとです。実はそのかたわら日本CTO協会略してCTOAというところの理事をやらせていただいているのですが、勢いで「CTOでAdvent Calendarやろうぜー」と言い出してしまい、まぁ言ったからには1日くらい書くかー、後半にしておけば (おそらくそれまでに何日か書き忘れがあるだろうから) まぁ最悪書けなくても平気だろうと本気思っていたんですがなんと今日にいたるまで毎日継続しております、みなさんすごいー、すごすぎるー。

ということでこれは、CTOA Advent Calendar 2020 20日目のエントリです。僕のはともかく、他のみなさまの素敵なエントリが並んでいますので、ぜひぜひご覧ください。

大事にしていること? (読まなくてもいい前置き-2)

CTOとして何をすべきか、問題に対してどうアプローチすべきか、というようなことは本当に最近よく書かれるようになったと思いますし、少なくとも過去相対では成熟してきていると勝手に思っている昨今です。しかも文章はみなさんのほうが上手だし、ってことでぼくのエントリではもうそういうテクニカルというかプラグマティック (という言い方が正しいかどうか分かりませんが) なほうではなく、抽象度が高いほうに思いっきり振り切って書いています。

表題の通り、曲がりなりにも、いやもう曲がってばっかりですが、15年間CTOをやってきて、これは大事にしている、しなければならないと気づいた、将来はわからないが今はこういう考え方をすることが大事である (と思っている)、ということをつらつらと書いてみるわけですが、正直読んでいるみなさまの何のお役にたつかはわかりません。言い換えれば一般に価値がある、ということが何かで証明されている話でもないので、あーそういうやつもいるんだね、くらいに考えていただければと思います。いずれにせよ、5年後くらいには「あーまだまだだったねぇ」と思えるように (言い換えればちゃんと成長しているように)、これからも前に進んでいければと思う次第です。5年後の自分げんきー?

1. 戦い続けること

戦い続ける、とかのっけから大袈裟にすぎまることを書いてますが、インパクトも大事だよね、ってことで少し攻めた言葉遣いにしてみました。

これは別に、常にあっちこっちにけんか売りましょう、ってことでは全くなく、自分が関わる全ての仕事において、自分が最後は絶対に何とかする、という意思、矜恃を持ち続けましょう、というだけのことです。逆に言えば、自分以外の全てのメンバーは、やりたくなかったり、無理だと思ったり、本当にしんどかったらいつでもギブアップする自由があるわけですし、というかむしろそんな状況で無理して何かしていただくのもだれも幸せにならないので、そういうときに、「じゃぁまぁあとはあいつが何とかするだろう」と思ってもらうようにする、というのは自分にとっては結構大事なことな気がしてきたので書いてみました。まぁ「何とかする」というのは別に美しく問題を解決するだけではなく (そうであることを望みますが)、場合によってはプロジェクトをシャットダウンしたり、方々謝罪して回ったり、などなども含んでいたりするわけですが、いずれにせよ、最後はなんとかするんでチームのみんなにはある種安心して働いていただきたいものだなーと思うわけです。

ただし、この考え方は極めて危険だとも思うので、間違っても他人に強制するとか、他の人もこうあるべき、とかならないように、という1点についてはとても注意深くあるべきだと思います (ぼくも、自分がこう考えています、というだけで、他のCTOもみんなこうあるべき、とか全く思いません、いやほんとに)。

最悪のケースを考える練習をしておく

で、合わせて関連するところで、なんですが、ぼくはたまに (頻繁にやってると心が疲れすぎるので)、ものすごく辛い事件が起こったときのイメージトレーニングとかをやるようにしています。例えば、プロダクション環境のデータが全部いきなり飛んでいってしまった、とか、超大規模なセキュリティ侵害があった、とか、人がいきなり9割がたいなくなってしまった、とか、まぁとにかくすごく辛そうな事象が起こったとして、じゃぁどうするか、ということを考えたりするわけです。

当然のことながら想像するだけでしんどいわけなのですが、一方で実際に何かが起こった時よりは、同じく当然楽なわけなので、冷静にそういったとき自分がなにをすべきか、どうあるべきか、ということをシミュレーションしておくことができます。まぁほんとにひどいことが起こったときは、ある種どうしようもない、ということもあるわけですが、じゃぁ「どうしようもないその先はどうなっているのか?それをちょっとでもマシにするためには何かできることがあるのか?」とかもあるわけですし、何より大事なのは、大変なことが起こったとき、起こっているときに、トップの人間が凹んでいたり動揺していたりしても何もいいことがない、正直時間の無駄なので、そういったときに冷静に、やるべきことができるように、という練習はやっておいて損はないなーと思うのです。

あと、こうやって考えておくと、まぁある側面から見ればものすごく大変だけど、大体のケースでは最悪といっても0からスタートし直しだな、というところなので、ある種の開き直りが大事だね、みたいな心の準備ができるようになる、気が、します。

ということで、日々なんとなく不安を抱えて過ごしていても仕方ないですし、一方で、まぁ長くやっていれば、想像を超えるような大変なことがあれこれ起きるわけでして、楽観的に過ぎるといざというときの対応が覚束なくなってしまいます。ので、こういったシミュレーションを通じて「そういうこともあり得る、けど、いざとなったらこうすればよい」という心持ちで日々の仕事に当たることが大事なのではないかと思う昨今です (もちろん、ある程度の確率で想定される事象に関しては、こういった個人でのシミュレーションではなく、ちゃんとチームとして避難訓練的なことをしておくのが大事なのは言うまでもありません)。

あと、大変なほうばっかり考えていると心の健康によくないので、あれこれめっちゃうまくいったらこうしよう、ああしよう、というほうも合わせて考えておくのも、実のところ結構大事なのでは、と思っています。

2. 構造的に問題を解決すること

立場上、多くの仕事が問題を解決することだったりするのですが、そのとき気をつけていることが2つありまして、1つは「誰にとってのどういう問題を解決するのか」ということ (詳しくは「ライト、ついてますか」をご覧ください)、そしてもう1つは (とりあえずその問題を解決、解消するのはそれとして) 「なぜその問題が起きたのか、どういう構造によってこの問題が発生しているのか」ということを考えること、そしてできればそれについてもアプローチすることです。

おそらく一番分かりやすいのは、いわゆるサーバオペレーションとかで、なんらかのオペミスがあったときに、「じゃぁ次は気をつけよう」とか言っても人間なんてミスするに決まっている生き物なのは誰もが知るところなので、人を責めたり、精神論な方向にいってもまた同じことが起こるだけなのは皆様日々お考えの通りで、なのでじゃぁ、よりミスが発生しにくい計算機に少しでも多くの仕事をしてもらおう、チェックをしてもらおう、というほうが余程健全だと思うわけで、まぁこれについては誰もが知るところだと思います。

一方で、例えばチーム間でなんらかの問題が発生した場合に、その問題を例えばお互いの認識を合わせる、コンテキストを理解してもらって落とし所をどうこう、とかいうコミュニケーションはしばしば行われるわけですが、これも同様に、そこで話が終わればまた同じことは起こるので、じゃぁ組織のあり方、お互いのインセンティブ設計、インタラクションの方法、などなどの構造にもちゃんと考えを向けて、よりマシなやり方を考える、実行する、ということが大事だと思うわけです。

で、このとき何より大事なのが「一気に全てを解決できると思わない」けど「ちゃんと積み上がる方法で問題を解決する」ことを忘れない、その認識をみんなで持つ、ということです。多分これはアメリカのソフトウェアな企業なひとたちと働いて得られた知見というか、違いの認識というか、なのですが、とにかく彼らはそのあたりの意識がすごく強い印象で、自分にすごく足りていなかったものだと当時思わされたことを覚えています。この考え方は、特にソフトウェアに携わる仕事との親和性がとにかく高いので、少なくともぼくらにとってはとても大事だと考えるわたくしでございます。

3. セオリーを大事にすること

お仕事をしていく上で、技術的なこと、組織的なこと、経営的なこと、多くの課題に直面するわけなんですが、考えてみれば当たり前のことですが類似した課題は過去に世界のだれかが解決してきた可能性が高いわけです。

もちろん細部は異なる (何もかも同じである、という問題なんてそれはないわけでして) のですが、それでも自分だけの力であれこれがんばるその手前に、先人の知恵をちゃんと拝借した上で、解決方法について考えることは自分にとってはとても大事です。自分1人でいくら考えようが、過去多くのひとが積み上げた知見のほうが有用なのは当たり前のことです…なはずなんですが、特にマネージメント関連の話題になると、ひとはどうしても (技術的な問題のように) フレームワークだったり、セオリーだったり、みたいなほうに行かずに、やれ「人間力」だの、みたいな話になったりしがちです。

もちろん、人間が関わる話なので、最後そういった要素は欠かすことのできないものではありますし、じゃぁマネージメントに書かれた本、論文、それらをそのまま実行してうまくいくのか、とか、自分のケースはこういう違いがあるからそんなうまくいくわけないだろう、とかあるわけですが、それでも、可能な限り先人の知恵を学び、その上で自分としてこうする、という考えを持って事に当たる、というのは、なんだからわからないが何とかする、みたいな積み上がらなそうなアプローチよりも良いと思うのです。それはシンプルに、1人で考えられることなんて多寡が知れているのでちゃんと歴史を学ぼう、ということと、なんらかの形式をもった考え方で事に当たらないと、うまくいかなかったときに反省、改善することができないからです。

4. 学び続けること

前述のお話とも関連する、というかまぁ当たり前の話すぎてあまりこれについて書くこともないのですが、1つだけ、どうやって学び続けるか、ということだけは見失わないようにする、という点について少しだけ書いてみます。

これはいわゆるお勉強方法、とかではなくむしろ、自分はどうやったらサボるか、あるいは逆にどうやったら図らずもお勉強してしまうか、ということを知っておくのは大事なのではないか、ということです。なんでなら、少なくともぼくは油断するとすぐ易きに流れる、ほっとくと楽しいことしかしない人間だということを重々承知しているからでございます。

で、ぼくの場合はとにかく危機感を煽るのが大事で、このままだとやばいよ、ということを思うきっかけを何らか用意したり、あるいは、多少自主的なところとしては、「以前の自分結構いいじゃん」とか思い始めたら本当にヤバイ、と思うようにしてます。過去の自分が良いと思えるってことはそっから進歩してないだけな可能性が結構高いですからね。

5. 細部をイメージすること

CTO的な (とかそういう) 立場だと、例えば意思決定だったり、全社に影響が及ぶような仕組みを作ったり、みたいなことが多くあると思うのですが、というか、別にCTOとか関係なく自分が起こす行動というのは多くの場合他人に影響を与えると思うのです。で、そういうとき、例えば何かを全社にアナウンスするようなとき、可能な限り事前に「このひとはこういう風に受け取るだろうな」「このチームにはこういう形で伝わるだろうな」みたいなことを考えておくようにしています。

合わせて、その結果こういうことが起こる、こういう影響があるだろうな、というところをなるべく具体的に、細部までイメージしておく、ということを割と常に意識しています。あれです、細かく把握して大きく決断、ってやつで、これは考えてみれば当然必要なことで、なにかを伝える、なにかを変える、ということは必然自分として望む結果があるわけなので、本当にそういった結果になるのか、想定していない別の問題が起こらないか、トータルでのROIは合うのか、ということを考えておかないと、たどり着きたかった場所とは全然違うところに行ってしまう、ということが発生しやすくなってしまうと思うのです。

もちろん、そういったことを考えたからといって、常に全員が満足するような意思決定、仕組みづくりができるわけもないというか、そんなこと考えていたら多くの場合なにもできずに、より悪い結果を引き起こすだけなのですが、それでも、そういったネガティブな影響もある、その側面もできるだけ正しく理解した上でものごとを進めることは重要です。

…と、そのためには割と普段から、会社全体を見渡して「あの人はこういう人だな」とか「あのチームはこういう状況だな」ということを知っておく、認識を更新し続ける、というのが結構大事で、いやもう最近は人も増えたしリモート多いし、とかでなかなかハードルはあるのですが、めげずに続けていこうと思う昨今です。

とか書いていますが、まぁそんな毎回うまくも行かないので、これに加えて (特に想定していない方向へ行ってしまったとき、想定していないレスポンスがあったときは) フィードバックを元に自分の考えだったり、「自分が持っているみんなの認識」をちゃんと改めたり、あるいは自分として伝えたいことを違うやり方で (例えば文章ではなく言葉で) 伝え直したり、という修正を行い続けるのもまた大事です。

何にせよ、「ちゃんと事前に考えておく」そして「結果との差分を元に反省する」ということをしないと進歩もないわけなので、より高い精度で仕事をするために、未来にもっと上手に仕事ができるようになるために、自分としては結構大事なことなのではないかなーと思っています。

6. 手を動かすこと

まず何より楽しいですし、というとお気楽な感じがしてしまいますが、この仕事をしている以上、なにがどうなってもものをつくる楽しさ、というのは忘れたくないし、忘れてはいけないと思うのです。その楽しさのポイント、とかは時によって、人によって色々で、とにかくできるのが楽しい、新しい技術を学ぶのが楽しい、なんか動いているのが楽しい、なんでもいいんですが、ぼくにとってはこれが全ての出発点なので、これを忘れたら何も始まらない、あるいは全てが終わるんじゃないかと思うのです。

それ以外にも、前述の通り技術的側面を持ったなんらかの意思決定をするときに、そこに影響する要素をできるだけ低い抽象度で理解しておくに越したことはないですし、それは上手な意思決定にはやっぱり欠かせないものだと思うのです (一方で、全てを把握して、全てを理解して、というのも現実無理なことがほとんどなので、このバランスはとる必要があるのですが、そのあたりの話はここでは割愛します)。

と、やはりエンジニアの矜恃として、「こういうもの作りたいよねー」と思ったときに、まがりなりにも、ちゃんとモダンなやり方で (慣れたやり方に固執しないで) それを実現できる、という状態であり続ける、というのは大事にしたいと思っています。が、しばらくコード書かないでいると、徐々にその解像度や自信がぼやけていってしまうので、ちゃんと自分で手を動かし続けておく、という努力は必要なのだと思うのです、そもそも楽しいですし。

とはいえ日々忙しいとこういった活動がおろそかになってしまうので、ハッカソンにとりあえず参加することにするなりなんなり、自分を追い込んでしまうのがよいと思います (この間「独学大全」を読んでから、自分の意識とか努力でどうこう、とかはもうさっさと諦めて、環境によって自分の行動を規定する、ということだけ考えるようにしています)。

そして無駄に白状しますと、ぼく半田付けが死ぬほど苦手でして、そのせいで若かりしころハードウェアに挫折して以来どうにも苦手意識があるんですが、もう大人になったし世の中めっちゃ便利になったし、ハードウェアも楽しく作れるようになりたいなーと思うのです。

7. 誠実であること

まぁ誠実ってなんだって話なんですが、個人的には天網恢々疎にして漏らさず、というかお天道さまはみている、ということに尽きるんじゃないかなーと思います。

お仕事をしていると、時にすごくシビアな、間違っているかもしれないけど楽な道がある、というような場面で決断をしなければいけないことがあったりします。こういうときにこそ、魂の本質が問われるということで、きちんと立ち止まってチーム、ユーザのみなさまに恥ずかしくない振る舞いをする、ということが大事なんだとこの15年で身に染みました。こういうのって、言うのは簡単なんですが実行するのは本当に難しい、その難しさを知ることができたのは (多くのご迷惑をおかけした上でのことなので申し訳ないです、が99%なのですが) ありがたいことだと思っています。

などと書くととても意識が高い、というような話にもなるんですが、もちろんそういうモチベーションでもいいですし、あるいは、より現実的に、そうしたほうが得なのである、ということを心に刻む、という考え方も非常によいと思います。

なお、蛇足ではありますが、本当に迷ったときは「Scent of a Woman (邦題: セント・オブ・ウーマン 夢の香り)」という映画を見ることにしています。これは本当に良い映画で、特に終盤のスピーチのシーンは圧巻です。

補遺 -足りないと思っていること-

などと偉そうにあれこれ書いてみましたが、一方足りないことなんてありすぎて無限に書き続けられそうです。が、特にそのなかでここ数年とにもかくにも課題だと思っているのは、(言葉にすると難しいのですが、無理やり書くとするなら)「何か新しいことをやってみる」というような能力です。

これは、もともとそういうタイプ、まぁ言ってみれば課題解決に頭が行きがちだったり、「特別なことを考えずに、まずはちゃんとやる」みたいなことを、ここ数年とにかく意識してきたので、そのある種真逆にあたるような「なんかわけわからんことをやってみる、斬新な仕組みを考える」みたいな、なんというかクリエイティブだったりキラキラしてたりするようなことが足りてないんではないか、ということは常に頭の片隅にあったりします。キラキラしたい。

この辺りはもうすこししたら、自分が全うに仕事をできるようになった、と思えたら、ゆっくり考えてみたいと思っています。

さいごに

まだまだ何かある気もしますが、とりあえず7つってのが良いらしいので勢いで書いてみました。それではみなさま、よいクリスマスを、そしてよいお年をお迎えください!

関連記事