プロマネとして本格的にアジャイルを取り入れた時のふりかえり

以前経験したプロジェクトマネジメントを通して学んだことがいろいろあるのでふりかえっておくとよい財産になるなぁと思いここにまとめる。プロジェクトはメンバー6人で9ヵ月ほど。既存サービスの作り替え。プロダクトオーナーが大まかな方向性を決めて僕は1から10を作ることを任された。それまでなんちゃってアジャイルだったので本格的にアジャイルを取り入れるのが目標。以下ふりかえり。

■Keep:良かったこと

『スプリント導入』

1週間のスプリントを導入。プロダクトオーナーの気が変わるサイクルに合わせると1週間がちょうど良かった。週初めにスプリントミーティングを行いメンバーと今週のやるべきことについて意識を合わせる。同時に週初めに次のスプリントの計画ミーティングを行う。なので計画立てから実装完了までは2週間。顧客チームと開発チームとで1週間ずれてサイクルが回る。リリースは月に1回。リリースを行う週はテスト/改善用に確保。

『スタンドアップミーティング』

スプリントミーティングだけだと日々発生するちょっとした情報共有がうまくいかないので途中から毎朝スタンドアップミーティングを採用。汎用的なクラスやメソッドの共有、個々が抱えている問題の相談、本日のタスクの整理など。

『優先順位の定義』

最初ウォーターフォールを中途半端に取り入れたため要件が膨らみ過ぎて進捗が遅れがちになる。それを解決するために優先順位を意識するようになる。ミニマム/マスト/ベターで優先順位付けすることをチームの文化とした。ミニマムでサクッと作って顧客チームと調整しながらスプリント内にマストなものを実装。余裕があればベターも取り入れる、余裕がなければベターはやらない。早い段階で最低限のものが出来ているので進捗に遅れが発生することが減る。

『マネジメント業務を顧客チームリーダーにいくつか委譲』

マネジメントをしながらプログラミングもしていたので僕の負荷が上がってきた。もう無理と思たのですべてを自分で管理するのをやめ管理業務を冗長化するようにした。要件の調整などは顧客チームリーダーに委ねた。もちろん丸投げではなく概要レベルでは把握しておくが詳細は完全に委ねた。負荷分散だけでなく脱属人化にもなった。

『タスクの詳細をメンバー自身に管理させた』

上記のとおり僕の負荷が上がってきて個々のメンバーの面倒も見れなくなってきた。そこでメンバー個々のタスク管理はメンバー自身で行うようにした。スプリント内にやるべきことができていればそれでいいわけで。悪く言えば丸投げなのだがそれがかえって個々の主体性を産んだ。実装者と顧客チームとのコミュニケーションが密になった。

『開発チームと顧客チームのコミュニケーション』

顧客チームとは顧客の立場で考え行動する要件定義者やテスターのこと。タスクをメンバーに丸投げするようになってから開発チームと顧客チームのコミュニケーションが密になり放っておいても回るようになった。これによってマネージャーとしての僕は細かいことを気にせず全体の流れを見ながら注力すべきことに注力できるようになった。

■Problem:悪かったこと

『最大の問題は要件の肥大化』

最初は既存サービスのメジャーバージョンアップということもあり「今までやりたくてもできなかったことを実現しよう」という気持ちが強かった。ゆえに要件が肥大化。ちょっとしたアイデアも要件定義しておくと後々役立つと考えやってみたいことを全部詰め込んだ。今思えばいくつかのアイデアはパーキングロッドしておくべきだった。

『要件が詳細すぎた』

慣れない内からすべてアジャイルにすると良くないと考え中途半端にウォーターフォールを取り入れ最初は要件定義をしっかり作っていた。詳細な動作や UI まで要件として定義した。ところが、詳細な動作や UI は繰り返し改善していくことでどんどん変わっていく。そういう不確実なものに時間をかけるのはもったいないし早い段階で詳細や設計を詰めてしまうとそれらに囚われてしまい柔軟性を失う。

『ワードやエクセルのドキュメントは不要』

最初はワードで要件定義書を作ってチケットでタスク管理するという方針だったが要件定義書の更新が滞ってしまいズレが生じてきた。なのでワードの要件定義書を捨てチケットですべてを管理するよう方向転換。チケットの運用ルールをしっかりしておけばチケットで“今”の仕様の確認やこれまでの経緯の確認などできる。チケット管理ツールはドキュメントとしても使える。

『優先順位が曖昧だった』

要件も肥大化し具体的なゴールを設定しなかったため、いつまでにどこまでやるのか?どこまでやればローンチできるのか?が曖昧に。つまりローンチ基準とスコープ管理が出来ていなかった。そのため後回しでいいものに時間を取られたりやらなくていいことをやってしまったなど多くの無駄が生じた。ローンチ基準を設定しておくとスコープが管理でき無駄を省いてスケジュール通りに進めれたはず。ローンチ基準とスコープ管理を取り入れた後半はうまく進捗したが、肥大化した要件に優先順位を定義してスコープを設定していく作業のコストは大きかった。

■Try:次に試したいこと

『小さく始めることを徹底』

実装もそうだが要件定義から小さく始めるべき。優先順位を意識して優先すべきものから作る。「あった方がいい」は必要ない。「あるべき」ことのみ必要である。

『ユーザーストーリー導入とチケット駆動』

要件定義書のようなものからじゃなくユーザーストーリーくらい曖昧な要件から開発開始したい。細かい仕様よりもユーザーが何をしたいのかが重要。ユーザーストーリーをチケットとして登録し実装を進めながらチケットに仕様を記載していく。チケットの説明欄に現時点での仕様をまとめておくとそれが仕様書となる。チケット管理をタスクの管理ではなくユーザーストーリーの管理として使い仕様を管理したい。

『システム内部仕様の情報共有』

エンジニア間での細かい情報共有が出来る Wiki 的なものを用意したい。というのも、エンジニア間での情報共有は各ミーティングで行っていたが、後から参画してきたエンジニアと共有できない。内部仕様を非同期で共有できるような仕組みが必要(GitHub の Wiki が良い)。

■感想

削ることの難しさを痛感。膨らんだものから取捨選択するより最初から小さくしておいた方が楽。常に必要最低限を考えることでコストはかなり抑えられる。Just In Time とか YAGNI とか。

アジャイルをメンバーに浸透させるのに結構手間取った。与えられた要件で実装するのではなく顧客チームと一緒に自分で考えながら実装することに最初は戸惑っていた。慣れたらなんてことはないんだけど。あと、アジャイルはメンバーにある程度の力量が求められる。「全員がシステムエンジニアでなければならない」「全員が判断できなければならない」「全員が主体的でなければならない」ひとりでもこれらからブレるとそこが足を引っ張る。故に増員が難しい。

特にとりあげることでもないけど、マニュアルの自動生成システム構築に失敗。要件定義書から自動でマニュアルを生成できればいいなと思っていたけど要件定義書が肥大化によって破綻。今はチケットに現在の仕様を記載する箇所を設けておけばそれで十分だと思ってる。

かわのくんとは

Web系IT企業でプログラミングやマネジメントをしています。趣味で音楽を少々。

Youtubeでライブ動画配信中

Ustreamでライブ動画配信中

スマートフォン向けにPCサイトを自動変換(コンバート)する『CONV2SP』 CSS作成支援ツール『CSSツクール』