CTO室のソフトウェアエンジニアの@yuya-takeyamaです。

最近はだし道楽の自販機で買った焼きあご出汁で卵焼きを作るのがマイブームです。鍋・おでん・麺類など幅広く活用できるので、冬には欠かせません。

CTO室の紹介

周囲の友人等に手短に話すときは「情シス的なこととか、コーポレートエンジニアリングとか、セキュリティとか」などと言った感じに話しますが、より正確にはCTO室の目的は次のように定義されています。

我々は社員・部・全体の生産活動に対して次の責務を持つ
1. 情報システムを活用し、ポテンシャルを最大化すること
2. セキュリティ・プライバシーリスクを最小化すること
3. 1および2の最適化により、生産活動の目標達成を最短・最大にすること

言い方を変えれば、攻めと守りの両方の側面において、全社に向けてイネーブルメント ¹ を行なったり、プラットフォームを提供したり、その運用をしている部署です。LayerXには開発・データ・Biz等の、より特化した領域においてイネーブルメントやプラットフォームの提供を行っている部署もありますが、CTO室は一番広範囲の人々に関わっていると言って間違いないでしょう。

のびしろウィークとは

今週はLayerX Tech Advent Calendarにおいて、「のびしろウィーク」という施策を行っています。

LayerXは採用関係のフィードバックにおいて「すでにすごいエンジニアがたくさんいて、もういい感じにやってそう」といった感じのフィードバックをいただくことが多く、私自身も入社前はそういった印象を持っていました。

確かに素晴らしいメンバーに囲まれた環境ではありますが、それでもやりたいことに対してできることは限られており、どの部署も数多の選択肢、やりたいことの中から、苦渋の思いで絞って業務を遂行しています。

そんな、やりたいけどやれていないこと、「のびしろ」にフォーカスすることで、より多くの人々に興味を持ってもらったり、実際に働くイメージを持ってもらうために、この施策を提案しました。

CTO室ののびしろ

人・組織・デバイス等あらゆるエンティティーのデータベース化による管理能力の向上、その継続的進化

社内のあらゆるエンティティーのライフサイクルを支える上で、データベースは重要です。

現状、Identity ProviderとしてはMicrosoft Entra ID (旧Azure AD) を利用しており、シングルサインオンによる各種SaaSへのログインや、SCIMによる自動プロビジョニング等に利用しています。ですが、Single Source of Truthになっているとは言えず、サービスによっては二重管理のようになっているものもあります。

特に大きいのは入社者の情報が最初に登録される「入社マスタ」と呼ばれるNotion上のデータベースで、これはHR Opsの方々により、氏名、所属先の部署、契約形態などが手入力されたあと、さらに別の部署のメンバーの作業により、Microsoft Entra IDやSmartHRといったサービスへのアカウント登録が、これも手動により行われます。

(厳密には、Entra IDへの登録自体はAPIを使って行われていますが、その自動化システムへの登録が手動です)

関連: オンボーディング関連のシステム作業の時間を87.5%削るまでの軌跡

また、入社マスタにおける部署名についても、一応の記入フォーマットらしきものはふわっとありますが、データベース上にマスターデータを持つものではなく、加速する組織の拡大やチームの分割といった変化への追従が苦しくなっている状態で、組織名やその構造をデータベースで管理する必要性を感じています。

そもそもNotionでどこまで行っていいのか、というところも不安材料です。おそらくいつかは脱Notionするでしょうし、段階的に変化させていくことは間違いないと思いますが、それをどこからどの順番で、どれぐらいの時期感でやるのかは何も見えていません。

また、重要なポイントとして、これらのNotionデータベースはほとんどがソフトウェアエンジニアではないメンバーによって作られてきているということです。彼ら・彼女らはWebアプリケーションの開発やデータベースの設計経験は当然ありませんが、自分たちが関わる業務フローについては深く理解しており、そんな人々が自らデータベースとプロセスを一体の物として作り上げることはBet Technologyを行動指針に持つLayerXにおいて、個人的には重要なポイントだと考えています。

必要に応じて、ソフトウェアエンジニアであるところの私などが改善していくことも当然必要だとは思いますが、こちらでイネーブルメントという形でサポートしていくようなやり方なども必要に応じて選択していくことで、社内のあらゆるエンティティの管理能力を向上させていくことにもチャレンジしていきたいです。

権限管理能力、資産管理・脆弱性管理・パッチ管理能力の向上

同じく管理能力についてですが、こちらはよりセキュリティ・ガバナンスに特化したものです。

権限については前述のとおりMicrosoft EntraIDによるシングルサインオンや自動プロビジョニングを行なっており、この規模 (執筆時点で二百数十名) のスタートアップとしては、それなりに投資ができている方だとは思います。

ですが、インシデントに繋がりかねないヒヤリハット事例なども起きてきており、フェーズの変化を感じているところでもあります。

権限に関しては最小権限の原則を徹底することはもちろんですが、管理者権限の付与に関するオペレーションを自動化で支えたり、アカウント管理者への教育、Audit Logによるトレーサビリティの確保、SIEMを用いた相関的な分析による脅威の検出など、さまざまな方向で、それもソフトウェアと組織の両面での取り組みが必要です。

(以下のパートのみ、CTO室のマネージャーであり、セキュリティに一番熱い思いを持っている@ken5scalに書いてもらいました)

また、資産管理、脆弱性管理、パッチ管理についても、たくさん伸びしろがあります。

当社はMicrosoft Defender for EndpointやAWS等のプラットフォームの機能を使い、適時管理・対応しています。しかし、その複雑性・カバレッジ範囲はいくらでも広がります。

例えば、ブラウザの拡張アプリ、デスクトップにインストールするアプリ、ソースコードの依存先（そしてその先の依存先）など等、考えれば考えるほど沢山あり、それらを管理するには更に追加の技術が必要になります。

また、多岐に渡れば渡るほど、それらから収集できる情報はノイズとなっていくので、適切なアクションにつなげるための、インサイト化・インテリジェンス化も見過ごせません。そのためには、適切なデータ構造を念頭に置いた、情報のリレーションが欠かせなくなります。

単純なソリューションに依存した管理だと、それが難しいです。

そのため、利用ケースから逆算し、プロダクト指向のもとデータ管理をエンジニアリングし、適切でチームの運用レベルにあった自動化をしていかねばなりません。例えば↓みたいな感じで。

私見をいうと、これらのデータ構造はグラフモデル化していきたいと思ってます。

https://www.ncsc.gov.uk/blog-post/so-long-thanks-for-all-the-bits

imagine you could model an entire network as a graph with the nodes representing functions, data sources, bits of kit and so on, and the edges representing the relationships between them

あらゆるリソース・設定のInfrastructure as Code化

LayerXにおいてはInfrastructure as Codeのツールとして、Terraformが広く利用されています。AWSやGoogle Cloudなどのリソースに関してはそれなりにInfrastructure as Code化ができている状態ではあります。

これをさらにAzureやMicrosoft Entra、Google Workspaces等においても広げていきたいと考えています。

LayerXのアプリケーションはほとんどがAWS上で動いていて、データ基盤・ML基盤ではGoogle Cloudが活用されていますが、Azure OpenAI Serviceの登場などによりAzureを活用するシーンも増えており、マルチクラウドへの対応の重要性は増すばかりです。それらを統一的な構文で扱え、エコシステムも発達しているTerraformは、ベストなツールだと考えています。

Microsoft EntraやGoogle WorkspacesのリソースをInfrastructure as Code化していくことは、前述の権限管理能力の向上にも繋がります。社員のUserに関しては別のアプローチでの管理となりますが、一部存在する共有ユーザーやサービスアカウント的なものはmoduleとしてある程度の定型化をすることによるメリットがあると考えます。

また、CTO室への社内への依頼のうち低くない割合を占めるのはGoogle Drive上での他社との共有ドライブの作成です。ここについては、依頼者のほとんどはソフトウェアエンジニアではないことを考えるとTerraformの利用がベストでない可能性も高そうですが、少なくとも設定が何らかコードとして定義され、変更のトラッキングや棚卸しができる状態を作ることは重要なはずです。

Terraformによる設定の適用についてはすでにGitHub Actions上のCI/CDパイプライン上で行われていますが、リソースの量の増加やドリフト検知等の細かい運用に対応していくために、tfactionの導入を進めている段階でもあります。

全社的な人的および事業的拡大とCTO室拡大の非対称性への対処

LayerXは直近で年あたり100人規模の増加をしており、これからもこのようなハイペースでの増加は続きます。また、コンパウンドスタートアップという性質もあり、プロダクト間・組織間の繋がりに関わる複雑性は線形以上のペースで増加していくことが予想されます。

地理的にも、現状すでに東京オフィスの他にも大阪、名古屋、福岡に拠点があったり、フルリモートで勤務する社員も多数在籍していたりと、セキュリティ・ガバナンスを維持する難易度も上昇していくことでしょう。

これに対してCTO室のメンバーを増やして追従していくことも、もちろん前提として必要ではありますが、単純な頭数に頼るだけではない戦略性も必要です。

直近では、今後数年間での大幅な拡大を計画している組織を中心にヒアリングを行い、集まった声を元に優先度の高い事柄を見つけ出そうとする取り組みも行なっていますが、このような情報を収集してそれを元に意思決定をするというプロセス自体も洗練させていく必要があると感じています。

そして、チームとしてのケイパビリティの向上への重要なポイントになるのが次です。

全員エンジニアリングと未知領域への積極的な支援

前述のとおり、CTO室に在籍するのは私のようなソフトウェアエンジニアだけではありません。CorpOpsと呼ばれる運用やそのためのプロセスの設計・構築を行うメンバーや、ヘルプデスクを担当するメンバーもいます。

ですが、その上でチームとしての目的 (最初のCTO室の紹介に書いたもの) を果たすための大方針として、以下を定めています。

(非)機能群をプロダクトとして見立て、組織目標の達成に最適な機会を提供すること
ソフトウェアエンジニアリングの技能やプラクティスを通じて、実現すること
継続的な更新・刷新を果たすこと

これはCTO室内の全員が共有するものなので、全員が何かしらソフトウェアエンジニアリングの技能・知識を身につけ、活用していくことを目指しています。

それには、全員がバリバリコードを書いていくとまではいかなくとも、必要に応じて多少のコードは書くこともあるでしょうし、Zapierのようなノーコードツールであれば現時点でもかなり活用していますし、前述のとおりNotionもその一角で存在感を放っています。そこに対して私はソフトウェアエンジニアとしてイネーブルメントのような形で積極的に関わることで、チームの成長を加速させていきたいと考えています。

また、現代的にはChatGPTをはじめとするLLMを活用していくことも積極的にしていきたいところです。LayerXではAI・LLM事業部が誕生していたりとLLMの活用に積極的ですが、これはやはりソフトウェアエンジニア以外も活用できてこそ本当のインパクトを発揮すると考えています。経営陣もそういったメッセージを社内外で頻繁に出しています。

参照: LayerXの理想の営業組織を夢想する。 AIとデータによる営業生産性革命

ここにおいては、ソフトウェアエンジニアたる私自身も、ゼロから学ぶ必要があると考えています。わかりやすいところで言えば、RAG (Retrieval-Augmented Generation) による問い合わせへの一次応答の自動化・効率化は少しずつ始めて、方法論自体への解像度を上げることから始めたいと考えています。