デルのノートパソコンの不具合、日本製品もあるっていうけど・・・

ここのニュース
＜デル＞ノート型ＰＣの充電池に不具合　自主回収へ
http://headlines.yahoo.co.jp/hl?a=20060815-00000028-mai-bus_all

によると（以下斜体は上記ニュースより引用）

回収対象は０４年４月～０６年７月１８日に出荷された、「ラティチュード」、「プレシジョン」、「インスパイロン」、「ＸＰＳ」の４ブランド３３モデルと、単品売りしたソニー製リチウムイオン電池で、電池部分を無償交換する。
　専用相談窓口はフリーダイヤルで０１２０・１９８・４３７。８月中は毎日午前９時から午後８時まで。９月以降は日曜・祝日を除く同時間帯で受け付ける。


だそうだけど、該当製品って多いんですかねえ。。
ちなみにウィリアムのいたずらのノートパソコン（今使っている）のはＨＰ製なんだけどね。

ウィルス対策サービスを”無料”提供－マイクロソフト－、ってまじっすか（＠＿＠！）

ここのニュース
マイクロソフト、ウィルス対策サービスを無料提供
http://news.goo.ne.jp/news/asahi/keizai/20060815/K2006081505190.html

えーっとえーっとえーっと。。。
これって、マイクロソフトが、無料でアンチウィルスソフトを提供してくれるって意味なんでしょうか？どーなのどーなの？？
　だとしたら、ウィルスソフトを提供してる、ソースネクストやシマンテックは、どーなるの？？

　つーか、本当にそういう意味？？

　あたまこんらん？？

国の人事院のシステムがITmediaで、たたかれているね！でも、国の改善方向はわけわからんぞ。。

　ITMediaで、電子政府の問題点を指摘するシリーズ、２回目に、

　人事院の人事・給与業務システムについて、叩いているね！

　ここ
浮き彫りになったEA導入の功罪 (1/2)
http://www.itmedia.co.jp/enterprise/articles/0608/10/news004.html

この指摘において（以下斜体は上記記事より引用）


　人事・給与業務システムは、これをベースにあくまで自庁向けに開発していたのである。ところが2003年7月、電子政府構築計画が決まり、急きょ府省共通システムの第一弾に仕立てられてしまった。

　この時点で、各省庁の給与体系、職位・職級制度をヒアリングすべきだったのだ。それを人事院は怠った。というより、「毎年、人事院勧告（国家公務員の給与）を一方的に押し付けるだけの役所に、そんなインセンティブが働くわけがない」（内閣府幹部）。職員700人の人事院に、国税庁や社会保険庁など2万人を超える大規模官庁にも通用する共通システムをつくらせること自体、無理だったと言える。


　ここまでの論理はある意味、正しいと思う。開発の場合、「各省庁の給与体系、職位・職級制度を」調べるべきでしょう。

　ただ、ヒアリングは、無理。ここで、やるべきことは、まず、その体系をドキュメント（この場合、なんか法律があるのかな）でしらべ、その法律がちょっとやそっとかわっても、問題とならない柔軟なシステム（方式設計）を考えるべきです。

　たとえば、介護保険のシステムにおいて、介護サービスの点数
　　身体介護4夜間３級
　（でたらめ書いてます。こういう基準がなかったらごめん　＾＾；）
　などという基準は、計算式で求まりますが、実は、ふつうは計算式では求めません。
　ＤＢまたはファイルに、「身体介護4夜間３級」だったら、いくらという金額が入っています。
　これは、計算で求めないことにより、どのように、介護の仕組みが変わってもＯＫになるように
するためにやるテクニックつーか、なんちゅーか、ほんちゅーかなんだけど、
そーいうふうな柔軟な方式設計をするのが、ふつうです。

注：介護保険の制度は２年で変わり、５年くらいで見直しがあるため、
　　短期間に大幅に変わる危険があるのです。
　　つーか、大幅に変わりましたよ！

---

　でも、問題は、そこにあるんじゃなくって、そもそもＥＡというアメリカの方式は優れているのか？という問題。これは、日本の風土にあわないと思う。
　アメリカは、トップダウンでも可能である。それはなぜかというと、ブルーカラーの知識や技能というのを求めていない。
　かれらは、固定給であり、言われたマニュアルを基本的にこなす仕事である。つまり、マニュアル＋ホワイトカラーの話を聞けば、業務全体が見れるので、トップダウンのマネージメントが可能なのである。

　しかし、日本の場合は、野中先生のおっしゃる、「ミドルアップダウン型」である。手法や情報は、一般に課長（場合によっては係長・主任、ないしは部長）にあつまるようになっている。
　だからこそ２００７年問題（ミドルがやめてしまう）が問題なんであって、トップダウンなら、ミドルがやめても問題ないはずだ。

　ちなみに、国の場合は、このミドルは、筆頭課長代理になるのかしら。。

　したがって、これらの人の頭の中にある業務を体系化し、それを下や上の人間に確認を取りながら、ミドル＝課長や係長・主任クラスを動かして、どういう方向に進んでいくのかを議論しないと、システムはまとまらない。この場合、ＥＡのようなトップダウン手法はなじまない。

---

　では、どういう手法が行われるか、というと、民間の合併を考えればいい。

合併の場合

１．お互いの会社の業務フローと、用語集を作る
２．まず、業務のよみかえをして、お互いの共通点、相違点をみつける
３．似ている業務から順に、どっちかのプロセスに吸収させるか、それとも新しく作るかを話し合い、
４．決まった業務プロセスに対して、ミドルレベル、トップレベルで合意を得る。
５．決まった業務プロセスで、新しく開発が必要なら、開発する。

っていうような手法をとっていき、どんどん範囲を拡張していくと思う。

---

　というように、今回のシステムの問題は、アメリカのＥＡというシステム設計論を無批判に導入し、ミドルの人たちの業務内容分析や、それをどう統合して、１つの方向性をだしていくか（方向性によっては、手直ししないという結論になることも、十分に考えられる。たとえば、人事院の省力化とか、そんなに、大事なのか？）という部分を考えなかったことによる。

　方式設計は、実は現場のミドルの考えをどのようなシステムに置き換えるのが最適かという部分にかかわる。ここを議論しない（というかできない）ということが、ミドル置き去り、官庁というユーザー置き去りな点を物語っていると思う。

　じゃあ、どういう方法がっていうと、上に書いたわけなんだけど、この方法、ふつーに使う方法うなわけでえ。。。つまりね、無理にあめーりかんな概念を取り入れる必要はないわけよ。。

---

なのになのに、ここ
問われるGPMOの調整機能 (2/2)
http://www.itmedia.co.jp/enterprise/articles/0608/15/news002_2.html
によると。。。
（以下、斜体は、上記記事より引用）


だからこそ、LOHAS（ロハス）化！―。

　GPMOと一部省庁の現場では今、性急に結果を求めるのではなく、継続性に基づく、ゆとりあるオルタナティヴ（代替計画）を模索するこの標語が、合言葉となりつつある。


は？、わけわかんねー。

システム開発のロハス化ってなによ（＞＿＜！）

お役人は、またわけわかんないアメリカのはやり言葉を導入して、けむにまこうとしてるう。。
結局、アメリカのはやり言葉をもってくれば、責任とらなくていいからでしょ。
アメリカと日本は文化ちがうんだから、それもってきても、うまくいかないなんて、指摘するのはウィリアムのいたずらだけだもんねえ。。


つまり、最適化計画を改めて検証し、実行可能な開発スケジュールを再設定することだ。その過程で不要不急なシステムは捨てる英断、すなわち、行政官が最も嫌う「誤りを認める」勇気が問われるだろう。


　だからあ、検証すんのはいいんだけどさあ、その検証ロジックをどーすんのよ。

　検証ロジックがただしくなければ、検証した「最適化計画」も間違ってるし、それがまちがってたら、そこから出てくる「実行可能な開発スケジュール」も間違っているわけでえ。。

　リスケしたって、いみないじゃーん！

　現実的にはＥＡのようなトップダウンでは、まちがいが生じるわけで（吸収・合併は無理かどうか、トップダウンでは見えない）、各省庁の業務内容から、ミドルが、これならできるという吸収、統合していくという過程を経なきゃいけないっていうのに（＝もちろん、開発だけでなく、この過程で、ミドルの業務レベルの協力が居る）。。。

また、わけわかんない合言葉で、わけわかんないリスケして、結局何開発したらいいかわかんないっていう状態で、開発がえいやとやると文句言われて、開発は悩んで精神病院にいくと。。

　うーん、すくわれねーや、この業界！

（もっとも、人事院の開発のえらーい人が、そこに気づけば、話は別だが。。
　気づいていたら、ここまでひどくは、ならないよな。。）

いろいろなフレームワーク等をＭＶＣの枠組みで整理すると、こんなかんじ？

いろいろ反論があると思いますが、そいつを一切無視して（＾＾）
最近話題のいろんなフレームワークなりなんなりを、
ＭＶＣ，つまり、

Ｖｉｅｗ　　　：ユーザーにみえるとこ
Ｃｏｎｔｒｏｌ：ＶｉｅｗとＭｏｄｅｌをつなぐとこ
Ｍｏｄｅｌ　　：実際の業務ロジックで以下に分かれる
　　　　　　　　　セッション　：エンティティを利用／管理して、業務をこなす
　　　　　　　　　エンティティ：データとかの入出力

ってかたちで整理すると、以下のようなかんじかなあ。。。




　帳票はモデルなの？っていうと？？だけど、まあ、モデルとして整理しておきました。
　呼び出し口はモデルのところなんで。。
　びみょーにかぶっているところなどあるんだけど、そんなのは目をつぶると、大雑把にこんなかんじと。。

　で、クライアントとサーバーの切れ目は、っていうとコントロール部分までクライアントで持って、モデル部分のＳＯＡの呼び出しまでをやってしまうケースもあるし、逆に、サーバーにコントローラーを置いて、そこからモデルを起動するっていうこともあるので、

Ｖｉｅｗの終わりのほうから、モデルのセッションの入り口くらいまでのところ

に、クライアントとサーバーの切れ目はありそう。どこで切るかは、システムによって違うと。。また、サーバーが２段、３段になるケースもあるし。。

　てなとこですかね。。