業務知識が必要なのは、誰？

ブクマも盛り上がっておりますが、フレームワークな人からすればこういっとかなきゃいかんのかなあと思ったりします。

SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。

深い業務知識が必要なのは案件の提案者と要件定義者 - yvsu pron. yas

ここまではなんとなくわかるのですが…

要件定義が終わると次は、外部設計をおこないます。外部設計の呼び方は、各社によって違うと思いますが、要件定義を顧客が理解できるレベルで具体化することです。この外部設計のメンバは、深い業務知識を持っていなくても大丈夫だと思います。基礎的なことをおさえておけば、後は、要件定義をしたメンバからレクチャーを受けながら設計を進めていくことができます。
つまり、深い業務知識が必要なのは、案件の提案者と要件定義者だけで、残りのメンバは、後から勉強して基礎を身に着ければ間に合うのです。

深い業務知識が必要なのは案件の提案者と要件定義者 - yvsu pron. yas

はっきりいってしまうと、実装するに当たって必要なのが「基礎」ではないから、ここでの話がおかしくなっていると思うのですよね。例えば、銀行業務であれば、預金とは何か、融資とはなにか、どうやって収益を上げて、どういう手順で業務が遂行されるのか、というのが基礎なんじゃないかと思うのですが、これは全体のデザインをするときにこそ必要です。そして、実装に落とし込む段階で必要なのは、利息計算であればもっと数理的なものですし、それは「仕様」であると同時に「業務知識」なのですよね。つまり、かなりコアな業務知識が実装の際に必要です。もちろん、これは要件としてきちっと決まっていればそのまま実装できるはずだ、という考え方もあると思います。ロジック単体レベルまでに要件が落としこめていればそれでもよいのでしょうけれども…
業務知識とひとことでいってもいろんなレイヤーのものがあります。ひがさんが言っているいわゆる業務知識は、多分業務とはなんぞやのところの話だと思いますし、一方で、業務知識といわれるもんが手順レベルだったりロジックレベルだったりもします。デリバティブなんて要件とロジックが一体のようなものですが、それをさらにシステムとして成立する形にくみ上げる際にはやはり「基礎」ではなく、「コア」な業務知識が必要でしょう。
僕は、上流工程で必要な業務知識は「広く深く」、実装の際に必要なのは「狭く、さらに深く」の人と「広く、全体の業務
事務フロー)を意識して」の２パターンがそれぞれ必要だと思っています。

「要件をどうやって実装に落とし込むかというスキル」なしで、外部設計をするから、実装できない設計になってしまうのです。

深い業務知識が必要なのは案件の提案者と要件定義者 - yvsu pron. yas

これは同意なんだけど、結局のところ、ユーザー部門がもつ業務知識はその業務そのものの知識である一方で、SIerに求められている業務知識ってのはそれをシステムに落とし込むやり方込みですよね。
我々SIerがお客さんに「業務知識」を要求された場合はまず間違いなく「その業務のシステムに携わった/設計した」経験なんですよ。その辺がずれたままいるいらないって言っていても仕方がないかな。
ブクマでかなり叩かれ気味だけど、それほどでもないような…
http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/higayasuo/20080620/1213929736