業務システムエンジニアは如何にして業務を身につけるべきか

データベーススペシャリストの午後の問題を見ていると、わりと業務システムなんて簡単にできる気がしてくるんだけど、実際に問題にぶち当たるのは、日本のシステムには厄介なオーダーメイド部分が沢山あって、一般論が通用しないことが多いせいかなあ。
よく問題になる在庫管理システムにしたって原理は簡単なんだけど、実際にはあの取引先には専用の帳票があってとか、この得意先は1営業日すべてのプロセスが早いとか、そういう仕様がたくさんあったりするんですよね。
それをもって「顧客の業務」と言ってしまえばその通りなんだけど、それって本当に必要なんだろうか。
こういう顧客に張り付いているエンジニアは、一般論を知らないことがよくあるんですよね。ここではこうやっている、というのは大事なんだけど、それが、普通はこうやるんだけど、ここではこういう理由があってこうしている、という理解にならないと、よそにいった時に何もわからなくなる。往々にしてある業務のスペシャリストとみなされていた人が蓋を開けて見たら使い物にならないのはそんなところに理由があります。
では、何をすれば良いのか。それは一般論を身につける、に尽きます。当たり前ですね。
現場から学べることなんてすべてそこ固有の特殊なものだって思っておいた方が良いです。もちろん、そこで得たものは一般論を理解するために必要なものがたくさんあって、無駄にはなりません。むしろ、プロセスが特殊であっても業務の目的自体は変わりませんから、理解は早くなるはず。
そして、一般論を身につけることで新しい別の現場だけではなく、今の現場にも応用が利くかもしれません。
例えば、得意先だけ早くするってのは実は全体が早くできるんじゃないか。対応が大変だから取引先には提案してなかったけど実はそんなことないのでは、とか。システム更改のときにプロセスを改善するチャンスですが、個社の事情にこだわっていることでその機会を逸しかねません。
僕はずっと金融やってますけど、金融業務は多岐に渡っていて難しい。でも、大まかな業務の概要は金融業務検定で勘所を押さえてみたり、外為みたいなものは入門書を読んだりとかする事で誰が何をどのようにする必要があるのかは大体理解しています。もっとも、現場で業務知識と言われているのは「Aファイルが第何営業日の何時に送られてきてそれとなんとかマスタを突合して出来たファイルを何営までにBシステムに送る」みたいなの。それって基本設計／詳細設計ですよと。でも業務プロセスだから、といわれるとはいそうですね。
これを業務知識だってほんとうに思っている人はシステムの改善に伴う業務の改善なんて絶対にできないし、多分新しい設計書を書けって言われてもろくなものが書けない。それは業務ではなく手続きなんですよと。手段であって目的そのものではないんですよと。
そこを勘違いしている人が「俺は業務を知っている」って威張っているのがレガシーなSIの現場で、そこから脱却できないシステムは10年以内に大変な目に合うことでしょう。
おっといけない、エンジニアの話でした。
つまり、業務を本当に知っているエンジニアってのはシステムと業務をイコールとはみません。システムの都合でプロセスができているところは必ずしも真の業務要件を体現していません。
リソースの制約がなければこのシステムはどう改良すべきか、という問いに常に答えられるだけの知識とデザインセンスを持っていること。それが業務プログラマーから業務システムエンジニアへの転換点なんではないでしょうか。