はじめに

自分は先日まである案件を担当していました。その案件はシステム移行という「終わりがあるプロジェクト」でした。「終わりのあるプロジェクト」はアジャイル開発との相性が良くないのですが、自分のたっての希望で、スクラムのイベントを取り入れてみることにしました。

プロジェクトの概要

プロジェクトの概要は次の通りです。アプリの改修を含んでいますが、移行がメインのプロジェクトでした。

• 先行で調査フェーズを行ったあと、2022年12月から開始

• チーム人数は5名(のち4名) + お客様のエンジニアなど数名

• 担当領域はアプリとインフラの移行プロジェクト

• 早く移行することが最優先

スクラム導入じゃない

始めに断っておきますが、今回やったのはスクラムの導入ではありません。

「終わりのあるプロジェクト」ではどうしても「終わらせる」ことへの圧力が強いため、スクラムを導入しても歪みが生じる可能性が非常に高いです。そしてスクラムガイド(2020)では次のように勝手に改変することを諌めています。

そのため、最初から「スクラムを導入」と言いませんでした。チームメンバーにも「これはスクラムじゃないよ」と言っています。

取り入れたイベント

具体的には次のイベントを行いました(スクラムと誤解されないように、あえて名前を変えています)。これとは別に「一週間の計画」の中で「今週の目標」を作成して、「朝会」で見直ししています。

• 「一週間区切り」

• 「一週間の計画」

• 「朝会」

• 「タスクの棚卸し」

• 「ふりかえり」

一週間のスケジュールは次のようになります。お客様との定例ミーティングを中心にイベントを集めています。

なお、朝会が1時間と長いのは、ThoughtWorks社のTechnology RadarでRethinking remote standupsという、定例ミーティングを長くして議論などに充てるプラクティスが紹介されていたからです。リモートチームということもあり、コミュニケーションを重視する形でイベントを調整しました。

うまくいったこと

最初はうまくいくかどうか確信が持てませんでしたが、当初想定していたよりもうまくいきました。具体的には次の3点がうまくいきました。

• 一週間区切りのリズムが作れた

• チーム内での認識が取りやすく、コミュニケーションミスが減った

• コミュニケーションが取りやすく、再計画ができた

チーム内コミュニケーションには結構時間を使いましたが、コミュニケーションミスによる手戻りが少なかったのと、後半になるほどチーム内の連携が取れてパフォーマンスが上がってきたため、十分な効果が得られたと思います。

このように、期間を小さく区切って、コミュニケーションを重視してチームで進めるやり方は「終わりがあるプロジェクト」でも有効だと感じました。

うまくいかなかったこと

一方でうまくいかなかったこと、十分な効果が得られなかったこともあります。次の3点です。

• 定例イベントが「進捗報告」になってしまっていた

• 「ふりかえり」「一週間の計画」がおざなりになった

• 属人化が避けられなかった

1つ目はどうしても移行プロジェクトという特性上、移行が完了するまでの全ての成果物は「中間成果物」あるいは「仕掛かり中の在庫」に過ぎません。自分はアプリ側に携わっており、改修箇所のテストなど念入りに整備していましたが、こまめにリリースすることができませんでした。

2つ目はプロジェクトの後半、リリースに合わせるために「ふりかえり」「一週間の計画」がおざなりになり、短縮、あるいはスキップすることもありました。

3つ目はなるべくペアで最初から作業することを勧めていましたが、内容の専門性が高く、全員でカバーするのは無理でした。

3つの課題がありましたが、今回の案件特有の「終わりのあるプロジェクト」「早く移行すること」を前提とすれば、十分な結果が出たのではないかと思います。

おわりに

最初に「自分のたっての希望で、スクラムのイベントを取り入れてみることにしました」と書きましたが、その理由は、不確実性が高いプロジェクトだったため、計画を立てることに時間をかけることよりも、計画を随時修正する方が大切だと考えたからです。

自分はこれまでの経験上、当初思い描いていた計画通りだったことはほぼありません。必ず大きな障害にぶつかります。規模が大きくなるほど、楽観視しているほど危ないです。計画を立てるのはいいとしても、計画が合わないと思ったら修正していくことが必要です。

また、トラブルの原因の多くはコミュニケーションミスによるものです。コミュニケーションミスによって時間をロスするくらいなら、最初からコミュニケーションに時間を使った方が良いです。

今回も、大まかな人員計画やスケジュール計画、作業計画は立てましたが、机上で「完璧な計画」を立てることよりも、実際に手を動かして検証することを重視しました。実際に手を動かして検証すると思いもよらなかった事象が発生し、計画を大きく変える必要性が出てきました。

もし最初から「完璧な計画」を作ろうとしていたら、計画が外れたときのリスクが大きく、スケジュールに大きな影響が出たでしょう。今回は早めに手を動かして検証することによってリスクを早期に見つけ出すことができました。こまめにフィードバックをもらい、軌道修正していく反復型プロセスを取り入れたことが、案件をスムーズに進められた要因だと考えています。