中堅企業が物流システムで競争力を向上するための導入方式とは！？｜オープンソースの倉庫管理システム(WMS)【インターストック】

中堅企業が物流システムで競争力を向上するための導入方式とは！？

画像素材： metamorworks / PIXTA

 

＜目次＞
１．業務システムはウォーターフォール型が採用されてきた
２．顧客サービスに直結する物流システム
３．「アジャイル型」は物流システム開発の救世主となるか？
４．セミスクラッチ型による物流システム導入
５．まとめ

 

●１．業務システムはウォーターフォール型が採用されてきた

 

WMS(倉庫管理システム)やIMS(在庫管理システム)のような日常業務で利用されるシステムのことを一般的に「業務システム」と言います。
これまで業務システムの多くはウォーターフォール型によって開発が行われてきました。
ウォーターフォール型による開発では、大きく「設計」・「開発」・「導入」の順で作業が行われ、基本的にこのサイクルは一回しか回りません。

 

 

ここで少し捕捉ですが、「要件定義」は人によって意味が異なる場合があるため注意が必要です。
具体的には「要求」・「要件」・「仕様」によって意味合いが違ってきますので、そこをはっきりさせなければならないのです。

「要求」とは、「こうしたい、こうありたい」というユーザー側の希望のことです。
そして、ユーザーの要求を実現するための条件が「要件」になります。
最後に要件を満たすための詳細な条件として「仕様」を決めていきます。

例えば、複数倉庫の在庫を一元管理したいというのが「要求」であれば、まず最初にその為に必要な条件を整理します。
「倉庫マスタの登録が必要」、「倉庫毎にロケーションの設定が必要」、「ハンディターミナルで倉庫コードの設定が必要」といった要求を満たすための必須条件が「要件」になります。

さらにこのような要件に対して、倉庫マスタの登録画面の設計や機能、操作を詳細に決めていく作業が「仕様」です。

話を元に戻しますが、ウォーターフォール型の欠点は上記フローのサイクルが1回しか回らないことです。
皆さんも経験があるかと思いますが、要件定義、詳細設計が終わって、途中の動作レビューやテストの段階で機能的に不足や不都合があった場合は、基本的には全て「仕様変更」として扱われます。

仕様変更となれば、別途工数の算出から始まり、見積もり、スケジュールの見直しとプロジェクト全体の予算とスケジュールに大きなインパクトを与えることになります。
そうなると、出来るだけ当初の仕様は崩さないようにといった雰囲気になり、現場側で使い難い部分や手間が増える部分は、よほどの業務上の不都合が発生しない限りはそのまま納品され、そのまま利用されることになります。

 

●２．顧客サービスに直結する物流システム

 

物流システムについても、他の業務システム同様に長年ウォーターフォール型で開発が進められていました。
しかし、近年の物流ニーズの高まりや多様化によって、ウォーターフォール型での開発ではユーザーを満足させることが難しくなってきました。

物流は顧客サービスに直結する領域であるため、自社の強みをIT化する必要があります。
また、物流ニーズの変化は激しく、仕様変更や機能の追加、修正に素早く対応する必要があるのです。
しかし、「設計」・「開発」・「導入」のサイクルが一回しか回らないウォーターフォール型による開発では、こうした変化にスピーディに対応することが不可能なのです。

そのような理由からか、アマゾンやアスクルやビックカメラなど、物流を差別化することで強固なビジネスモデルを構築している企業は漏れなく物流システムは内製化してアジャイルに近い開発方式を採用しています。

 

●３．「アジャイル型」は物流システム開発の救世主となるか？

 

長らくシステム開発の救世主として期待されてきた「アジャイル型」による開発は様々な現場で試され、アーリーアダプター(早期採用者)のフェーズは終わり、マジョリティ(多数派)へと移行しているように感じます。
アジャイル型の開発では、小さな単位で開発を行い、リリースと改良を繰り返します。
比較的シンプルな機能だけをリリースして、そこから随時機能を付け加えていきます。

ユーザーに利用してもらいながら、次のリリース計画を決め、また少しの機能を付け加えた次のバージョンを開発します。
ユーザーからフィードバックされた課題は、将来のどこかのリリースで解決します。

アジャイル型の一番のメリットは、一度に全部開発するのに比べて、ユーザーからのフィードバックをシステムに反映しやすい点です。
使いにくい部分や機能的な不都合が次回以降のリリースで改善され、どんどん良いシステムにバージョンアップされていきます。

このようにアジャイル型の開発はウォーターフォール型に比べて、不確実性に向き合う為のアプローチであると言えます。
“早く少しだけ作る”を繰り返すことで、ユーザーの仕様変更、あいまいな仕様、作業の不確定性といったリスクが解消されるのです。
しかしアジャイル型開発でも混乱が生じます。

作るべきものの決め方の混乱、合意形成についての認識の違い、いつになったら出来るのだろうという関係者の不安などです。
アジャイル開発によるプロジェクトについて、色々と調査してみると不確実性に向き合うためのアプローチであったはずのアジャイル型が逆にプロジェクト自体を不確実性の高いものにしてしまい、混乱が生じたケースも少なくないようです。

また物流システムは新規で事業を起こした場合でない限りは、既に現場オペレーションが決まった形で運用されており、そこにシステムを乗せていくので、完全なるアジャイル型だと逆に多くの不効率を生んでしまいます。

筆者の感覚値ですが、物流システムの場合、「汎用的な機能」・「既に決まっていること」が全体の7割を占め、「これから決めること」や「不確実性の高い要素」が3割程度です。
つまりこのようなシステムを構築するには完全なるアジャイル型では満足できないということになります。

 

 

では、ユーザーが満足する物流システムを構築するにはどのような方法があるのでしょうか。

 

●４．セミスクラッチ型による物流システム導入

 

物流システムは、どこの企業でも共通の「汎用的な機能」が全体の5割を占めるケースがほとんどです。
このような業務システムをゼロから構築するのはもったいない話です。
すでにそうした汎用的な機能がソース提供されれば、多くの企業がその恩恵に授かれます。

ユーザー企業の「既にきまっている」個別ニーズは「汎用的な機能」にカスタマイズを加えることで対応します。
この部分のカスタマイズについては、ウォーターフォール型に近い形で要件定義・設計・導入の手順を踏みます。

そして、これから決めること、今後どうなるか分からない「不確実性の高い要素」については、アジャイル型を採用します。
オープンソースの環境でウォーターフォール型とアジャイル型を上手く融合させて、将来的な内製化も支援する新たな導入方式が弊社が提唱する「セミスクラッチ型」です。

 

 

セミスクラッチ型の開発では、まず「汎用的な機能」をパッケージとしてオープンソースで提供し、契約前の試用段階でどうしても必要な「すでに決まっていること」を最小機能でプロトタイプ作成します。
これによって、パッケージでありながら、自社のある程度自社運用に合わせた形でシステムを試用することが可能になります。

プロトタイプ作成フェーズでは、詳細な仕様を決定して、ウォータフォール型でシステムの試用に必要な必要最低限の機能をリリースし、早い段階でシステムを評価します。

次に「これから決めること」、「不確実性の高い要素」については、アジャイル型で”早く少しだけ”形にしながら、随時機能アップを行います。
弊社の「セミスクラッチ型」サービスの場合、この部分の追加費用は当初のプロジェクト予算の中で消化するようにしています。

そうすることで、プロジェクト全体の進行がスムーズになり、システム改善への抵抗も少なくなるため、より良いシステム構築が行えるのです。

システム納品後はソースとデータベースを全公開し、社内に情報システム部門が存在する企業については、内製化の支援も行います。
パッケージベンダーと自社のどちらでもシステムをメンテナンスできる体制を構築することで、従来のベンダーが主導権を握ることによる様々なリスクを解消します。

 

 

●５．まとめ

 

筆者の長年の物流システムづくりの経験は常に不確実性と向き合うことの連続でした。
都度、人々の知恵を積み重ね、多様な人々との関わりのなかで多くのことを学んできました。

その学びの中で物流システム導入に大切なことに気付くことが出来ました。
それは、型通りにやることではなく、「物流システムというのは現場の作業者が毎日利用するものだ」という前提において、バージョンアップのためのサイクルをスピーディに繰り返せる体制を構築することです。

強い企業は、このサイクルがいつでもどんなときでも繰り返されるようにして、自社が主導権を握って物流システムをアジャイルでどんどんバージョンアップさせています。
アマゾンのような企業もアジャイルで作りまくって、現場で試して、良い機能をどんどん残していると聞いたことがあります。
この流れに乗れない企業はいずれ競争力を失うことになるでしょう。

物流システムの不確実性を招くのは現場や顧客ニーズの多様性に要因があります。
つまり多様性は不確実性を高める要素となり、その不確実性に適応する術を持っているかどうかが企業の競争力になるのです。

今回ご紹介した「セミスクラッチ型」の物流システム導入方式は筆者のこれまでの物流システムづくりの実践の中で必然的、自然的に生まれたものです。
筆者自身、多くの企業の物流システムづくりに携わる中で、多くの失敗を経験してきました。
セミスクラッチ型の導入方式は筆者と弊社にとって、守破離の「破」から「離」へと差し掛かる挑戦でもあります。