データ基盤は作った日が一番動く
—止まる・変わる・増えるへの備え
・稼働後の基盤が劣化していく3つの方向(止まる・変わる・増える)
・WMSのバージョンアップや拠点追加に、どう備えておくのか
・データ量の増加とコストを、運用としてどう設計するか
これは基盤の作りが悪いという意味ではありません。基盤が接している相手——設備、業務システム、拠点、データ量——が変わり続けるからです。作った時点の前提が、時間とともに合わなくなっていきます。
この記事は、物流業界の専門家としてではなく、システムを作って終わりではなく、サービスとして使い続けるにはどう設計するかを考える立場から書いています。作ることと使い続けることは、必要な設計が違います。
1. 稼働後に起きることは、3つの方向に整理できる
基盤が稼働してから起きる問題には、さまざまな原因があります。ここでは、稼働後に特に意識したい変化を、次の3つに整理します。
データが来なくなる
前提が合わなくなる
規模が変わる
この3つは、備え方が違います。順に見ていきます。
2. 止まる——気づけるかどうかがすべて
センサーの故障、通信の切断、電源の抜け、処理そのものの停止。原因は多岐にわたりますが、結果は同じです。データが来なくなります。
第5回で扱ったとおり、この状態はエラーとして現れないことがあります。取り込む対象がなければ処理は正常に終わり、集計も完了します。
止まることを完全に防ぐことはできません。機器は故障し、通信は切れます。したがって設計の焦点は、防止ではなく気づくまでの時間を短くすることに置きます。
ここで第5回との違いを整理しておきます。
| 観点 | 第5回:データの品質 | 本記事:基盤そのもの |
|---|---|---|
| 見るもの | 届いたデータの中身 | 仕組みが動いているかどうか |
| 異常の例 | 欠損、遅延、異常値、不整合 | 処理の停止、監視の停止、容量の枯渇 |
| 問い | この数字は信用できるか | この仕組みは動き続けているか |
2つは重なりますが、同じではありません。データが正常でも仕組みが劣化していることはあり、仕組みが動いていてもデータが間違っていることもあります。両方を見ておく必要があります。
止まったことを検知できたとして、その後どうするかが決まっていないと現場が困ります。
・データが欠けている期間のKPIを、そのまま出すのか、注記を付けるのか
・復旧後に、欠けた期間を遡って取り込み直すのか
・その間、現場は何を見て判断するのか
止まる前提で決めておくべきことは、検知の仕組みだけではありません。
3. 変わる——もっとも予測しにくく、影響が大きい
WMSのバージョンアップで項目が増えた、名称が変わった、コードの桁数が変わった。設備を入れ替えたら出てくるデータの形が変わった。現場の運用が見直されて、作業区分の意味が変わった。
これらは基盤の側では起こしていません。相手側の都合で起きます。そして多くの場合、基盤の担当者は事前に知らされていません。
「変わる」がやっかいなのは、止まるのではなく間違ったまま動き続けることがある点です。
WMSの更新で、それまで分単位で扱っていた値が秒単位で渡されるようになったとします。基盤側の解釈を変更しなければ、データは届き続け、処理も正常に終わり、KPIも表示されます。ただ、算出された作業時間が従来の60分の1になってしまいます。
この種の変化は、エラーにも欠損にもなりません。異常値の監視で「値がおかしい」と気づけるかどうかが分かれ目になります。
備え方は、大きく2つあります。
間違ったまま、動き続けるからです。
もう一つ、設計側で効くのは変更の影響範囲を狭くしておくことです。加工の処理が1本につながっていると、1か所の変更が全体に波及します。データの取り込み、意味をそろえる処理、KPIの算出が分かれていれば、修正はその段だけで済みます。
WMSのバージョンアップも、拠点の追加も、設備の入れ替えも、長く使っていればいずれ発生します。これを例外的な出来事として扱うと、そのたびに対応が場当たり的になります。
年に何回かは変更対応が発生する、という前提で運用の枠を作っておく方が、実際の負荷は下がります。
4. 増える——静かに進み、あるとき問題になる
拠点が増える。センサーが増える。取得頻度を上げる。保持期間が延びる。どれも1回ごとの変化は小さく、そのときは問題になりません。
問題になるのは、積み上がった後です。処理時間が伸びて朝までに終わらなくなる、費用が想定を超える、容量が上限に近づく。ある日を境に、急に問題として現れます。
増加は、3つの面で効いてきます。
| 増えるもの | 直接の影響 | 見落としやすい影響 |
|---|---|---|
| データ量 | 保存の費用、処理にかかる時間 | 過去との比較のために、古いデータを消せない |
| 拠点数 | 取り込み対象の増加 | 拠点ごとの運用差を吸収する変換ルールが増える |
| 利用者数 | 参照の集中 | 用途が増え、必要な処理タイミングが分かれる |
とくに拠点数の増加は、単純な足し算になりません。第4回で扱ったとおり、拠点ごとにコードの付け方や作業区分の運用が違います。拠点が5つになれば、拠点ごとの違いを吸収する変換ルールも増えていきます。
コストは、量と期間の掛け算で増える
クラウドを使う場合、費用は利用量や利用時間などに応じて増えていきます。導入時点では小さく見えても、第7回で触れたとおり、保存の費用は量と期間の掛け算で継続的に効いてきます。
そのため、運用のなかで次のような判断が必要になります。
想定していないから、問題になります。
5. 「使い続けられる基盤」の条件
3つの方向をまとめると、稼働後の基盤に必要なのは次のような性質だと言えます。
逆に言えば、これらが欠けている基盤は、動いているうちは問題なく見えます。問題が現れるのは、最初の変化が起きたときです。
止まったことに気づける、変更の影響が限定される、増加が見込まれている——これらは動作の要件ではなく、運用の要件です。作る時点でここを織り込んでおくかどうかが、数年後の状態を分けます。
ここまでの内容を一度にすべて満たす必要はありません。実務的な優先順位を付けるなら、まず「止まったことに気づける」ところからです。
気づけない状態で運用を続けることが、いちばんリスクが高いためです。気づける状態を作ってから、変更対応の枠、コストの見直しの周期、という順に整えていく方が現実的です。
まとめ:基盤の価値は、使い続けられて初めて出る
データ基盤は、作った日が一番よく動きます。そこから先は、接している相手が変わり続けるため、放っておくと合わなくなっていきます。止まる、変わる、増える。この3つは避けられません。
避けられないなら、備える対象にできます。止まったら気づける。変わったら分かる。増えたら見直す。この3つが運用に入っていれば、基盤は使い続けられます。
使い続けることのゴールは「変化に対応できること」。
次回はシリーズの最終回です。ここまで、つなぐ・関連付ける・品質を保つ・処理する・蓄積する・運用するという要素を順に扱ってきました。最終回では、それらが現場の改善に変わるまでを一本の線としてつなぎます。基盤の完成がゴールではない、という話です。
止まったことに気づけるか、WMSの更新や拠点追加にどう備えるか、データ量の増加をコストとしてどう見込むか——使い続けるための設計は、作る段階で織り込んでおく方が負担が小さくなります。現状の運用体制を前提に、どこから整えるべきかを整理するところからご一緒できます。
「動いてはいるが、この先が心配」という段階からでもご相談いただけます。
お問い合わせはこちら