はじめに
株式会社LITALICOでエンジニアマネージャーをしている @negi です。
この記事は LITALICO Engineers Advent Calendar 2020 の20日目の記事です。
私がLITALICOに2014年に入社したときは、ビジネス職も含めてほんの十数名で始まったPJTが、今や関係者は100人を超えています。
エンジニアも当時3名から、数十名へと大きくなっています。
この規模のチームでの開発課題管理について、具体的にどうしているのか、今後の課題などをお伝えできればと思います。
前提
私の所属する事業部では、障害を持つお子さんを抱える親御さん向けのWebサービスと、障害児支援を行う施設の経営支援システムを開発しています。
保護者向けの「LITALICO発達ナビ」。もうすぐ5周年！
事業部内は7つのグループに分かれており、2C/2B向けのSaaSサービス、ポータルサイトの開発を行っています。
大きく分けて2C/2Bの2つのプロダクトが存在するわけですが、システム開発は2つのエンジニアチーム、約20人で開発しています。
私がマネージャーを務めるエンジニアチームは4人、主に2C向けのサービス開発に責任を持っています。
2C向けサービスの会員は18万人を超え、LITALICO初の2C向けSaaSサービスも2020年4月から始まりました。
エンジニアも事業を伸ばすことにコミットすべく、事業部で追っているKGIと同じものに責任を持って日々改善を続けており、
4月に始まった2C向けSaaSサービス「発達ナビPLUS」の開発に注力しているところです。
一方で、「発達ナビ」はポータルサイトであるため、メディア機能やQ&Aサービスなど複数のサービスを提供しています。
保守やバグ改修もありますし、カスタマーサクセスチームからのアラートや改善提案など他チームからのエスカレーションも多数発生していて、対応に追われていました。
そのとき直面していた課題、取った解決策についてお伝えできればと思います。
直面していた課題
結論から言うと、下記の悪循環。
- 差し込みタスクで手一杯
- 最注力サービスで結果を出すために必死
- ずっと全力疾走
社内からのデータ抽出をはじめとする突発的な依頼、
CSからのエスカレーション、
セキュリティ系の保守、etc.
と、とにかくタスクが多い。
粒度にばらつきはありますが、2020年4月〜2020年12月で300件以上のタスクがありました。
（エスカレーション、連携があることは大変ありがたいことです）
また、エスカレーションの方法などもバラツキがあり、
複数のスプレッドシート、slack、hangout、メールと、コミュニケーション手段が異なる上、
状況が掴めないバグ報告、実施目的がわからない依頼など、エンジニアが必要としている情報が不足することも多々ありました。
これを、4人のエンジニアで対応しているので火の車です。
また、マネージャー視点では下記のような課題感も。
- 課題が集約されていないので優先順位が適切につけられず、場当たり的になりがち
- エスカレーション先が属人化し、把握できていないタスクがある
- 誰が何をしたのかわからないので評価できない
以上のことから、下記にフォーカスしてオペレーションとツールを選定、検討することにしました。
- 依頼が属人化せず、集約されていること
- 必要な情報が開示されていること
- タスクの見通しを持てること
- 実施したタスクが見える化されていること
解決策
1. 依頼が属人化せず、集約されていること
まずは、どこかに課題を集約したかったので、backlog の導入を決めました。
選定理由は簡単で、他方のエンジニアチームでの運用実績があり、ツールを使うべきメンバーも共通しているため、
ツールを分けるよりも共通化した方が、運用もコスト面でも有利と考えたためです。
また、非エンジニアが使いやすい、というのも大事なことですね。
ツールの導入によって、個別に依頼が来たときでも「backlogへ起票お願いします」と言えるようになり、課題の起票先が分散することもなくなりました。
2. 必要な情報が開示されていること
「XXの機能がほしい」「□□のデータがほしい」とチャットが飛んできたとき、
「なぜその機能がほしいのか？」「そのデータは何に使うのか、どういうFMTがいいのか」を聞き返すことになります。当然です。
しかし依頼側としては、エンジニアにとって必要な情報が何かわからないので、某CMのように「それ、早く言ってよ〜」状態です。
お互いにストレスが溜まりますし、サービスの改善が遅くなることが何よりの機会損失です。
幸いにも、backlogには課題の種別ごとに起票のテンプレートがあるので、活用することにしました。
こんな具合です。
## タスク内容
- タスク・作業内容を具体的に記述します。
- 目的や背景、依頼者がいれば記載してください。
- 意図を推し量ったり、確認事項があるときの連携先として役に立ちます。
- 属人化を排除できるよう心がけましょう
## その他（このセクションは課題追加時に削除してください）
- 抜け漏れを防ぐため、担当者を必ず設定してください。迷ったらエンジニアMGをアサイン！
- 担当者が複数になる場合は主担当者決定後に子課題を追加して担当者を設定してください。
- カテゴリには依頼元を入れてください。迷ったら自グループでOK。
- 期限日があれば設定してください。 **対応期限が1週間以内の場合は、別途slackでメンションをください。**
ガチガチに固いFMTにはせず、かつ、必要な情報とその意図がわかる程度におさめています。
これによって、タスク依頼時のやりとりが減ったことと、
依頼の背景や意図がわかるため、よりbetterな解決策の提案がエンジニアからもできるようになりました。
3. タスクの見通しを持てること
タスクを引き受けたのに取り組むのを忘れていたり、
気づいたら期限が同じタスクが山のように積まれているなんてことがよく発生していました。
また、運用保守系だとライブラリの更新など、重要だけど期限は数ヶ月、数年後のタスクもあり、忘れたくないものです。
ツール導入によってタスクの集約ができたこともあって、
週次定例で直近2~3週間の全タスク（大体20~30件）を確認するようにしました。
このとき期限の入っていないタスクは、この定例で着手開始日と期限を決め、担当者までアサインする運用にしています。
これによって、抜け漏れ防止だけでなく、タスクの分担もより協力的に行えるようになったと思っています。
4. 実施したタスクが見える化されていること
個人的にはこれが１番やりたかったことです。
頑張ったことの見える化って大事ですよね。
backlogの検索は割と充実しているので、過去の振り返りはもちろん、評価の証票としても使えます。
また、なぜエンジニアが忙しいのか、このタスクの優先度が低いのはなぜなのか、エンジニアは何に時間を使っているのか、説明する補足資料にもなります。
これをスプレッドシートで用意するには気が乗らないので、backlogに感謝。
今後の課題
部内全員が使っているわけではない
部内全員に活用してもらうのが理想ではありますが、もちろん起票の頻度などにバラツキがあるので、使い方や起票ルールが浸透していないところはあります。
これは依頼ベースで起票をお願いするしかないので、地道に取り組んでいきます。実装レイヤーの課題との連携や管理
backlog上では実装レベルのissueや方針議論などはしておらず、github上でやりとりしているのが現状です。
PRやissueにbacklogのURLを手動で関連付けるようにしていますが、もう少しいい棲み分けや連携ができたらいいなと思っています。マイルストーンとバーンダウンチャートの活用
マイルストーン機能を使うとバーンダウンチャートが使えるようですが、
まだ活用できていないので、どこかのタイミングで使ってみようかなと思っています。
以上、明日は@katzumiさんの「リモートモブプログラミングを9ヶ月間やってきたので振り返ってみる」です。お楽しみに！