Float on the flow

とあるエンジニアのブログ。「ゆったり・しっかり」がモットー。

業務ってなんだ。システムってなんだ。

SIerの世界で言われる「業務」って何だろう。
「SEはお客様の業務を熟知していなくてはならない」とか言われる、あれ。


自分は「業務=仕事の手順」だと思う。
販売管理の手順、経費精算の手順、輸出入の手順、…。


この「業務」の中で、システム化できる部分は、データの記録や照会をするところ。
どういうデータを記録するか。そして、そのデータをどのようにDBに記録するのか、どのように画面に表示するか、DBと画面間の変換はどうするか、データのチェックはどうするか、…。


ちょっと考えると、これってルールの話だということに気づく。
記録・照会したいデータがあって、それをどういうルールで処理するか。


そのルールを定義すること=基本設計。
で、そのルールを手続き的な言語に落とし込むのが詳細設計と製造。*1


今はこのルールを手続き型言語で書いているので効率が悪い。
処理フェーズを適切に分けて、各フェーズをルールベースで記述すると生産性は高くなる。
それこそ「コンサルタントがガリガリと設定を書く」という世界になる。製造不要。オフショア不要。短納期。低コスト。

「人間にわかる形」でルール設定を書いて、それを処理エンジンに食わせたら必要な処理をしてくれるという仕掛けがあればよい。


こうなると、テストフェーズの重要性が増す。設定ミスを防ぐにはテストしかないから。
「この設定でほんとうに予定通りの動きをするよね?」という確認が必要。


で、それはお客さん(ユーザ企業内の人)でもできるんじゃないか。むしろお客さんのほうが自社データの扱い方に慣れているから、チェックは確実なんじゃないか。


また、要件をお客さんと共有して、理解して、ルールに落としこめる人の存在が重要になる。今もそうだけど。
逆に、単純に「日本語で書かれたロジックをプログラム言語に翻訳するだけの人」は不要になる。集めてこなくてよくなる。そうしたら、コミュニケーションコストが下がるから生産性はその点でも向上する。


無論、一部に複雑なロジック(ルール設定できるようにあらかじめ作り込まれていない処理)ってのもあるだろうから、そこはプラガブルにしておく。そのロジックは優秀なエンジニアがさくっと書けばいい。難しくても物量は少ないから。これで解決。


なので、DSL、ルールベース、クエリ処理ってあたりは今後ますます重要になってくると思うなぁ。

こんなことを

3ヶ月前くらいまではよく考えてました。
いや、今でもこれはそう思ってるけどね。
でも、今は自分でコードを書けばいいだけなので、プログラム中にSQLを書くだけでだいたい解決できちゃってるんだよね。

上記のような考えって、大量にコードを書いたり、「標準化」の「標準」を低い位置にあわせなきゃいけない場合に役立つんじゃないかな。

*1:論理飛躍すると、だから詳細設計と製造は融合・一体化できる。工夫とスキル次第では。