アイロベックスメールマガジン　携帯版

明けましておめでとうございます。
すでに10日以上過ぎてしまいましたが、2009年初のメルマガとなります。
本年もよろしくお願い申し上げます。

多くの企業の方々からシステムのご相談を受けていると、「今あるシステムを直したい。拡張したい」という件をよく伺います。

そして、「現在使用しているシステムを作った会社がもう存在しない」「現在のシステムを作った会社と付き合いがない」会社が存在していても、「担当者が辞めたため、保守出来ないと言われた」というご相談が思いの外多いのです。

そこで、これから数回を「システムリフォーム」と題して、リフォームの視点からシステム開発を見直そうと思います。

これからシステム開発を依頼する方々も、システムのリフォームを行うときのことを考えて、知識として知っておくと良いかと思います。
システム開発に携わる方々には、非常に重要なテーマです。

現在システムを運用保守していらっしゃる方々に、何かヒントを掴んでいただくのも今回のテーマの狙いです。

また、このテーマを執筆することで、過去の経験や知識を整理して自分も何かを再発見してみたいという身勝手な考えもございます。

では早速ですが本題です。

システムをどこかの会社に依頼して作ってもらった、動いている、しかし修正や追加が出来ない。
どこの会社にどう頼んでいいのかわからない。
違う会社に頼んだら、とんでもない金額を請求された。

以上のような場合に、最低限必要なことは、以下の項目を確認することになります。

1)そのシステムが動く(動いている）オペレーティングシステム（OS）を確認する。

例:WindowsXP,WindowsServer2003,Linux など

2)プログラミング言語またはツールを確認する。

例:Java,VB,VB.NET,PHP,Perl など

3)データベース使用の有無とデータベース製品名を確認する。

例:使用無 テキストのみ、またはExcel など使用有 Oracle,SQLServer,MySQL など(出来れば細かくバージョンまで確認する。）

4)ミドルウエアと呼ばれる製品を使っているか、否か。使っていればその製品名とバージョンを確認する。

2)のプログラミング言語には2種類あります。
1つはソースがありコンパイルしてオブジェクトを作る形式のもの。
もう１つはインタプリタと呼ばれる、ソースがそのままで実行出来る形式のものです。

言語がコンパイル形式の場合、最新の（つまり、今動いているオブジェクトを作った）ソースがどこに保存されているのかということも非常に重要です。

ドキュメントがある、無いという前に、まず以上の情報をきちんと把握する必要があります。

そして、「2)プログラミング言語またはツールを確認する」がコンパイル形式の言語であり、ソースが無い、もしくは、どれが最新かわからないといった場合はシステムリフォーム出来る可能性は低くなってしまいます。

だからこそ、開発会社はソース管理をきちんとすることが、リフォームに向けての1番大事な仕事といえます。

最後にユーザーと開発者へ質問です。

ユーザーへの質問：開発会社任せではなく、きちんと1)から4)を書面で管理・保存していますか？

開発者への質問：ソースが現在のシステムにおける最新のものであると100%保証出来ますか？

世界的な新車販売の低迷を受け、トヨタ自動車の部長級約2200人が3月末までに自社の新車を購入する取り組みを始めたことが13日、分かった。
http://www.business-i.jp/news/flash-page/news/200901140004a.nwc

先週の驚きはこのニュースでしょうか。
読み進んでいくと、ある幹部は「自ら買って乗らなければその良さがわからず、人にも勧められない」と話し、販売回復の一助を担う意味合いを強調する。

とありました。
「トヨタの部長なのにトヨタ車に乗っていない人もいるのか」と驚きました。
トヨタ車以外を購入する理由として、「競合相手の車に乗って調査する」という理由もあるかもしれません。

でもそれは2台目の話なのではないでしょうか。
もし、私がトヨタに入社したのであれば3年ごとに新車を購入していたはずです。
これは断言出来ます。

「お客様の視点でものを考える」ことは商売の鉄則のはず。
次々と売り出されている新車に乗らずとしてどうする、というのが私の感想です。

さて、自分たちの仕事に置き換えてみれば、企業の業務システムを開発している会社の場合には、2種類のお客様の視点があります。

・1つ目のお客様の視点は「納品する企業の社員の視点」
・2つ目のお客様の視点は「納品する企業が相手にしているお客様の視点」です。

技術者は「納品する企業が相手にしているお客様の視点」つまり「顧客の顧客」の視点を、つい忘れがちであることを肝に銘じておきましょう。

さて、前置きが長くなりました。
「システムリフォームから考える　その2」です。

システムリフォームを受ける場合に、一番問題になる部分はどこかおわかりでしょうか。

それは「ビジネスロジック」なのです。
どのようなものがビジネスロジックなのか？
ということから簡単に説明します。

画面のプログラムを例にとって考えてみましょう。
「Tabキーで移動だけでなく、Enterキーでも移動する」や「エラーのとき赤く表示する」といったことは、ビジネスロジックではありません。

「単価を計算するときに、仕入先のフラグをチェックして、ある率を掛け合わせて計算する」というように、その企業の独自のルールがビジネスロジックです。

消費税計算はどうかというと、ビジネスロジックではありますが、その企業のオリジナルのビジネスロジックではありません。

一番問題になるところは、この企業独特のビジネスロジックについて、
「どのようなビジネスロジックがあるのか、どのようなものがビジネスロジックの例外になるのか」といったことでしょう。

実際に、システムリフォームをしようとしたときに、これらが「頭に入っている」のと、ソースを読んでしか理解出来ないのでは、後々問題が起きる確率が全く違います。

そこで、ユーザー側にすれば、前回システムを作った担当者、つまり、ビジネスロジックが頭に入っている人物がリフォームを担当することが一番良いと思いがちです。
しかし、一番良いのはビジネスロジックのドキュメントが公に残っていることです。

何故なら、どんなに頭の良い人でも何年も前のシステムの細部まで覚えていることは不可能だからです。
そして、常に「その人がその場所からいなくなったら」というリスクを抱えることになってしまいます。

企業での運用担当者がいつ変わっても良いように、システムの開発担当者も変わることを予期しておくことが必要です。
また、再チェック、相互チェックという観点からもドキュメントを利用しながらの打ち合わせが出来ることが一番望ましいのです。

さて、今回の質問はユーザー企業にとっても辛い質問かもしれません。
なぜなら、システム開発やリフォームに用いるだけでなく、新入社員に業務を教えるためにも、自らビジネスロジックをドキュメント化しているのは企業として基本であるはずなのです。

ユーザー・開発者への共通質問：システム内部に隠された企業特有のビジネスロジックを説明出来るドキュメントは用意されていますか？

追伸：ビジネスロジックは、JAVA、VB.NET、PHPといった言語で表現されるよりもデータベース言語にしておく方が良いと思いますよ。

1月24日は当社の創立記念日でした。
当社の創立記念日は、全員でセレブになった気分。
フランス料理店でお祝いするのが常でした。

あの「シャトーレストラン ジョエル・ロブション」「トゥールダルジャン」「クィーンアリス」など、名店を次々に制覇したものでした。

そして、今回は、……あの「ミシュラン3つ星」の高級レストラン。

ではなくて、ミシュラン観光地に燦然と輝く「高尾山」に登山しました。

あいにく前日は雨でしたが、1,050円の弁当をキャンセルしたら申し訳ない。
雨天決行を強く誓ったアイロベックス社員に、天候は味方してくれたのでした。

というわけで今日も、まだ、脚が痛い。
当日飲んだ酒は抜けたが、筋肉痛は3日後にやってくるというわけです。

さて、前回ビジネスロジックとは、企業独自のロジックであると申し上げました。

追伸として、迂闊に
追伸：ビジネスロジックは、JAVA、VB.NET、PHPといった言語で表現されるよりもデータベース言語にしておく方が良いと思いますよ。

などと書いてしまい、きちんと説明しなかったため意味不明の文になってしまったことと思います。申し訳ありませんでした。

嬉しいことにこの件で先週、読者の方からお問い合わせをいただきました。まず、表現方法があまりにも悪かったことで誤解があったと思うので、今回は詳しく書きたいと思います。

例えば、システム開発を行う場合、プログラム言語を使って開発します。
これが、20年前であれば主流がCOBOL、現在であればJAVAやVB.NETという言語になっています。

大雑把にいうと、入力から出力に加工する。
つまり「inputからoutput」ということなのですが、画面から入力された情報をデータベースに保存して、そのデータを加工して出力するのがシステムというわけです。

そこで、情報を入力する画面を作るには、上記にご説明したプログラム言語を使って開発します。

しかし、画面から入力する、というその機能を実現するためには、ビジネスロジックには関係ない機能がいくつも必要になってくるわけです。

例を以下に挙げます。

・ 郵便番号が入力されたら、郵便番号辞書を検索して自動で住所を表示する。
・ 入力された住所が長すぎた場合、「長すぎて登録できない」というエラーメッセージを表示する。
・ 金額欄に数字以外の文字が入力されないようにする。

以上のような機能です。
このような画面制御の機能も実はプログラム言語を用いて作っているのです。

システム開発の1つの方法としてすべての機能、つまりビジネスロジックも画面制御もすべて同一言語で作るという方法が行われます。

特に、機能数が少ないシステムの場合はこの方法が多いようです。

しかし、1つの言語のみで全ての機能を作るといった場合に問題が起こります。

1)どこがビジネスロジックで、どの部分が「画面制御」なのか、プログラムを読んで切り分けしにくい。
ドキュメントがあったとしても、多くの機能の中にビジネスロジックが埋没してしまいやすい。

2)新しいシステムを作るごとに同じビジネスロジックが、違った場所に作りこまれてしまう。
これは、そのビジネスロジックに変更が起きた場合に、修正しきれない、ミスが起きるという問題も含みます。

そこで、JAVAやVB.NETといったプログラム言語ではなく、SQL ServerやORACLEのストアドプロシジャといったデータベース言語（個別では、Transact SQLとか、PL/SQL等という名前がついています）にビジネスロジックを書くのです。

データベース言語の良い点は何か。

今後もリレーショナルデータベース（RDB）は、プログラム言語よりも長く残っていくものだと考えられます。
JAVAやVB.NETだといったプログラム言語が変わっても、データベースを変えるのはまず無いでしょう。

Webシステムだろうが、クライアントサーバーシステム方式のシステムだろうが、データベースを使うことでこのデータベース言語で作ったビジネスモデルを呼び出せます。

10年くらい昔は、この方式でシステム開発することを、3-Tier（スリーティア）開発などと呼んでいました。

Webだろうが、クライアントサーバーシステムだろうが、大規模だろうが小規模だろうがそこにビジネスロジックがある限り、他の機能との切り分けが必要であるかぎり3-Tier開発は、今でも有効です。

説明がまたまた長くなってしまいました。
ビジネスロジックをデータベース言語で作成すべきというのは、RDBのストアドプロシジャで作るべきだという考えなのがおわかりいただけましたでしょうか。