上流の仕事について考えてみる
コメント欄やはてブで「上流とはもっと上流なんだ」というようなご意見を頂いたので、そのことについて。
■ 上流の方からの御不満
元記事はこちらです。
客 「きめ細かい顧客サポートをしたいので、以前より取引（量、回数）が落ちている得意先に営業をかけたい。該当する企業をリストアップして欲しいんだけど」
と要望をうかがったとします。
ここで出てくる「客」の業種によって、上流の判断はかなり差が出ます。
例えば、「以前より取引（量、回数）が落ちている」が問題です。アパレル業界なら、季節ごとに買ってくれていたとか、自動車業界なら車検のタイミングとか、家電業界なら商品の耐用年数を考えて品種ごとに調査しないといけないでしょう。
しかし、上流をご担当の方からかなりご不満を頂きました。
これらの方々は、「上流の技術者はSQLを習得すべき」というわたしの提案から、SQLの習得を（上流の技術者にとっての）十分条件と感じたようですけれど、わたしは上流の技術者にとって、あった方がよいスキル（必要条件）だという風に考えています。
上流を担当するなら、業務知識や分析・提案能力があって当然です。それに加えて、SQLやセキュリティ、ネットワークなどの広範な知識が必要なのですが、その能力を持っている人はほとんどいない、ということです。特に、SQLのスキルが足りないのですが、業種ごとに話してもまとまらないので、抽象化して問題点を出そうとすると、以前の記事のようになるのでした。
とはいうものの、せっかくご意見を頂いたので、上流（あまりこんな言い方好きじゃないのですが）らしく、業界をイロイロ変えて話を進めてみましょう。
■ 業界ごとに上流の提案を考えてみる
客 「きめ細かい顧客サポートをしたいので、以前より取引（量、回数）が落ちている得意先に営業をかけたい。該当する企業をリストアップして欲しいんだけど」
まずは、顧客が考えていることを要約しましょう。すると、「過去データを参照し、受注見込み客、他社に移動しそうな客を洗い出し、それらの企業にアプローチしたい」ということになると思います。
●アパレル（B2C）
アパレル業界では、季節によって顧客の購買行動が変化します。前年同月比を見る必要があるかもしれません。
逆も考えられます。例えば、去年、秋物を購入した顧客には、1年と1シーズン空けて冬物が売れるかもしれません（連続で秋物ばかりは買わないかも）。
私はアパレルのことはよく分からないので、ここはしっかりとしたヒアリングが必要ですし、プロのコンサルタントならデータを分析すべきでしょう。
また、そもそも、顧客の購入履歴が十分集まっているかという問題もあります。
顧客情報はポイント制などを利用して集めている可能性がありますが、なければ顧客情報を効率的に集める方法を提案する必要があるでしょう。
ポイントカードシステムそのものやセキュリティなどについて、広範な知識もいるでしょう。
●アパレル（B2B）、材料メーカー（B2B）
B2Bで取引をしている企業の場合は、定期オーダーになりやすいですから、例題の状態で受注見込み客、あるいは乗り換えを検討している顧客をピックアップできるかもしれません。
とはいえ、季節が関係する材料のときには、前年同月の数値を比較する必要があるでしょう。
●車のディーラー
車検のタイミングが近い人を抽出することが多いですね。
対法人なら、決算期、リースアップ時期で抽出することになるでしょう。
ほかに、家族のイベント（高校・大学卒業時期）などの情報も集めておけばベストです。アンケートなどで正しいデータを集めて、それが確実にDBに反映されているか確認し、反映されていないときは、どうすれば正しくデータを集積できるか検討する必要があります。
DBの構造が抽出しやすいようになっているか確認する必要があります。
●家電（B2C）
品種ごとの買い替え時期（寿命）によって抽出すべきかもしれません。
Amazon.comのお勧め商品のように、ほかの人の購入履歴とマッチさせ、ワントゥワンマーケティングをすることを提案してもよいかもしれません。
●B2C全般
ポイント制を導入しているか？
ポイント制は「顧客の囲い込み」だけが目的ではありません。もう1つの目的は、自動的に名寄せされるというところにあります。
ところが、ポイント制を「顧客の囲い込み」のための単なる割引制度と考えているところは、「名寄せ機能」を提供しないところが多いです。
「名寄せ機能がない」というのは、カードを忘れたときに新規カードを発行させて、そのカードを合算させないとか……。
一方でカードを忘れても、名前と電話番号、住所などの組み合わせで、カードなしでポイントを貯められるところもあります。
個人的にはポイントカードなどに無頓着なので、カードがダブってしまうことがよくあります。後から合算できないお店を見ると、無駄になるポイントはどうでも良いのですが、システム屋としてついついイライラして、上流を担当したシステム屋に「このボンクラが！！」と心の中で毒づいています。
私が上流を担当したら、今は必要なくても、将来ワントゥワンマーケティングを実施するために（名寄せされた）履歴の重要性を訴え、ポイントの消費率が多少増えても、費用対効果は合うというオチに持っていきますけれど……。
ついさっき、家電量販店でイライラしたので脱線してしまいました（笑）
●全般
データを分析するには、SQLは必須です。
ざっくり業界を変えてみても、提案する前にはデータの分析は必要ですし、何を提案するにも難易度（粗い見積り）がないことには、費用対効果が分からない提案をせざるを得ません。
他人任せでよいと考える人もいるでしょうけれど、SQLができればいちいち依頼せずとも、いくつもの切り口で独自に分析が可能です。
■ まとめ
もちろん、上流の仕事において、ネットワークが分かることで解決できる問題はあるでしょう。セキュリティの知識も重要でしょう。それらがいらないとはいってません。
例題は、RDBMSを使うものなので、バイアスがかかっています。
しかし、SIerが担当するシステムのほとんどはRDBMSを使うのですから、SQLの知識は必須であるといって差し障りはないはずです。
そもそも、データの分析は上流の重要な職域です。SQLが分からなければ実務的にデータの分析はできないわけで、上記の話のようなことをPowerPointで水増しした資料でしゃべれば「上流（コンサル）」、ではないはずです。
ERPパッケージ入れているからいい？ う～ん……それがプロなんですかね？
次回は、「そんなやり方では工事進行基準に適応できない」などのご意見を頂いたので、それについて書きたいと思います。
コメント
インドリ
とっても理解できる内容です。
私の場合は全て丸投げされて仕様書から作っていたのでとても苦労しました。
実際問題、無知な上流は邪魔以外の何者でもなく、エンドユーザーから直接聞いたほうが道考えてもいいんですよね・・・
私は完全御用聞きの方が好きでした。
よくできるといわれている人が、上の方で余計なことを決めて来ると、ひっくり返すのは本当に大変だったり、不可能だったりしますからね。
だったら、居てるだけで何もしない方がマシって思ってたこともありましたね。
とにかく、技術を全く持ってないのに、技術者を名乗るのはやめて欲しいです。
ビガー
ビガーです。
データの分析の話を書かれていますが、前に私がコメントした静的構造を
顕にする際に必要なアクションと思われます。
静的構造を顕にする目的は、業務の普遍的な概念を見える化して将来的な
業務内容の変更や要望に柔軟に対応することです。
この普遍的な概念とは業務上の制約やルールなどを指しています。
これに加えて、業務フローや業務アクティビティ(ユースケース)の動的な側面を
詰めて本当に必要な機能や将来性を見極めていく感じです、私は。
そもそも生島さんの定義されている上流というのがお客様の全体的な業務像を
抑えず、部分最適なソリューションに見受けられるからシックリこない気がしますが、
実際には全体的な業務像を抑えられるスキルがある技術者は希少なのは確かですね。
私が思うにやはりこのフェーズでSQLは必要ないと思います。
静的構造分析の成果物である概念モデルや論理ERDのエンティティへの
CRUD程度は意識しておいてもいいでしょうが、物理ERDのエンティティのどの属性を
どう扱うかはやはり設計フェーズ以降になると考えるためです。
→生島さんの云う上流が設計フェーズの基本段階にあたると考えるとシックリくる
気がします。そのフェーズであればSQLは熟知しておく必要はあると思います。
※きっちりフェーズ定義をしたいわけではなく、業務視点/システム視点は分離した
ほうが 結果的に無駄なものを作らず済んだり、フェーズ毎に考えると考える範囲を
限定しやすいので生産性を上げやすいと考えています)
ちょっと前に実装含めて関わったFXなどの証券系システムでもRDBMSを使用しますが、
OLTPが基本なのでバッチ時間(10分以内/日程度までに完了させる必要あり)は
非常に限られますし、インメモリで処理させないと現実的な性能を担保することは
大変難しい(ほぼムリ)です。
マルチスレッドの有効活用や高性能ミドルの採用などでこのあたりを実現しましたが、
ちなみに生島さんなら上記をSQL(でなくてもいいけど)でどう解決されますか？
※無論上記ではCRUDするエンティティのデータ量やエンティティの関連を加味して
最適化(RDBMSのオプティマイザのお気に召すように)したSQLを実装していることが
前提です。
ビガーさん、ども。
申し訳ないですが、個別の話は書きようがないです。
ただ、上流が一言、不用意なことを言っただけで、下流の方針は非常に大きく変わります。
それこそバッチでやりますと言って調整を始めたら、オンラインには変えれませんが、SQLが分からずに、何をもって「バッチでやります」と言ってるのか？
ということです。
> ちょっと前に実装含めて関わったFXなどの証券系システムでもRDBMSを使用しますが、
> OLTPが基本なのでバッチ時間(10分以内/日程度までに完了させる必要あり)は
> 非常に限られますし、インメモリで処理させないと現実的な性能を担保することは
>大変難しい(ほぼムリ)です。
これだけで、ほぼムリと言われても何とも言えませんけれど、できなくても良いと言っている人の「ムリ」は「スキルがないから」というオチとしか言いようがないですよね。
次の記事に書きましたが、SQLで処理しようが、他で処理しようが、DBがアクセスするデータ量は、処理に必要なデータ量です（当たり前ですね）
SQLで処理しないで他で処理すると、DB内での四則演算と演算に必要なソートが減り、SQLの実行回数とデータ転送が増えます。
四則演算 ＋ 演算に必要なソート ＞ SQLの実行回数 ＋ データ転送
スケーラビリティ云々いわれる方は、パフォーマンスは気にしないらしいですけど、バッチ時間（パフォーマンス）が要件にあるなら、上の不等式は物理的に絶対に成り立ちませんよ。
ただし、これは
四則演算 ＋ 演算に必要なソート ＋ SQLが下手糞
＞ SQLの実行回数 ＋ データ転送
となったとき、下手糞具合によって成り立ちます。
インドリ
>とにかく、技術を全く持ってないのに、技術者を名乗るのはやめて欲しいです。
同感です。
本当にこの業界には胡散臭い人が多いですよね。
しかも働かず上前だけはねる人が何と多い事か・・・
話しは変りますが、ビガーさんの例については尚更上流人が技術者であるべきですね。
というのも、その様なトランザクション重視処理はかなり技術力を必要とします。
SQLぐらい知らない人がどうしてDBのトランザクション処理について知っているのでしょうか？
証券システムでは非常にシビアな分散処理（規模はWAN）システムです。
インメモリでデータを処理する際こそ設計力が必要です。
何故ならば計画的なデータ配置が必要とされているからです。
あとネットワーク設計も非常に重要となります。
SQLも知らない人がこの様な高度なシステムを設計できるのでしょうか？
この系のシステムの場合、ネットワーク・データベース・セキュリティ・ソフトウェア工学は踏まえて欲しいものです。
そもそも、技術力がない時点で式を採るのは馬鹿げていると私は思います。
素人が指揮を振る事もあるこの業界は異常です。
インドリ
それにしても、SQLを知らずとしてデータベースエンジニアリングをちゃんと学んだという人はありえるのでしょうか？
データベースを学ぶ時、自然とSQLも同時に学ぶ事になる筈です。
なので、SQLを学んでいないという事は、データベースエンジニアリングを学んでいないといっても過言じゃないと思います。
生島さんが言っているのはそういうことですよね？
インドリさん、ども。
そのとおりですね。
SQLをちゃんと（チューニングがスラスラできるレベル）分かってない人は、データベースエンジニアリングは分かってないでしょうね。
証券などのシステムで、分かってない人が上流は丸投げするのでしょうけれど、丸投げする前に顧客に話していたことが、前提条件になってしまって、手かせ、足かせをはめられてしまうのですよ。
明後日の方向の話をしてますから。
それが非常に迷惑なのですけれど、言った本人は全く気づいていない（笑）
そこまで撒き戻して責任を問われることがないから、気づくことはない。
これは断言していいと思います。
それで、仕方なく私は毒づいているのです。
証券などのシステム任してもらえないかな（笑）
大手の見積を見せていただけたら、無条件で半額でやります。
楽天証券で60億とか言ってますからね、インドリさん1年1億でどないでしょう（笑）
インドリ
いやぁーそれいいですね。
1年1億円で思う存分挑戦出来るシステムを作るなんて技術者の夢です。
証券システムは聞くところによると、データの信頼性が求められる上に、生データが重要となるから古いデータ捨てても良いという特異な世界らしいです。
というのも、その瞬間の価格が知りたいから1秒前のデータは捨ててもいいとのことです。
※ただしこれは、データマイニングしない時の話しですがｗ
しかも兎に角早く処理しなければならない。
スループットを最大化するために、極限までシステム全体のスピードが求められる。
そうなると、ディスクI/O、OSのページヒット率、回線効率、待ち時間・・・全ての知識が求められます。
嗚呼、もう楽しすぎます。
想像しただけで興奮しちゃいます（笑）
インドリさん、ども。
おっしゃるとおり、証券会社（例えば株取引）では、株式取引所からのデータ（株価）は、保存しておく必要はないはすです。
長期保存するのは、日別の、始値、最高値、最低値、終値があれば良いでしょう。
リアルの株価は、自社（証券会社）の取引だけ意味がないので、取引所のデータに頼るしかありません。
そして、顧客ごとに評価差損益をいろんなタイミングで表示する必要があるのでしょうが、その処理をDBでするか、APサーバでするかという問題になるのでしょう。
APサーバはリクエストをこなすだけで目一杯でしょうから、APサーバで処理させるのは、とんでもなくエコじゃないですね。
証券会社のサーバの処理は小さくないけれど、それほど大きくもないです。
楽天証券で60億って…ねぇ…。
もし、大きな案件が取れたら声を掛けさせていただきます（笑）
次の記事でも全SIerにケンカ売ってるので、弊社に大きな案件が回ってくることは残念ながらありません。
そうでなくても、そんな案件は回ってきません。
ビガー
ビガーです。
私の言いたかったことは、アプリケーションがDBに永続化したデータを
欲しい場合は意外と少ないということです。
現状RDBMSを前提としたシステムが当たり前となった本質は、
エンドユーザが業務をより良くするためにデータを分析して次の業務改善の
糸口にすること、永続化したデータを最も効率よく管理できることにあり、
枯れた技術となったことも加味され評価されているように思います。
私は私の云う上流の仕事を直接することは少ないですが、上流の方に
スキル不足が否めないならそれを補完してあげられるスキルと謙虚さがないと
エンジニアの成長は頭打ちになる気がします。
技術的な観点では噛み合わないところは多いですが、私も個人でやっているので
業界構造に対する想いはインドリさんや生島さんに賛同するところは結構ありますね。
> 私の言いたかったことは、アプリケーションがDBに永続化したデータを
> 欲しい場合は意外と少ないということです。
これはよく判りませんが、さすがに補完してきましたよ、俺様社長なので謙虚とは言いがたいけれど（笑）
でないと、小さいベンチャーなんてあっという間に倒産です。
ビガー
ビガーです。
要するにデータ主導の考え方ではなく、業務(ユースケース)主導で
あるべきで、DBにあるデータが常にプライマリであるような考え方では
真にユーザが求めるものは作れないのではないかということです。
今までの歴史的にプロセス(処理)中心、データ中心、業務(オブジェクト)中心と
遷移してきた歴史的背景を鑑みると自然な流れな気がします。
失礼ですが、生島さんはデータ中心で止まっている感じですね。
う～ん、どうなのでしょうね。
技術者とはかみ合わないことが多いのですが、エンドユーザとは大概かみ合いますけど。
そもそも、恥ずかしながら、プロセス(処理)中心、データ中心、業務(オブジェクト)中心とか、意識したことがないです。
お客様中心でしょう。
早く、安く、速く、お客様がやりたいことを実現できればそれでOKです。
「SQLが好きだから」とか誤解されるのですけれど、効率を求めたらそうなっただけで、パフォーマンスも、開発工数も、保守性も、ランニングコストも、スケーラビリティも上がるから、他を選ぶ必要はないでしょうということです。