カミナシ社の執行役員 CTO に就任しました
トリ(@toricls)です。
カミナシに入社してから早いもので3ヶ月 + α が経ちましたが、さすがのアーリーステージなスタートアップという感じです。前職では想像もしなかったようなスピード感で激☆動イベントがポコポコ発生し、つい先日書いた入社エントリがすでに遠い過去のことのように感じます。
というわけで、本日(2022年7月1日)付けでカミナシの執行役員 CTO に就任しました。
本記事では、あらためてカミナシという会社やサービス、それらを支えるエンジニアリング組織の話とともに、就任にあたっての今後への思いをしたためようと思います。
CTO 就任の経緯
これまで公にはしてなかったのですが、実はもともとカミナシからの入社オファーは『CTO 候補』というタイトルでもらっていました。僕はこれまで CTO という役割を経験したことがないため、まずは入社して一緒に働いてみて、僕も会社もお互いに期待に応えられそうだったら CTO に就任することにしましょう、という流れのイメージです。
今日まで明言できてなかったのは「CTO 候補として入社しまーす！」なんて書いといて実際には僕の力不足で CTO 就任とはなりませんでした〜アハハハハ〜なんてことになったらあまりにも小っ恥ずかしすぎるからなのですが、最終的に無事 CEO & COO の両名からも認めてもらえ、僕ももっとカミナシの成功にコミットしていきたいという思いから、このたびの就任と相成りました。
『カミナシ』というサービス
まずは私たちカミナシが提供するサービスについて簡単に紹介します。
社名と同名 SaaS である『カミナシ』は、カミナシ社が2020年6月にリリースし、その後 PMF の実感とシリーズ A 調達を社にもたらした B2B プロダクトです。
日常業務の中心がコンピューターではない『現場』仕事に携わるノンデスクワーカーたちが、自らの手で現場のデジタル化を推し進めていくためのサービスで、現場の、現場による、現場のための DX を支える SaaS と言えます。
現時点で最も導入実績が多い食品製造を始めとして、ホテルや小売、飲食、運輸などなど、日本中のあらゆる『現場』において、紙による非効率な業務を現場主導でデジタル化していくことに貢献しています。
そんな『カミナシ』は、前掲のスクリーンショットのとおり、iOS ネイティブアプリケーションとブラウザベースの SPA クライアントを提供しており、それぞれ TypeScript や React/React Native といった技術を利用して作られています。
また、サーバーサイドの RESTful API やバッチ処理は Go で書かれており、それらは AWS Fargate や Amazon Aurora といったコンポーネントを利用する形で AWS クラウド上に展開されています。
(本構成図では API サーバーを中心とした主要部のみ記載しており、その他の各種バッチ処理やデータ分析用のコンポーネントなどなどは割愛しています)
そんな『カミナシ』を支えるシステムですが、ありがたいことに、2021年からここに至るまでの1年強でユーザーが1日あたりに『カミナシ』で生み出す記録データは当時の10倍を超える量にまで成長し、開発当初のシステム設計や実装がそぐわないシーンが出てきました。
(プロダクトを作り始めたとき僕はまだカミナシには在籍していませんが、当時のカミナシ社はピボット直後で会社のランウェイが短かったこともあり、ここまでの大きな伸びを想定しきるための時間や心の余裕がなかったであろうことは想像に難くありません。)
というわけで、サービスとビジネスを今後も力強く継続的に成長させていけるよう、まずはここに真摯に向き合うことにしました。
サービスとビジネスを今後も力強く成長させていくために
今年の年末(2022年12月末)までに、中長期的な価値を犠牲にしなくともスプリントの6割を純粋な機能開発に充てられるチームになることをゴールに、5月下旬から技術的な負債の返済をプロジェクト化して取り組みはじめました。
"技術的負債とは何か"についてこの記事であらためて論じることはしませんが、
(1) 設計や実装の当時に最適解と考えていたものが
(2) 時間の経過とともに最適ではなくなった結果
(3) その最適と現状との間に生まれる差分である
と僕は考えています
プロジェクトの第1弾は5月下旬から6月末(まさにこの記事を書いている今日)までの5週間で、エンジニアリングの生産性や直接的な価値に繋がっていなかった複雑なパッケージ構造やコードの整理を進めてきました。お客様の業務を止めてしまうクリティカルな不具合の修正や問い合わせへの対応を除き、原則としてすべての機能追加と不具合修正に関する業務を停止して取り組みました。
本題から逸れるので注釈扱いにしますが、本来技術的負債というのは継続的に返済されていくべきものです。プロジェクト化しなければならないほどに負債を溜め込んでしまうことがそもそも誤っていると言えます。
特に SaaS のような継続的進化を前提とするビジネスモデルをとる企業にとっては、これはエンジニアリングだけではなく誰しもが共通認識として持つべきものです。
この考え方に理解を示した上で、僕を信じて負債返済のプロジェクト化を受け入れてくれたカミナシの経営陣やビジネスチームには本当に感謝しています。
そんな6月末まで進めてきた返済プロジェクト第1弾は非常に順調に完了し、この先コードに手を入れていくハードルを一気に下げられたという実感があります。また、既存メンバーだけではなく、今後入社予定のソフトウェアエンジニアたちにとってもコードベースの認知コストが下がることで、これまで以上に短い期間でオンボーディングを完了できるだろうという期待に胸が躍っています。
(※スクショ中の "harami" はサービスのコードネームです)
ただし、現時点では重要な技術的負債をすべて返済し切ったわけではありません。今後はスプリントの一部を通常業務に戻しつつも、優先順位が高い負債を継続的に片付けていくための時間を一定程度確保する形で2022年末までの計画を立てています。
例えば現状の機能要件や仕様が想定できていなかった部分を整えたり、エンタープライズな顧客の増加によってこれまで以上に重要度が増してきた非機能要件に力を入れたり、あるいはインフラや運用にいたるまで、息切れせずに安定して継続的な機能開発をしていける & 運用改善や新たな技術的負債の返済に継続的に取り組んでいけるチームになることを目指し、力強く取り組んでいきます💪
カミナシが目指すエンジニアリング組織のカタチ
次は少し話を変えて、これからカミナシが目指していくエンジニアリング組織の形について紹介しようと思います。
以下は、この先のカミナシにとって理想と考えられる組織の形について述べています。
状況やサイズの異なる企業にとっては、これらが当てはまらない、あるいはもっと良い形があるかもしれません。
すべてはオーナーシップ
経験上、優れたサービスを作るチームには、そのサービスに対する強いオーナーシップが明確に存在します。そのサービスを良くしていくのは自分たちなんだという認識と自覚、責任感なしには、優れたサービスを作ることが難しいとも言い換えられます。(余談ですが、継続的な改善を前提としたプロダクトを外注で作る難易度が高いと言われがちなのには、発注者と受託者の間でオーナーシップの所在が不明瞭になりやすいところにもその理由があると僕は考えています)。
では、どのようにして、オーナーシップの所在を明確にし、かつそれが一時的なものではなく継続可能なものにするか。
開発チーム自身がシステムを運用する
カミナシでは、システム運用の責務は開発チームに帰属すべきものであると定義します。システム運用を開発チーム外に丸投げする体制、あるいは丸投げを誘発しかねない体制は採用しません。
これは僕のエンジニアリングにおける信念の一つでもありますが、開発者が「コードを書いたら終わり、運用は誰かがやってくれる」というマインドセットでは、品質の高いコードやサービスは生まれません。(あるいは生まれることもあるのかもしれませんが、そんな超人が世の中にたくさんいるわけではないと考えています)。
品質の低いコードを書いたことで自らがページングされる、あるいはそのようなコードに起因して困っているお客様と真摯に向き合うことで、はじめて製品の品質に対してオーナーシップを持てるようになります。
加えて、短い期間で組成と解散を繰り返すような短期プロジェクト主体のチーム体制も、システム運用に対するオーナーシップが行方不明になりやすいことから、現時点ではおそらく選択しないと言えます。
安定したシステム運用は SaaS の重要な機能の一つであり、社内・社外に関係なく、誰かに投げて良いものではありません。
SRE、QA、プラットフォームの類を安易にチーム化しない
これらの安易なチーム化によって、結果として開発者に「XXX は自分たちではない誰かがやってくれる」と考えさせてしまうような組織設計をとることも、現在のカミナシにおいて必要なオーナーシップが損なわれかねない誤った選択だと考えています。
システムデザイン、サービスの信頼性、品質、セキュリティ、インフラストラクチャ。そのどれもが本来開発者自身がオーナーシップを発揮すべき事柄です。広義では、このセクションの内容も前セクションと同様の意図を持つと言えるでしょう。
カミナシとは状況やサイズ、優先順位が異なる組織においては、これらのチーム化が必要不可欠と言えるケースが数多く存在するであろうことはもちろん理解しています。
また、仮にチームがそれぞれ独立していたとしても、見事なエンジニアリングカルチャーと、よく設計されたチーム間インターフェース、責任分界点によって、きちんとオーナーシップが維持された成熟した組織も少なくはない実例を過去には見てきました。
ただし、今のカミナシの状況においてはそのような分割されたチーム体制である強い必然性がないこと、加えてオーナーシップを維持したままそれらを実現するのはあまりにも高コストであると考えていることから、思考停止のチーム化を避けようとしています。
これは、「カミナシには "SRE" という役割に定義されるミッションそのものが不要である」とか、「(サービス特性や中長期の視点を無視して)インフラ管理が不要な外部サービスを使えばいい」とか、そういったニュアンスではありません。
ここで伝えたいことは、優れたサービスを提供するためには、これらの重要なファンクションがすべて開発チームに内包され、外部チームに依存することなく、サービス提供のために自律的に動ける状態こそが理想である、ということです。
これら内包すべきファンクションを安易に開発チームの外に切り出してしまい、「あっちのチームがやるはず」という負の依存状態を作ってしまうと、デリバリ速度の低下を招くだけでなく、チーム間の不毛な責任の押し付け合いにも繋がりかねません。
そして、ひとたび組織がこういう状態に陥ってしまうと、それをあるべき形とマインドセットに戻すのに多大なコストが発生するというのは、多くのソフトウェアエンジニアのよく知るところかと思います。
では、このあたりにスペシャリティを持つ人材を単にチームに配置すれば十分かと言うと、それだけでもやはり意味がありません。仮にその時点でスペシャリティを持ち合わせていないチームメンバーであっても、将来的に自らもその領域において貢献できるよう、チーム内の互いの成長を促す仕組みが必要です。
「チーム内での外注」も防ぎ、チーム全体のオーナーシップを高く維持することで、チームにファンクションを内包させる本当の価値が発揮される状態をカミナシは目指していきます。
カミナシとカミナシエンジニアリングの強み
最後に、優れたプロダクトを作るためには絶対に欠かすことのできないと僕が信じている、カミナシとカミナシエンジニアリングの強みを紹介して締めようと思います。
ユーザーの声に耳を傾ける。これは昨今のプロダクト開発においては当たり前のことに聞こえるかもしれません。でも、実のところその実践はとても難しいことです。
(自分も含め)我々ソフトウェアエンジニアは、問題解決の手段であるはずの技術そのものに無意識のうちに傾倒しがちで、ともすればユーザーのことを置き去りにした内向きなモチベーションで仕事に臨んでしまうことに身に覚えがあるはずです。
カミナシには「価値のある、良いプロダクトを現場のユーザーに届けたい」という強い想いを持ったソフトウェアエンジニアが数多くいます。彼らはユーザーの現場に自ら赴き、お客様のペインに直接耳を傾ける重要さを知っています。カミナシ社員のあるべき姿を言語化したバリューの一つである「現場ドリブン」という言葉には、まさにこの姿が投影されていると感じます。
この1年で大幅にユーザーが増えたことで、すべてのソフトウェアエンジニアがすべてのユーザーと会話をすることは当然ながら物理的に難しくなってきました。しかし、プロダクトマネジメントやカスタマーサクセスといったチームとも協力しながら、常にユーザーペインのダイレクトな理解に努めることを重視する姿勢は変わりません。
エンジニアリングやプロダクト組織に限らず、会社全体が自ら現場のペインを理解することの重要さを知り、掲げているというのは、間違いなくカミナシの財産であり強さの源泉の一つです。
個人的な話
ここからは僕個人のポエムです。
これまでの仕事の中で各社の CTO 職にある方々と会話をする機会は幸運なことにたくさんありました。しかし、自分自身が CTO 職を務めるのは今回が初めてで、右も左も分からないなか様々な組織課題に対して日々思索を巡らせ、試行錯誤を繰り返しています。
僕はもともと仕事の結果や発生する出来事を他責にするタイプではないと自認しているし、日頃からそれを気をつけてきたつもりなのですが、経営者となると本当に他責はできません。
「する (Do) / しない (Don't)」ではなく、「できない (Cannot)」。なるほど、これが経営者の難しさや大変さ、そして面白さの一つなのかと心がゾクゾクしています。
仮に売上が伸びなくても、もしチャーンが続いたとしても、なかなかエンジニアリングの生産性が上がらなかったとしても、人材採用がうまくいかなかったとしても、それはどれをとっても社内の誰かのせいではなく、経営の責任。ゾクゾクします。
とはいえ僕は現時点では CTO やマネジメントとしての経験が豊富ではありません。カミナシに入社してからのたった数ヶ月の間に何度も失敗しながら、学びながら、助けられながら、CTO として成長し、それを通してカミナシやその先にいるユーザーに還元できるよう努力しています。
そして今から何年後なのか、まだクリアな青写真は描けていませんが、いつかカミナシを日本で有数の、世界に誇れるテックカンパニーにしたいという想いがあります。
そして、そこに立ちはだかるであろうたくさんの未知の壁を乗り越えていくために、もっとたくさんの優秀な仲間にカミナシに来て欲しいと思っています。
長文を最後まで読んでいただき、ありがとうございました！
FAQ
Q: 一緒に壁を越えていきたい場合はどうすれば良いですか？
A: カミナシ求人一覧からのご応募をお待ちしております！
あるいはカミナシの採用情報トップページはこちら↓
Q: 壁を越えるために採用サイトを見たのですが、希望のポジションが公開されていませんでした。どうすれば良いですか？
A: 事情により現時点で採用サイト未公開のポジションが複数あります。カジュアル面談なんかで紹介できるポジションもあるので、Twitter DM からぜひトリまでご連絡ください！
Q: FAQ に聞きたいことが載っていません
Q: 雑談したいです
A: Twitter DM から、ぜひご連絡ください！
Q: Chief Tori Officer ですか？
A: いいえ、Chief Technology Officer ですね
この記事が気に入ったらサポートをしてみませんか？