はじめに
こんにちは、最近チーム内情シスになりつつあるデータサイエンティストの坂元です。本記事はABEJA Advent Calendar2022の23日目の記事です。
ABEJAは機械学習やディープラーニングを軸とした様々な分析技術を用いてお客様の業務改善・変革のサポートをさせていただいています。データサイエンスチーム（以下DSチーム）はまさにその根幹業務の分析を担うチームです。
DSチームの昨年度版の紹介記事はこちらです。 tech-blog.abeja.asia
ちょうど上記の記事が出てから1年ほど経っており、この一年間もABEJA DSチームは大きな価値を生むための取り組みを進めてきたので、今回はそれについて紹介していきます！今までもあった取り組みをアップデートしたものと、新規で始めた取り組みがあるので、分けて紹介していこうと思います！
新規施策・取り組み
Technical Document
分析の工夫やDSの思考の蓄積・活用
チームとしての成果を最大化するには、過去に開発された実装や分析上の工夫、DSの思考の過程を記録し、活用出来る状態にすることが重要です。そこでABEJAではPJにおける仮説や思考の過程を含めたPJの履歴を記録しておくためのNotionドキュメントを導入し、Technical Documentとして制度化しました。
ドキュメントのテンプレート化
ドキュメンテーションはどこに何を書けばいいか判断が難しいと書くこと自体がハードルになってしまうこともあります。また、どこに何を書くかが個人に大きく依存していると、読み手にとってはどこに何の情報があるか分からないため、せっかく書かれたドキュメントも活用しにくいです。そこで現在、Technical Documentのテンプレートを整備していっています。
ただし、テンプレートとして情報を構造的にしすぎるとかえって書きにくくなってしまうこともあり、ここはバランスが難しい所です。現時点では、各施策の意図や結果サマリなどの情報はDBプロパティとして構造的に整理し検索可能な状態にしつつも、DBコンテンツのページの書き方はフリーフォーマットにするなどして対応しています。
タスク管理用DB
タスク管理用DBのコンテンツ
ドキュメンテーションの習慣付け
とはいえドキュメントを書くのは大変な作業です。そこで、後述するKPT FestでTechnical Documentを使うこととし、半ば強制的にTechnical Documentの記入を習慣付けられるようにしています。現在ABEJAでは契約上不可能な場合を除いて全てのPJでこのTechnical Documentを作成しており、ABEJAの価値の源泉として活用する仕組みの整備を進めています。
Reviewer System
中間レビューの廃止と代替施策の導入
これまでDSチームでは、各PJの分析方針をPJの中間のタイミングでDSチームでディスカッションする中間レビューを実施していました（中間レビューの詳細は前回記事参照）。しかし、中間レビューもDSレビューと同様、メンバーが増えるにつれて多くのDSが参加することによるデメリットが大きくなっていました。また、NDAの関係でPJ外メンバーはデータの詳細を見ることが出来ないため、的確なレビューがしづらいという問題もありました。そこで中間レビューを廃止し、新たにReviewer Systemという制度を整備しています。Reviewer SystemはメインDSとは別のDSを少ない工数でPJにアサインする体制です。
レビュアーの役割
レビュアーの役割はPJ状況や必要に応じて柔軟に変化しますが、基本は以下の5つです。
- PJ品質の向上
- PJの進め方、アプローチ方法、アウトプットイメージの議論を通してPJの品質向上に貢献する
- リスクマネジメント
- 潜在的なリスクを察知するため、複数のDSで方針を議論・決定していく
- レビュイーの心理的安全性の向上
- 議論や相談、壁打ちの相手となることでレビュイーの心理的安全性の向上に貢献する
- ドキュメンテーションの促進
- PJを進めながらテクニカルドキュメントの活用を促し、ナレッジの蓄積に貢献する
- デプロイメントの円滑化
- PJ中盤～終盤にかけて本番環境で動作させるためのコード整備を支援し、円滑なデプロイメントに貢献する
また、レビュアーは正式にPJのメンバーとなるため、実際にデータを見て議論することが出来る立場になります。
これまでは試験的に一部のPJで導入されていたのですが、実施したPJで好評だったため制度化するべく整備を進めています。
QA channel (Slack)
質問すること自体のハードルと対処
「自分で15分考えても分からないことは誰かに質問しよう」というフレーズはよく聞きますが、誰にどう質問すればいいのかなかなか判断出来なくて質問しづらいという質問のコールドスタート問題があります。QA channelはそんな状況を改善するために作られたSlackチャンネルです。QA channelではチームの全員にまとめて質問出来るので誰に質問するべきかは考えずに済みます。内容もどんなものでもいいということにして質問することのハードルを下げています。
Q&Aの蓄積
Q&Aのやりとりは蓄積することでチームの生産性の向上やチームの課題の把握にも役立ちます。ところがSlackは構造的に情報を整理するには向いていません。また、検索もそこまでしやすいというわけではないです。そこで、QAチャンネルに投稿された質問のスレッドをNotionに格納するアプリを作成し導入しています（これについてはまたどこかのタイミングで別記事で書こうと思います）。
Model Dev Template
Model Dev Teamplateとはcookiecutterを用いたABEJA内のPJテンプレートで、DSメンバーとDevチームが連携して開発を進めています。ABEJA Platformへのデプロイを容易にするために必要なツールやコードが一通りテンプレートに含まれており、調査実装フェーズで開発した成果物の資産化や効率的なデプロイに貢献しています。 より詳細な説明については下記の記事をご参照ください！
DS Day
ABEJAのDSチームにはリモートで遠方で働いているメンバーもいるのでなかなか対面で集まる機会を作ることが出来ないのですが、ABEJAでは3か月に1度、遠方からの出社を支援する制度があります。この3か月に1回の機会を利用し、DSチーム全員が集まってチームの良い所やもっと伸ばしていきたい所を出し合ったり、メンバーどうしがお互いをもっとよく知るための企画を行ったり、執行役員を召喚して質問をぶつけてみたりするのがDS Dayです。これもDSメンバーの発案で実現した取り組みで、次回の開催も非常に楽しみです！
アップデートした施策・取り組み
DS Review
DS Reviewの課題
DS Reviewとは提案前に複数人のDSが提案内容をレビューし、どのような提案にするかレビューする場です。詳細は前回記事をご参照頂ければと思いますが、変わったこともあります。これまでDS Reviewは原則としてDSチームのメンバー全員が都度参加していました。しかし、この体制だと視点が多いことのメリットはありつつも、全員が参加することによって
- PJに関連する知見をあまり持たないメンバーも参加しており、参加する全てのDSの得意領域を活かしづらい
- 発言しない人が多くなり無駄に工数を消費してしまっている
などの問題も発生していました。
DS Reviewの効率化
そこで現在は各DSをそれぞれが得意としている領域や興味のある領域ごとにグループに分け（複数のグループに属することも可）、レビューにかけられるPJごとに該当するグループから数人が参加する形態に変更になりました。またファシリテータが適切に意見を求めることで発言のしやすさを確保するように工夫もしています。こうすることで、人数を絞ってレビューに費やす工数を削減しつつも有益なレビューになるように体制を変更しています。
KPT Fest
PJ振り返り会のアップデート
KPT Festとは、終了したPJの成果をチームに共有し振り返る会です。元々は前回記事にあるようにPJ振り返り会という名目で行っていましたが、単なるPJ共有に留まらず今後のPJをより良くしていくためのアップデートを加え名称を変更しました。具体的にはTechnical Documentの活用、Q&Aの蓄積です。また、スケジューリングの自動化など効率化も行いました。
Technical Documentの活用
Technical Documentという施策を開始したことでPJ内での工夫や思考の過程が記録されるようになりました。しかしそれでもせっかく書いたドキュメントが一切見られないということも起こり得ます。そこで、KPT FestではこのTechnical Documentを投影しながら発表する形式にしています。こうすることでPJの履歴をドキュメントに蓄積しつつ、能動的な共有も行えます。
Q&Aの蓄積
とはいえドキュメントに全ての情報を書くことは現実的ではないので、第三者が読んでいて疑問に思うことなども出てくると思います。そこで、プレゼンター以外のチームメンバーは当日までにKPT Fest対象PJのTechnical Documentに目を通し、質問やコメントを共有します。プレゼンターはその質問やコメントに対する回答を記入しておき、ドキュメントには書ききれていない細かい意図などをKPT Festのタイミングで補足しています。
スケジューリング＆リマインドの自動化
KPT Festは基本的にはチームメンバー全員が参加するイベントです。つまりKPT Festを開催するためには主要メンバー全員のアンドが取れる時間帯を探す必要があります。また、プレゼンターに事前にTechnical Documentを書くようにリマインドする必要もあります。これらはとても面倒な作業なので、現在はスケジューリングとSlackリマインドを全て自動化しています。共通の時間が見つからない場合も調整しやすいように通知を飛ばす等の工夫をしているのですが、こちらについても詳細はどこかのタイミングで別の記事として書こうと思います。
Brainstorming
トピックの明確化
Brainstormingは、端的に言うとチーム内の勉強会です。現在は週に2回、メンバーの持ち回りで実施しています。詳細は前回記事をご参照ください。これまでBrainstormingの発表内容は何でもありだったので、KPT Festを開始して以降はKPT FestとBrainstormingの境界が曖昧になっていました。そこで、KPT FestではPJのこと、BrainstormingではPJ外で学んだことを共有する場に段階的に移行していっています。
発表内容はNotionに蓄積されているのでいつでも振り返ることが出来ます。
スケジューリング＆リマインドの自動化
現在はメンバーの持ち回りでプレゼンターを決めており、こちらもスケジューリングを自動化しています。また、プレゼンターが自分の発表日を忘れないように、Brainstormingで発表する当日の2週間前と1週間前にそれぞれプレゼンターに自動でSlackリマインドを送信しています。
さいごに
この記事を読んで少しでもABEJA DSチームに興味を持ったそこのあなた！ABEJAでは一緒に働く仲間を募集しています！DSチームは個人プレーになりがちな側面がありチームとしての価値を最大化するのが難しいところもありますが、ABEJAでは様々な施策を通してチームとして大きな価値を生めるよう工夫を行っています！（上記以外にも整備中の施策があります）AIの力で社会を変えられるチームに入りたいという思いがある方はぜひABEJAへ！
