前回のブログで、「入力から分析してしまうと、大変なことになる。」と書いたことについて。
システム開発を、入力や、開発の通論（業界の一般的なシステムの作り方とか）、パッケージソフトの利用から入ると、ものすごいオーバースペックになって、開発費が高騰したり、場合によっては開発できなくなったりしてしまう。
これは、実例から入ったほうがわかりやすいので、まず、例を挙げます。
おなじみ？？「夕食支援システム」において、
これで、夕飯を出前してもらうのに、商品マスタが必要だ！というところで、商品マスタから入ると、大変なことになるのですよ！
だって、お店によって、商品って、全然違うもん！
マクドナルドに誰かが買いに行く場合
１７クーポン利用１個
（＝てりたまバーガー＋チキンフィレオ＋チキンマックナゲット＋ドリンクＭ２個）
ナゲットは、マスタード
ドリンクは、ホットコーヒーで砂糖とミルクつき
とコカコーラ
それと、石焼いもの屋台
Ａさんは、やきいも小３個
Ｂさんは、５００グラム
Ｃさんは、やきいも１０００円分
（どうも、焼き芋やさんって、グラムでも、個数でも金額でもかえるみたい。。。経験値より）
それと吉野家の豚ドン、大もりつゆだくで。
っていうのを、マスターにしろ！っていわれたらどーする(^^;)
１つのお店、一つの商品でも、単位が違うし（石焼き芋のケース）、セットだとしても、いろんなバラエティがあるし、クーポンもある、さらに、吉野家の豚ドンにいちゃっては、マスターにはのってない注文もできちゃう（つゆだくとか）。
で、このマスター設計から入ると、暗礁にのっちゃうんですよ。
実は、これ、出力から考えると、かんたんです。
実は、この商品マスターって、ＤＢにいれなくってもいいんです。
最終的には、発注表をみて、発注ができれば、
商品マスタは、なくったって、いいんです。
つまりですね、ショッピングカートで、商品マスタＤＢを持たない形式っていうのがありますが、
あれと同じように、発注時に、発注用の商品名と数量、金額を受け取り、それをＤＢに入れるようにします。
ユーザーは（Webかなんかで）商品を選択していって、発注ボタンを押すと、発注用の商品名をjavascriptで作るようにします。
そうすると、各お店ごとにＷｅｂページをつくって、夕食の商品と数量が選択できるようにして、発注するとき、発注用の商品名と数量、金額を受け取るようにすればいいのです（そのインターフェースは共通化する）
うーん、わかりにくいけど、わかったかな。
用は、どんな商品でもかまわなくって、商品マスタを持たないかたちのショッピングモールのＣＧＩを利用すればできるってことなんだけど。
でも、入力から入って、商品マスタを作ろうとすると、まあ、この共通の商品マスタっていうのはできないし、通論から入ると、この手のＷｅｂサイトのマスタは、全部ＲＤＢに入れて作るので、かなり複雑なＤＢ構造になってしまう。
でも、結果から考えると、これって、フリーソフトの（ＤＢを持たない形の）ショッピングモールのＣＧＩと同じ作りとわかる。
さらに、もし、そのフリーソフトのＣＧＩを利用するとなれば、すぐに取り組めて、開発費は、ただ（は極論だけど、フリーソフト利用だから、相当金額は低い）はずだ！
営業さんとか、コンサルの場合、こういうシステムは、こういうソリューションという通論を持っていて（たとえば、ＣＲＭなら、当社のなんとかパッケージ、ＥＲＰなら当社のＥＲＰソリューション）、それを売りつけようとするわけよ。
そうすると、そんなのいらなくても（オーバースペックになっても）それ（＝自社の売り物商品）にあわせるから、開発費は高騰したりするのね。
また、コンサルを頼む場合、お客さんの出力に合わせるというより、知識を売り物にして、「これは、こうあるべき」論で考えることが多い。そうすると、入力のマスタから「こうあるべき」で定義しちゃうのね。
たとえば、商品マスタは、こういう機能をもつべきとかね。。。
そうすると、（今回の夕食支援システムのように）出力から考えたら、商品マスタなんて、どうでもいいような場合でも、りっぱなものを作ろうとして、結局、開発費高騰なんてことになりかねない。
じつは、こういう事態を避けるため、ＰＭＢＯＫでは、スコープ計画で、「成果物」を定義し、スコープ定義で、「成果物を実現する」方法を考える。
たとえば、さっきの夕飯支援システムなら、成果物の毎日の発注表を作るため、それを実現する方法ということで、フリーソフトのＣＧＩ利用でもＯＫなわけ。
でも、ふつう、この成果物って、そこまで考えないで、「成果物は、バイナリとドキュメントでドキュメントは要求仕様書と、画面設計書とファイル設計書」などという形式だけしか考えないので、あんまり役にたたず、こういう開発時高騰をまねくわけよ。
だから、ＰＭＢＯＫのスコープ計画とスコープ定義をまじめに捉えて、ここで成果物を出力するものまで規定できれば、開発は楽になるし、ユーザーも開発費は低減できる（が、実は、これをちゃんとやることは、無理。そのことは今後書いていくが、その方向にむかって、努力することは可能だ）。
いいかえると、（うるぐすディスカバリー風にいうと） 営業とコンサルの暴走による開発費高騰は、ＰＭＢＯＫのスコープ計画で、成果物を具体的に定義して、それに基づいて入力を考え、スコープ計画をたてれば抑えられることは、あまり知られていない。
システム開発を、入力や、開発の通論（業界の一般的なシステムの作り方とか）、パッケージソフトの利用から入ると、ものすごいオーバースペックになって、開発費が高騰したり、場合によっては開発できなくなったりしてしまう。
これは、実例から入ったほうがわかりやすいので、まず、例を挙げます。
おなじみ？？「夕食支援システム」において、
これで、夕飯を出前してもらうのに、商品マスタが必要だ！というところで、商品マスタから入ると、大変なことになるのですよ！
だって、お店によって、商品って、全然違うもん！
マクドナルドに誰かが買いに行く場合
１７クーポン利用１個
（＝てりたまバーガー＋チキンフィレオ＋チキンマックナゲット＋ドリンクＭ２個）
ナゲットは、マスタード
ドリンクは、ホットコーヒーで砂糖とミルクつき
とコカコーラ
それと、石焼いもの屋台
Ａさんは、やきいも小３個
Ｂさんは、５００グラム
Ｃさんは、やきいも１０００円分
（どうも、焼き芋やさんって、グラムでも、個数でも金額でもかえるみたい。。。経験値より）
それと吉野家の豚ドン、大もりつゆだくで。
っていうのを、マスターにしろ！っていわれたらどーする(^^;)
１つのお店、一つの商品でも、単位が違うし（石焼き芋のケース）、セットだとしても、いろんなバラエティがあるし、クーポンもある、さらに、吉野家の豚ドンにいちゃっては、マスターにはのってない注文もできちゃう（つゆだくとか）。
で、このマスター設計から入ると、暗礁にのっちゃうんですよ。
実は、これ、出力から考えると、かんたんです。
実は、この商品マスターって、ＤＢにいれなくってもいいんです。
最終的には、発注表をみて、発注ができれば、
商品マスタは、なくったって、いいんです。
つまりですね、ショッピングカートで、商品マスタＤＢを持たない形式っていうのがありますが、
あれと同じように、発注時に、発注用の商品名と数量、金額を受け取り、それをＤＢに入れるようにします。
ユーザーは（Webかなんかで）商品を選択していって、発注ボタンを押すと、発注用の商品名をjavascriptで作るようにします。
そうすると、各お店ごとにＷｅｂページをつくって、夕食の商品と数量が選択できるようにして、発注するとき、発注用の商品名と数量、金額を受け取るようにすればいいのです（そのインターフェースは共通化する）
うーん、わかりにくいけど、わかったかな。
用は、どんな商品でもかまわなくって、商品マスタを持たないかたちのショッピングモールのＣＧＩを利用すればできるってことなんだけど。
でも、入力から入って、商品マスタを作ろうとすると、まあ、この共通の商品マスタっていうのはできないし、通論から入ると、この手のＷｅｂサイトのマスタは、全部ＲＤＢに入れて作るので、かなり複雑なＤＢ構造になってしまう。
でも、結果から考えると、これって、フリーソフトの（ＤＢを持たない形の）ショッピングモールのＣＧＩと同じ作りとわかる。
さらに、もし、そのフリーソフトのＣＧＩを利用するとなれば、すぐに取り組めて、開発費は、ただ（は極論だけど、フリーソフト利用だから、相当金額は低い）はずだ！
営業さんとか、コンサルの場合、こういうシステムは、こういうソリューションという通論を持っていて（たとえば、ＣＲＭなら、当社のなんとかパッケージ、ＥＲＰなら当社のＥＲＰソリューション）、それを売りつけようとするわけよ。
そうすると、そんなのいらなくても（オーバースペックになっても）それ（＝自社の売り物商品）にあわせるから、開発費は高騰したりするのね。
また、コンサルを頼む場合、お客さんの出力に合わせるというより、知識を売り物にして、「これは、こうあるべき」論で考えることが多い。そうすると、入力のマスタから「こうあるべき」で定義しちゃうのね。
たとえば、商品マスタは、こういう機能をもつべきとかね。。。
そうすると、（今回の夕食支援システムのように）出力から考えたら、商品マスタなんて、どうでもいいような場合でも、りっぱなものを作ろうとして、結局、開発費高騰なんてことになりかねない。
じつは、こういう事態を避けるため、ＰＭＢＯＫでは、スコープ計画で、「成果物」を定義し、スコープ定義で、「成果物を実現する」方法を考える。
たとえば、さっきの夕飯支援システムなら、成果物の毎日の発注表を作るため、それを実現する方法ということで、フリーソフトのＣＧＩ利用でもＯＫなわけ。
でも、ふつう、この成果物って、そこまで考えないで、「成果物は、バイナリとドキュメントでドキュメントは要求仕様書と、画面設計書とファイル設計書」などという形式だけしか考えないので、あんまり役にたたず、こういう開発時高騰をまねくわけよ。
だから、ＰＭＢＯＫのスコープ計画とスコープ定義をまじめに捉えて、ここで成果物を出力するものまで規定できれば、開発は楽になるし、ユーザーも開発費は低減できる（が、実は、これをちゃんとやることは、無理。そのことは今後書いていくが、その方向にむかって、努力することは可能だ）。
いいかえると、（うるぐすディスカバリー風にいうと） 営業とコンサルの暴走による開発費高騰は、ＰＭＢＯＫのスコープ計画で、成果物を具体的に定義して、それに基づいて入力を考え、スコープ計画をたてれば抑えられることは、あまり知られていない。
アクセス
トータル
ランキング
