自動車メーカーの系列ディーラにおける中古車の仕入れルートは,新車販売時の車の下取りです。中古車の状態は1台ごとに違いますから,価格は一物一価となります。中古車の営業マンは,それぞれの中古車の状態を知るために査定書を見たいと言います。担当役員もそれは良いと言います。経営も現場も擦り合わせバッチリ!で,システム要件は固まりました。

 しかし,これからがソリューションです。

 査定書の公開は簡単です。でも中古車の営業マンが欲しいのは,膨大な査定書すべての公開ではなく,特定の条件を満たす個別の車両についての査定書です。営業マンはお客から「こういう車が欲しい」という要望を受けており,見込み顧客のユーザベースを持っています。ピンポイントで「あのお客が欲しがっていたのはこの車だ」とマッチングできたら,市場平均価格よりも高く売れる可能性が出てきます。そうなれば,通常の下取り価格にいくらかプラスすることができます。新車セールスから見れば,「下取り価格をプラスできる=値引幅をプラスできる」ということになります。

 中古車のような一物一価のプライスは需給関係で決まります。ITが仲介することで,新車と中古車の営業との新たな連携活動が起き,販拡につながるビジネスプロセスが創造されます。

 最初は入庫処理と査定書の公開だけがユーザーの要求でした。SEにコンサル脳がアドオンしたBE(ビジネスエンジニア)だからこそ,HowとWhyにより要件Whatをブラッシュアップし,IT利用のビジネス・イノベーションを実現できるのです。


部品表マスターの展開で不良在庫を避ける

 SEにコンサル脳がアドオンしたBEのソリューション事例を,もう1つ紹介しましょう。

 在庫管理の基本は,即納率と在庫コストのトレードオフ関係をどうするかです。でも,在庫管理システムを手がけてみると分かるのですが,長期不良在庫の問題が必ず浮かび上がってきます。ユーザーは長期不良在庫には問題があるというだけで,実現可能なアイデアまでは提案できません。御用聞きSEなら「言った通りに作ります」とシレッとするだけで,ユーザーが提案しない課題には手を付けようとしません。

 不良在庫にならないように在庫発注するのは難しい。自動車ディーラの部品在庫を例に取ると,季節用品やモデルチェンジ前の車の部品もあります。共通部品とともに,特定の車だけの部品もあります。ここらは人間では管理不能です。メーカーの部品表マスター情報を参照できれば不良在庫を避けることは可能ですが,ほとんどの自動車メーカーでは部品表マスターとディーラ側システムとの連携は手付かずになっています。

 例外はトヨタ自動車です。同社は設計・開発から販売に至るすべての業務で部品表マスターを展開させています。系列ディーラでは部品表に基づく情報を,TNS(トヨタネットワークシステム)を経由して参照できます。しかも驚く無かれ,今から20年以上の汎用機の時代に,部品サプライヤから販売店に至るTNSの全国ネットワーク網が完成していたのです。

 しかも,トヨタ自動車では団塊の世代が退職する2007年問題を見据えて,部品表データベースを再構築しています。部品表データベースには,黎明期からのSEの暗黙のノウハウが詰まっています。そこで,システムの中身を熟知する彼らが退職する前に,完全改訂してしまったというわけです。


コンサル脳をアドオンすればSEは楽しい職種になる

 マクロ的判断や問題の設定が間違っていたら話になりません。しかし,戦術が戦闘のやり方を決め,戦闘の累積が戦局を決定していきます。前回述べたように,最近の経済学も経済学の根拠である「経済合理性で動く人間」を疑っています。

 その視点で言えば,前回取り上げた以下3つの考え方は,正しいとも間違っているとも言えます。

1.効率化や省力化を目的とするITから戦略や競争優位の源泉としてのITへ
2.ITは聖域だから,ITの専門家に任せておけば良い
3.IT Doesn't Matter

 ビジネス効果の有無で言えば,2は完全に不採用です。ユーザーは要件を完璧には言えませんが,思いや要望や目的をBE(ビジネスエンジニア:コンサル脳がアドオンされたSE)と共有する(What<==>Why)ことはできます。

 要求定義と基本設計(ソリューション)とは行きつ戻りつです。(What<==>How )です。要求定義では語られない暗黙要件を考慮しないと設計はできません。基本設計で要件を叩いた後の要件定義書(ver.0)は恥ずかしいくらいお粗末で曖昧で的外れです。優秀なSEならこんな話は一杯あります。

 コンサル脳をSEにアドオンしたBE(ビジネスエンジニア)になるだけで,SEはもっとプライドを持てる楽しい職種になります。そんなSEを育成するのがトナチャンの役割だと考えています。今後の流れは,プロジェクト・マネジメントの知識体系であるPMBOKからソフトウエアエンジニアリングの知識体系であるSWEBOK(SoftWare Engineering Body Of Knowledge),プロジェクトマネジメントから要求定義(ソリューション設計)への流れです。

 今年はBE元年!です。