富士通のプリンタは，連続帳票とインサータ（紙送り）単票の操作が若干複雑でした。このプリンタでも，Yさんの富士通への要求は厳しかった。外資系プリンタ会社も入れての交渉です。結局，富士通はYさんの要望を飲んだのです。トヨタ・スーパーディーラの世界初のオンラインシステムですから，富士通も真剣勝負でした。

　オンラインシステム開発のプロジェクト・リーダーだったYさんは，今で言うCIO（最高情報責任者）です。徹底的にITベンダーに要求します。ただし，相当厳しいことは言っても，不可能なことは言いません。ですから富士通も真面目に対応していました。

　大成建設のCIOである木内さんもサントリーのCIOである酒井さんも，IT出身ではありません。でも，だからこそ，短納期開発を企業の生命線と考えており，要求は厳しかった。ITベンダーに厳しいだけでなく，自らも様々な方法論を研究し，試行・実行されています。真のQCD（クオリティ，コスト，デリバリー）アップの鍵は，「人月の神話」の排除です。人海戦術での生産性向上は，高々2～3割です。2～3倍の向上には全く新しい思想が必要になります。ほとんどの先進ユーザーは，日本の甘～い平均的なITベンダーを相手にしていません。


Yさんは我々を技術に走らせなかった

　ユーザーの問題に関して技術的側面からITソリューションを提案するのは，How型のテクノロジードリブンSEの仕事です。販売店サービス業務のオンラインシステムを構築していた当時は，使える技術も未熟でしたから，テクノロジードリブンSEの活躍の場は広大だったのです。DBMSも無く，ファイルはISAMです。リカバリも手作りです。OLTPやミドルやツールが充実した今とは雲泥の差でした。

　今のテクノロジードリブンSEは，ツールやメソッドの使い手に安住していませんか？高機能なツールを組み合わせ，問題解決に適用しているんでしょうか？ 問題とは経営ニーズもあるし，（現場の）ユーザーニーズもあるし，ニーズをシステム要件化したものもある。さらに，それらをブレークダウンした設計情報もあります。問題も階層化されるのです。

　Whatも目的から手段にブレークダウンしてくると，Whyもドンドン言えるようになってきます。何を対象にしてWhyなのかHowなのか？Why型とHow型は，対象に関してのアプローチの違いに過ぎません。

　元富士通のAさんは業務要件に対してはWhy型ではなくHow型です。しかし，ITソリュ－ションに関しては完璧なWhy型です。Aさんはプロジェクト会議の要求工程ではほとんど発言がなかったのですが，設計工程では物凄いアイデアを出してきました。Aさんからのメールでは，AさんがITソリューションに関してWhy型であることを示す，以下のような文章がありました。

　SEの役割は，要件を満たす機能が今検討している内容で本当に良いのか（その機能が本当に必要のものかどうか），その機能を満足する処理ロジックが出来るか，設計する（した）内容に整合性が保たれているかどうか等のチェックができることだと思います。

　Aさんは，富士通の有名な課長試験の意義を全く認めなかった人でもあります。徹底的にお客に尽くすところに，SEとしての生甲斐を感じていた人です。今でも同じです。そんなSEは今，どれほどいるんでしょうか？Aさんの後輩SEも素晴らしい人達が一杯いました。

　その頃の富士通SEは，一騎当千の梁山泊だったのです。IBMと違ってユーザーの中に入り込んで，ガムシャラだったのです。そんな野武士のような富士通が変わっていったのです。まさにビューロクラシー制度の弊害を絵に書いたように。

　現場業務の自動化や省力化のような部分最適なシステムは，問題（要件）＜ 解決（IT化）でした。しかし，全体最適な全社に及ぶシステムは，不等号が逆転して「要件＞IT」です。テクノロジーもブラックボックス化されたモジュールやツールをうまく使う技術であり，要望や要求をシステム要件化する要求定義に価値が移って来ています。しかし現実には，“要求を言えないユーザー”と“構築専門屋”との間に凄まじく大きな谷が広がってしまったのです。