2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
フェーズ2ですね。だんだん自分だけじゃなくてまわりの人間と開発していく中で、いろんな葛藤とかも出てきたりします。一番大きなところが、メンバーが増えるにあたって資金調達したところですね。
収益ってものは当然考える必要があるんですけども、赤字でも当分生きられるというところに変わったのが大きかったなというところですね。しかも当時にしては結構大型の資金調達だったので、当分生き延びられるかなと。
この辺りからですね、エンジニアの採用を本格化して徐々にメンバーが増え始めたというところです。
結構スタートアップCTOで誰もが経験してるんですけど「オレ最強勘違い時期」みたいなのがやっぱあると思うんですけども、そういったものがメンバーが増えていくとだんだん終わっていって。
だんだん属人化しないように開発しやすい構成だったりとか、わかりやすいアーキテクチャだったりとか、昔からむちゃくちゃなアーキテクチャみたいなことにだんだんなっていったりしました。
こういうところも皆さんご存知かと思いますが、1人と2人では全然変わってくるじゃないですか。なんで、個人がただ良ければいいよっていう技術選定じゃなくて、チームとしてどいうったことを選んでいこうかというのをちゃんと考えなければいけないと。
リリースサイクルをどうやって早めていくかだったり、個の責任範囲をどうやっていこうかなとかが、それなりに起きてくる課題なんじゃないかなと思っていたりします。
ここら辺から、結構技術選定とかにおいて起きてくる苦悩があって、プレイヤーとマネージャーの境目ぐらいになってくるんですよね。でも、この辺りって今まで自分が経験してきたものなんですけども、だんだんそれなりに仕切って任せなきゃいけないって時も出てくるんですよ。
でもやっぱり今まで自分が決めてきたりしてたし、自分が全ての意思決定をしたり、からんでいたいですよね。100%全てを把握していないと気持ち悪いというのがあったりしました。でも、自分自身より詳しい分野を持ってるメンバーがいますし、それをコントロールするのはどうなんだろうなあって苦悩し始めたのがこのあたりですね。
ただ技術の選定しててそんなに変わってはいなくて、最終的には私が決めるっていうことでやっていた時代です。
この辺りからビジネスがいろいろ変わってきて、自分自身もフェーズを変えなきゃいけないなあと、変えたのがフェーズ3ですね。「みんなを支える」ってよく言っていたんですけど、メンバーが10人を超えてきた辺りから、1人で全部マネージメントするってのがなかなか難しいなと。
マネージメントできなくなるんですよね。あと時代的にもPCとか中心だったのがだんだんスマホへシフトしていきました。もともと「nanapi.jp」ってサービスはPCありきのサービスだったので、それだけでもちょっといつまで戦えるんだろうねっていった部分が出てきました。
結果「nanapi.jp」がプロダクトに繋がらなきゃいけないよねって意識が出てきたりしました。ただ結果的に新規事業やりましょうねって話でわかるんですけども、大事なのは新しいプロダクト作ってそれが時代についていけなくなった時に、またさらに新しいものを生まなければいけないんですよね。
あと大事なのは、新投資できることは、現場から新しいプロダクトが出続ける組織作りをコミットするようになった時期だったりします。
それで先ほどご紹介したような、プロジェクト単位にエンジニアだったりデザイナーをアサインして、その中で意思決定をして、そこでさまざまな技術を導入するということをやるような組織になったというところですね。エンジニアは横断組織としてCTOが見るみたいな組織に変わっていったのがこのフェーズだったりします。
その辺りから各サービスの技術選定だったりある程度変わってきていて、直近でやってるところで言うと、nanapiサービス、さっきお話したようにCakePHPで作っていたんですけど、実は今RoRへ再実装したりしてます。
インフラに関しては長年オンプレミス環境でやっていたんですけども、今年の8月にAWSに全部移行したりとか、こんなことをやっていたりします。
そのほかアンサーとかもですね、実はデーターベースの発動の1年くらい前だったんですけども、組織になったからこそ、新しいアーキテクチャできたんじゃないかなと。
さっき紹介したIGNITIONも、これもRoRで作った最初のプロダクトなんですけど、チームに任せて議論した結果、RoR使いますって話だったんですけど、チームに技術選定がすることができるという裁量を与えた結果、出てきた結果なんじゃないかなと思っています。
結果的に目の前に出ている選定の技術ってそんなにとがったものじゃなくて、当たり前のことではあるんですけども、そんなに当たり前のようでも会社の中で新しい言語を使うって、それなりに大きな選択だと思うんですよね。
そういったものを技術選定する時に、議論で気をつけてることがいくつかあって、まず技術選定をするような議論の時はなるべくいるようにしているんですけども。
私がいるのはですね、結局結論を出すというよりかは、エンジニア同士が技術選定をする時にどうしても目線がいってしまうのが、何を選ぶかってところだけで選んで、議論してしまうんですよね。
これ使いたい、この言語がいい、やってみたい。それ自体は悪くないんですけれども、何を使うかって議論ばかりしていると、なかなか議論が進まないんです。最後好みの世界になってしまうので。
なので、大事なのはなぜそれを選ぶのかだったり、それを選んだあとどのようにやっていくのか、WhyとHowの部分で議論していくべきじゃないかなと思います。
なのでここら辺の議論ってのは極力公平にして、ただ何を選ぶかだけを議論しないように調整しているというのが私のやっていることですね。
最終的にWhyとHowがちゃんと議論されていれば、何を選ぶかってのはチームのほうに任せているので、その辺は裁量を与えていたりはします。こういう議論、プロセスはですね、意識して考えてもらうようにしているという、そんなのが私のやっていることだったりします。
こういう風に各チーム内で技術ってのが選べる組織ってのが、できてきているというところです。
その上で「風土をつくる」ってところなんですけど、技術選定ってエンジニアだけでできるとおもいきや、私結構エンジニアだけでできないかなと思っていたりします。
会社全体に技術ってこうだよねって風土がないと、絶対技術選定ってノイズが入ると思っているんですよね。新しい技術だったりとか、それこそ、インフラを移行しますって時って、何らかのリスクや工数って絶対に伴うものなんですよ。
例えば私が今年やった、オンプレミスの環境からAWSに移行しますって時、営業とかから見たら何も目の前の見栄えが変わらないものを、インフラを移行するからこれだけコストかかりますってのをやると、なかなか理解しづらいですよね。
コストメリットがあるとはいえ、やっぱりどちらかというとコストダウンのほうなので、わりともっと儲かる新しいサービスだったりとか、広告枠を追加とかのほうが、営業的には良いじゃんって話になってくるんですよ。
ただ、そこを理解してもらわないと、システムの安定が進化していかないので、そこら辺を理解してもらう会社作りってものがより重要になってくるところですね。
特にリファクタリングってエンジニア以外には意味がわからなくて、何でコードを書き直すことがそんなに大事なんだって、動いてるんだからいいじゃんってことが絶対起きると思うんですよね。
でもそれってやり続けなくちゃいけなくて、そのために説明しても非エンジニアからは根本的には理解されないのかなと思っていたりします。
なので、CTOとして大事かなと思ってるのがそんな風土作りだったりとか、社内における布教活動かなと思っていたりします。
当然社内には、非エンジニアもそうですし、経営陣同士もそうなんですけど、まず経営陣同士で技術的な目線を忘れないことですね。ウチってCEOとCOOとCTOっていうのが極めて対等な組織にしていたりします。
なので自分のほうでちゃんと主張していかないと、もともと対等なものが対等じゃなくなってしまうんですよ。なのでそういった経営陣同士での発言に対して、技術の目線も忘れないようにしていたりします。
そのCxO同士の力関係ってものは、常に対等であるべきなんじゃないかなと思ってます。これはCTOは組織を守ることで重要なことなので、ここを意識していたりします。
対等って書くと何かすごく揉めてるような感じがするんですけど、そうじゃなくて、ちゃんと言う事は言う、守るべきものは守るといったことだったりします。
当然、技術が軽んじられるような経営判断は絶対阻止しますよというのが、基本的なCTOとしてのやることなんじゃないかなと思っていたりします。
これは経営陣の話で、当然社内もそうで、非エンジニアの人はなかなか多いですよと、非エンジニアが技術をリスペクトするのが文化だったりとか、風土ってものを極力作るようにして。
技術選定だったりとか、リファクタリングだったりとか、そういったものを、社内で進めやすくするようなものを極力やるようにしていたりします。
技術っていう、共通の言語があれば、相互理解が進んで余計な摩擦がなくなると思うんですよね。その中でうまくやっていければいいんじゃないかなと思ってます。
この辺りの、技術をリスペクトする文化とか風土を作りましょうみたいなことは、1回ブログにまとめたことがあるので、もし興味があれば読んでみてください。これでエンジニア選びをしましょうっていうんじゃなくて、共通の言語を持ちましょうに近い感じですね。
それがあれば余計な摩擦を生みませんよみたいな話だったりするので、もし組織作りとかに興味がある方がいれば、こちら見てください。こんなことをやっていたりします。
こんなことをやっていくうちにですね、CTOって何が必要なのかな、技術選定だけとかじゃなくて、CTOとしてどういうことが大事なのかなってことを考えるようになりました。
そこで今意識してるのが、CTOとしての視座の高さなんじゃないかなと思っていて、技術選定って、どうしても何を選ぶかってところにいってしまうんですけども、なぜ選ぶのかってところにいかなきゃいけない。
なので、現場目線だけだと、今これを使いたい、選びたいって現場目線になってしまうんですけども、もう少し組織目線でなぜそれを選んだのかとか、これを選んだ先に、どういう先が待ってるのかとかという目線が大事なのかなって思ってたりします。
なので技術を選ぶ上でも、組織としてのあるべき姿を考えた上で、技術ってものを選ぶように極力現場をコーディネートしていかなければいけないんじゃないかなって思ってたりします。
その中で、さっきコーディネートってお話しましたけど、まさにこんな感じですね。現場のコーディネート加えて、上位レイヤーを調整したりとか、社内の相互理解の推進だったりとか、最後自由に選ぶことができる風土を作ったりとか、そいうったところが、CTOとして技術選定における一番作動できるところなんじゃないかなと思って思ってたりします。
いろいろ話してきて組織とCTOとしてみたいな話になってきたりしてしまってるんですけど、最終的にはこういう話に絶対になるのかなって思っています。
私自身が最近すごく、技術選定とかを含めて意識していることがいくつかあるんですけども、一番意識していることは、この3つですね。
CTOとしてではなくて、私は最初からやっているのでCo-Founderだったりとか、あと取締役としてできることってのは何なのかってのを考えていたりします。
社長が会社にするって決めて、僕がそういう風にこうやってるってわけじゃなくて、うちの会社でこういう戦略でやっていくための技術スタッフをどういうふうにやっていけばいいのかっていう戦略をとっていたりするので、極力ですね、会社としての戦略自体も一応考えるようにしていたりします。
その結果こういったところですね。技術はコントロールしきらない。うまく任せましょうという考え方だったりします。技術選定に関しても、コーディネートとか面倒くさい調整は私がやるけれども、最終的な意思決定は現場に任せたいなというところですね。
2点目なんですけど、そういったことのできる組織ってのが一番意識していたりします。なので、プロダクトのことを考えるのは現場に任せたくて、私みたいなCTOとか役員と言われる人間は、プロダクトだけじゃなくて、そのプロダクトを作ってる組織ってものを中心に考えることができるような、眼力がなければまずいなというところですね。
最後は、そういったことができるような風土を作って、それを整備して維持し続けるといったようなところが、大事なんじゃないかなと思っていたりします。
そうこうやっていたんですけども、今年の10月にウチはずっと単独でやっていたんですけども、大きな組織変更がありまして、親会社というものができました。親会社ができたんですけども、我々基本的には変わらなくて、本当に引き続きやっていきたいなってところですね。
最初からずっと言っているように「nanapi.jp」ってものだけをやっているだけじゃなくて、新しいサービスを生み出していく会社になっていかなくてはいけないかなと思っていたりします。
その中で、今回の選択をしたっていうのも、我々から自ら選んだ選択肢なので、親会社のアセットを使いつつ今までの企業文化をこのまま壊さないようにしていきたいなというところですね。
大企業についてしまうと、技術選定とか、新しいテクノロジー入れるのが面倒くさかったりってことが起き得るものだとは思うんですけど、そういったことが起きないように、今までらしくやっていきたいなということですね。
最終的にはウチで培った企業文化だったりとか、風土ってものを親会社に向けてフィードバックできていければいいかなって思っていたりはします。
こんな感じでですね、nanapiという会社、いろいろやってきて、実際はKDDIグループの会社の中に入ってはいるんですけれども、今までの企業文化だったりとか、風土を大切にしたいと思っておりますし。
引き続き技術選定とかってものに、現場が自由にできるような会社のままでやっていたいなと思っています。
会社の流れとして特徴的な会社なので、参考にならないところもいろいろあるかなと思いますが、私なりの考えを説明させていただきました。というわけでですね、私の発表は以上で終わりたいと思います。どうもありがとうございました。
関連タグ:
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略