見出し画像

サプライチェーンとQA

以前、サブスクギフトサービスのシステムをQAしていた時の話。

自前でシステムを作り、QAしてリリース。
ありがたいことに出だしは好調で、発送数も右肩上がり。

毎月増えていく発送数、仕入れ、発送準備はもちろん、委託会社への指示や、調整、その中での進めていくコスト削減。
今を回すのでも精一杯な中、未来に向けたアクションも同時進行で進めないと行けない状況に物流のチームは悲鳴を上げていた。

僕はなんとなくITの力で助けれるのではないか?と思い、物流のチームに顔を出す。
想像していたより過酷な状況・・・
ちょっとスイッチ入れ直して、現状のヒアリングしつつ、時には一緒に業務をしながら、解決すべきことを見つけるために必死になった。

サービス品質のいう観点で、全体を見たときに、僕の目にはシステムの品質より、サプライチェーンに対する改善のほうがインパクト大きいと感じていた。
会社としても物流とCSは重要と考えていた。

システムの方は追加開発はあるものの、割と品質も安定したこともあり、僕はほぼノリと勢いでQAから離れて、サプライチェーンの世界に飛び込んだ。


ザ・未経験のサプライチェーンマネージャー爆誕。


大手配送業者とのコスト削減目的での打ち合わせ中に知らない言葉をググるググる。
ググりながら理解して、会話に盛り込む盛り込む。
わからないことだらけの中、粗利率や、発送コスト等、数々の数値とにらめっこ。

委託会社だけでなく、自社での発送の規模を上げるために何が出来るか?なども考え、時には率先して、倉庫のレイアウト変更と掃除もした。

ありがたいことに、チーム内には頼りになるメンバーが存在していたので、判断などはするが、僕が実務にガッツリ入らないと回らないにはならず、僕自身の時間を改善活動に裂き続けることができたのは幸運だった。
当時のメンバーには感謝しかない。


理想と現状を把握し、ギャップを理解する。
そのギャップに対して、アプローチする。

僕の武器は正直これだけ。


ただ、やってみると、意外とQA業務で使っている脳みそが使える場面が多かったように思う。

インプットとアウトプットの結果に対して、検証する。
ある程度の期待値を設け、異なる場合は、その原因を解明する。
それをすべての工程を通して見ることもあるし、工程ごとに検証することもある。

機能テストと総合テストの応用。
ひとつ違うのは、原因の解明の対象がコードではないので、僕でもゴリゴリ解明に力を使えること。

目指すはQAしていた時と同じで、上流工程からの品質の作り込み。

品質の作り込みを実現するために、ITの力を使うため、要件作成なども行った。
リリース前の受け入れテストは任せとけ状態!

日々のタスクや、課題の管理は カンバン 方式を取り入れた。
自分が慣れているというのもあるが、物事の可視化と進行状況の把握という点でも、バッチリハマった。

バックログのもっとライトな 「モヤモヤシート」というものを用意した。
現場メンバーに、粒度問わず書いてもらった。
これは、現場のリアルな声を集め、そこに眠る根本解決すべき問題を探るのに非常に役に立った。

そして、僕なりのサプライチェーンが徐々に形になり始める。

エンジニア、ビジネス、経営陣、現場メンバー、関係するすべての方に頼るところは頼りつつ、毎月うなぎ登りな発送数に対しても、遅延を起こすこと無く、やり遂げた。

同時に、自社での発送数も半年足らずで4倍以上件数を伸ばせた。
これは、コスト削減を実現したことになる。


めちゃめちゃ大変だったけど、新しい世界でゴリゴリ動いたこの思い出は、今振り返っても面白かった。

もちろん、本職のサプライチェーンマネージャーから見たら、全然荒削りだったのかもしれない。
でも、少なくとも目の前にある問題と課題に対して、それなりの成果は残せたのは、とにかく良い経験だった。


確かに、サプライチェーンは未経験ではあるが、それは知識と、その業界での経験という意味。
僕の中に蓄積された他で培った経験はある。
僕の中に蓄積されていた経験は、他の業種であっても、活きる場面があることを大いに感じた。


これは、かなり面白い体験だった!
自分の中で何かが、ブレイクスルーする瞬間というか、一気に水が流れるような、点が線で一気につながる感覚。

これからも、未経験にビビらず、新しい扉を叩くチャンスがあれば、ガンガン叩いてみようと思う。

そんな風に思えた思い出話。



この記事が気に入ったらサポートをしてみませんか?