|
|
/*========================================================*/ ＜＜＜あゆしゃのＣ言語プログラミング＞＞＞ /*========================================================*/ 第３８１回 XP４ 短期リリース 発行 ２００３年９月１日（月曜日） 発行数 約３２００ {magclick} {magclick} /*========================================================*/ はじめに （ 決り文句 ） /*========================================================*/ ・このメールマガジンはまぐまぐさんから発行しています。 ・ジャンルは、マルチメディアのプログラム、Ｃ言語です。 ・このメールマガジンは、横６０文字で作成しています。 また、インデントはすべて半角スペース４つで構成しています。 ・ここで扱うプログラムは、C言語と半光年以内のものです。 ・登録解除は、まぐまぐさんのホームページでお願いします。 ・まぐまぐさんのバックナンバー（下欄参照）を活用して下さい。 ・ここは私の復習の場です。内容は約１ヶ月内外に私が勉強した 内容になっています。最新の技術があれば、へたれもあります。 ・わかりやすさを優先させる為、たまに嘘があるかもしれません。 /*========================================================*/ ご挨拶 /*========================================================*/ こんにちは。あゆしゃです。 しまった、ヴィオをやっていました。 このままでは私は、試験に落ちてしまいます。 社内試験なのでうかっても、とくになにというものでもない のですが、 落ちると追試を受けねばなりません。それだけは回避しなければ なりません。 そこで私は自分ルールを１つ決めました。 ヴィオ禁止！ {magclick} /*========================================================*/ 今回のお題 ＜＜ XP４ 短期リリース ＞＞ /*========================================================*/ １２回分の連載の内容です。 １ XPって何？ ２ ペアプログラミング ３ テスト駆動開発 ４ 短期リリース ５ ユーザテスト ６ 全員同席 ７ 最適ペース ８ コード共同所有 ９ 常時結合 １０ リファクタリング １１ シンプル設計 １２ 計画ゲーム さて、今回は４番ですね。 /*========================================================*/ ４ 短期リリース /*========================================================*/ 人生、何が起きるか分かりません。 だから生命保険やらなんやらに入りましょう。 自動車保険には２年連続お世話になったあゆしゃです。 保険料が１０万を超えましたが。 それはともかく、保険に入るのは、ソフトウェアも同じこと です。 /*========================================================*/ リリース後にバグが発覚したとしましょう。 しかもこちらはそれに気がついて、納品先にはまだばれていない としましょう。 まぁ、大抵見て見ぬ振りですわねぇ。 何か言われたら、対処もするでしょうが、何も言われていない うちは、こちらからわざわざちょっかいを出すようなことは、 あまりしません。 マイクロソフトがそうですが、どこでもそうです。やるだけ、 信頼が落ちるだけですから、ユーザに発覚する前に新しい ヴァージョンを出すのです。 ついでにこっそりバグも直す、という感じ。 /*========================================================*/ ウィンドウズのようなパッケージソフトはそれでいいでしょうが 企業に納品するようなソフトの場合、そうもいってられません。 この場合、（言われたら）バグを修正します。もちろん修正費用 はただです。 ただといっても、バグ修正といった保守費用はあらかじめ開発費 という名目でいただいちゃっていたりしますので、まったく損とい うわけでもないのですけどね。 しかしそれだけ儲けがすくなくなるのは事実です。ユーザとして 使い物にならないものはいらないというのは当然として、開発側と しても、なるべく平謝りでリリースしなおすというのは、避けたい ところです。 /*========================================================*/ そこで、短期リリースというわけです。 人生七転び八起き、ソフト七バグ八納入、というかどうかどうか はわかりませんが、つまり、ソフトになるべく場数を踏ませておこ う、という考え方です。 そうすれば、きっと最初のリリースはごたごたするでしょうが、 それは計算の範囲内として、最後のリリースには問題なくことが 終了するでしょう、という夢です。 リリースを重ねる（繰り返すのではない）うちに、ソフトが、 なんか、こう、固まってくるような、そんな気がします。 大丈夫ですよと、胸を張って納品できるようになります。 /*========================================================*/ しかしこれが、たとえ複数回リリースするとしても、 「今回リリースするバージョンは実際にお客さんのところで動作 しなければならない。よって失敗は許されないから、テストは 念入りに行うように。」 なんてことになると、プレッシャーはどうでもよいのですが、 失敗がないわけないでしょう。 テストと実装は違うもの、だからです。 /*========================================================*/ バグは、いろいろなものがありますが、もっとも深刻なバグは 「仕様書が間違っている」 というものです。 当然テストも、テスト駆動開発を前提としなくとも、仕様書通り に動作することを確認するのですから、仕様書が正しいかどうか というテストなど行いません。 ところがリリースを行うと、実際にユーザが使い、そこでバグが 発生します。 「こういうときに、こう動いてくれなければ困るのに動かないぞ」 作っている側としては、仕様書にそのような動作を記述しない 限り、ソフトが正しくできていれば、そのように動作しません。 そういうものだから仕方がないといって、ユーザにそのように 使っていただくということもありますが、使い物にならないほど 根本的な間違い、または勘違いは、直さざるを得ません。 根本的な間違いはともかく、勘違いというのは、仕様書を作成 した人が、ユーザがそのソフトを使用する方法を勘違いしていた、 もしくは気にしていなかったということです。 /*========================================================*/ 短期リリースは、開発期間を何分割かに分けて、そのたびに リリースを行います。 短期というのがどれほど短期であるかというと、１〜３週間 という期間です。このたびにリリースを行うようにするという ことです。 開発期間の長い、たとえば１年続くものであっても、３週間 というのが最大としておくべきです。 /*========================================================*/ ウィンドウズでもベータ版を配布して、ユーザから意見をかき 集めますよね。 私も２年ほど前、C#のベータ版でいろいろ遊んだものです。 短期リリースもこれと同じ目的です。つまり、ユーザからの フィードバックを得ることを目的としています。 フィードバックを受けたら、それを反映したものをまたユーザ にフィードバックしなおす必要があります。だから、たとえ 開発期間が長くとも、ユーザがフィードバックを忘れないうちに 次のリリースを持ち込むのです。 開発を推し進めていくことが短期リリースの目的ではありま せん。逆に、開発を推し進めないことが重要です。ちょっとまてよ それでいいのか、あぁそうなのか、という確認を丁寧に行います。 /*========================================================*/ 短期リリースを行うには、１つだけ問題があります。重要な、 問題です。 ユーザの協力が、絶対条件です。これがないと短期リリースは 成立しません。 ユーザの都合などお構いなしに一方的にリリースを繰り返すの では、意味がありません。 言い方が悪いですが、ユーザをデバッグツールとして使いこなす 必要があります。 興味本位で積極的にテストを行ってくれるのですから、すばら しいツールです！ まぁ、ユーザとしても、どっとシステムを渡されるより、段階を 経てシステムを使いこなせるようになっていったほうが、楽で しょう。 /*========================================================*/ 短期リリースに似たものとして、プロトタイプがあります。 意見を求めて開発を軌道修正するという考え方が似ています。 /*========================================================*/ さて、実際に短期リリースを行う場合、ルールが１つあります。 それは、決めてしまった期間を変えない、つまりリリース日を 変更しないということです。 ドラクエのようにリリース日をころころ変えられるというわけ にはいきません。ユーザとの、企業間の連係プレイーだからです。 よって、短期リリースのリリース日は絶対に変えません。 間に合わなかったとしても変えません。素直に謝りましょう。 /*========================================================*/ もしも開発が遅れて機能が間に合わない場合はどうするので しょうか。 そのような機能は、捨てます。 もしも機能が足りなくて使い物にならない場合はどうするので しょうか。 そのようなソフトは、捨てます。 もしもリリースに連続で失敗してプロジェクトがにっちもさっち もいかなくなった場合は、どうするのでしょうか。 そのようなソフトハウスは、捨てます。 そのソフトハウスがバグなのでしょう。取り返しのつく早期の 段階でバグを解消できて、ユーザとしてはラッキーと考えるべき です。 ソフトハウスとしては、社内またはユーザ側から大御所を呼んで 救済していただき九死に一生を得る、という感じでしょうね。 /*========================================================*/ リリースは開発者がユーザの評価を受ける恐怖の裁判です。 それが何度もおとづれるのですよぉ。怖いですねぇ。 恐ろしいですねぇ。 つまり、電車のホームのように、危険なほうが安全なのです。 /*========================================================*/ さいごに /*========================================================*/ 参考文献 よくわかる最新XPの基本と仕組み 長瀬嘉秀 監修 畑田成広 樋口博昭 著 秀和システム ISBN4-7980-9374-3 １９００円（税別）（ただし支給品） {magclick} /*========================================================*/ 次回予告 /*========================================================*/ 次回は９月４日（水曜日）に、第３８２回を送ります。 お題は「XP５ ユーザテスト」 次回はユーザテストについてです。 お楽しみに！ /*========================================================*/ 最後の決り文句 /*========================================================*/ このメールマガジンは、まぐまぐさんから発行しています。 このメールマガジンを解除したい場合は、まぐまぐさんをご利用 ください。このメルマガのまぐまぐアイディーは最後にあります。 このメールマガジンには広告が挿入されます。 このメールマガジンの内容に文面の引用はありません。 めーらっくすの場合はめーらっくすの利用方に従ってください。 このメールマガジンの内容は、転用、流用、宣伝、リンク、 昔は絶対を守れないと死刑でしたけどね なんて大歓迎です。 {magclick} /*========================================================*/ /*========================================================*/ 発行者 あゆしゃ まぐまぐアイディー 0000020674 まぐまぐバックナンバー http://jazz.tegami.com/backnumber/frame.cgi?id=0000020674 あゆしゃの世界 http://ayusya.hp.infoseek.co.jp/ 登録と解除 http://www.mag2.com/m/0000020674.htm ご意見・ご感想・ご質問メール mailto:ayusya@flamenco.plala.or.jp めーらっくす http://www.mailux.com/mm_dsp.php?mm_id=MM3E1AEE285AB4F |