8
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

スタンバイAdvent Calendar 2024

Day 10

MLチームのチーム運営を改善しようとしている

Last updated at Posted at 2024-12-09

スタンバイアドベントカレンダー2024の10日目です!

前置き

私は2024年4月1日にスタンバイに入社しました。
まだまだ社会人歴は3年目です。馬鹿が付くような正直さ(と、一応自然言語処理の研究で大学院を出たところ)に期待をかけてポテンシャルで採用してもらったという自覚があるくらい、ジュニアなエンジニアです。
なので、私自身はキャッチアップに半年も時間がかかり、下期になってやっと色々な面で貢献できるようになってきました。
その中で、私の経験不足に寄らないMLチームの状況的・構造的な問題も見えてきたため、改善活動を行っています。
この記事ではスタンバイのMLチームにおける「チーム化」について書いていきます。

背景

MLチームの性質

MLという分野は属人性が高くなりやすい分野です。
しかも、スタンバイのML系の業務は多岐にわたります。 今現在MLを使っていなくても、今後ML的なアルゴリズムを適用する可能性があるような分野はMLチームで検討することも多いです。
現在は各テーマに対して担当が2人付く形で業務を進めています。

スタンバイMLチーム特有の問題

スタンバイのMLチームでは、

  • 各テーマに担当が2人ずつつけない状態
  • 保守運用が特定のメンバーに偏る状態

が発生していました。

メンバーが優秀なため、課題に対しての議論はできますが、もし誰かが倒れたら引き継ぎなどはできないという危機的な状況です。

新メンバー受け入れの状況

さらに、

  • 各テーマについてのドキュメントは存在するものの、前提知識が抜けている
  • そもそもオンボーディングのやり方を忘れている
    • 特にまだエンジニア3年目という、ほぼ新卒みたいな新メンバーをサポートする体制はなくて当たり前です
    • ここは後に新メンバーが入るたびにFBをして改善傾向です

といった状況にも陥っていました。
こうなってくると、各々が各々のテーマに忙殺されて、そもそもどういうタスクがあるのかが中々見えてきませんでした。

目標

私のようなジュニアエンジニアが生き残っていくためには、チームメンバーとのコミュニケーションが欠かせません。
そのため、以下3つの目標を立てて、チームの運営を改善していくことに決めました。

  1. MLチームの属人性を低減する
  2. 保守運用などのタスクの偏りを解消する
  3. アイディアを出す議論から、その一歩先の議論へ

課題となる点

ところで、スタンバイでは多くのチームでスクラム開発が採用されています。特に、MLチームのお隣である検索エンジン自体を管掌しているチームでは、かなりしっかりとしたスクラム開発が行われています。
検索とMLは連携するべき部分が多いため、スクラムイベントに合同で出たりも行っています。

しかし、スクラム開発とMLチームは相性が悪いものです。

スクラム開発では、スプリント毎に成果を出すことが期待されます。しかし、MLの成果には不確実性があります。思ったほどの精度が出なかった、分析対象のデータの品質が低かった、そもそもモデルの学習や前処理自体に時間がかかるため非同期で実行可能な作業を先に実施していた…。
もちろん、「モデルの学習から推論までを実施した」ということを成果と呼ぶのであれば適用していくことは可能かもしれませんが、それはスクラム開発というフレームワークのスプリントゴールとして適切ではないでしょう。

また、業務を円滑に進めようと始めた施策に時間を取られるすぎると業務に支障をきたす可能性がありますし、ドラスティックな変更というのは反発も招きます。せっかくチームの改善をしようとしても、精神的な部分で溝ができてしまったチームは、近いうちに瓦解するのではないでしょうか。

改善していくためのポイント

以上から、MLチームのチーム運営を改善するためのポイントを決めました

  • 全員が現状を改善すべきことだと認識していること
    • お互いが改善すべきだと認識していないとそもそも改善は進みません
  • MLの業務の進み方に合う方法であること
    • 単純にお隣のチームを手本にスクラムイベントをやってもスタンバイのMLの業務方針に合わなければ空回りしてしまいます
  • 保守運用など、定常的なタスクに焦点を当てること
    • 新メンバーが入って行きやすいのは個人的には保守運用を見ることだと思っています。 

定常で走っている集計結果の分析や、モデルパイプラインのメンテナンス、各システムのEOL対応などを通して実際に今解決すべき課題が見えてきます。 
…もしかしたらシニアでスーパーなエンジニアとかだったらそんなこともないのかもしれないですが、少なくとも私はそうです

実際に実施していること

  • retrospectiveの新設
    • 頻度:月1回
    • 内容:前回から今回までの間にあったことをKPTで振り返ります
  • mini retroの追加
    • 頻度:週1回
    • リファインメントのアジェンダです。その週にあったことを書き溜める時間です。
      喫緊の課題があった場合はここで解決するか、別途ミーティングを立てて早期解決を目指します。

他にも、テーマがない場合は流会したり早仕舞いしていた相談系のミーティングの活用をしています。

実行したことによる効果・変化

正直なところを言うと、チーム全体で大きく変わっているような実感はまだありません。私は今もメンバーの報告を聞きながら、「後で資料を読もう…」と考えていますし、アイディア出し以上の議論ができていると言うつもりもありません。
また、新メンバーが業務に入っていく早さは個人差があります。簡単に比較できるものでもありません。(比較されると私の遅さが際立ちます)

しかし、チームメンバーは積極的に参加してくれています。
今後は保守運用タスクの偏りなど、なるべく定量的な指標を探して施策の効果を確認していこうと考えています。

8
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?