ちょっとSQLを贔屓し過ぎです。
前にも言いましたが、オブジェクト指向によるパフォーマンス向上もあり、適切に使えば生産性もかなり上がりますし、保守性も適切に行えばかなり上がります。
要はRDBMSでSQLを避けるのは愚挙だという事だと思います。
言語にはそれぞれ得意分野があって、RDBMSを使用するプロジェクトにおいてSQLがそれを得意としているだけです。

インドリさん、ども。

（Javaは基本情報処理だけだったかな？）
Javaの試験問題ぐらいスラッと書けないとプロなら困るでしょ。

最低レベルのユーザ向け試験を下回っても、プロっておかしいでしょう。
数ある技術の中で、SQLだけがそういう状態になっている。

で、Javaなどの言語は、Javaなど書けない人が上流でも、下流は勝手に伸びます。上流は知らなくても大丈夫です。事実、Javaの問題を下回るスキルだったら、数ヶ月で淘汰されますよ。

しかし、SQLは上からつぶしている。

つぶしているから、つぶさなかったと仮定した未来が見えている人はいないのです。

SQLでできる部分はSQLでやった方が速い。

工数は効率的でないことはしばしば起きるし、できないこともある。
この2つは、上流で判断すべきことです。

mayoです。
またまたまたまた、お邪魔します。

SQLとオブジェクト指向言語（Java)は、
優越をつけるのは無理じゃないでしょうか？

SQLだけでシステムはできませんし、オブジェクト指向言語だけでも
システムはできません。

両者をうまく使ってシステムは開発するもんだと思います。

生島さんの得意分野で例えるなら、VBのコードは一切かけなくても
SQLさえ完璧であればVBのコードをかけなくても、よいシステム設計はできる
と言っておられるようなものだと思います。

mayoさん、どうも。

VBをやったことなくても、VBの上流の設計はできますけれど、SQLが分かってなかったら上流で間違ってしまうとは言ってます。
業務分析するのに、VBだろがJavaだろうが全く関係ないです。
もっとも、COOBOLしかやってない人は画面設計あたりから怪しくなりますけどね。

とにかく、決め打ちはよくない。
しかし、上流でSQLを分かってなかったら、「自動的にSQLを使わない方針が採られてしまう」選択肢にないことは大問題で、上流が分かってないということは採りようがない。
つまり、プロジェクトとして最初から選択肢からはずしてしまっています。

初級シスアドの問題を見て分かったことは、SQLは素人向けというのは間違いないし、スキルアップのためにハケンの女性などががんばって勉強していたしね。

上流でできなくてもいいというのは、がんばって勉強されたエンドユーザより技術力が落ちるということで、ちゃんと会話できてない可能性すらあるのです。
それで技術者を名乗ったらまずいでしょ。

コメントをいただいた中に、「エンドユーザ（社内SE）です」と言ってコメントをくれている方がいて、その人たちはやはりSQLはかなり強いです。
コンサルが付くような場合はそこそこの規模の会社で社内SEがいることがほとんどですから、ユーザ以下でコンサルを名乗っている人がたくさんいるわけで……。

せめてユーザは超える技術力がなかったら、プロを名乗る資格はないんじゃないかな。

あまり続ける気はなかったのですが、もう一言だけ。

>VBをやったことなくても、VBの上流の設計はできますけれど、SQLが分かってなかったら上流で間違ってしまうとは言ってます。

確かにSQLを知らないで上流をやると間違いますが、VBを知らなくても上流は間違えます。

SQLは処理効率を高めますが、VBの設計次第でも処理効率、特にユーザーさんへの
使い勝手は大幅に変わります。

COBOLer出身の方が書かれる設計書はGUIではなくCUIです。
その設計書を元に作成されたVBが使いやすいとは言えませんし、
生島さんの言われる社内SEの方は、SQLだけでなく、画面の設計についても
よく理解されている人が多いです。

もちろんの事ながらSQLは大事な技術ですが、それだけで上流がうまく
いくとは思えません。

> COBOLer出身の方が書かれる設計書はGUIではなくCUIです。

先ほども書きましたけれど、COBOLしかやってない方は、画面設計あたりから怪しくなりますね。
その前段階では大差ないです。

まぁ、蹴り入れたくなることがないかというと、あるけど、COBOL出身であっても、今に至ってはGUIの画面を普通に生活の中で使ってますから、昔ほどはひどくなくなっています。

私は意外と我が強いほうなので（笑）、GUI程度の問題なら最下流にいてもユーザ抱き込んで裏工作で仕様変更させてしまうからね。

ユーザも使い込まないと使い勝手なんて分からないし、個人的にはGUIなんて「コロコロ変わるもの」と思っています。顧客も、上流も、誰しも完璧じゃないし、ボトムアップで直せるところは直してあげたらいいんじゃないの？

結局、上流、下流という分け方が悪いのであって、外部（GUI側）内部（DB側）って分ければ設計におけるインピーダンスミスマッチもなくなると思うけれど。

>結局、上流、下流という分け方が悪いのであって、外部（GUI側）内部（DB側）って分ければ設計におけるインピーダンスミスマッチもなくなると思うけれど。

これは激しく同感です。
これを伝えたかっただけですけどね^ ^

本論とは違う部分で横から失礼いたします。
初級シスアドへのリンクはwikipediaよりは、ipaの方がよいのではないでしょうか？
（URL欄に記入しました。）
それによれば、対象者像は、「利用者側において、情報技術に関する一定の知識・技能をもち、部門内又はグループ内の情報化を利用者の立場から推進する者」と書かれています。
「利用者”側”」という部分と「”利用”ではなく、”推進”するもの」という部分で、「一般の利用者」とは少し違うのではないかと思います。「プロじゃないのよ」と言われてしまうのはちょっとかわいそうかなと思ったので書かせていただきました。
自分は、感情的には「初級シスアドなんて全然よ…」と、やはり思っているために取得していませんが、利用者のテストと思われるより、利用者から一歩踏み出すためのテストであると思わるほうがいいんじゃないかなと感じました。
（中の人じゃないので勘違いだったらすみません。）

石神さん、どうも。

ありがとうございます。
SQLの教育を調べてたら、結構、初級シスアドに対する言及があったので分かりました。
ググッたらWikiの方が先に出てきたもので。
終わった試験だったのでないのかと（終わったことすらWikiで知ったけど）改めて調べてませんでした。IPAに過去問があったかもしれません。問題もそっちのリンクの方がよかったかもね。

社内SEはプロかプロでないかというと微妙ではあるけれど（プロでは絶対に無理な人も、元プロとか玄人はだしもたくさんいる）少なくともSIerの顧客であるのです。その顧客と話するのは、下流ではなく上流の技術者ですから、最低限、顧客の技術レベルは超えてないと話にならないでしょう。トンデモないことを口走ってしまいます。

業界として「コンサル様と話するにはこれぐらい（初級シスアド）勉強しやがれ！」って傲慢なことを言ってるってことなのですよ。その範囲は上流（コンサル）は最低限理解しとかないとね。

初級シスアドで、プログラム言語を必須にせずにSQLは毎年そこそこの難易度の問題を出しているところは「IPAも割と分かっているのね」ってイメージが変わりました。

なにぶんオヤジなので二種～特種ぐらいのイメージが強くて。IPAの皆さんすみませんでした。

saki1208です。

SIerにもトンデモSEがたくさんいますが、情シスなどの社内SEにも多いですよね。
# やれば出来ることとやるべきことの区別がつかない人とか...
# 今から構築しようとしているシステムのことが理解できていない人とか...
# 説き伏せるのに苦労するんですよね。いつも。

なまじ、元Sierとかだと知識だけが先走ってて、予算とか気にせずに夢みたいな
ことばかり語る傾向にあるような気がします。
# 結果、「高い」となる訳ですが...

こう言うと誤解を招きそうですが、私は、上流でも言語知識は必要だと思います。
そこに拘る必要はありませんし、逆に拘るとろくなことにならないでしょうけど...

saki1208さん、どうも。

まぁ、正直に言って個人的には「上流、下流」という分け方に無理があると思っていますので、「上流、下流と分けるなら……」と、私の考えとは矛盾したことを書いています。

私の考える外部、内部と分けるなら、外部の人は言語、内部の人はSQL、それぞれに、それぞれに合った業務知識、って話になるのです。

こうするには、今とは切り口の違う分業になって、今の人月ビジネスは難しくなる。

結局、「業界を変えたい」じゃあどうすればいいかを突き詰めたら……

　　　　上流がSQLをできるようになれば、内部、外部と切りたくなる。
　　　　内部、外部と切ると人月ビジネスやオフショアをやりにくくなる。

つまり、「上流がSQLを高いレベルで……」

10年やってるので毎度同じことを角度を変えて書いてます。
（ほとんど毎度同じオチです）

愚痴ですけどね……。すみません。

> SIerにもトンデモSEがたくさんいますが、情シスなどの社内SEにも多いですよね。
> # やれば出来ることとやるべきことの区別がつかない人とか...
> # 今から構築しようとしているシステムのことが理解できていない人とか...
> # 説き伏せるのに苦労するんですよね。いつも。

そうですね。社内SEってスキルチェンジのチャンスが少ないから、ガチガチのCOBOLerも多い。経営層には何やっているかわからないのである種の聖域になっていて、会社の金でずーとスキルアップの勉強している人もいたり……。

聖域になっている情シスは天国です。

やればできることとやるべきことの区別ではなくって、
自分がやりたいことと、やらねばならないことの区別がついてない人が多いな。

彼らも成功ラインを自分で決めれるから、ずっこいですわ。

上流がまとめた要件定義・基本設計を見ると、明らかに情シスまででエンドユーザの声が入ってないときがある。
しかし、こういう不満が出るということは、SIerは明らかに情シスにそこそこのレベルを求めているわけで、それならばSIerもそれ以上のスキルを求められて当然ということで……。
（昨日は酔ってたので追加）

こんにちは、ちょっと疑問がわいてきたのですが・・・

>結局、上流、下流という分け方が悪いのであって、外部（GUI側）内部（DB側）って分ければ設計におけるインピーダンスミスマッチもなくなると思うけれど。

ちょくちょく出てくる、この上下・内外の対比ですが、本当に対比していますか？

同じになってません？

上：上流層（といわれるところの）の技術者および、その人たちがやる仕事
下：コード開発層（といわれるところの）の技術者および、その人たちがやる仕事

外：おおよそ上でやってた仕事内容らしぃ（外部設計的な・・）
内：おおよそ下でやってた仕事内容らしぃ(内部設計的な・・）
もしかすると、この内外にコード実装も入るのかな？として、何が違うのだろうか・・

例えば、UI要件を設計して、必要なサービスを呼ぶような事になったとして、
サービスは未だ作成できていないので、ダミーです・・・って現状となんも変わらん気が・・

上：下、内：外の違いって具体的になんなんでしょ？
かなり前の記事の時は「フンフン」なんて思ってたのですが、真面目に考え始めたら、現状と何も違わない気がしてきたのですが・・

oumiさん、どうも。

　　外部設計≒基本設計
　　内部設計≒詳細設計

と呼ぶところもあるから、ややこしいですね。

> 外：おおよそ上でやってた仕事内容らしぃ（外部設計的な・・）
> 内：おおよそ下でやってた仕事内容らしぃ(内部設計的な・・）

外部設計というのはエンドユーザに見える範囲の設計。つまりUI。
内部設計というのはエンドユーザに見えない内部の設計。つまりDB。

現状の

　　要件定義 ⇒ 基本設計 ⇒ 詳細設計 ⇒ 実装 ⇒ テスト

を

　　要件定義 ⇒ 外部設計 ⇒ 実装 ⇒ 内部設計 ⇒ 実装 ⇒ テスト
　　（要件定義には、外部の上流と内部の上流がそれぞれ参加）

って感じですかね。

ミソは、内部設計（DB構築）の前にUIの実装が入るということ。
こうすれば顧客はイメージしやすいし、納品できるから工事進行基準にも合わせやすい、請求してもいいし。納品しているから仕様変更も言いやすいし、DB設計の失敗も最小限に抑えられる。

こういうやり方すると、要件定義の段階ではPOAとDOAとOOAが混在するけれど、目標は同じで、それぞれの良いとこ取りできると考えています。

問題は、プロジェクトの後半はSQLかストアドプロシージャしかないから、SQLができない人は、DB設計やビジネスロジック設計、実装が後回しになるのことが、とても怖く感じるということです。

私は、現物を見せずに、紙芝居の設計資料で取った合意なんて最後にエンドユーザにひっくり返されると思っているので、その合意で進める方がはるかに怖いけど。
ひっくり返すのは顧客のせいと思っている人が多いのでしょうね。
あと、オフショアが非常に難しいというか無駄という問題もある。

かなり前に書いたことと同じことを言ってます。
http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html

こういう話って面白いのだけど、モデルが決まってないと発散するだけなので、少しだけ。

>要件定義 ⇒ 外部設計 ⇒ 実装 ⇒ 内部設計 ⇒ 実装 ⇒ テスト

やっぱり現状と何が違うのかよくわからない。

ウォータフォール・アジャイルどちらでも、現状、見た目は基本設計（または同等のフェーズ）で行われると思います。
このフェーズでは、実装はデザインに関しては行われるけど、それ以外は行われない。
なぜなら（工事進行基準にシフトするとしても）、この時点でコードの実装を含めると、後々のＥＵ負担が増えるから。
つまり、ＥＵにとってリスクが増える。
見た目だけの検収ならば、大した話ではないけど、バリデーションや内部プロセスを始めとする諸々も検収する必要がでてくる。これって結果的にＥＵのリスクが増えるだけな気がするなぁ。
SIerもですけど、ミスの回収、同意事項の変更、すべからく「お金」の問題になってくるし・・つまり、EU・SIerどっちが持つのかって事。
今までですと、自然の流れで改修できたこともできなくなるかも・・・
程度の問題はあるでしょうけど、難しい気がするなぁ。

そこをあえて
>要件定義 ⇒ 外部設計 ⇒ 実装
で検収とすると（もっと細かいとしても）、ＥＵにどんなメリットがあるのか、今一つ判らないですね。

ぱっと受ける印象では、「良いかも」って思えるんだけど、誰にどんなメリットとデメリットがあるかをもう少し考えてみたいとこですね。
UIとデータアクセス周り（業務処理）の分散開発ってだけなんじゃないかという気もするんだけど、ニュアンスが違うんでしょうね・・

ガッチガチにシステムアーキテクチャや標準化が固まってて、
バッチじゃなくて、
メニュー間の関連性の薄いエントリ系で、（意外とこういう業務おおいと思われる）
などの条件が揃えば可能な気はするんですけど、ただ、ＥＵメリットがピンとこないな・・・

見た目以外の部分がきっちり（最初に）出来ているってことが、どんなメリットを生むのか？ってことですね。
ダミーデータや紙芝居的な物になっちゃうと、そこにどのような価値があるかって？ってなりますし。

末の請負の場合、資金の回収スパンが短くなるので、メリットは出るのでしょう確実に。
SIerは、面倒事が増えるだけで、あまりよろしくないのではないかなぁ・・
二次三次あたりは、うーん、負担が増える気がするな・・
人の単価が適切になるという効果があるかもしれない予感はする。逆に買いたたかれる場面もあるんだろうか(W)

EUとSIer、ともに成長していけるといんでしょうけどねー。

文中の「メリット」は全般的に「価値」という意味で使ってます。

oumiさん、どうも。

顧客にリスクを押し付けたいというわけではないのですけれど、やはりイメージできてないため、後々発生する齟齬というのは非常に多いわけで、お互いにメリットはあると思います。

個人的に、億を超える案件のほとんどがもう少し全うなDB構造だったらな～。
というのが多いのですが、ユーザも何がほしいか本当のところ分かってない状態での書面でのOKはあてにならない。
詳細設計を書くために「DB設計（テーブル設計）がなかったらできない」と言われて、無理無理作る。
今、世の中で作られている詳細設計を作るには、確かにテーブル設計がないと書けません。

で、中途半端な情報で作られた基本設計を元に（テーブル設計は基本設計に含んでいることが多いし）作られたテーブル設計ですから、詳細設計をしているうちに不備が見つかってテーブル設計の変更が発生する。

他の機能へ波及 ⇒ 更にテーブル変更 ⇒ デスマーチの完成

一番、多いパターンだと思います。
UIの変更って大きく見えても、テーブル変更がなければ大したことはないですから、DB構造を確定する前にUIをきっちり作るというのが効果が高いと考えています。

UIをきちっと作るというのは、顧客のニーズをしっかり掘り起こすということで、UIを担当する上流も顧客としっかり話せないといけないし、DBを担当する上流も顧客としっかり話せないといけません。

どちらも、違うスキルで両方できる人はそんなに多くないですから、そこを分業した方がよい物ができるはずです。
特にCOBOLerは内部の方に向いていて……。

毎度、同じことを言ってますが（笑）

saki1208です。

生島さん、フォローありがとうございます。
>自分がやりたいことと、やらねばならないことの区別がついてない人が多いな。
こっちですね。orz

なんかしっくりこないなと思ったんですが...

Java（他）の習得難易度が★★★★★というのには違和感があります。オブジェクト指向言語を血肉にするには楽じゃないと思います。

オブジェクト指向の話もSQL同様で、上流の方がよく分かっていないと大変なことになると思います。

もっとも、さらに上の上流（ビジネスコンサル）レベルでは不要かもしれませんが･･･。

木村祥久さん、どうも。

> Java（他）の習得難易度が★★★★★というのには違和感があります。

どうでしょうね。
C言語との比較ですからそんなものじゃないですかね。

> オブジェクト指向の話もSQL同様で、上流の方がよく分かっていないと大変なことに
> なると思います。

上流が知ってるに越したことはないですけれど。
SQLよりはましですね。

SQL如きをそんなに擁護されてもねぇ。。
PL/SQLとか、なんでもかんでもSQL使えばいいってもんじゃないと思う。

大体 JavaはCより簡単だし。SQLのHaving句を知ってます。だから何？
って感じですね。

第四世代言語や最近の開発ツールでは、そんなのパターン化されていて製品でボタン押すだけだし。どうでもいい話だと思う。

Drag&Dropで開発ができる時代にそんな共通的な知識を問うても無意味、
プロはお金につながる製品や専門の技術に精通していないと現場では
役に立たないと思う。

DBで食ってる人ならHaving句くらいは知ってて当然だが、
別にDBが専門じゃない人だってたくさんいるから別に知らなきゃいけないってこともない。

初級シスアドでも上級シスアドでもなんでもいいけど、所詮現場を知らない
○産省のオナ○ーでしかない試験に興味はありませんね。。

資格・試験マニアの人くらいしか受けないでしょ。

通りすがりさん。

できない人（くれぐれも技術者じゃない）ほど同じことを言うね。

上流は選択肢は持っていてもHAVINGがどうだとかそういうトコはどうでも
いいと思います。
知っているに越したことはありませんが、選択肢を潰さない限り、検討対象
になりますから。
検討対象になりさえすれば、調べまくればいい。聞きまくればいい。
実際それは、SQLに限った話ではないですよね。

SQLを知らないからと言って恥ではないと思います。
それはこの業界に関わる全ての知識を有してないと恥って言ってるようなもんですからね。

> どこにウェートを掛けるかによって、何をトレードオフするかを決めて
まったくその通りかと。
だからSQLが出来ない人ではなく、一辺倒な選択肢しかない人の方が問題だと思います。

SQLのスキルが業界的に上がっても、他が落ちたら結局は拙いものが出来上がると
思いますよ。
そもそも役割が違いますしね。

Takさん、どうも。

知らなければ、頭の中にはループする前提が出来上がり、言語の詳しい人を探し出します。スタート地点から明後日の方向を見ているわけです。

ですから、知らないことは恥です。
検討対象になったかどうか判断できてないから、選択肢としてもないわけです。

できなくてもプロジェクトは終わってきたと思うかもしれません。
しかし、できる人から見たら耐え難いほど稚拙な構造で、馬鹿のように工数を掛けて終わったことにしているに過ぎません。