2008年09月21日
今だから出来る業務システムを
先日、とある業務システムの事例が発表されていました。最先端を好むエンジニアに評判の良い最新技術を採用しての開発ということで大きく注目を集めたようです。その事例記事自体は普通の紹介記事なので、そこからあれこれと邪推するのもどうかと思うのですがいくつか気になるところがあり、それが日本の業務システムの問題の一部を体現している気がするので、ちょっと気になるところを書き連ねてみます。
■業務改善と無縁のシステム？
その記事には画面のスクリーンショットが掲載されていました。見た瞬間に「未だに？」と感じてしまいました。どういうことかというと、画面の一番上がラジオボタンになっており、
◎追加 ○更新 ○削除
と、まずは今から行う操作の種別を入力するようになっているのです。
これは「伝票入力する」という業務がそのまま残っているということになります。どういうことかというと、昔々というのはコンピュータが非常に高価な時代でした。そこでまずは入力のために記入する伝票が用意され、それをオフライン端末という比較的安価なコンピュータに向かってパンチャーさんと呼ばれる職能の人が入力するという流れになっていました。入力されたデータはフロッピーに記録され、実際のシステムであるホストコンピュータへのエントリは、このフロッピーを読み込ませるバッチ（一括）処理という形で行われました。
このとき、各データの頭に「このデータは追加ですよ」のように処理区分を入れていたのです。それを入力するのが
□ １：追加 ２：更新 ３：削除
のような端末画面でした。ここでの□は入力のボックスです。読み取りを行うバッチ処理のプログラムの側では、区分が１なら追加処理に、などのような分岐が行われていたのです。
その後時代が移って、ホストコンピュータに直接入力できるオンライン端末が普及してきました。しかし記入済みの伝票を見てパンチャーさんが入力するという業務は変わりませんでした。また既存のプログラムを再利用するためにバッチ処理のときと同じように処理区分を入力することも変わりませんでした。
さらにその後、時代はダウンサイジングへと向かいます。ネオダマなんていう言葉を懐かしく感じる人もいるかもしれません。クライアントサーバ型システムの幕開けです。WindowsというOSの普及とVB（Visual Basic）という開発言語の台頭もあって、画面の作りはWindowsらしい感じになっていくようになりました。マウスによる操作が主流となっていったのです。
ラジオボタンはこのGUI（グラフィカルユーザインターフェイス）の時代の産物です。複数の選択肢の中からひとつの値を選ぶ場合に用いられます。なので一見処理区分をラジオボタンで表現するのは間違いではないように感じられます。しかし実際にWindowsの上で動いているソフトウェアを見れば気がつくのですが、マイクロソフトさんがGUIのデザインガイドラインというものを提示していたこともあり、そのような画面のものはまず見かけません。いえ、実際には昔のホストコンピュータのシステムの焼き直し以外では見かけることがありません。
実はこのような場合は「追加する」という行為すなわちアクションとなるので、普通のボタンやメニューバーなどで「操作する」という形で表現します。ラジオボタンはボタンという言葉が混ざっているものの、あくまでも「値」の選択をするためのものであって、アクションそのものを表現する部品ではありません。
今回の事例はクライアントサーバではなく、さらに最近の仕組みであるWebを使ったものになっています。当然普通に設計するとラジオボタンは使わないはずです。しかし事例ではしっかりと処理区分として残っている。果たして本当にそれでいいのですか？ というのは、感じるところです。
こういうことを言うと、「既存ユーザの使い勝手が」という話が出てくるのですが、実はこれも要するに慣れでしかなくて、しかも元パンチャーの立場からいうと、テンキーだけでオペレーション出来ずにマウスに持ち替えたりする時点で、既に使い勝手は落ちているわけです。従来通りにこだわるのであれば、ラジオボタンなど使ってはいけないケースです。
さて、そういう画面設計に関する知見の停滞もさることながら業務システムという点でいうと、もっと気になることがあります。それはつまり、相変わらず伝票を回すという業務には手つかずなのだろう、ということです。どういうことかというと、入力の際に見ている伝票にはおそらく「追加・更新・削除」のどれかに○をつける、あるいは番号を選んで記入するという欄が残っているはず（でないと入力する人が判断できない）で、ということはずっと同じフォーマットの伝票を使っているということになるのです。
IT化しても効果が出ない、という話がよくあります。それは従来の業務をそのままにしているからです。ですから入力作業の分だけ余分に手間がかかるようになってしまった、という風になります。得てして「いかにシステムを作るか」に注力してしまった場合に起こりがちな状況なのですが、システムの周辺の紙（入力源および出力帳票）を与件としてそのままの形で残そうとしたときに露骨に現れてきます。
ITのIはインフォメーションすなわち情報です。業務システムをIT化する・IT化されたシステムを刷新する、というのは、業務における情報のあり方を見直すということです。情報を見直すことを通じて、仕事の流れを整理し直していくというのが、本来の意味での業務のシステム化です。ですが、伝票がそのままであるということは、おそらく業務自体は何も変わっていないのであろうと見て取れるのです。これはROIが相当に問われるケースかと思うのですが、得てして日本のシステム構築というのはこの辺何となく許されてしまえるようです。
■データベースを本当にきちんと使ってる？
別の点でも気になることが書かれていました。バッチ処理が多いと書かれています。ホストコンピュータの時代においてバッチ処理が多いのは、ある種の必然でした。マシンリソースが高価だったので時間を上手く使い分けないといけないので、大量データの処理をするには夜間にまとめてしまうほうがいい、という事情があります。
加えて、拙著「楽々ERDレッスン」でも触れましたが、構造化技法を採用（そもそも構造化技法を理解できていない人もいたりしたのですがそれはさておき）してプログラムの大量生産をしようとするとシンプルなアルゴリズムにせざるを得ず、そのためにはアルゴリズムに有利なデータ構造に変換するという処理が発生します。そのため主たる処理１つに対して構造変換のための処理が複数必要になるという事態に陥ってしまうのです。この問題に対するひとつの回答がRDBMS（リレーショナルデータベース管理システム）です。
現代の業務システムにおいては（好き嫌いの別はさておいて）RDBMSの利用が一般的になっています。RDBMSを使う場合に重要になってくるのは、データの重複を避けるということです。これは専門的には正規化という考え方になります。重複を避けるのですから、あちこちに散逸した同じデータのつじつまを合わせる処理は不要になります。つまり基本的にはホストコンピュータ時代に必要とされたバッチ処理の大半が不要になります。これにも異論をおっしゃる方もいますが、15年ほどの私の未熟な実績においてさえも自信を持って「バッチ処理は減らせる」と断言できます。
さて、この本来大幅に減少するはずのバッチ処理において、記事中ではディスクアクセスの性能の話が出てきます。実はこれはRDBMSのチューニングの肝となるところです。ですからプログラミング言語の話ではなく、SQL（あるいはストアドプロシジャ）の使い方とメモリ割り当てや利用しているRDBMSのパラメータなどが重要になります。ところがどうも記事から邪推すると、プログラミング言語の側で古典的なループ処理を回しているように感じられるのです。
RDBMSはクライアントサーバ時代に一般的になっていきました。バッチ処理をどう減らすか、そして残ったバッチ処理の性能をどう確保するかということについては、既に10年以上前にある程度ノウハウが確立しています。にも関わらず、どうもそこにはあまり突っ込まずにRDBMSのメリットを活かさないままに、昔ながらの作り方を繰り返しているように感じられるのです。
■邪推でしかないのですが
繰り返しますが、これは記事を読んだだけで私が勝手に想像して感じただけです。実際にはしっかりとRDBMSを使い切って、業務改善もしっかりと展開された上で、必要だから処理区分を残すという判断の下にUI設計がされているのかもしれません。ただ、もし私の邪推が少しでも当たっているのであれば、これはとても悲しく思います。先人の知恵が活かされていないということになるからです。
そして、実はこの事例に限らず同じような展開になっているプロジェクトが多数存在することも、残念ながら私は知っています。ですから記事へのリンクは伏せておきます。このプロジェクトだけの問題ではないからです。問題なのは道具を流行りのものに差し替えさえすれば後は上手くいくかのように煽る一部の利権屋であり、それに乗せられてしまうプロジェクトというのも正直どうかと感じるのです。
学びの最中にやり過ぎてしまうことはあります。例えば過度の正規化によって逆に性能を劣化させてしまうとか、妙にオブジェクト指向を意識しすぎて変な構造にしてしまうとか、そういうことはあるでしょう。実際に私にもそういう麻疹にかかってた時期があります。しかしそれは前に進もうとしているだけ、言い訳がましいのですがまだマシな気がします。新しい酒を新しい革袋に入れようとしてるのですから、そこからは学びがあるはずですし、実際に多くの学びを得ました（その大半は書籍や雑誌での記事で公開させて頂きました）。
新しい革袋に古い酒を移し替えるだけ、というのは、正直どうかと思うのです。結果として、リスクを無駄に大きくしてしまっているように見えます。昨今では日本のIT/SI業界は世界に通用しないとか色々と言われたりしていますが、通用するかどうか以前の話として、きちんと改めるということの意味を理解することが重要なのではないかと感じるのです。
■役に立つということ
エンタープライズとかいうのであれば、業務システムの開発に携わるのであれば、もっときちんと技術的な基礎・基本を押さえるべきではないか。流行り言葉を振りかざして格好つけるよりも先に、やるべきことが山ほどあるのではないか。そう思うのです。業務のあり方に関すること・使い勝手に関すること・管理する情報の扱い方に関すること、以上の三点はテクノロジがどう変遷しようとも、業務システムを作るに当たって無視できないことです。そこを脇に置いて、目先の作り手サイドの気持ち良さだけをとやかく言っても、本当の価値は生まれないのです。
従来ホストコンピュータで稼働していたシステムをWebアプリケーション型で置き換えたプロジェクトに技術支援として関わったことがあります。徹底的にUIを考えました。正確にはプロジェクトメンバーの皆さんに考え抜いて頂きました。結果として処理区分のあったホスト時代とは似ても似つかない画面になりました。リリース前の現場への説明会の際に50代の女性が「今まで色んな画面の説明を聞いてきたけど、今回のならすんなり使える気がする」という風におっしゃってくださったそうです。頑張ったプロジェクトメンバーが報われた瞬間でもあります。従来通りでなくても、便利になればそれを受け入れてもらえるのはどんな商売でも同じです。プロとしての意地の張りどころだと思うのです。
自社に照らして考えれば、他人の振り見て我が振り直せ、という一言になるのでしょう。スタロジとしてもお客様に提供するものをもっと見直していかなければならないと感じています。一方で、やはり「業界の未来を云々」と言ってる方々においては、こういうことをもっと改めていけるような取り組みこそが重要なのではないですか？ と問いかけておきます。シュプレヒコールの前に、もっともっと地道な、ですがエンジニアとして不可欠な、やるべきことがいっぱいあるように思うのです。
スタロジは、マジカ！やギョイゾー！などを通じて、お客様のお役に立つシステムを提供できるようにこれまで頑張ってきました。上記のような偉そうなことを書いていても、まだまだ未熟であるのは事実です。4月の終わりにギョイゾー！を発表しましたが、多くの声を頂いて地道に成長しています。年内中には多少なりとも成長の証をきちんと示すことで、業務システムというのはこういうことが出来るのだということをお伝えしたいと考えています。
他所様のことをとやかく言える資格があるのかと言われると耳が痛いのも事実ですが、さりとて正直これはどうなのかなと思うと、書かずにはいられなかったので書いた次第です。この投稿を自社に対する十字架にする気概でこれからも頑張ります。
追記：
気になって改めて見てみると、ソースコードを含めて設計書などが公開されていました。素晴らしいことです。この事実に対して素直に賛辞を送ります。早速ざくっと拝見させて頂きました。
UIについてはやはり微妙ですね。この業務を是とする前提であれば、やはりこうなってしまうのかもしれません。端末の配備だったり人員の活用（以下略）だったりを考えるとこうなってしまうのでしょうか。惜しいなという気がします。
データベースのテーブル設計は意外と普通でした。良いとは決して言えないのですが、このシステムは基本的に帳票出力機なので、これはこれで割り切ればありなのかもしれません…とは言い辛いかな〜、やっぱり。細かいところで排他の関係のフラグが別個に存在してたりとか、まぁそういうのは見逃すとしても、ん〜、気になる箇所は色々とあります。
バッチ処理はソースコードを拝見させて頂きました。残念ながらビンゴでした。これはテーブル設計と表裏一体の関係になっていて、テーブル設計がこうだからバッチ処理もこうなるのか、そもそもこういうコードの書き方を想定してテーブル設計をしているのか、恐らくコードの書き方に従ったのかなという感じを受けます。これだと性能を出すのは確かに大変です。拙著「SQL書き方ドリル」を真剣にお奨めしたいです。
…というわけで、これを無条件に横並び的に手本にするのはやはり問題だと感じます。今後の活発な議論を期待したいです。とはいうものの、こうやって外部の人間が論じられるというのは素晴らしいことだと感じます。改めてオープンにすることの意義と意味を実感しました。スタロジもOSSの恩恵に浴しているわけですから、このあたり見習いたいと真剣に思います。せっかくここまで業務仕様が公開されているわけですから、折を見て「スタロジならこうする」的なものを作ってみたいなと感じました。今すぐどうこうというわけではありませんが、このあたり色々と考えてみたいと思います。
締めとしては「やはりオープンというのは素晴らしい」ということになるでしょうか。その上で「オープンであれば良いわけではない」というわけで、切磋琢磨・自己研鑽を怠らないように心がけなければならないということを書かせて頂いて、一度この件はクローズとさせて頂きます。
その記事には画面のスクリーンショットが掲載されていました。見た瞬間に「未だに？」と感じてしまいました。どういうことかというと、画面の一番上がラジオボタンになっており、
◎追加 ○更新 ○削除
と、まずは今から行う操作の種別を入力するようになっているのです。
これは「伝票入力する」という業務がそのまま残っているということになります。どういうことかというと、昔々というのはコンピュータが非常に高価な時代でした。そこでまずは入力のために記入する伝票が用意され、それをオフライン端末という比較的安価なコンピュータに向かってパンチャーさんと呼ばれる職能の人が入力するという流れになっていました。入力されたデータはフロッピーに記録され、実際のシステムであるホストコンピュータへのエントリは、このフロッピーを読み込ませるバッチ（一括）処理という形で行われました。
このとき、各データの頭に「このデータは追加ですよ」のように処理区分を入れていたのです。それを入力するのが
□ １：追加 ２：更新 ３：削除
のような端末画面でした。ここでの□は入力のボックスです。読み取りを行うバッチ処理のプログラムの側では、区分が１なら追加処理に、などのような分岐が行われていたのです。
その後時代が移って、ホストコンピュータに直接入力できるオンライン端末が普及してきました。しかし記入済みの伝票を見てパンチャーさんが入力するという業務は変わりませんでした。また既存のプログラムを再利用するためにバッチ処理のときと同じように処理区分を入力することも変わりませんでした。
さらにその後、時代はダウンサイジングへと向かいます。ネオダマなんていう言葉を懐かしく感じる人もいるかもしれません。クライアントサーバ型システムの幕開けです。WindowsというOSの普及とVB（Visual Basic）という開発言語の台頭もあって、画面の作りはWindowsらしい感じになっていくようになりました。マウスによる操作が主流となっていったのです。
ラジオボタンはこのGUI（グラフィカルユーザインターフェイス）の時代の産物です。複数の選択肢の中からひとつの値を選ぶ場合に用いられます。なので一見処理区分をラジオボタンで表現するのは間違いではないように感じられます。しかし実際にWindowsの上で動いているソフトウェアを見れば気がつくのですが、マイクロソフトさんがGUIのデザインガイドラインというものを提示していたこともあり、そのような画面のものはまず見かけません。いえ、実際には昔のホストコンピュータのシステムの焼き直し以外では見かけることがありません。
実はこのような場合は「追加する」という行為すなわちアクションとなるので、普通のボタンやメニューバーなどで「操作する」という形で表現します。ラジオボタンはボタンという言葉が混ざっているものの、あくまでも「値」の選択をするためのものであって、アクションそのものを表現する部品ではありません。
今回の事例はクライアントサーバではなく、さらに最近の仕組みであるWebを使ったものになっています。当然普通に設計するとラジオボタンは使わないはずです。しかし事例ではしっかりと処理区分として残っている。果たして本当にそれでいいのですか？ というのは、感じるところです。
こういうことを言うと、「既存ユーザの使い勝手が」という話が出てくるのですが、実はこれも要するに慣れでしかなくて、しかも元パンチャーの立場からいうと、テンキーだけでオペレーション出来ずにマウスに持ち替えたりする時点で、既に使い勝手は落ちているわけです。従来通りにこだわるのであれば、ラジオボタンなど使ってはいけないケースです。
さて、そういう画面設計に関する知見の停滞もさることながら業務システムという点でいうと、もっと気になることがあります。それはつまり、相変わらず伝票を回すという業務には手つかずなのだろう、ということです。どういうことかというと、入力の際に見ている伝票にはおそらく「追加・更新・削除」のどれかに○をつける、あるいは番号を選んで記入するという欄が残っているはず（でないと入力する人が判断できない）で、ということはずっと同じフォーマットの伝票を使っているということになるのです。
IT化しても効果が出ない、という話がよくあります。それは従来の業務をそのままにしているからです。ですから入力作業の分だけ余分に手間がかかるようになってしまった、という風になります。得てして「いかにシステムを作るか」に注力してしまった場合に起こりがちな状況なのですが、システムの周辺の紙（入力源および出力帳票）を与件としてそのままの形で残そうとしたときに露骨に現れてきます。
ITのIはインフォメーションすなわち情報です。業務システムをIT化する・IT化されたシステムを刷新する、というのは、業務における情報のあり方を見直すということです。情報を見直すことを通じて、仕事の流れを整理し直していくというのが、本来の意味での業務のシステム化です。ですが、伝票がそのままであるということは、おそらく業務自体は何も変わっていないのであろうと見て取れるのです。これはROIが相当に問われるケースかと思うのですが、得てして日本のシステム構築というのはこの辺何となく許されてしまえるようです。
■データベースを本当にきちんと使ってる？
別の点でも気になることが書かれていました。バッチ処理が多いと書かれています。ホストコンピュータの時代においてバッチ処理が多いのは、ある種の必然でした。マシンリソースが高価だったので時間を上手く使い分けないといけないので、大量データの処理をするには夜間にまとめてしまうほうがいい、という事情があります。
加えて、拙著「楽々ERDレッスン」でも触れましたが、構造化技法を採用（そもそも構造化技法を理解できていない人もいたりしたのですがそれはさておき）してプログラムの大量生産をしようとするとシンプルなアルゴリズムにせざるを得ず、そのためにはアルゴリズムに有利なデータ構造に変換するという処理が発生します。そのため主たる処理１つに対して構造変換のための処理が複数必要になるという事態に陥ってしまうのです。この問題に対するひとつの回答がRDBMS（リレーショナルデータベース管理システム）です。
現代の業務システムにおいては（好き嫌いの別はさておいて）RDBMSの利用が一般的になっています。RDBMSを使う場合に重要になってくるのは、データの重複を避けるということです。これは専門的には正規化という考え方になります。重複を避けるのですから、あちこちに散逸した同じデータのつじつまを合わせる処理は不要になります。つまり基本的にはホストコンピュータ時代に必要とされたバッチ処理の大半が不要になります。これにも異論をおっしゃる方もいますが、15年ほどの私の未熟な実績においてさえも自信を持って「バッチ処理は減らせる」と断言できます。
さて、この本来大幅に減少するはずのバッチ処理において、記事中ではディスクアクセスの性能の話が出てきます。実はこれはRDBMSのチューニングの肝となるところです。ですからプログラミング言語の話ではなく、SQL（あるいはストアドプロシジャ）の使い方とメモリ割り当てや利用しているRDBMSのパラメータなどが重要になります。ところがどうも記事から邪推すると、プログラミング言語の側で古典的なループ処理を回しているように感じられるのです。
RDBMSはクライアントサーバ時代に一般的になっていきました。バッチ処理をどう減らすか、そして残ったバッチ処理の性能をどう確保するかということについては、既に10年以上前にある程度ノウハウが確立しています。にも関わらず、どうもそこにはあまり突っ込まずにRDBMSのメリットを活かさないままに、昔ながらの作り方を繰り返しているように感じられるのです。
■邪推でしかないのですが
繰り返しますが、これは記事を読んだだけで私が勝手に想像して感じただけです。実際にはしっかりとRDBMSを使い切って、業務改善もしっかりと展開された上で、必要だから処理区分を残すという判断の下にUI設計がされているのかもしれません。ただ、もし私の邪推が少しでも当たっているのであれば、これはとても悲しく思います。先人の知恵が活かされていないということになるからです。
そして、実はこの事例に限らず同じような展開になっているプロジェクトが多数存在することも、残念ながら私は知っています。ですから記事へのリンクは伏せておきます。このプロジェクトだけの問題ではないからです。問題なのは道具を流行りのものに差し替えさえすれば後は上手くいくかのように煽る一部の利権屋であり、それに乗せられてしまうプロジェクトというのも正直どうかと感じるのです。
学びの最中にやり過ぎてしまうことはあります。例えば過度の正規化によって逆に性能を劣化させてしまうとか、妙にオブジェクト指向を意識しすぎて変な構造にしてしまうとか、そういうことはあるでしょう。実際に私にもそういう麻疹にかかってた時期があります。しかしそれは前に進もうとしているだけ、言い訳がましいのですがまだマシな気がします。新しい酒を新しい革袋に入れようとしてるのですから、そこからは学びがあるはずですし、実際に多くの学びを得ました（その大半は書籍や雑誌での記事で公開させて頂きました）。
新しい革袋に古い酒を移し替えるだけ、というのは、正直どうかと思うのです。結果として、リスクを無駄に大きくしてしまっているように見えます。昨今では日本のIT/SI業界は世界に通用しないとか色々と言われたりしていますが、通用するかどうか以前の話として、きちんと改めるということの意味を理解することが重要なのではないかと感じるのです。
■役に立つということ
エンタープライズとかいうのであれば、業務システムの開発に携わるのであれば、もっときちんと技術的な基礎・基本を押さえるべきではないか。流行り言葉を振りかざして格好つけるよりも先に、やるべきことが山ほどあるのではないか。そう思うのです。業務のあり方に関すること・使い勝手に関すること・管理する情報の扱い方に関すること、以上の三点はテクノロジがどう変遷しようとも、業務システムを作るに当たって無視できないことです。そこを脇に置いて、目先の作り手サイドの気持ち良さだけをとやかく言っても、本当の価値は生まれないのです。
従来ホストコンピュータで稼働していたシステムをWebアプリケーション型で置き換えたプロジェクトに技術支援として関わったことがあります。徹底的にUIを考えました。正確にはプロジェクトメンバーの皆さんに考え抜いて頂きました。結果として処理区分のあったホスト時代とは似ても似つかない画面になりました。リリース前の現場への説明会の際に50代の女性が「今まで色んな画面の説明を聞いてきたけど、今回のならすんなり使える気がする」という風におっしゃってくださったそうです。頑張ったプロジェクトメンバーが報われた瞬間でもあります。従来通りでなくても、便利になればそれを受け入れてもらえるのはどんな商売でも同じです。プロとしての意地の張りどころだと思うのです。
自社に照らして考えれば、他人の振り見て我が振り直せ、という一言になるのでしょう。スタロジとしてもお客様に提供するものをもっと見直していかなければならないと感じています。一方で、やはり「業界の未来を云々」と言ってる方々においては、こういうことをもっと改めていけるような取り組みこそが重要なのではないですか？ と問いかけておきます。シュプレヒコールの前に、もっともっと地道な、ですがエンジニアとして不可欠な、やるべきことがいっぱいあるように思うのです。
スタロジは、マジカ！やギョイゾー！などを通じて、お客様のお役に立つシステムを提供できるようにこれまで頑張ってきました。上記のような偉そうなことを書いていても、まだまだ未熟であるのは事実です。4月の終わりにギョイゾー！を発表しましたが、多くの声を頂いて地道に成長しています。年内中には多少なりとも成長の証をきちんと示すことで、業務システムというのはこういうことが出来るのだということをお伝えしたいと考えています。
他所様のことをとやかく言える資格があるのかと言われると耳が痛いのも事実ですが、さりとて正直これはどうなのかなと思うと、書かずにはいられなかったので書いた次第です。この投稿を自社に対する十字架にする気概でこれからも頑張ります。
追記：
気になって改めて見てみると、ソースコードを含めて設計書などが公開されていました。素晴らしいことです。この事実に対して素直に賛辞を送ります。早速ざくっと拝見させて頂きました。
UIについてはやはり微妙ですね。この業務を是とする前提であれば、やはりこうなってしまうのかもしれません。端末の配備だったり人員の活用（以下略）だったりを考えるとこうなってしまうのでしょうか。惜しいなという気がします。
データベースのテーブル設計は意外と普通でした。良いとは決して言えないのですが、このシステムは基本的に帳票出力機なので、これはこれで割り切ればありなのかもしれません…とは言い辛いかな〜、やっぱり。細かいところで排他の関係のフラグが別個に存在してたりとか、まぁそういうのは見逃すとしても、ん〜、気になる箇所は色々とあります。
バッチ処理はソースコードを拝見させて頂きました。残念ながらビンゴでした。これはテーブル設計と表裏一体の関係になっていて、テーブル設計がこうだからバッチ処理もこうなるのか、そもそもこういうコードの書き方を想定してテーブル設計をしているのか、恐らくコードの書き方に従ったのかなという感じを受けます。これだと性能を出すのは確かに大変です。拙著「SQL書き方ドリル」を真剣にお奨めしたいです。
…というわけで、これを無条件に横並び的に手本にするのはやはり問題だと感じます。今後の活発な議論を期待したいです。とはいうものの、こうやって外部の人間が論じられるというのは素晴らしいことだと感じます。改めてオープンにすることの意義と意味を実感しました。スタロジもOSSの恩恵に浴しているわけですから、このあたり見習いたいと真剣に思います。せっかくここまで業務仕様が公開されているわけですから、折を見て「スタロジならこうする」的なものを作ってみたいなと感じました。今すぐどうこうというわけではありませんが、このあたり色々と考えてみたいと思います。
締めとしては「やはりオープンというのは素晴らしい」ということになるでしょうか。その上で「オープンであれば良いわけではない」というわけで、切磋琢磨・自己研鑽を怠らないように心がけなければならないということを書かせて頂いて、一度この件はクローズとさせて頂きます。
トラックバックURL
この記事へのトラックバック
1. 業務システムについて [ Think Not Forever ] 2008年09月22日 00:46
http://blog.livedoor.jp/habuakihiro/archives/65101791.html 読みました。妙に納得というか。 今まで仕事してきたけど、目をつぶってきた部分をまっとうに書かれたというか。 今までやってきたのは、「帳票なんて、既存のものからビタ一文変えませんぜ」というやり方であ
2. 業務システムの変化 [ mark-wada blog ] 2008年09月24日 11:26
技術とか考え方などは時とともに変化するものである。それは、新しいいいものが開発さ...
