「日本の“作りたがる”文化がアプリ苦戦の理由」というお話を、はぶさんのところで見たのですが、私は、パッケージ開発＆商品企画をやっていた人間として、みょーなところに、激しく同情してしまったので、今日はその話。
ちなみに、そんなかんじなんで、はぶさんのところとは、ぜーんぜん関係ない意見っす。
オラクルがビジネスアプリ不振ってことで、ラリー・エリソンＣＥＯは、「カスタム・アプリケーションの割合が高い」からって。。で、「日本の“作りたがる”文化がアプリ苦戦の理由」っていうことになるみたいだけど、「はいはい、またその議論ね、もうあきたよ。。。読みたいのは、”カスタムアプリを作りたくない人間とどう組むか”っていう話なのに」と思って読んでいたら。。。
同社のチャールズ・フィリップス社長にも同じ質問をぶつけてみると「ディストリビューションが十分でなかったのが原因」との答えを得た。
わかってるじゃん！！
ほーんと、そうなんだよねー。
で、上の人間は、あのカスタムアプリ論・・・
うーん、やっぱ、実際に現場で営業かけてないと、そういう論点の差っていうのがでてきちゃうんだよねー
昔、一時期(SRAが買収する前の話。その後SRAからLivedoorにいく）、Turbo Linuxが売れた、あの伝説の営業のおねーさん（でも、きれいではないそうだ）の話を持ち出すまでもなく、どこの人間をおさえるかによって、売れ行きは大きく変わる。そういう意味で、ディストリビューション政策は、すべてなんだよね。
そこに出てくるディストリビューターによって、製品も変わってくるわけで。。
で、問題はどの人間を抑えるか。。。なんだけど、ちょっと考えただけでも、方法は２つ
（まじめに考えれば、もっとあるかもお）
・カスタムアプリを作らせたくない人間と組む
→たとえば、積極的な買収会社と組む
・既得権益を持った団体（人物）をおさえる
→既得権益がらみの業界標準、外部インターフェースをおさえ、
その団体をバックに、外部インターフェースから、
さらに内部の業務システムへ、やわらかに、真綿でクビを
しめるように、会社を締め付けていく。
ウィリアムのいたずらの話としては、当然後者の、ドロドロ話のほうが、１００倍（当社比：うそ）面白そうだけど、時間がないので、前者の話で、お茶をにごす。
すばり、買収会社っていうのは、買収先のデータを欲しがっている。
顧客名簿持ってるようなもんだからねー
で、買収先のデータを取得するには、どうするか。。。
自社のシステムを使わせる。。。っていうわけよ。
このとき、普通だったら、いままでのしがらみなんとかかんとか。。って言ってくるんだけど、買収した場合は、簡単。うだうだ言ってる買収先の会社の社員なんか、クビにしちゃえばいいし、こっちは金持ってんだし、親会社だから、かなり強引にやれる。それが、買収ってやつだ。
つーことで、結構、「このシステムを使え！」っていうことができる。。。
そして、そのシステムを使うことによって、子会社の情報はすべて収集できるわけよ。
子会社の業績悪くなったら、その会社をたたんじゃうなり、またどっかにうっちゃえばいい。
データは、すべて抑えてあるんだからね。。こっちのもん。
でも、そうやって言うと、子会社の反発を買う。
そこで、パッケージ君の登場です。
パッケージソフトなら、「うちも使ってるけど、みんなつかってるよお！」っていうと、言葉のあたりがいい（でも、本当に、欲しいのは、そのパッケージで入力してくれるデータだ）。
っていうことは、その業界でこれから、おおきな買収を仕掛けるやつのシステムをはじめに作って、それをビジネスアプリとして売り出せば、そいつが会社を買収してくれる＝お客さん増えるつーことになるわけよ。そういう相手を押さえるわけだ。。。
そんな相手っていうのは。。。
実は、ホリエモンではない。
ホリエモンは、いろんな業界の会社を買収しちゃってるので、１つの業界の目にはならない。。
通信かんけー業界で１人、いるよね（孫さん以外で）
でも、この業界は勝負きまったんで、この後は、ないかな。。
次の戦場は、金融か。。。コンテンツか。。。
もちろん、買収ってわけじゃなくっても、パワーが集中するようなところを狙うのは、筋のいい考え方なわけで、そういう意味で、下請けに強制力をもてる業界である、自動車っていうのは、目のいいつけどころがいい。
ただ、金融っていうことで、銀行。。。ってくると、
ユニシスがいるからなあ。。。
きっと、こーいう話って、社長あたりは、話たいことなんだけど、えらーい、技術の人たちなんかだと、きらうのよねー。こういうどろどろの話。
で、もう聞き飽きたカスタムの話にもって行きたがり、日本文化批判よ。。。
外国人が儲からないのは、そのパターンに入っちゃうからでしょ。
日本でパッケージで儲けるやつは、わけありで、パッケージさせたい人間に結びつく。そうすると、そのわけありのやつも、推進してくれるんで、儲かる。
既得権益の話になると、もっと、どろどろの面白い話になると思うんだけど。。。（それが、要求仕様書に結びつくんだけど。。。）
覚えていて、気乗りして、こんな話を見てくれている人が、多そうだったら書くわ。
m_pixyさんのブログ「PM見習いの読書日記」で、FTPのPASVモード の話題について書いてありました。（ここ）
テスト用のIISでPASVモードへの設定ができなくて悩む。多分IISではできないんじゃない？と詳しい人に言われる。
でもでも、Microsoftのサポートページのここに、こんなことが書いてあるけど。。
IIS ベースの FTP サービス (MSFTPSVC) では、アクティブ モード接続とパッシブ モード接続の両方がサポートされています。
サポートの言うことを、信じちゃいけない？？
やっぱ・・・
信じるものは。。。だまされる！？（＞＿＜！）
仮に、サーバーが対応してるなら、この人が指摘してるように、PASV（パッシブモード）は、クライアント側から指定ですよね！
指定の方法は、サポート君もいってるように、
250 CWD command successful.
と、サーバーからきたあとに、
PORT 192,168,4,29,31,255
のように、PORTをおくるところを、
PASV
って、送るんじゃなかったけ！？
とおもって、検索エンジンでしらべてみたら。。。
こんなの発見
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=15521&forum=12
なんか、いろいろありそう。。。
と思ったら、
FTPファイル送信サンプル。
PASV（パッシブ）モードでの接続を試み、PASVモードが使用できない場合は、ACTIVE（アクティブ）モードでファイルを送信。
なんつーページも発見！（ここ）
あとで、ゆっくりみよう。
まずは、おしごとおしごとと！
この前のブログのつづき、要求仕様書の規約IEEE 830に準拠して書くと、こまること。
その２：
２．機能の定義の仕方が、オブジェクト指向などと合わない可能性がある
→オブジェクト指向では、このフォーマットだと書きにくい
についてです
上記の規約において、機能用件をかくところについて。
以下のような項目がある。（ここから引用）
◆外部インタフェース
ソフトウェア・システムの入出力について具体的に説明する。ただし、インタフェースの説明を補足するものであるため、同じ情報は繰り返さないほうがいい。
◆機能
入力の受付と処理および出力の処理と作成時に必要となる基本的な動作を定義する。機能要求を下位機能や下位プロセスに分けることが適切な場合もある。ただしソフトウェア設計でも要求の機能階層と同じ階層構造で下位機能に分解されるとは限らないので注意しておく。
つまり、機能を記述する際に、入出力について、具体的に示さないといけない。
このとき、DFDであれば、入出力は明確になっているので、簡単。そのまま書けばいい。
そして、この規約が決まった当時、１９９８年ごろは、たいてい、機能の定義とは、（業務フローにおいても）
○○、■■を入力とし、△△を出力する
といった、入出力による、業務内容の規定が中心だった。だから、この形で、なんら困らない。
ところが、オブジェクト指向になると、出力や入力について、その出力物、（たとえば、受注伝票とか）入力データそのものをクラスとしてしまう形で、話をすすめることが可能となる。
とくに、要求仕様段階では、業務内容をアクティビティ図、ユースケース図（ユースケース）で定義してしまった場合、入出力データの具体的な内容について定義しないで話を進められる。
この進め方は、昔の人たちから見ると、プロセスを検証していないことになるので、大きなリスクを抱えると思うだろう。
（あとから、この入力では、このプロセスは、実施できないと気づくリスクとか。。たとえば、ピザを配達するといったとき、顧客データ（クラス）という形にまとめてしまうがゆえに、住所は、どこで取ってくるのか、誰がいつ入力するのかを検証しないで、あいまいにして話を進めることが可能になってしまうケースとか）
でも、いま、そんなことをいって、「だから、オブジェクト指向分析で、業務プロセスから追っていくのは危険です」といったら、「空気よめー」といわれてしまい、意見を言うのもはばかられる。ふつう。
なので、入出力データについて、オブジェクト指向分析でやった場合（＝最近の分析）だと、はっきりしない。
なお、上記のケースは、アクティビティ図、ユースケース図を中心にしたからで、オブジェクト指向における業務分析でも、図を、BPMNで記述した場合には、（って、どういう図？という場合には、ここをみてね）データオブジェクトに、データは、表現されるジャン！っていう意見もあると思います。
それはそれで、確かなのですが、データオブジェクトは、補足的な情報で、必ずしも、きっちりしっかり書くというわけではないし。。ということで、アクティビティ図、ユースケース図だけよりかはいいかもしれないけど、まだ、データオブジェクトを使って、プロセスの内容を検証できるかどうかがはっきりしないという点で、不十分な気がします。
こまった。どうしよう。
でも、逃げ手があるんだな。
IEEE 830では、機能の要求の書き方として、８とおり考えています。（さっきのところから引用）
A1 ：外部インタフェースを記述してから、運用状態ごとに機能要求を記述する
A2 ：運用状態ごとに、外部インタフェースと機能要求を記述する
A3 ：外部インタフェースを記述してから、ユーザー種別ごとに機能要求を記述する
A4 ：外部インタフェースを記述してから、オブジェクトごとに、属性と機能要求、メッセージを記述する
A5 ：外部インタフェースを記述してから、サービス種別ごとに、目的、刺激と応答、機能要求を記述する
A6 ：外部インタフェースを記述してから、刺激ごとに機能要求を記述する
A7 ：外部インタフェースを記述してから、データフロー図を用いて機能要求を階層的に記述する
A8 ：外部インタフェースを記述してから、複数の視点の組み合わせごとに機能要求を記述する。
このA1を、無理やりだけど、こう解釈してしまう。
３－１．外部インターフェース
ってかいて、このシステムの外部とやりとりする入出力データを書いてしまって、
３－２．機能
って書いて、詳細化した業務内容（アクティビティ図、ユースケース図）を、いっぺんにかいてはり込んじゃえば（＾＾；）
上の人とかには、ばれなさそう（＾＾；）
機能を書くとき、こーいう書き方をしてきた部下がいたら、「ウィリアムのいたずらって知ってる？」と聞いてみましょう（＾＾；）
そのやり方が問題で、このプロセスをデータで裏づけないあいまいさが、システムの現場を混乱させていたり、デスマーチを招いていることはたしかなんだけど、「だから、オブジェクト指向に問題がある」とか言い出したら、みんなから袋叩きにあって、だれも会社でいうことを聞いてくれなくなるのが現状でしょう。
だから、表面的には、「オブジェクト指向まんせー」っていっておいて、上みたいな仕様書を書く。
もちろん、個人的には、データの流れを追っていって、おかしいところをチェック、予防線を張っておくんだけど（インターフェースのサンプルデータを書くという方法でチェックする）、それは仕様書には書かないし、だれにもいわない。マネージャーやプロジェクトリーダーのお仕事っていうのは、そういう想定をどこまで読みきるかにあるよね！（実際、今、サンプルデータって、くるでしょ。それは、その危険性を理解して、わたしてくれているわけよ）。
当然、オブジェクト指向で、みんな考えて、安易にクラス化、隠蔽してしまうと、たいてい、こういうデータ間の矛盾があとから矢継ぎ早に出てくる（データがとってこれないっていうやつ）。そのとき、想定していた予防線を、「想定の範囲内です」といって、披露すればいい。
はじめからいったら、みんなにぼこぼこにされて、うつ病になっちゃうからね。
まあ、そのままつっぱしっても、どーしょーもなくなって、うつ病になってしまうんだが。。。。
今、手元に、いくつもケータイがあって、写真をばしばしとっているのですが、
気のせい？いや、ちがうな、たぶん。
ケータイの写真って、機種によって、かなり差が出る気がするんですよ。
もちろん、画素数の問題はあるんですけど、それ以上に、遠くの人物をうつしたときに、顔がはっきり映るかどうか。。。
これって、問題ですよねえ、きっと。。。
だって、ヨン様を写したいおばさんたち、絶対ヨン様の近くには、行けないので、遠くから、条件悪い中、写すことになる。でも、その写真がぼやーっとしてたら。。。
そのためにも（ヨン様のためかい ^^;）、
端末ごとに、同じ条件で写真をとってみましたあ！
っていうサイト、あればいいんだけど
あるのかなあ。。。
って、おもったら、ありました、ありましたよ！！
ここのサイト 携帯情報局
http://www.officedd.com/ktai/
で、そこに、見たい機種名があったら、その上の○○○○年○月の写真をクリックするとみえる。
それと、「うだうだいわせて」(ここ）に感想なんかも書いてある。。。この人、すげー！！
これから、参考にさせてもらいますう。。
ちょっと、面白いものをみつけたので、めもめも
ブログでばれる会社のレベル
http://allabout.co.jp/career/corporateit/closeup/CU20050911A/index.htm?FM=ranks
あとで、ひまなときよもうっと。
まずは、おしごとおしごと。
この記事をみてたら、こんな言葉がありました。
金融系の大手インテグレータA社のある事業部では、3年にわたって社員の2割以上に当たる150名強に対してPM教育を実施し、資格取得を推奨してきた。中期計画の3年が経過し評価を行ったところ、教育の実施者数、資格取得者数は目標をクリアしたものの、当初事業部トップが期待した、失敗プロジェクトの発生は減少したとはいい難い状況にある。
ちょっとまって。
この文章を読むと、まるで、プロジェクトマネージャーの技術が向上すると、プロジェクトが成功するように読める。
うーんと、ふつう、そうとはかきらないんじゃないか？
その発想って、
楽天が負けてます＝監督（マネージャー）の田尾さんを変えよう
っていうのと同じ。
あ、コンピューター業界って、こうやってかんがえるのかあ！（＠＿＠）！
この考えのおかしさは、王監督が指摘したとおり。（ここ）
監督にお金をかけるんだったら、選手にかけないとダメだ。
（監督）は指示するだけで、戦力ではない
つまり、プロジェクトの失敗は、マネージャーの責任なんだけど、
そのこと＝プロジェクトの失敗の原因は、マネージャーではない。
マネージャーが、システムを作るのではないのだら。
（つまり、マネージャーの責任と、自分でコントロールできる権限は、まったく一致しない。というか、ふつうは、責任の範囲は異常にひろいが、権限は、依然書いたとおり、サラリーマンの場合、０に近い。権限があると思ってるのは幻想である）
多くのケースでは、中堅になる、プロジェクトリーダーや、アーキテクトの人が選ぶアーキテクチャ、個々のプログラマの能力によって、かなりの部分が決まってしまう。
その、アーキテクトをはじめとするメンバーの人選権は、マネージャーにない。
つまり、へなちょこな人間をあつめて、マネージメントの力でどうにかしろというのは、無理。客も選べないから、システムができるかどうかはわからない。
システムの成功は、客の能力と、態度にも、かなり影響する。
つまり、会社の業績が悪いときに、社長が辞めるのと同じで、プロジェクトが失敗したら、マネージャーがクビになるのは当然だけど、じゃあ、社長がしっかりすれば、会社は建て直るか？というのと同じく、マネージャーを教育すれば、プロジェクトは成功するかというと、それは、違う。
そもそも、マネージャーがコントロールできる部分は、かなり限られている。
たとえば、画像処理のシステムの作り方をまったく知らない人たちが、フォトレタッチソフトの開発をするのは、無理があるし（パフォーマンスがでない）、逆に、フォトレタッチソフト開発のプロを集めて、フォトレタッチソフトを作るって言うのは、意見調節くらいで、マネージャーはあんまり、マネージメントはいらない。マネージメントの知識すらいらない。メンバーが勝手にやるから。
でも、田尾監督がやめたことからかんがえて、このコンピューター業界は、トップ（マネージャー）が無能だからと考えて、クビを切っておしまいの業界なんだろーなー。
まあ、こんな業界だから、プロジェクト失敗は続く・・・
いや、まてよ、そーじゃーないなあ。。。
ソフトバンクは強い。王監督は、監督の限界を知っている。
で、孫さんは、たしか、選手補強におかねをだしていたよなあ。。。
つーことは、この業界、わかるやつは、わかってつよくなる。
わからないやつは、永遠にわからないで、２局化する。
それが、ソフトバンクと、楽天の差だってことか。。。
いいかえると、プロジェクト成功する会社は、それだけの、開発メンバーを揃えた上で、マネージャーをつけるから、どんどん成功する。儲かる。
失敗する会社は、マネージャーいじくれば、どうにかなると思って、いじってばかりいるから、なおさら失敗して、デスマーチ専用会社となるってことか。。
なっとく。
モナーを３次元にしたゲームがあるみたい
ここ
http://www.darkstory.jp/event/050921_evt5.asp
これが、どんなに、のまネコと似てても、また仮に将来、のまネコグッズににたグッズがでたとしても、エイベックスさんは、文句言えないんだよね。きっと。
だって、エイベックスさんの主張は、「のまネコ」と「モナー」は違うんでしょ。
で、このゲームは「モナーです！」って言い切っているんだから。。
このゲームキャラの「モナー」が、いかに「のまネコ」とにてても、違うんだよ。きっと。
もし、このゲームキャラ（＝モナー）とのまネコが同じということを、エイベックスが主張したら。。。
自分のはじめの主張が崩れてしまうもん！
うーん、この会社が、グッズをだすかどうか、注目（＾＾）ｖ
９月２８日、「コピーされるほど儲かるシステム！開発日記」第２３号を出しました。
内容は、WindowsのMedia Playerなんかで使えるＤＲＭ（著作権管理）のＳＤＫ
Windows Media DRMについて、その概要？と、そこであがっているビジネスモデル
などについてです。
このブログに書いていない内容なので、
もし、見たい人は、バックナンバー（ここ）で見てください。
。。。いないとおもうけど！（＾＾；）
ということで、あとは決り文句。
２３号のメルマガについての、感想などはここの「コメント」にどうぞ！
メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム！開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参称してください
昨日のブログで書いた、要求仕様書の規約IEEE830だが、実際の仕様書に起こそうとすると、こまることがある。ざっと考えて以下の３点
１．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない
２．機能の定義の仕方が、オブジェクト指向などと合わない可能性がある
→オブジェクト指向では、このフォーマットだと書きにくい
ちょっと、かえればいいだけなんだけどね。
３．外部設計の規約IEEE 1016と、あわせてつかうと、へなちょこになる
→つーか、IEEE1016が、へなちょこ！
で、今回は、「１．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない」について。
で、この話をする前提として、IEEE830の内容は、このページを参考にしています。
１．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない
ビジネスプロセスを創出する場合、まあ、いろいろあるわけなんですけど、（で、はぶさんはプロセスからと主張するのですが（ここ））、まあ、大きく２つのケースに分けちゃえるんじゃないでしょーか？
（あ）プロセスからきまっている。
→じつは、その上に、どんなものを乗せても、扱ってもＯＫ！
（い）扱う商品によって、業務内容が決まる
なんですが、まあ、（い）のケースで考えたほうが無難だったりします。
で、（い）の場合、ビジネス構築の流れは、こんなかんじ。
（１）はじめに、なにを（どんな商品サービス）を、どうやって売るか（カネを回収するか）を決める
ここは、社長など、経営陣が決めることが多い。
（２）次に、人（幹部連中）をあつめる
最近のビジネスは、自分でノウハウを持っているというより、経営陣は、Know Whoであって、できそうな人を知っている。あとは、その人に任せるというかんじも、けっこうある。
（３）幹部が、業務プロセスを決める
って感じになる。。
で、そういう流れのビジネスについて、システム開発するとする。
このとき、いきなり、業務プロセスの機能にいってしまうと、わかりにくい。
たとえば、ドメイン取得サービス業務をかんがえよう。
ドメイン取得業務において、いきなりプロセスにはいると、
こんなことばが、いきなりでてくることになる
JPRSに、申請する
？？わかんない？？。
まず、商品として、jp,comなど、あつかうドメインの説明があって、
jpドメインの場合の登場人物として、JPRS（日本レジストリサービス）があることを理解しないと、そのあとのプロセスすべてが？？？マークになってしまうだろう。
（ＪＰドメインの取得には、JPRSの指定業者になるか、指定業者の代理店になるなどの手がある）
もちろん、JPを扱わない場合、JPRSはしらなくていいし、代理店、たとえば、お名前.comの代理店であれば、お名前の仕組みだけを知っていればいいことになるからJPRSはしらなくていい。
つまり、商品と、仕入れ元、仕入先と現金回収者などなどがわかんないと、プロセスがわかんないときがある。
てなわけで、登場人物と、ものの説明がいるんだけど、このIEEE830のフォーマットだと、その辺の話をぜーんぶ、用語定義にかかないといけなさそう（順番的に）。。。
そうすると、「辞典よめー」みたいなかんじになっちゃいそーで、わけわからなそーなのよね。
なんで、ビジネスのカラクリ（登場人物の説明と、その登場人物間にながれる、モノとカネの交換の静的な側面）を、機能を説明する前、用語定義の前にかるく説明したいのよね。
そこで、システム概要みたいなのは、「はじめに」の最後じゃなくって、はじめにもってきちゃって、そこで、システムの目的、システムの登場人物、システムのカラクリと全体構成を説明しちゃいたいのよ。
そーすると、ビジネスの考え方の流れに沿ってるし、経営陣は、そこだけ見れば、いいわけだから（あとは、幹部が読めばいい）
で、用語定義は、付録に持っていきたいなあ。。いっぱいあるしい。。見なくていいことも多いしい。。
中小企業診断士ネタを書いたら、ものすごく、見ている人が増えたので、みんな関心あるのかと思い、付け足しの情報を載せます。
まず、中小企業診断士制度改正について載っているホームページについて。
中小企業庁のホームページいけば、すぐに見つかるのかと思ったら、
わ、わかんないじゃないの（－＿－；）。
このページに載っています。
http://www.chusho.meti.go.jp/keiei/koyou/18fyshindan_kaisei.htm
で、ウィリアムのいたずらが、登録証を再発行してもらったときに、一緒に入ってた紙というのは、以下の２つのＰＤＦです（リンクしてあります。ひらくと、ＰＤＦです）。
「中小企業診断士制度の見直しについて」
「中小企業診断士制度の見直しに係るQ&A集」
で、前回Ｑ＆Ａについて、書かなかったけど、そこで大事なことがあった。
診断士は、呼称独占（業務は独占していない。コンサルは、だれがやってもいい。やってはいけないのは、中小企業診断士でない人が、診断士と、名乗る（呼称）すること）なのですが、
休止中の診断士について、以下のように書かれています。
Ｑ４．休止中は「中小企業診断士」を名乗ってもよいのか。
Ａ 休止中「中小企業診断士」を名乗ることはできません。
つーことは、診断士とっても、休止中は意味ない？？
で、再開についてなんだけど。。
Ｑ５．休止中であっても更新研修を受講することはできるのか。
Ａ 更新研修を実施する登録研修機関の判断によります。
登録研修機関（中小企業診断協会とか）の判断って（＾＾；）
でも、受講できなければ、再開できない＝休止しても再開できなくなってしまうう。。
診断協会の判断が重要だよね！
でも、それが、どこに載ってるかわかんないぞー、診断協会！
なーんてかいたら、「会報よめー」とか、言われたりして（＾＾；）
ごめん、さいきん、よんでないかもー！！
きのう、放送大学の心理学の番組をみていたのですが、
千葉県のある私立大学（あえて、名前をふせます）の学生さんに、以下の実験をやった結果が映し出されていました。
＜実験＞
（１）「う」で始まる単語と「う」で終わる単語、どっちが多いと思う？
（２）さいころで
１，１，１，１，１がでる確率と
５，２，３，２，４がでる確率（数字は間違ってるかも）と
どっちが大きい？
（３）計算しないで、以下の問題に答えて（つまり、大体このくらいでよい）
１Ｘ２Ｘ３Ｘ４Ｘ５Ｘ６Ｘ７Ｘ８Ｘ９
９Ｘ８Ｘ７Ｘ６Ｘ５Ｘ４Ｘ３Ｘ２Ｘ１
で、信じられない結果が、画面にくりひろげられるのだ！！
大学生にきいてるんだよおー
（１）は、わかんなくって、まあ、当然
→ちなみに、うで終わる言葉のほうが、多いそうだ
（２）なんだけど、確率的に同じっていうことは、すぐにわかるよねえ、
どちらも、同じ回数投げて、ある特定の数字がでる確率なんだから。
ところがね、「同じ」と答えたのが１人だけなのよ。。。
先生も、「確率の初歩を知っていたら、だれでもわかる問題」っていってたけど、
みんな ５，２，３，２，４がでる確率（数字は間違ってるかも）のほうが大きいっていうのね！
（３）にいたっては、すごい！
１００以下の数字をいうのよ。
だって、いくら計算するな！ったって、９Ｘ８＝７２なんだから、で、それに７かけてるんだから、１００以上になるのはあきらか、最低でも１０００以上っていうか、多分１万以上っておもうよねえ。。。
でもね、平均値、下のほうは、９００いくつなのよ（＠＿＠！）
上のほうは、１０００００をこすんだけど、それも１人、５０００００って答えた人がいたから。。。って、その人が、まともな感覚なんですう！（計算してもらうとわかるけど。。。）
で、そのあと、先生は、いろんなこといってたけど、
ウィリアムのいたずらからしてみれは、いえる結果はただひとつ
その大学の学生は、馬鹿だ！！
たとえ、彼らが文系だとしても。。。
１人や、２人ならわかるよ。。何人も、そんな答えをするんだよお！！
うーん、大学行く前に、高校やり直したほうが、いい気がするんだけどお。。
大学の先生も大変。。
つーか、そういう人たちが、新卒で入ってくるとすると。。
うーん、期待はできんな。。
人材について、書いているホームページが多かったので、コンピューター業界に入ってくるかもしれない人材の問題として、こんな話題もとりあげてみました。
前のブログで、要求仕様書について、規約があると書いたので、（ここ)今日は、その話。
日本には、そういった規約はないのですが、アメリカでは、IEEEで規約があります。
要求仕様の構成として、IEEE Std 830-1998というのがあります。
IEEEのサイトで、その内容が書いてあるのは、ここ（もちろん英語）
で、それにもとずいて、説明がしてある（日本語です。NTTデータのかたが説明）のが、
ここ
http://www.bcm.co.jp/site/2004/2004Dec/04-youkyuu-kougaku-12/04-youkyuu-kougaku-12.htm
そこには、その構成が日本語で書いてあります。気になる人はみてください。
で、実は、最近よく売れている、要求仕様書の本は、この構成を念頭に入れて、書いているとおもわれます。
今、要求仕様書関連で売れてる本といえば、この２冊だと思います。
○ SEのための仕様の基本
翔泳社 ISBN 4-7981-0803-0
○図解入門 よくわかる最新
システム開発者のための
要求定義の基本と仕組み
秀和システム ISBN 4-7980-1122-3
で、「SEのための仕様の基本」は、６２ページから６３ページがIEEEの規約、６３から６７ページがサンプルです。この本では、本文中にIEEE Std 830-1984と明記してあります（1998より古い規約だが、内容はほぼ同じ）。
ただし、サンプルは、実際の実務内容からみると、ちょっと簡単すぎる例かもお？？
「図解入門」のほう（秀和システムの）は、２０８ページから２０９ページが規約をちょっとひねって、見出しをつけてあります。で、２１０ページから２１４ページが書き方の説明です。
実は、IEEE Std 830は、組み込みのようなものの場合はいいのですが、普通の業務では、「製品の」とかでてきてしまい、書きにくいかも（まあ、かけないことはないんだけど）なんで、ちょっとひねりを加えたほうが書きやすい。
てな話は、また今度、時間があって、覚えていたらします。
そこで、疑問なのは、秀和システムのほうの本の中に、わたしが、ざっと目を通したところ、IEEE Std 830のことが、書かれていないようなきがするんですよ（よく見ると書いてあるのかなあ。。）
なぜなんだろう。。。IEEEをもとに、一部使いやすいように修正と明記すれば、ちゃんとしたIEEEの規約にもとすいた内容について、書いてある本ということで、宣伝になると思うんだけど。
いまのように、書いてない場合、筆者が勝手に考えたもののように受け取られてしまわれないかな・・そしたら、それを読むより、IEEEに基づいて書いてある翔泳社の本のほうが。。っていうことにならないかなあ！？
なんで、明記したほうがいいとおもうんだけどなあ。。
いや、まてよ、この規約、IEEE(Institute of Electronic and Electronics Engineers:米国電気電子技術協会）の規約。。。っていうことは、アメリカのきやく。
ハリケーンなんかの対応をみて、もはやアメリカの権威は落ちている。。そんな規約に従うっていうのは、逆効果と思って？？
でも、でもだよ、この本ができたのは、ハリケーンのずーっと前ですよ。。。
。。。さては、予知した！
この本の関係者は、超能力者！？
なら、きっと、徳川埋蔵金も、探し当てているに違いない！！
そうそう、徳川埋蔵金って、やっぱ、そーいう超能力にたよらないと、見つかんないと思うんですよ。。。
って、ぜーんぜんコンピューターの話から、それてきたので、この続きを見たい人は、本家へ
注意：あんまりにも、くだらなすぎるお話ですよ！怒り出すくらい。それでも、見たい！という人だけ、どーぞ！
Ｐ．Ｓ でも、たぶん、関係者は超能力者では、ないと思います。
もし、超能力者で、徳川埋蔵金をみつけたら、たぶん、お仕事なんて、してないでしょうから。。。
引越しのとき、診断士の登録証がなくなってしまい（って、ウィリアムのいたずらがなくしたんじゃなくって、大家さんが。。。（＞＿＜！）とか言いたいところだが、「そーいう家に住むお前がわるい！」といわれると、まったく反論できないので、私がわるいんでしょう。。世の中的には）、登録証の再発行をしてもらったのですが、その登録証が、昨日きました（２ヶ月かかりました）。
で、その登録証と一緒にに、なにやら、いっぱい紙が。。。
「１８年度以降からの制度改正の内容につきまして、別紙のとおりご案内」。。。ってことで、改正内容について書いた紙がはいってました。
で、私がもらって、どうしろというの。。更新内容の変更は、関係あるけど、試験の改正までは、関係ないと思うんだけど。。。ブログに書いて、みんなに知らせろとでも。。。？？
うん、そうなのかな（いや、そういう意味じゃないと思うけど ＾＾；）
っていうことで、そこに書いてあった、診断士試験内容の改正点を書いておきます。
試験科目に、「経営情報システム」があるので、まあ、コンピューター関係ということで、このブログにのせておきます。
ちなみに、更新の改正点に関しては、ここに、すでに書きました。
あと、試験に受かったけど、すぐに診断士をしない人のための休業制度に関しては、最後に書いておきました。
中小企業診断士試験の改正点は、以下の４つ（説明文は、３，４をまとめて３つになってます）
１．科目合格制
一次試験、一発合格でなくてよいという話は流れていると思います。
問題は、科目合格なのですが、３年間有効です（申請必要）
２．科目ごとの年度間の難易度を考慮する
３．科目構成の見直し＝一次試験の科目が変わります
新規事業開発と助言理論が一次からなくなり、２次の範囲になります。
４．科目の重点付け＝時間配分がかわります。
中核的な知識科目（３科目）の試験時間は９０分１００点、それ以外は、６０分１００点になります。
３、４をあわせると、結果として、以下の試験構成と時間になります。
＜一次試験＞
・中小企業政策／中小企業経営 ９０分１００点
・企業経営理論 ９０分１００点
・運営管理 ９０分１００点
・財務・会計 ６０分１００点
・経済学・経済政策 ６０分１００点
・経営法務 ６０分１００点
・経営情報システム ６０分１００点
＜２次試験＞
・中小企業の診断および助言に関する実務の事例
・助言に関する能力
→新規事業開発、助言理論の内容を含む
＜３次（実習）＞
・経営診断１５日以上もしくは、診断協会が行う３次実習（ってふつういうやつ）
試験組？？でない、大学校の場合の取得に関しての変更点
・一次試験を受からなくては、ならない
・（中小企業）大学校だけでなく、登録された養成機関（民間機関）でもできるようになった
・大学校、登録養成機関の出身者は、３次実習は必要なく、いきなり登録できる
→いきなり休業届けもＯＫみたいに見えるけど。。
で、その、休業制度について、
受かっても、自分の会社の業務改善報告書を出して、それで、会社から、コンサルティング活動の紙にはんこを押してくれない、いじわるな会社に勤めちゃってるあなた（はんこおしてくれれば、ＯＫなことは、ここに示した）や、そもそも、会社につとめてない人で、更新要件満たせそうもない場合、休業できる。
１５年間。申請は必要。
再開条件は、知識の補充（＝理論更新研修）５回分と、１５日以上の実習を再開３年以内に。。。って、変だよねえ。。３年で理論研修５回？？１年に２回受けるの？？受けられるのかなあ？？
あと、Ｑ＆Ａ集とか、入ってたけど、こんなところであります。
報告おわり！！
Ｐ．Ｓやっぱ、助言理論（たしか、コーチング）は、はずされたのね。。そうだよねえ。
新規事業開発なくなる前に、どんなことやってるのか、テキスト立ち読みしよーっと！
（買う気はない。。。古本屋かBook Offで超安売りしてないかぎり）
アークランプさんのブログオープンであれば技術力は（そんなに）いらないをみていて、表題のように思いました。ちなみに、表題の言葉は、女王の教室の真矢先生の言葉「特権階級の人があなたたちに望んでいるのは、ずっと愚かでいてくれること」から、インスパイアされて、思いました。
今日は、そんなわけで、オープンソフトを使わない理由を、アーキ（方式部隊）と、共通部隊の立場から。。。
なお、はじめにお断りしておきます。この内容は、アークランプさんの意見、主張とは関係ありません。そのブログに対して反論しているものではありません。ただ、インスパイアされて思いついたというだけの話です（そのため、トラックバックなどもしてないです）。たんに、話のはじまりだけがその話を受けているという世間話なのです。
まあ、プロジェクトのフレームワークは、方式がきめ、一部のプロジェクトでは、共通も参加するってな感じになるんじゃないかと思います。で、そこで問題なんですけど、
アークランプさんの上記のブログでは、どーも話の流れが、
・オープンソースを使うか
・商用製品を使うか
の２つに１つのような印象を受けます。でも、ある程度の開発規模のものになると、もうひとつ、「自分でつくっちゃえば！！」という話がでてきて、そこに落ち着くケースも多い気がします（ウィリアムのいたずらの経験だけなので、ほかのプロジェクトでもそうというわけではないけど）。
さあ、みなさん、冷静になって考えてくださいね！
Javaをはじめたとします。どこのサイトみますか？
たぶん、JavaでHello Worldのサイトですよね。
つーことは、そんなに上級者ではないひと、ちょっとアークランプさんのプログラマレベルは、perlくわしくないんで、理解できないんだけど、たぶんレベル４くらいの人がみるサイトですよね。じゃあ、このサイトの知識しかなかったとしましょう。そこで、
クライアントサーバーを実現したいので、クライアントとサーバーでつうしんできるようにしてくれ。ただし、オープンソフトをつかってはいかん！
といわれたらどうしますか？
たぶん、全部読むと、Socketが使えそう！ということで、Socketのところを参考にやりますよね。で、あとはHTTPプロトコルがわかれば、Webサーバーの動きをするものはできますよね。
そして、その受け取ったデータをもとに、プログラムを動かすところは、リフレクション編をみればやりかたはわかる。つーことで、Ｔｏｍｃａｔもどきまで、つくれたりします。
（あ、あと、クライアントサーバー間のデータ受け渡しには、シリアライズの知識も要るけど）
つまりですねえ、オープンソフトを使わない気になれば、Ｊａｖａの上記のような基本的な知識で、考えれば、できちゃうんですよ。ところが、オープンソースになると、いろーんな知識が必要になってくるわけです。
で、そこで、ワーカーさんに流す場合、全員が、そのオープンソースの知識を身につけてもらって、さらに、場合によっては、自分たちで解析し、そのうえ、さらに、最悪の場合は、できないかもしれない。。。その状態を選んでまで、オープンソースを使うか、それとも、自分たちで１からつくるか？というとねえ。。。
つくりましょっか（＾＾）ｖって話で、落ち着いちゃったりする。
そうすると、オープンソースは、みんながテストしているので、品質が安定し。。。とか言う話を言う若手がいるけど、これは、いわないほうがいい。
品質が安定しって、言い切れるのか？証明してみろって言われたら、どうします。。。
実は、オープンシステムは、ここが問題で、まんべんなくテストしたことを保障してるわけではないのよ。つまり、自分たちの使うところはみんなチェックしてるだろうけど、使わないところまでチェックしてるかどうかわからないのよ。
パッケージソフト会社に勤めていて、ベータでお客さんに流している人なんか、わかってくれると思うけど、客から上がってくる報告は、自分の使うところかつ、使えるところだけなのよ。
バグがあると、客は使わない。で、それは、報告しないわけ（そんな報告してる暇はない）
てなことで、オープンソースも、特定の箇所にバグが偏在し、今回、そのプログラムを使ってしまう危険性がある。これが、せめられる１点。
でも、こんなことは、ちいさなことなのよ。
いまの、オープンソースには、致命的な欠点があるのよ。
余計な機能がありすぎる。。。
オープンソースも、バージョンアップを重ね、広い人たちに使ってもらうようになった。それにつれて、機能があがった。しかし、それにつれて、ソースも大きくなっていくのが普通。
でも、自分のプロジェクトで全機能をつかうのは、まれ。普通、一部しか使わない。
つーことはだよ。。。。たとえば、自分たちの機能を実現するのに１０００ステップで十分だったとする。でも、オープンなソフトを使うと、そのソフトは、何十万ステップもあるとしたら。。。どっちのほうが、バグが多い？？
一概には言えないのよ。。。１０００ステップのほうが、たいていは、少ないけどね。
さらに、解析するにも、どっから手をつけていいかわかんない。。。。
解析するより、１から作ったほうが、普通、早いし、
解析して手をいれるより１から作ったほうが、品質も、安定したりする。。
つまり、オープンソースは、みんなに使ってもらおうとすると、巨大化し、理論も複雑になる。その複雑な理論で遊ぶのが楽しい人たちは、それはそれでいいんだけど、こと、大きな開発になると、うーん、その複雑なもの、お守りするくらいなら、いっそのこと、つくっちゃえば！っていうことになる。
で、実際、作るとなった場合、これは、発想力の問題（apacheをみて、あ、ソケット通信をＨＴＴＰプロトコルでやってる、っていうことは、ソケット通信部分をJavaでくめばいいだけね！と発想できるか）であって、技術的には、レベルは、さほどたかくなくていいのよ。
（JavaでHello Worldを読んで理解できるレベル）。
でも、なんーか、いまの世の中をみると、ウィリアムのいたずらたちが、まるでばかで、オープンソフトなんか、まったく作れるレベルにない！ということを、ハッカーさんたちがきめつけて、それに周りの付き人たちが、難しい言葉を並べて、神学論争してるように見えるのよねー
え、オブジェクト指向の資格の合格証書が免罪符に見えてきたって（＾＾）
やっぱ、ハッカーさんたちや研究者、本を書く人たちから見ると、自分たちは天才で、
「ハッカーの人があなたたちに望んでいるのは、ずっと愚かでいてくれること」、
オープンソースのプログラムなんて、絶対作れないし、作っても、非効率的だと思ってくれること。。。
のようにみえちゃうんだけどなあ。。。
でもさあ、大きなプロジェクトのアーキも、共通も、そこまでおばかじゃないから、「自分たちのプロジェクトに必要なものに限定すれば」その程度のものは、作れることは、ぐるっとおみとおし！だよ（＾＾）ｖ
アクセス
トータル
ランキング
