update it, Inc.社長のブログ

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

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

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

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

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

これは私の知人から教えてもらった、心に残ったユーザからの一言です。

「システムを作るのは一時かもしれないが、私たちはそれをずっと使い続けるのです」

システムを作る側は、作っている間はそれに打ち込んでがんばるわけですが、リリースしてしまうとそれで終わったと考えがちです。しかしユーザはむしろリリースしてからが本番で、そこからシステムとの長い付き合いが始まります。

作る側も、そのシステムをどんな人達がどのように使い続けてくれるのか、またそのシステムについてどう思うのだろうか？　そんなことを考えながらつくるべきなのでしょう。そしてリリース後、何年間もユーザが使い続けられるシステムとしなければならないという責任感も、よりいっそう沸いてくるのではないでしょうか？

ビジネス的な観点では「凝る事」はコストがかさむだけであまり評価されないことが多いですが、ユーザ側の視点で喜んでもらえるようにシステムを凝ってみて、長い間喜んで使ってもらえるようにすることは、長い目でみれば大きなプラスのリターンが得られるのではないかと考えます。

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

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

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

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

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

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

プロジェクト・マネージメントは人をリソースとして扱うことから始まりますが、私はこの、人を「リソース」と呼ぶことが嫌いです。なぜならば人は一人ひとりが異なり、基本的には交換できないものであり、お金や資産などといった顔の見えない何か物質的なものと同等に扱うことに抵抗があるからです。

確かに人はマニュアルどおりに動きさえすれば良い、といったような職種も世の中にはあるかもしれませんが、システム開発のプロジェクトに関わる人達というのは単純にマニュアル通りに動けば済むような簡単な仕事ではありません。各自がそれぞれ過去の経験を通じて様々なノウハウを培っていて、そういったノウハウを活用することで始めて成り立つ職種です。この人達は簡単には交換できないのです。

一方でシステムが特定の人に依存してしまう状態のことを「属人的」と呼んで、一般には避けるべきこととしています。が、本当にそうなのでしょうか？　例えばある複雑なシステムに関与した人が非常に優秀で、いろいろと湧き上がる問題を次々と解決していたとします。そうすると周りがその人がいないとシステムが成り立たないと考えて、属人的になってしまっている、と判断する場合があるかもしれません。

確かに上記のケースではもしその優秀な人がいなくなってしまったらどうするのか？　というリスクが存在します。でもそのような複雑なシステムに関与する人は、それについて徹底的に理解するしかありません。理解してマスターするには時間がかかるのです。つまり複雑なシステムを扱っている以上、その人は本質的に簡単には交換できないのであり、「属人的」と呼ばれる状態にならざるを得ないのだと私は考えます。

これはドキュメントを整備してあれば済むというものではないことも皆さんは感づいているでしょう。もちろん最低限、ドキュメントはそろっているべきなのですが、それが揃っているからといって事が起こってからドキュメントを見ればいつでも対処可能なんてことはありえませんよね。ドキュメントやマニュアルでは未知の問題に対する対処法は書けません。やはり事前そのシステムを十分に理解しておくことが必要であり、その理解度が十分に問題に対処可能になるまで深まるには時間がかかるのです。

究極的にはシステムの複雑さを減らすことがベストなのですが、元が複雑なものから単純なものへ変えることができるのはよっぽどの天才でなければできない仕事で、まさに「属人的な」仕事が要求されます。

見方を変えると、属人的なのが問題なのではなく、その人がいなくなってしまうリスクが問題なのだと思います。まずはその人がいなくならないよう努力すること、そして時間をかけて同じレベルまでこなせる人を育て上げることこそ、本当のリスク回避と言えるのではないでしょうか。

今までのシステム開発を通して、ユーザから言われたことの中で、心に残った一言を１つ御紹介します。

「システムとは皆が使う入れ物なんだ。」　これは今から１０年以上前、あるシステムをリリースしたものの、なかなか現場で利用されない状態になってしまったときに、あるユーザの方から言われた一言です。

私はそのときまで、カッコいいシステムに憧れて、最先端の技術をふんだんに使ったシステムを作ることにやりがいを感じていました。そのときに作ったシステムも技術的には自分なりに「いけてる」と思って取り組んでいたのですが、特定ユーザのニーズのみを考え、関連する他のユーザのニーズの取り込みをおろそかにしたために、業務的にうまく回らない状態になってしまっていたのです。

その当時親しくさせて頂いていたあるユーザの方が、机の上のトレイを手に持ち、こう言ってくださったのです。「このトレイは単なる入れ物に過ぎないけど、みんながルールを決めてこの上で書類をやり取りしだすと、これはもう、立派なシステムになっているんだ。」

そう、システムというのは皆が使って初めてシステムになるのです。ことわざに「仏作って魂入れず」というのがありますが、私はまさに魂を入れ忘れていたのでした。

今でも新しいシステムを設計するときにはいつも、このときのユーザの方の言葉を思い出し、このシステムは皆が使ってくれる器になってくれるのだろうか？　そんなことを考えるようにしています。

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

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

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

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

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

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

タイトルを見てニヤリとした人はおそらく競馬ファンの人ですね。  :cool:（ちなみに私自身はまったくやらないので、実はこのハロンというのは知りませんでした）

最近社内でやっていることに、この第１ハロン、第２ハロン、第３ハロンというのがあります。ハロンというのは距離の単位で、競馬では一定の距離ごとにハロン棒というのを立てているそうです。私たちのプロジェクトにおいては、このハロンがそれぞれある決まった時刻を指しています。そしてその時間になるとみんなで集まって、前のハロンから今のハロンの間に自分がした事、そして次のハロンに向かって自分はどんなことをやろうと考えているか、を各自表明します。

つまり２?３時間という非常に小さな単位に対する目標を立てて、それを全力でがんばり、結果を確認する、という至極単純なことを繰り返すだけなのですが、こうすることで２つのメリットがあると思います。まずは小さな目標を立てるということです。２?３時間後というのはとても手軽に、気軽に立てられる目標になります。

そしてもうひとつはリズムです。少しの時間集中した後、ハロンの間は気軽にみんなと話し合うことで少しリフレッシュする、このリズムがちょうどいいように思えます。

弊社の社員が考えついたことなのですが、いまのところいい感じで回っているので、当分続けてみるつもりです。

皆さんのところでも試してみてはどうでしょうか？

隣の公園シリーズ

のんびりできますよ。

システムを設計する際に非常に気を使ってきた事として、このデータベースの設計があります。システムの中身（作り）についてはユーザ側では理解できないことが多いので、ユーザ側の注文は「外部仕様」に集中しがちですが、ことデータベースについてはユーザ側でもある程度容易に理解ができるということもあり、いろいろと突っ込まれやすい部分です。

確かにデータベースの設計においてはユーザ側の要件を明確にするために、ユーザ側にいろいろと確認しなければならないことが多々あります。例えば、こんなものです。

１．データ間の関係。１対１なのか１対多なのか、多対多なのか
２．データは変更・削除履歴を保持すべきか
３．データの発生する量
４．コード体系（単にどのコードを使うということだけでなく、どこの誰がいつ、どのようにコードを発番し、どのようにメンテナンスするのかなど）

変更・削除履歴というのはデータモデリング上は気にされにくい、機能に関する部分なのですが、もし必要となると結構厄介なものです。操作内容を操作履歴として保持すれば良いだけなのか、それとも対象のデータそのものを履歴データとして保持しなければならないのかなど、要件によっても構造が変わってきますし、もし対象のデータそのものを履歴データとして保持しなければならない場合にはユニークキーをどう設計するのか、履歴データ間の紐付けをどうするのか、実際のデータ容量を考えた場合、それは十分なパフォーマンスを確保できるのか、過去データの修正入力は可能とすべきか、など頭の痛い問題が多い機能です。

コードの一貫性なども設計上頭の痛い問題の１つです。私の出身の金融系の世界では様々なコードが存在しているのですが、困ったことにそれらのコードにはたまに変わったりするのが多々あります。もしそのような一貫性に欠けるコードをデータの主キーに使ってしまうと、コードが変わったときにそのコードを使っている全データのメンテナンスが発生する、といううれしくない事態になってしまいます。

これを避けるためにいちいちコードに対応する別なキーを機械的に付与して、これを主キーとして設計するという手法が良く使われるのですが、こんなのはなかなか説明しても理解してもらえる部分ではありません。またこうしたからといってすべてOKというわけでもなく、様々な事象について具体的に検討を重ねておかないと、運用し始めてから対応できないことに遭遇する、なんて最悪な事態を迎えかねません。

１つ言えることとして、こういった業務に直結した部分にノウハウを有しているシステム開発会社は、ユーザに対して強い立場になれるということがあります。単に言われたとおりに作るのではなく、対象の業務領域について、どういうデータ構造であるべきかがわかっていて、その方式についていくつかのやり方をメニューとして提案できる、そんなシステム開発会社は明らかに高い競争力を保持することができるのではないでしょうか。

近くの公園で撮った写真です。ここはどこ？って感じでしょう。

今日は初夏の陽気でいいですね。