こんにちは。LayerX でエンジニアをしている @civitaspo です。LayerX では Ops エンジニアとして開発速度向上や信頼性担保、セキュリティなどバクラクの爆速開発を支える役割を担っています。所属はCTO室兼バクラク事業部DevOpsチームです。2022年7月に LayerXに入社して早くも3ヶ月（試用期間）が経過したので、LayerX の良いところと LayerX でやったことを振り返ろうと思います。この記事を読んで LayerX の良さや LayerX で何ができるかが少しでも伝わると嬉しいです。なお、読者はエンジニアを想定しているので、後半で技術用語を使います。可能な限りリンク等で補足しますが、技術用語に疎い方には少し難しい文章になるのでご容赦ください。
この記事は LayerXアドベントカレンダー(概念) の35日目の記事になります。34日目は多田さんの「Trustfulだからこそ自分の課題に真摯に向き合えると感じた、LayerX相互フィードバックの紹介」でした。
LayerX の良いところ
まずはLayerXの良いところから書いていきます。たくさんあるのですが自分に特に良いと思っている3つを書きます。
経営に対する透明性が高い
LayerX に入って一番驚いたのは経営に対する透明性の高さです。もちろんセンシティブな情報は秘匿される（し、されるべき）のですが、Board Members の不断の努力によって非常に高い透明性が担保されています。多くの場合、経営に関する意思決定は広めに秘匿されたり、公開されていても意志決定に至る判断材料やその思考プロセスまで社員にインプットされることはないと思います（少なくとも自分の経験では）。LayerX ではそういった部分まで公開されていて「経営に対する専門性」に触れることができます。これは明確に自分の行動変容に繋がっていて「LayerX に入って良かった」と思える一番大きな理由です。
CEO の福島の発信や CTO の松本の発信を見ると、その「経営に対する専門性」が何を指しているのか少し伝わると思います。この濃さの内容が週次定例などの場で高頻度で社内に発信されています。社外公開されている LayerX 羅針盤もその一つです。LayerX ではミッションを達成するため文化の醸成に力を入れています。LayerX 羅針盤は行動指針の定義だけでは補いきれない個々の価値観を表現するカルチャーブックとして発信されました。この存在と個々人の努力のおかげで LayerX では高いレベルで文化が浸透しています。
他にも社内限定で発信されてる内容（キャッシュフローマネジメント、失敗した意志決定、etc…）があります。これらは明確に自分の視野を広げ、行動を規律し、意志決定に良い影響を与えています。
企業文化が高いレベルで浸透している
先ほども書いたとおりですが、CEOの福島が発信しているとおり LayerX では事業戦略と同じレベル、もしくはそれ以上に企業文化に投資していくことを重視しています。
その結果として LayerX では企業文化が非常に高いレベルで浸透しています。「高い」と表現したのは個々人の行動規範として機能していると感じるからです。自分は LayerX の企業文化に強い共感を持っているので、この企業文化が高いレベルで浸透している状態が心地よくて仕方ありません。ふとした瞬間につぶやいてしまうほどです笑
中でも自分は「お客様を主語に」という価値観が好きです。この「お客様を主語に」という価値観は「お客様は神様だ」といった話ではなく「供給者論理だけで意志決定をするべきではない。お客様の視点から考えてみよう。」というものです。
自分の職種はエンジニアの中でもお客様からかなり遠いところにあるので供給者論理のバイアスに陥りやすいです。また過去を振り返ると供給者論理が強い意志決定をした経験もあったなと自省しています。
たとえば障害対応ひとつとっても「どういう情報があればお客様の業務が止まらないか」「どういう情報があればお客様の心理的な負担を下げられるか」「その前提でCSチームとどういう連携をすれば良いだろうか」といったことを考えながら対応するかどうかでお客様に与える影響は大きな差になります。冷静に考えれば当たり前のことですが、障害対応などの緊急時には、常日頃からそういった当たり前の思考プロセスを徹底しておかなければ考えが行き届きません。
「お客様を主語に」という価値観を紹介しましたが、LayerX には他にも企業文化を醸成する様々な価値観があります。その一つ一つが「高いレベルの当たり前を徹底する」ことに繋がっています。そういった企業文化が根付いた環境の下で仕事をすることは刺激の連続で毎日を楽しく過ごせています。
Slack に times （分報チャンネル）が存在しない
これまで書いてきた内容と比較するとかなり細かい話ですが、Slack に times が存在しないことが自分の生産性向上・心理的負担の軽減に大きく繋がったので書いておきます。
LayerX では Slack に times チャンネルが存在しません。正確にはオンボーディング期間中は存在しますが、それ以降は times チャンネルはアーカイブされます。
入社直後は times チャンネルがない Slack に戸惑いました。「小さな疑問をどこで発言すれば良いんだろう」とか「雑談はどうすれば…」といった戸惑いです。しかし、慣れると times がない方が圧倒的に仕事がしやすいことに気付きました。仕事をする上で重要性の高い話は必ず watch しているチャンネルで行われますし、どこかで行われてるかもしれない面白い雑談が気になって times チャンネルを漁ってしまうこともありません。ただこれだけですが自分にとっては心理的な負担が大きく減りました。そして、そのおかげで仕事のパフォーマンスも良くなりました。
当初疑問だった「小さな疑問をどこで発言すれば良いんだろう」については、 LayerX では「素朴な疑問」が推奨されているのでカジュアルに質問しますし、誰宛か分からないときはカジュアルな質問を集めるチャンネルに投稿すれば誰かが拾ってくれます。「雑談はどうすれば…」については「あんまりしない」です。興味毎に分かれた雑談チャンネルでの雑談もありますし、朝会で軽い雑談もします。が、仕事への熱量がみんな高く、自分も高いので雑談よりも仕事の話をしちゃっています笑
LayerX でやったこと
次に LayerX でやったことを書いていきます。細々した成果は割愛して、大きい成果を3つ書きます。
バクラクのデータ基盤を作った
バクラクのデータ分析は本番データベースに対して分析用の Read Replica を構築して行われていました。そのためバクラクの複数のプロダクトを跨いだ分析が非常に難しい状態になっていました。また Salesforce など SaaS とのデータ連携も積極的に出来る状態ではありませんでした。必要なデータが様々な場所に置かれていたため横断的な分析・様々なデータソースを使用した高度な分析がほぼ出来ない状態にありました。
この課題を解決するためデータ基盤を構築しました。「あらゆるデータソースを BigQuery に集約し、BigQuery をハブとして各ツールとデータ連携をする」基盤です。
技術詳細は別の機会にブログにするので簡単に技術スタックだけ紹介します。以下のような技術スタックで構成しました。
- Data Load / Data Activation: Embulk on Fargate
- Data Transform: dbt
- Query Engine: BigQuery
- Workflow Orchestration: EventBridge / Step Functions
データ基盤を作った結果、当初の課題は解決されました。また複数のデータソースを組み合わせて SaaS へデータ連携出来るようになった結果、業務オペレーションの効率化にも利用されるようにもなりました。現在では取得データソース数は500を超えており活用の幅が広がっています。
バクラクに monorepo による terraform 管理を導入した
2022年7月に名村卓さんが入社されて、バクラク事業部に Enabling チームが発足しました。Enabling チームは「プロダクト開発で高いパフォーマンスが出せる最適な選択肢を選べる状態を作る」チームです。その施策の一つとして開発体験向上・開発速度向上・認知負荷軽減を目的とした開発の monorepo 構成化がありました。
一方、自分も別の観点で monorepo 構成化を進めるべきと考えていました。これまでのバクラク事業部の terraform 管理はプロダクト毎に terraform 管理用リポジトリが分かれている状態で、管理コストの増大によるガバナンス不全が起こりうる状態でした。リポジトリの数が増えるにつれ管理コストが増大するので、構成ポリシー徹底の漏れからセキュリティインシデント等が発生する恐れを感じていました。monorepo 化を進めて管理コストを減らすことで強くガバナンスを効かせる必要があると考えていました。
そんなタイミングで Enabling チームの monorepo 構成化施策で、インフラ構成に関しても同様の方針で進めたいという依頼を受けました。自分も観点は異なるものの monorepo 化を進めるべきと考えていたので快く引き受けました。
最終的な成果物の技術的詳細については割愛しますが、様々な課題を解決出来たのでいくつか紹介します。
まず1つ目は構成ポリシーの徹底です。monorepo 化を進める過程で様々な自動化を施し、想定する基本構成であれば terraform のコードは全て自動生成するようになりました。terraform による構成管理に人間の手が入らなくなったので高いレベルで構成ポリシーの徹底ができるようになりました。基本構成から外れた構成も徐々にサポートし、完全に人間の手が入らない構成管理を目指します。
次に新しいインフラの立ち上がりスピードに関してです。先ほど terraform のコードを自動生成していると書きましたが、おかげで新規にインフラを構築するときも数分で完了するようになりました。爆速です。
最後にセキュアな構成管理の実践についてです。monorepo 化を進めたことで様々なセキュリティ対策を入れやすくなりました。IAM 利用時の OIDC 化を始め、terraform plan/apply の role 分離や KMS Key の細分化（一つの KMS Key の管理対象を減らし、きめ細やかな権限管理を実現）といった施策を入れることができました。
個人的に嬉しかったことは名村卓さんから「かなりデカい粒度で雑にボール投げても良い感じのものが良い感じのスピード帰ってくるので信頼してる」とか「これだけ開発の早い Ops エンジニアと仕事をしたことがない」といったありがたい言葉をもらえたことです。
DevOpsチームのリード的存在になった
評価されました。タイトルはついてませんがDevOpsチームのリーダーという役割を担っています。これからもがんばっていくぞ！
おわりに
この記事では LayerX の良いところと LayerX でやったことを書きました。最後まで読んでいただきありがとうございました。LayerX がいかにエキサイティングで楽しいところか伝わったでしょうか。もし興味を持っていただけたようでしたら下記のリンクからカジュアル面談が行えますので是非ご予約ください。
また採用中のポジションは以下のページにまとまっていますので、いきなり選考フローにご応募頂くのも大歓迎です。お待ちしています！
