合流した時の状況＝課題だらけ
小谷口がプロダクトオーナー（PO）、佐藤がスクラムマスター（SM）としてチームに合流したのは2018年中旬になります。
この時、全社的な開発組織改革でプロダクトチーム制とスクラムを全面的に取り入れることになりました。
小谷口は別のチームでスクラム体制を実践しており、POとして活動していました。
ポイントチームでも合流前からスクラム開発を導入していたのですが、スプリントイベントに参加すると…。
- チーム内が開発・運用の2チームに分かれていた
- ストーリーポイントと時間が連動していた
- スプリントで終わりきらないストーリーがほとんど
- 完了の定義がないストーリー
- 振り返りが単なる反省会となっている
など、大小様々の課題が出てきました。
合流前所属していたチームでもスクラムをやっていたので、そこで得た知識ややり方を導入出来ればかなり改善が進むと思い、大ナタをコンパクトに振っていくことにしました。
なぜ上手くいかないのか？
チーム内チーム
まず一番驚いたのは、チームがアプリケーション開発専門部隊と既存システムの保守運用を行う部隊に分かれていたことです。 朝会、プランニング、レビューなどミーティングは全て別の時間帯でおこなわれ、バックログも別管理になっていました。
メンバー間の交流の場はあったものの、週に1回程度でした。 この場合、「作るだけの人」と「動かすだけの人」に分かれてしまいます。
どちらのチームにも同一人物がオーダーを出していました。全てを把握しているのはその人だけという状態になります。 メンバーは基本的にオーダーに従うだけなので、猛烈な「やらされてる感」が発生します。
ストーリーポイントと時間の連動
ストーリーポイント（SP）を時間換算（1SP＝8時間など）するやり方です。
スクラム導入時、SPの基準が分かりにくいのでこのような手法を取るところは多いと思います。 ただし、人によってかかる時間はバラバラなので、予測と実測がおかしくなることのほうが圧倒的に多いです。 見積もりの基準としては間違っていないと思いますが、次の項目とあわせるとSPが無限に膨れ上がる危険性をはらんでいます。
そのストーリーにかけた時間をものすごく正確に計測すれば予実を近づけることができるのかもしれませんが、その結果マイクロマネジメントと化し、メンバーのやる気をそぐことになります。
プリント内で終わらないストーリース
SPを時間として計測しているのですが、前述のとおり、ほとんどの場合で予測と実測が合わなくなります。 すると、スプリント内では終わらなかったストーリーが発生します。
終わらない理由は様々あるにせよ、それをそのまま次のスプリントに入れてしまうとどうなるでしょうか?
時間換算をしていると、スプリントで費やした時間＋次のスプリントで費やす時間となり、「あと何時間で終わるのか」が分からない状況に陥ってきます。
そうこうしているうちに、SP1=8時間のつもりが、そのストーリーにかかった時間が何倍にも膨れ上がってしまいます。
オーダーを出した人は早く終わらせてほしいし、作業をするメンバーは終わりが見えなくなります。 結果として両者の間で軋轢が発生するようになります。
完成の定義がない
ストーリーに完成の定義のないものがあります。
このストーリーはどうなったら終わるのかを誰も判断できない状態です。 そのため、毎日の朝会で非建設的な激論が繰り広げられ、15分で終わるはずの朝会が延々1時間くらい続く時もあります。 ここでもオーダーを出す人の想定と、メンバーの想定に認識のずれが生じ、両者の間にある溝はさらに広く深くなっていきます。
振り返りという名の反省会
スクラムに準拠しているので、レトロスペクティヴ（振り返り）を行っていましたが、メンバー個々人が、そのスプリントで起きたことを他のメンバーに伝えるだけになっていました。
個人的な問題や話題に終始するので、共通の話題はほぼ出てこず、問題が問題と認識されないことが発生していました。 出てきた内容についても議論はされず、端的に言うと「次は頑張ります」で終わってしまいます。
何らかのTRYが出てきても、ほぼ個人に紐付くものばかりです。 共通の話題がないので個人の反省を聞くだけになってしまい、メンバーの結束が生まれず、チームとして機能しなくなってきます。
どんな感じに変えていったか
作業の見積もりを時間から規模感へ
まず初めに見積もりのやり方を変えました。 時間による絶対見積もりから規模感による相対見積もりに変更し、メンバーが主体となってSPを付けるようにしました。
最初にストーリーを大・中・小に分類し、その後基準となるストーリーに対して作業規模を比較してSPを付けるようにしました。 例えば新規APIの開発であれば、まず不確実性の高い設計は大に分類し、定型作業化されているリリース作業は小に分類します。
全てのストーリーを大・中・小に分類した後、基準となるストーリーに3SPを設定してから、他のストーリーにも作業規模感を比較してSPを付けていきます。
この変更により担当するメンバーによる作業見積もりのズレが解消され、見積もりの責務を開発チームに移譲できました。
ベロシティを基にしたスプリントプランニング
SPを相対見積もりに変更した後はベロシティの計測を開始しました。 これまでは稼働時間に対して絶対見積もりで付けたSPを基にスプリントを計画していましたが、直近３スプリントのベロシティを基にして消化可能なストーリー数を判断するようにしていきました。
ただし、スプリントに組み込むストーリー数の最終的な判断は開発チームが責任を持ちます。 実際にスプリント内で実現可能かどうかは開発チームしか分からないためです。
そのため、スプリントプランニングを二部構成にし、第一部でPOからベロシティを基にしたストーリー数を提示してもらい、第二部で開発チームがストーリーをタスク分解して実現可能かを判断するようにしています。
これまでのリーダーによるマイクロマネジメントからチームメンバーを主体としたマクロマネジメントへと変わっていきました。
レトロスペクティヴの見直し
次にレトロスペクティヴの見直しを進めてきました。
これまでは個々の作業の反省会に近いものになっており、スクラム運用についてなどチーム全体に対するTRY出しができていませんでした。
見直しの第一歩としてレトロスペクティヴにおける「チームの約束」決めを行い、振り返りを行う目的・目標を毎回確認するようにしました。
また振り返りの手法もKPTだけではなく、学習マトリックスやFun/Done/Learnなどを取り入れ、振り返りがマンネリ化しないようにしています。
これにより個人の反省会の場からチーム運用の改善の場へと改善されていきました。
デイリースクラムの時間を短縮
デイリースクラムでも個々の作業ベースでの反省会に近い状態となっていました。 一人一人が昨日の作業内容と問題点、当日の作業予定を報告していたため、内容が重複していたり、その場で問題の解決を図り時間がかかってしまったりしていたケースが多くありました。
問題解決の議論に時間がかかりすぎてしまうと、本来の目的である作業進捗の検査や今後の進め方の再検査に割ける時間がなくなってしまいます。 そのため報告の粒度を見直し、報告内容をシンプルにするよう変更しました。
- 報告の単位は、個々人の作業ベースからストーリー単位での報告へ変更
- 「昨日やったこと」「今日やること」「何か問題が起きていないか」を大筋とし、問題解決の議論は朝会終了後に必要なメンバーを集めて実施
初めのうちは変更前のように話し合ってしまうケースが見られましたが、レトロスペクティヴなどを通して徐々に改善されていきました。
開発・運用チームの合流
ここまでで各スクラムイベントが見直され、スプリントがスムーズに回るようになってきたため、チーム内で分かれていた開発・運用チームを合流させることにしました。
これにより合流前よりも保守・運用を意識したプロダクト開発を行うことができるようになりました。
合流にあたりスクラム運用とは別の問題として、チーム内チームの運用が長く、開発・運用チームのメンバー間でスキル差が生じていました。
ペアプログラミングやモブプログラミングの積極採用
開発チーム/運用チームに分かれていたことから生じたメンバー間の業務知識やスキルの差の平準化、属人化の排除などの効果を期待して、ポイントチームでは1年以上前からペアプログラミング（以下ペアプロ）やモブプログラミング（以下モブプロ）を積極採用しています。
この章ではポイントチームの実体験に基づいたペアプロ/モブプロの効果について紹介します。
ペアプロ/モブプロとは？
まず、ペアプロについて簡単に紹介します。
ペアプロは1台のPCで2人のエンジニアが共同で作業を行う手法です。 2人にはそれぞれ「ドライバ」と「ナビゲータ」の役割があり、定期的（1時間毎など）に役割を交代します。
ナビゲータはコードの記述に関する指示を出したり、調査や誤りの指摘などサポートを行ったりしますが、コードの記述は行いません。
ドライバは実際にPCの操作を行い、コードを記述します。
モブプロはペアプロを3人以上で行う場合の言い方です。 モブプロの場合、「ドライバ」を行うのは1名で、それ以外のメンバーは「ナビゲータ」となります。
ポイントチームで実施しているペアプロ/モブプロ
ポイントチームのペアプロ/モブプロの実施方法について紹介します。
ペアプロ/モブプロ文化の形成
ポイントチームでは作業を行う際にペアプロ/モブプロで実施することを標準としています。
作業内容によっては一人で進めるほうが適切な場合もあるので、その場合はしっかりと理由付をして、臨機応変に対応しています。 こうすることで、ペアプロ/モブプロで作業することが当たり前になり、ポイントチームの文化として根付いていきました。
また、全員がオフィスに出社していた頃は、ペアやモブを意識するため、簡易的ですがグループ分けを壁に貼り出していました。 （メンバーのSlackアイコンを紙に印刷してマグネットで貼り付けています）。
作業人数
一つの作業を行うグループはだいたい2〜3人になるようにしています。
実際に4人以上で作業を実施したところ、「ナビゲータ」役の人が何もしない時間ができてしまいがちで非効率であると感じました。 ただし、作業を進めることではなく、「情報共有」がメインの目的となる場合は、4人以上でも問題ないと考えています。
リモート環境でのペアプロ/モブプロ
現在はチーム全員リモートワークを実施しています。
ペアプロ/モブプロと聞くと、一つの画面を使って、顔を突き合わせて実施するイメージを持つかもしれませんが、リモートでもZoom等の画面共有アプリを使うことで問題なく作業できます。
リモートの場合ドライバが画面共有を行い、ナビゲータがその画面を見ながら一緒に作業を進めています。
ペアプロ/モブプロをすることによる良い効果
属人化を防ぐことができる
複数人で作業を行うことで、作業中の思考の過程も含めて自然に共有できます。
思考の段階から一緒に作業を進めることで、複数のメンバーが自分事として捉えることができます。
ソフトウェア開発は往々にして開発した本人が仕様に一番詳しいという状況が発生すると思いますが、開発者が複数人になることで属人化を防げると考えています。 一人で作業をしたモノに対して情報共有やレビューを行っても、思考の過程まで共有することは難しく、その点ではペアプロ/モブプロのほうに圧倒的な強みがあると感じています。
優先度の高いタスクから確実に片付けられる
例えば3つのタスクがあり、そのうち一つだけ優先度が高く、高難易度だとします。
チームが3名の場合、それぞれでタスクを行えば並行で進めることができますが、最も重要な優先度の高いタスクだけ終わらなくなってしまう可能性があります。 ペアプロ/モブプロをすることで、優先度の高いタスクに複数人で群がって取り掛かることができ、優先度の高いタスクから確実に片付けることができます。
同様に、メンバーが体調不良等で突然休暇を取得しても、他のメンバーで続きを進められるため、優先度の高いタスクから順に片付けることができます。
レビュー待ちで作業が止まらない
ポイントチームでは開発したコードをmasterブランチにマージする前にプルリクエストを作成し、1名以上のメンバーの承認を得てからマージするルールにしています。
ペアプロ/モブプロを採用する前は、プルリクエストを作成してもすぐにレビューしてもらえず、レビュー待ち時間が発生しました。 ペアプロ/モブプロを採用してからは、一緒に作業をしているメンバー同士ですぐにレビューができるので、待ち時間が発生せずに効率的に作業を進められるようになりました。
メンバーの成熟度が相乗的に上がる
お互いが持っている技術や業務知識を出し合いながら設計や開発を行うため、一人で作業するより考えの幅が広がり、成長できる環境になったと感じています。
困難な問題が発生してもその場ですぐに相談/議論できるので、一人で無駄に悩むことがなくなりました。
必ずしも良いことだけではない
一人で作業したほうが良い場合もある
実体験として、一人で作業をしたほうがいい場面もあります。
例えば、やることがほとんど決まっている定形作業や似たようなものを複製する作業です。 このような作業の場合、あまり議論が発生せず、共有すべき情報もあまりないため、一人で作業を進めるほうが効率的だと考えています。
成果物の品質は向上するのか
複数人で作業すると、一人で作業するよりも成果物の品質が良くなるイメージを持たれているかもしれませんが、必ずしも良くなるとは限りません。 もちろん、複数人いることでミスや問題点に気付けるケースも多々あります。
ですが、他のメンバーのペースに合わせて開発をすることで、深く思考せずに「他の人がOKって言っているから良いか」と他人任せになってしまいがちで、仕様漏れに気付かないケースが発生しています。
不安に思ったタイミングで作業を止めて思考をしたり、質問をしたりすることも大事ですが、後で問題に気付いた時にすぐに直せるためのCI/CDを用意しておくことが最も重要だと私は考えています。
誰も経験のない作業を最初からペアプロ/モブプロするのは難しい
誰も経験がないことの場合、最初に調査や学習が必要になると思います。
最初からペアプロ/モブプロを実施してしまうと、全員で悩むだけの無駄な時間が発生してしまいます。
その場合は、最初に個人の学習時間を設けてから、ペアプロ/モブプロを始めるようにしています。 ペアプロ/モブプロをしている途中で調査や学習が必要になった場合も同様に、個人の時間を作ってからペアプロ/モブプロを再開することで効率的に開発を進められるように工夫をしています。
まとめ
今回の記事では、スクラム導入時の課題とその解決策について実体験を元に紹介しました。
チームやプロダクトの特性によって発生する課題や解決策は無数に存在します。 紹介した内容は一例として参考にしていただき、それぞれのチームにあったスクラム開発の方法を探してみてください。
