InfoQの記事において、Dave West氏がソフトウェア開発を理論構築とみなす場合、バックログはとても重要であり、実際のところ欠くことのできないものだと述べた。この記事は、全体に渡って何人もの読者が意見を述べていた。後に、議論はleanagile Yahoo! Groupで再び取り上げられた。興味深く、また、争いにもなっているのは、このテーマをもっと明らかにすることで得るものがあることをこの記事が示しているからだ。
そこでInfoQは、この件をさらに調査するために、Mary Poppendieck氏、Ron Jeffries氏、Jeff Patton氏、David West氏、Steve Freeman氏、Jason Yip氏といったこの業界の指導者たちに連絡を取った。そして、以下の点を尋ねた。
- あなたの意見では、バックログの目的は何ですか?
- バックログをどのように定義しますか?
- いつ、どこで、バックログは無駄だとみなされるべきですか?
- いつ、どこで、バックログは欠かすことのできないものだとみなされるべきですか?
- まだ尋ねていない質問はありますか? もしあるならば、その質問と答えを教えて下さい。
以下に回答を示します。(注: Mary Poppendieck氏の回答は「Redefining the Backlog」(バックログを再定義する)というこの記事の一番下にあるエッセイに書かれている)
1) あなたの意見では、バックログの目的は何ですか?
Steve Freeman氏:
チームが今どこにいて、これからどこに行くのかという感覚をチームに与えるものです。バックログは、その価値の分だけ真剣に受け止めるべきです。
Ron Jeffries氏:
おそらく多くの目的があります。私が示したいのは、異なる価値がある以下の2つです。
1. いつかやろうと思うことを追跡するため。
2. 他の人たちに要求の状態を伝えるため。Jeff Patton氏:
私にとって、バックログは2つの目的を持ちます。1番目は、構築している製品の「形」について、その製品が何であり、どうなるのか、そして、誰のためのものかといったことを理解する役に立ちます。「大きなストーリー」として高いレベルでその形を理解します。これは、Alistair氏がNauer氏による「理論構築」を引用したことをDave氏が述べたことと共鳴します。これこそが、私たちがしなければならないことです。私は、理論を伝えるための「ストーリーマップ」として、バックログの考えを利用します。http://www.agileproductdesign.com/blog/the_new_backlog.html
しかし、やがてある時期に、構築するものを決める必要があります。理想的には、ちょうどそのときに、ストーリーはスケジュールされた作業のバックログになります。しかし、バックログになるのは、私が具体的に選んだ作業のためだけです。
ストーリーとバックログは、少なくとも2つのものです。理論の一部を伝えようとするバックログの役割を果たすとき、バックログという名前は、「目的を示すこと」ではありません。この悪い名前のせいで、そして、理論を伝えるためにバックログを使う技術と理解が必要なせいで、私は大抵の人が目的を示しているとは思いません。David West氏:
バックログの目的は、ユーザストーリーの目的によります。ユーザストーリーは、ユーザ(顧客)に権限を与える仕組みとして考えられました。それは、会話形式の専門語で記述され、ユーザがシステムから手に入れたいと思うものを取り込み、期待される振る舞いや責任を正式に表現するものでした。ストーリーは、また、作業を分割して集中する方法です。このため、ストーリーに必要なのは、見積ったり、1つのイテレーションで完了できたり、大掛かりな場合はリファクタリングしたりすることです。
ストーリーカードは、作成したストーリーの期待通りにソフトウェアが動くようになるまで、ユーザと開発者の間で、最初から続けられてきた会話を思い起こさせます。会話の流れから、ホワイトボードのモデルやテスト、動くコードなど、一時的ですが変わることなくストーリーを思い出させるものを示します。
ストーリーカードを含めてこれらの成果物は、ユーザが何をほしいのか、ユーザが自分のほしいものをどのように理解するのか、開発者がユーザのほしいものをどのように解釈したのかといったことを具体的に思い出す以上の目的を持ちません。これらのものは、ユーザと開発者の間の漠然とした理解やコミュニケーションを具体的に呼び起こす(思い出させる)証拠となります。
ユーザストーリーを集めたものは、この場合、ユーザの間でほとんど会話上の具体的な証拠でしかありません。ストーリーは、優先順位(取引条件の中でこのストーリーはどのくらい重要か)、コミュニティ(この機能がほしいのは私だけか)、プロットと特徴の進化(あなたのオブジェクトXと私のオブジェクトYは異なる視点から見ているが、全く同じものだ)、選択肢、変化などに関するものです。この会話上のものは、個々のストーリーが完成してから得たフィードバックによって修正され、ソフトウェアプロジェクト期間中ずっと続きます。
上記により、次のように結論付けます。ユーザが何をほしいのか、そして、そのほしいものがユーザや組織にどのように役立つと思うのかに関して、進行中の会話を具体的に思い起こさせるものとしてストーリーの集まりがあります。ストーリーカードの集まりを「バックログ」と名付けたいのならば、自分の責任でそうすればよいでしょう。それは、意味論上の間違いを犯し、その集まりを意図していないものに陥れることになります。しかし、もしその名前を主張するならば、バックログを使う目的は、ソフトウェアシステムに関して、現在進行中の複数の人々が参加するマルチスレッドの会話と会話全体を具体的に呼び起こすことです。
Jason Yip氏:
スプリントバックログのことを言っているのならば、バックログは現在のスプリントでどの作業を目標にしているのかを明らかにします。製品バックログのことを言っているならば、バックログは製品で可能になる機能を示します。この場合、バックログは製品全体のビジョンを伝えるのにも役立ちますが、通常の平面的なバックログはあまり効果的ではありません。状況を考慮してバックログの項目を並べるには、ストーリーマップ、パーキングロット、プロセスマップなどのツールを使ったほうがよいでしょう。
2) バックログをどのように定義しますか?
Steve Freeman氏:
1) チームが顧客との関係を理解するのに役立つ考具
2) 何を提供する必要があるのか、現段階でもっとも近い推測を表す大まかな機能削減リストRon Jeffries氏:
バックログは「バックログオーナー」の現在の優先順位を示す、機能を計画した項目の一覧。
Jeff Patton氏:
もう一度言いますが、私は「バックログ」という名前が嫌いです。
繰り返しますが、バックログは2つのものです。
整理されたストーリーのリストは、製品の理論について理解したことの詳細を高いレベルで表すものです。
コミットしていないストーリーを除いて優先順位をつけたストーリーのリストは、予定を決めた作業のバックログです。
つまり、バックログを整理することとバックログの優先順位をつけることの間にある違いを理解しなければなりません。David West氏:
「製品バックログ」はストーリーの集まりであり、ユーザがソフトウェアシステムに何を望んでいるかについて、将来変わる可能性はあるけれども、現時点でもっとも私たちが理解していることを示します。「イテレーションバックログ」は、私たち開発チームがイテレーションによって定義された時間間隔で完了する予定の一連の会話です。イテレーションバックログは、一種の作業の棚卸表であるTO DOリストの役割を果たします。各ストーリーの会話は、私たちがしなければならない付加的なことを思い出させて、会話を進めたり、会話を予定通りに進めるために必要なフィードバックを得られるようにしたりします。イテレーションバックログによって、イテレーションの管理を支援して追跡するというさらなる負荷がかかり、元からある責任がなくなることはありません。その責任は、絶えず変化する進行中の会話の具体的な指標となるものです。
バックログは要求のまとまりではありません。
バックログは、完了していない作業の棚卸表ではありません。
Jason Yip氏:
取り組む可能性のある項目の待ち行列。バックログの優先順位を付ける場合、タスクとプロセスの流れと製品のビジョン全体の中に置く場合、項目の詳細をバックログの最初の方にくるまで先送りする場合、バックログはより効果的です。
3) いつ、どこで、バックログは無駄だとみなされるべきですか?
Steve Freeman氏:
もう一度繰り返すと、バックログが価値を提供するよりも維持するためにより努力が必要になるときです。
例えば、メンテナンス/サポート環境では、数多くの可能性のある要求を蓄えるよりも、素早く決定を変えるほうが効果的かもしれません。または、劇的に要求が変化する環境でも同様です。Ron Jeffries氏:
私は、バックログが実はそれほど無駄ではないと思います。バックログは、ただの項目の一覧表です。バックログは優先順に並んでいるので、前の方の項目以外を頻繁に見る必要はありません。
そうは言っても、短いバックログと比べて長いバックログを眺めるのは時間がかかります。だから、優先順位が高くない項目をすべて消してしまうのもうなずけます。私は、バックログの一種の動力曲線を期待します。つまり、80%の「自然に起こった」項目は、おそらくあまり重要ではなく、それほど痛みを感じずに消すことができるでしょう。
バックログはあまり価値を提供しないので、価値を提供せずに活動を消費するリソースである一種の「ムダ」で構成されています。これは特に公開されたバックログが誤解されるときに起こります。ステークホルダーは、現在待ち状態でずっと待つことになりそうなときに、彼らの考えが進行中であると錯覚を与えられます。
なぜ、ステークホルダーがずっと待つことになりそうだと言うのでしょうか? なぜなら、完了するために選んでいないバックログの項目は、選んだものよりも価値が低いからです。そうは言っても、おそらく新たに現れた考えは待っている項目よりももっと価値があります。新たな考えは待っている項目の前に入れられます。そして、このようなことがいつまでも続くでしょう。
要するに、バックログの前方のかなり近いところに線があって、その線の後ろにある考えは決して実現されないでしょう。このような場合、より良いのは、ただ人々に運が悪いと話して、その項目を完全に消すことです。そうすることによって、その考えの最初のオーナーは、何か他の方法でその項目を準備することなどをより良い状態で決定できます。
Jeff Patton氏:
ずっと先の作業の予定を立てて詳細を決めたけれども、その作業が本当に必要かどうか理解していないとき。
David West氏:
製品やイテレーションのバックログが無駄になる2つの状況があります。
１つは、バックログが「遺跡」のようになるとき。つまり、ストーリーはかつて行われた会話の指標でしかありません。ストーリーの集まりは、プロジェクトを始めた日に私たちがシステムをどのように理解していたかを示しているにすぎません。各ストーリーは「石版」になります。石版は、変更できない単に構文上のものです。文脈なく言われたことなので、語義に関する意味はありません。ストーリーの集まりは、そのときにはるかにさかのぼって、自分たちの無知の度合いを確認する歴史的な文書でしかありません。
もう1つは、ストーリーの集まりであるバックログが「管理」や「製品の追跡」の目的のために使われるときです。アジリティは本当に、使い古された言い方をすれば、新しいパラダイムです。アジャイルは異なった文化です。私たちは、習慣の力、怠惰、形式主義文化のプレッシャーの中で生きています。これらは、絶えずアジャイルやアジャイルプラクティスを古い確立されたパラダイムや構造化/工学/合理的/科学的な開発とテイラー主義の管理の中へ押し込もうと戦っています。
Jason Yip氏:
バックログは常に無駄です。
4) いつ、どこで、バックログは不可欠なものだとみなされるのか?
Steve Freeman氏:
やることがどのくらい残っているかというある感覚を持つ必要がある場合です。例えば、 マーケティングや部品一式のインストールなど設計から製品の完成までより長い時間が必要な人たちを調整しなければならない場合です。
スクラムが製品とスプリントのバックログを持つように、異なるレベルのバックログを区別する価値はあると思います。製造関係の人たちは扱う状況をより大きく把握しているので、次の項目を5つだけ見るように期待するのは合理的ではない可能性があります。しかし、開発チームが取り組むべきことは、5つの項目がすべてなのかもしれません。実際にモーターの製造を比較したい場合、それはトヨタ生産開発システムと製造システムの違いのようなものです。前者は、時間に間に合うように設計する必要があるため、多くの無駄があります。Ron Jeffries氏:
不可欠なもの? おそらく世界の中で、不可欠なものはほんの少ししかありません。
バックログは、実際に何をすべきかを伝えるという価値があります。バックログの真実がなくなっていくと、その価値もなくなります。これは、短いほうが良いことを示しています。
バックログがバックログとしての価値を持つということは、次にやることを考慮し、いくつかのバックログを選び、それらを実現するために定義をさらに洗練することです。
バックログは、物事を忘れないようにするリストとして、一部の人たちには価値があります。多くの人たちは、バックログのリストに絶対になければならないこと以外にも、多くのことを書き出します。そうすることで、快適さを生み出しているようです。
Jeff Patton氏:
理解することは不可欠です。理解するためのツールとしてバックログを使う場合、バックログは常に不可欠なものになります。そのようにバックログを使う方法を知らない場合は、バックログは不可欠なものではありません。
David West氏:
本当にアジャイル開発をすると約束した場合に、ドメインを深く理解していることをソフトウェアに反映したいとき、そして、ソフトウェアが現実世界で実際の作業をする現実の人々を支援し、向上させるようにしたいときです。
Jason Yip氏:
より大きな製品の目的を考慮して適切かどうかということを含め、次に取り組むものを知る必要があります。それは、製品全体がどのように見えるかという広い視野を持つのに役立ちます。これらの必要性を満たすためにスクラム形式のバックログを選ばない場合は、他の何かを持つ必要があります。
5) まだ尋ねていない質問はありますか? もしあるならば、その質問と答えを教えて下さい。
Ron Jeffries氏:バックログを表す良い方法と悪い方法は何ですか?
コンピュータに保存する形式でバックログを保持したいと思うかもしれませんが、それは危険です。コンピュータは大量の情報を保持できます。その結果、ほとんど必然的に、あまりにも詳細まで書かれた数多くの項目が残ります。これらの項目を無視するならば、それらは無駄になります。注意を払うならば、ほとんどは時間の無駄になります。
バックログをインデックスカードに保存することは、いくつかの素晴らしい利点があります。
数多くのインデックスカードをあちこち運ぶことはできません。だから、バックログの大きさは自然に制限されます。
個人もグループも、インデックスカードをテーブルに並べて、あちこち動かすだけで、カードの束をてきぱきと優先順位付けできます。プロセスは簡単で、効率的であり、非常に参加しやすいものです。
インデックスカードにはそれほどたくさん書けないので、必要のない詳細を増やすことはありません。
カードを破いて、新しいものに変えるのは簡単です。これによって、非常に簡単に更新できます。
もっと続けられます。これらのことをコンピュータに保存すればよいことは誰でも知っています。それでも、人が考えるよりも多くの場合、ほとんど全ての面において簡単なアプローチはより良いことです。
Jeff Patton氏:
製品の「理論」を理解するためにどのようにバックログを使いますか? 製品の理論を理解するのに役立つことが他にありますか?
(Jeff氏からの回答はありません。)
David West氏:
なぜ、誰もがそんなに間違うのでしょうか?(これは、もちろん私は正しいということを前提とします。) また、言い換えれば、「なぜ、ストーリー、バックログ、アジャイルなどに対する私たちみんなの理解が一致しないのでしょうか?」
簡単に答えると、私たちはコンピュータ科学とソフトウェア工学の学部で教育を受けた専門技術者であり、「正式なもの」を除いて何も尊重しません。正式でないものや「超自然的なもの」をほとんどあるいは全く尊重しない文化のなかで働いています。まとめて言うと、私たちは、「概念構造」の重大な性質と数学、科学、方法論、モデルなどの不適切さに関する観察についてBrooks氏の主張を無視してきました。まとめて言うと、私たちは、理論構築、理論の神聖さ、方法論と文書化の不適切さに関するNaur氏の考えを無視しました。まとめて言うと、私たちは抽象データ型に賛成するオブジェクトの考えを捨てました。私たちは、設計の技術を理解せずに起こる問題に対する解決策を記録することに賛成して、Alexander氏のTimeless Way of Building(邦題: 時を超えた建設の道)とQWAN(Quality Without A Name: 無名の質)を捨てました。まとめて言うと、アジャイル文化、哲学、そして、価値を古い方法で考えさせることによって、滅ぼそうとしているのです。
Mary Poppendieck氏は、"Redefining the Backlog:"(バックログを再定義する)と題されたこのエッセイの中で問題を再び述べ、質問に答えました。"
最初に、「バックログ」という言葉は、私が決定できる限りにおいて、スクラムによってソフトウェア開発の世界に導入されたということを述べたいと思います。私は、スクラムの用語、特に「バックログ」のような言葉を使うことを避けようとしています。そのような言葉は、会話の中でさまざまな異なった使われ方をしてきました。もっと正確な用語で会話を再構成する時期だと思います。例えば、伝統的なリーンの概念である待ち行列、知識の創造、集合ベース開発などです。「バックログ」は、これら3つのことすべてを、大体混ぜ合わせて意味するようになりました。
待ち行列は、ソフトウェア組織が頻繁に小さな要求をする環境において、もっとも適切に検討されます。それらの要求は、ある方法で作業を改善するために何かをしたいと思っている人々から出てきます。そして、このような顧客が必要なものを速く提供すればするほど、顧客は求めている価値を速く認識できます。このような場合、大抵、短い期間で完成できるリソースの分だけ、あなたが受け入れる要求の数を制限したほうがよいでしょう。この理由は、待ち行列の理論、特にリトルの法則から来ています。この法則は、要求が満たされるまでの平均時間は、待ち行列の長さに直接比例するというものです。
例えば、比較的小さな要求が顧客から定期的に出される場合、応答時間は待ち行列の長さに比例するでしょう。待ち行列が短い場合、素早く応答し、顧客が必要としたときすぐに顧客の必要性に対応できます。短い時間を提示して繰り返し確実に応答すれば、顧客は応答時間を信頼するようになります。応答時間が信頼できるものであれば、顧客は解決策を求める前にその問題について可能な限り学べます。なぜなら、顧客は、問題が常に変化する状態において、要求を出しても長い待ち行列で待たなくてもいいと知っているからです。待ち行列の長さを制限することで、顧客が要求した時に、はい、問題に対応します、または、いいえ、問題に対応しませんと顧客に対して正直に即答する必要があります。対応できると答えた場合は、顧客もその問題がいつ解決されるかが分かります。対応できないと答えた場合、顧客は、うそいつわりなく扱われたという面目が立つし、その問題を解決するために他の準備ができます。また、顧客たちは、何を実際に要求できるのかという制限をすぐに理解します。
このアプローチによって、顧客たちは、うそいつわりなく扱われ、チームが信用できるものであるという信頼を築きます。チームは、正直なアプローチと信頼できる日付を示して顧客に敬意を表します。チームは、顧客に価値を提供することに強いつながりを感じ、深く約束するようになります。リーンでは、顧客の価値に注目することが、唯一良いことです。知識の創造はリーンの考え方で、もう１つの大きな価値です。従って、何がやってくるのかを知ること、何をすでに検討したかを追跡し続けること、将来のための数多くの選択肢を理解することは、とても良いことです。各顧客の問題は学ぶ機会であり、顧客が将来どこに行こうと考えているかを知るために、顧客とパートナーにならなければなりません。顧客たちと開発チームが良いパートナーの場合、お互いの問題を追跡し続け、実行している試みから知識を引き出し、将来のマーケットと技術の流行に関してお互い注意を与えるために、一緒に時間を過ごすことになります。
知識の創造に良いもう1つの時期は、非常に大きなプロジェクトに取り組み、製品のロードマップのように、プロジェクト期間中に何が必要かという全般的な考えがほしいときにやってきます。これはとても良い考えです。ロードマップを後で変更しなければならないほど小さいストーリーにしてしまうことに時間を費やしすぎない限り、私は大賛成です。実際のところ、練習することで重大な学びを得られるならば、それでもOKです。学ぶことはいつでも良いことです。知識を追跡するのに使われる多くのデバイスがあります。推奨されるリーンツールの１つは、A3の文書です。(A3はアメリカ合衆国以外では、11x17インチの用紙サイズです)A3文書の片側の面に特定のトピックについて、関連する知識をすべて書き出すのです。インデックスカードはA6サイズの文書で、ソフトウェア開発において、人々は、ある特定の顧客の価値に関する知識をとらえるのにこのサイズがとても役に立つことを見つけました。A3かA6が適切なサイズかどうかは、実は関係ありません。問題なのは、言葉に表さない知識を明らかにして、役に立つ方法でそれをとらえなければならないことです。そうすれば、再度学びなおす必要はなく、より情報に基づいて決定できます。これらは、とても重要なリーンの価値です。
集合ベース開発は、選択肢に基づいた開発へのアプローチです。これは、決定を覆すことがとても高くつくような特にやりにくい状況で知識を作り出すのに使われます。つまり、いくつかの選択肢を完全に開発し、創造した知識からどのアプローチがもっとも良いかを決めます。あることがどのように上手くいくか、2つか3つの理論を作成し、その理論に対して結果を比較するために試しに実行します。その結果によって理論の誤りが判明した場合、理論を改善する必要があります。理論を支援する結果が得られた場合は、その理論が強化されます。
知識を改善するために試しにやってみるという考えは、またプロセス改善にもとても効果があります。例えば、理想的な待ち行列の長さを理解するもっとも良い方法は、その長さがどのようにデータの重要点に影響するかという理論を作り出し、データの重要点が実際にどのように影響されるかを見るために待ち行列を異なった長さで試してみることです。
ご覧のようにバックログに関してまったく同意にはいたっていません。しかし、私たちが見つけたとても重要な共通のスレッドがいくつかあります。
- 重要なのは、これからどこにいくのかという大きなイメージを理解することです。
- 重要なのは、今どこにいるのかを理解することです。
- (1)と(2)で創造した知識を保存して分散することが重要です。
- リストが長すぎたり、つまらなすぎたりする場合は、リストは無駄であり、努力しただけの価値はなくなります。