目次
- 本記事で目指すもの
- スクラムは「チームで働くための問題解決のフレームワーク」
- スクラムの決まり事と業務の進め方
- 利用していたITツール
- チームメンバー構成と自身への期待
- 反復的なデータ分析プロセスを管理可能
- 完了定義と見積りをつける癖がつく
- 個人活動に陥りがちな分析業務をオープン化
- エンジニアリング力の向上
- メンタルモデルの拡大
- スクラムで働くと、とにかく仕事が楽しくなった
- 正直葛藤もある
- 今後自身はどうしたいか
- まとめ
自社のアドベントカレンダー18日目を担当させていただきます。
本記事では、ビジネスサイドで業務を遂行していたデータアナリストが、エンジニアで構成されるスクラムのチームにアサイン（派遣）された体験記を書かせていただきます。なお、私の経験は、弊社を代表する業務経験ではありません。
本記事で目指すもの
本記事では、例えば以下のようなことを日々考えている方のお役に立てればよいなと思います。
- データアナリストの「エンジニアリング力*1」を育てたい、高めたい
- データ分析の分析プロセスをいい感じに管理したい
- データ分析組織のアナリストを事業部やプロジェクトに派遣したい
- スクラムを取り入れたチーム運営を行いたい
現在、様々な形でデータアナリスト、データサイエンティストの皆様は活躍されていると思いますが、そのデータ分析チームやデータアナリストの仕事の例として、参考になればと思います。
また、これをキッカケに皆さんの会社がどのような体制でデータアナリスト業務に従事しているか、情報共有させていただけると幸いです。
まずは、スクラムについて少し話をさせてください。
スクラムは「チームで働くための問題解決のフレームワーク」
私はエンジニアとともに、スクラムのフレームワークで一緒に仕事を進めてまいりました。
スクラムを一言でいうと、メンバー各人の自主性を尊重しながら、計画と振り返りによりチームを成長させていくフレームワークです。
スクラムが前提とする考え方に経験主義があります。経験主義とは、未来を予見することなく、実際に経験を積み重ねることで知識を獲得していこうとする考え方です。これを漸進的に繰り返すことで、予測可能性を高め、リスクの低減を目指すのがスクラムです。
未来は不確実に富んでおり、起こりうる全てを予測し計画を立てることは難しいです。1つの大きなサイクルを回すのではなく、小さなPDCAを回すことで、チームで学習しながら、変化に柔軟に対応しながら、目標に向かっていくのがスクラムの考え方です。
スクラムの決まり事と業務の進め方
スクラムでは、短い一定の期間に区切って計画と振り返りを繰り返し、より良い成果物を作っていきます。そのためにいくつかのイベントや役割、成果物が決まりごととして用意されています。逆に決まっているのはそれくらいです。
区切られた短い期間をスプリントと呼びます。1つのスプリントはだいたい2〜4週間です。そして以下を繰り返します。
1. スプリント開始時：スプリント計画
スプリント計画では、例えば以下を決めていきます。
- タスクの見積りと優先度付け
- 次のスプリントでチームで対応するタスクの決定（スプリントバックログ）
2. スプリント期間中：デイリースクラム
スプリント期間中は、スプリントバックログのタスクを、チームメンバー全員で対応していきます。
スプリント期間中はデイリースクラムと呼ばれるMTGを15分ほど毎朝行います。デイリースクラムでは下記を共有することで、チームの透明性を図ります。
- 昨日対応したこと
- 今日対応すること
- 障害となっていること
また、スピーディーかつコンパクトな運営を心がけるために、スタンドアップミーティングを行っています。
3. スプリント終了後：振り返り
スプリント期間後、チームのメンバー全員で振り返りを行い、次のスプリントへの知識として活かします。これを繰り返していきます。
利用していたITツール
スクラムを円滑に運営するために、ITのツールを利用しました。
- Gitlab
- Slack
Gitlabのissue機能を利用し、各タスクを定義しています。各issueの中に、タスクのプロセスのメモやメンバ間のコミュニケーションを行います。 また、かんばんボード機能を利用し、スプリントバックログの進捗を管理します。
かんばんのレーンは、下記を設定しています。
- ToDo（=スプリントバックログ）
- Doing（＝対応中）
- Done（＝完了）
前置きが長くなりましたが、まずは私が取り組んでいるスクラムの概要でした。 より詳細については下記記事を参考にしてください。私自身が愛読させていただいた書籍になります。
- アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
- エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
チームメンバー構成と自身への期待
私が所属するチームは、開発エンジニア（4名）、システム維持管理（2名）、データアナリスト（私）の7名前後で構成されます。
私自身はプロジェクト発足後1年以上経ってから、チームに無かったデータ分析の要素を取り入れるためにアサインされました。例えば、期待されていた内容は、下記のとおりです。
- 既存システムに機械学習の仕組みを導入し、業務を効率化
- 蓄積データを分析し、インテリジェンスを生成(レポート書く)
私のスキルにかかわらず、データ分析に関わることは大体期待されていた感じはします。データアナリストとデータサイエンティストと機械学習エンジニアの要素が少しずつ必要な感じでした。
では、実際にデータアナリストの立場でスクラムチームで働き、何が良かったか、書いていきます。
反復的なデータ分析プロセスを管理可能
データ分析のプロセスには、反復的な試行プロセスが存在します。特にこのフェーズにおいては、スクラムのフレームワークとの相性が良いと考えています。
例えばモデリングや特徴量エンジニアリングにおいて、様々なアイデアが浮かんできて全てを試してみたくなると思います。これらのアイデアは適切に管理しないと無限に時間を浪費する一方、価値を生み出さない結果となります。
スクラムのフレームワークを活用することで、各アイデアの優先度と稼働見込みをチームで決めることができます。チームにとってインパクトが低いアイデアは、優先度が高くなることはありません。また、Gitlabのかんばんボードを利用して、適切に進捗管理ができます。
完了定義と見積りをつける癖がつく
EDA（Exploratory Data Analysis）という言葉に代表されるように、データ分析には探索的にデータ分析を行うプロセスが存在します。データの理解にはEDAは必須です。しかし、このEDAも適切にゴール設定を行わないと、むやみに時間を浪費する結果を生むことがあります。
スクラムでは、スプリント計画時に各タスクに対して以下をチームで考えます。
- 完了定義：何をもってこのタスクを完了とするか。サブタスクの洗い出し
- 見積：完了定義をもとに、どれくらいコストがかかりそうか
これにより、EDAにおいてもゴール設定をしっかりした上でタスクを遂行でき、むやみやたらに探索し続けることを防ぎます。「意識の問題」といわれるかもしれませんが、しっかりとフレームワーク化されていることで、仕事の進め方としても、思考が整理され予実乖離も少なくなります。
個人活動に陥りがちな分析業務をオープン化
データ分析業務のプロセスにおいて、データ理解やビジネス業務を理解するフェーズにおいては、当然関係者とのコミュニケーションが発生します。一方で、EDAやモデリング等のフェーズにおいては、時に個人活動に陥り、自分の世界に閉じこもることも少なくないのではないでしょうか。
個人でゾーン状態に入り集中することも大切ですが、適切なタイミングでチーム内に棚卸を行い、方向性等の意思統一を行うことも重要です。
スクラムでは、デイリースクラム（朝MTG）の中で簡潔にチームにタスクの進行状況を説明します。また、うやむやなことはスクラムマスターという役割が、チームに問いかけを行い、チームでの理解の深化を促し、業務の透明性を担保します。
エンジニアリング力の向上
これまでどちらかというとビジネスサイドで職務をこなしてきたために、エンジニアとは関与が多くありませんでした。初めて同じチームで業務を行うことで、自分だけでは成しえなかった小さな成功体験を積み重ねることができ、それが自分の血となり肉となりました。
データサイエンティスト協会では、「ビジネス力」「データサイエンス力」「データエンジニリング力」をスキルセットとして定義していますが、この「データエンジニアリング力」とだいたい同義と考えていただければと思います。
アサイン当初、プログラミング言語はRしかコーディングできなかったのですが、チームの開発言語はPythonでした（じゃあ、なんでアサインされたんだよという話は、割愛）。
早期に機械学習システムの構築が求められた中で、私たちのチームは以下の方法を取りました。
自分の強みを生かしつつも、エンジニアの全力サポートの恩恵を受け、チームの中で機能横断的にタスクを遂行することができました。自身も徐々にPythonを学び、スクラムのイテレーションの中で少しずつRのコードをなくすようにリファクタリングしていくことができました。
なお、我々のチームでは、ペアプログラミングを行い,、機械学習システムのコードについてエンジニアと対話を行いながらリファクタリングをする機会がありました。
ペアプログラミングは、想像以上にコストが高く、精神も消費する取組みですが、個人の成長によりチームの機能横断性を高める手段となりました。
「データサイエンティストのコードは汚くてそのままデプロイできない」的な話はよくあると思います。私自身もそうでした（今でもそうかも。。。）。データアナリストとしての活躍の場を広げる手段は様々ですが、ビジネス寄りのポジションにいた私が、エンジニアとともに業務を行うことでエンジニアリングスキルを身に付け、機械学習エンジニアのスキルセットへと活躍の場を広げることができました。
メンタルモデルの拡大
当然個人差はありますが、職種が異なるだけでも、働き方や仕事に対する姿勢、文化は大きく異なることを知りました。スクラムチームでは様々な専門性をもつメンバーたちが、機能横断的に1つの方向に向かって取組みます。
スクラムチームへのアサインは、自身のメンタルモデルを大きく拡大することができたと感じています。個々人（特に職種）の文化や価値観を知ることで、コミュニケーションの衝突はなくなり、相手をリスペクトし自身も謙虚に働くことに繋がります。
いくつか例を書いておきます。
以前の職場ではエンジニアが周りにいなかったために、様々な業務に対する自動化の意識が低かったように感じます。これは、自動化したくないわけではなく、実現できること（可能性がある）ことを知らないだけでした。 エンジニアとともに仕事をすると、自動化、再現性に対する意識が非常に高いと感じました。様々な業務のプロセスはGitlabで履歴が残っていますし、コードも当然バージョン管理がされています。
また、私たちのチームでは、シーーンと静まり返っている時間帯があります。ビジネスサイドの業務ではあまりないのではないでしょうか。そのような時間帯は、ゾーンに入っているエンジニアが多いので、直接話しかけずSlackでメッセージを飛ばしたりします。この経験もビジネス側ではありませんでした。
エンジニア側から「ビジネス側は××」。ビジネス側から「エンジニアは××」。正直、それぞれがお互いの立場や思考を理解せずに悪口を言う場面を多々目撃してきました。自身が両方の経験を積むことで、これらの議論の本質を見極め、コミュニケーションのきっかけを作れたら良いなと感じます。
また、データアナリストにとって需要なのは、ビジネスに興味を持ち、理解を深め、ビジネス成果までコミットすることです。立場が違う人間の思考を理解しようと努めることは、データアナリストにとって重要な要素になると思いますので、様々な価値観や文化を受け入れられる人間性を持てるように精進することが必要ではないでしょうか。
スクラムで働くと、とにかく仕事が楽しくなった
スクラムのフレームワークで働くことで、とにかく仕事が楽しくなります。理由は2つに絞られます。
- 創造性の発揮
- PULL型の仕事の進め方
1点目として、スクラムでは創造性を発揮できるフレームワークです。 ウォーターフォールの場合、プロジェクト開始以降に発生するアイデアは全て廃棄されます。市場の変化に対応できずや自身の新たなアイデアは採用することはできません。一方で、スクラムではそれが歓迎され、自身の創造性を最大限に発揮でき、徐々に仕事が楽しくなります。
2点目として、スクラムではスプリント期間中のチームのタスクは、基本的には各メンバが自主的に対応することを宣言します。このPULL型の業務の進め方は自身のチャレンジ精神を最大限発揮できます。チャレンジした結果チームが前進することで、自己効力感が高まり、またチャレンジしたくなります。
そうすると、だんだん、データ分析以外の業務も自ら率先してこなし始めるようになります。それが今度は業務の幅やエンジニアリングスキルの向上に繋がりました。
正直葛藤もある
業務の幅が広がった結果、データアナリストだった私は、スクラムマスターも兼任するようになりました。
スクラムマスターとは、スクラムで定義される役割の1つです。この役割は、スクラムのプロセスに対して責任を持ち、チーム全体が自律的に協調できるように、場作りをするファシリテーター的な役割です。（詳しくは、上述の参考書をご覧ください。）
スクラムマスターは、チームの外部から訪れる障害に対して、率先して対応します。極端な話、忙しいチームの飲み会の幹事もします。
業務の幅が広がった反面、データ分析の業務以外の比率が増え、本来の自信の専門性を十二分に発揮できないもどかしさも、最近では正直感じています。ここらへんは、チームの段階や自身のキャリアの考え方によるかと思います。
今後自身はどうしたいか
スクラムはアジャイル開発との混同から、開発手法の1つと考えられがちですが、実際には問題解決のフレームワークであり開発現場以外にも適用できます。そしてスクラムは、ただの枠組みに過ぎないので、この枠組みをもとに自分たちの組織に合ったフレームへと自律的に変容させていくことができます。
今後、スクラムでの経験をもとに、自己組織化を目指すデータ分析組織で、自律的に創造性と情熱を持って働くが私のテーマです。
まとめ
年末のこのタイミングで、自分のこれまでの経験を棚卸する良い機会となりました。ありがとうございます。心身ともにスーパーなエンジニアたちに出会えたことは、自分の社会人生活の大きな財産であります。
簡単ですが、以上です。
*1:ここでのエンジニアリング力とは、データサイエンティスト協会が定義するスキルセットに準拠します。
