はじめに
こんにちは。株式会社アップルワールドで業務委託として稼働させていただいています、フリーランスエンジニアのさいじょうと申します。
私たちのチームでは現在、アップルワールドの既存システムのリプレイスプロジェクトに取り組んでいます。
何度かプロジェクトの進捗会議に参加させていただいて、以下のような感想をいだきました。
- １人の人がずっと進捗会議で自分のタスクの細かい内容を話して終わっている
- このプロジェクトは順調に進んでいるのか？がよくわからない
- 明らかになっている課題のうち、すぐ対応すべきものは何か？がよくわからない
- 来週は何をやればよいのか？がよくわからない
チーム全体でプロジェクトの状況を明確に共有しながら、進捗を見える化できるように会議改革を行いました。現在ではチーム全員が今どこにいて、どこに向かっているのかを把握できるようになりました。
この記事では、スクラムの考え方を部分的に取り入れることで、チームが抱えていた課題をどのように解決していったかを共有します。完全なスクラム導入ではなく、週1回の定例MTGを軸に、スクラムのエッセンスを活用した実践例として参考になれば幸いです。
スクラムの本質：透明性・検査・適応
スクラムは以下の3本柱で成り立っています。正直、スクラムを勉強した時にはピンと来なかったのですが、今はこんなふうに理解しています。
- 透明性: 情報を必要な人が、いつでも、その情報にアクセスできる状態
- 検査: 定期的に目標との差分を確認すること
- 適応: 検査結果をもとに、改善すること
今回の取り組みでは、まず透明性の確保に注力しました。情報が見えなければ、正しい検査も適応もできないからです。
直面していた5つの課題
チーム立ち上げ当初、以下のような課題に直面していました：
課題1: 進捗の不透明性
定例MTGは実施していたものの、プロジェクトが順調に進んでいるのか、遅れているのかが判断できない状態でした。個々のタスクの話はするものの、全体像が見えていませんでした。
課題2: 個人作業の見えづらさ
誰が何の目的で、どんな作業をしているのかが不明確でした。特に全員が業務委託メンバーという環境では、この問題は深刻でした。
課題3: 長期的な見通しの欠如
このプロジェクトがどのように進んでいくのか、ゴールまでの道筋が共有されていませんでした。
課題4: 技術的意思決定の記録不足
なぜその技術を選択したのか、どういう経緯でその設計になったのかという情報が残っていませんでした。
課題5: 非効率な朝会
複数チーム合同の朝会で、関係ない話が長く、本当に話したいことが埋もれてしまっていました。
スクラムの考え方を活用した4つの取り組み
やったこと1: 課題1と課題3への対策 - プロダクトバックログの考え方でプロジェクトロードマップを作成
スクラムにおけるプロダクトバックログとは
プロダクトバックログは、**プロダクトに必要なすべての機能・要求・改善点を一元管理する唯一の情報源（Single Source of Truth: SSOT）**です。重要なのは以下の特徴です：
- 優先順位付けされている: 価値の高いものから順番に並んでいる
- 常に最新: 新しい発見や変更が即座に反映される
- 誰でもアクセス可能: チーム全員が同じ情報を見ている
- 進捗が一目瞭然: 完了・進行中・未着手が明確
私たちの実装：プロジェクトロードマップ
この考え方を参考に、プロジェクトロードマップを作成しました：
実際に使用しているロードマップ。✅ついてるやつが終わったやつ。☑️は今週終わらせる予定のやつ。
さらに、定例MTGの進め方も変革しました：
Before（ただの進捗報告会）:
- 「私は〇〇をやっていて、60%くらい終わりました」
- 「次は△△をやります」
After（今週完了したことをロードマップ上にチェックをつける、来週どの項目にチェックがついてたら嬉しいかを話すアクティビティに）:
- レビュー要素: ロードマップのどの項目が「完了」になったか確認
- プランニング要素: 次の1週間で「完了」にする項目を選定
- 全体感の共有: 選んだ項目で1週間のキャパシティは適切か議論
なぜこれが効果的だったか
- SSOT効果: 「進捗を知りたければロードマップを見る」という単純明快なルール
- 認知負荷の軽減: 情報が分散していないため、探す手間がない
- 共通言語の確立: 「今、ロードマップの3番をやってます」で通じる
- 予測可能性: 毎週どれくらい進むかが見えてくる
やったこと2: 課題2への対策 - スプリントバックログとユーザーストーリーの考え方でチケット化
スクラムにおけるスプリントバックログとは
スプリントバックログはそのスプリントで取り組む作業項目とその計画です。以下の特徴があります：
- チームの所有物: チームが自律的に管理
- 詳細な作業内容: 誰が見ても何をするか分かる
- 完了の定義が明確: いつ終わったと言えるかが明確
ユーザーストーリーの価値
ユーザーストーリーは「誰が、何をしたくて、なぜそれが必要か」を表現します：
As a [誰が]
I want [何を]
So that [なぜ/どんな価値]
私たちの実装：チケット化システム
定例で決めた週次目標を、以下の形式でチケット化しました：
実施プロセス：
- 各自でチケット作成
- メンバー同士でレビュー
- ステータスとアサイニーで進捗管理
なぜこれが効果的だったか
- 文脈の共有: レビュアーも「なぜこれが必要か」を理解できる
- 完了の明確化: チェックリストが全部埋まれば完了
- SSOT for Tasks: チケット一覧を見れば、誰が何をやっているか一目瞭然
- マネージャーの負荷軽減: チケット一覧を見るだけで進捗把握が可能
やったこと3: 課題4への対策 - ADR (Architecture Decision Records) で意思決定を文書化
これはスクラムの枠組みには含まれませんが、透明性の原則を技術的意思決定にも適用しました。
ADR
なぜこれが効果的だったか
- 未来の自分たちへの贈り物: 「なぜこの技術？」にいつでも答えられる
- 議論の土台: 文書ベースで建設的な技術議論が可能
- オンボーディング: 新メンバーも経緯を理解できる
やったこと4: 課題5への対策 - デイリースクラムの考え方でチーム別ハドルを実施
スクラムにおけるデイリースクラムとは
デイリースクラムは15分以内で行う日次の同期イベントで、以下を目的とします：
- 進捗の確認: スプリントゴールに向かっているか
- 障害の特定: ブロッカーがないか
- 今日の計画: 何に取り組むか
重要なのは「報告会ではなく、計画会議」であることです。
私たちの実装：自信度の5フィンガーによる状態共有
毎日ではなく週3回、15分のハドルを実施：
【ハドルの進行】
1. 「今週の目標達成の自信度は？」（1-5点）
2. 点数の理由を共有
3. 「4-5点にするために何が必要？」を議論
4. 何か話しておきたいことがあればしゃべる
例：
メンバーA: 「3点です。エラーハンドリングの実装について、実装は終わりそうですが、マージまで行けるかどうか。。。」
メンバーB: 「じゃあ最優先でレビューするようにしましょう。」
なぜこれが効果的だったか
- 心理的安全性: 数値化することで「助けが必要」と言いやすい
- 協力の促進: 自然に助け合いが生まれる
- 時間の効率化: 15分で必要十分な同期が完了
得られた成果：透明性がもたらしたもの
情報のSSOT化による効率向上
それぞれの情報に「見るべき場所」が明確になりました：
- プロジェクト進捗 → ロードマップ
- 週次の作業 → チケット一覧
- 技術的決定 → ADR
「どこを見ればいいか」が明確になり、情報を探す時間が激減しました。
共通認識の形成
全員が同じ情報を見ているため、認識のズレが減り、コミュニケーションコストが大幅に削減されました。
自律的なチーム
情報が透明になったことで、メンバーが自律的に判断・行動できるようになりました。
メンバーの声
実際にメンバーからは「何をやればいいのかが明確になって作業に集中しやすくなった」という声をもらいました。
また、マネージャーからは「今の状況の把握がロードマップとタスク一覧を見ればいいので、すごく楽。ありがたい。全プロジェクトこうだったらいいのに。」とのコメントをいただきました。
思った通りの効果が出ていて、よかったです。
正直な課題：まだ解決できていないこと
タスク一覧の更新遅延問題
実は、タスク一覧のステータス更新が遅れがちという課題があります。
タスク一覧がチームの週次目標を把握するツールとして機能し続けるには、チームに「この一覧は常に最新だ」と信頼してもらう必要があります。形骸化を防ぐために、今はデイリーで「更新をお願いします」と声かけしている状況です。
正直、毎回リマインドするのは本質的ではないと感じています。理想は自動化なのですが、まだそこまで手が回っていません。
リファインメント不足による認識不一致問題
今チケットレビューは行っているものの、あまり細かくレビューはしあっていません。
チケットごとの認識があっていないことがちょいちょいあります。チケットに細かい仕様が書かれていなかったり、受け入れ基準自体が発展途上になっています。
ちゃんとリファインメントを時間を使って行い、チケットごとにどんなアウトプットを作成するか、それによってどういうったアウトカムが発生するのかをチームで話し合って決めた方が、結果的に認識齟齬がなくて、早く進むのではないかと考えています。
こちらもまだそこまで手が回っていません。
今後の展望：透明性から検査・適応へ
次のステップ：振り返り会の導入
現在は透明性の確保ができたので、次は定期的な振り返りを導入予定です：
- 何がうまくいったか
- 何を改善できるか
- 次のアクションは何か
- など
動くソフトウェアの重要性
アジャイルでは「動くソフトウェア」を重視します。現在は基盤実装が中心ですが、毎週小さくても動くものをデモする文化を作りたいと考えています。
やはり動くソフトウェアは世界を救うと思っています。完璧でなくても、動くものを見せることで、チームのモチベーションも上がり、ステークホルダーからのフィードバックも得られ、より良いプロダクトへと進化していけるはずです。
まとめ：スクラムは「考え方」
今回の経験で学んだのは、スクラムは単なるフレームワークではなく考え方だということです。
- 透明性: すべての情報を見える化し、SSOTを作る
- 検査: 定期的に現状を確認する仕組みを作る
- 適応: 改善し続ける文化を醸成する
完璧なスクラムの実践を目指すのではなく、チームの課題に対してスクラムの考え方をどう応用するかを考えることが、私たちのチームにとって有効でした。
今回はあえてスプリントやプロダクトバックログといった、スクラムの用語を使用していません。私たちはスクラムを実践したいのではなく、高品質なソフトウェアを爆速で開発したいだけだからです。スクラムの用語を使わず、徐々にチームの課題を改善しながら、我々オリジナルのアジャイルなスタイルを確立していければと考えています。
皆さんのチームでも、「情報が見えない」「進捗がわからない」といった課題があれば、まずは透明性の確保から始めてみてはいかがでしょうか。それぞれのチームに合った形で、スクラムのエッセンスを取り入れることで、課題解決の糸口が見つかるかもしれません。
Discussion