要求仕様ではビジネスモデルをおさえる。ビジネスモデルは、人物金情報＋インセンティブをおさえる

　さて、いままでの話で、要求分析を始めるために、出力帳票の分析をするという話とかかきましたけど、問題は、どこまで分析するか。

　この分析は、あくまでも、仕様を固めるためのものだから、
１．このシステム開発で実現しようとする業務やビジネスモデルに対して、
２．このシステムの出力を利用して
３．その業務、ビジネスモデルが実現できることを、シナリオとして表せる
ということが大事で、３の内容が実現するために利用する、２の出力が分析対象になる。

　つまり、開発するシステムを利用してできる業務、ビジネスモデルを明確に描き、その中で必要とされる出力を分析し、それに対応する入力を、そのあとで分析することになります。
　通論とかは、この出力から入力が思い浮かばない場合や、抜けがないかどうかを確認するのに必要となります。

　ちなみに、上記の「開発するシステムを利用してできる業務、ビジネスモデルを明確に描き」すなわち、上記１．２．３の３に相当するのが、ブログ「ウィリアムのいたずらが行った場合の「コピーされるほど儲かるシステム」の見積もり」の「（あ－１）まず、ユーザーの利用の仕方の絵を書く」にあたります。

---

　現実的には、もらった資料を分析しながら、最終的に、こう利用するんだよねというシナリオを描き、そのあと、そのシナリオにもとづいて、資料を位置づけ、足りない資料を補う形になると思います。

　で、この利用の仕方のシナリオが実現できるかどうかを確認するのに、フィージビリティスタディをやったり、プロトタイプをつくるのが、本来のあり方だとおもう。

---

　で、問題は、そのビジネスモデルとか、業務とかは、なんについて書くか？ということ。
　これは、放送大学大学院の経営システム１でやってたけど（すみません、詳しいページは忘れました。今度調べて、書き直しておきます）、以下の５つ

　　１．物の流れ
　　２．金の流れ
　　３．情報のながれ
　　４．人の流れのうち、業務の役割の流れ
　　５．人の流れのうち、インセンティブの流れ

この５つの流れについて、問題なく流れれば、システムとなる。

---

　たとえば、今まで取り上げている夕食支援システムは、この流れで考えると崩壊する。
　つまり、ものの流れとしては、発注表を出すので問題ない。
　しかし、実際のシナリオを描いてみると、

■■　マクドナルドにて
１．夕食の発注表を担当の人が読み上げる
２．お店の人が、ご注文は、以上ですか？という
３．はいと答える
。。。このあと
４．お店の人のたまわく「お会計先によろしいですか」

がーん！お金を回収してないから、かえないじゃん！

つまり、夕食支援システムは、お金をどうするか（会社立替え？それともみんなから回収？）といった、「金の流れ」を決めない限り、このままでは、出来ないことになる。

---

　ちなみに、放送大学の、このビジネスモデルの考え方の鋭いところは、インセンティブのシステムについて、考えていること。
　これ、必要なければいいんだけど、代理店のシステムなんかだと、結構大切。
　インセンティブの設計なんかがいい加減だと、矛盾したシステムになり、毎月、計算して、発送した後で、「すみません、いまの計算、間違えてました！」などというお知らせを送らないといけなくなるので、注意っす。

---

っていうことで、やっと、次あたりから、「コピーされるほど儲かるシステム」の、要求仕様作成のための分析に入れそうです。

オブジェクト指向がシステム開発の難易度を絶望的に上げることを、阿多氏の発言は予言してたかも？

前のブログで、「成果物を出力するものまで規定できれば、開発は楽になるし、ユーザーも開発費は低減できる（が、実は、これをちゃんとやることは、無理。」の理由、昨日に続く第二段！

　最近のシステム開発論は、オブジェクト指向に傾いている。このオブジェクト指向に切り替わるときに、実はシステムの開発内容が大きく変わった。
　そのことを、久保田達也さんや、波頭亮さんが、出てくる企画バトル番組が、１０年以上前だったかなー？にあって、その番組に、昔のマイクソフトの社長（いまは、ソフトバンクＢＢの偉い人なのかな？）の阿多氏が出たことがあった。ちなみに、当時、阿多氏は、マーケティング部の人だったが。。。

　さらにちなみに、その番組のアシスタントは向井亜紀さん（だんなさんが、高田総統、で思い出した！このブログで、高田総統がインリンに小川直也と戦わせるって話書いたけど、結果は、インリンが勝ったらしい！？って、話を戻す）だった。

---

　で、その番組で、もう、発言した阿多氏も含め、だれも覚えてないと思うけど、そこで、おもしろいことを言ってだぞ！

　「それ以前の開発方法とちがって、最近（１０年前の最近＝オブジェクト指向）は、世界観全体を開発する」みたいなことをいってたんだ。

　つまり、いままでの開発というのは、開発したい部分を切り出して、そこだけ、入力と出力、開発に必要なロジックを切り出して、開発していた。いわば、システム開発できる部分を切り出して、開発していた。

　それに対して、オブジェクト指向っていうのは、モデル全体、そのモデルで表現される世界全体を開発してしまう、危険をはらんでいる。
　つまり、クラスをきってしまった場合、そのクラスが、出力にあんまり関係が無い話でも、どんどん深入りができる。
　ゲームプログラムなどでは、この深入りが面白いんだけど（登場人物のキャラクター、なんでそこまで決めるの？っていうやつ）、システム開発なんかだと、不必要なメソッドを作ったり（対称性を考えて、このメソッドを作っとこうとか）、不必要に深入りしたりする。

---

　具体例で、夕飯支援システムで考える。

　商品っていうクラスをきった場合、お店ごとに商品がちがうので、クラスとしては、商品クラスをつくって、その中に、マクドナルドの商品とか、石焼芋やの商品とかを派生させないと、うまく定義できない。
　で、マクドナルドの商品を、モデル化して、（セット商品とか、単品とかもわけて）それら、派生した商品それぞれに、発注するというメソッドを記述することになる。
　この商品、もちろん、お店によって、ぜんぜんちかうので、ＲＤＢでは定義できない。
　やるとしたら、ＸＭＬＤＢで定義するか。。。

　っていう感じになるけど、前のブログで書いたとおり、出力だけ考えたら、この商品、ここまで定義しなくていいし、そもそも、ＤＢにする必要ないのよ！

　でも、クラスとして認識されると、ここまで、モデル化しないと、いけなくなるのよね。

---

　結局、出力に関係ないクラス定義に忙殺されて、全体をモデル化しようとしちゃって、肝心の開発の難易度を、絶望的にあげてしまうのよ。
　今のマクドナルド商品クラスのようにね（マクドナルドの商品をクラスにして、注文メソッドを作るのって、難しいよ！うそだと思ったら、書いてみ！）。昔だと、目的のはっきりしてない開発は、出来なかったんだけど、オブジェクト指向の場合、クラスと戯れることで、開発している気になるのよ。さっきの例だと、マクドナルドの商品クラスの開発のようなのをやってると、開発してる気になるのよ。出力には、関係ないんだよ！。


　最近のＥＡとかも、全社的に考える場合、お金を生み出さないような不必要な部分を考慮するために、結構たいへんな作業になってしまう危険があるのよ。
　ＥＡを行う目的がはっきりしてないとね。