シリーズ「開発の初めから順番に書いていってみる」の続きです。
前前回、要求仕様の問題について書いて、そこで、「プロトタイプ」の話と、「雛形があってそれをカスタマイズ」の話を書くということを書きました。
前回、プロトタイプの話を書いたので、今回「雛形があってそれをカスタマイズ」の話です。
なお、今回の話はあくまでもウィリアムのいたずら個人の意見であり、一般的な意見ではありません。
■ラーメンのスープをしょうゆのとんこつにして。。
要求仕様の問題点のところで、「要求仕様にできないことが書いてあるかもしれない」ということを書きました。
これは、ユーザーの要求は、実現してないものを要求としてあげるため（っていうか、実現しているものは要求する必要ないけど）現実的には、無茶なことを要求してしまうことがあります。
これを、たとえ話で言うと、ラーメンを作るとしましょう（ラーメン＝システム）
今の気分は、こってりしつつ、あっさりしたのがたべたい。
こってりした、とんこつはたべたことある。
あっさりした、しょうゆラーメンを食べたことある
（ちがうかもしれませんけど、仮に、そうだとします）。
そこで、ラーメン屋さん（SEさん）にむかって
「ラーメンのスープをしょうゆのとんこつにして。。」
といってしまうと。。。
どんな味になるんだ？？
■ユーザーが知っていると、それを組み合わせて。。とかんがえてしまう
これは、ある程度、お客さんに知識があるとき、顕著に起こります。
組み合わせることが、可能かどうかというのがわからず、組み合わせてしまうため、システム的に（ラーメン的に）おかしくなったり、不要に重くなってしまったり（トッピングしすぎで、らーめんかどうか、わからなくなる）します。
お客さんじゃなくって、営業がそうしてしまうこともあります。
営業もある程度知っているので、この手の話がおこりやすくなります。
どこをいじると、システムがおかしくなる（ラーメンのスープの味が崩れる）かがわからないため、無茶な組み合わせをします。
■ラーメン屋さんは、そーはしていない。
でも、ラーメン屋さんは、ふつう、お客さんに、しょうゆのとんこつという組み合わせをさせません。
ふつう、ラーメン屋さんは、あらかじめ、こういうラーメンを作るというものがあって、特注とか、トッピングで多少変えます。
だから、ラーメン屋さんはなりたつのであって、客に合わせていたら、おいしいラーメンもめちゃくちゃになっちゃいます。
■そー言う意味で、雛形とカスタマイズ
そーいう「こういうラーメンを作る」っていう部分が雛形で、「特注とか、トッピング」がカスタマイズになります。
つまり、雛形部分を自社にあわせる（自分の好みに合わせる）ために、カスタマイズが必要になってくるっていうことです。でも、雛形となる部分は、ある程度できる見込みがないと（スープをちゃんと作って、ラーメンの味が崩れないことを確認しないと）、客の要望だけではめちゃくちゃになる危険があるってことです。
つまり、今みたいに、客の要望をきいて、それを元につくるというシステム開発は、客の側で、絶対できるという閉じた世界観のシステムを提案しない限り（ラーメンとしてスープも麺もこれでOKという裏づけがないと）、危険である、客の言ったとおりに作ってつくれるかどうかわからないということになります。
こちらから、作れるラーメンを（雛形システムを）提案するのであれば、OKなんですけど、そーじゃないと、とんでもないものを作ろうとしてしまう可能性があると。。
■カスタマイズのさいのフィット＆ギャップ
で、カスタマイズする場合、フィット＆ギャップ分析ということになるのですが、その場合、よくやるのが、製品の機能についてのフィット＆ギャップ分析です。
しかし、ラーメンで考えると、トッピングを安易に変えても、おいしくならないわけです。作り方とかあるし。。そうやって考えると、作る材料、作り方から吟味しないといけません。
同じように、フィット＆ギャップを考える場合でも、まず、入出力データレベルで同じかどうか、その後、処理過程が同じかどうかなど、順を追って差を確認しないと、結果だけ追っても、無茶な部分が出てきます。
っていうことは、雛形自体の、エンティティやプロセスを明確化し、そのプロセスと出力がどう関係するかというのをだしておかないといけません。
そのような、仕様を明確化した雛形を、各ソフトハウスが出しておくことで、システム開発の精度、要求分析の精度は、かなり上がってくると思います。
ということで、次回から、外部設計です。
アクセス
トータル
ランキング
