スクラム開発をボトムアップで始める (1) 〜 Impediment Listから始める〜

自己紹介

はじめまして「むらたん」です。昨年9月にアスクルへ入社し、3PL事業であるOPA（Open Platform by ASKUL）を担当しています。事業についての詳細はこちらをご覧ください。

OPAはASKULやLOHACOと比べると歴の浅いサービスで、エンジニアチームはまだ立ち上げ段階ということもあることから、現在取り組んでいるチーム作りについて、何回かに分けて紹介したいと思います。

よくあるチーム作りと陥りがちな光景

チームの立ち上げ段階といえば、インセプションデッキを作ったり、ステークホルダーと共にチームビルディングに関するワークショップを小一時間やったりして、チームビルディングできた気になることがありますが、ほとんどの場合、それは幻想だと思っています。

チームの存在意義や目標の共有ができたとしても、チームメンバーの物事の捉え方や考え方、業務の進め方、保有スキルなど、メンバー同士で知らない事の方が多く、チーム活動を始めても機能せず、混乱状態に陥ります。

タックマンモデルと呼ばれるチームの成長段階を表したモデルでは、以下のように定義されています。

フェーズ	説明
形成期 (Forming)	チームが編成され、メンバー同士のこともよく分からないまま、チーム共通の目標を模索している時期
混乱期 (Storming)	チーム共通の目標や業務の進め方について、メンバー同士が衝突する時期
統一期 (Norming)	混乱が収束し、チーム共通の目標や業務の進め方が定まる時期
機能期 (Performing)	メンバー同士が連動し、チームメンバー数以上の成果が出る時期
散会期 (Adjourning)	何らかの理由でチームが解散する時期

ここでも混乱期が定義されていることから、チーム立ち上げ後に混乱状態となることは一般的だと言えます。しかし、メンバー同士で知らない事がある状態であれば、メンバー同士の衝突に加え、認識齟齬による計画とのズレや作業の手戻りが生じたりもするので、必要以上に混乱します。

その状態を脱するには、チームメンバー同士の透明性を確保する必要があります。

チームメンバー同士の透明性を確保する

アジャイル開発でおなじみの「スクラム」は、現状を可視化し、下記の状態を保つように努める業務の進め方で、役割、会議体、成果物、時間概念に関するルールが定められています。

透明性：自分たちの置かれている状況が瞬時に把握できる状態
検査　：置かれている状況の良し悪しが判断できる状態
適応　：状況をより良くできる状態

スクラムで定められたすべてのルールを適用しないとスクラムで開発をやっている状態とは言えませんが、個別のルールを採用するだけでもチームの活動が改善することもあります。

有名どころだと、ふりかえり (Sprint Retrospective) や、デイリースタンドアップミーティング (Daily Scrum) でしょうか。以降、スクラムのルールは英語で書きますので、ルールの詳細についてはスクラムガイドをご参照ください。

これらのルールは導入が容易なため、チーム活動の序盤で取り入れられたりしますが、ルールの背後にある目的や、メンバー同士の理解がない不透明な状態では、導入効果が薄いのではないかと思います。

そこで、私が取り組んでいる、タックマンモデルに則り、スクラムを段階的に適用しながらチームビルディングする方法を紹介します。

タックマンモデル×スクラム

前述の通り、チームのフェーズには段階があるため、スクラムのルールをチームメンバーの透明性の確保、つまり、チームやメンバーのことを理解するために活用します。

チームやメンバーの理解が進み、チームとしての課題の真因が明確になったら、スクラムのルールやエクストリームプログラミング (XP) で提唱されているプラクティスを用いて課題解決を試みます。

このとき、解決すべき課題が明確になっていれば、スクラムやXPの教科書に書かれている模範的な型をどう実践するか、自ずと見えてくるのではないかと思います。

あとはチームに即した形でプロセスを作り上げていけば、チームメンバーの理解を深めながらチーム活動を遂行できるようになります。行き着く先はチームに即したスクラム開発の完成形かもしれませんし、別の手法かもしれません。

タックマンモデルとスクラムの関係をまとめると、以下のようになります。

フェーズ	説明	スクラムのルールを適用する目的	スクラムの状態
形成期	チームメンバーを理解し、お互いの透明性を確保する時期	チーム課題のあぶり出しと管理、解決に向けた仮説検証	スクラムの【前準備】
混乱期	チームやメンバーの特性に合わせて、スクラムを形作る時期	チームに即したルールのテーラリング	スクラム、または別の手法の【開始地点】
統一期	チームとしての生産性を向上させる時期	チームの生産性やビジネスKPIの可視化と向上	スクラム、または別の手法を【守】
機能期	チームが所属する組織の価値を向上させる時期	組織を取り巻くビジネス環境の変化への追従	スクラム、または別の手法を【破】
散会期	チームが解散してメンバーが新しいチームを組成する時期	組織内へのスケール	スクラム、または別の手法を【離】

Impediment Listから始める

さて、本題です。Impediment Listはスクラムのルールで定められている成果物の1つで、チームの活動を支援する役割であるスクラムマスター(Scrum Master)が、チームの活動を阻害する要因を管理するものです。

チームの活動を阻害する要因として、チームの活動拠点のファシリティや他部門との関わり方などチーム外に目が行きがちです。

しかし、チームが形成期でチームやメンバーの特性についての理解が深まっていないようであれば、それらに加えて、チームやメンバーについて理解できていないことも管理して、日々のチーム活動の中で優先度を上げて対応します。チームやメンバーの理解が浅い状態で外的要因を解消しても、その打ち手が本当に効果的か分からないためです。

と、言うのは簡単なので、スクラムのルールの一部を用いて、スクラムマスターが意識するポイントや日々の活動チームやメンバーを理解をするポイントの例を紹介します。（あくまでも、私の取組み例で、個人差があります）

スクラムマスターとして意識するスクラムのルールとポイント

スタート地点となるスクラムのルール：Impediment List
1. 上述の通り、チームやメンバーの不透明な部分を課題として管理し、打ち手を仮説検証する
2. 特定のメンバーに対しての課題であっても、チームの課題として扱い、チームで解決する手立てを講じる
課題がどうなったかを評価し、新しい施策を講じるスクラムのルール：Sprint Retrospective
1. 目の前の課題を解決し、新しい課題を生み出し、また、解決するというサイクルをつくる
2. チーム形成の初期段階ではチームメンバーの目線が揃うまでは公式の活動とせず、スクラムマスターの内省に留める

日々の活動からチームやメンバーを理解するためのスクラムのルールとポイント

活動のフィードバックサイクルとなるスクラムのルール：Sprint
1. 活動のフィードバックサイクルを決めることで、チームの活動にリズムをつくる
活動の良し悪しの評価軸となるスクラムのルール：Sprint Planning
1. フィードバックサイクルに対して計画を立てることで、予定と実績が把握できる状態をつくる
2. タスクの組み方、見通しの立て方、課題解決の方法から、業務の進め方や保有スキルを確認する
日々の活動に対するコミットとなるスクラムのルール：Daily Scrum
1. チームメンバーの日々の状況を確認する場をつくる
2. メンバーの物事の捉え方や業務の進め方を観察する
活動結果を評価するスクラムのルール：Sprint Review
1. 計画に対して、どれだけ達成できたかを確認する場をつくる
2. メンバーが活動結果をどのように捉えているかを観察する

赤裸々告白：OPAのエンジニアチームについて

最後にOPAチームの状況を紹介したいと思います。フェーズとしては混乱期で、チームが抱える最大の敵、認識のズレを打破する施策を試行錯誤しているところです。書き出してみると当たり前のことではありますが、チームの課題に則した形でスクラム開発の手法を作り上げています。

チームの課題とその対応

メンバーのキャリアやバックグラウンドが異なるため、同じ単語を使っていても意味が異なっている。
- 受容するしかないので、使われている単語が何を指しているのか、会話の中で探りながらイメージをすりあわせる。
ゴールイメージがチームメンバーで揃わないまま着手してしまい、タスク完了まで持っていけない。
- スプリントプランニングでタスクへの落とし込み、完了条件の設定に注力する。
メンバーの保有するスキルが偏っており、タスクが平準化できない。
- プロダクトコードを用いて、読み解き方やコードレビューの観点、設計思想を理解する勉強会を定期開催する。