2008年5月24日土曜日

なんとなく デザインポリシー

仕事の話。
個人的にシステムデザイン時に心がけていることがらはこんな感じ。

1.業務アプリはシンプルになるはずである

「人は複雑な業務をできない
 だから、システムで複雑に表現されるような業務を人はやっていない」

という前提でシステムをデザインする。システムのロジックが複雑になりかかった時、まず自分のシステムデザインを疑って掛かる。思い返す限り、この疑いは正しい。
なので複雑な仕様書は書かないように努める。直感で理解できない仕様書は、情報を整理・分析し切れていない証拠ともいえる。


2.論理モデルを叩く

論理データモデルを叩いて、破綻のない仕組みを考える。とはいっても、要求は尽きないのでそういったところでいつか必ず破綻し始めるんだろうけど、その日ができるだけ遠くになるように多くを想定し叩ききっておく。


3.フラグやコードは使わない

フラグやコード値は、システム化限界の境界線に至った時にのみ登場させる。そこは已む無くハードコーディングとなる。


4.プライマリキーにUID以外の意味を持たせない

テーブルのプライマリキーに意味のあるキーは持たせないようにしている。切り口はいくらでもあり、その一つをプライマリキーにした瞬間、システムが傾き始める。


5.法則を見抜きエンジンを作る

作曲も同じ。
好きな曲には必ず法則がある。パッとは分からないかもしれない。けど、少なくとも曲の好き嫌いがあるのなら、それらを識別する何らかの法則があるはずである。考えていくとなんとなく好きな曲の仕組みが見えてくる。それを、自分のエッセンスを加えつつ抽象化したものがこのマイソウルを生み出すエンジンとなる。そのエンジンに自分の"俺のこの思い"というパラメータを与える。するとポコッと曲が生まれる。
むろん音楽に限らない。料理とか水墨画とかも同じだし、アウトプットが物体ではない、スポーツや、この"人生"でも同じ。

ユーザはルールをシステム化要求としてあげていると思うんだけど、似て非なる要求は、実は非なるようで同じ要求、ということが多い。1.の「人は複雑な業務をできない」と言ったように、人はそこまで賢くないので多くのルールがあるとそれを守ることができない。
少なくとも俺は守れていない。勤務表を出さないのでいつも怒られる。それに交通費の清算もしないので、新幹線代とか、出張手当とか、タクシー代とか大いに損してる。忘れている間はいいんだけど、思い返すと、「ああ、あの金でうまいもんが食えたよな~」とか考え出してしまい。もとい。
ゆえ、分析すると、ごく一部を除き、まったく同じ仕組みの上に実現することができることが大半だ。
その仕組みがエンジンで、"ごく一部"は、振る舞いを決定するパラメータである。


6.仕様書からシステムはジェネレートできるはずである

仕様書は定義の集まりだが、大きく二つの意味があると考える。一つは、エンジンの定義。それからもう一つが、パラメータの定義。
エンジンとパラメータを掛け合わせて、コードをジェネレート(自動生成)するか、
エンジンを手で作って、パラメータをジェネレートするか。
どっちにしても仕様書からある程度はジェネレートできるはずである。
ジェネレートできない仕様書は、情報の質としては"あと一歩"である。

それから、開発を完全にアウトソースするなら、仕様書は"あと一歩"ではよくないはずである。よく、オフショア開発がうまくゆかないという話を聞くけれど、うまくゆく例があればその仕様書の精度がどれくらいなのか見てみたい。仮にその仕様書が"あと一歩"ではない、つまり、システム化の情報がそこにすべて盛り込まれているレベルのものだとしたら、オフショアするまでもなくシステムをジェネレートできてしまう。もしジェネレートできないとしたら、ベトナム人にもタイ人にもインド人にも期待したジェネレートはしてもらえない。仕様の曖昧さは、文化、という感じ方の違いにより、ブレを生む。文化は家庭ごと、個人ごとにも異なる。
日本人の間でも「よきにはからって」はなかなか通じないのだから。


7.ゴールまでの工程は極限までそぎ落とす

そんな感じで、ジェネレートなどを駆使して、要求がそのままシステムになるように努める。
ゴールまでの工程が多いほど要求はゆがみ、品質が落ちる。こここそが情報処理業で働く僕らの知恵の見せ所だと理解している。

ほんと、ここが知恵の見せ所。


8.業務はシンプルになるはずである

業務で受け渡しされている情報を分析すると、大半、業務がもっとシンプルになることに気づく。
それを見越してシンプルになるはずである、もっとコストは掛けずに済むはずである、という大前提から業務を分析、改善していくのがコンサルタントなんだと思う。1.で言ったことと表裏一体というか。


9.システムはユーザの時間を創り出す道具である

システムはツールの一つである。
ツールとは、道具である。
トースターや洗濯機や冷蔵庫、コンロ、パソコン、、、などなど全部道具である。
道具は便利で僕らの時間を創造してくれる。

その昔、人はガスコンロにも驚き、感動したはずだ。
「スイッチ一つで火がつくのか!火力の強弱も自在なのか!!!」
と。今となっちゃ当たり前の事象として、僕らの生活の一部を担ってくれている。

できれば、そういうものでありたい。
僅かな驚きと感動と、存在を忘れさせるほどのさりげなさと。
そういうのを、社会に生きる一員として提供できたらって思う。


ざっと。

0 件のコメント: