こんにちは、開発3センターの堀内(horiuchi)です。

現在は LINE ドクターのサーバ開発リーダーとマネージャーをしております。

2015年12月に提供を開始し、2023年3月末にサービス提供を終了したライブ配信サービス「LINE LIVE」では、さまざまな技術的な挑戦や工夫を行ってきました。
そこで、今まで行ってきた施策の紹介や大規模サービスならではのクロージングに関わる話を連載していきます。

初回のこの記事は、プロジェクト全体の生産性と安定性の向上を目指して改善してきたことについて紹介します。

プロジェクトの状況や背景

LINE LIVE は7年以上続いてきました。その間に追加された機能は規模が大きく複雑なものも多いため、全ての機能を間違いなく暗記し続けることは不可能です。

また、サービス開発に関わるプランナーやエンジニアを合計すると30人程度の規模になるので、ショートスパンで複数の開発を回していると、担当者によって進め方や品質に違いが生じやすい状況でした。その結果 LINE LIVE では不具合が発生しやすい苦しい状況が続く時期もありました。

ここでは、上記課題の「担当者によって進め方や品質に違いが生じやすい状況」に対する改善について紹介します。

開発フローの可視化

担当者が違っても進め方や品質を一定に担保するために、下図のようにフローを整えてドキュメント化しました。そしてフローの各アクション単位でも何をすべきかを詳細なフローに落とし込み、担当者によってやるべきことが抜けたり迷ったりしない状態を目指しました。アクション単位のフローまで言及すると長くなりすぎるため、ここでは割愛します。

紹介したフローは基本に忠実であることが分かると思います。しかし、このような基本的なフローであっても全体で認識を共有し続けなければ、人によって簡単に違いが生じてしまうということを再認識しました。

全体で認識を同じレベルにするために重要なことは、ドキュメントにまとめて可視化した上でメンバーに徹底的に共有することです。このことは、新メンバーがジョインするなどのメンバーの入れ替わりにも非常に効果的でした。

またその他に、何か少しでも引っかかることがあれば気軽に議論できる雰囲気を作れていることも重要です。上記フローでは、実装中に少しでも引っかかることがあればすぐに議論してスペックや設計を見直すことになっています。

スペックや設計の穴はコーディングをしていると気づくことが多々ありますし、既存機能の理解不足で余計なエンバグをすることもあります。

これらの可能性をできるだけ低くするには、何かあった時にすぐに確認したり議論できる雰囲気を作っておくことが非常に効果的でした。私たちは時間があればすぐに集まれる専用の Zoom 部屋を常に用意しています。そして、1度 Fix したスペックや設計でも柔軟に変更することを許容する組織になっていることも重要でした。

リリース作業のフロー化

もう1つ、担当者によって進め方に違いが生じやすい事例を紹介します。プロダクション環境へのリリース作業です。

LINE LIVE ではサーバチームのメンバーが持ち回りでリリースマネージャーとなりリリース作業を進めます。ここで言うリリース作業とは、単にプロダクション環境へ開発物をデプロイするだけではありません。必要に応じて関係各所とコミュニケーションをして、開発物を過不足なく適切に反映しつつモニタリングを完了するまでを指します。よって、担当者によって進め方や品質に違いが生じやすいです。

この課題に対しては、リリースノート作成の徹底をした上で Slack のワークフロー機能を使うことで必要な確認や告知が漏れなく実施される環境を構築しました。

ここでは Slack のワークフロー機能をどのように活用したかを紹介します。Slack のワークフロー機能自体については公式情報をご覧ください。

まずリリースマネージャーがワークフローを開始して、立ち上がった入力フォームに情報を入力しつつ Submit すると、下図のようなリリースの概要が流れます。

その後のフローは、上の概要にスレッドの形で続いていきます。ワークフローが毎回決まった形でメンションと確認・連絡事項を投げることで属人性を排除しています。

弊社では Risk Assessment Team によるセキュリティチェック(RA)を必ず通してからリリースするルールになっているので、その進行も漏れないようにしています。

私たちのワークフローでは、重要なポイントで必ず担当者がチェックするようにボタンを設けて止まるようにもしています。

各キャプチャの clicked となっているのがボタンクリック後です。

またこのワークフローでは、Deploy 開始と終了時に下図のような通知を複数の Slack チャンネルに別に投げます。

このような簡単な通知でも、人力で複数のチャンネルに間違えないように投げると担当者の負担になったり漏れも発生するので自動化しました。

担当者に対して迷いやストレスをできるだけ低くすることをポイントに、自分たちの環境に相性の良いワークフロー機能の設計ができると良いと思います。

なおここで紹介したリリースフローは、弊社にて全社的に案内されているフローを元に LINE LIVE の環境に合うように適用しています。

おわりに

プロジェクトやチーム全体がストレス低く回るようになることが、生産性や安定性の向上に繋がる方法の1つだと思っています。

開発フローを整理したことで、注意すべきことが明確になり各種レビュー時の指摘漏れやドキュメントの更新漏れの低減に繋がりました。そして仕様書や設計書の品質も一定の担保ができたので、リリース後に問い合わせが来た際の仕様の確認もスムーズになりました。

リリース作業の進行を Slack ワークフロー化したことでエンジニアは迷いや漏れなく進められ、デプロイ作業やリリース後のモニタリングに集中できるようになりました。

今回紹介した内容は既存のプロジェクトへも導入しやすいと思いますので、ぜひ検討してみてください。