仮に、「BREWの勝手アプリが作れる」としても。。。

　いつも、お勉強のために見ているブログがあるのですが、そこで、アプリ★ゲットでBREWアプリの登録が可能になった話を取り上げてました。

---

　これって、もし、
　・国内のＢＲＥＷ開発者（個人）が、
　・勝手にＢＲＥＷアプリを作って
　・登録できる
ということであったとしても、

　じゃあ、MIFエディタで設定するClass IDは？
　　（アプリごとに固有のＩＤを持っている）
とか考えると、日本国内で、BREWを個人で（KDDIの審査なく）勝手に開発するには、まだいろんな問題があると思いますよね（このほか、問題書くと、きりないのでやめる）。

---

　ただ、もし、海外のBREW開発会社が、日本にアプリをもってこようとした場合、
　・Qualcommから、クラスＩＤはもらってるだろうし。。。
　・もし、アプリ★ゲットに登録するだけでＫＤＤＩの審査なしにやれるとしたら。。。
　海外のBREW開発会社は、日本にもってきやすくなる。。

　けど、これって、やばいよね。

　だって、ＫＤＤＩの審査があるから、あぶないＢＲＥＷアプリは作れないけど
　（というか、ＫＤＤＩの規制を守っているから、危ないアプリが出てこないけど）、
　ＫＤＤＩの審査がなくなっちゃったら。。。
　なんでもありになっちゃう。。。

（どんな悪いソフトが作れるかは、あえて書きません。書いたら、みんな、作るでしょ (^^;) )

　で、実際、そんな危ない部分をこっそり入れられたら、チェックしきれないよねー。

　うーん、中南米あたりのBrew Developerが悪いソフト作らなきゃいいけど。。

　こりゃ、テリー伊藤を顧問に雇い、ミニスカポリスを結成し、危ないアプリをチェック、
　作っている会社があったら、時にはパンチ、時にはキックで逮捕していただかなくては！

---

　ってミニスカポリスは、どーでもいい話なんだけど、やっぱ、BREWアプリ開発者を広げるには、

　・ARMコンパイラ使わなくても、GCCでも出来るっていう話があるけど、それ、どーやるのか公表して
　　（もちろん、保証しなくていい。誰かのブログに書いてあるだけでもいい）

　・アプリ★ゲットなどに企画を持っていくと、その会社名でＫＤＤＩに企画書を出してくれて、

　・ＫＤＤＩの前に、プレ審査してくれる

　体制が、できてれば、いいんじゃないかなあ。。。

　やっぱ、テスト（転送）ツールや詳細情報を入手するには、企画を出さなくてはだめで、その企画エントリーは、法人でないとだめ（商業登記簿謄本を提出するから、事実上、個人は無理）っていうんじゃ、個人では、どこかの会社が代行してくれない限り、アプリ作成は難しいよね！！

IT業界のIは、InfomationのIじゃなくって、investmentのＩ？？

　昨日、「IT産業のIは、InfomationのIじゃなくって、investmentのＩじゃないかって。。。」って書いたけど、最近、まさに、そんな感じですよね。

　ライブドアって、昔はブログで有名だったけど、今や、ニッポン放送で有名だし、ソフトバンクだって、ソフトで成功したというよりか、YAHOOの株で成功したイメージあるし。。
　楽天の場合では、投資ではないけど（いや、野球に投資した？？）、でも、ソフト開発で有名というよりかは、野球で有名な感じがするし。。。
　そーいえば、マザーズだったっけかな、でちょっと前、上場廃止になった会社があったけど、あれも、ソフト関連の会社で、廃止理由はたしか、売上高の水増し。。

　うーん、最近のＩＴ業界は、コンピューターはさておき、投資で儲けてる？？

システム開発において、一番重要なのは、リスクヘッジだと思うね！

　機能のブログで、「見積もりの期間で、できそうかっていうことを考えて、リスクがあればヘッジする」というやり方について、今日は書きます。

---

　その前に、前提として。。。
　システム開発の受注の方法において、最近のトレンドは、

　　まずＲＦＰ（提案依頼書）をもらってから、
　　見積もり、検討をして
　　提案書を書く。

　という流れだと思います。で、その提案書の中に、期間や金額を書き入れるか、まあ、書かない場合でも、ある程度決めていくと思います。
　このとき、だいたいユーザーの都合で、期間や金額は、きまってしまう。
　また、会社で、仕事をやる場合は、ある程度、作業の流れは決まっている。

　だから、ここで、ＳＥができることは、与えられた期間、金額で、ＲＦＰに書かれていることができるか？やる場合のリスクを考え、問題があったら、ヘッジするっていうことしか、出来ないわけです。で、その結果を、提案書に書くと。。

---

　で、そのリスクのマネジメント方法ですが、PMBOKだと
　（プロジェクトマネジメント知識体系ガイド
　PMBOKガイド2000年版　日本語・公式版
　プロジェクトマネジメント協会から引用）

・リスクマネジメント計画
・リスク識別
・定性的リスク分析
・定量的リスク分析
・リスク対応計画
・リスクの監視・コントロール

となります。
　実際、提案書を作る程度の状況では、定性的リスク分析、定量的リスク分析は出来ませんし、リスクマネジメント計画なんつー堅いものを作る必要も無い。
　つまり、リスクを挙げて、（リスク識別）それが起こったら、どうする（リスク対応計画）を、徹底的に、読みきっていき、「これなら出来る！」というところまで、ありありと、絵が書けるかどうか、時間のある限り、詰めていくといいうことになります。

　そういう意味で、PMBOKでは、リスク識別として、特性要因図なんか使ってたけど、それより、シナリオを読んでいくって言うほうが、重要ですね。

　つまり、こんなかんじ。

　（１）ＲＦＰを実現するには、どんな技術を使うか
　　→これが、思いつかないようなら、あなたに、その仕事は出来ないはず。
　　　即、逃げることを考えよ

　（２）それを、実際やったとしたら、どんなふうになるかのシナリオを作る

　（３）そのシナリオが描けなかったら、それはリスク
　　　　→他のやり方で実現できないか、考え直す（２）へ

　（４）そのシナリオどおりやって、予算、期間的に間に合うか。
　　　　間に合わなかったら、それはリスク
　　　　→他のやり方で実現できないか、考え直す（２）へ

　（５）それは、ＲＦＰで言っている要望を満たしているか
　　　　この満たしているとは、言っていない要望も含む
　　　　満たしてなかったら、それはリスク
　　　　→他のやり方で実現できないか、考え直す（２）へ

　で、（５）までＯＫになれば、そのやり方でＯＫ。それで提案する。
　提案書は、その案で書ける。
　でも、（５）までＯＫにならないのに、その仕事を受けなければいけないことがある。
　そういうときは、できるだけ、問題になるところを避けられる、技術的方法を見つけるって
いうことになる。

---

　だから、置き換え方法、他のやり方が見つからないと、結局、行き詰まって、開発不能になる。

　たとえば、Web系で開発してしまった場合、ユーザーから、入力をタブで移動させて
くれないと、やりにくい！といわれてしまった場合、HTMLしか知らない人の場合、
もう、開発不能になってしまう。
　でも、毎日、そんな、「ユーザーインターフェース変えろ！」とか言われたら、気がめいって、病気（うつ病とか）になっちゃいますよね。


　でも、ウィリアムのいたずらだったら、じゃあ、

　　そこjavaのappletで？
　　いや、めんどーならWindowsで画面を開発して、ポート80番でSocketつかって、送ります？

　とか、いろいろ回避案が出てくる。
　そういう意味で、ＳＥさんは、自分が出来る技術をいろいろ持ってたほうが、身の安全を図れると思う。ようするに、それが、技術における、リスクヘッジだね。

---

　でもでも、じゃあ、ウィリアムのいたずらのやってるシステム開発って、
　　リスクを分析して
　　シナリオ作って
　　その中で、取れるリスクを取っていく
　っていうことじゃん。それじゃー、株式投資と同じじゃん。
　じゃあ、株式投資のほうが、手っ取り早くていいじゃん！

　っていう結論になりますよね。これは、この前のヒモの話とは違い。。。
　そのとおり。。。という雰囲気、（開発とは、関係ないけど）最近ありますね。
　IT産業のIは、InfomationのIじゃなくって、investmentのＩじゃないかって。。。
　そんな話、今度書こうかな。。。

要件を決めるとき、機能で決めていくと、同床異夢になりやすい。で、どうするか

　昨日のブログで、システムの要素を決めるとき、「機能より、出力内容から決めたほうがいい（なぜかは、別のときに書きます）」と書いた件について。

　いいかえると、要求仕様の要件は、機能より、入出力項目（内容）で決めたほうが、間違いが少ない。
　理由や、それに関するソフトウエアの歴史を述べる前に、その事例を示します。

---

日経システム構築　２００５年２月号　５２ページ（問題解決の軌跡　東亜建設）から引用

　用語と機能に対する認識の相違、ならびに業務分析の不足は、要件定義工程でカスタマイズの増加となって噴出した。
　一例を挙げると、「手形管理一覧」という言葉に対して、東急建設側は、旧システムでの「支店別に小計を出力する形」を想定していた。一方のＮＥＣは、パッケージ標準の「小計を出力しない」手形管理一覧を想定していた。
　支店別に小計を計算できなければ、東急建設にとっては使えない。「（パッケージ導入なので）帳票の体裁が変わるのは当然だと思うが、業務で利用できなければ意味が無い」

（ここまで引用）

---

　上記の例、「手形管理一覧」という機能名（たぶん、おおまかな内容も）は一緒だけど、入出力でみると違うと言うケース、結構起こります。
　営業サイドは、売りたいので、似た機能があると、「それできます！」といってしまう。
　開発は、現在の開発は、オブジェクト指向が進んでいるため、クラスが切れれば、あと細かいことを意識しなくても、話が進められてしまう。とくにＵＭＬを使う場合、アクティビティ図から書くけど、アクティビティは、機能（業務内容）さえ決まれば、書けてしまう。
　そこで、まったく予想していない出力項目が入っていても、その項目を意識しなくても、問題なく、仕事がすすめられてしまうことがある。

　でも、実際には、必要な出力項目がないと、意味ないし、出力項目を導くには、入力データを受け取ってないと、処理できないです。

　なので、要件を出すとき、
（１）機能から抽出すると、たしかにやりやすいけど（動詞を探せばいいから）
（２）その機能は、入出力項目で定義しないと（売上代金、担当コードを入力とし、担当コードごとに売上を集計、出力する機能とか）、誤解が生じやすい（同床異夢になりやすい）

---

　あと、機能できめると、もうひとつ問題がある。

　これは、１９９０年ころの、システム開発のトレンド、ＤＯＡについて、思い出してもらうと分かる。ＤＯＡが出てきた背景は、機能は、変わりやすいが、データ構造は変わりにくいということから、でてきた。

　実際そうなの？っていうことはあるんだけど、でもでも、機能は、変わりやすい。

　立場や、見方によっても、機能は変わってみえる。

　それに対して、データで定義すると、実物の、事実に基づいて定義できるから、結構、変わりにくいし、同じ見方になりやすい。

---

　まあ、ここらへんの詳しい議論は、要求定義のお話のときにします。
　とりあえず、昨日、保留にしていたことの、回答。
　あと、昨日、保留にしていた、作業内容が、見積もりの「期間で、できそうかっていうことを考えて、リスクがあればヘッジする」過程については、また別にあらためて。

「コピーされるほど儲かるシステム」の場合の見積もり例

　では、実際に、「コピーされるほど儲かるシステム」の場合を使って、スケジュールと見積もりを立ててみると。。。

まず、もう、決まっちゃってること。

・人員　ウィリアムのいたずら１人
・期間　決まってないけど、Windowsを使う場合、最大３年くらい
　　　　→開発に３年かけたら、せいぜいそのシステムは２年くらいしか使えない。
　　　　　つまり、５年間くらいしかWindowsの場合、計画が立てられない。
　　　　　だって、５年前のWindowsって、どーなってたか
　　　　　（答え：たぶん、９８で、数Ｇのハードディスクを使ってたと思う）
　　　　　つーことは、５年後。。。想像つかない。。
　　　　でも、物には、相場っていうのがあって、今回の場合、６ヶ月くらいだろう
・手順
　　　要求仕様作成
　　　外部設計
　　　詳細設計（内部設計）
　　　プログラミング
　　　テスト
　であることは、間違いない。

　で、今回のシステムを、まず、要素に分ける。

　これは、機能より、出力内容から決めたほうがいい（なぜかは、別のときに書きます）
　出力内容は、ホームページということにしてしまいましょう。
　この構成は、メルマガの１０話のとおり。

　で、それをもとに、ざっくり要素をきめると、１１話で述べたように、要素は３つ。
　　・７話のExcelファイルを作る
　　・自分の作品を発表できるページ（第十話の内容をもっている）
　　・「自分の作品を発表できるシステム」のどこかに「７話のExcelファイル」を利用

　で、これのリスクを考える。
　７話のExcelファイルは、内容は、見えている
　自分の作品を発表するページに関しては、ここで書くと長くなるから省略するけど、
　見えている。それをどうつなぐかって、いうことも、読みきっている。
　なので、ここまでＯＫ。

　じゃあ、手順にしたがって要素を適当に並べる。
　要素に分解できるのは、外部設計から（要求段階では、要求がどの機能に分けるべきかを
考えないといけないので、まだ、分けないほうがいいだろう）。テストも、個々のテスト
（単体テスト）と、結合テストがあるので、こんなかんじ。

（１）全体の要求仕様作成
（２）７話のExcelファイル
　　　外部設計
　　　詳細設計（内部設計）
　　　プログラミング
　　　単体テスト
（３）自分の作品を発表できるページ
　　　外部設計
　　　詳細設計（内部設計）
　　　プログラミング
　　　単体テスト
（４）Excelホームページ連携
　　　外部設計
　　　詳細設計（内部設計）
　　　プログラミング
　　　単体テスト
（５）結合テスト

相場が半年。で、項目が５つ。
なので、１ヶ月づつ割り振って。。。１月あまる。。。要求仕様に入れときましょう。
（２）から（４）について、
　　　それぞれのステップは４つ。
　　　１月は、４週
　　　ゆえに、１週１ステップ
結果として、見積もりは、こんな感じ。

（１）全体の要求仕様作成 ２ヶ月
（２）７話のExcelファイル
　　　外部設計 １週間
　　　詳細設計（内部設計） １週間
　　　プログラミング １週間
　　　単体テスト １週間
（３）自分の作品を発表できるページ
　　　外部設計 １週間
　　　詳細設計（内部設計） １週間
　　　プログラミング １週間
　　　単体テスト １週間
（４）Excelホームページ連携
　　　外部設計 １週間
　　　詳細設計（内部設計） １週間
　　　プログラミング １週間
　　　単体テスト １週間
（５）結合テスト １ヶ月

ていうことで、

　ね！なんにもきまってないのに、スケジュールって、制約ときまりごと
だけで、できちゃうでしょ。

　あとは、担当が１人しかいないので、時間に１人を掛けて、その会社の
規定の金額を入れてしまうと、見積もりができちゃうのよ。。。

　ウィリアムのいたずらなんかが見ると、多分、こうやって、決まったことを
てきとーに割り振ったんだろうな、っていう見積もり、けっこうあります。

　で、問題は、この期間で、できそうかっていうことを考えて、リスクがあれば
ヘッジするわけですよね。
　その過程は、またこんど。

中小企業のシステムの中には、今の流行の技術を使うと失敗するものもある

　ちょっと、興味深いブログを見たんで、話は脱線してしまうんだけど、自分の経験したおはなしを１つ。

　中小企業（大企業でも、部署によってはこういうことがあるんだけど）では、今はやりのＩＴ技術を使うと、失敗しやすいケース（＝自爆ですな）があります。

　っていうのも、最近のはやり(Strutsにしろ、JavaBeansにしろ、PHPにしろ）のＩＴ技術って、データベースにRDBを使います。大体（Oracleか、PosgreSQLか、SQLServerかMySQLかの違いがあるが）。

　で、このＲＤＢですが、ＲＤＢを設計する場合、データ構造が決まってないと、作るのが、難しいんです。あとから、適当に追加すると、矛盾をきたしてしまったり。。

　また、ＲＤＢの場合、
　　　　この人のケースでは、この形、
　　　　あの人のケースでは、あの形。。。
　と、ケースによって、データ構造が変わるのも、苦手です
　（情報処理試験お勉強中の方へ；そういう場合、正規化を崩せばできるけど、
　　もし、崩さないなら、そのケースにあったテーブルをもつとか。。。
　　で、テーブルが増える＝操作たいへん。
じゃあ、XMLDBにすれば！と思うけど、そうすると、帳票の細かい出力が大変）

　こういう場合、Excelだと、データ構造をあまり意識しないで、ブック＆シートが作成できるので、簡単に開発できるケースがあります。

　たとえば、介護の顧客情報（＝介護される人の情報）を、保存するケースなどでは、
　　・介護関連法案が、頻繁に変わるので、それに対応して顧客の個人情報の構造も変わる。
　　・その場合、前の情報と、後の情報、どっちも持ってないといけない（構造は、変わるのに）
　　・お客さんの変化によって、新たなデータ構造を導入しないといけないことがありえる
　　　　たとえば、いままで、その会社では、認知症（って、いうそうです。痴呆症のこと）の人
　　　　はみてなかったけど、その人が認知症になったら。。。
　　　　介護に必要な情報は、根本的に変わってきます。
　てなかんじで、ＤＢのデータ構造を定義するということは、できないです。
　極論すれば、介護技術と法案と、会社の成長と、顧客の変化で、データ構造はちょくちょく変わる。

　そういった場合、顧客ごとのExcelファイルを持ってしまって、必要な情報を、テキトーにシート
に入れてもらい、それに検索機能を付けたり（Excelでもかなり柔軟に検索出来るし、マクロ書けば、結構使える）
　帳票を出す場合にも、Excelで、帳票の雛形を作ってもらい、Excelのマクロでデータを取ってきたほうが、簡単に出来たりする（StrutsからRDBでデータ取ってきて。。。帳票に出すのって、どーする(^^;)？FO使う？AccessにODBC接続？？）。

　データ構造が変わっても、Excelのブック内の話であれば（つまり、顧客ごとにExcelファイルを持った場合、顧客の情報が、データ構造ごと変化しても）さして操作に問題はないし。。。
　問題は、スピードと、データの一貫性と、排他制御なんだけど、その辺があんまり関係ないシステムには、Excelのほうが、向いていることもあります。

　問題は、それなのに、ＲＤＢでむりやり作ろうとした場合。。。
　データ構造が決められないのに、無理やり決めようとして、あとで、ちょくちょく修正が入ったり、
　ユーザーが仕様（＝ここではデータ構造）を決められないので、開発できないとか言ったり
　もともと、そーいう構造だから、データ構造は決まらないのに、決めようとして悩んじゃったり。。。
　と、いろんな弊害（＝できないから休日出勤とか、病人が出たりとか）が起こりますな。

業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実

　今までのブログで、ソフト開発の場合、現実的に何にも決まってない状態で、見積もりをしなくてはいけないということを書いてきました。
　で、そんな状態で、どう見積もるのか。。。です。

---

　一応、プロジェクトマネジメントの標準（になろうとしている）PMBOKに敬意を払い、PMBOKで、見積もりを、どうやって出すかについて書きます。

PMBOKでは、スケジュールと、コストを以下のように出します
（プロジェクトマネジメント知識体系ガイド
　PMBOKガイド2000年版　日本語・公式版
　プロジェクトマネジメント協会　の　３３ページの図より引用
　ただし、番号と一部の用語は、ウィリアムのいたずらが変えた）

（１）スコープ計画
（２）スコープ定義
（３）アクティビティ定義
アクティビティ順序設定
アクティビティ所要時間見積り
（４）資源計画
コスト見積もり
（５）リスクマネジメント計画
（６）スケジュール作成
（７）コストの予算化

　つまり、（１）から（３）で、作業を詳細化し、その後所要時間と、人材などの資源を見積もるということになってます。ここから、仕事を積み上げ、何人月という単位で出すので、ソフトウェア開発は、不透明だと、偉い人たち（大学の先生、一流企業のお偉いさん）は言ってます。
　

---

　でもですね、一流企業は、そうやって出してるのかもしれませんが、
　それって、幻想に近いんじゃあないかと、思うんですよ（昔は、そういういい時期もあったと思いますが）。いまどき、普通は、

・開発期間というのは、もう、ユーザーの都合で決まっちゃうことが多いと思います
　　（たとえば、法令が施行されるまえに開発しろとか、競合が販売する前に出せ！とか）。
・予算もですね、たいてい、ＭＡＸは、決まっちゃいます。
・決まってなくても、だいたい使える人材には、限度があります。
・で、さらに、開発方法は、方法論が、会社内で、おおまかに決まっていることが多いです
（特に、ＣＭＭＩっていう、ソフト開発の成熟度を示すものがあるのですが、それを気にしてる会社などは、開発方法が標準化されてるし。。。）

　ということでですね、見積もりをするときは、

　　・内容は、わかんないのに
　　・予算と期間と、作業手順は、おおまかに決まっている

　というのが、多いのが、現実だと思います。
　つまり、人月単位でだしてくれれば、まだいいんだけど、ユーザーの予算と、営業の思惑できまっちゃうっていうのが、現実では？？

---

　では、どうするか。。。ですが、PMBOKで、あと、使っていないで、できる活動っていうと、リスクマネジメントしかないですよね。実際、ウィリアムのいたずらが見積もりするとき、現実的には、こうやってます。

（あ）まず、分かっている範囲の開発内容から想像して、各種要素技術に分解し、その技術を使って、ユーザーが希望するものが、出来そうか、読みきる。
　→読みきれなければ、それがリスクとなる
（い）手順、予算、期間は大体決まっていることが多いので、それを、ならべる
（う）（あ）を（い）の中に当てはめて、大丈夫かあ？って考える。
　→ダメそうだったら、それは、リスク
（え）（あ）や（う）で起きたリスクを他のものに置き換えられないかなどの対応を考える。で、置き換え可能と読みきったら、営業に、「こーしてよー」って、哀願する。

ってな感じしか、現実的には、この状況では、出来ないと思うけど。。。

ソフト業界は、なぜ規格化して、規模を大きく出来ないのか？

　一般的に考えると、サービス（ソフト業界ならシステム開発）を規格化すれば、
　その規格に合わせたサービスを大量に供給でき、サービスの技術もあがり、
　規模を大きく出来ます。
　これを規模の経済という。。。っていうのは、普通の経営の授業で習うこと。

　でも、ソフトハウスの場合、これだ、できないんです。
　理由は、ソフトを作る目的が、ビジネスモデルの構築だからです。

---

　企業は、競争して、勝ち残ったものが利益を得ます。
　それが、日本やアメリカを初めとする資本主義社会のしくみです。
　で、競争に勝つには、どうするか。。。

　放送大学大学院の経営システムＩのテキスト６２ページにあるばあい、
普通とる戦略が差別化です。
　で、差別化には（そのページの図にあるように）２つあり、
　・製品あるいはサービスの差別化と
　・ビジネスシステムの差別化
があります。一般に、後者のほうが、差別化として、大きなインパクトがあります。
で、これを行うためにビジネスモデル特許などもあるのでしょう。

　でも、ここで問題です。ビジネスモデルを規格化したら、差別化できないですよね。
その規格と、違うことをするのが差別化ですから。

---

　つまりですね、ビジネスを差別化するために、システム開発する場合、
規格にはずれたことをするわけですから、規格化はあんまり役に立たないです。
　もちろん、二番煎じ、そのあとに続く人たちに対応するために、規格化と
いうのは考えられますが、この場合は、パッケージソフトが出てしまうので、
ソフト開発的には、規格化というよりかは、パッケージ化の問題になります。

---

　じゃあ、そのような新たなビジネスモデルに対応するにはどうしたらよいか
というと。。。

　規格化でなく、部品化と、その部品の限界（問題点）を分かりやすくすること、
　部品を使いこなせる人を増やすことです。

　つまり、ミドルアップダウンの、ミドルマネージメント層を増やし、その人たちに
有効な情報を提供することになります。
　では、効率よく、ミドル層を養成するには、どうするかというと、小さな成功で
いいので、それを積み重ねることです。

---

　たとえば、証券システムを開発しようとした場合、規格化で考えるなら、
一つの証券会社のシステムを受注して、それで規格をつくり、そのあと、
いっせいにその規格をもとに、他の証券会社のシステムを開発するということになります。

　しかし、この場合、証券会社のビジネスモデルは、多くの場合、かなり異なっています。
　ネット証券だけみても、１０万円以下無料、ループトレードで課金のところも
あれば、１回の取引手数料が安い（けど毎回の取引にお金がかかる）といったように
さまざまです。
　これを規格化するというのは、無茶でしょう。証券会社が納得しません。

　っていうことで、この部分を作り変えると。。。
　結局、規格化できない部分が複雑で、それと、規格が合わず。。。問題化してしまいます。



　一方、ウィリアムのいたずらの述べた、部品化＆小さい部分の成功ということから
考えると、今、手付かずの分野として、証券仲介業の部分があります。
　ここの部分だけを受注、システム化します。
　で、ここの部分で、どんどん部品化します。

　証券業界の場合、手数料部分は違いますが、発注の出し方は、むしろ、取引所
ごとに決まってるし、その日の集計なども、使えるかもしれない。。。

　そうやって、成功事例がたまっていくと、あらたな受注を受けたとき、どの部品が使えるか
みえてくるということです。

---

　一方、規格化して、いっぺんにやる場合は、そういうミドルを育てないで、いきなり
やるので、前のブログに書いたように、それだけ、危険性が増します。
　結果として、だれか、おおきな失敗をしでかして、儲けを吐き出してしまうということに
なってしまう。
　やっぱ、ソフト業界で、規格化は、危険だと思います。じみちにいこう。

---

ということで、ウィリアムのいたずらの富士ソフトＡＢＣの記事のコメントはおしまいです。
で、次回から、「コピーされるほど儲かるシステム」の、プロジェクトの見積もりの話から

プロジェクトのはじめ！見積もりをだせ！という無理な注文

ほんとうは、今日あたり、開発ネタで、

放送大学大学院でやってた授業と、規格化の問題について、

書かないといけないのですが、
今日、テキストがないので（引用ページがわからないので）、
コピーされるほど儲かるシステム！の１２回の話題に関連する

プロジェクトについて

のほうを、書きます

---

　プロジェクトマネージャーさんは、はじめてのミーティングが終わ
ると、いや、ミーティングをする前から、営業から「見積もりを出せ！」
と言われます。

　つまりですね、前のブログで「日経の富士ソフトＡＢＣのところに
書いてある」といった、「何階建てにするかわかんない段階で見積もり
をだせ！」といっているものです。

　１０回、１１回の話を総合すると分かると思いますが、初めのミーティング
では、目標と、制約ぐらいしか決まってません。

　つまりですね、システムというのは、だいたい、画面や帳票数、テーブル、
ＤＢの数および難易度、機能に影響するんですが、そんなのがわかる、
きっかけとなる、ユーザーさんのヒアリングを、ちゃんとする前から、
見積もりをきめさせられるのです。

　で、その見積もりが一人歩きし、その予算のなかで、やらないといけないのです。
　で、失敗すると、プロジェクトマネージャーとか、ＳＥなど、開発の責任になります。
　営業は、無関係。。。っていうか、失敗したら、プロジェクトマネージャー、ＳＥ
をいじめにかかります(^^;)

　？？？？

　業界に関係ない人は、不思議に思うかもしれません。
　・なにをつくるかわからないのに、なぜ、値段が決まるのか
　・普通、営業とは、受注だけでなく、売掛金回収まで、責任をとらないにしても、
　　関心は、あるだろう。
　　ましてや、自分のとった受注が、結果として失敗したら、やばい取引先として、
　　記憶しておくだろう。。。なのに、なぜ、営業は、開発を責めるだけ？？

　理由は。。。

この業界の慣行だからです。

　さらにですね、日経ビジネスソリューションの物語のやつにあったけど、
　開発は、そんなんで、営業のせいで、四苦八苦してるのに、
　その最中に、平然と、「見積もりをたてろー！！」といって、苛め抜くのです。

　その受注、とったら、どーする気？？だれやるの？？と思うのに。。。

　でも、その物語に書かれているように、誰が考えても、普通の神経していたら、
どー考えてもおかしい話なのに、あたかも「開発が悪い！！」と決めつけ、
開発以外、とくに営業から総攻撃されます！！


　でも、それが、この業界の慣行なので、そんなことに文句をいっても、仕方ないです。
　その慣行から、逃れたかったら、
　　会社やめて、ウィリアムのいたずらのようにフリーになるか、
　　そういう仕事をして、うつ病になって、会社やめるくらいしか、手が無いかも

　だいじょうぶ！、そういう仕事はたいてい、理論上、出来ないようなシステムなので、
それを、無理やり作れ！っていわれれば、頭おかしくなって、うつ病になります。

　徹夜しても、なんでも、できないのです。。。。
　努力してもダメなのです。

　それは、１＋１をむりゃり３にしろ！といっていることと同じです。

　問題は、その営業の無茶な注文に対し、どうやって、リスクを軽減して、見積もり
を出すか？？という話です。

---

　で、それを。。。たぶん、放送大学大学院でやってた授業の話のあとに書きます。

セッションIDとクッキーの設定法、取得法

Webで、２つ以上の画面にまたがるとき、データを保持しておく方法である、
セッションIDと、クッキーのまとめです。
　これ、あくまでも自分用のメモです。
　実際に試してない（＝ほんとに動作するか不明）のもあります。

------------------------------

＜＜目的＞＞
　ブラウザで、セッションが切れても、前のデータを保持したい場合、
　（＝複数セッションを１トランザクションとするとき）
　　　前のデータを、クライアント側にもつのが、クッキー
　　　前のデータを、サーバー側にもつために使うのが、セッションＩＤ
　　　
＜＜セッションＩＤ＞＞
・しくみ
　サーバー側にデータをもつ。したがって、クライアントは、そのデータの
ＩＤ（セッションＩＤ）をもらって、次回の接続のとき、それを渡せばよい。
　セッションＩＤは、クッキーとして持つかまたは、ＵＲＬとして持つ。

・PrelでのセッションID取得・設定
　　CGI::Sessionを使う
（まあ、ほかにもWalrus::Session::Liteとか、Apache::Session.pmとかも、あるみたいだけど）

・サーブレットでのセッション
　開始　HttpSession session = request.getSession(true);
　取得　HttpSession session = request.getSession(false);
で、セッションを取ったら
　　　　session.getAttribute(名前);
　設定　session.setAttribute(名前 , 値);
　終了　session.invalidate();
　くわしくは、ここ　


　クライアント側で、セッションＩＤを知ることは可能だが、自動的に
ブラウザで、振ってくれるので、知ってもあまり意味がない
（ハッキングとかするのでなければ）
　クッキーを利用できないクライアントの場合、セッションＩＤが、ＵＲＬ
に入ることもある。
　
＜＜クッキー＞＞
・しくみ
　クライアント側でデータを持ち、サーバーにそのデータをわたす。

・perlでのクッキー取得・設定
　クライアントが持っている値を、クッキーを使って取得するには、
サーバーの環境変数HTTP_COOKIEの値をみる
　クライアントに、Cookieの値を設定したいのであれば、
　　CGIがprintで出すとき、ヘッダーにSet_Cookie:を入れる

・サーブレットでのクッキー
　クッキークラスへ設定する。くわしくは、ここ


なお、クライアント側でも、クッキーの値は読み込めるし、設定できる
・たとえば、JavaScriptで、クッキー取得・設定
　document.cookieに、値を設定すれば、設定、document.cookieの値を参照すれば、取得

8.3形式のファイル名（短いファイル名）をWindowsで取得

あるMakeFileを記述しているとき、スペースがあると動かなかったんで、短いファイル名が
必要だった。そのとき調べたことの備忘録です。

　コマンドラインから
dir /x

２月９日「コピーされるほど儲かるシステム！開発日記」の第１１号を出します

　９日に、「コピーされるほど儲かるシステム！開発日記」の第１１号を出します。

----------

内容は、目標の立て方について、以下の２つのブログのまとめです。
http://blog.goo.ne.jp/xmldtp/e/5704635f113ed6e174ad21c802e5e649
http://blog.goo.ne.jp/xmldtp/e/dca68877d362978309ed9cf8a2fada45
メルマガのほうが、読みやすくなっています。

ちなみに、今回で、初めのミーティングの部分が終わりで、
次回から、プロジェクトマネージメントの話です。
ＰＩＭＢＯＫや、実際のプロジェクトの大きな問題について、
次回取り上げる予定ですが、その前に、ここのブログに書くことでしょう。

----------

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

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

JAVAの日付関係のまとめ

(Javaにおいて）よく、日付関係の変換、比較について、聞かれるし、
自分自身も迷うことがあるので、まとめておきます。
（きょう、野暮用で、日付関係のクラスを使うことがあったので）


どっちの日付のほうが、前か、後かを確認する
Date.after(Date when);
この Date オブジェクトの表す時点が when オブジェクトの表わす
時点より遅い場合だけ true、そうでない場合は false
Date.before(Date when);
(afterの反対）
compareToで比較してもいい。
Dateでなく、GregorianCalendarでやってもいい。

日付を数字でだす。
Dateに入っている値の、年、月、日など出したい場合。
Date.getMonth()などは、推奨されていない。
GregorianCalendar.get(Calendar.YEAR);
の形で取得する

設定するときはsetになる
MONTHについて、返り値に１を足したのが、本当の月の値

現在時刻の取得
new GregorianCalendar();で現在時刻が入ってくる。
(new Date()でも）なお、ミリ秒をlongの形でいいなら
System.currentTimeMillis()でもＯＫ

DateとGregorianCalendarの変換
GregorianCalendar.getTime()で、GregorianCalendarからDateを取得できる
new GregorianCalendar(Date.getTime())でDateからGregorianCalendarを取得できる

注意
　GregorianCalendarのクラスでは、上位のクラスCalendarのメソッドも使える。
　Calendarクラスに、使いやすいメソッドがあるので、そっちもチェック。

規模を大きくすると、ソフト開発会社は危険です。

前のブログで、プロジェクトマネージャーの類型として
（１）トップダウン型
（２）ミドルアップダウン型
（３）丸投げ型
とあげました。そして、丸投げ型について、 仕事を丸投げして、マネージメントしやすいもの、しにくいもの のなかで、

　　（あ）やることが決まっている場合、丸なげしやすい
　　（い）やることに、少しずつ違いがある場合、丸なげしにくい

と書きました。

　さらにいうと、丸投げ以外については、
　（１）のトップダウン型の場合、（あ）の、「やることが決まっている場合」は、マネージメントしやすいです。
　（い）の、「やることに、少しずつ違いがある場合」は、「ミドルアップダウン型」のほうが、現場の状況とかを判断して、マネージメントできるので、やりやすいです。

---

　で、（１）のトップダウン型の場合は、やることがきまっているので、それをマニュアル化すれば、大規模に仕事ができます。
　しかし、（２）のミドルアップダウン型の場合には、ミドルのマネージャーに、ある一定の技術になってもらわないといけないので、すぐには、規模が大きくなりません。

---

　ところが、この矛盾を背負ってしまったのが、ソフト業界です。
　ソフトウエア開発は、美容師などと同じく、仕事の内容に、少しずつ違いがあります。
　業務が同じでも、新しいハードにするとか。。。
　したがって、ミドルアップダウン型にしないと、いけないんです。

　でも無理やり、大規模にやったら、どうなるか。。。

　人だけそろえても、ミドルでマネージメントするだけの判断ができないので、結局、そこの人たちの仕事は、失敗する可能性が高いです。
　で、ソフト開発の仕事は、成功する場合、利益は、限定的なのですが、失敗すると、かかる費用（＝損失）は、プライスレスです。

　そのうえ、その失敗したプロジェクトに人をさかれます。

　ということで、９個成功しても、１個失敗すると、結局損失ってなことになります。
　で、やるプロジェクトの数が増えれば、ただでさえ、失敗する危険性も増えますから。。。

　規模を大きくするということは、ソフト開発会社にとって、危険です。

　でも、規格化すればいいんじゃないの。。。という考えには、またこんど。

ちなみに、、 仕事を丸投げして、マネージメントしやすいもの、しにくいもの がキャバクラの話になるので、あとは、放送大学大学院の話がのこってます。
そこで、規格化の問題を書きます。

今度は日経ビジネスと、日経コンピューター（要求仕様の標準化）で、ボケツッコミ？

　前に、日経ビジネスと、日経ソリューションビジネスでボケツッコミと書いたけど、今度は、日経ビジネスと、日経コンピューターでボケツッコミやってますね(^^)v

　日経コンピューターの２００５年２月７日号、１３ページ「日本発で要求定義の標準手法確立へ」っていう、要求仕様の標準化、openthologyの話。その３段落目、
「ユーザー企業の要求精度が高まれば、システム開発の失敗は少なくなるはず」


　　　　　　　　　　　　　これと、


　日経ビジネスの２００５年１月３１日号、６４ページ（富士ソフトＡＢＣの話）で、
「実は、建設会社の方が、情報サービス会社よりずっとまとも。きちんと設計書を作って、細かい部材の仕様まで決めてコストをはじき出している。だが、ＩＴ業界は、ビルに例えれば、まだ何階建てにするかも決まってないのに、いきなり見積もりを出す。」

この２つ、一見すると、（現場に出てない人には）同じ内容に見えますよね。
つまり、「きっちり設計書をつくれば」＝「要求精度が高まれば」失敗は少なくなる
ところが、違うんですねえ。

---

　つまりですね、今後、メルマガやブログで説明するけど、PMBOKのような、現行のプロジェクトマネジメント論や実際に現場でやられていることに従うと、要求仕様に入る前、あるいは途中で、もう、見積もりださないといけないんです。



　　　だから、要求精度を高めても、

　　　要求仕様を決める前（つまり、設計書をちゃんと作る前に）見積もりをだせ！
　　　　といわれてしまう現在のやりかたでは、
　
　　　結局、要求仕様をきめたころには、見積もりも全て決まっているので、

　　　要求仕様の精度を高めても手遅れ、結局、見積もりオーバーで失敗になってしまうのです。



　つーわけで、日経コンピューターの見解は、結局、ボケになってしまうのです(^^;)

---

　ウィリアムのいたずらが思うに、プロジェクトを成功させるには、方向が逆で、

　・要求精度を高めなくても、ある程度のリスクをとりながら、見積もれる手法と、
　・そのリスクに対するリスクヘッジ手法
　
　について、研究しなければいけません。
　まあ、この話を、今後、このブログとか、メルマガで話していくんですけど。。。

---

　でも、だからって、今回のこの、「要求仕様の標準化」が無意味ってわけじゃなくって、大いに意義があるのですよ！

　理由は、現在のプロジェクトが、標準にくらべて、どれだけ、ずれているかが分かるから。

　たとえば、時刻で考えてみましょう。
　アメリカと日本と、イギリスと、インドで、日が昇るときは、ぜーんぶちがいますよね。
　だからって、時刻をきめなかったら、みんなで、いつ、会議しましょう！なんてことは
きめられない。アメリカ、日本、インドの人がネットで会議なんつーのもできない。

　でも、ここで、イギリスを標準にして、標準時刻をきめ、日本は何時間ずれてる、インドは
何時間ずれてる！って決めれば、アメリカ、日本、インドの人が、ネット上で会議するのも
可能。イギリス時間（ＧＭＴいまはＵＴＣなのかな？）で、何時って決めれば、あとは、
各国、ＧＭＴから、ずれてる時間を足せばいい。そうすれば、会議にみんな出席できる。

　というわけで、要求仕様の標準がきまれば、このプロジェクトは、標準から、どこがずれているので、どういうリスクがあるので、どーいう管理をしなきゃいけないかが分かる。
　そういう意味で、意義がありますね。

---

　で、実際の内容については、ダウンロードできるみたい。
　そのサイトは、ここ
http://www.openthology.org/download.htm
ウィリアムのいたずらも、いまダウンロードしたばかりなので、今度、内容を読んで
もし、なんか、ネタになりそうなことがあったら、このブログに書きたいと思いますです。