こんにちは。「カミナシ 教育」というプロダクトを作っているふじはら（@daipresents） です。毎日アイスを3本以上食べてます。
僕は「カミナシ 教育」のサービスチーム（スクラムチームみたいなチーム）でマネジメントを担当していますが、それ以外ではダブルワークでアジャイルコーチとしていろんな企業の開発支援も行っています。
カミナシでは各チームが自律して動くことを求められ、それぞれが試行錯誤しながらがんばっています。なので、カミナシではあんまりアジャイルコーチの仕事はしていないのですが、自分のチームを俯瞰して見ていると、自然とアジャイルな見積もりと計画づくりをしていないことに気がつきました。
『アジャイルな見積もりと計画づくり』は名著です。だから、僕はチームでの開発にかかわる方に、この本をいつもおすすめします。なのになぜ、このチームはやらないのか？
具体的には
- スプリント計画
- ストーリーポイント
- プランニングポーカー
- ベロシティ
をしていない・使っていません。
この記事では、アジャイルな見積もりと計画づくりでよく使われているプラクティス（手法）をやらない理由、使っていない理由を考察・解説してみたいと思います。
そもそもスプリントがない
僕のいるチームは、スクラムをしていません（参考： 「しかたないスクラム」じゃないアジャイル開発を求めて）。よって、スプリントもイテレーションもありません。これは、開発しているプロダクトが新規事業なので、変化への対応がとてつもなく必要になり、1週間のスプリントですら窮屈に感じたからです。
そのかわりに週次で集まって話したり、月ごとに大きなゴールを決めています。
これらがタイムボックスのように働き、スプリントやイテレーションのように機能しているのかもしれません。
ちょっとだけ補足しておくと、スプリントはないけど、一部スクラムイベントやそれに近い活動はしています。
たとえば、毎朝朝礼をしていますが、現場訪問や顧客フィードバックの共有がメイントピックだったりするので、スクラムの定義するものとはちょっと違う使い方をしているのかもしれません。ふりかえりも月1回集まるときや（僕のチームはリモートがほとんど）、都度気がついたときにやっています。
計画はざっくりとしか立てない
ストーリーポイントやベロシティを使っていないので、ベロシティベースの計画づくりができません。スプリントがないのでスプリント計画もできません。
そのかわりに、最大半年ぐらいのロードマップをざっくり作っています。
ロードマップにより、だいたいのリリース予定が決まります。ただ、できたものからどんどん出しているのでリリース計画にコミットメントは求めていません。
できあがった計画は、必要なときに必要なだけ更新していきます。必要になったらユーザーストーリーを作成し、デザイン検討、リファインメントを行っています。
おそらく、新規事業で先が見えなすぎて、計画を作るのに時間もかけられない。だから、こうなったのではないかと思います。
もちろん、先が見通せるのはとてもいい面もありますが、どうせ変わるかもしれない未来に時間をかけすぎて、開発する時間が奪われていくのは避けたいものです。
見積もりはスコープ調整だけ
つぎに、ストーリーポイントやプランニングポーカーを使った見積もりもしていません。
そのかわりに、プロダクトマネージャ（PM）が期待するスケジュールをもとに、PMとプロダクトデザイナー（PD）とエンジニアでスコープを調整します。
開発の後半でも調整できるように、ユーザーストーリーを工夫しました。やりかたは簡単にシンプルに
- ストーリーを小さく分割する
- ストーリーをうまく分割する
- ストーリーを依存させないことで完成率を上げる（これがないとあれができないをなくす）
- 最低でもこのライン、最高ではこのラインというようにストーリー自体をバッファのように扱い、スコープを調整する（フィーチャバッファとも呼ぶ手法です）。
ストーリーが大きすぎてスコープ調整ができなかったときに、ふりかえりでこれらを提案しました。その結果、翌月のふりかえりで成果がちょっとずつあらわれはじめました。
見積もりの難しいところは、正確性を求めれば時間がかかるし、雑にやると意味をなさなくなる点だと思います。自分もいろんな現場でアジャイル開発の支援を行ってきましたが、見積もりの悩みは本当に多いです。
対策としていろんな手法は世の中にありますが、それだけで解決しない場合も多いです。そこでいつも「なんで解決しないのか？」考えてきましたが、一番大きい壁が 「信頼関係」でした。
たとえば、正確な計画を求められる現場では、精緻な見積もりが求められます。精緻な見積もりを出しても、予想しなかったことがおきて計画はすぐに遅れます。そうするとまた精緻な見積もりをするために時間がかかり、負のサイクルに陥ります。
一方で、今のチームはPMとエンジニアで信頼関係を基盤に計画を立ててます。
みんなベストを尽くしており、それでもうまくいかない場合は、チームで対策を考えて次の改善へと進んでいきます。
精緻な計画は作れませんが、この方法で「だいたいええ感じに」リリースできているので、この状況が続いているのだろうと思います。
チームのアジリティはデータを使って確認する
ロードマップは定期的に見直しているので、エンジニアリングのアジリティを月1回確認しています。
ベロシティを計測していないので、バーンダウンチャートを使ったり、ベロシティトレンドを追いかけたりできません。
そのかわりに、チームのアジリティを確認できるようにデプロイ回数、リードタイムを計測しています。
データはGitHubから引っこ抜いてくるツールをAIで作り（コードは一切書かなくてよかった。AI最高）、BIツールのLooker Studioでグラフ表示しています。
月に1回、チームメンバーと眺めてますが、数値目標は特になく、あくまで「先月と比べてどうなっているか」をチームが定量的に理解するために使っています。
データを見せるだけでなく、データを見てチームメンバーが自分の判断で行動することを期待しています。
まとめ
チームが自然とこうなった理由を考えると、やはり変化の多い環境だからではないでしょうか。
日々状況が変わるので、スプリントやイテレーションですら制約になってしまいます。よって、「必要なときに必要なだけ（Just in time）」や「ひとつずつ仕事をこなしていこう（フロー効率）」や「作業分担せずにひとりで多能工化しよう（セル方式など）」といった方法になっていき、結果的にプロセスとしてのかんばんやリーンの考え方に近づいているように思います。
逆に悪い点を考えると、毎日のように変化できてしまうので、その変化の対応コストは高いです。ルールはまだありませんが、「原則として計画を守れる範囲で対応していこう」という考え方を持つようになってきました。
僕がチームで実現したいことは、「最高速度で開発を行うこと」です。これはアジャイル開発に出会ってからずっと変わらない部分でもあります。
おそらく、アジャイル開発が生まれて10年ぐらいは、「スクラムをやれば」、「XPをやれば」ある程度うまくいくケースも多かったのかもしれません。ただ、現代はビジネスも技術も環境も複雑すぎて、「これをやれば正解」を見つけにくい。
ただ、カミナシのメンバーは「ええ感じ」で改善を続けてくれているので、型にはめこまず、自由にプロセスを改善することによって、「必要なことを、必要な分、必要なところで」アジャイルプラクティスを活用する形になったのではないでしょうか。
＊
「カミナシ 教育」のサービスチームの働き方にご興味があれば、ぜひカジュアル面談お願いします！
