結局、これだけ聞き出せば、業務分析は、ＤＯＡでもオブジェクト指向でも落とせる。。ハズ（＾＾；）

　まえに、ここで書いたシートをもとに、

　　　分析のアクティビティ図、ユースケース図、
　　　実装のクラス図、シーケンス図、
　　　要求のスノーカード
　　　データ定義のＥＲ図

に展開できるって言うことを、ここに書いた。

　今日は、さらにそれを深堀りして、なにをヒアリングで聞き出せば、ＤＯＡの図やオブジェクト指向の図に展開できるか？ということについて、書きたい。

---

■聞き出すのは５Ｗ１Ｈのうち。。。

　先に結論を書いてしまおう。
　まず、５Ｗ１Ｈを全部ききだしてもいいんだけど、
　以下の●をついている項目を、とりあえず聞き出せば展開できる。

●いつ
　どこで
●だれが
●なにを
　なぜ
●どのように

　このうち、「どこで」は、必要ないこともあるけど、分かるんだったら聞き出したほうがいい。

　なぜは、無理にききださなくてもいい。
　「なんで、そんなことをしているんですか？」
　って聞くと、これは、疑問なんだけど、聞き方によっては（というか、受け取り方によって）「なぜそんなことをしているのか？する必要はない」と反語表現に聞こえてしまい、ユーザーとのラポート関係が解けてしまうことがある。

　さらに、もっというと、なぜやっているか、自分では分からないこともある
　（前任者から引き継いだ）。ところが、全体から見ると、そこで、それをしないと困るという
こともある。この場合、どんなにその人を問い詰めても答えは出ない。
　なので、これは、書かなくてもいい。
　なお、なぜというのは、「なんのためにするのか？」というより、「これをしなかったらどうなるのか」という立場で聞いたほうがいい。

　で、問題は、上記の●のついたやつ。
　これを、単純に聞いても、システムはできないのだ。
　つまり、聞くポイントがちょっとちがう。

---

■「いつ」とは、タイミングで、「時間」、「順番」、「条件」のきまりを聞く

　いつというのは、

　　　何年何月何日何曜日何時何分何秒地球が何回、回ったとき

　というのを聞くという意味では「ない」

　「どのように」つまり、ある作業をする（＝アクティビティ、ユースケース）とき、

（１）いつでもやってＯＫなのか
（２）何時何分とか、月何回とか、決まった時間があるのか？
（３）ある作業の前とか、この作業が終わったらとかいう、順番があるのか？
（４）何かがないときとかいう、条件があるのか？

　というのを聞きます。
　つまり、いつでもＯＫでない場合は、
　　時間、順番、条件のきまり
　についてききます。これが、「いつ」にあたります。

　前の図では、前のアクティビティ、あとのアクティビティで表現します。

---

■「なにを」とは、入出力のこと

　「何を」という、「何」は、もの、エンティティ（のうち、リソース）を指します。
　なので、「なにを」とは　「どのように」つまり、ある作業をする（＝アクティビティ、ユースケース）ときの、

・入力
・出力
・入出力

について、聞きます。これは、まず、エンティティとして、つまり、モノレベルで抑えた後、どのようにを具体的に書いていく中で、モノの属性値レベルにまで落として考えます。

　前の図では、入出力で表現します。

---

■「どのように」というのは、手順内容になります

　これは、上記の「なにを」にかかれたものを利用して、どのように処理するのか、
　その結果、なにができるのか？ということを書きます。

　ここで、入力から出力が導き出せることが確認できないといけません。

　前の図では、内容で表現します。

---

■とりあえず、「いつ」、「なにを」、「どのように」でプログラムには落とせる

　これだけあると、
　　オブジェクト指向だと、クラス図とシーケンス図、
　　ＤＯＡだとＥＲとＤＦＤ
　はかけるので、プログラムには、落とし込めます。
　あとは、トップの「システム全体」から、プログラム可能レベルまで、この「いつ」、「なにを」、「どのように」を順番に落としこめるかという話になります。

　なお、落とし込みのレベルについては、前の図では、上位レベルを「親アクティビティ名」で表現します。

　そのシートのアクティビティ名は「アクティビティ名」に書きます。

　下位レベルを、内容の「子アクティビティ名」で書きます。
　これによって、落とし込みの関係がつながっています。

---

■「だれが」は、アクターやスィムレーンに関係
　でも、分析するときには、アクティビティ図やユースケース図なわけで、そこには、スィムレーンやアクターが必要です。

　これらが、「だれが」に相当します。実際に行う人、担当者です。

　前の図では、「担当者」で表現します。

---

　ということで、前の図は、結局、「いつ」、「だれが」、「なにを」、「どのように」を聞き出しているということになります。ここから、ＤＯＡの図やオブジェクト指向の図がかかるということは、それらの図が、結局「いつ」、「だれが」、「なにを」、「どのように」のどれか一部を表現している図であるということです。

　しかし、実際の業務をとらえるには、これら全部ないと、捕らえられないので、そこで図にすると、情報が欠落し、問題になります（２つ以上の図を使っても、分かれてしまってつながらなかったり、矛盾していたりする）。

　てなわけです。。

「×」を押して閉じたウィンドウを復活できる

どうやってるんだろう（＠＿＠！）

ここのニュース
「×」を押して閉じたウィンドウを復活できる
http://news.ameba.jp/2006/12/web1213f_3.php
によると（以下斜体は上記ニュースより引用）

Windowsパソコンの画面上にあるウィンドウの右上には「×」（"閉じる"ボタン）があるが、皆さんはうっかりこのボタンを押してしまい、まだ見たかったウィンドウを閉じてしまった経験はあるだろうか。

　通常なら、このボタンを押して閉じたウィンドウは再び開くことはできない。だが、一旦閉じてしまったウィンドウを復活できるツールが存在した。

　ツールの名称は「GoneIn60s」で、サイトから無料でダウンロードすることができる


ちなみにそのソフトはここ
Download GoneIn60s 1.1
http://www.softpedia.com/get/System/Back-Up-and-Recovery/GoneIn60s.shtml
にあるけど、まだウィリアムのいたずらはダウンロードしてない
（なので、使ってない。もしやってみる人は自己責任で）

継続性に基づく組織的な開発には、オブジェクト指向が向いている。というと。。

前にＥＡのことを書いたときに、「崖っぷち！電子政府～迷走する4500億円プロジェクトの行方」というところの話を書いたので、今日は、そのシリーズにある、最後のところ

崖っぷち！電子政府～迷走する4500億円プロジェクトの行方・第3回：
問われるGPMOの調整機能 (2/2)
http://www.itmedia.co.jp/enterprise/articles/0608/15/news002_2.html

にある（以下斜体はそこからの引用）

継続性に基づく、ゆとりあるオルタナティヴ（代替計画）を模索する


ということについてちょっと触れて置きます。

---

　これを、「ロハス化」とかいっちゃうところから、また欧米か！っていう感じで、
役人の責任逃れ的な考えが見え見え（外国の考えはすばらしく、それを導入すれば
ばっちり！）なところが、いやーんなかんじだけど、それはまあ、置いておくとして、

この意味が、継続性に基づく、ゆとりあるオルタナティヴ（代替計画）を模索する
ということであって、本気でこれを目指すなら（とは、思えないのだが。。）この考えは
オブジェクト指向でないと無理だ。

　ＤＯＡなんかだと、全社的、全企業的にデータを解析する。そうしないと、関連部所間のつじつまが合わないから（ＤＯＡでは、それらのデータをＤＢに入れ、共有化する）。

　このつじつまを合わせるには、その対象以外の部署をカプセル化し（部署のクラスを発生させ）、対象部署とのＡＰＩのやり取り（すなわちこれが、メッセージ化なわけだが）に追い込まないといけない。

　そして、このカプセル化とメッセージのやり取りが、まさにオブジェクト指向なわけだ。

---

　そしてさらに言えば、オブジェクト指向の延長で考えれば、
最適化計画を改めて検証し、実行可能な開発スケジュールを再設定する
と平然と言っているが、
この考えは継続性に基づく、ゆとりあるオルタナティヴ（代替計画）を模索
という考えとは合わない。

　そもそも、最適化計画の最適とは、全体最適のことであるから、全体最適を
求めれば、いままでの部分最適（あるいはそれ以下）で行っていたシステムとは、
違うものになる。そこに継続性はない。

　しかし、そんなことより問題なのは

　”「実行可能な開発」は、「最適化計画」を改めて組みなおせば、
　　実現できるのか？”

　ということだ。

　継続的、部分的に開発しないといけない理由は、全体最適（＝最適化計画）を
考えようとしても、膨大な組織で、「実行不可能」だからだ。
　そこで、代替計画として、部分最適＝＞全体への標準化という手法が求められる。

　ある一定以上の大きな組織では、実行可能な全体最適をまず求められない。
　だから、実行可能なスケジュールを何回作り直しても、できっこない。。。

　今、そういう状態のように思われるのですが。。。

---

　つまり、小さなシステムであれば、全体最適を求めて、改革を断行することができる。

　しかし、ある一定以上大きくなると、全体を見切れないので、どうしても、部分最適を
もとめ、他の部分は、いったん分からないものとしてカプセル化するという、オブジェクト
指向的発想が必要になる。

　こうすれば、継続的な開発が可能となる。

　これは、改革ではない。継続的に改善していくという手法になる。

　そして、これの技術的な参照モデルがアジャイルのリファクタリングとなる。
　ＡＰＩは同じにして内部の最適化をめざしていく。
　そして、だんだん大きな塊で修正をかけていけば、最終的には、全体組織を
見ることになるだろう

---

　ここで、念のために行っておくが、「改善」とかくと、
　役人は「あ、トヨタのカイゼンシステムですね」といって、
　トヨタ方式を導入しようとしてしまう。

　そして、開発のマネージャーも、トヨタまんせーとなってしまうのだ。

　でも、この考えは、根本的におかしい。

　「トヨタのカイゼン」システムは、トヨタが行う上では、改善だが、
　トヨタ以外の会社が、「トヨタのカイゼン」を導入したら、
　　　それは組織を継続的に”改善”しているのではなく、
　　　組織をトヨタ方式に一気に”改革”しているのだ。

　郵便局の「トヨタのカイゼン」システム導入の失敗の１つは、ここにあると思うのだが。。

---

　といって、まだ分からない人が居るかもしれないので、念のために説明しておこう。

　改善というのは、継続的に、組織をよくしていこうとする一連の行為だ。
　改革とは、一気に組織を変える行為だ。

　トヨタは、毎日、カイゼン活動をやってるのだから、トヨタにとって、
　「トヨタのカイゼン」システムは、継続的に、組織をよくしていこうと
　する一連の行為＝カイゼンだ。

　でも、他の会社は、ちがうやりかたでやっているわけで、
　そこに「トヨタのカイゼン」システムを導入したら、
　それは、”一気に組織のやり方を変えた”わけで、改革になる。

　改革は、さっきの全体最適の問題で、改革が見切れればいいけど、あんまりにも
　大きな組織を急に変えると、崩壊してしまう。
　だから、「トヨタのカイゼン」システムを他社が急に導入したら、
　崩壊してしまうのである。

　自社のカイゼンシステム（この場合、国のカイゼンシステム）を新たに生み出さない
といけない。そのひとつの参考例に、「トヨタのカイゼン」システムは役立つかも
しれないけど。。。

---

　しかし、ウィリアムのいたずらとしては、じゃあ、e-Japan構想は、そういう風
に変わっていくかというと。。。上にちょっと書いたけど、変わらないと思う。

　なぜなら、政府は、「改革」をしたいのだ。。

　劇的に、こんな風に変わったぜ、だから、参議院も自民党に入れてくれよ！って。

　でも、継続的にカイゼンをしたら。。。

　この役所のここをかえました、あそこを変えましたと、少しずつやっても、

　そんなもんは、目立たないのだ。。

　そんな政治的アピールのないものを。。。やりますかねえ（－＿－）

---

　さらに、オブジェクト指向を導入しうんぬんって言ったら、
　いままでのＥＡのやり方を否定することになる。
　そんなことはできん。役所的にも、まわりで儲けてる人も。。

　だから、やんないと思う。
　結局、電子政府に多大なお金を今後もつぎ込んで、
　結局、今と同じ結果になると思う。
　方法が変わらなければ、結果は同じだから。。。

　それでも、電子政府は、政府の方針だから、
　どんどんお金がつぎこまれ、
　ソフト会社は、どんどん人を投入してやっていくと。。。

　うーん、第二の公共工事（＾＾；）

Wii向けOperaブラウザ？

ここのGIGAZINEの記事

Wii向けOperaブラウザのダウンロードは12月下旬に開始か
http://gigazine.net/index.php?/news/comments/20061213_wii_opera/
によると（以下斜体は上記記事からの引用）

スウェーデンの任天堂は、公式ページでWii向けOperaブラウザを用いた「インターネットチャンネル」の提供を12月23日に開始すると告知した

ということだそうな。。
ってことは、スェーデンでは、Wii向けOperaブラウザが出そうってことだよね。
でも

日本語版もその前後に提供される可能性が出てきたと考えるべきなのかもしれません。

といえるのだろうか？
（スェーデンだけのサービスとか　＾＾；）