CTOの学習帳

日々学んでいること、考え方などの思考整理

奇兵隊、7年間お世話になりました。

株式会社奇兵隊という名前も含めて先鋭的なスタートアップで約7年ほど働いておりまして、2022年12月をもってその奇兵隊を退くことになりましたので、これまでの軌跡と考えをつらつらと残しておきたいなと思います。

奇兵隊の組織とサービス

全体では約25人、開発チームは6人ほどでまわしており、外国籍が過半数以上の組織という感じでした。

また、7年を通して以下のような主にto C領域のプロダクトを提供していました。

直近では、埼玉県の横瀬という町でオフラインとオンラインの両方で授業を行うWeb3スクールのトークンエコノミクス設計をしたりしていました。

Web3やNFTに興味がある方は試しに参加してみてください。 実際にDAOに入ってコミュニティと繋がりながら色々なWeb3体験ができるので、かなり割安でお得だと思います。

https://towns.open-town.org/yokoze/index.html

towns.open-town.org

Web3とは?はこちらも参考にしてみてください。

ryuucham.hatenablog.com

第一の試練

奇兵隊は二社目だったのですが、Global SNSのAirtrippというAndroidアプリを開発するところからスタートしました。

Android javaRubyはその頃未経験で、ライフサイクルなど学びながら遮二無二開発していた時期です。 入社後は先人のエンジニアの方たちが本当に優秀だったので、詰まっても聞ききながら開発することであまり泥沼にはまることなく開発を続けられていた感じでした。

そんな時に自分の師匠だった(勝手に言ってる)エース級のエンジニアが離脱することになり、おいおいやべーなまわせるかこれっていう状況になったのが第一の試練でした。

この試練をきっかけに人に聞いて問題を解決していくという姿勢から、自分で試行錯誤して問題を解決していくスタイルに変わったような気がしています。 また、ユーザーに良い影響を与える開発タスクをどれだけ早くこなせるかということを日々意識して、開発速度というスロットルを開け続けていたなと。そのおかげで設計からコーディング、テスト、デリバリまでをかなり高速でまわしていける力がついたと思います。

第二の試練

そんな中で開発を続けていき、入社1年ちょっとしたくらいにCTOの役割をいただいたわけなんですが、正直最初はまじか、なにすりゃいいの? って感じでした。 CTOといえば本当に恐ろしくコーディングができるようなお偉い方々ばかりで、自分が名乗ったらアカンやろこれって何度も自問しました。

会社として名乗っていかなければいけないわけですので、ロールに負けることのないように死ぬ気で自分を律しました。 わりとそれだけで、「やってやろうじゃん」と奮起できた感はあるのでメンバーに適切な責任を持たせるのは本当に大切だなと痛感しています。

ただ、律したものの何をやればいいか相変わらず全然わからないし、思ってるより自己変革を起こせずに、エンジニアの延長線上として1年くらいは経過してしまっていたと思います。

そんな中で、こちらも師匠である(勝手に言ってる)COO(元CTO)が離脱するという自分にとって第二の試練がはじまりました。 もう後ろで見守ってくれる人なんていないぞ、のほほんと居座っている場合じゃないぞという状況に陥りました。

パニックゾーンぎりぎりのラーニングゾーン

社内である程度の指示を出してくれるような人、砦になるような人がいない中で正解のない課題に対して自ら仮説をもって意思決定し、挑んで道を切り開いていくというのはかなり精神がすり切れる感じがして、かなり辛い時期だったなと思います。

責任をもって意思決定するというのは慣れないうちは本当に疲弊するので、この時は限りなくパニックゾーンに近いラーニングゾーンにいました。

CTO界隈の知り合いも当時は少なく、誰に何を聞いたらいいかもわからない状態でした。 また、自分は経営知識がめちゃくちゃあったり、技術力がめちゃくちゃ高かったり、マネジメントがめちゃくちゃすごかったりとかするわけでは決してないので、常にこのままじゃやばいなーとか、もっとやらんと!といったことが頭から離れませんでした。

まさに人生で一番自分の能力と向き合って、成長のために何をしなければいけないかを考えた時期でした。

圧倒的インプットで乗り越える

わりとノリと根性でやってきたそこまで学がない人間ですので、アンラーニングして絶対にやりきってやるとまずは思考を固めました。

CTOたるもの経営視点で考えつつ、システム全体を見ながら技術戦略立てないといけないよね、というところで経営から組織開発、マネジメント、テクニカル領域すべて学習し直しました。

具体的には基本、応用情報を一通りやり直したり、GCP/AWSのサービスを使いながらSAAを取得したり、AI白書読みながら時勢をアップデートしつつG検定を取得したり、MOT(技術経営)を学んだり、組織開発の古書を一通り読み漁ったりとあらゆる書籍や情報に手を出して、とりあえずは幅広くインプットをごりごり増やしていきました。

そんな時にAWSさん主催のCTO nightというものに参加して、名だたる先輩CTOの方々に「そもそもCTOって何を考えているのか?」「どういう責任を背負っているのか?」を手探りで聞きまくった覚えがあります。

独学だけでは決して辿り着かなかった思考プロセスなどを、そういった場で補填できたのは自分にとって大きな転機でした。

個人的には勉強会で知見を増やすより、飲みながらざっくばらんに語るのが大好きなので、本当にあのような場を提供していただいているAWSさんには感謝しかないです。

内外でのインプットを増やしていくにつれ、おおよそ自分の中でCTOとしての動き方や価値観というものが定まってくるような感覚はあったのですが、それでもレベル100中のまだレベル20くらいの段階にいる感覚は今でも拭えません。

辿り着いた価値観

そこからはプロダクトやテクノロジー戦略に関しては、もちろんCTOとしてメインで見てきたわけですが、さまざまなインプットの末に行き着いたのは組織自体を、いかにして円滑に自律的に動くような仕組みにもっていけるかという事だったと自分の中で帰結しました。 あくまでテクノロジーはビジネスで何を実現したいかを達成するための手段にすぎず、達成するには一つのVisionに向かい、熱量高く自律的に動ける組織が必要なんだと。

その中で自分が本当に大切にしてきたのは、「個を尊重する」ことと、「違和感を解消する」ことです。

「個を尊重する」

これは当たり前のことかもしれませんが、意外と意識していないとできなかったりおろそかになりがちなので、常に以下の5つは自分に言い聞かせてたものになります。

言葉に気をつける

  • 命令口調は絶対に使わない
  • 親しくてもできる限り、~ですます調で話すように心がける

弱みを見せる

  • 知識や能力がなく、できないことはできないと言う
  • わからなかったら素直に教えてもらう

全力で信頼する

  • 細かいことは口を出さずに任せる
  • 失敗したら責めることなく一緒にふりかえる

相互主体的に観る

  • メンバーの発言や態度を観察する
  • メンバーの立場になって物事を観る

真剣に寄り添う

  • 小さな悩みでも真剣に向き合う
  • メンバーのキャリア、納得感を最優先に考える

「違和感を解消する」

事業に集中しているとないがしろにしてしまう問題なのではないかと思うのですが、メンバーにフロー状態を保ってもらうために、違和感をいかに早期にキャッチして解消させてあげられるかということを大事にしていました。

土壌を築く1on1

思ったことを吐き出す場がないと疲弊する問題

  • 自身でも気づかない悩みはあるだろうし、早めに壁打ちしたほうがいいな、悩みを打ち明けてすっきりした状態で成長してほしいなと思ったので1on1は初期から実施を決める
  • メンバーの本質的な話題を選ぶことをこころがける

MVV, NSMでの方向づけ

北極星がないまま進めてしまうことで、手段の最適化に陥り、いつのまにか違和感が生まれる問題

  • メンバーそれぞれのセンスメイキングなしには、普段の業務でフロー状態になることはないので、向かう先を言語化して伝える
  • プロダクトビジョンを伝えることで、手段ではなく目的に対して自律的な動きができる

エンジニア向けに経営方針を咀嚼

経営層は理解しているが、メンバーは理解が追いつかず、認識に齟齬が生まれる問題

  • 内発的なモチベーションを高められるようにエンジニアに向けて発信する
  • なぜこれをやるのか?の背景をきちんと伝えることで、常に納得感を持ってコーディングしてもらえるようにする
  • 自分自身が、今なにを考えているのかなどの頭の中の様子を常にSlackのtimes等で発信

情報のフローを整理

Google Driveでの管理で、どこに何の情報があるのかわかりにくく、決定事項が浸透しにくい問題

  • 全メンバーが必要な時に必要な情報を見れる体制を保つ
  • 常に情報は可視化する
  • 当時プライベートで利用していたNotionを導入して、情報の透明性と検索性の向上を促進
  • 「自分は知らないぞ」とか「聞いてない」というような状況を減らす

すぐに吐き出せる開発体制

吐き出す場が少ないと、暗黙的にフラストレーションがスタックする問題

  • 当初はExcelといまはなきWaffleを使って管理されていたものをスクラム体制に変更
  • 少数精鋭でチーム一丸となってコミュニケーションを増やしてトライアンドエラーしつつ、迅速にプロダクトをデリバリーする
  • 違和感はDaily Scrumとその他セレモニーにてすぐに吐き出して解消する

このように、CTOとしてはコードが〜、とか速度が〜、とかアーキテクチャが〜、とかメトリクスが〜、とかもちろん死ぬほど大事なわけですが、それ以前に結局は組織って人間が集まって運営しているわけなので、そこが一番ケアしなくてはいけない部分だよねということを様々な体験から学ばせてもらったなーと思っております。

ここの指針としては成功循環モデルや学習する組織の理論を用いたりしました。

ryuucham.hatenablog.com

もちろんこの価値観に至るまでに紆余曲折ありましたし、テクノロジーの部分もかなり試行錯誤したことが多かったのですが、一番学びが深かったのはここかなと思っています。

最後に

自分に至っては今年の前半までコード書いてましたし、本当にCTOってフェーズや業界ごとにいろいろなスタンスや考え方があります。 もし見てくれた方がいるなら、価値観とか心構えとかなにかしら役に立つことがあればいいなと思います。

また、主体的に動く経験をさせていただいた奇兵隊という組織には本当に感謝していますし、一緒にやってきてくれたメンバーにもめちゃくちゃ感謝しています。 直近の事業も応援していますし、少しでも何かしら関わっていけたらなと思います。

個人の今後としては、テクノロジーや組織開発についてより多くの知見を得たり、実践を増やしていきたいなと思っていますので、もっと色々な方とお話ししていきたいなと思っています。

時間が余ってるなー、ちょっと軽く飲みながら組織開発やテクノロジーの話したいなってなったら気軽にお声がけください。

2022年もお疲れ様でした!