株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。

炎上までいかなかったけれど、たくさんのご意見ありがとうございました

»

■ ご意見ありがとうございました。

 皆様、ご意見いただきありがとうございました。

 結局、ここでコメントくれるような人はおそらくできる人だから、もっともっと反対意見を聞きたかったのですけれど……。

 正直、何を根拠にAPサーバで処理した方が良いなどと言ってるのか、いまだに分かりません。私がアホなんでしょうが、口汚く罵って煽ってみても、そういう主張の方のコメントが得られなかったのは残念です。炎上もさせられなかった(笑)。

 インスタンス変数にマスターなどをキャッシュしてデータが変わったときにリフレッシュすればよい、などという高度なご意見も頂きましたけれど、APサーバが複数であればリフレッシュはなかなか困難ですね。複数サーバへのリフレッシュ機能を持ち合わせていなければ、スケラービリティは落ちてしまいます。

 不可能じゃないけれど、そこまで考えられているプロジェクトは、おそらく、DBサーバですべき処理は、DBサーバで処理されているでしょう。

■ 問題は考えてない人

 問題は考えてない人です。

 つまり、

 「DBサーバで処理した方がパフォーマンスがいいのは分かる、でも、シングルポイントのDBサーバに処理させるのはスケーラビリティに問題がある

と、切り替えしてくる人です(本当にそう思う人は、ぜひ、こちらを読んでください)。

 わたしは、数百人の技術者を見、百人以上の技術者と深くかかわってきましたが、こういう人はゼロではなく、むしろ大多数で、彼らはDBサーバの処理なんて考えたこともないし、検証もしてない。

 流れ(雰囲気)で話しているだけで、わたしとしては技術者と呼ぶのに抵抗があります。

■ SQLができないのはオートマ免許

 自分で考えている人は少数派です。

 さらに、SQL(DB)を高いレベルで理解している人はかなり少数派です。

 そして、SQLができてJavaなど他の言語ができないという人は極めて稀です。

 なぜなら、SQLから教育を受けることは稀で(一部、あるみたいですけれど。非IT企業だったり……)、Javaや.NETなどから仕込まれ、Javaや.NETを使う現場へ放り込まれる。SQLについて教育を受けたとしても、Javaや.NETなど他の言語の添え物程度です。

 その状態で、Javaや.NETなどの言語に何か問題や限界を感じた人が、個人的に(一部、組織的に)SQLの技術を磨き始めるわけです。ですから、SQLだけができるようになる技術者は、極めて稀になるわけです。

 逆に考えると、現在の様な逆境の中でSQLが高いレベルでできるようになった人は、問題意識が高く、同時に他の言語や開発手法にも(限界を感じるところまで)通じているということになります。

 ですから、現状ではSQL(DB)が高いレベルで分かっている人は、いろんなしがらみでAPサーバで処理することになったとしても、仕事と割り切れば対応は可能です(わたしは割り切らないために起業したのですが、以前は……)。

 つまり、SQLができる人はどちらでも選べるわけです。

 しかし、当然ですが、SQLができない人はDBサーバで処理する方法は選べないのです。

 片方しか選べないというのは、車でいえばオートマ免許と同じですが、それでよく金を取るというか、プロを名乗るというか、呆れるというか……。

 技術者としてプライドがあるなら、マニュアル車にも乗れるようになったらどうかと言っているわけです。RDBMSはほとんどの現場にあるのですから、その気になれば習得できます。

 わたしが覚えた頃は、Oracleのマニュアルすら別売りで30万円もして、Oracle自体も100万を超えていて個人ではとても買えなかったから、会社に残って勉強するしかなかったのです。今ではOracleもSQL Serverもフリーのモノがあって、マニュアルもすべて無償で公開されています。それだけ恵まれていて、なぜ、自習できないのか不思議でなりません。

 結局、プロとしての意識の違いでしょう。

 もちろん、フォークリフトの免許はあるとか、玉掛の免許があるとか(自動車免許なしに取れるのかな?)、そういう人はプロですよ。つまり、RDBMSとはかかわりのない仕事を担当している、ネットワークやセキュリティやモロモロのプロは、やはりプロですけれど、SIerならイヤでもRDBMSを使うことが出てくるのですから、必須であると言ってます。

■ 方針を決めるには

 SIerの本来の判断は、何を決めるにしても以下のようなファクター

  • 要件
  • 開発コスト
  • 設備コスト
  • パフォーマンス
  • 保守性
  • スケーラビリティ
  • 技術者のスキル(教育コスト)
  • FWなど過去の資産(しがらみ)

のすべてに何らかの傾斜(重み)を付けた上で、決定しなければなりません。

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

 もっとも、顧客の情報システム部がメンテするのに「SQLは分からないから」というときは、さすがに頑固一徹の私も引きます。

 最終的に経営者は赤字を出すわけにはいかないので、【開発会社の都合】を優先して、それで受注できれば、技術者の考える方針ではない決断になることもあるでしょうが、技術者が提案する上で、SQLが高いレベルでできなければ、DBで処理するという方針は絶対に選択されることはないのです。

 オートマ免許しか持ってない人は、オートマの車しか買えない(買っても乗れない)のと同じです。

 そう考えると、さらに何度も同じことになるのですけれど、方針を決めるべきいわゆる上流技術者がSQLを知らなければ、上に立つ人間が重要な選択肢を最初から潰しているわけで、大変な問題があるわけです。方針を決めるべき人間が、重要な選択肢を持ってないということはあるまじき事態だとわたしは考えます。

 ですから、上流の技術者はSQLを高いレベルで理解しておくのは必須であると主張しているわけです。

■ それぞれのファクターを検討するなんて実は理想論

 実際には方針を選択するのにそれぞれのファクターなど見ていない。

 とりあえず「今の流行はJavaだから、Javaで提案しておけばいい」「前うまくいったからこれでいい」「先輩がいうから」「部長がいうから」なんですよ。

 Javaは、Rubyに置き換えようが何に置き換えようが構いませんが、大方針を決めるのに検討なんかしていないです。

 突っ込まれたときに、「スケーラビリティの問題がある」などというはぐらかす言葉だけは強くなっても、それは前例主義や権威主義です。わたしは、そんな理屈になってない発言に対して「お前らは糞官僚か!!!」って激怒するわけです。既得権を必死で守ろうとする姿勢も官僚とまったく同じで、人間として軽蔑の対象にしかなりえない。

 会社を興してまで、そんなものと戦おうとするのはバカの極みで、自分でももうちょっと楽な生き方を考えなくはないのですけれど……。

 ぜひとも反論してもらいたい。

■ アジャイルで工事進行基準

 面倒くさくなったので別記事にはしないけれど、ついでに「アジャイルでは工事進行基準に適応できない?」というご意見についてです。

 もちろんできます。

 アジャイルというのは、わたしが主張している「テーブル設計は実装の後に!」行うというものです。

 つまり、わたしの主張は【外部要件】【内部要件】をそれぞれ分けて開発します。

 いわゆるウォーターフォール開発の基本設計フェイズは、アジャイルの実装フェイズになります。

 単純に考えて、

【ウォーターフォール開発】 

  • 基本設計(テーブル設計も含む)
  • レビュー・承認
  • 詳細設計
  • レビュー・承認
  • 実装
  • 単体テスト
  • 結合テスト
  • ユーザー検証
  • 導入教育

【アジャイル】

  • 外部設計・実装(アジャイル)
  • 外部単体テスト・レビュー(納品)
  • 内部設計(テーブル設計も含む)
  • レビュー・承認(ないことも)
  • 内部実装
  • 内部単体テスト
  • 結合テスト
  • ユーザー検証
  • 導入教育

 工程数は同じか増えているのですから、ウォーターフォールより工事進行基準に適応しやすいのです。

 ウォーターフォールで基本設計書が1回のレビューで通るでしょうか? COBOLの時代では実装するのに時間がかかって、ドキュメントの方が遙かに早く顧客に見せることができたから、ドキュメントベースでアジャイル(反復開発)になっていたともいえるのです。

 しかし、大変優れたIDE(RADツール)が登場した結果、UIに絞れば、実装してもドキュメントを作るより早くできます。もちろん、複雑なUIはそれなりに時間(回数)がかかりますが、それもドキュメントだけでやるより、遙かに時間は少なくなります。

 ですから、内部要件・外部要件に分けた方が良いわけです。

 両方できる人は、残念ながら少数派なのですから、分からない知識で設計するなんて危険なことをしてはいけないのです。

 わたしは神ではないので、すべて正しいなどとはこれぽっちも思っていません。わたし自身も、間違いに対して不安を持っています。

 反論はいつでも待っています。

Comment(25)

コメント

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

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

パフォーマンスを抜きにしてスケーラビリティを求める際には、できるだけ処理を分散というか委譲というか、ネックとならないように構築することによってリソースの増強により性能を拡張することが多いと思います。私はあまりその道に詳しくはないので、間違っているかもしれませんがDBサーバーを増強するよりもAPサーバーを増強する方が、かなり実施しやすい方法なのかなと思います。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屋さんは、ユーザに毛が生えただけの存在ですから、センスの良いユーザ(情報システム部)に負けちゃいます。
本当の要望を知っているのはユーザ(情報システム部)で、技術の裏づけをクラウドの向こう側に求めるなら、勝てるわけがないのです。

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

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

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

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

インドリ

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

生島さんが仰るように

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

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

saki1208

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

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

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

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

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

tripod

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

> 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を使うのはいいのですが、その辺まで考慮しているのかと私は問いたいです。
そうしないと・・・
お客様「データがおかしいぞ」
上流「わかりません。最近の技術は複雑ですからねぇ・・・」
となりかねません。
キャッシュはデータの同期問題を解決する必要があります。

インドリ

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

oumi

「上流の技術者は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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

oumi

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

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

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

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

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


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

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

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

インドリ

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

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

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

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

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


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

oumi

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

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

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

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

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

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

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

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

oumi

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

コメントを投稿する