リリースはお早めに（短期リリース） | column

またもや、消費者金融っぽいタイトルですね〜(^_^)

前回の”ご利用は計画的に（計画ゲーム）”の最後で軽く触れましたが、「短期リリース」は、リリースの期間を短くとることで、ビジネス側と開発側の意識のズレが大きくなることを防ぐ役割を持っています。

例えば、リリースまで３ヶ月あるとすれば、１ヶ月に１回の中間リリースを２回行い、最後に最終リリースを行うといった感じで段階的にリリースを行います。

また、開発側は更に細かいイテレーションという単位にリリースを分けます。１回のリリースが１ヶ月であれば、１イテレーションを２週間として、１回のリリースまでに２回のイテレーションがあるようにします。

さて、この短期リリースですが、リリースやイテレーションのサイクルが短ければいいというものではありません。

リリースやイテレーションの終わりのタイミングでは、実際に動くシステムを提供する必要があるのです。

そうです、実際に動くシステムです！

よく、中間納品という形で「動かないシステム」を形式上納めるというビジネス習慣がこの業界には未だありますが、これは短期リリースじゃぁありません(^_^)

実際に動くものをビジネス側と開発側が一緒に見て、意識合わせをします。

このとき、リリースや納品と言うと、「えっ！もう納品してくれるの？」とビジネス側にあらぬ期待を抱かせてしまうので、「仕様確認のデモをする」という位置付けにするといいですね。

そうやって、実際に動かしながら、ビジネス側から「これこれはこうした方がいいねぇ」といったフィードバックをもらっていきます。

その際、期待通りの動きでなかったり、作ってみたものの「やっぱいらないや」といった意見もビジネス側から出てきます。

これ、すーーーっごく大事な一言ですので、開発側のみなさん、絶対に聞き逃さないで下さいね。この一言は、”ビジネス側が当初想像していた道”をビジネス側自身で少し踏み外したことに気付いた「合図」なのです。

この段階で進む方向を修正できれば、路肩に乗り上げる程度で済みます。F1でもしょっちゅう路肩乗り上げてますよね？まったくもって普通のことです。

でも、もしその一言を無視して、方向を修正しなければ、路肩の代わりに暗礁に乗り上げちゃいますよ(^_^u 即リタイアです。

（開発側の頭の中）でも待てよ．．．方向修正って「仕様変更」や「仕様追加」じゃないの？

．．．そこでイヤーな顔してる開発側のあなた、少し続きを聞いて下さい。

もちろん、次のリリースでもやることがある上、仕様変更をそのまま受けるのは、一方的に作業時間が増えるばかりで、まぁはっきり言ってやってられまへんよね．．．

ですので、ちゃんと解決する仕組みがあります。

それは、次のリリースで組み込む予定だった優先順位の低い開発項目を減らす。これだけです。

「えっ！？そんなことしちゃっていいの？」と思ったあなた、実に正直ですね(^_^)

この部分、今までは開発側がえらく負担を支払っていた部分ですが、ご利用は計画的に（計画ゲーム）をよく思い出して下さい。

時間のスケジュールおよび「どれをやるか？」は、ビジネス側が決めることなんです。

開発側は、ビジネス側がやりたいことに対して、純粋に見積もりを出すだけ。

つまり、決められた一定時間内に「どれをやって」「どれを捨てるか」、その結果として最良なシステムを得るのは、ビジネス側の役割であり、責任なのです。

．．．そこで「なんじゃそりゃ！？」と憤慨しているビジネス側のあなた、少し続きを聞いて下さい。

よ〜く思い出して下さい。

「全ての機能を作り込まないといけませんか？」

「今すぐ作らないといけませんか？」

「運用次第で対処できるものや段階的に作っていけばいいものは本当に１つもないですか？」

「ほしいものを優先順位も振らず無造作に盛り込んでいませんか？」

「急がなくてもいいことにこだわっていませんか？」

「そのシステム自体、本当に必要なんですか？（笑）」

もし、これらに１つでも即答できない項目があれば、いわゆる「余計なこと」をしている可能性があります。

上で紹介したように、こういった余計なことは、実際に動くものを見たら、「やっぱいらないや」ってことになることが本当に多いんです。本当に多いんです。

それに全部やったところで、次のリリースで変更しなければいけないところがボロボロと出てくるんです。

最初から全部うまく作ろうなんて、幻想やエゴ以外の何者でもないんです。

そんな余計なことをするために開発側をフル回転させて、肝心なところで開発側がへばっちゃったら、いいシステムなんて作れる訳ないですよね？

でこぼこ道やコーナーでいくらアクセルを吹かしても、スピードは出ないんです。

そんなところで無理やりアクセルを踏み込んだら、最悪クラッシュですよ。

本当にレースに勝ちたいなら、でこぼこ道やコーナーはできるだけ消耗しないようにステディに走り抜け、何もないストレートになったところで思いっきり踏み込むんです。

そして、スタート直後のロングストレートで決まってしまう勝負もあります。

まずは、本当に必要な最小限のものから作っていき、実際に動かしてみて、本当に必要かどうかを改めて検討することをオススメします。

開発側は、そんなあなたのためにXPを使えるようにして、いつでも仕様変更を受け付けているんですから(^_^)

あったり前のことなんですが、わかるところから始めましょう。

そして、間違いに気付いたら、すぐに直しましょう。

リリース毎、イテレーション毎に必ず動くシステムを着実に得られたら、すがすがしいと思いませんか？

リリース直前になって、「あ〜でもない、こ〜でもない」って慌てふためくことなく、毎日無事家に帰れたらどんなに気持ちいいことでしょう。

実際に動くものを見せれば、あなたの上司にも少しは言い訳できるんじゃないですか？(^_^)

短期リリースは、リリースやイテレーションの終わりに確実に動くものを手に入れるプロセスです。

これを肝に銘じましょう。

そして、計画ゲームと同じく、ビジネス側と開発側が協力して、「１ヶ月毎にリリースしていくぞ！」と足並みをそろえる心構えが重要になるのです。

なお、短期リリースをスムーズに行うためには、開発側の工夫も欠かせません。

これらの詳細については、「テスティング」と「継続的インテグレーション」をお待ち下さい。

次回、12/10(金)は「メタファ」についてです。

お楽しみに！

フィードバック下さい！

tomomo: (Fri Dec 3 22:07:40 2004 )

「次のリリースで組み込む予定だった優先順位の低い開発項目を減らす。」
なんてのが、今まで経験した顧客でと許されないような気もします。。
顧客に、どう説明し、理解を得るのが難しそう。。
一度やれば理解されるかもしれないけど、その一度がハードルが高くないで
しょうか？

tomomo: (Fri Dec 3 22:21:48 2004 )

すみません肝心な事を忘れていました。
いつも楽しみに読ませて頂いています。大変勉強になります。

ますく: (Wed Dec 8 17:53:58 2004 )

tomomoさん、コメントありがとうございますm(_)m
いつも読んでいただいて、嬉しいです！

そうですね〜。
たしかに最初の一歩はハードルが高い感じがします。

お互い、それまでの付き合いや習慣がありますからね。

でももし、tomomoさんが「一度やれば理解してくれるかも知れない」と
お考えであれば、まずはそれにチャレンジしてみるのはどうでしょう？

お客さんが許してくれないというのは、きっと事実ではなく、
tomomoさんの思い込みかも知れません。

他のもっとスマートなやり方はありますが、人からのアドバイスよりも、
自分ができそうなことを信じて行動するのが一番です。

ダメそうでも飛び込んでみるチャレンジ精神は、
どんなことに対しても、どんなときでも、重要なスキルですから．．．

私もそうやってXPを常にテストしてきました。

もし、心配であれば、ピアソン・エデュケーションから出ている
XPシリーズ本を一通り読んでから、その内容を試してみて下さい。

そして、「失敗は学び」。
失敗したからといって、この世が終わりになる訳じゃありません。

私もずいぶん失敗しました。
でも、そのおかげでこのコラムが書けるようになれたんです。

一時的にヘコむことはあっても、失敗から得るものは大きいですよ。

Chat (Lingr.com)

Informaiton

Daily

Column

Zope Solution

Extra

アーカイブ

OSS案内所

Site Info

関連リンク

フィードバック下さい！