プロトタイプの利点って？

こんにちは。
今派遣で行っている先が、プロトタイプ型の開発手法で製造を行っています。汎用機育ちの私としては、非常にもどかしいのです・・・
中小企業向けのクラサバ（ACCESS使用）で、直エンドユーザーさん相手にやりとりしています。
確かに、要件定義書やら、基本設計書をみせても理解していただけるのが難しいお客さんだと思います。できたところを少しずつ見せて、意見を言ってもらうのは、正しい手法だと思いますが・・・
如何せん仕様書が存在しないし、製造完にならないので、テストができません。下手すると、途中でPGが変わっていたりするので、どこまで出来上がっているのかわからない状況です。
こういうお客さんの場合、やはりプロトタイプが有効なんでしょうか？プロトタイプで開発した場合、品質をあげるためのポイントをお教え願えないでしょうか。よろしくお願いします。

No.4 ベストアンサー 回答者： kosaoji 回答日時： 2003/10/27 11:30

わたしは，４３歳，プロジェクトマネージャです。

わたしは，よく，プロトタイプ手法を活用します。
開発手法の選定は，受注段階でほぼ選定しており，開発チームのキックオフ時点までに確定しています。

プロトタイプが向く案件は，開発チーム側に顧客業務ノウハウがあることが必須です。開発チーム側から，顧客にとって稼働後に価値のあるシステムとはこうですよ！と見せる位の論理性が必須です。

なければ，そのプロジェクトは，海路図もなければキャプテンも素人という状態での航海に等しい結果が待ち受けていると思います。

ウォーターフォールモデルでは，膨大な設計書を開発側が作るけど，顧客は，見ても，書いている内容がさっぱわからない。なら，プロトタイプだ！というのでは，短絡すぎ。早晩，失敗プロジェクトの烙印を押されます。

派遣で行っておられるなら，逃げたもんがちですよ。
まぁ，それはさておき，プロトタイプの利点は，上段で述べたとおり，開発側が顧客にとって必要な機能をある程度知っているというのが前提と述べました。

ということは，設計書なんて書かなくても，開発チームにグランドデザインが入っているので，その出力が紙という設計書に向かうのではなく，直接納品物となるプログラムに向かいます。

当然，生産性はあがります。
また，顧客も，設計書をいくら見せられても，実際に稼働してみるとこんなはずでは，というのは多々ありますよね。プロトタイプは，それを１００％とはいいませんが，かなりの顧客満足を得られる手段となります。

が，プロトタイプ手法のリスクは，gooco_chanさんの質問内容にあるとおり，仕様が二転三転して定まらない，とか，仕様の軸が決まらない，が延々と続いてしまう可能性が高いこと。

そのドツボにはまると，納期限間際になって，もう，顧客のことなんかそっちのけでの突貫工事で，とりあへず，作った，使え！っていうレベルのしろものを収めて終わったことになってしまうでしょう。

プロトタイプはメリットも大きい分，リスクも大きいです。そのことを認識しておくのがプロジェクトマネージャの最低限の知識だと思います。

この回答へのお礼

ご教授ありがとうございました！
もともとは、数人の技術者で起こした会社なので、少し大きくしたいらしいが、若い未熟な人たちがついてこれていないというのが現状のようです。

＞プロトタイプが向く案件は，開発チーム側に顧客業務ノウハウがあることが必須です。開発チーム側から，顧客にとって稼働後に価値のあるシステムとはこうですよ！と見せる位の論理性が必須です。

表向きはこんな感じでお客さんには見せていますが、実は開発サイドは火の車・・・

逃げたほうがいいですよね。
自分の技術力が腐っていきそうで、時間がもったない！とストレスがたまる日々です。

お礼日時：2003/10/28 00:08

No.5 回答者： Jitta 回答日時： 2003/10/27 14:48

>ということを繰り返すたびに、ドキュメントの修正をするのが、コストがかかるからいやなんでしょうね・・・。

　ドキュメントを作らないことのコストの方が大きいです。

　例えば、ある段階で「ここはコンボボックスで表示しよう」となりました。それで作っていって、「やっぱりリストボックスにしよう」となりました。そして作っていって、「やっぱりコンボボックスにしよう」となりました。そして作っていって・・・（以下省略）

　実際に、近いことがありました。「なぜそのようにしたのか」を書き留めておかないと（ドキュメント化しないと）、人間は必ず忘れますから、同じことの堂々巡りをやります。また、特定の人物が最初から最後まで一貫して管理を行うとも限らないので（ここで「最後」は作り終わりではなく、使い終わりを指す）、こういうときもドキュメントは有効です。担当が変わった後に「なんでこんな作りかたしてんねん」と文句言われたこともあるし…。

　プログラムを作るときには、プログラムよりもテストを先に作りましょう（テストファースト）。例えば、「ユーザによる入力」というコンポーネントがあった場合、たいていの場合そこに「どんな値」が入力できるかも、おおよそ決まっています。ですから、その値の範囲内、範囲外を入力するようなテストケースができます。これを先にコーディングしておきます。そしてその中にコメントとして、いつ、誰と、誰が、どこで、決めたか、を記入しておきます。あまりお勧めできる方法ではありませんが、仕様書が全くないよりかはマシです。

No.3 回答者： suzuhide 回答日時： 2003/10/27 00:17

上司の方に意見を言って、仕様書を作らして貰った方が良いと思います。

僕も昔小さなプログラム等は仕様書無しで作りましたが、ある程度以上大きくなると、支離滅裂で何を作っているか、何処まで出来たかさえ判らなく成ります。
面倒でも仕様書を作り、それに合わせてプロトを作って、クライアントに試しに使って貰い改良をしていったほうが、結果的に早く仕事が終わると思います。
これはプログラムだけでなく、総てのものづくりに共通して言えると思います。

この回答へのお礼

ありがとうございます。
自分の担当分は、結構ドキュメントにして残しているんですが、モジュールごとに担当が決まっていないんですよ。丁寧に作っても、他人が手を入れちゃうと、投げ出したくなるのは、私が根性なしなんでしょうか。
この状況をどうしたら上司に気づいてもらえるか・・・
とりあえず、自分の認識がそれほど間違っていないようなので安心しました。

お礼日時：2003/10/28 00:01

No.2 回答者： kan3 回答日時： 2003/10/26 02:01

仕様書作らないと、終わらないですよね。

まず、仕様書でしょ。

この回答へのお礼

そうですよねえ。
じゃあ、今から仕様書作るかってことにはならないですよねえ。納期があるわけだし。
この会社なんとかしてほしいです。
どうしたら、気づいてくれるんでしょうかね。

お礼日時：2003/10/27 23:57

No.1 回答者： suzuhide 回答日時： 2003/10/26 01:28

プロトタイプを作るのが早すぎるのでは無いでしょうか。

なんだか、スケルトンからユーザーの話に合わせて手探りで作っているような気がします。
普通、ユーザーの要求を集約して一応の仕様書を作ってからプロトタイプを作り、それから必要な部分を足し、不必要な部分を削って製品版を作るのでしょう。
貴方の会社では製品の製作を急ぎすぎていませんか。

この回答へのお礼

ご回答ありがとうございます。
規模が大きいのかよくわかりませんが、プロトタイプを作っては、見せ、意見を反映して・・・ということを繰り返すたびに、ドキュメントの修正をするのが、コストがかかるからいやなんでしょうね・・・。
製作を急ぎすぎているのか、途中のフェーズが面倒なのか・・・。
仕様を考える人間と、メイクをする人間が分離していないんですよ。メイクしながら、仕様を考えているって感じです。

お礼日時：2003/10/26 21:03