update it, Inc.社長のブログ

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

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

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

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

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

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

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

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

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

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

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

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

昨日のテーマ「システムを使う人、使われる人」の続きです。

またまた「私の履歴書」ネタですが、セブン＆イレブンでは日本初の本格的POSシステムが1983年に全店導入されるという話が4/18に載っていました。POSとは販売時点情報管理システムのことで、単に商品の売上げだけでなく、いつ、どんな人が、どんなものを、どれだけ買ったのかをデータとしてかき集め、それを販売予測に利用するというシステムで、少なくとも当時としては非常に画期的なシステムだと思います。でもこれって単なるレジ打ちのはずだった仕事に余計な仕事が増えるケースです。まあ実際にはちょっとしたオペレーションが増えるだけだと思うのですが、とはいってもオペレーションする側が面倒だと思ってやっていると、正確なデータは集まらず、うまく機能しなかったのかもしれません。

セブン・イレブンでやったことは、まずシステムを導入したのではなく、「各店舗の経営相談を行うOFC（オペレーション・フィールド・カウンセラー）を通して、オーナーからアルバイトまで単品管理の意識を徹底するように努めた。」とあります。つまり現場の意識改革を最初にやって、その後でシステムを導入したのです。

単品管理の重要性が予めきちんとわかっていて、それを実施したいと現場が考えているのであれば、そのために導入されるシステムは「使われる」ものではなく、「使う」ものになります。自分たちの行う販売予測（仮説と検証プロセス）をやりやすくするための、便利な道具に変身したわけです。

システムに使われる立場の人をなくすためのやり方は１つだけではないと思います。それぞれのシステムによってその方法は様々でしょう。しかしどのやり方にせよ、もともとは「使われる」立場だったはずの人達が主体的に参加できるように業務を改善すること、これこそが普遍的な王道ではないかと私は考えます。

システムを新規に導入しようとする際に忘れてはならない点として、今日は「システムを使う人、使われる人」というテーマで書いてみます。

システムを導入するとみんなが楽になる、というのが理想なのですが、現実にはシステムを入れることによって逆に仕事が増える人がいる場合があります。システムの提案・企画をする際にはシステムを使って楽をする人だけでなく、逆にシステムを入れることによって仕事が増えてしまう、拘束されてしまう人達のことをよく考えて設計しないと、「使われないシステム」になってしまう場合があるという話です。

システムを導入する際には業務全体の効率化という御旗の元、新しい業務フローができるケースが多いと思います。例えば何らかのデータを毎日入力する、みたいなものです。データを入力することを専門とする職の人ならばそれでも問題ないと思うのですが、通常の業務をやっている人に、追加する形でデータ入力を強制するような場合、彼らはシステムに「使われる」立場になります。こういった場合、彼らがちゃんとデータを入力するように、業務的に『強制』したりするわけです。

でもこれって、その「使われる」立場と同じ立場・視点で考えてみればわかりますが、面白くない話ですよね。一生懸命入力するまじめな人もいるとは思いますが、大半はまともに入力しません。最初は業務的に強制させることによってなんとか回っていても、いつの間にかきちんとした、意味のあるデータが入力されていなかった、なんてことがよくあると思います。

正直な話、私も過去にこの手の失敗をした経験があります。そのシステムはリリースはされたものの、あまり有効に活用されませんでした。

これはそもそも、強制させればきちんと回せると考えていることに問題があると思うのです。つまり上記のケースでも、データを入力したいと思わせる仕組みが必要だ、ということです。システムに「使われる」と思っている人がいる限り、うまくいきません。システムに関わるユーザがすべてシステムを「使っている」と感じることができるかどうか、にかかっていると思います。

ではそのためにはどうすべきか、これは後日ということで。

変なタイトルですが、最近IT mediaの記事で、「字幕.in」を1人で作る…を見たときにふと、いまから10年ぐらい前のVisual Basicがでてきたときのことを思いだして、こんなことを考えてみました。

IT用語としてのマッシュアップとは、他から提供されたWebのサービス（API）を利用して、そこにアドオンする形で新しい付加価値を追加する行為です。元のコンテンツの部分についてはある意味で「パクリ」なのですが、コンテンツ提供者側も意図的にAPIを公開しているのであり、また元のWebのサービスにはない付加価値をそこにつけることに大きな意義があります。先の記事の「字幕.in」などは、一人でこんなものつくっちゃったんだ、て感嘆するぐらい、よくできていますよね。

この「他の人の成果物を利用して、そこに付加価値を追加する」というやり方は、コンピュータの世界では過去、コンポーネントという形で扱われることが多かったと思います。そこで思い出したのがタイトルにあるVB (=Visual Basic)です。VBが出た当時注目されたのは、もちろんグラフィカルに簡単に画面を作れたということもあるのですが、もしそれだけなら既にNextのInterface Builderなど、先行しているものもありました。それ以上に、その当時VBXと呼ばれた部品がいろいろ開発されて、日付をかっこよく入力できる部品とが、データベースとのやり取りが簡単にできるようにする部品とか、そういった部品をペタペタと自分のアプリケーションに張り込んで使うことができた、というのが実はVBが当たった大きな要因だったのではないかと私は考えます。この部品(=コンポーネント)とは、他の人（会社）が開発したものであり、この他の人の成果物をうまく利用することで簡単に本格的なアプリケーションと比較して遜色のないアプリケーションを開発できた、というのがVBが伸びだ大きな要因だったのではないか、ということです。

ただしVBのころと比較した場合、現在のマッシュアップと呼ばれているものは、コンポーネントの位置づけが主客逆転しているというか、利用するAPIのほうがむしろ主といえるぐらい、利用される側の存在（関与する度合い）が大きいという点がだいぶ異なっています。実際似たようなサービスを提供していたニワンゴの「にこにこ動画」がYouTube側の都合でサービスが中断したっていう件もありましたが、サービスとしての脆弱性の克服が今後の課題でしょう。逆にいうと提供する側もこのような不安感を払拭するための施策をとらないと、なかなか企業レベルで利用できるサービスとはならないのではないでしょうか？