危険な案件を取らないために、仕事のはじめにやる作業

う、今日書こうと思った、「案件が来たら、要素技術に分解してしまって、その部分だけを抜き出して、確認をとってしまう。」について、時間がないので、書きたかった内容のメモ

---

・結局、処理は
　　入出力
　　他の基本的な処理
　にわかれる。

案件がきたら、以下の感じで要素技術を分解する。
（１）入出力を決定するには、ハード要件もきめないと、結局いけない。
　その上で、技術要素をチェック
　　　（あ）新しい入出力デバイス？？、
　　　（い）新しい入出力プロトコル／フォーマット？？
　　　（う）新しいＯＳ？？
　　　（え）新しいライブラリなどなど

（２）他の基本的な処理は、結局、
　　（あ）業務をデータ的に矛盾なく落とせるか
　　（い）処理可能な言葉にまで、落とせるか
　　　　→処理方法のわからないものはないか？見切れるか？

　現実的には、ＲＦＰをもらって（ないしは、お話を受けてから）提案するまで（次回会うまで）の時間には、（１）の（あ）、（い）、（う）（２）の（い）の見切れるかどうかまでしか、確認できない。実際には、確認のさわりくらいしかできない。

　そこで、問題がないかどうか判断する。

ＲＤＢで、VIEWやORDER BYを使うと危険という話と、対応策？なのかな？？

「危険な兆候５つのポイント」と題して、ものものさんが、ブログを書いているのですが。。。以下の５行しかないんです。


・create view
・order by
・join（使っていない）
・if nest
・null


おお、これは、なんか、ゲームで、地図とか、アイテムをもらった心境っすね。

このメモの推理を１つ。たぶん、これは、「ＲＤＢでの」危険な兆候かなあ。。。

---

はじめの、
・create view
・order by
・join（使っていない）

この３つは、佐藤正美氏のセミナーで聞いたことがある。

佐藤氏は、View禁止、Group Byをするから遅くなるといっている。

理由は、これらの処理をＲＤＢで行った場合、ワークテーブル（転置テーブルだったかな？）領域を確保するから。

　この領域確保＝広大なメモリ確保をするから遅くなるといっていたと思います。たしか。

　ちなみに、メモリ確保をすると遅くなるというのは、ＲＤＢだけでなく、ＶＣ＋＋なんかでもそうで、CStringをやると、文字列領域をとって遅くなったり、ファイル領域をいっぺんに読み込もうとして、領域確保しようとすると、遅くなったりする。

　エヴァンゲリオンのような、組み込み系ロボット（なのかなあ？）だと、この遅れは、こまるので（シトにやっつけられてしまうので）、どうも、エヴァの場合、１バイトずつ読み込んで処理しているらしいことが、番組中、「intのc」という言葉から推測されるというのは、以前のブログに書いた。

　で、VIEWを禁止するということは、JOINしろということになるので、１番目と３番目は同じことになる。
　しかし、単純にJOINをしたら、遅くなるだろう。

　そこで、佐藤氏は、JOINをしやすくするために、徹底的な正規化と、その正規化したものに、バンバンIndexをはって、JOINはindexで解決するような形を提唱している。

　しかし、注意していただきたいのは、この手法では、JOINは早くなっても、indexを多用するので、更新や挿入は遅くなる問題がある。

　つーことで、実務上は、程度問題だと思う。

　氏の提案は、確かに画期的で、その発想はいいとおもうが、全プロジェクトで常に従うべきかどうかは、自己責任ということで、自分で考えたほうがいい。

　JOINの多用の場合、注意していただきたいのは、SQL文のよしあしだ。
　ある人（３年くらいの経験者なんだけど）ＳＱＬの１文が１万６千文字！とかいう人がいたけど。。。そりゃーきびしいものがあるんでないかい（＾＾；）

---

　２番目のorder byに関して、じゃあ、ＤＢでやらない場合、どこでやるのさ？っていう話。たしかに、受け取ってきてからソートしたほうが、早い場合がある。

　つまり、データのResultSetから、１行１行とってきて、ハッシュマップに入れる。

　　　ハッシュマップの
　　　　　キー：ソートしたいキー（仮にキーの型はStringだとします）
　　　　　値：とってきたデータ１行分

　で、そのハッシュマップをmpとすると、
String[] keylist = (String[])mp.keySet().toArray(new String[0]);
　で、キーをStringの配列として取得できる。
　その後
Arrays.sort(keylist);
　とすると、キーがソートして取得できるので、あとは、
Vector kekka = new Vector();
for(int i = 0 ; i <keylist.length;i++) kekka.add(mp.get((String)keylist[i]));
}
とかやると、kekkaに、ソートした結果が入る。
　いま、昇順だったけど、降順にしたい場合は、
for(int i = keylist.length ; i >= 0;i--)
　にすればいい。

　キーが３つか４つあるとき、
　全部昇順、全部降順なら、３つなり４つなりのキーを
　item1 + " " + item2 + " " + item3
　のように、スペース（スペースが値としてありえないとき）やタブでつないで、
　ハッシュマップにいれればよい
　（数字の場合は、桁数あわせが必要になるかも。文字も桁数合わせたほうがいいかも）

　でも、昇順と降順が入り混じる場合は、この方法は出来ない。

---

　ただし、上記の方法を行った場合、むしろ、order byを行ったほうより、遅くなる場合がある。

　このケースは、たとえば、この処理を行うプログラムが、サーバーサイドのようなプログラムのときで、サーバーで、いっぺんにみんなが、ハッシュマップをとってしまうとき、あるおばかなプログラムが、１００万件分のハッシュマップを使う！みたいなことをやられると、すっげーメモリをとられてしまい、そのプログラムが終わったあと、急にガベージコレクションが走ると、周りが迷惑する。

　なんで、ウィリアムのいたずらは、自分で、大きくメモリーを何回も使いそうなときは、自分でgc()を起動している。結構、思ったより、早くなる”こと”もあるよ！

　でも、order byより、遅くなるようなら、素直にorder byしたほうがいいぽ。

　可読性がわるくなるぽ！

---

　ifnest？？これが気にかかる。。。

　　　ＲＤＢの話？
　　　一般の話？

　一般的に言って、ifのネストはよみにくくなるよね。

　でも、じゃあ、状態遷移表や、決定表で書かれたとき、ifのネストを使わないで、表現するには？って、いう話はみんなＯＫなのかなあ。。。

　いや、このネタを書こうといつも思っているんだけどね、eclipseを立ち上げられないのよ、いま、Excelのバグフィックス中なんで。。。

　（って、そんなとき、ブログ書いているなよ！＜自分）

　なんで、このネタについては今度eclipseを立ち上げられるときに。

---

・null
　NULLを入れるとプログラムが落ちるというテストの話かもしれないけど、話の流れから、多分正規化の話だと思う。佐藤正美氏は、正規化をしないと噛み付くとか言ってる。

　で、NULL値を利用すると、正規化しないですんじゃうものがある。
　
　たとえば、衣料品と有機野菜を扱う会社があったとする（なんか、「あった！」なあ）
　そんな会社だと、商品名にこまる。
　衣料品はサイズ、色、がある。有機野菜は、サイズはあるものもあるけど。。。

　トマトは、普通赤です
　ピーマンはふつう緑です（赤いのは、赤ピーマンといいます）
　バナナは黄色です（青いのは、黄色くなります。茶色いのは売っちゃだめです）

　っていうわけで、色は、使わないです。
　そこで、NULL値をいれてしまい、衣料品も有機野菜も１つのテーブルにしてしまう。

　しかーし！それって、まずくないかい？
　衣料品と、有機野菜は別々のもんだろう。テーブルを分けなさいと。。
　っていう話。

　正規化すると、JOINが多くなる＝＞っていうので、３番の話とつながる

---

　ただ、この正規化を崩してＮＵＬＬをいれるのを、世の人がやるのは、実際、JOINのスピードが遅いことから来ている。

　確かに佐藤氏の主張するように、indexをはって、それでjoinが解決するようにすれば、うまくいくケースもおおい。しかし、更新系が頻繁に行われるシステムにおいては、今度は、更新スピードが問題になるし、佐藤氏自身も、joinで遅い場合はnative シーケンスを使うようだし。。。。

　ただねえ。。。そーいうテクニックはオラクルには使えても、postgreSQLやmySQLでも使えるのか？おお、しんふぉうえあーは、どーなのどーなの！とかいう問題がある。

　さらにわるいことに、この問題、あなたの上司の時代は、汎用機だから、あんまりおこらないと思う。

　汎用機の場合、メモリ確保はJCLによって、プログラム起動前にあらかじめ行われる。したがって、ワークエリア取得のメモリ要求がきても、その範囲をわたすだけなので、そんなにかからない。

　その上、INDEXやデータ領域に関しては、どこにおくかをシリンダレベルで、ＪＣＬで設定できる。これにより、ＩＮＤＥＸを１シークでアクセスできるようにしてしまえば、すんげえＤＢアクセスは早くなる。

　さらにだ、これを操作するＣＯＢＯＬ言語は動的にメモリを取らないし、プログラムが使用するメモリ領域はＪＣＬにより起動時に取得するので、ガベージコレクションによって、遅くなるなんてことはない。
　

---

　ということで、現場的には、「危険を覚悟で」こういうのを使うことになる。

　なんで、現実的には、はじめ、可読性をあげておいて、あとで、スピードアップするために、こういうところの書き換えになるよねえ。
　で、これについての、現実暴露話を書こうと思ったけど（可読性をあげるために、実はあえて、遅くなるプログラムを書くように指示が出る。。。でもでもね、それって。。。っていうような話）、もうそろそろ、お仕事しないとやばやばな「空気」なんで、きょうは、ここまで。

---

　もしかすると、佐藤氏非難のように聞こえるかもしれないけど、とんでもないっす。

　多くの場面では、佐藤氏の方法は、非常に有効だし、有効でない場面でも、この方法を意識して置くべきだと思う（意識して使わないということ）。

　とりあえず、佐藤氏の話は一度は聞いておいたほうがいいと思う。

　ただし、（誰の話でも）うのみにしないこと。

　なんか、佐藤氏や、その周辺の人たちから、文句こないだろうなあ。。
　きたら、このエントリー、そっこーで、削除します。

Excel VBAで、エラー2023がでるとき

ExcelのＶＢＡでエラー２０２３が出るときのメモ
ＶＢＡで、「型が一致しません」とか言われるたとき、
MsgBoxで、その値を表示しようとしてもやはり、「型が一致しません」
で、CStr(その値）でやると、この

エラー２０２３

が帰ってくる。

他にも、こういう状況があるようだ。

---

わたしがひっかかった原因：

その値の式中で参照するシートが参照できず、エラーになっていた
（＃ＲＥＦエラーになっていた）
http://park7.wakwak.com/~efc21/cgi-bin/wwwlng.cgi?print+200502/05020112.txt
　の人の件とあわせて考えると、シートの参照エラーになるときに、このエラーメッセージが出るのかもしれない
（コピーして、ペーストしなおしたらＯＫになったっていうことは、どこかの文字にゴミが入ってたけど、表示できていなかったとかなのかもしれない）。

私の場合は、もっと簡単で、見ようとしたセルの式中で参照しているシートを削除してしまっていた。

え、そんなバカいないって（＾＾；）

。。。だからか。。。

このエラー、ＹＡＨＯＯの検索で引いても、ぜんぜんひっかからなくて。。

だから、ブログに書いたんだけど。。

ひょっとして、そんなエラーに引っかかるのは私だけ？？

システムの効率的な開発法より、効率的にやばいシステム開発を見つける法のほうが利益貢献するはず

　現在の学会、業界本のトレンド、大手企業の人たちや、若い人の意見、ブログなんかをみると、ウィリアムのいたずらが接する、中小下請けの上の人や、現場で作業してる人の感性と、ちょっと違う（いやかなり）という気がしてます。

　学会などの感性は、「効率的なソフトウエア開発方法」を議論しています。その一つとして、オブジェクト指向では、ＵＭＬを用いてＭＤＡで。。。とかいう路線の議論とか。。。
　そして、オブジェクト指向、アジャイルでの開発論を中心に展開し、「こんなように開発します！！」といって、で、なんか、このケースでは、だめなんじゃない！みたいな意見が出ると「銀の弾丸はない」（でしたっけ？）みたいに言って、お茶を濁す。。。っていうふうに見えてしまいます。

　中小企業の現場ではそもそも、「銀の弾丸」どころか、

・結構多くのシステムは、どんな開発方法論を使っても、開発不能である
　　→ユーザーのいってることが矛盾してるので、論理的に開発できない

・かなり多くのシステムは、開発すると、採算割れする。
　　→これは、開発会社も、ユーザーも採算割れする

　という暗黙の前提があるように思われます。
　（以下、次の水平線につづく。水平線の中は、独り言。。きにしないでね！！）

---

　あのさー、いま、１人月６０（万）から７０（万）のご時世なのよ。

（学者の方やＩＰＡのＩＴＳＳを信じている人へ：なんで、ＳＥの値段が１つの値段に決まるのか。。これには、あるからくりがあります。たしかに予算ではＩＴＳＳのように、階級にわけて費用計上することが可能だし、多くやられるのですが、実は、その予算と実際に取れるお金が違うからなんです。そのからくりについては、（この前中堅のＰＭと話してても、知らなかったので）今度書きます。。って、書いていいのか！こんなソフト業界の裏の実態 ^^;)

　いままで、１００から８０くらいは、取れてたわけよ、２０００年のことはね。
　１００だったとしたら、６０になったら、４割引っすよ。

　きのうのＭＤＡの開発だって、３５％の削減でしょ。ほら、まにあわないでしょ。

　さらにねえ、６０もくれないところだって、あるわけよ。
　できるシステムなんて、限られてくるのに、きまってるじゃん！

---

　で、さらに、

　　・ものによって、最適な開発方法論が違うことが明らかである
　　　　→ＢＲＥＷの開発をするのに、オブジェクト指向を使われても。。。
　　　　　あれって、Ｃで書くのが普通なわけです。
　　　　　Ｃで、ＵＭＬでクラス図書かれても。。。なわけですよ。

そして、一番大事なことは！！

　やばい案件に手を出さないこと。
　やばい案件に手を出すと、すべての利益をふっとばしてしまう（＞＿＜！）

　これは、富士通さんが、たしか、言ってましたよね。
　なんか、変な案件に手を出して、赤字になったみたいな。。
　大手なら、赤字ですみます。中小零細なら、会社がふっとびます！！

　フリーなら、自分がつぶれちゃいます！！

なので、中小や現場にとって、一番の利益貢献になることは、作業の効率化ではなく、

　　・やばい案件を早く見つけること
　　・まともな案件を、確実にこなせる、最適な開発標準を見つけること
　　　→つまり、まともな案件でも、適切でない開発方法論をもってくると、失敗してしまう
　　　　なので、適切な開発方法論をもってきてほしい。
　　　　適切な開発方法論が、ものによっては、オブジェクト指向でないことは
　　　　ＢＲＥＷより明らか

だと思います。

　開発標準をきめて、その開発標準に従ってやらせることは、開発効率っていうこともあるけど、「こうやると、このプロジェクトはできる！」というやり方をきめるためです。そうすることによって、やばい案件でなく、これは、まっとうに仕事をすれば、まっとうにできる案件になるから。

　はっきりいってしまうとですねえ、オブジェクト指向にまったく向かない開発に、オブジェクト指向を持ってきてしまうと、それだけで、開発は失敗します。だから、オブジェクト指向で開発標準なんか、作られると困るわけなんですよ。

　なんで、自分たちの仕事をこなせる開発標準をだしてきてほしいわけです。

　この開発標準は、メンバーによっても代わります。
　メンバーによっては、「ここを触らせたくない」っていうので、その部分をパターンにしてしまったりするから（バッチパターンなんかを作るとき、この意図もかなり多い）。

　で、その部分をＰＭさんにつくってもらいたいんだけど、プロジェクトマネージャーは、意味が通じないことが多いんだよね。工場の標準化と同じようにかんがえてしまう。
　工場の場合、作っているものは、似ています。たとえば、自動車工場で、おばぎをつくったり、お菓子工場で、ピアノをつくることはありません（って、言い切って大丈夫だよな？？たぶん）。

　でも、ソフトウエアの場合、Javaで業務系をやっていた部隊が、次、Cやアセンブラで組み込みやファームとかっていう話、あります（最近、言語とか、ＯＳとか選んでられないのよ！）。
　この２つの標準化を考えるってことは、自動車とおはぎの標準化を考えるっていうことで、無理っす！

---

　っていうことで、前書きはととのった。

　で、前のブログで書いた、「仕様を要素技術に分解し、その技術に対してリスクドリブンで行うという手法を、「こっそり」上司に見つからないようにやる」（一番最後の部分）について、なんだけど、これは、まず、

　　・やばい案件を早く見つけること

　のために、案件が来たら、要素技術に分解してしまって、その部分だけを抜き出して、確認をとってしまう。
　で、その要素ができるかどうかを確認し、できそうなら、使える部隊を考慮して、そこの部分をどこまで隠すかを決定して、パターンを作り上げていくという作業をしてます。

　くわしくはですね。。。

　げ、また、長くなってしまったので、またこんど。。
　いつまでたっても、かけないジャン！