FrontPageでHTMLファイルで保存すると、Excelで開いてもExcelファイルで保存不可

　今回から「コピーされるほど儲かるシステム」の要求仕様作成に入ります。
　要求仕様作成作業は、まず、出力ファイルをもとに、作業できるかどうかを分析するということからは要ります。

　作業手順は、以下のとおり。
１．ホームページをＨＴＭＬで作成する
　　まあ、FrontPageで作りますか。。

２．そのファイルをFTPで送る
　　ＦＴＰで送る場合、ある時間が来たら、自動的に送りたいので、
　　２－１．以下の内容が書いてあるバッチファイルを作成し、それを、
　　　　　　(Win2000だと、コントロールに入っている）タスクに起動時間を登録します

　　　　　　内容は、以下のとおり
　　　　　　（スクリプトファイル名は、実際のスクリプトファイルのパスがはいる）

　　　　　　ftp -s:スクリプトファイル名

　　２－２．スクリプトファイルを作成します。geocitiesでやることにします
　　　　　　スクリプトファイルの内容は、以下の形で、送りたいファイル分、続けます
　　　　　　（ユーザー名、パスワードは実際のものを書きます。
　　　　　　　今回はindex.htmとsend1.htmをルートに送る例を書いてます）

スクリプトファイルの中身

　　　　　　　　open ftp.geocities.jp
　　　　　　　　ログイン名
　　　　　　　　パスワード
　　　　　　　　put index.htm
　　　　　　　　put send1.htm
　　　　　　　　quit

　　ちなみに、バッチファイルをコマンドプロンプトから起動したり、プログラム内部から
　　起動もできますので、それによって、ftpでファイル送信できます。

３．webにアップして、いろいろ作品ができたら、Excelファイルで読み込み、
　　パスワードを知らない人は、一部しか見れないけど、パスワードを知ってる人は
　　全部見えるファイルを作成します。

ということは、出力は、以下のものです
１．ＨＴＭＬファイル
２．ftpのバッチファイルと、スクリプトファイル（あとタスク）
３．作品用Excelファイル

---

では、作ってみましょう。
１．のＨＴＭＬファイルは、FrontPageでかんたんかんたんにつくれます。
２．のバッチファイルも順調です！
で、３．のExcelファイルを作ろうとしたときです。

　Excelを開き、１のＨＴＭＬファイルを読み込もうとしたら。。。
　読み込めない！
FrontPageが開いちゃうんです。なので、ここで保存してももともとのファイルが保存されるだけでExcelファイルに変換されないのです。。。。

　うーん、こまった。

　さあ、どうする（つづく）

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

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

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

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

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

---

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

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

---

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

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

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

---

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

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

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

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

---

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

---

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

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

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

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

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

---

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

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

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

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

---

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

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

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

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

---

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


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

開発論から考えると、成功哲学も多少は、意味あるかもしんない。（多少は、だよ ^^;)

　前のブログで、「ＰＭＢＯＫのスコープ計画とスコープ定義をまじめに捉えて、ここで成果物を出力するものまで規定できれば、開発は楽になるし、ユーザーも開発費は低減できる（が、実は、これをちゃんとやることは、無理。そのことは今後書いていくが、その方向にむかって、努力することは可能だ）。」って書いたけど、なんで、「ちゃんとやることが無理」なのかについて。

---

　実は、開発の初めに、
　　　最終的に、どんなシステムにするか、
　　　システムが出来たら、どういう風に利用するかということを、
　ユーザーが、イメージしていない場合が結構ある。

　最近のベンチャーや中小企業のおやじさん（社長さん）の中には、「もうかればいいんだ！」とか、「とにかくもうけさせろ」という話をする人もいる。
　そういう人にとって、会社が、儲かるかどうかが重要で（会社もシステムもマネーゲームの道具）、どんなシステムを作るかは興味が無いっていう場合もある。

　そこまで行かなくても、どんなシステムにするかを決めるのがＳＥの仕事というふうに考えている人もいる。
　（っていうことは、社長はＳＥの奴隷って言う意味になるし、社長の生きている意味ってあるのか？っていう問題になるんだけど、儲かればいいのよ、結局、その人はね）。

　そういう人に、どういうシステムを作りますか？って聞いても、「とにかく俺が、儲かるようにすればいいんだよ」といわれるだけだ（実はこの言葉、あるベンチャーの社長から言われた言葉だ　^^;)。

　

---

　普通の経営学の考え方だと、

　ビジネスモデルというのがあって、それをコンピューターなどを使って実現していくという形なんだけど、

　現実的に、そのビジネスモデルをやりたいから、会社をつくるとか、システムを開発するという人は、ごく少数で、

　まず、「金を儲けたい」という考えが先にあり、「そのためには、こんなビジネスモデルをすればいいんじゃないか」という方向で考える人がおおい。

　まず、こういう会社のシステムを開発すると、お金を切り取ることができない場合がおおい。
　（儲かんなかったら、仕様が実現できてない＝金を払わないという論理に陥る）

　なので、まあ、こういう開発は、やめておこう。
　でも、営業も、金儲けしたい人間だから、同じ人間を呼んじゃって、こういう人をユーザーで拾ってきちゃうのよね。

　ただ、そういう状態でも、「最終的こういう方向にもっていく」という像をありありと、自分の中で描いておくことは、システムの作り手としては、おさえておいたほうがいい。それが、「その方向にむかって、努力することは可能だ」と書いた意味。

---

　そこで思い出されるのが、成功哲学。

　成功哲学っていうと、ポジティブシンキングで、そこはウィリアムのいたずらは、「開発には使えない」と思っている。

　なぜななら、営業の場合、１００個の取引で断られても、１個の取引が成功すれば、営業としては成果ありということになる。その場合、めげないことが重要だ！だからポジティブシンキングが必要となる。必要な能力は、運鈍根といえる。
　ベテランとしての条件ともいえるかもしれない。

　しかし、開発の場合　、たとえ、１００個の開発が成功しても、１個の開発に失敗しただけで、すべての名声と信用を失い、利益も全部吐き出して、損失になるっていうことがあるよね、某大手コンピューター会社さん（某大学病院のこと (^^)v )
　必要な能力は、この場合、プロとしての条件だ。プロの条件はゴルゴ１３いわく

　１０％の才能と
　２０％の努力と　　（＝努力ではどうにもならないことがあるということ）
　３０％の臆病さと　（＝謙遜とリスクヘッジってことだとおもう）
　４０％の運だ

　なので、臆病さを持たない、ポジティブシンキングは、むしろ危険だ。

---

　ウィリアムのいたずらがいいたいのは、そこではなく、成功哲学では、最終目標をありありと描くようにする。ここが大切だ。システム開発でも、最終目標をありありと描くことが重要だ。
　そうすることにより、なにが必要か見えてくる。

　だから、「金を儲けたい」という中小企業のおやじの考えは、その時点で却下だ。
　いくら儲けて、どうなりたいのかを、語っていない。

　「女をはべらして、高級外車にのって、勝ち組みの景色が見えるマンションの最上階を買い取りたい」というのなら、「女を何人はべらすか」、「車は何を買うか」とか、具体的にブレイクダウンできる。そうすれば、いくら儲ければいいかが、くめる。

　そうすれば、「うーん、かたぎの商売では、もうけられないね。」とか、「株で、一発勝負を３回やれば（一発なの３発なの？？）」とか、やるべきことの議論は出来る（やるかどうかは別問題だよ）。


　だけど、ただ、「お金を儲けたい」では、どの規模のお金を儲けたいのか分からない。
　そのために、お金儲けの通論である、株を勧めたり、いまのビジネスの延長を勧めたりする。
　しかし、株は、ある一定以上の金額を投資しないと、儲からない（手数料で取られてしまう）。
　なので、結局、「金を儲けたい」っていう考えですら、「いくら儲けたい」という出力を先に考えることが重要で、それを放棄している以上、この客は、儲ける資格はないのだよ。

---

　ということで、システム開発でも、最終的な出力を、ありありと目の前に描くことが重要なのだ。で、それには、シナリオをつくったり、プロトタイプをつくったり、フィージビリティスタディやったりするんだけど、そういうことが重要だと言う人は、ユーザーにも、ＳＥにもいない。

　だから（システム開発も失敗するので）システム開発の本も売れるし、
　　　　（成功しないので）成功哲学の本が売れるんだけどね。

営業とコンサルの暴走による開発費高騰をＰＭＢＯＫで抑えられることは、あまり知られていない

　前回のブログで、「入力から分析してしまうと、大変なことになる。」と書いたことについて。
　システム開発を、入力や、開発の通論（業界の一般的なシステムの作り方とか）、パッケージソフトの利用から入ると、ものすごいオーバースペックになって、開発費が高騰したり、場合によっては開発できなくなったりしてしまう。

　これは、実例から入ったほうがわかりやすいので、まず、例を挙げます。

---

　おなじみ？？「夕食支援システム」において、
　これで、夕飯を出前してもらうのに、商品マスタが必要だ！というところで、商品マスタから入ると、大変なことになるのですよ！

　だって、お店によって、商品って、全然違うもん！

　マクドナルドに誰かが買いに行く場合
　　　１７クーポン利用１個
　　　（＝てりたまバーガー＋チキンフィレオ＋チキンマックナゲット＋ドリンクＭ２個）
　　　　　　ナゲットは、マスタード
　　　　　　ドリンクは、ホットコーヒーで砂糖とミルクつき
　　　　　　　　　　　　とコカコーラ

　それと、石焼いもの屋台
　　　Ａさんは、やきいも小３個
　　　Ｂさんは、５００グラム
　　　Ｃさんは、やきいも１０００円分
　（どうも、焼き芋やさんって、グラムでも、個数でも金額でもかえるみたい。。。経験値より）

　それと吉野家の豚ドン、大もりつゆだくで。

っていうのを、マスターにしろ！っていわれたらどーする(^^;)

　１つのお店、一つの商品でも、単位が違うし（石焼き芋のケース）、セットだとしても、いろんなバラエティがあるし、クーポンもある、さらに、吉野家の豚ドンにいちゃっては、マスターにはのってない注文もできちゃう（つゆだくとか）。

　で、このマスター設計から入ると、暗礁にのっちゃうんですよ。

---

　実は、これ、出力から考えると、かんたんです。

　実は、この商品マスターって、ＤＢにいれなくってもいいんです。
　最終的には、発注表をみて、発注ができれば、
　商品マスタは、なくったって、いいんです。

　つまりですね、ショッピングカートで、商品マスタＤＢを持たない形式っていうのがありますが、
あれと同じように、発注時に、発注用の商品名と数量、金額を受け取り、それをＤＢに入れるようにします。
　ユーザーは（Webかなんかで）商品を選択していって、発注ボタンを押すと、発注用の商品名をjavascriptで作るようにします。
　そうすると、各お店ごとにＷｅｂページをつくって、夕食の商品と数量が選択できるようにして、発注するとき、発注用の商品名と数量、金額を受け取るようにすればいいのです（そのインターフェースは共通化する）
　うーん、わかりにくいけど、わかったかな。

　用は、どんな商品でもかまわなくって、商品マスタを持たないかたちのショッピングモールのＣＧＩを利用すればできるってことなんだけど。

---

　でも、入力から入って、商品マスタを作ろうとすると、まあ、この共通の商品マスタっていうのはできないし、通論から入ると、この手のＷｅｂサイトのマスタは、全部ＲＤＢに入れて作るので、かなり複雑なＤＢ構造になってしまう。

　でも、結果から考えると、これって、フリーソフトの（ＤＢを持たない形の）ショッピングモールのＣＧＩと同じ作りとわかる。
　さらに、もし、そのフリーソフトのＣＧＩを利用するとなれば、すぐに取り組めて、開発費は、ただ（は極論だけど、フリーソフト利用だから、相当金額は低い）はずだ！

---

　営業さんとか、コンサルの場合、こういうシステムは、こういうソリューションという通論を持っていて（たとえば、ＣＲＭなら、当社のなんとかパッケージ、ＥＲＰなら当社のＥＲＰソリューション）、それを売りつけようとするわけよ。
　そうすると、そんなのいらなくても（オーバースペックになっても）それ（＝自社の売り物商品）にあわせるから、開発費は高騰したりするのね。

　また、コンサルを頼む場合、お客さんの出力に合わせるというより、知識を売り物にして、「これは、こうあるべき」論で考えることが多い。そうすると、入力のマスタから「こうあるべき」で定義しちゃうのね。

　たとえば、商品マスタは、こういう機能をもつべきとかね。。。
　そうすると、（今回の夕食支援システムのように）出力から考えたら、商品マスタなんて、どうでもいいような場合でも、りっぱなものを作ろうとして、結局、開発費高騰なんてことになりかねない。

---

　じつは、こういう事態を避けるため、ＰＭＢＯＫでは、スコープ計画で、「成果物」を定義し、スコープ定義で、「成果物を実現する」方法を考える。
　たとえば、さっきの夕飯支援システムなら、成果物の毎日の発注表を作るため、それを実現する方法ということで、フリーソフトのＣＧＩ利用でもＯＫなわけ。

　でも、ふつう、この成果物って、そこまで考えないで、「成果物は、バイナリとドキュメントでドキュメントは要求仕様書と、画面設計書とファイル設計書」などという形式だけしか考えないので、あんまり役にたたず、こういう開発時高騰をまねくわけよ。

　だから、ＰＭＢＯＫのスコープ計画とスコープ定義をまじめに捉えて、ここで成果物を出力するものまで規定できれば、開発は楽になるし、ユーザーも開発費は低減できる（が、実は、これをちゃんとやることは、無理。そのことは今後書いていくが、その方向にむかって、努力することは可能だ）。

---

　いいかえると、（うるぐすディスカバリー風にいうと）　営業とコンサルの暴走による開発費高騰は、ＰＭＢＯＫのスコープ計画で、成果物を具体的に定義して、それに基づいて入力を考え、スコープ計画をたてれば抑えられることは、あまり知られていない。

ＵＭＬの問題に対する解決策は、９０年代のシステム開発論を否定することによって、葬り去られた

　昨日のブログで、ＵＭＬを使ってヒアリングからＪａｖａプログラムまでの作成の流れについて書きました（ここ）。で、その手順では問題があることも、このブログの後半の「夕食支援システム」で説明しました。

　そして、そのため、要求分析は、帳票定義からはじめたほうが良いということも、すでにブログに書いています（ここ）。
　きょうは、そのブログに書いてある、「いろんな帳票やドキュメントをもらってきて、それをてきとーに整理して。。。といろいろな作業がある。これは、別の機会に取り上げよう。」についての話。

---

　まず、プロジェクトが始まると、（提案後はもちろん、提案前から）いろんな資料を、ユーザーからいただきます。

　問題は、この資料の何から見て、どう整理するかについて。

　整理の仕方については、帳票や画面のドキュメントから、最終的にはＥＲ図を作っていくわけですが、これについては、佐藤正美先生がやり方を示しているっていうことは、さっきのブログに書いてある。

　具体的な方法は、佐藤先生の著書、

データ設計の方法：数学の基礎とT字形ER手法 論理データベース論考
佐藤 正美著　 SRC　 ISBN 4-88373-134-0

の１７６ページから１７９ページあたりから書いてある。
　命題論理方式、コード体系方式から、エンティティを切り出せばよい
　（なお、この本は、このページの、右側の図から、通してみたほうがいい。
　　この前のページの数学の部分は、良くわかんない割に、わかんなくっても、作業は可能です）

　しかし、この本を読んでも、どの帳票、あるいは画面から分析すればよいのかは、書いていない。

---

　ここまでを、整理しよう。

　ＵＭＬの手法は確立されているが、業務分析から入る場合、業務分析できないものがある。

　それらは、帳票分析によって、業務分析を推測したり、補足することでシステム化可能だ。

　帳票分析についての手法は、佐藤氏の手法を参考にすれば出来る。

　問題は、ただ一点、その際、どの帳票から手をつければよいかだ。
　これが決まれば、一挙に手法は自動化できる。

---

　実は、どの帳票から手をつけたらいいかということは、９０年代には分かっていた。が、その後、ＵＭＬの到来により、葬り去られてしまった。
　９０年代まで、分析の主流はＤＦＤで行っていた。このＤＦＤの提唱者デマルゴによってかかれて本の和訳が、以下の本である。

構造化分析とシステム仕様
トム・デマルコ　著／高梨智弘、黒田純一郎　訳
ISBN 4-8227-1004-1 日経BP社

　この本の９５ページをみてほしい。

　ＤＦＤの場合、分析のスタート、つまり最上層のダイヤグラム（図）は、コンテキストダイヤグラムと呼ばれる。コンテキストダイアグラムは、システム全体をあらわす真中の楕円、その楕円に矢印で、システム外部からの（外部への）入出力が書かれる。
　つまり、はじめの分析対象は、システム外部に対する入出力ということになり、とくに、ＰＭＢＯＫの関係で言えば、成果物となるシステム（スコープ計画で、成果物は定義されているはず）の出力から分析することになる。

　簡単に言うと、出力から分析しましょう！！

---

　で、出力をどう整理するのか、佐藤氏の本を読んでいただければいい。

　ここでは、それを理解してエンティティが切り出せたとしよう
　（っていうか、ＵＭＬの本なんかだと、そこの操作、なにもかいてないで、エンティティが切り出せることになってるけど ^^;)。

　そうすると、
　　２つ以上のエンティティが結びついている場合、
　　　その対応表（または対照表かな）が必要となり、
　　その対応関係が永続的でなければ、
　　　時間が関係する、
　　　　すなわちイベントということになる。

　　イベントを行うって言うことは、
　　　業務として行っているということなわけで、
　　ここで、ヒアリングからでてきた、業務と照らし合わせることで、
　　　成果物を作成するのに必要な業務が分析できているかどうかわかる
　　　これが出来ていれば、あとはＵＭＬの手順でプログラムまで落とせる。

---

　
　　つまり、出力内容からエンティティとその関係を切り出し、そのエンティティの関係が永続的かどうかで、イベント（とリソース）に分けることが出来、イベントがあるということは、そこに業務があるということが推測できる。
　その業務が存在するかどうかを、ヒアリングで確かめることになる。
　そして、ヒアリングのほうで、業務がでてくれば、
あとはこのまえのＵＭＬの手順に従い、クラスに分けられる。
そのクラスのうち、データソースになるものは、エンティティのリソースになっているはず。
　そのことにより、ヒアリング内容がただしいか、十分かの判断が出来るってわけ。

　おー、話がおそろしく抽象論になったぞ！
　具体的な例をあげよう

---

　「夕食支援システム」において、出力は、
　　　　ゆうごはん　　または、　　ゆうごはんの出前をする発注表である
　　（どっちにするかは、システムの発注者との話し合いになる）

　仮に、発注表だとすると、その発注表には
　　社員ＮＯ
　　出前を頼む先のお店（のＩＤ？）
　　頼むもの（商品）とその数
　が記入されているはずである。

　ここから、エンティティは、社員、お店、商品があることがわかる。
　そして、これらが結びついて、発注になっている。

　ここで具体的に
　　　商品＝月見照り焼きバーガー
　　　社員＝ウィリアムのいたずら
　と考えると、ウィリアムのいたずらは、つねに「月見照り焼きバーガー」ではないので、（あれは期間限定って、そういう意味ではなく、ある日の夕食がたまたま月見照り焼きバーガーなだけという意味）ここに、日時が介在するはずである、つまり、発注という行為は、イベントである。

　そう考えると、発注という業務があるはずと考えられる。ヒアリングでは、発注をどうしようか？ということを考えることになる。
　もちろん、発注データ自体には、ＣＲＵＤ（クルド人ではないよ！）が存在するはずなので、発注という生成行為（＝業務）だけでなく、発注訂正（キャンセルとか数量変え）、発注削除（は、自動的だね。出前しちゃえば、もういらない）、発注検索（社員が検索するのと、この場合、お店に電話するための検索、つまり発注表作成が考えられるね）という業務も存在することが予想できる。

　一方、商品、社員、お店というデータは、業務では作成されないので、これらは、マスタとして、アプリオリに存在しなければならない。
　したがって、これらのマスタのＣＲＵＤも、考えなくてはならないが、「業務として意識されていないので」ヒアリングからでは、出てこないだろう（こういう、マスタ作成業務って、ヒアリングで出てこないので、作業から抜けやすいんだよね！）

---

　と、こういうふうに分析できる。

　だから、出力から分析したほうがいいんだよね。

　なお、これを、入力から分析してしまうと、大変なことになる。
　それは、また、別の機会に

昨日のブログの修正。ＷＢＳをめぐるあれこれ

昨日のブログ「ＷＢＳとスコープと要素技術とＲＦＰ」で書いたことの一部修正とか、訂正。

　まず、「ＷＢＳに書きますが、ウィリアムのいたずらは、その作業を省略してしまっているので」って書いてしまったけど、じゃあ、ＷＢＳを書かないで、どーするの？っていう話。
　これは、スケジュール表で代用してます。
　
　「プロジェクト計画書に書かなくてはいけないこと、省いて手抜きできるとこ」で、のとはら先生のやつに、

　　　　　４.プロジェクト全体作業フロー
　　　　　（中略）
　　　　　８.プロジェクトスケジュール

ってある。ＰＭＢＯＫにも

　　　　　え・ＷＢＳ（コントロールレベルまで）
　　　　　お・（ＷＢＳに対する）コスト見積もり、スケジュール、責任分担

ってある。

　そこで、「スケジュール表の項目を書いた場合、ＷＢＳが想像できるものは、スケジュール表をいきなり書いて省略しています」という意味です。

　とくに、スケジュール表をガントチャートで書くとき、一番左の見出し部分に、その作業内容を書きますが、その作業内容（見出し部分）を見れば、どういう行動をすればいいのか分かる場合（その項目を見ればＷＢＳが自動的にかけるから）、書かないという意味です。

たとえば、ＷＢＳとして、こんな表形式で書く人がいます。
　ウィリアムのいたずらの場合は、この表形式の右側に、年月の線表を書いて、ガントチャートにして、スケジュール表として出して、ＷＢＳの図は、省略することが多いですね。

　ＷＢＳの「図を書かない」という意味であって、（クラスが思いついたとしても、そこから）作業を考える→スケジュールに入っていくという頭のなかの流れは、踏んでいます。

---

　あと、「なにをやったらいいのか、わかんない場合、ＷＢＳに分解して、安心しちゃうっていう危険もあるのよね。」って、文章的に変でしょ！と思うかもしれない。

　なぜなら、コントロールレベルまでＷＢＳを落とす
　　っていうことは、行動できる範囲にまで、落とすっていうことだから
　　なにをやったらいいかわかんないわけ無いじゃん！

　っていう話。お話は、もっともっす。

　ここ、書き方が悪かったです。
　書きたかったことは、

　「その要件を満たすために、やるべきことの全てがわかっていない、
　　　　つまり、「なにをやるべきなのか」分かっていないときでも、
　　ＷＢＳに分解して、行動できるレベルに落としてしまうと、
　　なんとなく、その作業をやれば、できるような気分になってしまう
　　　　＝結果として、漏れが出てきたり、出来なかったりする危険もあるよね」

　という意味です。

　例を出します。

　前の、「ヒアリングからＵＭＬのドキュメントを作成、Javaのクラス作成までを半自動化で行う手順」をみると、これで、システム設計は完璧！のように思えるよね。
　で、これをＷＢＳに書けば、すぐ行動に移せる。バッチリです。

　じゃあ、システムを作ってみましょう。

　夕食支援システムを開発します。
　社内従業員の夕食のために、出前を取るシステムです。
　今後、残業が多そうなので。

　業務手順を洗い出しましょう。ヒアリングです。
　「夕食は、どのように決めていますか？」
　「いやー、今、残業無くって、うちに帰って毎日食べているので、奥さんが決めています。」
　。。。このヒアリング終了です。

　今やってないことの業務手順は、答えられません（わかんないです）
　でも、システム開発は、将来のために作ることも多いです（今やってない業務の開発）
　極端な例だけど、こういうお間抜けな行動内容をＷＢＳで作っちゃうことがあるわけ。
　例えば、「用語を調べる」って、必要ない用語を一生懸命調べて用語集作っちゃったり、
　意味の無い業務分析をしてみたり。
　で、肝心の部分の業務分析が抜けていても、ＷＢＳ上、見てもわかんないことがあるのよ。

　でもでも、ＷＢＳをつくって、なんとなく、仕事していると安心してしまうっていうことがあるのよね。という意味です。

ヒアリングからＵＭＬのドキュメントを作成、Javaのクラス作成までを半自動化で行う手順

　前に、「このヒアリングをもとに、」（以下中略）「クラス図がかけ、ＵＭＬのドキュメントに変形できる。」と、ヒアリングからＵＭＬのドキュメントまで自動的に書けるような感じの話を、ブログに書きましたが（ここです）この、「ヒアリングからＵＭＬのドキュメントを作成し、Ｊａｖａのクラスをきるまでの自動的な流れ」について、まとめて書いておきます。

　この方法は、以下の本にかかれています。
　ＵＭＬシステム設計実践技大全―アッと驚く達人の技
　ISBN:4-8163-3635-4
　２１５ｐ　２４×１９ｃｍ　ナツメ社 (2004-01-06出版)
　　長瀬　嘉秀・橋本　大輔【監修】・テクノロジックアート・Ｃ＆Ｒ研究所【著】


　今回は、その本の表題などを抜書き、まとめて、半自動的に作成する手続き（流れ）を見やすくしました。この流れ、実は、このブログのあとで、つかうもんで。
　実際にこの流れどおりやると問題はあるものの（その問題と解決法は、後日、ブログで書きます）、この本が、一番良くまとまっていると思います。うだうだ理屈をこねるより、この本買ってきて、徹底的に読んだほうが、絶対いいと思うぞ！

じゃあ、以下、おまちかね、その「ヒアリングからＵＭＬのドキュメントを作成し、Ｊａｖａのクラスをつくるまでの流れ」を書きますね（括弧内は、その本に書かれてるページ数）。

---

１．モデルの対象決定（Ｐ５４～）
　目的をベースにモデルの対象を分割する

２．業務手順をアクティビティで表現（Ｐ５９～）
　ヒアリングから業務手順を表現する
　事前条件、事後条件を表現する
　スイムレーンでアクティビティの担当者を整理する
　分岐する業務、並行する業務を表現する
　ビジネスプロセスの大きさを調整する

３．アクティビティ図からユースケース図を作成する（Ｐ７２～）
　システム化範囲の設定
　ユースケースの抽出
　アクタの抽出
　関連の抽出
　ユースケースの粒度の調整

４．ユースケースからシナリオを作成する（Ｐ８０～）
　具体化する

５．ユースケースからオブジェクト図を作成する（Ｐ９４～）
　シナリオから名詞を抽出する
　名詞からオブジェクトを抽出する
　オブジェクトに属性をつける
　オブジェクトと属性にリンクをはり、オブジェクト図を作る

６．オブジェクト図からクラス図を作る（Ｐ９８～）
　オブジェクトを抽象化し、クラスにする
　クラスの関連をオブジェクトのリンクから設定する
　多重度の設定をする

７．シナリオからシーケンス図を作る（Ｐ１１４～）
　シナリオから、アクタとオブジェクトを抽出する
　プレゼンテーション、ドメインクラスの導入をする
　メッセージを追加する
　オブジェクトの生成と破棄を追加する

８．クラス図とシーケンス図から設計クラス図を作る（Ｐ１２５～）
　操作（メソッド）を入れる
　可視性(public とか privateとか）をいれる
　プレゼンテーション、ドメインの追加

９．クラス図からjavaへ（Ｐ１４１～）
　クラス定義
　属性定義
　操作を実装（中身はコメントになるけど）
　クラス間の関係を実装

---

　言葉の意味とか、具体的な内容を知りたかったら、本屋さんにＧＯ！
　「ＵＭＬシステム設計実践技大全」の該当ページをみてくれ！
　そうすれば、やることは、分かると思う。

ＷＢＳとスコープと要素技術とＲＦＰ

　「業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実」で、プロジェクトの始まりを、こんなふうに書きました。
（１）スコープ計画
（２）スコープ定義
（３）アクティビティ定義
　　　：（以下省略）

で、普通の本をみると、この（２）のところで、ＷＢＳと要素分析とか、作業分解という話がかならず出てくる。たとえば、こことか、こことか。。。

　でも、ウィリアムのいたずらは、見積もりのとき、はじめに要素に分解したあと、ＷＢＳを書いていない。なぜか。。。

---

　まず、WBSは、書いたほうがいい。しかし、小さいシステムの場合、クラスが決まれば、やるべきことが標準として決まっていて、さらに、ＲＦＰと納品物から、クラスが明確にわかってしまう場合、わざわざＷＢＳを書かなくてもいいかな、というか、実際には、書いてないと思う。

　つまり、（１）のスコープ計画で、納品物とかが決まる。
　この、納品物を決めるということは、絶対しないとまずいでしょ。
　これは省略不可。

　で、その納品物を作るために、どうするかということを考えるのが、（２）のスコープ定義ということになると思う。そして、その（２）の作業の検討結果をＷＢＳで表現するということになると思う。

　でも、ＲＦＰで、ほしいもの（成果物＝出力）が明確にわかっていて、入力画面が決まっちゃう場合、ＳＥさんの頭の中に、オブジェクトが切れてしまう（＝クラス図（とＥＲ図）ができてしまう）場合があるのよ（これが「読みきった」という状態。ウィリアムのいたずらの場合、読みきった仕事を受けるのが、ふつう。フリーの場合、そうでないと、仕事が出来ない可能性があるので危険）。

　で、オブジェクトがきれて、クラスわけまでいっちゃうと、そのクラスを、分析する→つくる→テストするっていうのが、作業になる。つまり、クラス図（とＥＲ図）が自動的に頭の中に広がっちゃうと、そのクラス図（とＥＲ図）を元に全作業工程が、わかってしまうので、その場合、ＷＢＳをわざわざ作るか？それとも、もう、クラス（プログラムに発展）とエンティティ（＝これがＤＢに発展）ごとに管理したほうが早いじゃん！っていうことになっちゃうのよ。それが、よいか悪いかは別にしてね。

　で、ウィリアムのいたずらなど、ＳＥさんの場合、そういう状態のとき、ＷＢＳをわざわざ書くかあ？っていうことになる。でも、プロジェクトマネージャーさんは、きっと書いてほしいんだろうね。つーか、書くべきだ。見落としとかもあるかもしんないし。

　一方、なにをやったらいいのか、わかんない場合、ＷＢＳに分解して、安心しちゃうっていう危険もあるのよね。たとえば、ここに書いてある最後の図って、ＷＢＳに割ってあっても、何も言っていないのと同じでしょ。なにやったらいいか、よくわかんないもん。

---

　っていうわけで、本来は、（１）のスコープ計画で成果物を定義した後、その成果物をつくるための要素に分解し、作業範囲と内容をきめ、その結果をＷＢＳに書きますが、ウィリアムのいたずらは、その作業を省略してしまっているので、今回も省略しましたというだけの話です。本当は、やったほうがいいんだろうね（つーか、やるべきだ）。

　ただ逆にＷＢＳにかけたからといって、必ずしも作業に入れるほど分解されているとは限らない（さっきのよくわかんないやつのケース）し、作業がスムーズに進むとも限らない。その点は注意ですな。

ＲＦＰと提案内容が違う場合の対処法－ウィリアムのいたずらの場合

前のブログで、今後、以下の３つの話題を書くといいました。

　　１つは、プロジェクト計画書に書くこと、
　　２つは、ＷＢＳとスコープと要素技術とＲＦＰ、
　　３つは、ＲＦＰと提案内容が違う場合の対処法

　１つめの「プロジェクト計画書に書くこと」は、このブログと、このブログでとりあげました。

　３つめの「ＲＦＰと提案内容が違う場合の対処法」について、このブログの後半で書いているんだけど、はっきりとしてないので、ここでまとめます

---

　ＲＦＰは、「提案依頼書」だから、これに基づき、提案するのは前提なのですが、以下の場合、ＲＦＰとは提案内容を、変えて書きたい場合があります。

１．会社のきまりで、こういうときは、こういう提案と決まっているので、ＲＦＰの提案依頼を満たせない
　→コンサルティングファームなどで、売り物が決まっている場合。
　　ただし、そういう場合、提案のしかたもたいてい決まっているので、まあ、そのやり方に従ってください。ここでの話の対象ではありません。

２．ＲＦＰを満たすことが、会社のためにならない
　→もっと、安い提案がある場合とか

３．そもそも、ＲＦＰの内容は実現できないので、これを満たす提案がありえない。
　→ユーザーが身の程知らずの場合のＲＦＰとか、キーワードを並べただけのときにある。
　　サーバーってなに？っていう状態のユーザーが、自分で、ＷｅｂとＤＢを管理してＥＣサイトを作りたいとか。

こんなとき（２．３の場合）、どうするか。

---

　はじめから自分の案を書くことは、まずいです。お客さんがついていけません。
　そこで、
（１）まずはじめにお客さんの案でやると、こうなる（こういう問題が出る）
（２）「そこで」、「ところが」、などの接続詞をいれ、話を転換させる
（３）あとは、自分の提案を書く

というスタイルになると思います。
　こういう感じであれば、自分の案を提案することも可能と思います。

---

　で、この場合、（１）が実現可能である場合、（３）を自分が提案したいのに、（１）になってしまうことがあります。（３）になることも、もちろんあります。
　それは、出たとこ勝負です。ただ、（３）のほうが後に言うし、「ところが」とかいって、話をひっくり返すわけなので、（３）のほうが、有力とは思いますが。。。

　まあ、どっちにころぶかは、わかんないっすね。

---

　なお、「コピーされるほど儲かるシステム」第１４話で、２つの案をあげ、あとから出てきた案に勝手に決まるところがありましたが、そこは、上記のような提案をして、後の方に決まったと考えてくださいませ。

---

ということで、「ＲＦＰと提案内容が違う場合の対処法」も終わったこととします。
のこるは、「ＷＢＳとスコープと要素技術とＲＦＰ」ですね。

要件定義は何からはじめるか－世代の断絶が、業界の病理と開発の教祖を生み出した

　要件定義には、どのようなやり方があるか。
　「要件プロセス完全修得法」
スザンヌ・ロバートソン＋ ジェームズ・ロバートソン／著　苅部英司／訳
http://www.sangensha.co.jp/allbooks/index/111.htm
のＰ１００～Ｐ１１４に、そのやり方が、以下のように書かれている
１．徒弟制度
２．ユーザーとのインタビュー
３．ビジネス事象ワークショップ（シナリオを含む）
４．ブレインストーミング
５．マインドマップ
６．ビデオ
７．電子的要件収集法
８．文書考古学
９．スノーカード

　問題は、この中で、何からはじめるのかが明記されていないことだ。
　これでは、勉強のやり方を列挙して、教育ママ（ふる！）に「勉強しなさい」としかられているようなもんだ。
　出さなきゃいけない成果はわかってる（勉強の場合、宿題を終わらすとか、テストでいい点ｗ撮るとか、システム開発なら、要件定義書とかユースケースとか）。でも、どの順番で、やったらいいのか分からなければ、いくらしかられても、手をつけられない。

　で、わからない結果、どうするか。。。
　一番非効率な方法を、なぜかとってしまうのだ。それは、いきなり
　２．ユーザーとのインタビュー（ヒアリング）
　からはいる。
　でも、何をきいたらいいかわかんない。その結果、ユーザーへのコーチング、愚痴を聞くカウンセリングや、あたりまえの用語を説明してもらう勉強会になってしまう。
　これを続けると、ユーザーは、「本当に出来るのか」と不安になる（ひどいと、聞いてるＳＥ自身が、「先が見えない、できるのかなあ？？」と思ってしまう）
　結果として、関係が悪くなり、見切り発車状態で、ヒアリングを終えて、開発に入らなければならなくなる。

---

　では、どこから手をつけるのか。それは、ずばり、
８．文書考古学
からだ。これは、昔、帳票分析と呼ばれていたものだ。
　やり方は、上記の「要件プロセス完全修得法」のＰ１１１～１１２に書かれている。
　ドキュメントから名詞を取り出し、その名詞からエンティティを抽出するってこと。
　この方法は、まさに、佐藤正美氏のＴ字型ＥＲ図の作り方と同じだ。なんで、詳しくは、佐藤正美氏の（早稲田のエクステンションセンターなんかの）講義とか、著作を参考にして欲しい。
　ウィリアムのいたずらからより、直接本人から聞いたほうがいいだろう。名講義だ！

　ただ、そこまでやらなくても、このブログの「ＵＭＬでやりにくいもの。確定申告を例に」プラスアルファでＯＫだ。
　ただし、実際にやるには、まず、いろんな帳票やドキュメントをもらってきて、それをてきとーに整理して。。。といろいろな作業がある。これは、別の機会に取り上げよう。

　そして、帳票からわからない言葉を取り出し、帳票が出来る手順を（確定申告の例のように）追っていく。ヒアリングのときは、この分からない用語の確認や、帳票ができる手順にそって、物とかねの流れを追い、さらにそこに対する担当者を聞く。
　（ただ、ここまでできれば、あらかじめ質問紙の形でヒアリング内容を事前にまとめておき、ユーザーに見てもらうことが出来る。そのほうが、ヒアリングしやすい）

　で、あとは、このヒアリングをもとに、物、金、帳票等のに関する動詞を取り出し、プロセスとし、そのプロセスと、情報や物、金、人（＝データの源泉か、データになる）を図示すると、ＤＦＤが出来てくる。ＤＦＤのプロセスからメソッドを取り出すとユースケースがかけるし、ＤＦＤのデータ（エンティティ化していることが多い）とプロセスを適当にまとめると、クラス図がかけ、ＵＭＬのドキュメントに変形できる。

---

　問題はこの流れ、つまり、ドキュメントをみて、ヒアリングの下準備をするという仕事のやり方をおさえているかどうかだ。
　むかしの８０年代のＳＥは、帳票分析というのを、よくやらされた。私たちの世代も、そのやり方を受け継いだ。
　しかし９０年代、オフコンの文化が否定されて、このやり方自体が否定されてしまった。
　（ちなみにＣＯＢＯＬ文化も全否定された。この結果の弊害も大きいが、今回は、それを書ききれるほどひまでないので省略）

　その結果、新しいＤＯＡからオブジェクト指向の考え方が正しいということになり、このやり方で世の中がやるようになってきた。しかし、オブジェクト指向の問題点は、ユーザーが、ヒアリングで必要な情報をしゃべってくれるということを、暗黙の了解にしていることだ。
　でも、ユーザーは、必要な情報はなにか、分からない。

　うそーと思う人へ。あなた、少なくとも一生のうちに１度以上、夕飯食べましたよね。
　さて、質問です。夕飯って、どうやって、決定されるんでしょう？
　必要な情報を、「すべて挙げなさい」
　無理でしょ。家に帰る場合、外食の場合、夕飯抜きの場合。。。
　全てのケースどころか、なにから話していいか、体系すら、語れないでしょ。
　ユーザーの状況って、そんなもんなんですよ。

　だから、下準備が必要なわけで、その下準備の方法がわかんないと、仕事が進められないわけ

---

　ところが、世間はＵＭＬの提唱者やエバンジェリスト（広める人のことね）を教祖のようにあがめ、一流企業の研究者や管理職は、その教祖の主張を全面的に受け入れて、これができれば、システム開発ができるように思い込んじゃってるのよ。

　だから、「要件仕様はＵＭＬのユースケースで入れましょう！」ってなると、管理職は部下に、ＵＭＬの書き方とか、ＵＭＬの試験とかにお金をだすだけで、どうやったら、もらった資料から、ヒアリングにもっていけて、さらにそこから、ユースケースがかけるのかの、一連の作業の流れを教えない（ヒアリングからメソッドを出す手法はＯＭＴでは言われてたんだけど、ＵＭＬになるときに、その手法は、なぜか伝えられなくなった）。

　結局そのため、部下は一生懸命がんばっても、どうやったらいいのかわかんなくって、精神的に（うつ病とかで）まいってしまう。
　その一方、開発論の提唱者は、教祖的に「この方法でやるといい！」って訴えて、みんな信じちゃうのよ（この下準備の部分を説明してもらえば、理性でわかるんだけど、その部分を説明しない限り、感性で信じ込むしかない＝教祖化する）。
　つまり、下準備からの一連の流れを教えなくなった、技術の断絶が、業界の病理と開発の教祖を生み出したといえるね。

　で肝心の、下準備からの一連の流れを、このブログで。。

　取り上げられるようだったら取り上げようと思う。。。

プロジェクト計画書に書かなくてはいけないこと、省いて手抜きできるとこ

　前に、プロジェクト計画書に書くことっていうのでＰＭＢＯＫの内容を書いた。
　そこで、「実際にかく場合の問題とかは、べつに書きます」って書いた。
　今日はその話。

　実際に書く場合の問題は、以下のとおり
　・プロジェクト計画書って、実際に書こうとしたとき、人によって書く内容が違う。
　・プロジェクト計画書を書こうとしたとき、ＰＭＢＯＫのいったとおりにかけない点
　　→その時点では、決まっていないことがある

---

　はじめの、「人によって書く内容が違う」例としては、日経システム構築　２００５年２月号「のとはら先生の実践！プロジェクトマネジメント指南」の１４３ページがあげられる。
　ここでは、（解答として）以下の項目を、プロジェクトマネジメント計画書として、書くこととしている。

１.プロジェクト目的
２.プロジェクト範囲
３.プロジェクト制約事項
４.プロジェクト全体作業フロー
５.プロジェクト成果物リスト
６.プロジェクト標準
７.アプローチ
８.プロジェクトスケジュール
９.プロジェクト必要資源
１０.プロジェクト体制
１１.プロジェクト予算
１２.プロジェクトリスク評価
１３.品質目標
１４.プロジェクトチーム目標

PMBOKの場合は以下のとおり（ここを参照）

あ・プロジェクト憲章
い・プロジェクトマネジメントの方法や戦略
う・スコープ記述書
え・ＷＢＳ（コントロールレベルまで）
お・（ＷＢＳに対する）コスト見積もり、スケジュール、責任分担
か・技術スコープ、スケジュールのベースライン、コストのベースライン
き・主要マイルストーンと目標期日
く・主要スタッフ、予想コスト、作業工数
け・リスクマネジメント計画書
こ・固有のマネジメント計画書
さ・未決課題と未解決事項
し・詳細資料

書く内容や順番、使っている言葉も違う。実際、書く内容も異なるところがある。

---

　では、実際に両方を比較しながら、「ＰＭＢＯＫのいったとおりにかけ」るかどうか、みてみよう。
　（あ）プロジェクト憲章（意味は、ここを参照）は、見せられない場合や、プロジェクト計画書作成時には、決まっていないことが多い。
　だから、これは、のとはら先生のとおり、（１）プロジェクト目的と、（５）プロジェクト成果物リストで逃げたほうがいい。そこを突っ込んでくくる人はまずいないだろう。。

　（い）は、のとはら先生の（７）に相当

　（う）スコープ記述書と（え）ＷＢＳはこの時点でかけるなら、書いたほうがいい。かけない場合、のとはら先生の（２）、（４）のように、全体フローを「ぼやっと」書いて逃げる手もある。
　（３）の制約は、入れておいたほうがいい（ＰＩＭＢＯＫで何で入ってないのかわかんないけど、（か）か（け）に入れるつもりかな？）

　（６）は、のとはら先生、強調してたけど、ＰＭＢＯＫに明示されていない（（こ）が近いのかな？）。
　現場的には、プロジェクト計画書を書く時点で、会社として、どういうドキュメントを書くか、決まっている場合は、その（決まっている）資料の書き方を添付（あるいはどこどこ参照と）明示しておけばＯＫな話。
　でも、多くのケースで、ドキュメント標準やプロジェクト標準は、この時点では、かけない（もっと後で、走りながら決まる。それがいいことか、悪いことかは別として）なので、（６）は、「書ければ」の話。

　のとはら先生の（８）から（１１）は、ＰＩＭＢＯＫの（か）から（く）みたいな感じでＯＫだと思う

リスク評価はどちらにも入っている。これは必要だと思う

　品質管理とプロジェクトチーム目標はあるに越したことはないが、実際にはこの時点でかけないことが多い。これが書けないから、プロジェクト計画書がかけないとするくらいなら、この部分を書かないで、発行したほうがいいと思う。
　ＰＭＢＯＫの（こ）から（し）も同様で、あるに越したことはないが、それが書けるのを待つくらいなら、適当な線で切って、プロジェクト計画書を発行したほうがいい。
　この部分、かけなければ、なくても計画書として成立してしまうものだと思う。

---

　ということで、現実的に書ける部分、書いておきたい部分をあげると、

(A)目的（当たり障りのない範囲）と、成果物（作成標準がある場合、それも明記）、
(B)作業範囲範囲と、その順番（わかる範囲で）、
(C)スケジュール、費用、体制、予算（わかる範囲で）、
(D)リスクと制約（どこが読みきれていないのか？）
(Z)戦略、アプローチ、品質目標などあれば、かいてもＯＫ

　これだけそろっていれば、計画書としては、ＯＫじゃーないの、実際、ここしか見ないでしょ。みんな(^^;)

　現実的には、あとは、会社の規約や、その道の権威の言うことに、フォーマットを合わせることになる（のとはら先生の流派なら、のとはら先生方式に、ＰＭＢＯＫでやるって会社が決めたなら、その流派で）。

---

　つまり、「プロジェクト計画書に書かなくてはいけないこと」は、上の(A)(B)(C)(D)、それ以外は、省いても問題ない（流派によっては省く）ので、あとは上司に逆らわない程度に、でっち上げて書くというのが現状だとおもう。

　少なくとも、「こう書かないとプロジェクト計画書は成立しない！」と主張しているのは、上司とか、現場から離れている人で、現場的には、(A)(B)(C)(D)が決まっていれば、あとは、どーでもいいことだと思うよ！

３月１６日に出す、「コピーされるほど儲かるシステム！開発日記」第１４号について

３月１６日に出す、「コピーされるほど儲かるシステム！開発日記」第１４号は、ウィリアムのいたずらが行った場合の見積もり例です。実際に何を作るのかについて書いてあります。

----------

内容は、
ウィリアムのいたずらが行った場合の「コピーされるほど儲かるシステム」の見積もり
http://blog.goo.ne.jp/xmldtp/e/58cde1a7e9197d37e739fdd073729fff
とほぼ同じです。


----------

　で、１４号のメルマガについての、感想などはここの「コメント」にどうぞ！

　メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム！開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参照してください

日経ソリューションビジネスの提案書の極意のやり方を、日経システム構築で否定してなーい！？

　提案書の書き方について、日経ＢＰ社の日経システム構築と日経ソリューションビジネスで、それぞれ記事があります。
　でも、これを２つあわせて読むと、商談の極意は、日経システム構築の考え方を否定することだ、もしくは、日経システム構築の考え方では、日経ビジネスソリューションのやり方は、ありえない！！ってなっちゃうのよ(^^;)

---

　「日経システム構築」２００５月３月号「ＲＦＰに基づく提案書の書き方」の１２８ページに「ＲＦＰを十分に意識したものであるべきだ」と書いて、「しかし、実際にＲＦＰに対する回答を明文化している提案書にはほとんどお目にかかったことが無い」として、ＲＦＰを満たすことが大事だ！でも、実際には満たしていない、なんてやつって言う論調で書いてあるのよ。

　でもね、その考えで、「日経ソリューションビジネス」の「商談に勝つ提案書作成の極意」をみてね。２００５年２月２８日号のＰ６５の図２が明確にＲＦＰになってるよね（「ご協力をお願いします」って書いてあるんだもん）。つまり、
（１）課題と解決策の再確認
（２）活動のデザイン「企画提案型ビジネスにおける顧客獲得活動のグランドデザイン」
（３）営業に必要な情報の明確化
（４）情報システムの要件定義
を書けってかいてあるよね。
　ところが、その答えとして、書いてある２００５年３月１５日号Ｐ５３の提案書、
　多分この答えが図３だと思うんだけど、
（１）課題の再確認→課題も多く存在します？？
（４）情報システムの要件定義→（図３一番下の行）上記を踏まえた上での情報システム化の要件定義
なにも、答えて無いじゃん！全然、対応わかんないじゃん！！

　つまり、日経システム構築で、ＲＦＰに提案書がこたえてなーいっていうことを怒ってるけど、その書き方こそ！日経ソリューションビジネスによると、「極意！」なのよ(^^)v

---

　実際の現場でも、こういうことよくあるよね。
　課長が、「こんなやり方やるやついねーよ！そんな風にやるやつの顔が見たい」とか、ぼろくそ言ってるんだけど、まさに、そのやり方が、部長の方法のような、

　

２人の上司が言っているやり方が全然違うとき、部下の私は、どーしたらいいの？？

　っていうこと。

　今回の話も、まあ、答えておくと、日経システム構築の、「しかし、実際にＲＦＰに対する回答を明文化している提案書にはほとんどお目にかかったことが無い」わけは、実際には、ＲＦＰの書きかたって、いろいろあって、受け取る人もさまざまだから、いろんなやり方で、成功しちゃうことがあるのよ。でも、一度、それが成功しちゃうと、そのやり方が成功体験となる。
　したがって、ＲＦＰを満たさない成功体験っていうのも結構あって（営業が勢いで売る）そういう人の部下は、「おっかしいんだけどなあー」と思いながら、上司のやり方を踏襲する。その結果、百花繚乱のＲＦＰの書き方になったっていうのが、オチじゃないかなあ？って思うけど。
　だから、この極意のように、直接ＲＦＰを提案書自体は満たしているかどうか、わかんないように書く書き方も「あり！」だと思う。

　でも、部下にしてみれば、一方の上司が、「日経システム構築」方式、一方の上司が「日経ソリューションビジネス」方式だと、困るのよ！どっちのやり方に従っていったほうが、自分の身は安全か！（もう、客は関係ないっす。保身の問題です！）

---

　で、ウィリアムのいたずらの場合、どうするか？

・一番危険なのが、どっちかの上司やり方にあわせ、一方の上司を無視すること
　例えば，日経システム構築の上司を一切無視して、日経ソリューションビジネスのやり方にあわせると、あとで、「日経ソリューションビジネス」上司がはしごをはずして、「どうして、日経システム構築上司の言うようにやらないんだ！おれは、そんな指示をしていない！おまえが馬鹿だから理解できない！」と、いきなり責任逃れをされる危険がある。

・一方のやり方を踏襲し、「ところで」と話をどんでん返しさせ、後の話に持ってくる
　これは、ウィリアムのいたずらは良くやります。
　はじめに、「日経システム構築」の上司のやり方で、とりあえず書いておきます（ＲＦＰを満たして書いておく）
　で、「でも、こういう問題がある」とかあげて、あとの「日経ソリューションビジネス」のやり方にもってくる。
　もちろん、逆に、日経ソリューションビジネスのやり方で書いて、あとで、「まとめると」、として日経システム構築の話を書くとか、このバリエーションはいろいろあるけど、両方の意見を取り入れて、玉虫色にする。

・フォーマットをどっちかの上司、中身をどっちかの上司のやり方に変える
　反則技っぽいんだけど、内容が多少違っても、形式はＡ上司、中身はＢ上司のやり方という方法で両方を立てる。
　今回の場合、日経ソリューションビジネスの
　　Ｐ５３ページ図３、２つの中見出しがありますが、この中見出しの上のほうを
　「課題と解決策の再検討」
　下の見出しのほうを
　「営業に必要な情報の明確化」
　図４の大見出しを「活動のデザイン」
　図５の大見出し（プロジェクトアプローチ）を、「情報システムの要件定義へのアプローチ」

　とすると、「ばっちり！」日経システム構築上司（＝ＲＦＰの内容）のやり方を満たしているように見えます。
　中身は、「日経ソリューションビジネス」上司のやり方だけど。

---

　でも、サラリーマンの場合、怒られてなんぼで、お金もらっているっていうことは確かなわけで、このように、上司がまったく意見が違う場合、どっちなの上司に怒られることは必至。
　まあ、無理にがんばんないで、どっちかに怒られ、嵐の過ぎ去るのを待つしかないのかな？

　まあ、どっちにしろ、大手の雑誌に載せるくらいなんだから、どっちも偉い人なわけで、その人の意見すらまとまんないんだから、正しいやり方、心に響く提案の仕方なんていうのは、決まりが無いんだろうね。

やっぱ、お客さん直接の受注は怖いよね！

　今出ている日経ソリューションビジネス（３／１５号）の５６ページ、あの劇の記事の表題で、「プライム受注の怖さ」ってあったけど、やっぱ、（プライムって言うほどの規模でなくても）お客さんから直接受注もらうのは、怖いよねー。
　現実的に、お金はらってくれるかどうか、わかんないもんねー。

　とくに、小さい仕事の場合、お客さんが、結構羽振りがよさそうにしている場合、実際には儲かっていなくて、おおざっぱ（どんぶり）って言う場合があって、そういう人って、払えないから、開発をやらせといて、急に払えないとか言い出したり、なにかとプログラムにけちを付けて、払わないでいいように仕向けようとしたりとか。。。このシステム使って、お金が入ってきたら払うとか。。。
　そういう話じゃないジャンみたいな。でも、売っちゃうと営業も必死で、なぜか、その会社のために、仕事見つけてきたりすると、もう、わけわかりません。

　ウィリアムのいたずらも、お客さんからの受注っていうのは、散々懲りたし（いまも、そのため、収入に影響を受けていることは確かだし）、ウィリアムのいたずら以外でも、お客さんが、お金を払ってくれない＆条件を途中で変えられて、大損害を与えられた。。。その他もろもろのトラブルで、もう、お客さんとの直接の取引をやめた人（会社）って、多いんじゃないかなって気がする。最近。

　まあ、こんな感じだと、結局、お客さんと直接取引きするのは、体力のある会社と、お金がすぐには必要のない、週末企業とか、大企業に勤めている人の副業とかになって、ソフト会社やフリーの人は、どこか大きい会社の下請け的に入るっていう形になるのかな？と思うぞ。