公開されているコードの功罪

昔、VBAでデータベースへのアクセスクラスを作り、今でも便利に使っている。
しかし、今の仕事ではサーバー系のツール作成の方が多いため、VBAより.net系言語を使うことの方が多い。できればVB.netを使いたいところだが、職場としてはC#に傾いているためそちらを使っている。

最近、DBとXMLへのアクセス用共通モジュールを作ろうとしている。まずは急ぎのDBアクセス。当然ADO.netになる訳だが、これまではADOで作ったものをお手軽に改変しADO.netにしたものを使っていた。今回はしっかりとやってみようと思う。ADO.netはそれほど触っていない。そこでサンプルになるコードをネットで探した。しかし、そこで「こりゃまずいな」と思ったことがある。

C#にしろVB.netにせよ、検索すると質問＆回答サイトが上位に来る。そこに掲載されてあるコードが問題だろう。
公開される質問であるので、質問者は「素人」「初心者」という免罪符的な言葉を含めて質問しているのは分かる。で、その回答は、なぜかFormモジュールでボタンをクリックすれば作動するようなコードが多い。というより、それ以外を見つけられなかった。
サイトのみならず、書籍でもそう。意外と、海外からの翻訳本でも同様の傾向があった。


これにどういう問題があるか。

少なくとも、.net系の言語はオブジェクト指向である。なら、MVCを意識したコードになっていないのはなぜだろう？もちろん、まっとうなプログラマなら、それをクラスモジュールにアレンジすることは訳ないはずである。しかし初心者と大差のないプログラマも大勢居る。その人たちはコピー＆ペーストで処理を書いてしまうのだ。動けばとりあえずよし、そういう感じなのだろう。

インターネットという性格上、誰でも情報を検索できるし、誰でも情報を発信することができる。その仕組み自体は悪いことではないだろうけれど、発信される情報の質が低ければ、良質な情報が埋もれてしまう。

サンプルコードに関しては、Javaはしっかりしているように感じる。

オブジェクト指向の言語に変更したものの、保守がかえって手間になったという場合は、設計やコーディング上で、オブジェクト指向の利点を取り入れていないことも疑ってみればどうだろうか。

GeneXus Winterに参加

2010/12/7 に開催された GeneXus Winter に参加した。

GeneXus とは、「仕様を入れれはコードが生成される」というもので、幾多のベンダーが挫折してきている経緯がある。しかし、このツールの歴史は実は２０年を超える。南米ウルグアイの製品なので、日本に初めてやってきたのが2000年を超えてから。最近、日経コンピュータなどで取り上げられ、知名度が向上しているものだ。
C#やJava、Rubyなどのコードを出力する。Webシステムとクライアントサーバーに対応。ただ、ASP.netのようなのはないような感じ。


会場は結構な賑わい。ただ、私のように個人参加は少なかったのではないか。ほとんどが会社からつるんで来ている感じだった。
会場の段取り、仕切りは「ああ、手を出したい！」と思うレベルであったが、まあそれは本筋ではないので省く。


本題は内容である。

NEC情報の講演内容で、生産性を測定したり、生成されたソースコードの質をチェックしたりしたした結果を話していた。冗長なコートはあるが、SQL インジェクションやクロスサイトスクリプティングなど、セキュリティ関連は問題ないコードが生成されるそうだ。
生産性も、画面周りはまだ弱いところがあるようだが、概ね向上するとのこと。


そして本命は東洋大学での導入事例。ユーザー側からのメリットが盛りだくさんであった。
業務改善とITとの両輪、いわゆるビジネスプロセスリエンジニアリングで、ITコーディネータの立場としては結構興味のある分野。話を聞いていて驚いたのは、このツールはウオーターフォール型とアジャイルのいいとこ取りができるツールのようなのだ。
つまりは、設計したらそれを設定してやればソースコードとデータベース定義を作ってくれるので、変更にめっぽう強い。そこにテストデータを入れてやれば、プロトタイピングさえできてしまう。
ユーザーは改革業務に専念すれば、おのずと成果が出てくる。データベース変更を伴うような仕様変更でも、仕様さえ固まればツールが吸収してくれる。

GeneXusの思想として「未来の変化からビジネスを守る」というものがある。は？という感じだが、OSが変わる、データベースが変わる、とかいう変化が起こると、それだけで費用が発生するのが常であるが、ユーザー側にとってはそれは全く以て嬉しくないコストである。GeneXusはGeneXusが生成するコードを使えばいいのだから、未来に起こりうる変化で、コストが掛かりすぎてビジネスが成り立たない、ということを防いでくれる訳である。この思想はすばらしいと感じた。


なお、このツールを用いれば
・コンサルティングファーム、会計事務所など、特定の業務に強い専門家集団がITベンダーに頼らないシステム開発を行える。
ということになりそうである。

もしこれが開発の主流になったら、ホントにプログラミングしかしていないようなエンジニアは淘汰されるだろう。

バックアップについて考える

データについてはバックアップを確保するのが至極当然になっている。
大型汎用機で開発していた頃は、ハードディスク（富士通製品はDASDとか呼んでいたか）も高額なので、テープデバイスに記録する設計にしていた。まあ、データベースが主流ではなかった時代でもあるのだが。現在、データといえばデータベースが主流だろう。データベースならバックアップを確保する機能はDBMS側で装備されていることが多く、開発者が設計上盛り込む機会は少ないかもしれない。もちろん、運用設計を考えると必要なことではある。

さてさて。仕事で「客先のバックアップを取って欲しい」という依頼が来た。こういうざっくりした依頼が営業担当者から来るのなら分かるが、技術者から来るのが困ったところだ。詳細を確認してもゼロベースだ、一から考えて欲しいとのこと。


別に、バックアップをどのタイミングでどこに取るのかの案くらいなら特に準備は要らない。しかし、バックアップを取る、というのは目的ではなく手段である。手段をいくら決めても、目的に適合していなければ顧客の期待には答えていることにはならない。

よって、万一のとき、その万一の程度がどのくらいかによってどこまで対応したいのかを顧客から引き出しておく必要がある。そのためには事象を例示し、この場合はどのくらいまでに復旧する必要があるのかを顧客と合意しておく必要がある、ということに他ならないのだ。その合意があって初めて、どの程度のバックアップが必要なのか、顧客にあった提案ができる。
もちろん、万一のときの役割分担も決めておく必要がある。「これだけのバックアップ取っています」としか決めていなければ、顧客側は「万一のときには無償で復旧してくれる」と思うかもしれない。しかし、対応側としては「そんなもの別料金に決まっている」と言いたいだろう。そこはあらかじめ協議のうえ、確定する必要があるだろう。


万一のときの避難訓練は実施している職場は多いが、万一のときの復旧訓練をしているところは知る限り皆無である。避難訓練の一環として、情報系の復旧訓練というのもやっておいたほうがいいだろう。
情報システムの復旧も、慣れていればたいしたことはないが、パニック状態では問題が起きやすいからだ。

顧客のバックアップの目的が「なんとなくデータ保全」なのか「万一の時でも決められた時間内に復旧し、事業継続性を担保するためのもの」なのか、その話もできておらず「バックアップを取る」というのは、木を見て森を見ずって感じであろうか。
バックアップ＝DBMSで設定して終わり、という考えしか持っていない技術者は結構多いかも知れないが、それだけでは顧客のニーズに合致していない可能性もかなり高い、といえる。