たとえ納期が厳しくても、スプリント作業に優先度を設定したり、日々のスタンドアップでブロッカを管理したり、レトロスペクティブを実施して作業方法を改善することは可能だ。恣意的に決定された納期を交渉によって緩めさせようという場合には、ステークホルダとの関係性が重要になる。事前に対話を始めておくことで、より望ましい期待値を設定し、スムーズな提供を確約することが、不確実性に直面する状況では特に重要だ。
Ben Dovey氏はAginext.io 2020で、アジャイルと納期の関係性について講演した。
アジャイルはモノリスではない、とDovey氏は言う。チームにとって何が有用なのかを見い出した上で、経験を積むことが必要だ、と氏は提案する。同じテクニックが違う状況でも通用すると仮定してはならない。
優先度の設定は最高のネゴシエータである。何が欲しいのか、と問えば、長々としたリストを返されるだろう。だが、2つの機能のどちらかを選ぶのかを問えば、その判断と、どちらかより重要なのか、という感覚を得ることができる、とDovey氏は言う。
固定的なものは柔軟にすることができる。最大限に厳しい納期であっても、疑義を挟む余地はあるのだ。この方法によって、変更不可能な納期には高い優先度を設定して、作業を集中するための強力なツールとして利用する一方で、変更可能なものについては納期を変更する、という方法が選択できる。
John Lewis(訳注:英国の百貨店)のビジネスアナリストであるBen Dovey氏に、アジャイルと納期を連携させる方法について聞いた。
InfoQ: どのような納期で、何を提供することが必要でしたか？
Ben Dovey: John LewisのLoyaltyチームの一員として1年間作業する中で、新たな課題を与えられました。7ヶ月後の2018年9月までに、Waitrose(訳注:英国のスーパーマーケット)とJohn Lewisのロイヤルティスキームを組合わせてひとつのスキームにする、というものです。納期の理由は分かりませんでしたが、後になって、より広範なブランド変更に関わる活動が9月に予定されていて、その関係であったことを知りました。
最初のタスクは比較的小規模で、両スキームにまたがったユーザ向け新カード発行のフィジビリティ評価を行う、というものでした。この命題は経営陣から直接与えられたものだったので、それを実行して質問に回答する、というのが一番単純(かつ簡単！)な方法でした。ですが私たちは、質問の背後にある"理由(why)"について、もう少し掘り下げることにしました。そこで得た結果から、この課題を行う本当の理由が分かってくると、元々のスコープや当初の納期そのものに疑問が生じてきたのです。
結果として、作業のスコープをフルスケールからトライアルにシフトした上で、そのトライアルも9月にひとりのユーザ(つまり私！)を対象に着手し、そこから徐々に立ち上げて、10月まで続けることにしました。最初の要求とはまったく違う成果になりましたが、費用を大幅に節約できたと同時に、理解や知識をより深いものにすることができたのです。
InfoQ: 納期を守る上で、どのようにアジャイルを利用したのでしょうか？
Dovey: 私たちは既存の常任チームで、長年にわたってアジャイルな作業方法を構築してきました。ですから、初めて説明を受けた時、私たちからの最初の質問は"なぜ？"、"その価値は？"というものでした。
納期が厳しくても、毎日の作業はそれほど大きく変わりません。2週間のスプリントで作業を優先付けし、ブロッカを管理するためのデイリースタンドアップを実施して、作業方法の継続的改善のためにレトロを開催しています。事前の計画やスコープ設定が少し増えましたが、これが開発者やテスタの日々の作業リズムを乱すことのないようにしています。長期的な計画では、他の何よりもステークホルダ管理に集中するようにしました。作業者に必要以上に負担を掛けず、求められる作業に集中できるようにしたかったのです。
全体として、作業と価値の提供を続ける上で重要なのは、チーム内においてはそれまでの作業方法を守り、協力的な強いチームの構築に集中すると同時に、外部からの圧力からチームを保護し、管理することです。
InfoQ: 交渉の手段として、優先度をどのように使うのでしょうか？
Dovey: 納期が提示された時点で、すべてを提供できないことが最初から分かっている、という状況は珍しいものではありません。それでもステークホルダーたちは、何とかしてすべてを完了させるように要求し、期待することが多いのです。この問題へのアプローチは難しいのですが、現実的な目標を設定する上では重要です。
Loyaltyでは、機能数を評価した上でステークホルダグループに提示し、次のように話しました — "皆さんの要求するものがこれで、私たちが提供可能だと考えているものがこれです。"これによって、私たちが提供しようと考えているものは何か、その後で必要になるものは何か、ということに対する最初の視点が定まりました。このリストが柔軟なものであることも確認しました。リストに何かを追加することは可能です。ただしそれは、他のものを落とすことが条件であって、追加する余地はありません。さらに、提供対象を増やすことは可能だが、何かを提供できないというリスクが大幅に増えることになる、という点も説明しました。4機能を100パーセント実現する方が、7機能を60パーセントの確率で実現するよりも望ましい、少なくとも最初の選択対象は実現して価値を加えることができるのだから、というのが私たちの意見でした。
このプロセスには時間を要しましたが、例示とイテレーションによって共通理解に達することができました。結果的には、当初目標としていた以上の機能を提供できたのですが、それが達成できたのは、優先リストから次の項目を取り上げるまで、目標としていた範囲内に集中することができたからなのです。この交渉をしなければ、提供期限の前月になって、何も準備できていないことをステークホルダに報告しなければならなくなる危険がありました。事前に対話をしたことが、よりよい期待の設定と、よりスムーズなデリバリにつながったのです。
InfoQ: ステークホルダとはどのようにコラボレーションしたのですか？
Dovey: 恣意的な納期を緩めさせようという場合には、ステークホルダとの関係が重要になります。固定的な納期の裏にあるのは、詳細や状況、信頼の欠如です。何らかの成果が得られること、さらにはそれが価値のある成果であることをステークホルダに信用してもらうには、理解と信頼を築き上げるしか方法はありません。それができてしまえば、成果提供のタイムラインをずっと柔軟なものにすることも可能になります。
Loyaltyでは、週次で行うデモを通じて、広いステークホルダと定期的かつオープンな対話を確実に行うようにしていました。課題を通じて議論し、週の開発成果を開示することで、進捗に関する真実の源(a source of truth)としての役割を果たしたのです。これにより、ステークホルダに交錯する情報が届くことによる噂や廊下での陰口によって、デリバリが低下するような状況を回避することができました。デモは信頼の構築だけでなく、噂も払拭しました — いつでも質問を受けて、オープンな会話を行うことができたからです。もうひとつの重要なファクタは、これまでの話にも含まれていた、フランクな会話です。私たちは開始当初から、何がよくて何がよくないか、何が達成可能で何がそうでないか、といったことについて話し合っていました。
InfoQ: どのようなことを学びましたか？
Dovey: これらすべてから、大切なことを知りました。
そのひとつは、タフな納期に出くわした時、すべてを実行することができなくても悪くはない、ということです。デリバリの現実についてのタフな会話から逃げる必要はありません。それが事前に分かっていれば、苦痛を完全に回避して、本当に価値のあるものを提供する大きなチャンスがあります。その対極にあるのが、遅れ続ける大規模プログラム開発なのです。そうならないためには、事前に優先順位を設定して、デリバリ可能な小さなチャンクを提供しながら、バックログを粛々と消化していけばよいのです。終わってみれば、当初認識していた以上の成果を上げられることが少なくありません。
ふたつめは、おそらく重要なこととして、納期に常にチャレンジすることです。たいていの納期は誰かがどこかで作ったものです。そうであれば、変更や修正の余地があります。納期の背景となっている理由が理解できれば、それ以降の価値についても理解できますし、その価値に到達するためのよりよい方法やタイムフレームも分かるはずです。私が重要と思うのは、必要な結果を理解し、そのための最適な方法を理解することです。そうすれば、無理のない納期が自ずと明らかになります。ステークホルダを近くに置くことができれば、あらゆる関係者にとって、これはより簡単で、よりよい方法になるでしょう。