LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

「開発者のための最高の環境をつくる 」をミッションに新設されたReliability Engineeringセンターを紹介します

LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介していく「Team & Project」シリーズ。今回は「エンジニアに価値ある環境とツールを作る 」「環境とツールをより価値あるものにする方法を探し出して実行する 」をミッションに設立された、Reliability Engineeringセンター(REC)を紹介します。

RECのセンター長である片野をはじめ、室長やマネージャーを務めるLINEのエンジニアたちに話を聞きました。

―― センター設立の背景、目的、コンセプトなどを教えてください

片野: RECのセンター長を務めている片野です。LINEの開発組織はこれまで一定の属人化や個別最適を柔軟に受け入れ、スピード感のある開発を進めてきたのが特徴だと考えていますが、開発組織の規模も大きくなり、このスタイルの良さを活かしながらもう一歩進化させるフェーズに差し掛かっていると感じていました。

開発組織の規模が大きくなってくると、個別最適によるデメリットも無視できなくなってきます。

  • 開発者が積極的にリソースを割きたくない業務に個別対応が必要になる
  • 会社内でのノウハウや資産が有効に再利用されない

開発組織の規模が数百人、プロジェクトチームも数十個という程度であればまだ良いのですが、数千人のエンジニアが数百のプロジェクトで活動している規模になると、大きな課題になってきます。
逆に言えば、これだけの規模でプロジェクトが展開している中で生まれてくるノウハウを全社へ還元できる仕組みをつくることが出来れば大きな強みになるということです。

組織設立にあたって、新組織のLeadメンバーと何度もディスカッションしたのですが、「すべての開発者の不便さを解消したい」「サービスの成長に貢献したい」「どうせやるなら最高の環境を目指したい」といった意見が多く出ました。

こういった意見を集約して掲げたRECのMission/Visionがこちらです。

  • MISSION
    • エンジニアに価値ある環境とツールを作る
    • 環境とツールをより価値あるものにする方法を探し出して実行する
  • VISION
    • LINEとLINER(LINEスタッフ)がより良く成長できる最高の環境をつくる

シンプルに「開発者のための最高の環境をつくる」ということです。このMISSION/VISIONを実現していくためには、ユーザとなる各開発組織やプロジェクトとの強い連携が欠かせません。そのため、新設したRECでは、サービス開発や運用の実情に詳しいSRE/DevOps領域を担当するメンバーも合流して、サービス開発者との連携を強く保ったまま、よりスピーディに改善サイクルが回していけることを目指しています。

―― みなさんのチームの構成・役割について教えてください

今回インタビューに参加してくれた
片野・池田・松本
岩月・髙木・Hyungbae

片野:まずREC全体について説明しますと、このような形で7つの室やチームがあります。兼務を含め、全体で40名ほどの組織です。

どういったことをしているチームなのか各担当の皆さんから紹介してもらいます。

池田: Engineering Infrastructure室、室長の池田です。社内で運用実績の長い歴史的なデプロイツールであるPMCやモニタリングツールのIMONの開発・運用、そして開発者の開発エクスペリエンスを向上させる取り組み全般など、社内のエンジニアが共通して恩恵を受けられるような活動をEngineering Infrastructure室では行っています。
国内ではLINE Fukuokaと、国外では韓国やベトナムとバーチャルチームを組んでおり、RECの中ではとても国際色の強い組織だと思います。様々な価値観を共有している組織のため、チームメンバー同士がリスペクトし合っており、お互いにストレスなく切磋琢磨できる環境であると自信を持って言えます。

松本: LIAM Devチームの松本です。私たちのチームでは、LINEグループの社内システムから利用できる新しい統合認証基盤であるLIAM(LINE Identity & Access Management)の開発・運用をしています。
アーキテクチャ全般に責任を持つTechLeadと、プロジェクトの推進全般に責任をもつプロジェクトマネージャを中心として、20名程度のエンジニアが複数のチームに分かれて開発しています。人数が多いため、夕会などチームごとのミーティングに加え、チーム横断で連携できるよう全体での朝会を実施したり、全体用のチャンネルやZoomの常設Roomを作成するなど、チーム間連携やコミュニケーションが疎遠にならないようにしています。

髙木:Dev Support チーム 髙木です。我々は監視基盤や負荷テストツール、k8s向けのデプロイ基盤の開発・運用を主に行なっています。基本的にはArgoCD, k6, Prometheus, Grafana, Thanos, PromgenなどのOSSをベースに開発・運用していて、他にも細かなツール類も運用していますが、主なものは上記のとおりです。
6名の小規模なチームなので、プロダクトごとに定例は設けずにチームとしての定例を週に1回で済ませて、あとは Slack上でコミュニケーションをとっています。その代わりチームの定例は枠を長めにとっていて、その中で雑談やメンバーのプライベートを含めた話をしたりしなかったりという緩い時間を設けています。

岩月:Enterprise Devチームの岩月です。 LINEグループの開発で共通的に利用されているシステムの運用と改善を主に担当しており、MAUで15,000を超えるConfluenceの他、Jira、GitHub Enterprise、Slack Botなどを担当しています。
システムを安定的に動作させることはもちろんのこと、レスポンスの改善やプラグイン開発、システムをクロールしてのモニタリングや検索システム化なども重要な仕事となります。
各々の進捗を報告する定例を週1回、軽い進捗報告をする夕会を週2回、相談事や雑談したいことなどがあれば自由に出入りできる「部屋」という時間を週2回、それぞれ別の日で設けています。日々違った形で交流できる時間を作ることで、各々が担当しているシステムが違っている中でもメンバー間の交流が希薄にならないようにしています。

Hyungbae: Audit DevチームのHyungbaeです。私達のチームでは、社内システムの監査ログの保管と閲覧、監視を目的としたログ基盤を構築を進めており、社内的に様々なログデータを管理するプロダクトの中で、一番センシティブなデータを扱っているプラットフォームでもあります。
プロジェクトマネージャ1名とエンジニアが2名、サポートが2名と小規模な体制になっていますが、今後の全社展開にあわせ体制を拡大していく予定です。 少人数なこともありSlackでのやり取りは濃密で、開発用チャンネルでは仕事の話からプライベートの話まで飛び交っています。

―― 今のチーム課題と、解決に向けた取り組みを教えてください

池田: Engineering Infrastructure室は全社を対象にしたプロダクトや施策を続けているためステークホルダーやユーザーの絶対数が多く、それだけ方向性の異なる要望が多いため、なるべく多くのケースにおいて多くのステークホルダー間でWin-Winとなるそれぞれのプロダクトや施策の方向性を決めることが求められています。また内製プロダクトを多く持つ単独の部署でもあり、プロダクトを通して全社に開発プラクティスのガイドラインのようなものを定義することも求められているため、幅広い技術的な知識や経験を身につけて他部署に対してある種のリーダーシップを取る必要もあります。
ビジネス的な問題解決とエンジニアリング双方において高い技術が求められるため、リスペクトを基礎とした積極的なディスカッションや学習を積極的に奨励したり等、メンバー一人一人がストレスなく継続的に成長できる環境・文化作りに注力しています。

松本: LIAM Devチームの課題は、認証基盤という社内の中核となるシステムにもかかわらず、エンジニアリングは外部協力会社の方に頼っている部分が大きい体制となっているところです。
全社公開に向けた安定運用や機能面でもまだ課題が残っており、これらを解決できるエンジニア組織そのものの立ち上げを今期のミッションに入れています。
認証認可の仕組みを提供する立場で関われるのは貴重な機会だと思いますし、学びも多いです。今後は社内公募なども視野に入れて、早急に体制を拡充していきます。

髙木: Dev Support チームは、元々一部の部署用に運用していたものを全社展開することになったため、運用体制やドキュメント整備のところで課題が残っています。
また、社内のニーズをキャッチアップするところまで深掘りできていないので、なるべく運用コストを下げて、今後はそのあたりにフォーカスしていきたいと考えています。ArgoCD, k6, Prometheus, Grafana, Thanos, Promgen の運用を行なっています。

岩月: Enterprise Devチームは、チームで運用しているいくつかのシステムについて社員数の増加で利用者が増え、サーバー負荷やレスポンス速度に課題がでています。システムの特性から単純なスケールアウトでは解決できないケースが多く、重たいリクエストを回避する仕組みを入れるなどして対応しています。
また、運用の効率化とユーザーへの最新機能の素早い提供のため、オンプレからSaaSへの移行には積極的に取り組んでいきたいと考えています。

Hyungbae: Audit Devチームは、監査業務という非常に幅広い業務を対象にしていること、ステークホルダーも多くそれぞれに業務要件や実現したいことも異なるため、プロジェクトスコープも非常に変化が多いプロジェクトなっています。それらの監査業務の中でAudit Devチームが賄うべき部分はどこか、開発範囲をどうするか、どのように連携するか、と言った多くの部分でリーダーシップを取っていく難しさがあります。
モニタリングやセキュリティ面の考慮など得られる経験が多く、かつLINEグループ全体の監査ログ基盤として送信や保管の仕組みをグループ内に確立・浸透させていく過程に関わることができます。 技術スタックも最新のものを使用しており、他のログ基盤との連携など社内の技術に触れる機会も多く、幅広く知見を得ることができます。

―― RECが今後取り組もうとしていることについて教えてください

片野:RECではツールの提供だけが目的ではなく、ツールの提供を通して開発者の課題を解決することを目的とするため、サポート体制の充実化も進めていきたいと考えています。
具体的なものをあげると、ドキュメントや具体的なPracticeの提供、問い合わせ対応リソースの強化などです。理想としては、個別のプロジェクトに対して、コンサルティングまで入れると本当に開発者の助けになると考えています。
こういったサポート体制を強化することで、より具体的なフィードバックを受け取る機会も増え、ツールの改善が加速する相乗効果も期待できます。今の組織規模ではまだ対応が難しい部分も多いですが、積極的に体制を強化してより良い環境を作っていきたいと考えています。

―― 最後に、RECに興味を持ってくれた人にメッセージをお願いします

片野:RECのユーザは開発エンジニアが中心となるため、主なコミュニケーション相手も開発エンジニアになります。
そのため、要求もレベルが高く、課題に対する解決アイディアをユーザ側のエンジニアからもらうことも多いです。難易度は高いのですが、エンジニア同士でディスカッションして、より良い解決方法を見つけ出していくなど、エンジニアとしての面白みも多くある環境だと思っています。
エンジニアであれば、開発を進める上で不便に感じることや無駄をなくしたい、自動化を押し進めたい、など、Developer Experienceの改善に注力したいと感じたことはあると思います。こういった取り組みはサービス開発などの業務と並行していると難しく、「ある程度」までの改善しかできなかった、という事が多いのではないでしょうか。

RECでは、こういったDeveloper Experience向上への取り組みがメインミッションになっているので、思う存分注力して「最高の環境」をつくることに全力を注ぐことができます。
このような取り組みに共感し、「(私達自身も含めた)開発者のための最高の環境をつくる」というミッションに興味を持ってくれた方と一緒に働けると嬉しいと思っています。

Reliability Engineeringセンターではメンバーを募集しています

LINE株式会社では一緒に働くエンジニアを募集しています!
今回のインタビューと関連する募集ポジションはこちらです、ご応募お待ちしております。