update it, Inc.社長のブログ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

隣の公園シリーズ

のんびりできますよ。

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

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

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

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

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

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

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

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

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

昨日、ずっと使い続けてきたPDA（CLIE）がついに壊れてしまいました。電源ボタンを押してもうんともすんとも動きません。リセットをかけても電源は入りっぱなしの状態でオープニングの画面以降に一向に進もうとしません。

今となっては非常に少数派になってしまったのですが、私はいまだにPDAをよく使っています。どうも忘れっぽいたちなので、予定はPDAに入れておいてその時間になったらアラームで呼び出すようにしておかないと不安でしょうがないのです。発売元だったSONYはPDAから撤退してしまい、Palm自身も日本では売っていないので、現在PalmOSで日本語が使えるPDAはたぶん売られていないと思います。困った。

と書いているうちに電池を使い切ったCLIEが復活しました。良かった。まだしばらくは使うぞ。

私の場合、普段机にいるときには入力はPCで行い、同期してCLIEに転送して使っています。ペン入力は遅いので、やっぱり入力はキーボードに限りますね。ペン入力はCLIEしかないときの非常入力手段です。

結構便利に使っているのがDiddleBugというアプリケーションで、手書きのメモをそのままま保存しておくことができ、かつワンタッチでアラーム設定を付けて、時間になったらメモを表示するようにすることができます。手書きのメモは入力が速いので便利です。さっと言われたことを書き留めておいて、アラーム設定しておけば、忘れっぽい私でもOKです。

CLIEは起動が早いのもありがたいです。取り出してボタンを押せばすぐに予定を確認することができます。

こんなに便利なPDAなのに、最近はあまり見なくなってしまいました。原因を考えてみると、こんなところでしょうか？

１．余計なお遊び機能がいろいろ付いたが、どれもこれも中途半端で結局使いこなせない。
２．携帯と２つ持つのがうざい。
３．ペン入力が使いづらい。
４．セキュリティー意識の高まりで会社のPCにPDAが接続できなくなり、会社の予定を持ち歩くことが難しくなった。（そもそもPDAを持ち込めないオフィスもある）

特に最近は４が顕著で、PDAはビジネスでは使えないということになると存在意義がなくなってしまいます。PDAは進化の方向を間違えたのでしょうね。もっとビジネス路線に特化して、遊びの機能はばっさり削って、セキュアに、ビジネスのスケジュールも個人のスケジュールも両方を持って歩け、入力も簡単なパーソナルオーガナイザーとして進化すればもう少し生きる道があったのではないかと思います。

システムの世界では最近すっかり市民権を得たオブジェクト指向ですが、私が最初に関わったとき(1991年頃)はまだオブジェクト指向と言えば一般にはオブジェクト指向プログラミング（Object Oriented Programing = OOP）のことを指していました。それがいつの間にやらオブジェクト指向分析(Object Oriented Analysis = OOA）やら、オブジェクト指向設計（Object Oriented Design = OOD）やら、オブジェクト指向モデリング（Object Oriented Modeling = 00M）やら、いろいろなオブジェクト指向なんたらのバリエーションが増え、それらの概念が若いシステム・エンジニアやプログラマーの間でごく当たり前のように語られているのを聞くと、いい時代になったな、としみじみ思っています。

ただし、ちゃんと中身を理解して使っているかどうか。それを応用してきちんと現場で活用できているか。そういう話になると、ちょっと怪しい人も結構多いのではないでしょうか？　そもそもオブジェクト指向ってなんなのか、その良さをきちんと他人に説明できない状態で、OOP言語を使うことがオブジェクト指向だと思い込んでいる人も多いかもしれません。

以前Javaでプロダクトを作るためには、オブジェクト指向分析やオブジェクト指向設計を「しなければならない」と思い込まれていたケースに遭遇したことがあります。新たにJavaでシステムを作るという話になったときに、それまでのやり方をすっかり換えて、すべてオブジェクト指向分析やオブジェクト指向設計（のようなもの）でやらないとオブジェクト指向でプログラムを作ることができない、というのです。

そう思い込んでいる人は、上流工程の分析・設計時にもクラスという概念がでてくるので、それがそっくりそのまま実装の世界でも同じ単位でクラスとしてコーディングされるものだと思い込んでいるんですよね。そんなことをしていたらまともに動くプログラムにはならないってことは、おそらくいっぺん経験（失敗）しないとわからないのだと思います。

確かにオブジェクト指向分析、設計、プログラミング間では親和性が少しは高いと思いますが、「でなければならない」ということでは決してないはずです。通常に業務分析をしたり、データ指向分析をして、プログラミングをオブジェクト指向プログラミングとする、というのも別に悪い話ではありません。特に上流工程に関与する中心人物がオブジェクト指向分析や設計に長けた人ではない場合には、むしろ従来の手法を導入し、プログラミングの工程にオブジェクト指向を導入したほうがプロジェクト全体としてはうまくまわると思います。

昨日、弊社のホームページを立ち上げたことを告知いたしました。見ていただいた方は気づいたと思いますが、Communityというコーナーにはプロジェクト・アンチパターンとして、UMLのアクターの形をした主人公が活躍するユースケース記述が書いてあります。

(もし就業中に見ていて、上司からとがめられた人は、ぜひ「参考となるユースケース記述を見ています」と言ってみてください。ただし結果は保証しません。)

このようなコーナーを用意したのは、決してふざけているのではなく、実際にこれに近いことがこの業界でごく普通に起きているという現実を何とかしたいと考えたからです。実際にどこでも良く起こりがちなプロジェクト・アンチパターンをみんなで共有することによって、改善していくためのきっかけぐらいにはならないか、そんなことを考えてこのコーナーを企画しました。

ですので、ぜひ皆さんにも参加していただきたいのです。皆さん自身が体験した、もしくは見聞きしたプロジェクト・アンチパターンを教えてください。プロジェクト・アンチパターンを集めることができれば、実際にそのような状況に陥りそうになったときに、これを参照することによって、場合によっては役に立つことがあるかもしれません。

みなさんからの積極的な参加をお待ちいたしております。

日経ソリューションビジネスの4月15日号の特集ページ「胎動！ IT業界維新」で、NTTデータが「年内に『セル生産方式』のパイロットプロジェクトを走らせる」という記事が載っているようです。（「ようです」と書いたのは、私自身は日経ソリューションビジネスを取っていないので、ITProに公開されている記事の抜粋を読んだだけだから、です。  :grin:）

セル生産方式とはキャノンなどが取り入れて有名になった生産方式で、Wikipediaによると、「1人、または複数人の作業者チームで製品の組み立てを行う。ライン生産方式などの、従来の生産方式と比較して作業者一人が受け持つ範囲が広く、場合によっては最初から最後まで1チームで担当する。」となっています。製造業向けの生産方式の１概念なのですが、NTTデータではそれをシステム開発の現場に適用し、「NTTデータの社員がシステム構築における上流だけではなく、中・下流のソフト開発やテストをパートナーと共同で進める」ことを意味するそうです。

「そんなことはもうやっているよ」っていう会社もあるかもしれませんが、これだけ大手のSI会社が中・下流も自分たちが主体的に絡んでやっていこう、という姿勢が現れているということはとっても良いことだと思います。

このセル生産方式は、作業工程の一人ひとりのスキルの高さを前提に、優れた少人数のエキスパートチームによって製品を作り上げるということがポイントです。少人数のエキスパートチームということであれば、いろいろな雑多で複雑なことを扱うには大組織よりも明らかに向いていますし、中の人達の士気を非常に高く保つことができます。そう、システム開発というのは雑多で複雑なことを扱う、クリエイティブな作業であり、本質的にこのセル生産方式のようなやり方が向いているのです。

またこれを実現するためにはメンバーのスキルを非常に高く保つ必要があります。そのための教育コストは当然高くつくわけですが、結果として、そのコストを軽く補えるほどのリターン、つまりプレミアムが得られるはずです。

NTTデータのこの試みがぜひ成功して欲しいと、強く願ってやみません。