いまから12年ほど前の昔話ですが、ふたつの IT案件のプロジェクトマネジメントを掛け持ちしました。
ともに小売業の SCMシステム を構築する案件です。
ひとつ目のプロジェクトのお客様は、無店舗販売の会社です。
そのお客様は、ターゲットとなる企業の健康保険組合や労働組合などを通して、社員向けにシーズンの商品カタログを配布します。社員はカタログから買いたい商品を選び注文します。その際、商品の配送先を会社にすることも、自宅にすることもできます。もし、注文した商品が品切れになったり、納期に間に合わない場合は、オペレーターが注文者とやり取りをして、代替品を提供するか、キャンセルするかの調整します。
無店舗販売のシステムでは、動いている製品の在庫管理がポイントです。製品在庫は、自社倉庫だけにあるわけではありません。仕入先や配送センターにも存在します。製品はトラックなどの輸送途上にあったり、梱包により製品の保管場所が移動します。仕入先から最終消費者へと、適切な期間内で、正しいモノを正しい数量、届けられるよう在庫情報を管理できることが求められます。
お客様から 無店舗販売の SCMシステム の導入を相談されたとき、わたしはアーキテクチャーをどう提案するか悩みました。
わたしは それまでSAPシステムの導入や保守に携わっていました。SAPは大企業を相手にしたERPパッケージです。そのお客様の事業規模で、SAP を導入することは予算的に無理です。また、会社の組合を経由した消費者への販売という、やや特殊な流通形態ゆえ、市販のパッケージソフトで適切なものが見当たりませんでした。
わたしは、パッケージの導入ではなく、フルスクラッチによる開発を提案しました。Windowsのサーバー製品群や、VB.NETなどのMicrosoft系のアーキテクチャーであれば、わたしも知見があるので、プロマネしながら設計にも携わろうと考えました。
こうして、わたしを含めた5名のエンジニアで、開発プロジェクトＡが発足しました。
プロジェクトＡを進行しているとき、別なベンダーから相談を受けました。
そのベンダーは中堅・中小企業を相手に商売をしてます。元々は、POSレジなどの IT機器 を販売する会社ですが、業務パッケージの導入を手掛けることで、ハードベンダーからソフトベンダーに転換することを目論んでました。
ただ、そのベンダーが販売する、業務パッケージは、外資系の製品なのですが、日本での導入実績はほとんどありませんでした。
わたしは、パッケージ導入の見込み客となった小売業に対するプロジェクトマネジメントをして欲しいと相談を受けました。
わたしは、実績のないパッケージを導入することに、リスクを感じました。しかし、プロジェクトが成功すれば、自社でも、そのパッケージを担いで顧客開拓ができるかもしれないと、期待を持ちました。
また、見込み客の小売業は、会社規模は大きくありませんが、根強い人気のある独自ブランドのアパレル商材を持っています。直営店舗による販売がメインですが、複数のECサイトやカタログによる販売もしています。また、イベント会場への出店を盛んに行うことで、短期間に在庫をさばいてました。直営店舗にはブランドのコンセプトを継承したカフェが併設され、その空間は魅力的です（ちなみに今でもカフェは存在し、食べログの評価もかなり高いです）。
わたしはパッケージに対する将来の期待と、魅力的なお客様企業の業態に惹かれました。
結局、プロジェクトメンバーとして自社の若手エンジニアを２名参画させて、開発経験を積ませることを条件として、相談を頂いたベンダーに、プロジェクトマネジメントの役割を引き受けました。
こうして開発プロジェクトＢが発足しました。
プロジェクトＡとプロジェクトＢは、同じ時期にプロマネとして参画しましたが、ふたつのプロジェクトの成果は大きく異なりました。
プロジェクトＡは、Microsoft系のアーキテクチャーという明瞭で、技術的知見のあるスクラッチ開発を行ったため、ほぼ失敗がありませんでした。プロジェクトの予算内で導入に成功しました。スクラッチ開発は人件費がかかるので、開発工程での大きな利益は望めませんが、導入後の保守案件も受注したことで、その後の安定した事業収益に貢献しました。
プロジェクトＡは、小さな成功といえます。
対して、プロジェクトＢは炎上しました。
この要因は導入実績のないパッケージの機能調査に工数がかかったのと、パッケージの標準機能ではお客様の業務要件を満たすことが出来ず、想定外の周辺開発をしたことによる予算オーバーです。
お客様の販売形態を情報システムで実現するには、消費者の注文により商品を引き当てする在庫の単位と、発注や金額評価に関わる在庫の単位を分ける必要があります。しかし、パッケージには階層的な在庫の単位を持つ機能がありませんでした。そのため、パッケージの保有する独自のデータベースから、周辺開発のために購入した 汎用的な Microsoft SQL Server にデータ連携を行い、外部DBで在庫引き当てや、購買発注量の計算（需要予測による計算と、発注点管理法）の処理を行うように設計しました。
こうした周辺開発の規模が膨らんだことで、プロジェクトＢは、赤字に転落しました。一部はお客様から追加開発の費用を頂いたものの、当初の見積の甘さは拭えず、赤字分はベンダーと痛み分けすることになりました。
ジョブ型雇用を提唱する日本の大手企業では、社員の評価制度の見直しも課題になります。
日本の伝統的な雇用形態とされるメンバーシップ型雇用での人事評価は目標管理制度です。目標管理制度（MBO）は、社員が個人目標を自ら定め、評価者は部下の目標を承認し、その進捗や達成度合いによって成果を評価する仕組みです。
メンバーシップ型雇用は、会社が社員に適した仕事をあてるイメージなので、社員が自ら目標を設定する、目標管理制度との相性がいいのです。
一方、ジョブ型雇用は、専門性重視の採用です。人事評価は専門性に特化して、社員の能力を定量的にはかることが求められます。
そのため、評価制度は目標管理制度からコンピテンシー評価制度へと変わっていきます。コンピテンシー評価制度は、仕事の分野ごとに業務遂行能力が高い社員の行動をモデルとして、個々の社員の成果をはかる仕組みです。
そこでわたしが思うのは、12年前 に担当したプロジェクトＡとプロジェクトＢのプロジェクトマネジメントの評価です。
コンピテンシー評価制度の仕組みだと、小さな成功を達成したプロジェクトＡでは、そこそこの評価を得られると思います。しかし、炎上したプロジェクトＢは間違いなく、プロジェクトマネジメントとして汚点のキャリアとなるでしょう。
もし、あのとき会社がコンピテンシー評価を導入していたら、わたしはリスクの大きなプロジェクトＢのマネジメントは断ったと思います。
そうすると、ジョブ型雇用が浸透すると、社員はリスクのある仕事より、小さくとも確実な成果が期待できる仕事に志向が集中するように思います。
それは日本の会社全体にとってあるべき姿なのかが、気になりました。
