日本版ＳＯＸ法の草案なんて、できてたんですね！

　不勉強で知らなかった（＞＿＜！）
　その日本版SOX法の「実施基準案」っていうのが、ここらしい。

企業会計審議会内部統制部会の公開草案の公表について
http://www.fsa.go.jp/news/18/singi/20061121-2.html
（草案は、財務報告に係る内部統制の評価及び監査に関する実施基準（公開草案）（PDF：606K）にある）

---

で、それについて、こんな意見があるらしい

日本版SOX法「実施基準案」に疑問符、アビームが指摘
http://www.atmarkit.co.jp/news/200611/13/abeam.html

日本版SOX法「実施基準案」を読み解く－その1
http://www.atmarkit.co.jp/news/200611/16/jsox.html

日本版SOX法「実施基準案」を読み解く－その2
http://www.atmarkit.co.jp/news/200611/22/jsox.html

---

内容の概略は
ここ
http://www.atmarkit.co.jp/news/200611/06/jsox.html


また、内部統制委員会の内容は、ここ　http://www.fsa.go.jp/singi/singi_kigyou/top_gijiroku.html#naibu

「財務報告に係る内部統制構築のプロセス」は、
ここ（ＰＤＦ）http://www.fsa.go.jp/singi/singi_kigyou/siryou/naibu/20061120/02.pdf
に図でまとまってて、わかりやすい。

。。。って、なんか、リンク集みたいになっちゃったな（＾＾；）

現在の開発方法論と、実務上の問題

　前に現在の開発方法論は、システムをつくる要件を満たしているのか。。。。で、現在使われている方法論である、ＤＯＡとオブジェクト指向について、論理的に、システム要件を満たすかどうか吟味してきた。

　で、それでみると、ＤＯＡに関しては、決め事を決めれば、実際にコンピューターに載せる部分の制約（たとえばレスポンスタイムとか）はわからないものの、まあまあいい線いっている。
　でもＵＭＬは、プロセスとデータを分けて設計することができて、そーすると、それが結びつく、クラスわけ、さらには実際のコーディングまで、仕様の矛盾（このプロセスでは、このデータは取得できないなど）が、表ざたにならない可能性があるという問題点を書きました。

　そーすると、まるでＤＯＡのほうが、いいみたいに聞こえるかもしれないけど、実務的には問題があります。この問題があるから、オブジェクト指向が中心になって、アジャイルになってしまいました。今回はその話。

---

■ＤＯＡの問題点

　ＤＯＡで、データを分析して、その後そのデータの入力－プロセス－出力を、コンテキストダイアグラム（ＤＦＤの一番トップ）から、ミニスペック（処理機能記述書）にまで落としていくというやりかたは、論理的には、良く見えます。

　しかし、もし、だれも、プロセスの方法がわからなかったら。。。どうします？

　たとえば、新しいビジネスをはじめようとしたとき。
　そのビジネスモデルがきまっていなかったら、プロセスもはっきりしないし、データも分かりません。

　ほかには、複数のシステムを一まとめにしようとしたとき、あるシステムは分かるんだけど、他のシステムはわからないという場合。
　たとえば、ある企業の給与システムを作るとしましょう。
　その会社は、人事、財務、法務、金融、その他の現場いろいろに分かれていたとします。

　そして、人事部の給与は、そりゃー人事部ですから、コンピューター化できたとします。

　ところが、これを、全社に広げようとしたら。。。

　ＤＯＡでやるとしたら、全社の給与関係の「データの入力－プロセス－出力」がわかんないといけません。しかし、本社では、金融の部署のことはわからず、事務員の女性のボーナスがなぜか９００万円！！とかとか（そんな会社、あるわけねーだろ！っていうひとは、リンク先参照、そこからちょっと編集して引用）。
　で、本社でヒアリングをお願いしても、金融部門にはシカトされたとか（＾＾；）

　したら、ＤＯＡでは、開発できないですよね。。

　つまり、（上記リンク先のような　＾＾；）ベンチャー企業や、中小企業で、データを追っていくのが難しい場合、ＤＯＡでは、作れない！ってなってしまいます。

---

■その点、オブジェクト指向はなんとかなる

　この点、オブジェクト指向だと、プロセスを優先して決めていってしまえば、なんとか、形にはなってきます。つまり、人事部のシステムをもとに、つくって、後の各部署の差異は、クラスを派生して作ればいい、データも追加すればいいとしてしまえば、話は進みます。

　で、ある程度作ったら、みんなにメールを送って、「これであってる？文句あったらいってね！」とすれば。。。いいかっていうと、実は、急にメール送られても困るんだけど。。。まあ、それでいいことになって進めてしまう。。

　っていうことで、何とかなったりします。

　ただし、この場合、最終的に、これで、うまくいくのかはわかりません。
　なので、とりあえず、どんどん作っていって、確かめる（これがアジャイルになる）っていう形になります。

　上記のように、「差異はあとで解消しましょう」っていうことになると、その差異は、ずーっと後まで残るっていうことになります。そして、アジャイルで、仕様が出来たところから開発してしまうと。。。分かっているところのコーディングが終わった後に、その差異の部分で「う、こうは、いかないや（＞＿＜！）」ってことになって。。。修正って言うことになります。

　でも、仕様修正をしようとしても、ほかは決まっていないので、部分的な仕様修正になります。
　そんな仕様修正がいっぱい出てくると、仕様修正で矛盾が起こる危険性があります。
　（全体は分からない状態で開発に入っているから、部分最適がかならずしも全体最適ではない）

　そんなこんなで、システムがまとまらず、テストに入っても修正するという危険はあります。

---

■では、どうすればいいのか？

　つまり、ＤＯＡが使える範囲とオブジェクト指向が使える範囲があって、その範囲内で、適切な順番でやればいいわけです。

（１）まず、全体が読みきれる範囲で、オブジェクト指向を使います。
　この場合、プロセスとデータが分かれていても、システムを読みきっている
　（＝頭の中では入力－プロセス－出力の循環ができている）ので、実際には、
　クラスに矛盾なく落とせます。
　　逆な言い方をすれば、クラスに落とし込んで、間違いない範囲で、作っていきます。

　もちろん、ここで、ＤＯＡでやってもいいんですけど、ＤＯＡの場合、一応
入力－プロセス－出力ができてから、コーディングに入るので、コーディング
して実機で試すタイミングが遅くなります。
　現在の開発だと、論理的にうまくいくけど、実機では問題がある（処理結果が
返ってくるのが遅くて使い物にならん）っていうケースがあり、この場合、
アジャイルですぐ確認できるほうがいいわけです。
　そして、アジャイルと親和性の高い開発方法ってなると、オブジェクト指向になります。

（２）そして、個別のできているシステムを組み合わせるにはＤＯＡがいい
　個別にできているシステムは、そのシステムごとに入力－処理－出力ができているので、
あとは、統合しようとするシステム全体と比べて、統合できるところは結合し、
できないところは、個別にそのまま残せばいいということになります。

　この場合は、初めにできているので、厳密にやるためＤＯＡがいいことになります。
　オブジェクト指向だと、みんな似通ったことをやっているため、１つにできそうな
幻想をいだきます。
　じつはこれが危険思想で、実際にまとめてしまおうとすると。。。。どツボにはマリ、
それをごまかすために、ラッパーでくるんだり、委譲しているうちに。。。（‘＿‘！）
わけわかんなくなってしまいます。

---

　てなふうに、最近思っています。

「一太郎」最新版、グーグル検索と連動っていうけど、それだけで差がつく？

ここのニュース
「一太郎」最新版、グーグル検索と連動
によると（以下斜体は上記ニュースより引用）

ジャストシステムは2007年2月、文書作成ソフト「一太郎」の最新版を発売する。グーグルの検索システムと連動させ、文書を作成中に簡単にキーワード検索ができる機能を搭載する。市場で圧倒的なシェアを占めるマイクロソフトの「ワード」との違いを打ち出す。


うーん、でも、キーワード検索するだけなら、Ｇｏｏｇｌｅ　ＡＰＩがあるから、だれか、マイクロソフト大好き！なひとが、ＷｏｒｄのＶＢＡで、
１．なんかされたイベントのところに（ボタンが押されたとか）
２．選択された言葉を、
３．Ｇｏｏｇｌｅ　ＡＰＩで検索して
４．ダイアログに表示する
っていうやつをつくって、公開されたら。。。

まあ、もっと、ユーザーインターフェースがいいとか、なんかあるんだろうな。。

あらかじめ設定すれば用語と関連したウェブサイトや画像、地図などの検索結果も表示できる。

そこまでやるんだったら、もっとＷｅｂサービスのＡＰＩを登録して、表示できるようにすればいいのに。。たとえば、ＡｍａｚｏｎのＡＰＩと結べば、その本があるかどうかわかるから、便利べんり。。。って、できるのかな？？どーなのかな？？

　っていうか、別にワープロなんて、あらかじめパソコンに入ってるの使うだけだから、
　あんまり関係ないんだけどね（＾＾；）