📎 クリップした記事
あえて非IT系の大企業でデュアルトラックアジャイルを採用した理由とその現在地｜Yuta Kaneharaの記事では、非IT系の大企業がなぜデュアルトラックアジャイルを採用したのか、その理由について詳しく説明されています。また、現在の状況や課題についても触れられています。デュアルトラックアジャイルは、開発と保守の2つのトラックを同時に進めるアジャイル開発手法です。この記事は、非IT系企業がアジャイルのメリットを享受し、効果的なプロジェクト管理を実現するためにデュアルトラックアジャイルを採用した事例を紹介しています。
「アジャイル開発」という言葉の弊害として、「開発」という言葉に引っ張られることで開発プロセスのための手法のように誤認し、企画側には関係のないことだと蓋をされることがままあります。
「アジャイル」にしていく対象はそもそもプロダクトでありビジネスですし、「スクラム」についてもこれが持つ理論や価値基準は決して開発だけに閉じるものではありません。
あくまで今回実現したいのは、丸井グループにおけるアジャイルなものづくりの実践であり、このような環境下においても誤認のない明瞭なモデルを示す必要がありました。
Discovery Track: 企画/要件定義 (企画チーム担当)
- Delivery Track: 開発/実装 (開発チーム担当)
のように誤った形で重ね合わせをして、これを認識をしてしまいます。
こうなると、本来両輪となるべきところが無自覚的に上流下流へと分断されていってしまいます。
本当にわかる。あくまでもチームでやる事としてDiscoveryとDeliveryがあったはずが、それ自体がチームになってしまって、ミニウォータフォール化してしまう。
UPDATE: Starting with the publication of INSPIRED V2, I stopped using the term “Dual-track Agile” because the phrase made people focus far too much on process, and not enough on the principles. I wrote why this is the case here. So instead I started using the terms Continuous Discovery and Continuous Delivery.
これは追えてなかったなー。Discovery Trackではなく、Continuous Discoveryとすることで確かに、状態になる。
本質を理解したら問題ないじゃんでもあるけど、やっぱり言葉は大切。言葉からイメージが生まれてしまう。
結果的にはDiscoveryとDeliveryはメインで担当する人は別れちゃうけど、それはだれがそこでの業務を行っているかという話なので、チームでDiscoveryとDeliveryを両輪回すには、チームでDiscoveryとDeliveryを比重調整しながらDiscoveryでの検証サイクルを回して価値があると思うものを見つけていけるか、そしてそれをいかに早くDeliveryできるかとういうそれぞれのサイクルのスループットを高める事と、全体の最適化をし続けることは、向き合い続けるの大事だよね。とてもよかった！！