CTOを引き継ぐということ

カケハシ Advent Calendar 2024の25日目の記事になります。

こんにちは、カケハシでCTOをやっているゆのん(@yunon_@phys)です。

様々なスタートアップやベンチャーでCTOの肩書を持った方が、入れ替わっているのを観測しています。かくいう私も、創業メンバーに近かった海老原さんからCTO のポジションを今年の3月より引き継いでいます。私自身はこれまでのキャリアでCTOになったことはなく、これまでに無いリーダーシップが求められています。まだ9ヶ月という短い期間ではあるのですが、この期間にどんなことを考えどんなことを実行していったのか、はもしかしたらそういったリーダーを引き継ぐ方の学びになるかもしれない、と考えました。そこで、CTOを引き継いだ後に私なりにどのようにリーダーシップを発揮してきたのかを本エントリで書いていきます。

CTOと名乗り、退路を断つ

CTOを引き継いだと書きましたが、私が開発組織の取りまとめをやることは決まっていたのですが、実は当初CTOという肩書きにするかどうかは決まっていませんでした。どう名乗っても良いよ、とCEOの中川から言われていました。

カケハシはテックカンパニーであり、これからもテックの力で医療ドメインをアップデートしていく会社です。しかし、そうやってテックカンパニーとうたっていながら、開発を取りまとめをする私が仮にCTOと名乗らないのだとしたら、私なりの覚悟が足りないのでは？と考えました。

CTOを名乗らなくても良い理由はいくらでも作ることは出来ます。でも、それはどこか自分以外の誰かに最後の責任を負ってもらうことを期待しているのではないか、そのような姿勢で本当にこの難易度の高い領域に向き合っていると言えるのか、と自問自答しました。悩んだ末、中川との1on1で、CTOと名乗らせてくださいとお願いしました。これは、カケハシひいては医療ドメインのアップデートに対する私なりのコミットメントです。

開発組織のミッションをつくる

会社としては「日本の医療体験を、しなやかに。」というミッションを掲げていて、しなやかというワードチョイスが会社文化・行動指針を一言で表されていて、私はとても好きなミッションです。一方で、このミッションを達成するための開発組織としての行動指針があった方がやりやすいなと思ったので、開発組織のミッションを新たに作ることにしました。最終的には「医療体験が日々進化する世界の実現」というものにしたのですが、この文言は一枚の画像をぼーっと眺めていてふっと湧いてきたものでした。

その画像がこちらです。

これはカケハシのWebサイトに載せている画像で、ここに写っているお二人はカケハシの社員です。薬剤師役の方は本当の薬剤師です。

薬剤師の方が端末画面を指差しながら笑顔で話をしていて、それをにこやかな表情で聞いている患者の構図です。私たちの開発組織はこの端末に表示されているシステムを開発しています。それは現状システムとして必要とされているからというのは確かにありますが、私たちの開発するシステムを介して、この画像で表現されている和やかな空間を作り出したいんだということに気がついたのです。だから、技術やシステムといった言葉をあえて使わないミッションにしました。

さらに、私たちは医療体験を進化させようとしていますが、進化は突然起きるものではありません。近年世間を賑わしている生成AIも突然出てきた技術ではなく、人類の歴史を通した日々の研究の積み重ねによって出てきたものです。なので、無理なジャンプアップを狙うのではなく、日々の積み重ねの延長線上に医療体験の進化はあるんだと信じることが大事だという価値観を持って目の前のコトに向かうことの大事さを”日々”という言葉に込めました。

そういった様々なことを考えた末に、「医療体験が日々進化する世界の実現」というミッションにしました。文言としてはすごくシンプルですが、いろいろあってもやはりここに戻ってくるなあという感覚があります。

技術戦略を描きつつ、目の前の課題に向き合う

CTO直下の組織として技術戦略室をつくり、カケハシとしてこの2-3年かけてどんな技術を追うべきなのかを議論してきました。紆余曲折はあったのですが、来年度の予算を作る過程で、なぜ技術に投資をしなければいけないのか、なぜそれが今なのか、をクリアにしていきました。ここの細かい過程は昨日の@kimutyamのブログに書かれているのでそちらを見てください。

技術戦略が決まり、戦略に沿ったアクションをしていこうと動き出そうとしたとき、それを今やるべきなのか、その前にやるべきことがあるのではないかという声が上がりました。私の頭の中には戦略を作ったら、そこからの逆算で作戦・戦術に落とし込んで実行していくものだ、と思い込んでいました。戦略はありたい姿を埋める手段になるので、この落とし込み方は誤っていません。一方で、我々は既にMusubiシリーズというプロダクトを持っていて、多くの調剤薬局を支える基盤となっています。こういったプロダクトやそれを開発している体制に例え理想(戦略)とのギャップがあろうと、そのギャップを埋めるための目の前の課題の解決に向き合うことも大事なのだということに気付かされました。

つまり、私の気づきとしては、「理想からの逆算で進めるのか」「改善の延長線上で進めるのか」と二項対立で捉えることをやめることでした。両方を見ながら、どうやって理想の状態と改善の延長線をなめらかに接続させられるように組織的にうまく動いていく状態をつくるか、を考えて実行していくことが重要なのだと捉え直しました。

各チームの状況把握を1on1や定例に頼りすぎない

開発組織としては150人規模、EMは約10名という中で、さすがに情報同期を1on1だけで実施するのは無理だと考えました。そこで、非同期でのコミュニケーションとして週報をEMに提出してもらうことにしました。週報という報告書の形式にしたのは、うまくいったこと・改善すべきことを週次で洗い出すことつながるので、業務の質を週単位で向上させられる効果があると考えたためです。週報のフォーマットとして、「相談したいこと・気になっていること」という欄を設け、報告するまでも無いがちょっとしたモヤモヤを気軽に書けるようにして、コミュニケーションのきっかけにしたのも工夫のポイントです。頻度については、日報だと多すぎて負担になるし、逆に月報だとリアルタイム性に欠けると考えたので、週報ぐらいが妥当なラインだと考えました。私のレギュレーションとしては2営業日以内に何らかのコメントをつけることとしました。

週報の導入の結果として、やって良かったです。問題を察知したらすぐにそのテーマについて話す1on1を入れることが出来るし、日常のちょっとしたチームやチームメンバーの良い動きも報告してもらえるようになりました。何より非同期にやりとりするので、お互いの時間を調整せずに済むので結果的にコスト安いと感じています。

開発に集中できる環境をつくる

我々の提供するシステムに対してあるべきものが正しいタイミングで実装され、より使いやすいものになっていくために、どれだけ開発に集中出来る状態になっているか、が肝です。一方で開発を阻害する要因として不具合の対応だったり、急な差し込み業務だったり、あるいは普段のミーティングだったりと様々起こり得ます。

各メンバーがどこに時間を使っているのかを細かく工数をつけてもらい、どのような健康状態なのかをチェック出来るようにしました。

こういった定量化をしていく上で気をつけなければいけないのは、良く見せようとする人間心理です。人間が意思を持ってやる行動(この場合は工数をつけること)に対しては、どうしてもこの心理から逃れられません。そこで、この指標はチームの評価や個人の評価に使わないことを約束したのと、この指標を適切につけるような行動を取るメンバーであると信頼しているという発信をしました。

また、逆に正しく工数をつけようとしすぎるがあまり、ものすごく厳密につけようとてその検討に工数をかけすぎるのも本末転倒です。そこで、全社共通のガイドラインを作り、なるべく工数をつけるときに迷わないようにしました。あとは多少間違いがあったとしても、誤差として受け入れて傾向値を見るので気にしない旨も伝えました。

結果として、工数をつけることで開発にどれだけ時間を使っているのか、保守・運用が想定以上に増えすぎていないか、不具合対応工数がチームを圧迫していないのかというのが見える化されました。また、全社基準としてこれぐらいの割合だと良いよねという目標は作る一方で、チームによって適正な割合は異なります。例えば、チームによっては保守・運用にあえて時間を使うことで、今後の開発効率が良くなるとか、システムの信頼性を上げていくことで障害発生確率を抑えるとか、障害が発生しても問題を最小化するための仕組みづくりをするという状況もありえます。なので、チームにとって今目指すべきでないところにトップダウンの意思決定で向かいすぎないように、チームで指標をどのように使うかは判断してもらうようにしました。

こうやって指標を見える化していくことで、チームはどうあるべきなのか、どのように向かっていけば良いのかを自然と話す仕組みになり、結果として今やるべき開発に集中出来るようになってきています。

開発組織外のメンバーとの接点を積極的に持つ

カケハシ社内では開発とフロント(営業・CS・マーケティング等)が別部署であるため、どうしても組織上の壁が起きやすいです。組織の壁は悪い憶測や高すぎる/低すぎる期待に発展しやすく、実際に私の耳にそういう声が聞こえてくることがありました。私としてはそれは望む状態ではなく、会社として一体感を持ってプロダクト・サービスを作っていきたいし、お互いがお互いを信頼しあえているような状態を作りたいと思いました。

そこで、積極的に開発組織ではないメンバーとも接点を持つようにしました。具体的には1on1や横断課題の相談のミーティングも行ったり、フロントの主催するイベントに出たり、顧客と会話する接点を持たせてもらったり、開発メンバーが全く参加していない飲み会にも積極的に参加したりしました。そうすることで、開発に何を期待しているのかを私自身が理解して開発組織に意識改革と行動の変化を促すようにしたり、逆に開発ではこう考えていますよを代表として伝え続けて期待を調整するということに繋がりました。

結果として、CTO就任当時と比較すると、私以外のメンバーが開発組織外のメンバーと話す機会が増え、会社全体で動いていくという空気感を作ることにはつながっています。もちろん、まだまだ開発としても課題はあるので今の状態で満足しているわけではないですが、少しずつ良い方向に向かっているのではと思っています。

フィードバックを常にもらう

創業メンバーに近い前任から、いきなりわけもわからない人がCTOになるということで、信頼もされていないし、期待もバラバラだろうなと思いました。そこで、毎週フィードバックや質問を匿名で自由に書いてもらえるようアンケートフォームを作り、それに対して私の公開週報で返信するというスタイルを作りました。

湯前の発信や行動が良いねというポジティブな意見をもらうこともあれば、「湯前がCTOになって何が変わったのかわからない」、「もっと成果を出すものだと思っていたけれど期待と違ったので行動を改善して欲しい」、という厳しいフィードバックをもらえたりもしています。

こういうトップポジションについたときに一番あってはいけないのが、そのポジションについた人の成長が止まることだと思っています。なぜかというと、組織のキャップを作ることになり、トップポジションの存在が本来あるべき成長の阻害要因となってしまうからです。厳しい意見は真摯に受け止め改善する、普段の言動やコミュニケーションのやり方でそれが誤解なのだとしたらその自分の行動を改める、という一つ一つを丁寧にやっていくことが私の成長につながり、結果として、組織がより良くなっていきます。

一時期、いろいろあって1ヶ月程フィードバックを止めていたことがあるのですが、再開したときにまずメンバーに言われたフィードバックが、「再開していただきありがとうございます」という言葉でした。言える場を作ることって大事なんだなと改めて認識しました。

意思決定を恐れない

以上がこの9ヶ月間で私がやってきたことの一部です。他にもやってみたけれどうまくいかなかったこと、自分のコミュニケーションが良くなくて組織を戸惑わせてしまったこと、いくつもあります。それでも、その中で自分たちに出来ることは無いか、今よりもどうしたらもっと良いチームになるのか、良いプロダクトを作っていくには何をすれば良いのか、を各々が考える様子を至るところで見ました。その様子を見て私自身が何度も励まされ、そういうメンバーたちのためにも、もっと良い組織や仕組みづくりをしていくぞと誓いました。本当にメンバーに助けられた9ヶ月でした。

何やってもうまくいくタイミングがあるし、逆に全てがうまくいかなくなるタイミングはどうしてもあります。短期的な視点に立ってしまうと、それに一喜一憂してしまうことはリーダーなら誰しもが経験するとは思います。でも大事なのは、もっと中長期の視点で見渡したときに、以前よりも良い状態になってるよねと言えるかどうかだと考えています。一つ一つの意思決定に対して紆余曲折ありながらも、それが良いマネジメントが出来ている、ということだと捉えています。

前述の通り、メンバーに大変助けられているところは多分にあります。でもそういったメンバーたちがいるからこそ、組織を信じて恐れずに意思決定をしていき、前を向いて進もうとすること、それがCTOとしてリーダーシップを発揮するということなのだとこの9ヶ月を通した学びです。