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のアクターの形をした主人公が活躍するユースケース記述が書いてあります。

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

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

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

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