■    再び「ぐだぐだ言ってないでプロセスを書けよ、ハゲ」

前回にコードを書かないという話をしました。そして、シリーズの第1章でウェブ系のハッカーたちの間で「肝に命じる」言葉として、「Shut the fuck up and write some code.」というのがあって、その意味する「ぐだぐだ言ってないでコードを書けよ」のコードをプロセスに置き換えて「ぐだぐだ言ってないでプロセスを書けよ」という話を書いた。つまり、プロセスを中心にして業務を見ていこうということなのだから、とやかく言う前にプロセスを書こうぜということである。

このコードの代わりにプロセスとしたというのが前回の議論のポイントなのである。Webサービスとビジネスサービスではサービス粒度が違っていることに注意してください。単一的なものに対して複合的であるとでも言いましょうか、アクティビティレベルなのかプロセスレベルのなのかという言い方になる。つまり、Webサービスはアクティビティレベルが多く、ビジネスサービスはアクティビティの連なりであるプロセスから成り立っている。

ですから、Webサービスでコードを書くというのが、ビジネスサービスでプロセスを書くことに対応するということになる。コードを書くことでアクティビティを生成するのに対し、アクティビティを組み合わせフロー化することでプロセスを生成するということである。例え話でいうと、自動車や家電製品を作るのがWebサービスで、それらを使ったライフスタイルがビジネスサービスと考えてみてください。田舎に住んでいたら自動車は必須ですが、都会では電車を利用するから必要ないといったことになるわけです。

もうおわかりだと思いますが、田舎に住んでいるから田舎暮らしに適した自動車を設計して作りますか。部屋の空いているスペースにぴったり収まるテレビを作りますか。スタイルをデザインして、それに沿って活動するということは、システム製品を作ることが目的ではありませんよね。いかに快適にとか、節約できるとかいったことが目的になります。

さて、「ぐだぐだ言ってないでコードを書けよ」というのは何しろ動くものを作れよということであるから、プロセスを書いたら直ぐに動かさなくてはいけない。逆に言うと、イメージしたビジネスサービスが直ぐに動くようにするためにはどうしたらよいかである。それがシステム開発(システム構築と言ったほうがよいというのは前回書きましたが)となるはずである。設計フェーズで実際にオペレーションするイメージが持てるようにプロセス要素を定義したのはこの流れを意識しているわけです。

従来のように要件定義書やプログラム仕様書ではオペレーションのイメージをわかすことができるでしょうか。コードを書くということはアクティビティレベルのサービスのイメージはわきますが、プロセスレベルのものは難しいでしょう。ですから、設計ではできるだけ業務視野で記述して、そのまま実装できるのが望ましいのです。

設計から直ぐに動かそうとしたらコードを書いてなんていられないので前回に提起したようにコードはやむを得ない場合のみにして極力書かない旨を徹底することだと思います。ということは、自動車や家電に相当するような既成のものとしてあるコンポーネントを利用することです。要求ユーザの前でレゴ細工のように組み上げて見せるようなやり方が必要になるのです。
 

No TrackBacks

TrackBack URL: http://blog.wadit.jp/mt/mt-tb.cgi/85

Leave a comment