update it, Inc.社長のブログ

物の本には、プログラムを作る際にはパフォーマンス・チューニングは最後にやるものだ、と書いてあります。これ、ウソだと思います。

もちろん最初からプログラム上の小細工をしてパフォーマンスの良いプログラムを書け、ということではありません。が、システムの基本的な処理フロー、基本的なアルゴリズムの部分が根本的に間違っているときには、いくら最後に小細工してもどうしようにもない場合があります。もしそうなってしまうとデータモデルも含めて大幅な修正が必要になってしまうことだってあるのです。

だからシステムを作る際には、まず粗々の処理フローを組み上げたときに最初にパフォーマンステストを実施すべきです。その時点で既に問題があったら最初に戻って再設計が必要ということになります。

この手の問題は、例えばネットワーク上に分散されたオブジェクトを扱っていると特に良く遭遇します。オブジェクトのやり取りの粒度を間違えるとパフォーマンスに大きな影響がでますが、この修正はいろいろと影響がでやすく、最後に行うにはあまりにもでかいものです。これからSOAやろうという人は気をつけてくださいね。

予めパフォーマンステストを早い段階で実施しておけば、その後機能追加によって徐々に遅くなった場合の許容度を見積もることもできるようになります。最後になってあたふたしないためにも、プロジェクトのリスク管理の一環として早めのパフォーマンス・テストの実施をお勧めします。

あらかじめ断っておきますが、以下の話は今当社が研究・開発しているものとはまったく関連がありません。純粋にこうしたらいいんじゃない？っていう話です。

今から１０年以上前の話なのですが、私は昔、当時勤めていた会社内で「コンポーネントウェア宣言」なる文章を書いたことがあります。コンピューターのハードウェアは最初は真空管に始まり、トランジスタ、ICと徐々に集積度があがり、最終的にはLSI（大規模集積回路）と呼ばれるまで集積度が上がったのだけれども、ソフトウェアも徐々にそのように集積度があがり、コンポーネント単位で扱われる時代に変わるでしょう、そこでどんな「コンポーネント」を用意したらビジネスになるのか考えてみませんか？という内容でした。

ま、正直なところ社内で相手にしてくれる人はあまりいなかったのですが、その後ERPソフトをベースにした商売を外資系システムコンサルティング会社がやっているという話を聞いたときに（ERPソフトがコンポーネントといえるか？という点は若干あるものの）、やっぱりそうなってきたな、という実感がありました。

さて現代。今までフレームワークというと、どちらかというとシステム的基盤として用意されることが多かったと思うのですが、私は今後、業務システム毎のフレームワークというものを作っていくべきだと考えています。そう、業務システムのコンポーネント化です。ERPソフトはその１形態に過ぎないと思っています。もちろん基盤とするシステム技術としては一般的なフレームワークを利用するのですが、その上にカスタマイズ可能な業務アプリケーションを作りましょう、という話です。

少し前のブログ拡張ポイントは計画的に その２において、一般の業務系のシステムでも拡張ポイントを予め設計しておくべきだという話を書いたのですが、この拡張ポイントを正しく設計するというのが業務システムのフレームワーク化だと考えます。

システム基盤としてのフレームワークは低レベル階層のものでしかありません。カスタマイズ可能な業務システムとして、業務に特化した高レベル階層のフレームワークが一旦構築できてしまえば圧倒的な強みとすることができるはずです。

以前大量のメールが飛び交うでプロジェクト内でのメールのやり取りの多さについて書いたのですが、今回はビジネスインフラとしてのEメールについて書いてみたいと思います。

Eメールは今やビジネスインフラとして完全に定着しているといって良いでしょう。仕事上のやり取りを行うには実に優れた仕組みです。BtoBの商売であれば、まずほとんどのケースでメールでのやり取りが可能だと思いますし、履歴も自動的に残るので、電話の場合のように言った、言わないの問題になることがありません。またPUSH型の仕組みでありながら、いつメールを読むかは読み手側の都合で決められるので、うまく使えば非常に効率的に仕事が進められるようになります。

ある意味でFAXが似たような情報伝達の仕組みだといえますが、送る手間、受け取る手間、整理する手間など、FAXはいろいろ手間がかかりますよね。私の場合、FAXとメール、どっちかを選択しろといわれたら何の躊躇もなくメールを取ります。とまあ、便利なことは間違いないメールですが、一方でスパムメールの多さに辟易している方も多いと思います。またスパムメールとはいえないものの、こちらがそれほど読みたいとは思わない広告メールを送り続けられる、というのもあまりうれしくない話です。

スパムメールに対してはスパムメールフィルタが便利なのですが、間違えて通常のメールがスパムメールとしてブロックされている場合が多く、ちょくちょくスパムメールのリストをチェックしなければならない点が難点です。またドメイン名でスパムメールを判別している場合、ちゃんとした会社のドメイン名がなぜかスパムメールのブラックリストに載ってしまって、そのお客様からのメールがいつの間にか受け取れなくなっていた、なんてこともありました。

スパムメールは送信にコストがかからないことに起因していると思います。そう考えると実現性は薄いのかもしれませんが、インターネットとは別の、送信するのにコストのかかる有料のビジネスEメールネットワークなんてのがあっても良いのかもしれませんね。

昨日、ANAが予約や搭乗手続き、手荷物管理などを行うシステムでトラブルが発生し、予約や発券、搭乗手続きなどがしにくくなったため羽田空港を同日午後6時までに出発するすべての便を欠航にした、というニュースが流れていました。このニュースの詳細はまだよくわかりませんが、気になったことがあります。コンティンジェンシープランはどうしたの？ということです。

飛行機を制御するようなシステム、すなわち安全に直接関連するシステムの場合にはそもそもシステムトラブルが絶対に起こらないように二重三重の対策をする必要がありますが、今回トラブルを起こしたシステムはチェックインのためのシステムということで、業務の自動化システムであり、直接安全性に関わる部分ではないように思えます（実際のところはわかりませんが）。一般に業務を自動化するためのシステムの場合、万が一そのシステムが停止した場合に備えてコンティンジェンシープランを作って備えておき、いざとなったらマニュアルで運用して回避するのが普通だと思うのですが、今回の件はどうだったのでしょうか？　新聞を読む限りは職員が手作業で対応したが追いつかなくなり、朝の段階から遅延や欠航が出始めた、とありますので回避策は一応行ったのだと思いますが、準備が足りなかったのかもしれません。

システムを設計する際に、このようなシステムトラブルに対応するための仕組みを用意しておくことも重要です。例えば証券系の発注システムの場合、取引所へ発注するたびにそのログをラインプリンターに印字する場合があります（今どきラインプリンター？といわれてしまいそうですが、１件発注するたびに紙媒体上に１行記録するにはこれが一番良いのです）。　こうして紙に残しておけば、万が一その時点でコンピュータがダウンしたとしても、最低限のことはその紙を見ながらマニュアル対応でなんとか切り抜けられるようにするわけです。そして数が多い場合には人海戦術で対応できるように準備しておきます。

ハードウェアのトラブルの場合には交換することによって復旧できることが多いですが、ソフトウェアのトラブルの場合、そう簡単には復旧できない場合があります。その場合に備えて、可能であればマニュアルでなんとかなるように設計しておくことがコンティンジェンシープランへの第一歩だと思います。

プログラマーの間に一般に浸透してきたリファクタリングという言葉ですが、誤用が目立つという話を聞きました。プロジェクトのメンバーがいつまでたっても進捗が進まず、何をやっているのか聞いてみると、延々とリファクタリングをしていると言う。でもどう考えてもやっていることはリファクタリングではない。確かにこの手の話は私もたまに聞きます。

上記の例では作り直すことをリファクタリングと称していて、実際にやっていたのはリストラクチャリングだった、ということでした。確かにリファクタリングとは作り直すことの一種ではありますが、外から見たときの振る舞いを変えずに中身を洗練させる作業であり、振る舞いが変わってしまうような場合にはそれはリストラクチャリングと呼ぶべきです。しかしリストラクチャリングという言葉が一般化していないためか、もしくはリファクタリングという言葉がかっこよくて、ある種免罪符のように使えるからか、なんでもかんでもリファクタリングと称してしまう場合があるようです。

リファクタリングは常に推奨すべき行為だと思いますが、リストラクチャリングとなると通常時間、つまり工数がかかるので、実施すべきかどうかはプロジェクトの状態によって判断が分かれると思います。それが今後のシステムの開発を阻害するような問題を含んでいる場合にはリストラクチャリングすべきですが、そうではない場合には無理に行うべきものではありません。

行っている行為がリファクタリングなのか、それともリストラクチャリングなのかの判断は、厳密にやろうとするといろいろ議論があって難しいと思いますが、１?２時間以内、どんなに長くてもせいぜい半日以内に完了するレベルがリファクタリングであり、それを超えるレベルの場合にはおそらくリストラクチャリングになっていると思います。もし皆さんのプロジェクトのなかで何日間にも渡ってリファクタリングをしているという例があるのであれば、それは本当にリファクタリングなのか、もしリストラクチャリングであるならば、それは本当にいますべきリストラクチャリングなのかを判断させるべきだと思います。

この間オープンしたホームページのコミュニティー欄に、プロジェクト・アンチパターンとして「社内共通基盤を利用する」というストーリー（ユースケース？）を載せました。

この話の背景として、採用を強制させられそうな基盤技術が既に陳腐化してしまっているということがあります。では基盤技術の陳腐化がどんなときに起こりうるのかを考えてみました。

１．要素技術（使用言語、対象OS、対象とするサーバ、データベース、ハードウェアなど）が陳腐化しているとき
２．要素技術側のバージョンアップに追いつけなくなっているとき
３．メンテナンスが行われなくなったとき、もしくはおこなわれにくくなった状態のとき
４．メンテナンスがボランティアベースの場合に、メンテナンスする人々の興味が失われた場合

最後のは最近のオープンソースでたまに（良く？）見かけるケースです。  😀

こうやって考えてみると、基盤技術というのは生き物のようなものなのだな、思いました。作ったらそれで終わりということではなく、手間ひまをかけてメンテナンスしていかないと、放っておけばあっという間に死に絶えてしまうのです。

基盤技術をうまく生きながらえさせるには、なにかエコ・システムを作り出さなければならないのだと思います。

拡張ポイントは計画的に、の第２弾です。

仕事で統合開発環境のEclipseを良く使っているのですが、このEclipseが偉大だな、と思うのは拡張ポイントがソフトウェア的に定義されている点です。通常アプリケーションに新しい機能を追加する場合には、ソースコードに手を入れる必要がありますが、Eclipseでは拡張ポイントを外部に対して公開することで、Eclipse本体のソースコードには手を入れずに様々なプラグインを組み込んで新しい機能を統合して使うことができるようになっています。

正直なところ、Eclipseの中のコードそのものはあまりきれいだとは思わないのですが（失礼！）、統合開発環境としてのフレームワークとしては非常に良く設計されており、特にこの拡張ポイントをどこにどのように設定すればよいかという部分は統合開発環境としてのノウハウの集大成のように思えます。

こういった概念は一般の業務系のシステムでも同じように定義されていて良いものかもしれません。そうすることによって本体のコードは同一のものを保ちながら（シングルソースコード）、ユーザ毎のカスタマイズが可能になるわけです。

そして各業務システム毎に、どういった部分を拡張ポイントとして設計するのかが大きなノウハウ部分といえましょう。

最近「ご利用は計画的に」というフレーズがある業界のCMで流行っていますが、今日のテーマは「拡張ポイントは計画的に」です。

システム設計にはできるだけ対象の事象を一般化し、拡張性を考慮した上で設計することにより、様々なケースに対応できるようにする、という一種の美学があると思います。確かに美しいのかもしれませんが、その美しさが役に立たつことのないままシステムが寿命を迎えるということも多いのではないでしょうか。そうなってしまうと、その美学のために費やした時間とお金は無駄になってしまう、ということになります。

このことへの反動からXP（エクストリーム・プログラミング）では、「YAGNI = You Aren’t Going to Need It.」（今必要なことだけ行う）というスタンスで、最初から無駄に拡張性を考えてプログラムを作るな、今必要な機能だけをシンプルに作れ、と説いています。これもこれで一理あるのですが、そうは言ってもはじめから必要性がわかっている部分についてはきちんと拡張性を考えて作らないと、やっぱり大幅に作り直しが必要になって無駄な作業が増えることになりかねません。

むしろ重要なのは、どの部分には拡張性が本当に必要なのかを十分に検討しておくことだと思います。拡張性が明らかに必要な部分だけ、拡張性を考慮した設計にすればよいのです。それ以外のところは「この方が拡張性に富むから」という理由で無駄に複雑なものは作らない。このようなスタンスでシステムを開発するのがもっとも効率が良いと思います。

業務的な観点からどこを拡張できるようにすべきか、その拡張ポイントをきちんと明確にして、クライアントとよく「握って」おきましょう。

オブジェクト指向は当初はソフトウェアの部品化と再利用を促進するため、という理由付けが行われることが多かったのですが、一般に普及した現状ではあまり声高に再利用を唱える人は少なくなりました。実際に振り返ってみると、オブジェクト指向によって再利用が促進された対象には偏りがあると思います。

例えばGUIの部品などは再利用されやすいものです。一度作った使いやすい部品はプロジェクトを超えて容易に再利用化されます。他にもデータベースとのインターフェースの仕組みやロギングなど、システム的でかつ一般的な部品は比較的再利用されやすいといえます。

それに対して業務に即した部品など、何かに特化した部品はなかなか再利用されません。例えば金融向けのアプリケーションの場合、もしあるシステムで債券や株などを表すクラスを定義したとしても、それをそのまま他のシステムに流用できるとは限りません。対象の用途を限定して同じようなシステムに適用する場合にはある程度は流用可能ですが、ちょっと使い道が異なるシステムとなると役に立たないことが多いのです。

つまり何をオブジェクトとして表現するのがちょうどいいのかが、対象の業務によって異なるということです。例えば同じ債券を扱うシステムでも、それを取引管理システムの中で扱う場合と、在庫リスク管理システムの中で扱う場合では同じ債券という概念でもシステムの中での取り扱われ方が異なるということです。

ただし業務寄りの部分でも、もう少し大きな粒度では比較的再利用がしやすくなります。例えば上記の例では取引管理システムとか、在庫リスク管理システムという単位での再利用はむしろやりやすいのです。もちろん同じような取引管理をする場合とか、同じような在庫リスク管理をする場合に限られます。業務的にみて似通っている場合には再利用がやりやすいというわけです。

業務的な観点で対象業務毎にフレームワークを持つことができるかどうかが再利用化の鍵だといえます。

アプリケーション・データベースとは私が勝手に作った名前で、エンタープライズ・データベースの反対の意味です。

エンタープライズ・データベースとはある会社の基本的なデータを集約して持っているようなデータベースで、企業活動におけるデータの入り口にあたり、複数のシステムから参照されるようなものです。一方、私がアプリケーション・データベースと呼んでいるのは特定のシステム、もしくはアプリケーションからしか参照されない、閉じたデータベースのことです。

エンタープライズ・データベースはオープンであり、複数のシステムから参照されるものなので、中のデータは広く会社全体で共有可能な形式で保持されなければなりません。つまり特定のアプリケーションを意識したデータ構造ではなく、さまざまなアプリケーションからでも利用可能な一般的なデータ構造でなければなりません。

一方のアプリケーション・データベースはクローズドなので、中のデータの形式は特に問われません。多少特殊でもアプリケーションから利用しやすいデータ構造が利用可能です。

システムを新たに設計する際には、対象とするデータベースがエンタープライズ・データベースなのか、それともアプリケーション・データベースとしてよいのかを見極める必要があります。もしエンタープライズ・データベースとすべきものであれば、特定のアプリケーション固有のデータ構造はできるだけ排除すべき、といえるでしょう。逆にアプリケーション・データベースとみなせるのであれば、中のデータ構造はできるだけアプリケーションから利用しやすい形式のほうが望ましいといえます。

O-Rマッピングツールを用いる場合、O-Rマッピング側の都合の良い構造にすることが可能なのはアプリケーション・データベースということになります。もし対象とするO-Rマッピングツールが対象のデータベースについて特定の構造を前提としている場合には、エンタープライズ・データベースには適用すべきではないといえます。そのような場合には他のO-Rマッピングツールの適用を検討すべきでしょう。