井上 研一 @ITにあるジーワンシステムの生島氏のブログにあった記事で、
ベンチャー社長で技術者で: 上流の技術者はSQLを高いレベルで習得すべき: 顧客に言われたものを、そのとおり整理するレベルが上流技術者じゃないでしょう。工数、レスポンスの問題ではなく、顧客が思っている以上の提案ができるかどうかが上流技術者として職務の根幹にかかわる問題じゃないですかね？
この部分と、
コンサルや上流SEにとって重要なのはSQLができるかどうかではありません。SQLを選ぶかループを選ぶかの判断、つまりSQLでできると判断するかどうかです。「何でもできます」という御用聞きタイプでなければ、コンサルは演習問題ぐらい見た瞬間（聞いた瞬間）に判断しています。
この部分に深く頷くものがあったので、上流技術者の仕事について書いてみようと思います。
まず、「顧客が思っている以上の提案ができるかどうかが上流技術者として職務の根幹」というのは、そのとおりだと思います。いや、上流技術者とか技術者という縛りとは無関係に、顧客が思うちょっと上の仕事をしようと思うことが、自分のモチベーションにつながり、顧客からの信頼にもつながるのです。それを技術者の世界に特化していえば、たしかにユーザという意味での顧客に直接アクセスするのは上流と呼ばれる技術者であるので、「上流技術者としての職務の根幹」になるわけですが。
顧客が何をしたいか、ということを、顧客がただ口に出して言っていることから深読みすることはなかなか難しいのです。顧客が言っていることをそのまま実現すれば、とりあえず顧客は満足するし、技術者も仕事をした気になります。しかし、それはたいていの場合、場当たりでの対応になるのであって、根本的な問題はちっとも解決されていないことが多いのです。数日後、数週間後に似たような、でもちょっと違う依頼を顧客が口に出すようになります。
最初の顧客の依頼から、その深層を理解し、顧客の当初の期待を上回る回答を出すことが出来れば、問題は根本的な解決につながっていきます。このレベルの仕事が出来るか否かで、顧客にしても技術者自身にしても、本当の満足感を得られるかが決まります。
「コンサルや上流SEにとって重要なのは・・・SQLを選ぶかループを選ぶかの判断」というのは、この記事が上流技術者にとってのSQLの重要性について説いたものなので、殊更SQLが登場してくるわけですが。
業務系のシステムを作っている技術者にとって、SQLの重要性というのは、非常に高いのです。オブジェクト指向での開発が進めば進むほど、SQLの重要性は低下するものと思っているのですが、なかなかそういう現実は訪れていません。
SQLとループのどちらを選ぶかというのは、つまりは簡単なプログラムというか、スクリプトやViewのレベルで解決出来るか、大がかりなプログラムを組まなければならないかということなのだと思いますが、それは開発工数＝費用に直結します。現場では、SQLレベルなら設計者自らが書いて、プログラムになるなら設計書を書いてプログラマに渡すといったシーンが多いのではないかと思うのですが、出来るだけ顧客と直接話をしている設計者（上流技術者）が（このシーンではSQLでの）実装まで落とし込んだ方が、出来上がったモノの完成度は高いのです。プログラマに渡すことになれば、コミュニケーションギャップやプログラマの業務理解度の低さによる出来上がるモノのレベルの低下は免れません。
（SQLかループかの選択肢でSQLを選んだとすれば、そのSQLは上流技術者自らが書くべきです。プログラマに渡すのなら、SQLよりプログラムの方が完成度が高くなるような気がします。）
私のことを言えば、最近2年ほど、ずっと上流技術者というか実際の設計をずっとやっています。ユーザ企業のSEや実際のユーザと話をして、基本設計や詳細設計して、プログラマに渡すのが仕事ですが、ひたすらSQLを書いている時期がありました。（このプロジェクトは画面で使うViewを設計者が書くという決まりなのです。他にも、ちょっとしたデータ抽出の依頼で200行くらいのSQLを書くことになるとか･･･。）
それで、自分のSQLの能力はかなり高まったと思っているのですが、SQLで出来ることというのはなかなか幅広く、かつ低コストだということを悟りました。自分自身で書くのだから、安心感もあるし。（もともとはオブジェクト指向推進派なので、長いSQLは毛嫌いしてたんですけどね。）