アジャイルと通過点とベクトル

昨日と比べて今日一歩前進してる?

もう10年以上前になるけど、計画とリソース効率を重視していた大きな組織の中で、より良いサービスづくりをしたいと、アジャイルなプラクティスやスクラムを取り入れてやり方を変えたことがある

それは、うえから「アジャイルな開発をするように」とふってきたトップダウンな指示ではなくて、自分がそういうものづくりをしたいなと思ったというボトムアップな始まり(幸運なことに、少し進めていたところでトップダウンでも話が出てきたので、ボトムアップとトップダウンの両方から取り組むことになってとても良かった)

そのボトムアップな改善のときに考えていたのは、その瞬間にやっていることが理想的かどうかというスナップショットじゃなくて、昨日と比べて今日一歩前進してるかというベクトルだったなと思う。まぁ、あんまり深く考えるタイプじゃないので、結果的にそうだったという側面が大きいかもしれない

計画駆動で頑張る

最初は何も変えずに、その当時のやり方に従いながら、結果を出せるようにがんばった。プロデューサーがタスクを個別のエンジニアにアサインして、ガントチャートをひくようなやり方

  • スナップショットで見ると、計画駆動の開発をしているだけ。なので、全然自分のやりたい開発ではない
  • ベクトルで見ると、「この人に任せておけば最終的にはなんとかする」という信頼を周囲から得ることができたので一歩前進

チームの外からだけじゃなくて、チーム内でも信頼を得ることができたので、中心的なエンジニアとして動けるようになった

イテレーションを導入

周囲からの信頼を得たことで、わりと自由に動けるようになったので、イテレーションを導入した。これで、開発フェーズの中ではイテレーティブな開発ができるようになった

  • スナップショット:ウォータースクラムフォールまたはスクラマーフォールと呼ばれるような状況。理想的ではない
  • ベクトル:完全な計画駆動に比べて、開発フェーズでリスクを早めに発見することができたり、変更すべき仕様の発見に対して柔軟になったりした

あんまり覚えてないけど、イテレーションと同時かそれより前に、ふりかえりを導入していた。それもあって、開発プロセスを改善するリズムができた。それによってチーム内のやり方をちょっとずつ改善していくことができた。例えば

タスクを小さく分割

  • スナップショット:デモができるような単位で切ってるわけじゃない
  • ベクトル:大きなタスクを小さく分割することで何をやっているかが見えやすくなった

プランニングポーカーの導入

  • スナップショット:ポーカーをしたところでデッドラインは変わらない
  • ベクトル:お互いの認識のズレが見えるようになったので、早い段階で認識齟齬に気づいたり手を打ったりできるようになった

その後も色々と試したり改善したり。このあたりで、僕個人ではなくチームが周囲から信頼を得ることができてきたのかな。何をやっているのかが外から見えるようになってたり、あぶない兆候を早い段階で伝えられるようになったりしていたので

プロデューサーを巻き込んだ取り組み

チームが安定してきたので、プロデューサーを巻き込むことができた。プロデューサーは今で言うと、プロダクトマネージャーとプロジェクトマネージャーを合わせたような役割かな。プロデューサーを巻き込むことで、工数に影響がでる部分にも手を出せるようになった

  • 自動テストの導入(開発フェーズでやることが増える)
  • ペアプロの導入(2倍の工数がかかるように見える)

などを少しずつ取り入れて、結果を見ながら調整していった。色んな難しい局面もあったけど「この人・チームに任せておけば最終的にはなんとかする」というところは守るようにしていた

  • スナップショット:開発チームに閉じている
  • ベクトル:工数影響がでる部分の改善にも取り組むことができた

ビジネスチームを巻き込む

プロデューサーも巻き込んで開発チームとして動けるようになったので、ビジネスチームも巻き込むことができるようになった。リーンキャンバスやユーザーストーリーマッピングなどで、なぜつくるのか、今何を最優先にするべきか、などビジネスチームからの意見をより深く聞くことができるようになり、重要な部分に集中できるようになった

このあたりで、開発チームとして、本当に向き合いたかった課題に向き合えるようになってきたように思う

他の組織を巻き込む

組織の中で信頼を得ることで、他の組織を巻き込んだ改善を考えることができるようになった

  • デザイナー組織を巻き込んで、デザイナーさんがもっと意見を言ったり、結果を見てすぐに次の手を打ったりできるようにしたり
  • QA組織を巻き込むことで、シフトレフトな取り組みを始めたり、テストの観点をエンジニアたちに教えてもらって開発の段階で品質を上げていったり

そんな感じで

スナップショットではなくて、ベクトルを大切にして、一歩ずつ前進していった感じ

今から取り組む人たちに、このやり方をおすすめするわけではない。今だと、アジャイルな開発は以前よりも普通のことになってると思うから、トップダウンとボトムアップの両方で全体として取り組むのが良いなぁって思う。コーチを呼んだり、研修に参加したりして

ずっと通過点

スクラムはカスタマイズしない方が良い、というのはそうだなって思うのだけど

  • カスタマイズしたスナップショットをもって「ここが最終地点だ」って言うのが僕は好きじゃなくて
  • ベクトルを意識して「ここは通過点だ」って言ってるんだったらいいんじゃないかな

と思っているのでぼーっと書いてみた。やりたいことに向かって今日も前進できてるかな?って考えて、前進してるなら、それはとても良いなって思う