「技術をリスペクトする組織を作ろう」CTOとして守り続けるnanapiの企業文化

CTOの「オレ最強勘違い時期」が終わる時

フェーズ2ですね。だんだん自分だけじゃなくてまわりの人間と開発していく中で、いろんな葛藤とかも出てきたりします。一番大きなところが、メンバーが増えるにあたって資金調達したところですね。

収益ってものは当然考える必要があるんですけども、赤字でも当分生きられるというところに変わったのが大きかったなというところですね。しかも当時にしては結構大型の資金調達だったので、当分生き延びられるかなと。

この辺りからですね、エンジニアの採用を本格化して徐々にメンバーが増え始めたというところです。

結構スタートアップCTOで誰もが経験してるんですけど「オレ最強勘違い時期」みたいなのがやっぱあると思うんですけども、そういったものがメンバーが増えていくとだんだん終わっていって。

だんだん属人化しないように開発しやすい構成だったりとか、わかりやすいアーキテクチャだったりとか、昔からむちゃくちゃなアーキテクチャみたいなことにだんだんなっていったりしました。

こういうところも皆さんご存知かと思いますが、1人と2人では全然変わってくるじゃないですか。なんで、個人がただ良ければいいよっていう技術選定じゃなくて、チームとしてどいうったことを選んでいこうかというのをちゃんと考えなければいけないと。

リリースサイクルをどうやって早めていくかだったり、個の責任範囲をどうやっていこうかなとかが、それなりに起きてくる課題なんじゃないかなと思っていたりします。

ここら辺から、結構技術選定とかにおいて起きてくる苦悩があって、プレイヤーとマネージャーの境目ぐらいになってくるんですよね。でも、この辺りって今まで自分が経験してきたものなんですけども、だんだんそれなりに仕切って任せなきゃいけないって時も出てくるんですよ。

でもやっぱり今まで自分が決めてきたりしてたし、自分が全ての意思決定をしたり、からんでいたいですよね。100％全てを把握していないと気持ち悪いというのがあったりしました。でも、自分自身より詳しい分野を持ってるメンバーがいますし、それをコントロールするのはどうなんだろうなあって苦悩し始めたのがこのあたりですね。

ただ技術の選定しててそんなに変わってはいなくて、最終的には私が決めるっていうことでやっていた時代です。

メンバーが10人を超えてきたら変わること

この辺りからビジネスがいろいろ変わってきて、自分自身もフェーズを変えなきゃいけないなあと、変えたのがフェーズ3ですね。「みんなを支える」ってよく言っていたんですけど、メンバーが10人を超えてきた辺りから、1人で全部マネージメントするってのがなかなか難しいなと。

マネージメントできなくなるんですよね。あと時代的にもPCとか中心だったのがだんだんスマホへシフトしていきました。もともと「nanapi.jp」ってサービスはPCありきのサービスだったので、それだけでもちょっといつまで戦えるんだろうねっていった部分が出てきました。

結果「nanapi.jp」がプロダクトに繋がらなきゃいけないよねって意識が出てきたりしました。ただ結果的に新規事業やりましょうねって話でわかるんですけども、大事なのは新しいプロダクト作ってそれが時代についていけなくなった時に、またさらに新しいものを生まなければいけないんですよね。

あと大事なのは、新投資できることは、現場から新しいプロダクトが出続ける組織作りをコミットするようになった時期だったりします。

それで先ほどご紹介したような、プロジェクト単位にエンジニアだったりデザイナーをアサインして、その中で意思決定をして、そこでさまざまな技術を導入するということをやるような組織になったというところですね。エンジニアは横断組織としてCTOが見るみたいな組織に変わっていったのがこのフェーズだったりします。

その辺りから各サービスの技術選定だったりある程度変わってきていて、直近でやってるところで言うと、nanapiサービス、さっきお話したようにCakePHPで作っていたんですけど、実は今RoRへ再実装したりしてます。

インフラに関しては長年オンプレミス環境でやっていたんですけども、今年の8月にAWSに全部移行したりとか、こんなことをやっていたりします。

そのほかアンサーとかもですね、実はデーターベースの発動の1年くらい前だったんですけども、組織になったからこそ、新しいアーキテクチャできたんじゃないかなと。

さっき紹介したIGNITIONも、これもRoRで作った最初のプロダクトなんですけど、チームに任せて議論した結果、RoR使いますって話だったんですけど、チームに技術選定がすることができるという裁量を与えた結果、出てきた結果なんじゃないかなと思っています。

技術選定の議論で重要なのは「Why」と「How」

結果的に目の前に出ている選定の技術ってそんなにとがったものじゃなくて、当たり前のことではあるんですけども、そんなに当たり前のようでも会社の中で新しい言語を使うって、それなりに大きな選択だと思うんですよね。

そういったものを技術選定する時に、議論で気をつけてることがいくつかあって、まず技術選定をするような議論の時はなるべくいるようにしているんですけども。

私がいるのはですね、結局結論を出すというよりかは、エンジニア同士が技術選定をする時にどうしても目線がいってしまうのが、何を選ぶかってところだけで選んで、議論してしまうんですよね。

これ使いたい、この言語がいい、やってみたい。それ自体は悪くないんですけれども、何を使うかって議論ばかりしていると、なかなか議論が進まないんです。最後好みの世界になってしまうので。

なので、大事なのはなぜそれを選ぶのかだったり、それを選んだあとどのようにやっていくのか、WhyとHowの部分で議論していくべきじゃないかなと思います。

なのでここら辺の議論ってのは極力公平にして、ただ何を選ぶかだけを議論しないように調整しているというのが私のやっていることですね。

最終的にWhyとHowがちゃんと議論されていれば、何を選ぶかってのはチームのほうに任せているので、その辺は裁量を与えていたりはします。こういう議論、プロセスはですね、意識して考えてもらうようにしているという、そんなのが私のやっていることだったりします。

こういう風に各チーム内で技術ってのが選べる組織ってのが、できてきているというところです。

その上で「風土をつくる」ってところなんですけど、技術選定ってエンジニアだけでできるとおもいきや、私結構エンジニアだけでできないかなと思っていたりします。

会社全体に技術ってこうだよねって風土がないと、絶対技術選定ってノイズが入ると思っているんですよね。新しい技術だったりとか、それこそ、インフラを移行しますって時って、何らかのリスクや工数って絶対に伴うものなんですよ。

例えば私が今年やった、オンプレミスの環境からAWSに移行しますって時、営業とかから見たら何も目の前の見栄えが変わらないものを、インフラを移行するからこれだけコストかかりますってのをやると、なかなか理解しづらいですよね。

コストメリットがあるとはいえ、やっぱりどちらかというとコストダウンのほうなので、わりともっと儲かる新しいサービスだったりとか、広告枠を追加とかのほうが、営業的には良いじゃんって話になってくるんですよ。

ただ、そこを理解してもらわないと、システムの安定が進化していかないので、そこら辺を理解してもらう会社作りってものがより重要になってくるところですね。

非エンジニアが技術をリスペクトする文化・風土作り

特にリファクタリングってエンジニア以外には意味がわからなくて、何でコードを書き直すことがそんなに大事なんだって、動いてるんだからいいじゃんってことが絶対起きると思うんですよね。

でもそれってやり続けなくちゃいけなくて、そのために説明しても非エンジニアからは根本的には理解されないのかなと思っていたりします。

なので、CTOとして大事かなと思ってるのがそんな風土作りだったりとか、社内における布教活動かなと思っていたりします。

当然社内には、非エンジニアもそうですし、経営陣同士もそうなんですけど、まず経営陣同士で技術的な目線を忘れないことですね。ウチってCEOとCOOとCTOっていうのが極めて対等な組織にしていたりします。

なので自分のほうでちゃんと主張していかないと、もともと対等なものが対等じゃなくなってしまうんですよ。なのでそういった経営陣同士での発言に対して、技術の目線も忘れないようにしていたりします。

そのCxO同士の力関係ってものは、常に対等であるべきなんじゃないかなと思ってます。これはCTOは組織を守ることで重要なことなので、ここを意識していたりします。

対等って書くと何かすごく揉めてるような感じがするんですけど、そうじゃなくて、ちゃんと言う事は言う、守るべきものは守るといったことだったりします。

当然、技術が軽んじられるような経営判断は絶対阻止しますよというのが、基本的なCTOとしてのやることなんじゃないかなと思っていたりします。

これは経営陣の話で、当然社内もそうで、非エンジニアの人はなかなか多いですよと、非エンジニアが技術をリスペクトするのが文化だったりとか、風土ってものを極力作るようにして。

技術選定だったりとか、リファクタリングだったりとか、そういったものを、社内で進めやすくするようなものを極力やるようにしていたりします。

技術っていう、共通の言語があれば、相互理解が進んで余計な摩擦がなくなると思うんですよね。その中でうまくやっていければいいんじゃないかなと思ってます。

この辺りの、技術をリスペクトする文化とか風土を作りましょうみたいなことは、1回ブログにまとめたことがあるので、もし興味があれば読んでみてください。これでエンジニア選びをしましょうっていうんじゃなくて、共通の言語を持ちましょうに近い感じですね。

それがあれば余計な摩擦を生みませんよみたいな話だったりするので、もし組織作りとかに興味がある方がいれば、こちら見てください。こんなことをやっていたりします。

こんなことをやっていくうちにですね、CTOって何が必要なのかな、技術選定だけとかじゃなくて、CTOとしてどういうことが大事なのかなってことを考えるようになりました。

そこで今意識してるのが、CTOとしての視座の高さなんじゃないかなと思っていて、技術選定って、どうしても何を選ぶかってところにいってしまうんですけども、なぜ選ぶのかってところにいかなきゃいけない。

なので、現場目線だけだと、今これを使いたい、選びたいって現場目線になってしまうんですけども、もう少し組織目線でなぜそれを選んだのかとか、これを選んだ先に、どういう先が待ってるのかとかという目線が大事なのかなって思ってたりします。

なので技術を選ぶ上でも、組織としてのあるべき姿を考えた上で、技術ってものを選ぶように極力現場をコーディネートしていかなければいけないんじゃないかなって思ってたりします。

その中で、さっきコーディネートってお話しましたけど、まさにこんな感じですね。現場のコーディネート加えて、上位レイヤーを調整したりとか、社内の相互理解の推進だったりとか、最後自由に選ぶことができる風土を作ったりとか、そいうったところが、CTOとして技術選定における一番作動できるところなんじゃないかなと思って思ってたりします。

いろいろ話してきて組織とCTOとしてみたいな話になってきたりしてしまってるんですけど、最終的にはこういう話に絶対になるのかなって思っています。

nanapiの企業文化と風土は維持し続けたい

私自身が最近すごく、技術選定とかを含めて意識していることがいくつかあるんですけども、一番意識していることは、この3つですね。

CTOとしてではなくて、私は最初からやっているのでCo-Founderだったりとか、あと取締役としてできることってのは何なのかってのを考えていたりします。

社長が会社にするって決めて、僕がそういう風にこうやってるってわけじゃなくて、うちの会社でこういう戦略でやっていくための技術スタッフをどういうふうにやっていけばいいのかっていう戦略をとっていたりするので、極力ですね、会社としての戦略自体も一応考えるようにしていたりします。

その結果こういったところですね。技術はコントロールしきらない。うまく任せましょうという考え方だったりします。技術選定に関しても、コーディネートとか面倒くさい調整は私がやるけれども、最終的な意思決定は現場に任せたいなというところですね。

2点目なんですけど、そういったことのできる組織ってのが一番意識していたりします。なので、プロダクトのことを考えるのは現場に任せたくて、私みたいなCTOとか役員と言われる人間は、プロダクトだけじゃなくて、そのプロダクトを作ってる組織ってものを中心に考えることができるような、眼力がなければまずいなというところですね。

最後は、そういったことができるような風土を作って、それを整備して維持し続けるといったようなところが、大事なんじゃないかなと思っていたりします。

そうこうやっていたんですけども、今年の10月にウチはずっと単独でやっていたんですけども、大きな組織変更がありまして、親会社というものができました。親会社ができたんですけども、我々基本的には変わらなくて、本当に引き続きやっていきたいなってところですね。

最初からずっと言っているように「nanapi.jp」ってものだけをやっているだけじゃなくて、新しいサービスを生み出していく会社になっていかなくてはいけないかなと思っていたりします。

その中で、今回の選択をしたっていうのも、我々から自ら選んだ選択肢なので、親会社のアセットを使いつつ今までの企業文化をこのまま壊さないようにしていきたいなというところですね。

大企業についてしまうと、技術選定とか、新しいテクノロジー入れるのが面倒くさかったりってことが起き得るものだとは思うんですけど、そういったことが起きないように、今までらしくやっていきたいなということですね。

最終的にはウチで培った企業文化だったりとか、風土ってものを親会社に向けてフィードバックできていければいいかなって思っていたりはします。

こんな感じでですね、nanapiという会社、いろいろやってきて、実際はKDDIグループの会社の中に入ってはいるんですけれども、今までの企業文化だったりとか、風土を大切にしたいと思っておりますし。

引き続き技術選定とかってものに、現場が自由にできるような会社のままでやっていたいなと思っています。

会社の流れとして特徴的な会社なので、参考にならないところもいろいろあるかなと思いますが、私なりの考えを説明させていただきました。というわけでですね、私の発表は以上で終わりたいと思います。どうもありがとうございました。