ベンチャー社長で技術者で

　「上流技術者はSQLを！」と何度も書いていますが、それは「上流技術者のスキル不足で方針が覆せなくなり、顧客に対する成果物に差が出る」からです。

　なぜ、差が出るのか、以下で説明します。

　案件のスタートラインの打ち合わせで、顧客から漠然とした要望を聞いたとき、そこにいる営業と最上流の技術者は、話しながら難易度（粗い見積り）を測っています。

　これはどんな人でもやります。新人PGだって、「あーやって、こーやって、なんだか難しそうだ」ってね。つまり、会話（打ち合わせ）で難易度を測らない人はいないです。

　営業が一般的な人であった場合、会話の仕切り役に終始することでしょうが、今までの似た案件を元にざっくり難易度（粗い見積り）を見定めながら、最上流の技術者の顔色などを見ながら仕切っていきます。ちなみに、営業が技術者上がりだった場合、SQLを使わないパターンの見積りはかなり正確に出しています。

　もちろん、最上流の技術者も難易度を測っていてます。

　もし、この場で自信を持った難易度が出なかったら、顧客に下手に言質を与えるわけにいかないので「帰って検討します」しか言えません。「ガキの使い」状態になるしかないですね。

　ですから、この瞬間というのは、最上流の技術者にとってかなり緊張を強いられる難しい（楽しい）瞬間になります。

　この時点で、VB6か.NETかなんて瑣末なことはどうでもよい（どちらで考えても誤差の範囲）のです。しかし、難易度を測る上で、ループして処理するか、SQLで処理するかで、想像した難易度やその後のプロジェクトの運営方針は全然違ってくるので、その打合せの場で話す内容も変わってきます。

　変わらないと思ったら以下を確認してください。

1. SQLで処理をしたら、工数が数倍以上、パフォーマンスが10倍以上の差がつくことがある。
2. 顧客から要望を聞いた時点で、イメージしたもので工数が数倍以上、パフォーマンスが10倍以上の違いがあれば、その後、顧客に話す内容に違いが出る。
3. 上流の技術者はコンピュータを使わない手段も含め、あらゆる手段を検討し提案すべき。

　ノーと考えたなら、顧客に話す内容は変わらないでしょうし、わたしの考える前提と違っているのでしょう。この後を読むのは時間の無駄なので読まない方がいいです。

　全部イエスとなり、SQLで処理できるのに「できない」と判断していたときは、SQLで処理した場合の工数が数倍以上、パフォーマンスが10倍以上のイメージの違いがある状態で顧客と話すことになります。

　つまり、顧客に話した内容は、工数が数倍以上、パフォーマンスが10倍以上と同等の大きな差がついています。

　新人PGが考えた難易度は周りの指導で簡単に変わりますが、最上流は誰からも指導されることもなく、顧客にも話してしまっている既成事実になっています。もう固定されてしまって覆せないのです。特に営業が優秀であった場合や、上流技術者が複数いた場合、力を持った者の複数のコンセンサスになってしまうので、絶対にひっくり返りません。

　難しい処理ほど差がつき、難しい処理ほど顧客に対して影響が大きい。顧客に対して影響が大きいものほど、上流技術者がソリューションを提供すべきものになりますが、その肝心の場面で、工数が数倍以下、パフォーマンスが10倍以下の方針へ指揮棒を振ることになります。でも、上流技術者が指揮棒を振った方向が成功ラインなのですから、上流はよほどのことがない限り、失敗することはないけどね（下流のせいにできるものね～）。

　こういう状態にならないためには、上流が会話のペースで粗くても良いので、（当然、できないこともあるので闇雲ではなく）できるかできないか確証が持てるレベルに習熟する必要があります。つまり、演習問題ぐらいの難易度で、会話のペースで判断できるかどうかが非常に重要なのです。演習問題ぐらいがこなせないと、打ち合わせの現場でSQLで処理するという方針（わたしの考える成功ライン）を採ることはできません。

　逆に確証がもてれば、自分がコーディングする必要はまったくなく、指示すればよいのです。

　ところが、現状では、上流の技術者が演習問題を見ても、SQLの問題と聞かなければSQLで処理することを検討することすらないでしょう。つまりほとんどのプロジェクトで、上流が打ち合わせの席で難易度を測りだすというわずかな時間に、SQLで処理するという方針の大部分が潰されてもう覆せません。

　潰されなかったモノが、更に下流のコーディングレベルでも差がでて、そこで起きる議論が一般的な「SQLでやれよ！」って議論なのですが、わたしはその上にもう1段あると言ってるわけです。

　では、表題に戻って。

　VB6のお陰か「継承など何が便利か分からない」って人は案外たくさんいます（多重継承の批判のため逆説的に使う人を除く）。

　継承を利用するのは、オブジェクト指向言語を使うのと同義語と言えるぐらい当たり前のことですが、それでもしばしば、機能分割からクラス設計が始まるあたりの議論が起きます。

　タイミング的にはSQLで処理するかの決定よりずいぶん後になってからで、上流というか中流というか、ともかく機能分割などを担当する技術者のスキルによって変わるでしょう。担当者がCOBOLやVB6からの流れで「継承など何が便利か分からない」という人で、それより上位も同じようなスキルだったら、たいがい難儀（大阪弁）なことになります。

　つまり、妙な機能分割をして、いい加減な（というか継承がわからない人がどうやって……）クラス設計をしながら作業を割り振っていきます。そして、作業分担が決定した時点で覆せなくなります（覆すには相当な手戻りや、調整が発生します）。

　継承の議論なんて馬鹿馬鹿しいと思う向きもあるかもしれませんが、冗談抜きでVB6と.NETの議論をされてた方々の何人かは経験があるかもしれません。

　実はわたしもこれをやられて、数千万の赤字を抱えることになったし……、そのときは精神が壊れて、本当に何度も電車に飛び込む寸前まで追い込まれました。そういう奴をアサインした時点でわたしの大ミスですけれど、さらに当事者に文句を言われるのは何とも納得できなかった（逆に、納得してたら飛び込んでたな……）。

　それはともかく、そういう人は言うのです。

　「俺はこういうやり方（継承なし）で実績上げてきた」

　「俺の方針（継承なし）で、できないというのか～！」

　継承ぐらい当たり前にできるあなたはこう思うでしょう。

　「あんたが上げた実績は成功じゃなく、成功ラインが低かっただけ！」

　「できる、できないじゃなく効率の問題だって」

　できる人から見ればものすごく馬鹿げた話で、「右折のできないタクシードライバー」ぐらいに感じると思います。しかし、相手が理解できるレベルに来るまで、まともな会話は成り立ちません（上にいる人は簡単には自分ができないとは認めないしね）。で、できない人は、今起きている問題点の存在すら分かりません。

　では、継承をSQLに置き換えて読んでもらえればどうでしょう。同じことはSQLでも起きますし、現実にもっと広範囲（継承のなかったVB6のころからずっと）に起きています。

　「そんなことはない」と思う人もいるかもしれませんが、それは「俺はこれで実績を上げてきた」ってことですよね。演習問題程度も「できない」基準で見ているからで、「できない」人が何を根拠に「そんなことない」というのか、わたしにはまったく理解できません。

　もちろん、多数決をとれば、いわゆるフルボッコでわたしは負けますけれど、技術者が多数決を持ち出したら、地球はまだ平らのままでしょう。多数決を言い出す奴は、技術者じゃなく慣習に流される作業者です。（多数決というか技術者の少なさで）リスクを考えて判断するのは、経営者（まぁPMもするけどね）が最後にすることで、技術者が多数決を持ち出す必要はないのです。

　継承ぐらいの小さな問題は、実際には下流に近いところや下流で起きますので、ボトムアップ（下流の人が言語を勉強する努力）で徐々に解決する問題で、そんな戯けたことを言う人は確実に減っていきます。

　で、継承を使わないプロジェクトもやったことがあるけれど、実際にそんなに大きな差は出ないのですよ。継承するかどうかなんて、ときに激しく議論になることもありますけれど、SQLと比べれば結果は本当に瑣末な問題で、顧客に対しての成果物にほとんど差はありません。（弊社で失敗した理由は、SQLを使うかどうかとか、もっと他のが重なってね……、そのレベルの人間に期待をかけてPMに置いてしまったわたしの責任ですけどね）。

　オブジェクト指向言語を使っていて「継承など何が便利か分からない」というのは技術者として、かなり恥ずかしいと思いますけど、顧客に対する結果の差から考えると、顧客にRDBMSを導入させておいて、「SQLができない」ことの方が相当に悪質です。

　上流の仕事を最初の打合せに戻って考えると、VB6か.NETか、などの言語の選択や、継承や、その他の問題は、決定までに猶予、つまり社に戻って他の技術者を交えて議論する余地があるのですが、SQLで処理することは、説明したとおり、本当に顧客を前にした最初の瞬間に限界が決まっていて、後からは変えられないのです。

　GOTOを駆逐するのも、継承を利用して工数を下げるのも、下流からボトムアップで解決できるから変わってきましたが、これは、上流の人間が「言語なんて……」と思っていて、言語の詳しい内容は知らないから、逆に「よきに計らえ」って言い易い。ですから変わっていくのです。

　10年かかってもSQLがまっとうに使われないのは、SQLが難しいからではなく、上流でつぶしているから、つまり、「上流がボンクラだから」なのです。

　上流のほとんどの方は、自分が顧客の前で話してきた内容を、下流の指摘によって変更して顧客に再提案するなんて、プライドが邪魔して簡単にはできません。

　プライドだけでなく、場合によっては、バッチ処理を選んだために運用チームに運用設計の指示を出しているかもしれません。リアルに答えが出ないための工夫を顧客に説明しているかもしれません。中間処理の設計を指示したかもしれません。顧客に中間の操作をお願いしたかもしれません。

　変更するときは、すべての関係者に方針の変更を説明しなければなりません。つまり、事実上、変更できない。くどいですが、上流のほんの一瞬のイメージで確定してしまいます。

　うそだと思ったら、演習問題を実際に設計してPGに詳細設計書が渡ったあと、それを見たPGが「こんなの一発でできますよ」って言ってきたときを想像しましょう。……それが理解できたとしても、どうしようもないでしょ。遡って、どの段階なら方針を変更できたかというと……。

　理解できましたでしょうか？ あなたが処理をイメージして誰かに伝え始めた時点で、もう変えれないのです。

　上流下流と分けるなら、もちろん、案件の規模が2千万以下なら上流は何もかも知らないといけないけれど、それ以上の規模なら分業せざるを得ませんから、規模によっては上流はVB6を選ぶか.NETを選ぶかなんて、（積極的にかかわってもいいけれど）下々に任せてもいいぐらいです。継承を使うかどうかなんて、まったく関係ない職域の話になることもあります。

　しかし、SQLについては会話のペースでパフォーマンスを予想するぐらいできなくては、無意識にプロジェクトの未来をつぶしてしまいます。部下の可能性も止めてしまいます。

　上にも書きましたが、上流とは、もっとも多くの選択肢（コンピュータを使わない手段も含め）を持っているべき立場ですから、顧客に対する便益が大幅に変わる可能性のある「SQLで処理する」という選択肢をもってないのは、職責にかかわる重大問題です。

　選択肢を持った上で、最終的に選択しないのと、選択肢を持っていないのは本質的にまるっきり違います。右折のできないドライバーが、たまたま直進と左折で行ける目的地だっただけの話です。結果的に使わないことになろうと、なかろうと関係ない。演習問題ぐらいできなかったら選択肢に入っていないというのが、重大問題なわけです。

　しかも、RDBMS（SQL）は業務システムでもっとも広範に使われていて、現在使われている技術の中では、一番古くからあるといえるものです。突発的に出てきた新しい技術ではない、それで、職責にかかわる重要なスキルが足りないのに「上流技術者」を名乗ったら詐欺師でしょう。相対論ですからね、上流が、右折のできないドライバーでも、ボンクラでも、詐欺師でもないなら、わたしが神になるしかないかな（笑）。

　ともかく、くどいけれど上流の技術者はSQLをできるようになるべきです。

　現状ではできない人の数が多すぎて、全員が詐欺師になっちゃいかねないので（笑）責められないですが。ならば、逆にできるだけ早く覚えておいて（もう十分遅いけどね）損はないはずです。早くスキルチェンジできれば、それだけおいしいところが取れます。.NETよりは長持ちするかもです（笑）。

　特に上流の技術者は、おいしいところを自分で作り出せるのですけどね（あまりにできる人の数が少ないと、わたしのように苦労しますけど）　。あとは、既存のお客様になんと言い訳するかですけど……。ドラスティックに変われば変わるほど、過去の自分を徹底的に否定することになるからな～。

　つまり、大きな案件で頭（上流）をいくつも取ってきて、自分の過去を否定しにくい大手は簡単には変われない。これも馬鹿な話ですが、既得権を持って、過去を否定できないからよい悪いでは判断できない。官僚と同じ構造で実に醜い。個々には非常に優秀で立派な人が多いけれど、過去を否定できないからという点は、わたしには許しがたい。

　逆に中小で下請け脱却を狙う、下克上にはちょうどいいのですけどね……。ツールもFWも言語も関係ない。導入済みのRDBMSをちゃんと使うだけですから。「上がボンクラ」を証明すれば良いわけです。

　「じゃあ、なんでお前はできないんだよ！」というのは……、前に書いたでっかい赤字を引きずっているからです。受託で頭を取りにいくには資金力が要る。たとえば、1億の案件を取るには、7～8千万はキャッシュを持ってないと取れない。7千万しか持ってないのに取りにいくのも相当なギャンブルです。そんなギャンブルをするところに、1億の案件を出す人はない。つまり、弊社ではできないのですよ。……本当に死にたいぐらいに悔しい。

　金ない、金ないと言ってても仕方ないので、NPO法人JASIPA というころに加盟したりして、ジョイントベンチャーなどもやっていきたいと考えています。まだ、わたしも入ったばっかりですけれど、もし、中小IT企業の社長さん（社長でなくてもよいのですが）がごらんになっていれば、ぜひご加入ください。

　それはともかく、SQLなんて本当に簡単なものですから、2日も勉強すれば、できるかどうかの判断と粗いパフォーマンスの見積りぐらいはできるようになります。

◇　　　　◇　　　　◇　　　　◇

　急ですが、東京でセミナーをやることになりました。わたしは、そんなに怖い人じゃないですよ（笑）。

　日程は7月16、17日、7月18、19日の2日コース2回です。

　内容は、文法の細かな説明ではなく、これはSQLで処理できるかどうか、パフォーマンスはどれぐらいになるか、といったことが会話のペースで理解できることを目標にしています。後はリファレンスを見たら書けるでしょう。

　PCのあるセミナールームを使おうと考えていたのですが、貸し会議室でSQLServer 2005 Express Edition以上をノートPCをご持参いただく形にしました。（レンタルは2台まで可能です）　

　大阪では、数人で弊社の小汚い事務所で土日に開催します。7月11日12日は開催確定です。

　価格は、次回から個人で受けられる方と、会社から受けられる方（領収書の宛名が個人か法人かで）と分けたいと思います。わたしが神なら、神の価格になるので普通人より安い今がチャンスです（笑）。詳しくはメールにて　info@g1sys.co.jp