物流システムを「外注」するときに中堅企業の経営者が知っておきたいこと｜オープンソースの倉庫管理システム(WMS)【インターストック】

物流システムを「外注」するときに中堅企業の経営者が知っておきたいこと

画像素材： EKAKI / PIXTA

 

＜目次＞
１．減らないシステム開発をめぐる訴訟
２．知っておきたいユーザーに求められる「協力義務」
３．システム開発に絶対不可欠なこと
４．まとめ

 

●１．減らないシステム開発をめぐる訴訟

 

現在、私たちは個人生活のレベルにおいても、企業活動のレベルにおいても、システムに大きく依存しています。
ひとたびシステムトラブルが発生した場合に私たちの生活に与える影響は日増しに強くなっており、システムに期待する機能や品質も高まる一方です。
システム依存が高まる一方で、ITに関する技術も日々進歩しています。

しかし、いくら技術が進歩しても、システム開発をめぐる発注者とベンダーのトラブルは一向に減る気配がありません。

発注者側からすると、システム開発プロジェクトの失敗はベンダー側に否があると考える場合が殆どです。
しかし、最近の訴訟問題を調べてみると、意外とベンダー側が勝訴しているケースも多いのです。
理不尽に思われるかもしれませんが、逆に発注者側がベンダー側に対して損害賠償を支払いしている判例もあります。

最近では国内ERPパッケージの最大手の企業が数十億円の訴訟を発注側企業から起こされて業界ではちょっとした話題となりました。
発注者側の主張は「稼働が遅れ、実施したテストではシステムが動作せず、追加開発も膨大になった」というものでした。
一方でベンダー側の主張は「システム稼働が遅れたのは際限のない仕様変更があった」というものです。

 

 

昨今の物流システムは、その企業独自のビジネスモデルや業務プロセスに深く関係し、顧客サービスに直結します。
ですから物流システム開発はベンダーが主導権を握るのではなく、発注者側が主導権を握って、ベンダー企業と協業してシステム開発に取り組む時代なのです。

もし、経営者であるあなたが「システムのことは分からないから、ベンダーさんに全てお任せします」という姿勢であれば、物流で差別化する時代に乗り遅れ競争力を失う選択をしたことになります。

本稿は、自分の会社にこれから物流システムを導入しようとしている経営者やプロジェクトマネージャーに向けて発注者目線で物流システム開発プロジェクト成功のポイントを考察してみたいと思います。

 

●２．知っておきたいユーザーに求められる「協力義務」

 

システム開発における発注者とは「お客様」ではなく、明確な役割と責任を持った「プロジェクトメンバー」であるということです。
これを「協力義務」といいます。
先の例で発注者側がベンダー側に損害賠償を逆請求された判例などは、まさにこの「協力義務」を怠ったことが要因です。
発注者側が「お客様」でベンダーが「外注業者」という認識では、プロジェクトを円滑に進めることは困難です。

プロジェクト中に発生するさまざまな問題に対して、ベンダーと一緒に対応したり、ベンダーの作成したシステムをテストするなど、発注者にも沢山の役割と責任があるのです。
多額のお金を支払う側の発注側からすれば納得出来ないかもしれませんが、システム開発において、発注者とベンダーは完全に対等な関係であり、プロジェクトメンバーなのです。

 

 

●３．システム開発に絶対不可欠なこと

 

「システム開発の成功を判断する重要な要素は？」と問われると、おそらく多くの人が「品質」・「コスト」・「納期」と答えるのではないでしょうか。
どれも正しいと思いますが、筆者の考える最も重要なものは「ビジネスの成長に対する貢献度」です。
いくら高品質に仕様書通りに開発されていても、現場がそれを使わなければ意味がありません。
どんなにコストを抑えて短納期でローンチされたとしても、全体最適の視点から業務の課題に対して解決がされていなければ、何の意味もないのです。

しかし、日本企業の多くは発注者側もベンダー側もこの3つを重視するあまり、ガチガチに固められた設計書、隙間のない開発スケジュールに縛られて、効果性の低いシステムを導入してきました。
システム開発者の間でよく読まれている本にこんなことが書かれてありました。

「”品質を作り込む”ことこそが、最終的にコスト削減、納期短縮につながる」

まさにその通りで、事実ではあるのですが、システム開発は品質が全てではありません。
確かに人命を預かるような医療システムや、膨大な額のお金を管理する金融システムには最高品質が求められます。
では物流システムはどうでしょう？

顧客サービスに直結し、差別化戦略の中枢となった現代の物流において求められるのは革新性です。
ベンダーのもとにも、「斬新なアイディアはないのか」、「最新のテクノロジーの提案が欲しい」といった要求が向けられています。

決められたものを決められたルールで反復することで品質というのは担保されます。
つまり、全く新しいテクノロジーをこれまでにない新しいやり方でイノベーションするときに、品質が優先されるとそこには大きな矛盾が生まれるのです。

今から導入する物流システムを自社のビジネスに大きく貢献させるために絶対不可欠な作業が「要件定義」です。

社内全体の業務を俯瞰して、全体最適の視点から、業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどを整理する作業です。

物流システムを刷新することで、倉庫オペレーションがどれだけ効率化されるのか、顧客に対してどのようなメリットが生まれるのか、インプットされた情報を分析することで、マーケティングや経営にどのように活かせるのか、それがどれだけのインパクトを経営に与えるのか。

要件を整理しながら関係者全員でこういった点を確認し、経営者も一緒になって業務フローを作成することが大切です。
経営者を含めた関係者全員が「開発コンセプト」を共有化することが重要なのです。
経営者の経営方針から物流戦略に落とし込み、現状の問題点の改善や将来構想およびマクロ的な採算性の検討を行い、開発目標とこれから開発するシステムスケールを明確にします。

その上でどんなシステムを作りたいのか、つまり、「どんな機能や性能を持つシステムを作るか」というコンセプトを決めてベンダーに伝えるのは発注者の重要な役割であり、中堅クラスの企業であれば、経営者自らがその役割を担う必要があると筆者は考えています。

 

 

●４．まとめ

 

物流システムを提供するベンダー側の立場の筆者が、「発注者とベンダーは対等な関係だ」と言うと生意気なやつだと思われるかもしれませんが、ベンダー側とすれば、自らの知見と技術で開発したシステムを導入することで、発注者が支払った額以上のメリットを与えることを目標にして仕事をしています。
ですから、その目標を達成するために対等な関係が必要であることを皆さんには是非知って頂きたいのです。

「ビジネスの成長に貢献するシステム」というのは、言い換えれば「会社に関わる人を幸せにするシステム」であると言えます。

日本のシステム開発プロジェクトの成功率は3割と言われています。
なぜこのように成功率が低いかを考えてみたときに、原因が全てベンダーにあるとは決して思えません。
会社を幸せにして、評価され、感謝される物流システムを開発するには、発注側とベンダーの対等な関係をベースにしたチームワークが欠かせないのです。