エンジニアブログです。#のびしろウィークのびしろこんにちは!バクラク事業部DevOpsチームです。』という記事を書いてくれました。過去の対外的な発信では社内でうまく行った事例などについては各種発信していましたが、どういう課題があってどういった方の協力を求めているかについての発信はあまり行なっていませんでした。多くの企業と同じように不確実な市場で事業に向き合っているため、うまくいったこともあれば、これからもっと整備したい部分、いわば「のびしろ」もたくさんあります。Engineering部DevOpsグループ」と言います(以下、「DevOpsチーム」と呼びます)。Engineering部」が存在しています。DevOpsチームはその中でも、インフラ・CI/CD・セキュリティといった領域のプラットフォーム機能を開発・運用するチームです。ミッションとして「プロダクト提供における、プロダクト開発以外の複雑性に対して、必要な抽象化を行い、プロダクト開発チームがプロダクトの価値を最速で最大化できる状態を作る」という言葉を掲げています。バクラクのお客様にとっては直接的に価値を感じられる領域ではありませんが、プロダクト開発チームに対してプロダクトの価値提供を最速・最大化できるプラットフォームを提供することで、お客様への価値提供を最速・最大化できると考えています。現在、DevOpsチームには4人のメンバーがいます。DevOpsチームの取り扱う技術領域は広く、それぞれのメンバーに得意・不得意な領域があるため、お互いに領域を補完しあいながら、日々プラットフォームづくりに励んています。DevOpsチームの「のびしろ」これまでの活動を振り返りつつ、改善すべきポイントや新たに取り組みたい課題をリストアップしてみました。以下にその一部を紹介します。新しいプロダクトであるバクラク請求書発行は、全面的にlayerone上に構築しています。tech.layerx.co.jp紹介した記事中で述べている通り、サービス数は単調に増加していく傾向があります。現時点ではすべてのプロダクトは同じ定期リリースサイクルであることから、定期的に50+のサービスが一斉にデプロイ対象となります。共通パッケージの依存関係チェックを厳密に行えておらず、共通パッケージが変更された場合はほぼすべてのサービスが一斉にデプロイされることになります。この状況では以下のような課題があります。弱いオーナーシップこれまでlayerone上に実装された多くのサービスは、それ自体がプロダクトを強く構成するサービスではなく、またプロダクト間を繋ぐ機能や共通利用されるサービスであることから、オーナーシップが相対的に弱い状態になっています。layeroneの仕組みに詳しいDevOpsなどプラットフォーム側のチームがデプロイ開始のトリガーを行い、サービスのデプロイまで行っています。プラットフォームチームはデプロイするサービスの中身をすべて熟知しているわけではないため、適切なオーナーに移譲していく必要があると考えています。デプロイ順序の弱い解決サービス間には当然ながら依存関係があります。サービス間通信に利用するパッケージ依存をチェックすることで、ある程度機械的に解決していますが、layerone外のサービスを含め完全な解決ができていません。定期リリース時はドキュメントに変則的なデプロイ手順が書かれることもあり、最終的には人間がデプロイ順序を解決しており、リリースにかける負担が大きいことが問題です。フロー効率を重視することから、一人の実装者が破壊的変更を含む変更を複数のサービスに適用し、定期リリースで一気にデリバリーすることもあります。これはマイクロサービスの前提である独立デプロイを諦めていることになります。現時点での開発リソースや開発スタイルでは最適かもしれませんが、今後さらに開発者が増えたり関心事が増えると難しくなるのではという懸念があります。Actionsを動かしデプロイするCIOpsを行っています。deployを行うWorkflowが走ります。これらのActionsは疎結合に構成されており、それぞれのサービスに対して専用のものがあります。APIが悲鳴を上げることがしばしばあります。eventで起動するはずのWorkflowが起動しなかったりします。Runnerに変えたとしても解決しないのではないかと思っています(まだ実際に検証できていません)。デプロイPRの作成やデプロイを今よりゆっくり行えば安定性の問題は回避しやすくなる一方、全体のデプロイのリードタイムは伸びてしまいます。以上の課題に対して、まだ道半ばですが以下の取り組みを行っています。Groupを立ち上げました。次のような活動をしています。破壊的となる変更の整理とドキュメンテーション、CIによる破壊的変更の検知layeroneで構成されたプロダクトを対象に、ステージング環境で独立デプロイの試行バクラク請求書発行を対象とした独立デプロイの試行では、依存するバクラク共通管理の変更がまだリリースされていなかったことが原因で、一部機能が使えなくなる発見がありました。バクラク共通管理は最も他サービスへの依存が少ないプロダクトであるため、バクラク共通管理を独立してデプロイできるようにすること次のゴールとしています。オーナーシップの意識monorepoでCODEOWNERを設定してCODEOWNERのapproveを必須としたり、プロダクトをまたぐ機能を開発運用するチームを明確化してデプロイを移譲する取り組みを現在進行系で行っています。DocsやADRなどのドキュメントとして残すようにしています。ドキュメント間の関連やオンボーディングの観点では改善の余地があると考えてます。前述した通りサービスが増え続けると、サービス自体やサービス間の関連を理解する助けが必要になります。Mapなど組み込みの機能が役立つこともありますが、この領域にはまだあまり投資できていません。依存関係だけでなく、ドキュメント、コード・インフラリソースへ一発で辿れたり、CIやモニタリングダッシュボードと紐付けたりすることで、開発者にとってもプラットフォームチームにとっても便利なポータルを育てていきたいと思っています。Portalに準じるものです。個人的な興味でBackstageを社内クラスタにデプロイして遊んでみたりしています。可能性は感じるものの、使いたいプラグインがmonorepoを想定していなかったり、ECSのプラグインが無かったりとまだ実用段階にはできていません。プロダクト開発チームによるインフラ変更のスループット向上とガードレール整備バクラクではインフラの構成管理にTerraformを使用しています。Terraformのリソース定義の多くは自動生成されており、事前定義したアーキテクチャパターンから所望のアーキテクチャを選択することで、必要なインフラを構築できるようになっています。バクラクにおける標準的なパターンであれば、わずか数行の設定を設定ファイル(Jsonnet)に記述するだけで、本番環境にデプロイ可能なレベルのインフラが監視も含めて構築できます。以下の例は、休日情報を返却するサービスの設定例です。Connectも有効化する、という設定です。))このような数行の設定と、アプリケーションコードを書くだけで本番環境にデプロイできるのは、サービスの開発者にとっては魅力的ではないでしょうか。現実はこのようにうまくいくことばかりではありません。この自動生成にも「のびしろ」が眠っています。いう設定があることに注目してください。Connectを有効化する設定です。昨今、バクラクでは様々なアーキテクチャパターンが生まれ始めており、このような追加設定が増え始めています。結果として、設定が冗長になってしまったり、競合するオプションを設定してしまったりと、設定難易度が上がり続けています。この問題を解決するためには、プロダクト開発チームにヒアリングを行い、アーキテクチャパターンの取捨選択とさらなる抽象化が必要となるでしょう。アーキテクチャパターンによる自動生成ではカバーしない特殊構成や実験的構成については、Terraformのコードを直接書いています。Moduleを整備していますが、ガードレールの整備も必要です。具体的には、semgrepのruleの拡充やTrivyによる静的解析による指摘ができるようにするべきだと考えています。現時点では、プロダクト開発チームだけでインフラ構築が完了するレベルまで、この自動生成システムやドキュメントが成熟していません。そのため、インフラの構築・変更は主にDevOpsチームが行っています。バクラクの爆速開発を支援するには、プロダクト開発チーム自身がインフラ構築・変更を行えるセルフサービス化が必須だと考えています。Directory)を利用しています。ID上には、現時点では「アカウントが割り当てられた人」に関する最低限の情報しか格納されていません。この「のびしろ」について、この章ではお話しようと思います。これまでLayerXは、組織規模が比較的小さく、管理したい権限の種類も多くはなかったため、非常にシンプルな権限管理方法を採用していました。SaaSや社内管理画面の管理者、もしくは管理部署の上長に高い権限を与え、必要な権限を必要な人に随時与えてもらう、といった方法です。バクラクの開発組織における権限管理は主にDevOpsチームが担当していました。LayerXは急成長しており、2025年度に「2025年度に500名体制」を目指しています。note.com組織拡大による権限付与対象の増加や権限種別の増加、及び、複雑な権限付与要件が発生すると仮定した場合、現行の権限管理方法ではすぐに破綻するでしょう。権限管理は、管理者に権限付与を行ってもらうのではなく、権限付与ポリシーをメンテナンスしてもらうように変更する必要があります。そのうえで、権限付与自体は自動化、権限付与ポリシーの変更はガードレール内であれば(定期的に監査するものの)自由に変更が可能という状態を作るべきだと考えています。IDに集約して行く必要があります。おける組織図や「SaaS管理者」といった組織図上には現れないロール情報などです。その情報が継続的に、かつ、可能な限り迅速に反映される状態を作る必要があります。この「のびしろ」はCTO室も認識しており、バクラクDevOpsチームと共同で解決していく予定です。tech.layerx.co.jpこの「のびしろ」をのばした暁には、従業員一人ひとりが必要な権限を最速で与えられ、かつ管理負荷も抑えられ、組織全体の生産性が向上すると期待しています。権限の不適切な付与や使用を防ぐことで、セキュリティリスクも低減できるはずです。おわりに今回はバクラク事業部DevOpsチームの「のびしろ」についてお話しました。今回お話した「のびしろ」は一部であり、他にもたくさんの「のびしろ」があります。気になったら是非カジュアル面談しましょう。Nightというイベントも開催しています。LayerXのメンバーとゆるく組織の話や技術の話ができるイベントです。日本酒をいっぱい飲める会です。今年のクリスマスイブもひたすら料理していました。#のびしろウィークのびしろこんにちは!このブログを書くにあたり、LLMに「のびしろ」のいい感じの挿絵画像をリクエストしたら縦長のお城の絵が生成されました。のびしろ今年の2月にデータイネーブリングはじめますという宣言をしました。こちらの記事にもチーム設立の背景や課題についてまとめています。