トラックを止めずに12年前の倉庫システムを刷新する

小さな会社で最も危険なソフトウェアは、動いているソフトウェアです。誰もが不満を言う不具合だらけのツールではありません。それはいずれ置き換えられます。危険なのは、誰も好きではないのに全員が頼っている12年もののシステムです。隅のベージュ色のタワーから起動し、チームの半数が採用される前から倉庫を回し続けてきたものです。動いています。ほとんど動かなくなるその日まで。そのとき全員が一斉に、会社全体がそれの上で危うく釣り合っていたことに気づくのです。

これは、そうしたシステムの一つと、それをどう置き換えたかの物語です。クライアントは地域の卸売業者で、数千の商品ライン、倉庫一棟、現場と事務所で約30名です。匿名化し数字も丸めていますが、プロジェクトの形は起きたとおりそのままです。触るのが怖い老朽化したシステムを抱えているなら、まともな刷新が内側からどう見えるかは、おおむねこのようになります。

この物語に英雄的な書き直しはなく、スイッチを切り替えてすべてが新しくなった週末もありません。要点は——それを成功させたものは——劇的なことが何も起きなかったことにあります。トラックは積み込みを続けました。倉庫は足元で地面がずれていることにほとんど気づきませんでした。それがレガシー作業の目標であり、その理由を理解する価値があります。

状況：一人の記憶でつなぎとめられたシステム

倉庫は、とうに去った開発者が2013年頃に作ったカスタムシステムで動いていました。中核の仕事——在庫の追跡、ピッキングリストの印刷、注文の出荷——はこなし、普通の日にはきちんとやっていました。問題は実のところソフトウェア自体ではありません。問題は、それを使い続けるためにその周りに育ったすべてでした。

十年あまりかけて、チームは粘着テープで影のシステムを静かに組み上げていました。ソフトが間違える在庫数のためのスプレッドシート、それを現実と突き合わせる二枚目のスプレッドシート、システムでは表せない品目を倉庫責任者が知らせるためのWhatsAppグループ、そして新人が暗記しなければならない回避策の印刷バインダー。どれも一か所に書き留められてはいませんでした。それらは運用マネージャーの頭の中に存在していました。そこで14年働く、五十代の落ち着いた女性で、機能的には彼女こそがドキュメントでした。

経営者が最初に私たちに電話してきたのは、システムが落ちたからではありません。彼女が2年後に退職したいと表明し、彼が計算して、彼女が去る日には倉庫が実際にどう機能しているかのかなりの部分が彼女と共に外へ出て行ってしまうと気づいたからです。これはどんな技術的故障よりもよくある刷新のきっかけです。システムが壊れることではなく、それをつぎはぎしている人がいつまでもいるわけではないと気づくことなのです。

誰もが気にしなくなっていた症状

最初の二日間をただ倉庫の働きを見て過ごすと、古いシステムのコストは至るところにありました——しかしあまりに当たり前になっていて、誰ももう問題だと指摘しませんでした。在庫の数字は予測可能な幅で間違っていると信じられていたので、大口の注文はどれも「念のため」手作業の実地確認を受けました。新人が戦力になるには何週間もかかりました。仕事の多くが書かれざる口承だったからです。そしてシステムは、もうパッチを当てられないほど古いOSの上で、経営者が密かに「いつ起きてもおかしくないセキュリティ事故だ」と知っていたネットワークの上で動いていました。

• 在庫精度は80%前後を漂っていたため、スタッフは重要なものはすべて手作業で数え直していました——毎日何時間も、静かに。
• ピッキングリストのロジックは現在の倉庫レイアウトに対応できず、ピッカーは画面ではなくバインダーが告げるルートを歩いていました。
• 月末の在庫照合には2名で丸3日近くかかっていました。
• ソフトの管理側を動かせるマシンは1台だけで、それが壊れたら明確な計画は誰も持っていませんでした。
• 2019年に会社が追加したオンライン注文チャネルには何もつながっておらず、それらの注文は手で打ち直されていました。

あえてやらなかったこと

明白な一手——多くのベンダーが売り込むであろう手——は、大きな既製の倉庫管理プラットフォームを買い、ある週末にすべてを移行し、月曜の朝に古いシステムを切るというものです。そのやり方が失敗するのを十分な回数見てきたので、こういう会社には提案しません。一斉切替えは、古いシステムを完全に理解していることを前提とします。十年分の文書化されていない回避策があれば、誰も理解していませんでした——それを動かしていた人々でさえも。

二つ目の魅力的な一手は、ゼロからの完全なカスタム書き直しです。古いシステムがすることをすべて取り、きれいに作り直し、新しいものを出す。責任あるように聞こえますが、これは会社が代替品を凍りついて待つ間に、一年と多額の予算を燃やす古典的な方法です。代替品は遅れ続けます。やっかいなのは、書き直しは起動できるようになる前にあらゆる癖を再現しなければならないことです——なくなって初めて誰もが「あれは要だった」と気づく、誰も覚えていない癖も含めて。

ですから私たちはどちらもやりませんでした。古いシステムを取り壊す対象ではなく、取り囲んでゆっくり置き換える対象として扱いました——一度に一つの機能ずつ、古いシステムを全行程で安全網として下で動かし続けながら。華やかさはありません。そしてこれが、確実に機能する唯一の版でもあります。

アプローチ：古いシステムを締め上げる、爆破しない

開発者の間でこのパターンには使い古された名前があります——「ストラングラー（絞め殺し）」アプローチです。木に絡みつき、やがて自立できるようになって元の木が静かに消える蔓にちなんでいます。古いシステムを一手で置き換えるのではありません。その周りに新しい部品を作り、実際の仕事を一つずつそちらへ流し、古いシステムを縮めていきます。残りが、誰も息を止めずに切れるほど小さくなるまで。

この倉庫では、それはあらかじめ順序を合意することを意味しました。どの機能を最初に剥がすか、どれを最後に取っておくか、そして——肝心なことに——どの段階でも、新しい部品がうまく振る舞わなければ、その日のうちに古いやり方へまっすぐ戻れるというルールです。どのステップも最後の最後まで後戻り不能点になることを許されませんでした。そのたった一つのルールこそが、経営者を眠らせ、倉庫スタッフがプロジェクトに身構える代わりに信頼できるようにしたのです。

1. 1
   システムが実際に何をしているかを地図化する

   現場と事務所に3週間付き添い、実際の業務フローを文書化しました——すべてのスプレッドシートとバインダーの回避策を含めて。私たちは、当初の仕様書が記したものではなく、現に存在するシステムを書き留めました。
2. 2
   移す前にデータをきれいにする

   完全な実地棚卸しを行い、それに照らして商品データベースを洗浄しました。汚れたデータを新システムへ移行しても、より速く間違った答えが出るだけです——だからこれは、いかなる新ソフトもデータに触れる前に行いました。
3. 3
   最も痛い部分を最初に置き換える

   新しい在庫追跡・棚卸モジュールを作り、古いものと並行で動かし、数字がまる一か月現実と一致して初めてそれを信頼しました。
4. 4
   古いシステムが無視していたチャネルをつなぐ

   次に、オンライン注文チャネルを新しい在庫データへ直接配線し、2019年から静かに存在していた手作業の打ち直しを葬りました。
5. 5
   残りを剥がし、それから古い中核を引退させる

   ピッキング、レポート、照合が一つずつ移りました。古いシステムで本物がほとんど何も動かなくなったとき、ついにそれを切りました——その頃にはもう何でもない出来事でした。

本当に大変だった部分

これを順調だったと見せるのは不誠実でしょう。技術的な作業は易しい部分でした。大変だったのは人と手続きの部分で、それはほぼすべてのレガシープロジェクトで同じ大変さです。

機能を壊した文書化されていないルール

新しい在庫モジュールを並行で動かして二週間、ある商品カテゴリーで数字がずれ、なぜか見えませんでした。一日掘り下げたあと、運用マネージャーがほとんど何気なく、特定のかさ物は個ではなくパレット単位で数えられ、古いシステムには十年間誰も文書化していない隠れた換算が組み込まれていた、と漏らしました。どの仕様書にもありませんでした。それは彼女の頭とバインダーの中だけに存在していました。コードだけからは決して見つけられなかったでしょう——両システムを並べて動かし、なぜ食い違うのかと問うことによってのみです。並行稼働を支持する論拠のすべてが、この一つの逸話に詰まっています。

現場を味方につける

倉庫スタッフは、善意ながら日々を悪化させた「改善」を一度ならず生き延びてきたので、もっともな疑いをもってプロジェクトを迎えました。私たちはそれにプレゼンで立ち向かいませんでした。最も大きな声で不満を言うピッカーを選び、一朝彼の隣に座り、彼が実際にどう現場を歩くかを軸にピッキング画面を作り直しました。彼が休憩室で新システムを擁護し始めると、残りも続きました。レガシープロジェクトでは、最も手強い批判者を味方につけると、その人が最良の擁護者になります——そしてそれは通達では買えません。

一年後の成果

私たちは見栄えのよいビフォーアフターの数字を警戒します。会社ごとに測り方は違い、御社では数値も変わるからです。ですからこれらは、一つのプロジェクトの誠実で丸めた数字として、約束ではなくリターンの形を示すものとお考えください。要点は、ある一つの指標よりも、何が怖くなくなったかにあります。

経営者が最も気にかけた数字は、どのグラフにもありませんでした。それは、運用マネージャーが実際に退職したとき——結果的には予定より数か月早く——倉庫がぐらつきさえしなかったことです。かつて彼女の頭の中にあった知識は、今や誰でも数日で習得できるシステムの中にありました。プロジェクト全体の当初の理由は、静かに、完全に解決されたのです。

このようなシステムを抱えているなら

老朽化した中核システムを抱えるオーナーのほとんどは、二つのことを同時に感じます。残すのはリスクがあり、置き換えるのは恐ろしい、と。どちらも本当です。誤りは二つ目の恐れに勝たせることです。古いシステムのリスクは一定にとどまらず——毎年静かに増していきます。それを理解する人々が退職に近づき、それが動くプラットフォームがサポートからさらに外れていくにつれて。

「そのままにして祈る」か「会社を大きな書き直しに賭ける」かを選ぶ必要はありません。中道——取り囲み、一度に一部分ずつ置き換え、新しいものが信頼を得るまで古いものを網として残す——は、より遅く、はるかに英雄的ではありません。けれどそれは、トラックを止めない版でもあります。この物語全体から一つだけ持ち帰るなら、それです。

よくある質問