こんにちは、back check というサービスでスクラムマスターをやっている山口です。
今回は急造のインフラチームで緊急性の高い開発案件に取り組んだ際にチームがつらい思いをしたので、失敗談とそこから学んだことについて書きたいと思います。
飛び込んできた、なるはやインフラ案件
back check の開発チームでは、現在インフラ環境の移行を実施しています。
もともとはアプリケーション開発チームの中でサブチームとしてフィーチャーの開発の合間に粛々とインフラ環境の移行作業を行ってきました。 しかしインフラ周りの優先度の高い要件がでてきたことで、これに対応するために移行に必要のない作業を省いて最短で進めるという対応でプロジェクト化し進めることにしました。
そのためにまずはインフラチームをアプリケーション開発チームから切り出すことで作業以外の時間について、MTGやCS依頼対応に使う時間をなくし、やることを必要最低限に絞りました。 さらにインフラ移行の中でもミニマム要件のスコープを絞り、セキュリティ面の担保以外は移行完了後に回してとにかく早く新環境でサービスが動く状態を目指しました。 また急ぎの要件だったため、作業の計画についても必要なタスクを粗い粒度で切り出し、とりあえずガントチャートで完了予定日までの線表を用意した上ですぐさま開発に着手しました。
一応この段階で、POと開発者の間で完了予定日についてはサービスの0→1フェーズの技術的負債が多く残っており、現段階では確度の高いものではないため予定が後にずれ込む可能性が高いことを共通認識としてすりあわせておりました。
開発が進むにつれて表面化してきた課題
このプロジェクトでは週次でPOと進捗の共有会を行っていたこともあり、最初の1ヶ月は共有の場でもスケジュールの2~3日程度の遅れによる調整が発生する程度で特に問題もなく進んでいたように見えました。 しかし、プロジェクトが進むにつれてぽつりぽつりと課題が出てきました。
度重なる予定変更
週次の共有会を重ねるにつれ、ガントチャートの調整に掛かる時間がだんだんと長くなってきました。 要因としては、アサインされたタスクを進めてみたら実は別タスクに作業が依存しており、現在は依存先のタスクを進めているとか。 1週間程度で完了できると見積もっていたタスクに着手してみたら、想定よりも作業量が多く計画に遅れが生じているとか。 週を重ねるごとに進捗共有会だったはずの場がガントチャートの調整会のようになってしまいました。
ここでの深掘りとしては、タスクの内容を詳細化せずに着手してしまったところに課題がありそうでした。
メンバー同士の低い透明性
また、度重なる予定の変更にあわせてインフラチームはそれぞれの得意領域を個別に進めていたため、声をかければ集まれはするものの他方のメンバーの作業もスケジュールに遅れがでていることから気が引けて作業の詰まったポイントがあっても相談しづらい状況になっていきました。
これは、チームメンバー間で障害を共有する仕組みがない点が原因でした。
不確実性を織り込めない開発計画
ここまでで多くのスケジュールの遅れと、それによるガントチャートの調整が発生しました。 しかし、前述したとおり「完了予定日が後にずれ込む可能性が高いこと」は事前にPOと開発者の間で共通認識を持てていたはずでした。 ただこの時点で開発者からつらいという声が上がってくるようになりました。 要因を聞いてみると、予定を毎週遅らせることによる罪悪感と、手詰まりになったときにみんな忙しそうで声をかけづらいことでメンタル面で追い詰められてきているとのことでした。
ここでの問題点として、不確実性が高いとわかっていた開発プロジェクトに対してガントチャートで完了予定日を表現していることで、PO、開発者、そしてSMの私を含め完了予定日を管理できると錯覚していたことがこれらのつらさの根本原因だと考えました。
課題へのアプローチ
度重なる予定変更
度重なる作業計画の変更の原因のひとつとして、計画したタスクの内容を詳細化せずに着手してしまったところに課題がありそうと前述で述べました。
これらの作業計画の変更の一部は、着手前にチームとして必要な作業を深掘りしていれば事前に予測して計画に折り込むことができたのではないかと推測しました。 そこで、直近開発を計画しているタスクについては必要なことを深掘りする時間を設けて完了までに必要な作業をチームで話し合うこととしました。
メンバー同士の低い透明性
相手の作業状況がわからず声がかけづらいことの原因として、チームメンバー間で障害を共有する仕組みがないことがあげられました。
ここについては、毎日インフラチーム全員で集まる時間を作り、お互いの障害になっていることがあればここで相談できる時間を設けることとしました。 また、これによって一人で作業をしている閉塞感を少しでも解消できるのではないかというメリットもありそうと感じています。
不確実性を織り込めない開発計画
完了予定日を管理できると錯覚してしまうような、不確実性を表現できていない開発計画については2つのアプローチをとることとしました。
1つめは不確実性を計画で表現できていないことに課題があるので、これを解決するために完了予定日にはあらかじめ幅を持たせた日程で共通認識を持つこととしました。
具体的な方法としては以下の流れで完了予定期間の合意をとりました。
- 既存の粗い粒度のタスクをそれぞれストーリーポイントで相対的に見積もります。
- 遅れなく進んだ場合と遅れを想定してバッファを含んだ場合それぞれの完了予定期間を幅を持たせた見積もりとして計上します。
- ただし、この見積もりの幅は週を重ねるごとにベロシティ（1週間に完成したタスクのストーリーポイントの総和の過去平均）の精度があがっていくため正確性を増していきます。
幅それぞれの見積もり方法は以下です。 こちらは書籍「アジャイルな見積もりと計画づくり」に書かれている「より単純なバッファ」の計算方法になります。
遅れなく進んだ場合：ストーリーポイントの総和 / ベロシティ = 必要な週数
バッファを折り込んだ場合：（ストーリーポイントの総和 + ストーリーポイントの総和の50%） / ベロシティ = 必要な週数
2つめは週単位でチームのゴールを設定する取り組みです。 これによって複雑な開発に対して小さな完了を積み上げることで着実なプロジェクトの前進を試みることとしました。
表出したそれぞれの課題に対して、チームとして実験的に以上のアプローチを実施しました。 とはいえこれらの取り組みはまだ適用したばかりです。チームとして、今後成果がでるかを観察をしていく予定です。
つらさから学んだこと
これらの過程を通してインフラチーム、そしてスクラムマスターとしていくつかのことを学んだので書きます。
開発プロセスの整理
急ぎの開発案件だったとはいえ、チームとして機能する開発プロセスが用意できていない状態で作業に着手するのは悪手だと感じました。
チームとして機能するプロセスが整理できていない状態では、時間が経つほど生産性が低下していきます。
どんな優秀なメンバーが集まったのであれ、チームとしての仕事の進め方をきちんと整理してから作業に入ることが大切だと痛感しました。
プロジェクト計画を不確実性に対応させる
ソフトウェア開発はそもそもが不確実性の高いジャンルの仕事です。 ガントチャートを用意することで、完了予定日を正確に予測・管理できると錯覚しがちですが、複雑な物事が予定通り正確に進むことはまずありません。
プロジェクトを計画する際には、不確実性を折り込んだ計画づくりをしましょう。
透明性
ここではチームメンバー間の作業の透明性について述べましたが、プロジェクトの進捗管理やその他どこにおいても透明性が高い状態にあることが重要です。
透明性が高い環境によって、コミュニケーションや意思の疎通のハードルがぐっとさがるように思います。
今回感じたつらさはこれらの条件が満たせていない状況で気づかないうちに積み重なっていきました。そしてこれからもつらさ、やりづらさは出てくると思います。チームとしてこれらの障害をうまく乗り越えていくために、定期的に立ち止まってふりかえることが大切だと学びました。
まとめ
未整理のプロセスと、不確実性に対応していない計画によってチームの生産性は下がり、みんながつらくなります。
コードを書き出すその前に。 きちんと成果をだせる環境の準備がプロジェクトの最初のタスクです。
みなさんも日常のプロセスに違和感を感じることがあったら、立ち止まって環境をふりかえってみてはいかがでしょうか？
