*本ブログは ATLASSIAN blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2009 年 7 月 9 日、Per Fragemann 投稿 "Dogfooding and Frequent Internal Releases"



リリースサイクルが短いのは素晴らしい

2, 3 か月ごとに、ソフトウェアの新しいフィーチャーバージョンを出荷すること - 2, 3 年ごとにではなくて - は素晴らしいことです。

• 短いリリースサイクルは、フィーチャーがゆっくりになることを避けるのに役立ちます。なぜなら、いつも締切が迫ってくるからです。そして、この締切はデベロッパーとステークホルダーに緊急性の感覚を保たせるのに役立ちます。

• 短いリリースサイクルは、"絶対にこのリリースに入れなければいけない" といった狂ったように急ぐことを避けるのに役立ちます。その次のリリースはそれほど遠くでは決してなく、クリティカルではないフィーチャーが遅れることについて、ステークホルダーを説得する良い材料となります。

• 短いリリースサイクルは、定期的にバグを修正するようあなたを強制します - どのデベロッパーも明らかに、格好良く新しいフィーチャーへの取り組みにすべての時間を費やしたいのです。バグを修正する代わりに。しかし、あなたがもし頻繁に出荷するのならば、バグの修正を永遠に先延ばしすることはできません。それらは動作しなければいけないからです;

• そのリリース日が、一歩引いて全体像 (そして競争力) を見るのに最良の日なので、短いリリースサイクルは、あなたの戦略をとても早く現実に適応させます。

• 最後ではあるけれど重要なこと。頻繁に進捗を確認することは、チームの士気向上にとって素晴らしいことです。

       

しかし、その 2, 3 か月の間にたくさんの間違いを起こすこともある

残念なことに、たった 3 か月という短いリリースサイクルにおいても、新たな問題が発生するだけの十分な時間があります。典型的なチームは、おそらく、全く使えない 3 つの新しいフィーチャーを設計し、5 つの予期せぬパフォーマンスのボトルネックを導入してしまうでしょう。そのサイクルの途中で、通常のバグに加えて。つまり、3 か月は、またとても長い時間でありえます。そして、通常はリリース日の周辺になってこれらの問題に気づくでしょう!あなたは本当にこれほど長く待ちたいのですか?

たしかに、いくつかのアジャイルのリスク緩和の戦略があります: 継続的インテグレーションサーバーは、多くのバグを発見し、デベロッパーがそれらを修正する手助けとなり、自動化されたテストはあなたが多くの微妙な問題を本当に早期に発見することを助け、そして、QA チームは、終わりなく働き、ユーザビリティーを解決するでしょう。しかし、考えてみましょう: 最高の QA チームとユーザビリティーのエキスパートでさえ、ユーザーの振る舞いをシミュレーションしているだけなのです。本当のテストは、実際のユーザーがあなたのソフトウェアを使用するときなのです。あなたが考慮していなかったような方法で使用されるかもしれません。そしてまた、そのソフトウェアが他のプロダクションソフトウェアと一緒に使用されるときなのです。早ければ早いほど、あなたは良いデータを得ることができます。

アトラシアンにおいてどのように行っているか

ドッグフーディングの実施

ドッグフーディングとは、自分たちの製品を使用することをまさに意味しています。これは、素晴らしい原則です。なぜなら、自分たちのソフトウェアを使用することにより、顧客と同じような痛みを共有することが出来るからです。もしあなたの製品がクズであれば、それをより良いものにする強い動機となるでしょう。もしあなたがそれを毎日使用していれば。ただ見栄えを良くするだけではなく、フィーチャーを良く動作するようにするかもしれません。より多くのフィーチャーを追加する前に、バグを修正するでしょう。あなたが開発しているソフトウェアがなんであれ、あれこれ方法を使ってあなた自身でそれを使うようにしてください。

ウィキペディアによると、その用語は、実際のドッグフードの広告により作られ、後にマイクロソフトが促進したそうです。これが神話だとしても、その用語は、とても覚えやすいものです。あなたが販売しているものを食べましょう!あなたが出荷しているソフトウェアを使いましょう!あなたの指をテーブルノコギリに突っ込んで、シャットダウン機構が動作するところを見せましょう!ええ、良いドッグフーダーになるために、ここまで極端にする必要はありません。ただあなたのソフトウェアを、あなた自身が使う理由のあるシステムに展開すればよいだけです。あなたは創造的になり、会社のルールをいくつか折り曲げる必要があるかもしれません。しかし、掛け金が高いと、できることは少ないのです。あなたはまだ、もう一つの Twitter クローンを開発していますか?それなら、全社員において、会社内からの、Twitter アクセスをすべて閉じましょう。あなたは新しいウィキをコーディングしていますか?Confluence を捨てましょう!あなたはのろいオンラインバンキングのソフトウェアをテストしていますか？実際のお金をステージングインストレーションに移動させてみましょう。従業員が現実的な設定のもとにお金を費やすことを促すために。これらの例では、抵抗が起こるでしょうが、しかしそれと戦うことは、たいてい、努力するに値することです。

ドッグフーディングサーバーへのミニリリース

つまり、あなたの最終製品をあなた自身に展開することは素晴らしいことです。. しかし、単に最終リリースを自分の会社に出荷するだけでは、短期的に見て、製品を良くするとは言えません。もし、最終リリースがクズであれば、そのとき、あなたを怒るのは顧客だけではないでしょう。同僚や上司もです!片手では、ドッグフーディングにより彼らからのフィードバックが欲しい一方で、もう片手では、彼らを混乱させたくはないのです。目の前に機能的ではない最終リリースを置くことによって。解決策はとてもシンプルです: あなたの会社のサーバーに常に出荷していればよいのです。四半期に一度ではありません。2, 3 週間ごとにです!

最初は、そのアイデアはより悪く聞こえるかもしれません。なぜなら、3か月ごとの代わりに、2週間ごとに上司を怒らせてしまうかもしれないからです。しかし、良いニュースは、すぐにその製品を改良するチャンスが得られるということです。ひとたび、上司があなたを罵るのをやめれば。しかし、使えないフィーチャーを修正したり、改良したりすることの優先順位は、下手なドッグフーディングリリースのほとんど直後に、上がるでしょう。追加のフィーチャーは、既存のフィーチャーが十分に良く動作しているときにのみ、取り組まれます。自動的に、次のドッグフーディングの展開は、とてもフラストレーションが少ないものになるでしょう。そして、その次はもっと良くなるでしょう。いつでもまともなドッグフードリリースを出荷するというリズムに落ち着くまで。それはただ起こります！

ミニリリースについて、スタッフからのフィードバック

品質を改良することに加えて、頻繁な内部リリースは、定期的なフィードバックを収集するためにもまた素晴らしいことです。アトラシアン内部では、Confluence サーバーを2週間ごとにアップグレードし、そして、各リリースごとにリリースノートも作成しています。スクリーンショットや説明も含まれています。これらのリリースノートを作成することは、シンプルで、1時間か2時間かかる程度です。しかし社内のスタッフからのフィードバックは見事なものです。リリースノートと実際のミニリリースを見ると、スタッフメンバーは何が変更になり、何にコメントすべきか（もし気になるものがあれば）が分かります。開発チームとプロダクトマネージャーは、いつでも、実際のユーザーから無料のフィードバックを得られます。つまり、そてはとても価値のある投資だということです。定期的にビルドとデプロイを行う開発チームにとって。

こちらに、最近のミニリリース（私たちはマイルストーンと呼んでいます）の抜粋があります。あなたは、私たちのマイルストーンリリースノートをすべてオンラインで見ることができます。なぜなら、それらを私たちの開発コミュニティーにも公開しているからです。


そしてこちらに、社内のいろいろなところから得たフィードバックの抜粋があります。Bill はマーケティング、Joshua はセールス、David は IT、そして Matt は開発です。これらは、私たちが得た26のコメントのうちの6つです。そしてそれは、議論されたマイルストーンリリースのほんの1つです。私たちはこの種のフィードバックをいつも得て、そして廊下での会話や、IMやJIRA上の課題を通じて、もっと多くのフィードバックを得ています！


QAが、バグを発見したり、使えないフィーチャーを早期に発見したりすることに本当に重要である一方で、実際のユーザー（この場合では、顧客の代表者）だけがあなたに全体像を与えてくれます。もし、いつでも内部的なConfluenceのリリースを出荷しなかったら、この種の情報を得るのはとても遅くなってしまい、次のリリースにフィードバックすることができないでしょう。

自分のチームでこれを試してみる

私たちはそのConfluenceチームにおけるドッグフーディングのプロセスにとても満足しています。そして、他の製品チームにも少しずつ広げているところです。しかしながら、興奮しすぎる前に、いくつかのリスクと常識的要件を見てみましょう。

リスク

前述したように、ドッグフーディングはあるリスクを伴ないます。2週間ごとの展開をほぼ2年間行ったにも関わらず、私たちはまだ時々、いくつかの共通の問題にぶつかります:

• 私たちはときどき、2週間のイテレーションの間に、多すぎるコミットをしてしまいます。私たちはときどき、社内のシステムにフィーチャーを出荷してしまいます。まだ役にたたないので、デベロッパーのマシンにもう2週間とどまるべきフィーチャーを。

• 偉大なQAチームを持っている一方で、ときどき、私たちは十分に近くでその話を聞かずに、社内のユーザーに多くのバグを出荷してしまいます;

• ときどき、私たちは社内で出荷したあとにとてもたくさんのバグを発見するので、次のマイルストーンまでにすべてのバグを修正することができず、一部の社内のユーザーをときどき、困らせます。

しかし再び、ドッグフーディングの間に問題を発見します。それは3倍多くのテスターを使ったとしても発見できなかったであろう問題です。ときどき、マーケティングやセールスの社員は、イントラネットのサーバーに新しいバグを持ち込んだことについて、Confluence デベロッパーに少し怒ります。しかし、彼らがつまづかされたバグについて、少なくとも顧客をつまづかせることがないことに、皆が同意します。それはまた、マーケティングやセールスの社員にとっても素晴らしいことです。

そして、完全に技術的ではないリスク：私たちはトライはしますが、全てのフィーチャーを、顧客がするのと同じ方法では、社内で使用できません。私たちは誤った安心感に落ち着いてはいけないと、いつも確認しなければなりません。そのソフトウェアが私たちにとってきちんと動作することは極めて重要だけれど、それでは十分ではありません。偏執的で悪魔のようなテスターがいることは、それ以上ないほどに重要です。

ドッグフーディング展開の基準

いくつかの問題にぶつかるでしょうから、内部のドッグフーディングシステムを展開するときのシンプルな基準を2,3つ定義しておくことは理にかなっています。安定性とドッグフーディングの価値との間のバランスにぶつかるにちがいありません。実験的なことに集中しすぎた場合、あなたは早期に多くのフィードバックを得るでしょうが、主なものは否定的なフィードバックでしょう。安定性に集中しすぎた場合、バグについて否定的なフィードバックは避けることができます。しかし、リリースサイクルにおいて遅すぎるときにフィードバックを得られるでしょう。フィードバックに基づいてそのフィーチャーをもはや改良することができないほど遅くにです。Confluence において、私たちはこれらの基準を持つことが多いです:

• Bambooサーバー上の全ての自動化されたテスト（数千もあります！）は、ターゲットのコンフィギュレーションに合格しなければならない（もしTomcatに展開する場合は、そのTomcatテストが合格しなければならない）；
• その自動化されたパフォーマンステストは、重大なスローダウンを示してはならない；
  

• まさに複製であるステージングシステムに展開し、動作しなければならない。上位のユースケースの、手動試験は、そのステージングシステム上でいかなる問題も示してはならない;

• 新しいフィーチャーは、QAによりチェックされ、致命的問題が発見されてはならない。多くの既知のバグは受け入れられるべきである。ミニリリースにおいて、私たちはバグをゼロにすることを目標とはしていません！フィーチャーが正しい方向性あるかどうかを早期に知りたいのです。新しいバグが多かったり少なかったりするのは問題ではありません。エンドユーザーが新しいフィーチャーについての概念をつかむことさえできれば。バグをゼロにすることにこだわると、多くの時間がかかり、非常に重要なフィードバックを入手するのが遅くなってしまうかもしれません。

      

公開ドッグフーディング

私たちはまた、誰からも見ることができるサーバー上で、Confluence の未リリースバージョンを動かしています。しかし、そこでは2週間ごとのリリースは動かしていません。内部のドッグフーディングにより、バグやユーザビリティーの問題を早期に発見することに集中しているので、マイルストーンリリースを洗練させるために極端に高い要件は持ちません。しかし、外部のシステムはまた、潜在的な顧客により使用されます。私たちは、その一時的なバグが実際に最終ソフトウェアリリースに残ると思われたくはありません。つまり、外部のドッグフーディングは、主にパッチリリース（いかなる新しい機能も追加されません）や、リリースサイクルの最終月にベータ版品質のリリースとして行われます。バグが発生するかもしれないというある程度のリスクはまだありますが、それは制御可能な範囲です。4ヶ月のリリースサイクルの最終月にフィードバックを得ることは、とても遅いです。しかし、依然として、一部のユーザーからのフィードバックや、社内システムにおいて遭遇することのないだろう現実的な問題（たとえば、スパム、検索エンジンウェブクローラー、匿名アクセス、ハッカーの問題など）に対応するだけの十分な時間はあります。

実用主義であり、ニーズに対応する

アジャイルプロジェクトはとても頻繁に失敗してきました。なぜなら、ネット上で読んだいくつかのアプローチに盲目的に従うことができると人々が考えたからです。ばか正直にならないようにしましょう！私たちがここにたどり着くまでには、たくさん考えることと、注意深い準備を必要としました。2週間ごとのドッグフーディングによるフィードバック無しに、私たちの、成功、アジャイル、速いペースは無し得なかったでしょう。しかし、一つの方法が皆にあてはまることは意味していませんし、皆様はすべてのプロセスを夜通しかけてボード上にならべてみて、私たちの例に従うべきでしょう。注意深く段階をふみ、警戒をしてから自分のチームで試してみましょう！バックアップは役立つでしょう。QA は役立つでしょう。非本番環境で試してみることも役立つでしょう。チーム内で議論することは、成功のために非常に重要なことです。明瞭なコミュニケーションはかつてないほど重要です。失敗しかけているプロジェクトの途中でこれを試すことはやめてください。むしろ待って、メジャーリリースを行った後にこのプロセスを導入するのが良いでしょう。そのような感じです。いくらかの常識があれば、継続的なドッグフーディングにより、それなしにどのようにソフトウェアの開発を管理したらよいのかとあなたは考えることになるでしょう。


アジャイルイテレーションへのアプローチについて、Perの説明を聞く