同じくコラムを書かせてもらっているAhfと申します。
いつも過激な意見、参考にさせてもらったりしながら読ませてもらっています。
ここまでの流れを見ていまして少々気になる点がありましたので書き込みさせてもらいます。

生島さんの言われるスケーラビリティにはパフォーマンスが含まれているように見受けられます。そして反論されている方々のスケーラビリティにはパフォーマンスは含まれていないように思えます。

パフォーマンスを抜きにしてスケーラビリティを求める際には、できるだけ処理を分散というか委譲というか、ネックとならないように構築することによってリソースの増強により性能を拡張することが多いと思います。私はあまりその道に詳しくはないので、間違っているかもしれませんがＤＢサーバーを増強するよりもＡＰサーバーを増強する方が、かなり実施しやすい方法なのかなと思います。DBサーバーの増強を行った際にはデータの整合性維持が難しい気がしています。
それであれば可能な限りDBサーバで処理を行わずに、APサーバにて肩代わりするというのは、レスポンスを抜いたスケーラビリティとしてそれほど間違ってはいないと思います。

そこ以外については私も同じような意見です。考えていない人が問題とか、SIerとしてのプロ意識ですとか。生島さんの記事をきっかけにして色々と考えてくれる人達が増えてくれると嬉しいことですよね。

Ahfさん
はじめまして。

パフォーマンスは入ってないですよ。

APサーバで処理を肩代わりしたとしても、DBサーバの処理は減りません。
パフォーマンスが落ちる分、ピークは低くなりますが、処理が減らなければ意味がないです。

例えば、CPUの問題だけではないのですが、判りやすくCPUでお話しましょう。
APサーバで処理した場合、DBサーバである1つの処理に1%CPUを使用し10秒掛かるとします。
DBサーバで処理した場合、DBサーバで同じ処理が100%CPUを使用し、0.05秒掛かるというようになります。

このとき、APサーバは、DBサーバで処理した場合、処理はかなり減りますがとりあえず1台で1秒間にこなせるセッションは20とします。

つまり、10秒間に処理できる数は、
APサーバで処理した場合、
　　APサーバ5台分、100セッション
DBサーバで処理した場合
　　APサーバ10台分、200セッション
となります。

APサーバで処理した場合、理論上は全員が10秒後に結果を得ます。
DBサーバで処理した場合、運が良い人は一瞬で、運が悪い人は10秒後に結果を得ます。

上の様な状態になりDBサーバの方がスケーラビリティが高くなります。
比率は処理によってまちまちでファクターが多いので、本来、一概には言えないのですけれど、おそらく逆転するシステムはほとんどないです。

ものすごく単純化して説明していますが、単純に肩代わりした処理量と、それとトレードオフして増えた処理量を冷静に考えてみてください。

しかし、多くの技術者は100%になる時間を見てビビってしまいます。
で、おそらく「10秒も掛かる人が出た！」と言います。
APサーバでやってたら、半分の処理しか出来ず全員が10秒掛かるのにね。

もちろん、DBで下手糞に作っちゃったらおしまいで、それは否定しません。

繰り返しますが、ものすごく単純化して話しています。
変な突っ込みも受けますけど、あまりへンなのはご勘弁を。

というわけで、APサーバで処理しても、スケーラビリティは基本的に上がりません。

よろしければ、こちらもご覧ください。（汚い言葉で済みません）
http://www.g1sys.co.jp/column/_sql_2006_3_1_2.html
http://www.g1sys.co.jp/column/_2006_11_10.html

ちなみに、私の周りでもファイルサーバにEXEを置けばAPサーバという奴が居ました（苦笑）10年選手だったんですけど……。

追加です。
同じ100セッションと考えると、DBサーバで処理していればAPサーバの処理も減りますから、

APサーバで処理した場合、
　　APサーバ5台分、100セッション（DBは余裕なし）
DBサーバで処理した場合
　　APサーバ2～3台分、100セッション（DBは余裕あり）

となります。
エコですね。

ふと思ったのですが、クラウドコンピューティングが上流の無知さに拍車をかけないでしょうか？
私は非常に不安です。
生島さんはどう思われますか？

インドリさん、ども。

そうですね。
個人的には、クラウドの向こう側に居るのが上流であり、プロであるべきと思っています。いわゆる上流の人たちは、っんなことはこれっぽっちも思ってないように思います。

しかし、クラウドコンピューティングで組合すだけのIT屋さんは、ユーザに毛が生えただけの存在ですから、センスの良いユーザ（情報システム部）に負けちゃいます。
本当の要望を知っているのはユーザ（情報システム部）で、技術の裏づけをクラウドの向こう側に求めるなら、勝てるわけがないのです。

私はそう思っているからこそ、厳しい言葉で「プロなら！」って言ってるのですけどね。

もちろん、クラウドコンピューティングを否定して売るわけじゃないですよ。
プロは雲の向こう側に行くことを考えるべきで…。
雲を扱う側になろうとする人は、プライドを売り渡すのねと思ってます。

今現在、稼げていることや、今時点の社会的ポジションがアイデンティティの人たちは、この先大変なことになると予想しています。

まぁ、事業的な借金を抱えて、明日死んでもおかしくない私よりは、遙かに楽でしょうから、がんばってねとしか言えないのですけど（笑）

返信有難うございます。生島さんの意見が聞けて嬉しいです。
私も同意見です。
私は統合開発環境に支配される事さえ嫌で、プロはいざとなったらテキストエディタだけでも仕事できなければならないと考えているので、クラウドは余りいい印象はありません。
一言で言うと、雲の上の誰かに任せたくないのです（笑）

生島さんが仰るように

>今現在、稼げていることや、今時点の社会的ポジションがアイデンティティの人たちは、この先大変なことになると予想しています。

となって、偽者が排除され本物のプロが笑える時代になる事を祈っています。
その時までお互い頑張りましょう！

今回もアツいですね。(笑)

私は、後輩たちと会話するとき、「ツールを使う場合は裏でどんなことを
やってるのか、ちゃんと理解しとけ」と言い続けています。
たとえば、SIOBが裏で実行しているSQLが何か? とかですけどね。
それを押さえておかないと、とんでもないことをしでかすぞ! と。

インドリさんの「テキストエディタだけでも...」と同一だと思っていま
す。

ツールがないと仕事ができないなんて「プロ」としてはちょっと恥ずかし
いですから。
(ツール作るくらいじゃないと)

本来は、そんなツールを提案/創造する職業だと思っています。

スケーラビリティに関しては、私の言葉不足でした。
「スケーラビリティに不安」ではなく、正確には「スケーラビリティの確保に不安」、です。
普段、あまり厳密に使い分けていないので、通じていないことに気づきませんでした。
で、

> APサーバで処理した場合、DBサーバである1つの処理に1%CPUを使用し10秒掛かるとします。
> DBサーバで処理した場合、DBサーバで同じ処理が100%CPUを使用し、0.05秒掛かるというようになります。
> APサーバで処理した場合、
> 　　APサーバ5台分、100セッション
> DBサーバで処理した場合
> 　　APサーバ10台分、200セッション

この状況で1000セッションをサポートしたいという要求に応えるのが、スケーラビリティを確保するということです。APとDBに負荷を分散しているのであれば、計算量の移転を進めた上でAPサーバを増やします(scale out)。
DBへの問い合わせを減らすためにキャッシュするのもよくやります。キャッシュの同期はちょっと面倒ですけどね。

DBサーバで処理する場合は、そこがそもそも限界を超えているわけですから、DBサーバのハードウェアをより処理能力の高いものに交換します(scale up)。
scale upの場合、そのとき手に入るハードウェアの性能が上限になるため、実際にはなかなか難しい面があります。また、ハードウェアの価格性能比は大幅に落ちます。ソフト屋的にはこっちの方が楽でいいのですが。

ポイントは計算量の移転ができるかどうか、です。これができるケースではscale outが向きます。実際には移転に伴う通信コスト等の増加があるため、判断基準としてそれだけでは不十分ですが、基本はそういうことです。少し前のエントリで生島さんが挙げていた例は、移転した計算量以上に通信コストが増大したケースです。

> このとき、下の2つは【開発会社の都合】と置きかえられます。これは、最も重要な【顧客の要件】と相反するのではないでしょうか？

顧客の要件には実現に要するコストも含まれますから、教育コストや過去のしがらみを断ち切るためのコストを顧客が負担すればいいんですよ。実際、技術力が高いとされている会社が高い単価を取るのは、この種のコスト(の一部)を顧客が間接的に支払っているからですね。

インドリさん、saki1208 さん、ども。

酔っ払って何を書いたか憶えてなかったのに、割とちゃんとしたコメントになっててびっくり（笑）
いわゆる上流の連中がクラウド（という新しい言葉）で踊るのを見て、普段から怒るというか、笑うというか、呆れるというか…。

今でこそ、マシンが速くなったので、Eclipseも使うけれど、出始めの頃はEditerで書いてたな。

ツールで言えば、クエリビルダがないとJOINが書けないってのも居る。
GUIでSQLを書けば、GROUP BYしたときの抽出は、自動では一旦HAVINGになりますけど、見てなかったり、直せなかったり。

ツールはタイピングを助けてくれているだけって考えれない人は危ないですね。

そういえば、裏の処理を考えたらお腹一杯になってO/Rマッパーは使ったことがないのですけれど、使わずに批判しているのはマズいかな。

tripod さん、ども。

本気で減らす気になったら、減るかもしれません。
でも、スケーラビリティ云々言ってるプロジェクトに入っても、平気でOrder Byやってますから。
もちろん、画面側でもやるけれど（それはUIの要件）
Order Byを禁止しても、DBの処理が減るかというと、ループの中でSQLを呼ばれたらアウト。

ですから、DBサーバの処理を減らすならば
　　WHERE句までのSQL
　　抽出時はインデックスを使用すること（← これが既にムリ）
　　ループの中でSQLを使わない。

って条件で組めるならスケーラビリティは上がります。

それでも、AP側でGRUOP BYの処理をして読み飛ばす量が増えたら、やっぱりDB側を苛めていることになるし、そんな条件で組めるのは、余程小さい簡単なプロジェクトに限られると思いますけれど……。

saki1208さん、ども♪
そうなんですよ。最近の技術者は内部に興味を持たない。
それじゃあ「技術者」と呼べません！
OSの実装までする私としてはその現象が理解できません。
究極的には、お客様の話しを聞いてOSから作れるようになったら真のプロだと私は考えて毎日鍛錬しています。
現在は前世紀のWin95にも勝てませんが、何時の日にかLinuxと競うまでのOSを作りたいです。
アセンブラ→コンパイラ＆デバッガ→OS→ネットワーク＆DBMS→アプリケーション
まで作るのが私の夢です。

スケーラビリティについては、回線を考えなくてはならないのでは？
回線が細い支店と、太い支店がある事が往々にしておこります。
そうした場合、ハードウェア的側面だけではなくて「業務手順」もちゃんと見直さないとなりません。
あと、季節や時間によりトランザクション数が変化する事も考慮しないと・・・
それを考えると、どの位置で分散するのかが大事だと思います。
最近のデータベース処理はインメモリによるキャッシュが増えてきています。
クライアントの性能が上がったので処理負担をクライアントに任せているわけです。
しかし、技術をちゃんと理解していないと、トランザクションのACID特性が保障できません。
APを使うのはいいのですが、その辺まで考慮しているのかと私は問いたいです。
そうしないと・・・
お客様「データがおかしいぞ」
上流「わかりません。最近の技術は複雑ですからねぇ・・・」
となりかねません。
キャッシュはデータの同期問題を解決する必要があります。

連続になって済みません。
そういえば、この業界では「教育＆調査」がプロジェクト計画に含まれて居ませんね・・・
技術の変化は早くて、常に学習をプロジェクト計画に含めないからデスマーチになるのです。
でも技術の変化は早くても「進化」は滅多にないので、教育こそ大事なのに・・・
おそらく上流は社長本人が技術を把握していないのでしょう。
現状は工場の設備投資をしないで無理やり不良製品を売るのと似ております。
この業界での設備投資とは技術者なのにそれを考えない経営者は駄目です。
それにこの業界の経営者は意外とお金の計算が出来ない人が多いです。
ソフトウェアの原価管理も、無形資産管理もしていない・・・
もうこれじゃあ普通は成り立ちません。
まともに商売しているとはいえないと思います。
このままでは他の業界から信用されません。

「上流の技術者はSQLを高いレベルで理解しておく」とは、読む人によってその内容・レベルの設定に差が出そうですが、どの程度のものを言っているのか興味が湧いてきました。

今まで、読ませていただいてきた感じですと、言い方自体は「RDBMSを高度に理解すべし！」ですが、そんなに高いを要求しているのかなぁ？と疑問がわいてきました。
なんていうか、「おまえら、こんな基本的なことくらいベンキョしとけ！」くらいの感じかなぁとか受け取れる部分もあったり・・・

例えば、
RDMS一般、SQL Server 2005、 Oracle 10g あたりでいうとどんな感じになるででしょうか？
自分が、どの程度の位置にいるのかも気になるところです・・・
後輩の指導にも何かヒントがあるかもしれないですし。
ちょっとまとめてもらえると、万人が助かるかもしれないです。
「プロなら自分で考えろや！と言われたら、面目ない（＞＜）」

あと
> APサーバで処理した場合、DBサーバである1つの処理に1%CPUを使用し10秒掛かるとします。
> DBサーバで処理した場合、DBサーバで同じ処理が100%CPUを使用し、0.05秒掛かるというようになります。
この前提は、やりすぎでないですか？（＾＾；特にAPのほう・・

システムのスケーラビリティの話をする上で、DBのスケーラビリティに（処理能力に）着目した話だけですと、また誤解もわんさか生まれそうで怖い・・・

ウォータフォールとアジャイルは・・・・
そもそも適用できるシステム規模が全然違うので、同じ土俵で並べるのはまずいと思っていたり・・・
なぜなら、ウォーターフォール開発の基本設計フェイズが、アジャイルの実装フェイズにヒットするシステム規模っていうものがおのずとあるわけで・・・
また、世の中悲しいことに、一度画面を確定させても、そしてそれに伴う実装が終わっても、システム全体の開発が終わらないうちは、「ごめん、ここちょっとこうして」　orz なくならないねぇなかなか・・・

【外部要件】【内部要件】にわけて考える開発するっていうのは、当然で良いと思います。ただ、これ行き過ぎるとマッピングにいろいろな面で負荷がかかるので、知恵絞るとこですねー。

最後にインドリさんの、この業界では「教育＆調査」がプロジェクト計画に含まれて居ませんね・・ですが、私は逆にこのフェーズが含まれていないプロジェクトは見たことがありません。というかこれやらないと、後腐れありすぎて終われないですハイ(^^;

反論書こうと思ったんですけど、反論になってないな・・・
というか、参加する快感覚えてしまったような・・
見事に釣られてる気がします。（ちょっと自重）

>私は逆にこのフェーズが含まれていないプロジェクトは見たことがありません。というかこれやらないと、後腐れありすぎて終われないですハイ(^^;

ええっ！これは驚きです。
それならばSQLを知らない上流が居るはずが無いと思いますが・・・
技術者の教育と新技術の調査を怠っているプロジェクトが存在しないのならば、RDBMSを使用するプロジェクトでSQLを教育するのは当然ですから、SQLを知らない人なんて存在する筈ありませんよね。

釣られていただいてありがとうございます。

>「上流の技術者はSQLを高いレベルで理解しておく」とは、読む人に
> よってその内容・レベルの設定に差が出そうですが、どの程度の
> ものを言っているのか興味が湧いてきました。

インデックスのつけ方が分かっているとか、その辺りも当然ですけれど。
ファウラーさんのSQLが読む（会話）のスピードで出てくる＋実行計画見てSQL文のチューニングできるぐらいでいいと思います。
上見ればきりないし、下見てもきりがない。

JOINはツール使わないと書けないとか、HAVINGなんて使ったことないという人も多いですが、億のシステムでそんなレベルの人がテーブル設計していますから、大阪が酷いのかと思ったら、東京でも案外いました。

> あと
>> APサーバで処理した場合、DBサーバである1つの処理に1%CPUを使用し10秒掛かるとします。
>> DBサーバで処理した場合、DBサーバで同じ処理が100%CPUを使用し、0.05秒掛かるというようになります。
> この前提は、やりすぎでないですか？（＾＾；特にAPのほう・・

ホントだ。
途中でごっちゃになってしまってますね、100%になる瞬間があるとビビる人がでるので…。
DBの方が10% 0.5秒のつもりで書いていました。
パフォーマンスは20倍ぐらいの差、スケーラビリティは2倍ぐらいの差が私の経験では標準的です。
これは処理によって差があるので何とも言えませんが、ひっくり返ることはほとんどありません。

> ウォータフォールとアジャイルは・・・・
> そもそも適用できるシステム規模が全然違うので、同じ土俵で並べる
> のはまずいと思っていたり・・・

そんなことはないです。
そもそも、ペーパーベースで仕様が作れるのになぜに実装できないの？

> 【外部要件】【内部要件】にわけて考える開発するっていうのは、
> 当然で良いと思います。ただ、これ行き過ぎるとマッピングに
> いろいろな面で負荷がかかるので、知恵絞るとこですねー。

ダミーのストアドで先にインターフェースとしてのマッピングを終えておくわけです。

> 技術者の教育と新技術の調査を怠っているプロジェクト

「教育＆調査」は中堅がやることで、上に対して教育というのはないのです。
それに、調査するのは新しいフレームワークとかを調査して社内規約を発展させてプロジェクトの規約作るぐらいですかね。

生島さんは反論を望んでいるとの事なので、あえてAPサーバの方が良いという状況を書いてみます。
それは「エンドユーザーお金を出さない場合」です。
我々はプロなので、エンドユーザーの予算に合わせてシステムを構築せねばなりません。
この時有効なのは、王道のシステム作りではなくて、手抜き料理方式だと思います。
この状況では、この場合はAPサーバが適切だと思います。
手抜きという表現は適切で無いと思いますが、常に最高の品質が求められているわけではなくて、身の丈にあった安物のシステムも求められています。
情報処理技術者とは、高級料理しか作れない職人ではなくて、食堂の料理も作れる者でなくてはならないと思います。

saki1208です。
話、戻しちゃいますが...

インドリさん
>ええっ！これは驚きです。
>それならばSQLを知らない上流が居るはずが無いと思いますが・・・
これは割とゴロゴロいますヨ!
特にバブル開始前に就職したCOBOLオンリーの人たちに...
で、オープン系の開発もできないし、マネジメントもできない。と...
# そういう人たちは、プロジェクトごとの教育/調査にもあまり参画し
# ないケースが多いですかね。

生島さん
>そもそも、ペーパーベースで仕様が作れるのになぜに実装できないの？
単にリスクを負いたくないだけだと思います。

理由は、oumiさんの
>また、世の中悲しいことに、一度画面を確定させても、そしてそれに伴
>う実装が終わっても、システム全体の開発が終わらないうちは、「ごめ
>ん、ここちょっとこうして」　orz なくならないねぇなかなか・・・
ですよね。

お互いに何か着地点を探しているのかなぁ?

インドリさん、ども。
saki1208さん、ども。

> それは「エンドユーザーお金を出さない場合」です。

少なくとも、弊社は他所より安いのであてはまらないな。単独でできる場合ですけど。規模が小さいので受けれないけど、普通の単価で工数が下がる分、安くできるのですけどね。

># そういう人たちは、プロジェクトごとの教育/調査にもあまり参画し
># ないケースが多いですかね。

彼らが逃げるから、業界がよくならない。
彼らを逃がさないために起業するしかなかったのですが、まだ逃げられる（笑）

>また、世の中悲しいことに、一度画面を確定させても、そしてそれに伴
>う実装が終わっても、システム全体の開発が終わらないうちは、「ごめ
>ん、ここちょっとこうして」　orz なくならないねぇなかなか・・・

実装先にして納品してフェーズを切っちゃうから、変更は変更と主張できますし、ペーパーでやるよりは発生を抑えれます。

本当はね、外部の実装まではユーザがすりゃいい、って思っています。
それの手直しフェーズ、内部の設計、実装となってもいい。

多くの技術者が職を失うけど…。

>> ウォータフォールとアジャイルは・・・・
>> そもそも適用できるシステム規模が全然違うので、同じ土俵で並べる
>> のはまずいと思っていたり・・・

>そんなことはないです。
>そもそも、ペーパーベースで仕様が作れるのになぜに実装できないの？

小さな範囲の開発プロセスにおいては、この理屈は当たっていると思います。しかし、大規模開発では、横の仕様調整などが必須でこれに時間が非常にとられるのも事実。仕様やアーキテクチャがどうあるべきかという話のふりをして、憎悪や怨念が基底にある世界(TT)
アジャイル型の場合、システムにおいては非常に小さな部分でしかない単位でOKが出されて進行します（と思い込んでいます）。この時、横の連携を確保するとなると、アジャイル型開発の良さが失われていきます。横の連携とは、顧客の部・課、上級責任者、各開発チーム、サブシステム、といったような、おもに顧客組織構成（や開発組織構成）による単位です。
一方フリーフォール型（というか、フリーフォールの変形型ですね今時は）では、タイミングを決め仕様を確定させ（たことにして）開発フェーズ進行させていくわけですが、不確定要素を持ったままほぼ本番直前まで進んでいくことがほとんどです。
これも、おもに顧客組織構成（や開発組織構成）により問題を取りまとめられない、ということによる部分が殆ど。技術者(SIer)がヘボっていうのも多々ありますが・・

つまり、アジャイル型でもフリーフォール型でも大規模になればなるほど、顧客組織構成（や開発組織構成）による影響が大きい。特に、すでに確定させ、その開発が完了したもの、について影響がある問題が後から出てきた場合、非常につらい。
契約関係の下部にいる開発者や会社にはお金は仕様変更として新規に払われるが、上部へ行けば行くほど持ち出しとなる可能性が高い。また顧客が大規模開発において、予測のできないコストを良しとすることもなかなか無い（日本では）。

転じて、比較的小回りの利く小さめのプロジェクトの場合、フリーフォール型よりアジャイル型のほうが、圧倒的に良い。なぜなら、決定権を持つ人が全体を見渡せる可能性が高いから。また、いくつもの組織間の調整が必要のないケースが多いから。実際、フリーフォールとはいっても、偽アジャイル的な開発になっているのは事実。この小さめのプロジェクトでは、外部設計にかかる時間が圧倒的に短くて済み、顧客の納得も早く得られるのでよいでしょう。

大規模開発に、アジャイル型を浸透させるためには、アプリケーション開発方法論だけではなく、システム開発管理方法論も合わせて浸透させる必要があり、そのうえで、どのように利益を出していけるかが判っていかないと、大規模開発に完全適用するのは難しい。当然、開発に携わる人の教育も必要。
ですので、今はまだ実験的に、比較的影響範囲の狭いと思われる部分に適用してるだけという感じです。

とはいっても、この私見は、会計や外為・為替、窓口サービスなどの、よく言われる基幹系システム部分と、それらに関係する情報系・BIなどの世界での話ですので不完全な考えの部分もあると思います。特に、数名～数十名で行われるシステム開発や、コンシューマ向け、パッケージについては、トンチンカンです。

{
アジャイル：責任者は顧客
フリーフォール：責任者はSier
最後に泣くのは:いつも顧客
}
上流の連中にSQL覚えさせるより、顧客に覚えさせたほうが、必然的に総体的に良くなっていくのではないだろうか・・・

お客様が看板しか見ず、さらに鑑定士も用意せず、完璧に信じきって無防備に非技術者を優遇するからこの業界は、奴隷産業や多重下請け構造と揶揄される結果になっているのですが、だからといって素直に「全てのエンドユーザ」が自分の業務とは関係の無い情報処理技術を学ぶでしょうか？
億単位のお金を平気で消費する人達が・・・
それは上流に学習させるよりも難しいと思います。

10億ぐらいのプロジェクトでもユーザはアジャイルを求めたりする。
これは、ユーザ（情報システム部）が本当にユーザだから。
もちろん、SIerは頑なに拒むけれど、拒めば拒むほど仕様変更で泥沼になり、ユーザが悪いとユーザの所為にする。

1000万ぐらいの案件でも、ユーザがウォーターフォールを求めたりもする。
これは、ユーザ（情報システム部）が、実はSIer上がりのCobolerだから。

ところが、やっぱり現物を見ないで承認したものなど話にならないから、仕様変更で泥沼になる。

確かに、巨大システムの場合は、ユーザもSIer上がりのCobolerの可能性が高いので難しいのですけれど。

oumi さんの考え方は、結局、従来どおりでないと巨大プロジェクトは終わらないと言ってるわけで、プロであるSIerが何の解決策も持ってないことになりやしませんか？

>oumi さんの考え方は、結局、従来どおりでないと巨大プロジェクトは終わらない
>と言ってるわけで、プロであるSIerが何の解決策も持ってないことになりやしま
>せんか？

どこをどう読むとそういうことになっちゃうのかな？（やめませんか、こういう話の展開のさせかた・・）もっとも、今、just now 、適用可能な方法・手法をSIerが取っていないということを問題だというのであれば、是、でしょうけど・・だから何？ってなもんですね。時間はかかると思いますよ。

あっと、ここで訂正
「アジャイルでうまくいくのは、テーブル設計の必要がないぐらい内部が単純で、外部の要求が厳しい場合」
これすっかり忘れてました。この前提があると、私の私見は全く当てはまらないですね。いまさら投稿したもの消せないですし・・・困った、申し訳ないです。

すみません。
毎回、前提を書くとややこしくなるので、アジャイルと言ってるのは、「UIをテーブルなしでアジャイルで！」ということです。
ややこしくてすみません。

影響範囲の大きな内部要件は、UI（外部要件）の実装中、ずーと基本設計をするわけです。UIが完璧に固まったのを見て、テーブルを確定し、それぞれの詳細設計を行う。

UIの実装前に確定してたテーブルなんて、もう、滅茶苦茶ですけれど、ギリギリまで確定を遅らせたテーブル設計は非常に効率的ですから、ほとんどの処理はSQL１文（＋ストアドファンクション）で処理可能なぐらいになっています。

巨大なプロジェクトほどアジャイルでUIを固めるべきと言ってるのですけれど、そうすると、重要なスタート時点でCobolerの上流の人の仕事が大幅に減る。
→ 尋常じゃない抵抗を受ける。

これを何とかしたいのです。

>巨大なプロジェクトほどアジャイルでUIを固めるべきと言ってるのですけれど

そのとおりUIはそうするのが良いですね。
テーブルの実装は後でというより、開発者サイドの内部の問題だということだと思います。たぶん「後で」というのはそんなニュアンスだろうと思います。

既に、前に書いたと思いますが、フリーフォール型での開発現場でも、UIについては、アジャイル的発想が取り入れられているところがあります。これはSIerの努力というよりは、顧客がいろいろと判ってきたからだと思います。（SIerも努力してます実際^^;

そうでない状況にあるところは？
人間だれしも、その人のやってきた事を否定されると反発するものですから、ある意味、理想の学校教師的な方策が必要だと思っています。たとえば、「これこれ、こうですが、そこは足並みを早くするために、こんな方法を使ってみてはどうか？、これは○○でも効果があったので、検討の余地はあると思いますが？」というような、やんわり～とした言い方で攻める。くらいしか思いつかないな・・
（国がとか他力本願的な発想は無とすればですが。）
その、Coboler(この単語自体は非常に嫌悪を感じますが)上りの上流の方々には、肯定から入り、ちょっとした提案を、という方法が結構効きます。（全員というわけではないでしょうけど）それでもダメなところは？、、、乙としか言いようがないかも・・

しかし、このやりかたは、草の根活動的でダイナミックさにかけるから、面白みはないですね・・

>影響範囲の大きな内部要件は、UI（外部要件）の実装中、ずーと基本設計をするわけです。UIが完璧に固まったのを見て、テーブルを確定し、それぞれの詳細設計を行う。

この方法はアプリケーションの開発方法としては、良いのですが、結構DBのおもりをする方にはつらい部分もありますね（＾＾；後になって、うわー、DISKのフォーマットサイズかえなきゃ（＞＜）とか、論理ボリュームの配置治さなきゃ（＞＜）とか、いろいろ・・げーINDEX量が全然予定とちがうやーんとか・・
ま、アジャイルに限った話じゃないですから、泣くのは同じか・・

高度なSQLの知識についてすっかりどっかいっちゃったのですが、
生島さんのおっしゃってる内容ですと、ちょっとハードル下げすぎかなと思いました。特に、キャパシティに関する数値を把握しているとか、現在のINDEX構成がどうなっているかとか、INDEXのタイプは何何だとか、そういったところまで、つっこんで知っているべきだと思いました。
以前辟易したことがありますが、約65000テーブルで、6テラ程度のスキーマ（Oracle）を後から正規化、サイズの減量、列項目の妥当性、INDEXの見直し、などもろもろをなんとかしてくれという事をやったときに、開発者（設計者）の方達があまりにも何も知らなさすぎるということにぶち当たった時がありました。実際、これと同等のスキーマが６つもあるので、すごい量です。
しかたがないので、情報の周知をするとともに、ツールを作成したり、アプリケーションのリリース前に、性能とキャパシティに関する精査を必ず報告する運用をするといったことを行いました。

アジャイルだろうが、フリーフォールであろうが、上流担当する技術者は高度なRDBMSの知識は必須です。ほんと。（５人に１人の割合でいてほしい最低限）

> アジャイルだろうが、フリーフォールであろうが、上流担当する技術者は
> 高度なRDBMSの知識は必須です。ほんと。（５人に１人の割合でいてほしい
> 最低限）

5人に1人いた上で、全員が最低限の知識を持つことでしょうね。
普通のプロジェクトでも、それなりのDBエンジニアは招聘するでしょう。
しかし、DBエンジニアが上流とはみなされなかったり、他の4人と会話が成り立たないぐらい隔たりがあるから、巨大プロジェクトでも失敗するのです。

おかげで、下流の方にいる人は作業者に成り下がり、残業で稼げる！って喜ぶ人と、壊れていく人と…、どちらも健全ではないです。

約65000テーブル ってことは、既に担当者が何も分かってないということでしょう。

月締めごとに顧客単位のテーブルができるというすごいプロジェクトとか、1台のマシンでDBが30個（必要なテーブルをコピーして作っていて、整合性がぐちゃぐちゃ…）とか、理解不能なのはいくらでもあります。
作り直ししかないでしょう。

残念ながら、巨大プロジェクトの一番上は私は取れないので、私のところに来るときには既に手遅れです。