アジャイルを怠惰の言い訳に使うな高校校歌・プロジェクト管理編

はじめに

株式会社ウェイブでエンジニアをしている者です。
ふとここN年くらいのプロジェクト管理について振り返ってみて、思ったことを書きました。
似たような話はたまに目にするので、一般的な話よりも実体験に基づく話にしています。

主張（自戒含む）

スピード重視でも、

• チケット管理はする（当たり前）
• ドキュメントは書く（当たり前）
• だけではないけどそんな感じ

背景

https://zenn.dev/wwwave/articles/3cceb8b0393128#背景

N年前、プロダクトチームのメンバーは、（ほぼ）スクラム開発の形骸化を感じ、体制の見直しを検討した。タイムリーな課題にしっかり対応していくために、リリースサイクルのスピードを意識して開発に取り組むようになったのであった！

本編

チケットが適当すぎて振り返りができない

体制変更前

体制変更前は、主に企画メンバーが要件をまとめた仮チケットがリファインメントにかけられて詳細の検討がなされ、プランニングで優先度をもとにスプリントへの追加が行われ、実際に開発に進む、という流れでした。

体制変更後

スプリントごとに行うリファインメント、プランニングなどのスクラムイベントは継続しましたが、変更前ほど厳密ではなくなりました。

どの課題に取り組むかを検討する初期の段階からエンジニアも議論に参加するようになりました。解決案の実現性や、MVPをどのような状態と定義するのかということをより早い段階から検討しやすくなるため、大きな手戻りが少なくなることも期待されました。
また、開発フェーズになったらあとは全部エンジニアがやるというわけでもなく、非エンジニアとも細かくコミュニケーションを取りながら実装を進めていく感じでした。

結果

全員が機能開発のほぼ全フェーズに関わるようになったため、その時のプロダクトの状況への意識は高くなったのではないかと思います。各種指標をもとに会話が始まることも増えました。

一方で気になったのはチケット管理の雑さです。
「プロダクトに必要なものは常に変わり続ける」ということを意識した結果、「ある時点で決まっていた仕様」が軽視されるようになってしまっていたような気がします。それが進み、一番重要なことがチャット上に残っているということも発生してしまいました。
以前はチケットに仕様の詳細を記載することになっており、大体のことはJiraを見れば把握できる状態でした（）。別のドキュメントがある場合も、Jiraのチケットを起点に辿れるという一定の信頼感がありました。

チケット管理が雑になり記載内容もまちまちになった結果、Jiraが信頼できる情報源ではなくなったように感じます。例えば過去に実装した機能の修正をするとき、当時の開発の意図を知るためにJiraで検索、Slackを検索、Google Driveを検索、Google Chatを検索...のように無駄な作業をすることがあります。

アジャイル開発ではスピードも重要ですが、各種指標の測定も重要だと言われます。
（アジャイルメトリクス半分くらい読んだ😇）
測定するのはプロダクトの指標だけではなく、開発プロセスについても言えます。
プロダクトと同様に開発プロセスも継続的に改善していくためには、開発の記録も残す必要がありますが、そこの意識があまりできていませんでした。

これからはチケットを記録として活用できるように、適切に記載する仕組みづくりを検討しています。

ドキュメントがあったりなかったりよく分からない

そもそもいつ書けばいいの

ドキュメント作成のルールが曖昧だったため、個人の感覚で作成したり作成しなかったりしていました。ドライブのこのディレクトリを見ればなんとかなる！とも言い切れず、決してうまく運用できているとは言えない状態です。
開発体制の変更により、コミュニケーションを増やして細かい方針の修正を繰り返すことを意識した分、ここで実装完了！といったちょうどよい区切りの、ドキュメント書くぞ！のタイミングを感じにくくなってしまったのかもしれません。
一定以上の規模の機能開発ではさすがに記録を残さないと開発者自身も分からなくなってしまうため、開発メモがドキュメントとして残りますが、中規模の機能で微妙〜に困ることが時々あります。

「どうせいつか変わるから書かない」という意見もあるかもしれませんが、書くのが億劫になるということはそもそも課題が大きすぎた可能性もあります。課題をより適切な粒度に分割してシンプルにしていけばドキュメント作成のストレスも軽減できるのかも。

どこ

チケットの節にも書いたように、（あるかもしれない）ドキュメントへ辿り着けないことがあるのも課題です。これに関しても、置き場所であったりチケットにリンクを記載することであったりをしっかりルールとして浸透させていく必要があるかと思います。

全部AI Agentに任せるみたいな話もありますがそれはまた別の話なので省略。

嗚呼〜

嗚呼〜アジャイルを怠惰の言い訳に使うな高校〜

終わりに

これまでの反省を活かし、スピードだけを追うのではなく、堅実に開発プロセスを回せるように改善に取り組んでいきたいと思います。厳しすぎるルールだとメンバーが動きにくくなってしまいますが、自由と統制のバランスはこれからも考えていく必要があるな〜と思いました。