判断ミス時の退路を考えておく--Facebookの失敗事例から学ぶ、新しい技術の取り入れ方

判断ミス時の撤退路を念頭に置く

技術選定のところはいろいろ方針があって、ケース的にはこうしたほうがいいよねっていうのがあるんですけど、Facebookの事例は参考になると思います。

Facebookで一番技術的に大きなミスをしたのは、iOSアプリをHTMLで書くかNativeで書くかっていうのを、2010年、11年くらいにずっと論争されていて。

日本でもHTMLファイル派とNative派で論争があったと思うんですけど、最初にFacebookは2012年のブログエントリーでNativeで書き直すことにしましたっていう、さらにスピードが上がってFacebookのアプリもすごい使いやすくなったんですけど。

Facebookくらいの規模があればこれぐらいの規模の技術選定を間違えたとしても、リカバー可能なんですけど、もう少し小さいとこのレベルの技術選定を間違えると結構時間をロスしてしまって、それが致命傷にもなったりするので、そこはちゃんとうまくやる必要があるなと思ってます。

僕が考える技術選定の方針は、いろいろ選定するときに判断に悩むときがあるんですけど、方針としては、ある程度保守的にするのが安全だろうとは思ってますので、まずはデフォルトとしては保守的な判断をするようにしてます。

ただすべてにおいて保守的にしてると、競争優位にあるあまり先端的なことができなくなっているので、重要なところではアグレッシブにどんどん新しいものを取り込んでいこうと思ってます。

あとはどの辺りを重要と見るか、どのタイミングでそれを導入するかってのが、CTOとしての腕の見せ所なんじゃないかなと思ってます。

1つ重要なのは、判断ミス時の撤退路は念頭に置くっていうこと。

例えば今までオンプレでサービスをずっと運営していたのを、例えばデータベースにごそっと忘れるってなったときにAWSはすごい実績あるから、そこでスランプになることはないと思うんですけど。

例えば2011年とか2010年くらいにその判断を出したときには、基本的にはAWSが駄目だったらどう、オンプレに戻すかとか、そういう撤退路を考えていくことが非常に重要で。

その撤退路を確保しておけばよりアグレッシブに新しい技術を選定することもできるので、そこは表裏一体でちゃんと撤退路を念頭に置きながら選定するっていうことでよりアグレッシブな判断が出きるんじゃないかなと思っています。

守りの一つのスケーラビリティとかセキュリティとか、ここはもう、粛々と手抜きせずにちゃんと、きっちりやっていきましょうということだろうと思ってます。

途中から専門職かマネージャーになるかで分かれる

ここまでは技術的なことを話してきたんですけど、今度は人材面のところです。人材面だと、エンジニアとマネジメントというのがよく話題になるところで、エンジニアの人はなかなかマネジメントをやってくれないとか、エンジニアの現場の人、若い人が一生コードを書いていたりとか、そういうのを言われていることが多いと思うんですけど。

ちょうど昨日「超わがままCTOと語る」という記事が出ました。個人的にはいろいろ思うところもありますが。いろいろ思うところを言ってしまうとちょっとパブリックな場では言えないこともあるので、個別に聞いていただければと思います。

ただ、ちょっとあれですね「超わがままエンジニア」って自称してるのがすごい重要で。ちゃんとこう、一応チェックはして使っていいって、本人公認であるんですよね。元・超わがままエンジニアがクックパットCTOになっているっていうのが、いろんな意味でおもしろい現象だなと思ってます。

そういうエンジニアとマネジメントをどうやるかっていうのを考えた場合に、エンジニアのキャリアパスを1つ考えておこうと思います。典型的には専門職スペシャリスト系とマネージャー系というのがよくあるパターンかなと思います。

だいたいある程度の規模の会社になってエンジニアのキャリアパスの人事制度とか奨励してるところとかを見ると、だいたい最初は全員エンジニアで入るんだけど、ある時期になると専門職、スペシャリストルートと、マネージャーになるマネージャーコースと、分かれていくのをよく見るので一般的なんじゃないかなと思います。

はてなも専門職コースとマネージャーコースと分かれるようになってて、なんだかんだ言って、これが現実的なんじゃないかなと思います。

一番下の研究職は、相当の規模の大きい会社じゃないと出てこないと思うんですけど、一応研究職っていうのも、キャリアパスとしてあり得ると思います。

専門職の話をするときに、どれくらいのスキルを身につけてもらうかってことで「フルスタックエンジニア」っていうキーワードが出て来たりしますけど。

実際にはここにいるような人たちがサービスなり事業を組み立てていく上でレイアウトがどんどん広がっていって。

昔はフロントとJSとバックエンド、あとサーバーインフラまわりを触れればよくて、だいたい一人で何とかこなせる範囲だったんですけど。

ここ5、6年はスマートフォンエンジニアがちゃんとやんないとねって話もいったりとか、ゲーム系の人だと3Dグラフィックをさわれるような人だったりとか。

ビックデータ系のところだと、機械学習をちゃんとやりましょうとか、データ解析ちゃんとやりましょうとか。

この辺のレイヤーは現場で一線級のもの持ってる人、ほとんどいないんじゃないかと思います。

スキルセットのポートフォリオを組んだほうがいい

これも最近話題になってましたけど、ドワンゴさんがハードウェアエンジニアを募集してて、FPGAで配信の高速化をしたいっていう話をしていて、FPGAの設定のところまで出てくるともう、全てを網羅するのは非現実的。

もしかしたらできる超人はいるかもしれないですけど、多くの人には非現実的なので、スキルセットのポートフォリオを組むとかがいいんじゃないかと思って。例えば、バックエンド＋機械学習とか、バックエンド＋スマートフォン、得意な領域＋αくらいを狙っていくのがいいんじゃないかなって。

これは個々のエンジニアと話すときに「君はこの辺が得意だから、もう少しこの辺に手を出したら」とか、そういうのを話したりしてます。

もちろん得意な領域がすごい強ければ、それだけやってもいいパターンもあると思うんですけど、必要な求められるスキルセットってのは変化していくと思ってまして、ビジネスや外部環境の変化によって必要なスキルセットも変化していくと。

例えばスマホが普及してくれば、情報のスキルも必要になりますし、AWSみたいなクラウドが普及してくると、サーバーインフラ系の技術ってのはそんなに必要じゃなくなってくると思うので。

新しく必要な技術も出てくれば、あまりいらなくなる技術も出てきて、日本のエンジニアの日本の雇用形態の中では、一度採用するとその人をずっとうまく活用してもらわないといけないので。

そうすると必要十分なスキルセットを各従業員に適用してもらう必要があって、そういうインセンティブとか動機付けをちゃんとやっていくのも大事だなと思ってます。

各エンジニアが自分の会社の中でずっと活躍できるように、生き残ってもらうのを後押ししつつ、ちゃんと、スマホみたいな新しい物が出てきたら先行投資として、新しい分野に果敢に挑戦してもらう。

エンジニアを育てていくとか、そういう自社で必要となるスキルセットを今いるエンジニアで埋めていったり、必要なら新しい人を連れてきたりとか、そういうスキルセットを考えるのも会社が考えつつ、個々のエンジニアにも考えてもらうっていうのが大事だと思ってます。

マネージャーがエンジニアを理解することが大事

マネージャーの話になると、マネージャーの役割ってのは基本的にプロダクト開発を推進するのが一番の役割になって、その役割としては具体的にはエンジニアをモチベートする点と、開発プロセスを整えるっていう2つの点があるかなと思ってます。

エンジニアのモチベーションはとても重要で、開発チームの生産性に直結しますし、そのモチベーションを上げるためにもコミュニケーションをちゃんとしていくってのが重要だと思ってます。

エンジニアのコミュニケーションについてですが、Web系のエンジニアはできるだけ多くのものごとをオープンにしていって、情報共有をすることが大事だと思います。

会社の上のほうの流れとか、サービスの将来的な方向性とかいろんな情報をちゃんと共有できるようにしておいて。個々のエンジニアが自分が何をやってるかとか、自分のやっていることがどういうものなのかってのがちゃんと理解してもらいながら、進めていく必要があると考えています。

あと、マネージャーがそれをお願いする上でも、エンジニアへの理解が重要。

ちゃんとエンジニアへのリスペクトを持った上でコミュニケーションをとっていくことで、それでエンジニアがモチベートされる点がすごい多いと感じてますので、マネージャーがちゃんとエンジニアへの理解があることが大事だなと思ってます。

そういう意味で、エンジニア出身のマネージャーっていうのは、そういうのがやりやすいというメリットがあるんじゃないかなと思ってます。

エンジニアへの理解という点では「神は細部に宿る」とよく言われますけど、特にエンジニア出身のマネージャーでも、現場から離れると「自分の経験で自分ならあれくらいできる」とか、細部を軽視しがちになる傾向があると思ってて。

僕が実感してるのは、なんとなくわかった気にならないとか、簡単に見えそうだけど簡単にできるとは限らない。

これはもちろん現場でコードを書いてれば当然わかることなんですけど、現場を少し離れると、自分があまり知らない分野になると、そういう細部が見えなくなって抽象化された状態で簡単に見えたりするので。

この辺はちゃんとリスペクトして意識しながらコミュニケーションをとる必要があるんだなと思って。ここは時間をかけていってるところですね。

開発プロセスを整えるというのも、マネージャーとしての重要な役割で。

はてなの場合だとスクラムを導入したりとか、それに必要なツールを導入したりとか。

リモートワークはコミュニケーションを重要視

あとは働き方の多様性を許容して、最近だとリモートワークをしたりとかしています。

スクラムはこういう感じでやっていて、基本的には教科書的なことをやったりしてます。ただこれをちゃんとまわすとか、そういうところがマネージャーに期待するところですね。

ツール導入は、最近SaaSのサービスを使うようになってきて、GitHubを先頭にslackとか、TravisとかCI系サービスも使うようになってきてます。あとは自社ですけど、mackerelを導入したりとかもしてます。

リモートワークは最近始めたんですけど、もともとはてなは東京と京都の2拠点制でやってたんですけど、一人のエンジニアが家庭の都合で愛知に引っ越したりして、3拠点体制になったり。

あとはエンジニアがときどき出張してちょうどこの週末北海道へ行ったり、そういう出張先でも空いた時間にちゃんと開発ができるようにするためにも、リモートワークができるような体制を心がけてます。

リモートワークの運用上心がけているのはコミュニケーション。フェイストゥフェイスのコミュニケーションを重要視する必要があって、典型的には一人がはまってしまって浪費してしまったりすることがないように気を付けています。

一人黙々と進めてスムーズなんだけど、そのノウハウが共有されないとか、そういうのがありますので、ちゃんとコミュニケーションを重視して進める必要があるなと思ってます。

そのためにも道具、ツールにこだわって、より使いやすい道具とかより使いやすいサービス、ツールを模索しながら、こういう構造を改造していく必要があるなと思ってます。

こういう道具、ツールにコストをかけるってことこそ、リモートワークを成功させるために必要だなと思ってます。

最近だと、ZOOMっていうテレビ会議。手元の端末でできるんですけど、主にMacのソフトウェアでできるテレビ会議システムを使って。9人10人くらいまではいけるんですけど、そういう会議はリモートでやったりしています。

この本はリモートワークを推す、推奨した本なんですけど、これの半分くらいをいろいろしてます。こういう感じで、技術面と人の面を判断したりマネージャー職に対してこういう感じでやってるとか、こういうコミュニケーションをやってきてます。

そういうふうにいろいろとやってきてるんですけど、あらためて「CTOに求められるもの」というものを考えてみますと、僕としてCTOとして意識してきたことは、技術面と人材面の2つがあったなと思ってます。

いろいろやってきたんですけど、もちろん成功したことだけじゃなくて失敗したこともあったし、判断をミスしたこともあったんですけど、振り返ってみると失敗は恐れるべきではないなと思ってます。

ただ、退路はちゃんと確保した上で、失敗をおそれずに進むべきだなと思ってます。実行するときはちゃんとボトムアップで実行して、ボトムアップで実行すると失敗したとしても経験っていうのは残りますので、次にやるときにはもう少しよりうまくできるだろうというのがありますので。

ちゃんと現場を成長させつつ現場を巻き込んでやるというのもやるように意識していることで、そういうのにやったときからうまくいってるなと思います。

最後、まとめですけど、「CTOに求められるもの」ってのは、今言ったような技術と人の問題に対して失敗かもしれないけど、とりあえずの答えをきっちり出して、それをちゃんと実行していけるような役割なんじゃないかなと思っています。

以上になります。ありがとうございました。