エンジニアにとって”気持ち良い”組織になる──CTO室が目指す開発体制の進化

私はもともとプロダクト本部の下にあるPlatformグループに所属していたのですが、当時から全社的な開発体制の「横軸の改善」を担うチームとして活動していました。

ただ、事業会社ですから、個々の機能のリリースや突発的なパフォーマンスの改善などのほうが、どうしても優先されます。その都度いろいろなチームにヘルプとして呼ばれる、というような状況でした。正直、それだと横軸の改善作業は全然進まない状態だったんですね。

ですから、いわゆる全社的な改善作業をするチームを切り分けようというのが、CTOの松下さんが、これまでのプロダクト本部とは別にCTO室という組織を立ち上げた意図だと思います。

私は、入社当初からCTO室に配属されることが決まっていました。どんな会社でも抱える悩みだとは思いますが、プロダクト開発を続けていく中で、どうしても組織全体の不整合が生まれてしまう。長い視点でビジネスを考えるのであれば、どこかでそれを解消しなければなりません。

そんな話をCTOの松下さんとしていて、インフラからシステムまで俯瞰的な視点で見てほしいというお話を受け、入社を決めました。

現在、CTO室には10名のメンバーが所属しているのですが、4つのチームに分かれています。フロントエンドの問題を解決する「FEST（フェスト）」、バックエンドに関わる技術負債を解消するための「BERT（バート）」、全社的な技術課題の解決をする「＋（クロス）SRE」、そして「採用チーム」です。

この中の「BERT」というチームに、私と富所さんは所属しています。

私が松下さんからまず言われたのは、現状の複雑化したソースコードの問題を解決して、開発効率を上げたいということです。その際に出されたキーワードが「マイクロサービス化」というものでした。

システム全体を単一な構造（モノリシック）ではなく、機能ごとに独立したアプリケーションに分割する「マイクロサービス」という手法は、当時からある種のバズワードになっていました。ただ、バズワードの多くがそうであるように、手段ありきで進めようとすると上手くいかないことも多い。「じゃあ実際に『カオナビ』の開発体制を良くするために本当に必要なことは何なのか？」と考えていくと、そうではないことが見えてきました。だから今は「リアーキテクチャリング」が必要だと定義しなおしています。

私たちのミッションは、マイクロサービスを実現することにあるのではなく、「カオナビ」が提供する既存の価値を毀損することなく、さらにサービスの質やエンジニアの開発体験を改善することです。それをリアーキテクチャリングと呼んでいます。

そのために、今は「カオナビ」の仕様を一から調べなおしています。複雑なソースコードを解きほぐし、ドキュメントを漁って過去の失われた知見を見つけ出してくる。

そうして見つけた問題を改善するために、まずはプロトタイプを作って試してみて、改善できそうならリリースまで持っていくというような活動をしています。1年半くらいやってきて、ようやく全体像が見えてきたというところで、これからさらに改善のエンジンをかけていくつもりです。

技術的負債の解消が難しいのは、それを評価する基準が明確でないことです。実際、私たちもまだ確固たるKPIは見つけられていないのですが、まずは循環的複雑度などで数値化しながら、社内的にこの活動の意味を積極的に提示していこうと考えています。

開発手法は、目的や規模によってその都度変わってきますね。アジャイルでやる場合もあれば、昔ながらのウォーターフォールを採用することもあります。

例えば、私は「カオナビ」に付随する検索エンジンのシステム改善を担当しています。簡単に言えば、これ以上検索の負荷がかかると結果表示に不具合が出てしまう状態にあります。そのデータの入れ方を工夫することで、検索の負荷を下げるという取り組みをしているところです。

この検索システムは比較的規模が大きく、目的が明確でステークホルダーが多いため、設計などの上流工程をきちっと決めておく必要があります。ですから、ウォーターフォールの開発方式を採用して、要件定義の段階からCTO室として関わっています。逆に、富所さんがやっているような仕事は、アジャイル式でやっていくほうが適していますよね。

CTO室の役割は、課題を自分たちで見つけてきて、それを改善することです。課題はたくさんあるので、できることから手をつけていくしかありません。その際に意識しているのは、「カオナビ」の開発効率が上がって、より顧客に対する価値提供をスムーズに行えるようになることです。逆に言えば、そこさえブレなければ手法は何でもいい。

そうですね。CTO室のメンバーは一人ひとりがすごくパワフルで、そうした臨機応変なやり方を実現できる能力や経験を持っている人が多い印象です。

抽象的な課題に対して、ちゃんと答えを出すことができることですね。それから大前提として、周りの人とのコミュニケーションを上手くとれることでしょうか。全社的な課題を解決するための専門性＋人間力があれば理想的です。

私自身、普段からあちらこちらの部署に突撃して、「こんなことやってるんだけどどう？」といった感じでSlackなどで話しかけています。他のメンバーもいろいろなところに顔を出しているようですし、それがいざという時に助けてもらうことにもつながりますから。

私の担当している検索基盤の技術は、他の部署の人も関心が高いジャンルなので、オンラインミーティングは基本的にオープンにして、誰でも聞けるようにしています。そこから新たなコミュニケーションが生まれることもあります。これはリモートワークの恩恵でもありますね。

CTO室で働く人に持っていてほしいのは、”謙虚さ”です。富所さんが言うように、CTO室は他の部署とのコミュニケーションが求められますが、それはお互いの思いをしっかり情報伝達して理解し合うことが仕事に不可欠だからです。

海外のシステム開発の現場でも、技術力よりも謙虚さを重視して人材を集めているという話を聞いたことがあります。

そのために、CTO室内だけで物事を決めずに、最初からオープンな議論にしていくことを心がけています。例えば、私が今進めているアーキテクチャ変更についても、草案を作った段階で情報を公開して、全社から意見をもらおうと思っています。

CTO室は全体最適化を目指す部門ですが、トップダウンで現場に押し付ける形になると、どうしても現場は「やらされている」という気持ちになってしまう。そうではなく、できるだけ民主的なプロセスを踏むことで、CTO室のやろうとしていることを応援してもらえるような形にしていきたいですね。

会社に取って必要なのは、みんながオーナーシップをもって仕事をしていくことです。もちろん、専門性が高くなればそれぞれが理解できないことも増えますが、それでも議論の始まりで問題点と解決方法を共有することで、納得感を増すことはできるはずです。

その意味で、私がもう1つCTO室の人材に必要だと思うのは、向上心です。「こうすればシステムがもっと良くなるのではないか」という気持ちが、システムをどんどん進化させていきます。

そのために必要な技術力はどんどん吸収していかなければならない。ただし、気を付けなければいけないのは、単に技術書に載っているような”カッコいい”システムを作ることが目的ではないということです。あくまで「カオナビ」を使う人にとって一番最適なシステムとは何かを追求することが大切です。

もちろん、現時点でメインとして使っている技術はあって、「カオナビ」にはPHPが現状最も適していると考えていますので、PHPに強いエンジニアの方にはぜひ来ていただきたいですね。

CTO室には、バックエンドだけでなくインフラやフロントエンドのメンバーもいるので、全社的な横軸での改善の話が非常にしやすくなったと感じています。

今の段階での目標を一言でいえば、「毀損されている価値を取り戻す」ということです。例えば、Aというチームが開発している機能とBというチームが開発している機能があって、独立して開発した結果、ハレーションが起きてしまっている部分があるとします。

CTO室の役割は、そのハレーションを上手く解きほぐして、それぞれの機能が十全に、かつ相乗効果を持つようにできることだと考えています。

私たちが目指すのは、「気持ち良さ」です。1つはお客様がシステムを使う際に感じる気持ちよさ。それは細かいところで言えば、スムーズに画面が切り替わってストレスを感じずに使えるといったようなことから、やりたいことが実現できるという大きなことまでを含みます。

もう1つは、開発メンバーが感じる気持ちよさ。プロダクト開発のメンバーたちが、より効率的に開発作業できるように改善することで、顧客に提供できるバリューも大きくなるはずだと考えています。