株式会社SKL 代表取締役社長 松永様、営業部 主任 齊藤様、営業部 副主任 藤田様にお話を伺いました。

SKL様は、親会社がお酒の卸売り大手の「柴田屋酒店」様で、その物流部門を担う会社さんです。

私にとって、初回の商談に同行したり、「柴田屋酒店」の社長さんにもお会いしたりしたので、とても思い出深いお客様の一社です。

というわけで、今回のインタビューには私も同行させて頂きました！

皆さま、ご協力有難うございました。

詳しい事例はコチラ↓で公開しています！

ドライバーの働きやすさを考えて導入：運送会社

 

さて、本題なんですが、SKLさんはODIN（オーディーン） リアルタイム配送システムを本当に使い倒して頂いているんですよね！

お酒をレストランさんなどに配送されているのですが、現在位置情報と、配送計画を合わせてみれば、進捗が一目瞭然なのです。(`･ω･´)

それを業務に生かして頂いている。

この大きい画面に、ODINのリアルタイムマップが映っています！地図がきれいだったことも決めての一つと松永社長さんがおっしゃってました( ˊᵕˋ )

 

また、日報も今まで個別に作成されていたものが、ODINで効率化されたそうです。

一つ興味深かったお話は、ODINを検討したきっかけとして

「お酒が好きな人が多く、社風的にも従業員同士で飲みに行くことが多いです。

その中で、「だれだれさんの配車は平等でない」「自分が楽できるような配車になっている」などの不満を抱くドライバーがいました。

それがシステムで配車することにより、効率的かつフェアな配車が出来るようになりました。

人の手で考えるより、システムに考えさせるとフェアになるので、ドライバーの説得ができています。」

という話ですね。

いや~　こういうお話って、本当に配送・運送をされている会社さんだとどこの会社でもありますよね。

私、時々思うんですけどODIN リアルタイム配送システムが解決している問題って「心の問題」なんですよね。

特に、今の時代、「生きづらい時代」と言われています。

中でも不公平を感じるというのはかなりのストレスです。

それを減らすには、「公平感」を出すことと、数字で「なるべく公平である」ということを証明するしかないと思っています。

そして、正直なところ機械を使わないと配車が公平であるのは難しいのではないかと思います。

心の問題を解決していきたいなと常日頃考えていますので、それができたというのは嬉しい限りです。( ˊᵕˋ )

 

また、基本的には回るルートが決まっていらっしゃるそうなんです。

「ウチはルート配送だから配送ルート計算する機能はいらないかな。基幹システムで注文とルートを作ってるし。」

と最初は仰ってたんですが、1日に数件ぐらい、急な注文や注文忘れなどでイレギュラーに何件か行かなければいけない配送があるそうです。

そのルートを考えるのが本当に苦痛だったそうです。

今はそれがODINで一瞬で終わるので、とても快適だというお話です。これもとっても嬉しいですね。( ˊᵕˋ )

ちなみに、固定ルートの方は、CSVなどでODINに取り込んで頂いて、日々の進捗や日報などに生かしていただいています。

 

マップを見ながら「今、これ帰ってきてるんだね」などとお話されています。

トラックはすべてリーファー車だそうです。リーファー車とは、外部の温度に左右されずに庫内の温度を調整できる機能を持つ車です。お酒は温度管理が大事ですもんね。

代表取締役社長　松永 様

後、SKLさんへお伺いすると、お互いに下の名前で呼び合ったりされていて、いい感じなんですよね( ˊᵕˋ )。

「お酒の会社なので、お酒が好きな人が多いので、基本的に飲みに行くことが多い。」

というお話を何度もお聞きしています。

「現場の声を重視し、経営に取り入れている。」

というお話も何度もお聞きするので、これはリンクしているんですよね。

飲みにケーションなんて役に立たない　という話をよく聞きますが、それって本当なの？とも思いますね。

また、体制がしっかりされているので、有給も多いし、残業も少ないとお聞きしています。( ˊᵕˋ )

採用の面接の際に、ODINをその応募者の方が見て、

「しっかりと管理されている会社なので、この会社はブラックではない！」

と感じたというエピソードもお聞きしました。

そうなんですよ。(`･ω･´)

お客様事例のご紹介です。

ロジボン株式会社様のインタビューを行いました。

詳しいインタビュー内容は、下記をご覧ください。

https://delivery-system.com/customer_feedback/2024/07/30/logibon/

私、宣伝に関しては一家言ありまして(`･ω･´)

例えば、中華料理屋でよく

「おいしくて安い中華料理」

って看板出しているところがありますが、自分で言っちゃダメなんですよ。（そして大体こういうお店はまずい）

お客様がどう思っているかが重要なんですよ。

自称ならいくらでも「おいしくて安い」って言えますしね。

なので、自社のODIN リアルタイム配送システムについても、「お客様の声」というのを非常に大事にしています。

そして、往々にしてお客様のほうが、宣伝としてキャッチーなことを言ってくださるんですよ！

「町の運送屋からロジスティクス企業になるために必要だった」

って、めちゃくちゃいいフレーズじゃないですか？？

これ、ロジボンさんにインタビューしている際にお客様から出た話なんですよ。

平たく言うと、

「今までは配車マンが頭の中で考えて配車をしていた。

が、台数が増えたり仕事の規模が大きくなる中で、これではダメだと思った。

元々の歴史が社長が軽トラ1台で始めた会社だが、町の運送屋の仕事の仕方では限界があって、ロジスティクス企業になるために、こういうシステムが必要だった。」

というお話です。

私、このお話を聞いてめちゃくちゃ感動しました！

お客様の夢の手助けができたってことですからね！！♡

ODINを作っててよかったなとしみじみ思いました。( ˊᵕˋ )

ヘタなコピーライターよりお客様のほうが、心に響く言葉を言ってくださいます。

使っている商品の魅力を知っているからなんだと思います。

配車マンの仕事を脱属人化できたことのほかに

・2024年問題について解決できている

・荷主さんへのプレゼンに使って新規案件の獲得に役に立った

などのお話もありました！

3PL事業部 部長 赤岩様　ODINの画面をご覧になっている

ODIN リアルタイム配送システムへのお問い合わせはコチラから。

ちょっと話はそれますが、「軽トラ1台で起業して」って話いいですよね。( ˊᵕˋ )

物流の会社さんはそういうところ多いかと思いますが、夢がありますよね！！

ロジボンの黒沼社長はTikTokもやられています！スゴイ！(`･ω･´)

ご興味あれば、ご覧ください。↓

@logibon

ロジボンTikTok始めました‼︎ 社長の私が色々発信していきます！ フォロー、いいねを宜しくお願いします✨ #物流 #社長 #社長シリーズ

♬ アイドル – YOASOBI

またまた新機能ができました　⊂(^-^)⊃

配送計画を作成する際に、例えば

「この配送先は午前中に来てほしい」

とか

「この配送先は午後に来てほしい」

などという指定がありますが、最初はODINで自動で最適なルートを作成することができるんですけども、後でいろいろ修正が必要な場合があります。

それは、例えばドライバーさんの出勤がずれてしまうとか、他の配送先に急に行かなくてはいけなくなった、などです。

（前回投稿した追加配車機能などを使ったりですね！）

で、色々変更しているうちに、午前中指定　だった配送先が午後になってしまっている、などということがありえます。

ですが、それを防ぐことができるようになりました！！(๑´ω`ﾉﾉﾞぱちぱち

配車表という画面で、ルートを見ると下記のように表示されるのですが

赤いエクスクラメーションが出ているのがおわかりでしょうか？

ここにマウスオーバーすると、次のようになります。

どれぐらい遅れるのかも表示される

すごいのはここからで、弊社の秀逸、S君がめちゃくちゃ早くこの機能を実装してくれました。

開発にかかった時間、

わずか1日弱。

すご！

元になった機能は、この開発の時に実装されていたとは言え、かなりオサレなUIにもなりましたし！

これからも、新しい機能をどんどん作っていきたいと思います！(`･ω･´)

なんと今回、業務用初！（弊社調べ）の機能をリリースしました！(`･ω･´)

乗車中か歩いているか、止まっていたかの履歴がわかる機能

めっちゃ平たく言うと、今どきは、ランニングアプリとか、ヘルスチェックアプリとか歩数計とかで、何歩歩きましたね、とかアプリが教えてくれますよね？

ただ、ああいうのは自分で見るだけで、ほかの人のを見たりとかはできませんでした。

それができたのです！！( ˊᵕˋ )

ODIN リアルタイム配送システムへの機能追加となります。

今までもODINではリアルタイムで、現在走っているのかドライブ中なのかがわかったのですが、履歴まではとっていませんでした。

それを、記録するようにしました。

例えば、

・チラシを配布する際は、小走りで行うこと　というポスティング会社さん

・配達の際は、小走りで行うこと　という配達会社さん

・連続して運転を続けていないかを確認したい会社さん

・位置情報がわかっても、歩いていたら納品作業をしている、止まっていたら待機中だった、などを把握したい運送会社さん

などのニーズを想定しています。

【業務用初】スマホで従業員の行動を詳細に記録する機能をリリース

詳しくは、上記のプレスリリースをご覧ください。

弊社のODIN リアルタイム配送システムは、配送業・運送業さんのためのシステムですが、この機能は広く外出して仕事をされる会社さんにニーズがあると思っています！

2週間、無料でお試しもできますので、ぜひお試しください。

お試しはコチラから。

新機能ができました！

配送ルートがもう決まっているものがあったとして、新しい行かなければいけない配送先が増えたときに、それを配送ルートに足したら、どのぐらい時間が増えるかというのを試算する機能です！

拘束時間を完璧に把握しながら配車できるようにする機能のスクショ

例えば、東京から大阪へ行かなければならないとして、途中に長野を挟んだら、結構走行時間が増えそうだなという予想ができると思うんですが、実際にどのぐらい走行時間が増えるのかなってわかりづらいじゃないですか。

ですが、この機能を使えば、ワンドラッグアンドドロップですぐにわかるんですよ！

とっても便利！！٩( ‘ω’ )و

プレスリリースはこちら！↓

拘束時間を完璧に把握しながら配車できるようにする機能をリリース

で、この機能なんですが、実はある大規模修正の副産物でできた機能で、他にも機能のアップデートがあります！

・配送計画閲覧画面にて、行先だけでなく住所を表示するように変更
・配車表のリニューアル
＜変更点＞
・積み下ろしのデザイン変更
・合積みの解除の際に、ひとつづつ解除するのではなく、すべてが解除されるように変更
・時間軸にて、配送先を追加する際に時間が足りないのかだけでなく、どれくらい余るのか表示するように変更
・足りない、余っているのメッセージの時間を〇分という表示でなく〇時間〇秒のように変更
・時間軸にて、移動時間が足りないような時間に配送先を追加した際、後ろをずらして間に合うようにする選択肢を追加
・配車表の表示時間範囲を、ボタンのクリックによって１日ずつ前後させることができるように変更
・スタート地点の時間と場所が選べるように変更
・最後の配送先を削除した際に、そのひとつ前の配送先の空き時間が自動的に削除されないように変更
・時間軸にて、配送先を削除した際に、その配送先の後ろの配送先の時間が自動で詰められるように変更
・通常の配車表という名称を「タスク軸」に変更
・タスク軸の配車表にて、配送先を追加した際に拘束時間が何時間に変化するかを表示するように変更

特に配車表がめっちゃ便利になったんですよ！o(>▽<)o

ぜひ使ってみてください！（無料お試しはコチラから）

上記に書いたのはユーザーさんに影響があることだけなんですが、実は裏側のプログラムがめっちゃ変わったんですよ！

というのも、配送ルートの更新系をミニイベント駆動にしたんですよ！

ついでに、プロパティの整理（分刻みのものと秒単位のものが乱立していたので整理）などしました。

なんと、10か月かかりました！！

長かった~(>_<)

これ、実は私が主導でやりまして…。本当にキツかったです（笑）

私はそこそこハードワークになれている方だと思うんですが、今回はしんどかった。

朝から晩までやるのはもちろん、2月って3連休が2回あったじゃないですか。

その3連休、両方ともこのためにプログラミングしてました。

人生の中できつかったプロジェクト10位には入りそうです。

既存のプログラムを直すのってしんどいんですよ。

新しいプログラムを書くのは楽しいことなんですが、自分以外の人が作ったプログラムを直すのは純粋にしんどい。(´ω`)　楽しくもないしね（笑）

そういう過去のプログラム上の不整合やまずい部分を技術的負債と呼びますが、まさに負債、借金！

技術的負債を返すのは大変だ～（泣）

借金なのでほっておくと雪だるま式に増えていくので、ここで改修に踏み切ってよかったです。

楽しくないとか言っても、それでも私はプログラミングが好きなので、休みでもできたという感じかもしれません。

特にこだわった部分は、エラー処理ですかね。

不整合なデータがデータベースに入ると直すのがより大変になるので、その前に食い止める必要がありますが、その食い止め方もなるべく発生から浅い段階で返すようにしました。

もちろん一人でやったわけではなく、協力してくれた皆さんのおかげです！( ˊᵕˋ )

TypeScript化をしてくれたM君、中盤でがんばってくれたＳ君、天才的なひらめきとスピードで終盤の開発をぐいぐいしてくれたS君には特に感謝です。

ありがとう！

この改修は今後の機能追加をやりやすくするためのものなので、今後の機能開発がスムーズにいくはずです！

ODIN リアルタイム配送システムの機能強化にご期待ください。( ˊᵕˋ )

有名な本なので、タイトルを知っている人は多いと思います。
私もタイトルは知ってましたが、この度初めて読みました！ Amazon: 人月の神話

なんと、1976年に書かれた本だそうです。
いや、時代を超えて語り継がれる名著ってやっぱり違いますね~。

何より驚くのは、ソフトウェア開発、つまりプログラミングというものにまつわる難しさの本質が、この48年前からほとんど変わっていないということです。
つまりは人間が何人か集まって、複雑なものを作ろうとすると発生する問題というのは同じなのかもしれませんね。

私が読もうと思ったきっかけは、弊社も少ない人数で開発していますから、
「いかに少数精鋭でよいソフトウェア製品を作るか」
ということを常に考えています。そんな時に、この本のことをAWSのセミナーで上げてらっしゃる方がいて、この機会に読んでみようと思いました。

下記に私が大事だなと思ったところを上げておきます。

①人月について

人月って言うのは、システム開発業界でよく言われる用語なんですが、「5人のプログラマーが5か月かかって作る」場合、5×5で25人月となります。

・人と月は交換可能ではない
コストは人と月に比例するけども
・人と月が比例するのは、作業者の間でコミュニケーションを図らなくても仕事が分担できる場合だけ
・コミュニケーションの労力は、人数が多いほどかかる。
・特に新しく追加した人は経験者から仕事に対する教育、訓練を受けないといけないので、それに3名が1ヶ月かかるとすると、3人月がもとの見積もりになかった人月がかかる。

→人員を投下しまくったり、後から開発に追加したりしても、なかなか成果が上がらないということです。
単純作業だったら、人を追加したらいいかもしれませんが、システム開発というのはコミュニケーションが大事だからです。
遅れているソフトウェアプロジェクトへの人員追加はさらにプロジェクトを遅らせるだけってよく言いますよね。

②スケジュール組について

ソフトウェア開発のスケジュールは
1/3 計画
1/6 コーディング
1/4 単体テストおよび初期システムテスト
1/4 すべてのコンポーネントを統合して行うシステムテスト
（あれ？この計算合ってます？（笑））

→計画が大事ってことですね！キモに命じます。

③コンセプトについて

少数精鋭チームは10人以内が理想的。
外科手術のチームように行う。
機能などで分担を分けるのではなく、執刀医と副執刀医はプログラムのすべてを把握し、判断する必要がある。

大勢で考えたほうがよいとか、そのほうが民主的とか、そういう問題もある。
が、重要なのはコンセプトの完全性なので、貴族政治の方がよいわけ。
アーキテクトとインプリメンテーションは違うタイプの創造的仕事。

ソフトウェア製品にとって、コンセプトの完全性がとても大事。
コンセプトの完全性は、デザインは一人または互いに意見が同じで共鳴するごく少数の頭脳から、考え出さないといけない。
重要な仕事は、製品を定義すること。

→これもわかる~×100。ですね。
昔、爆笑問題の太田さんがテレビで話していた逸話ですが、太田さんが映画を作ろうと思ったことがあったんですって。
で、映画を作っていると、太田さんは映画を作るのが初めてだから、美術監督は「これをこうしたほうがいい」、
照明さんは「あれをこうしたほうがいい」脚本家からは「こうしなきゃダメ」とか言われて、全員の言うことを聞いていたら、まったく面白くない作品になってしまったんですって。

これ、作品というか何か創造物というのは本当にこの側面があるんですよね。

④コミュニケーションについて

コミュニケーションの欠落が抗争、憎悪、嫉妬につながる。
そのうち内輪喧嘩するよりは一人でいたほうがいいと思い、バラバラになり始める。
マネージャーにとって重要なのは、全員を同じ方向に進ませること。
そして、組織の在り方というのは大事だし、組織にどんな人を追加するのかがとても重要。

→身につまされる話ですね。

⑤工数見積もりについて

プログラムを書く時間は、大体倍の時間かかる。
大体のプログラマーが、勤務時間の2分の1しかプログラムにかけられない。
機械が故障して使えないとか、ミーティングとか書類作成、社内事務、病気、私用など。

→わかる~。実際にそうですよね。

⑥スケジュールについて

1日毎の遅延
昨日はキーパーソンが病気
今日は機械の故障
顧客との緊急ミーティングなど、どんどんスケジュールは遅れていく。
が、3か月の納期とかってなってると、1日ぐらい遅れても、取り戻せるだろうと思っている。

しかし、結局1日の遅れを取り戻すことが難しい。
ハッスルプレイ、一生懸命になること、1日の遅れも取り返すために躍起になるべし。

→ううう　その通りだと思います。

⑦ソフトウェアを作るということが、なぜこんなにも難しいのか

表現はプログラミングの本質。
仕様書や文書でコミュニケーションを図る必要がある。

何を構築するのかを決めるのが非常に難しい。
にも関わらず、後から変更するのがこれほど難しいものもない。

→弊社で、最近変えたことがあります。
それは、仕様書をもっと作っていく、ということです。今までは、テスト仕様書はあったんですが、プログラムの仕様書については、作ったり作らなかったりでした。
ソフトウェア製品の仕様書って難しいんですよ。すぐに仕様書が古くなってしまうからです。
コードが仕様書、テストコードが仕様書、という状態は多いと思います。

ただ、どうしてもそれじゃ表せない仕様がある。UMLもシーケンス図も足りないとい思うときが多いです。
図や絵じゃないと表せない仕様ってあるんですよ。
えてしてそういう仕様が複雑かつ大事なんですが、コードもテストコードもUMLもシーケンス図もそれを表すことができない時があります。
で、Outdateな仕様書だとしてもそういう絵や図を含むものが「ないよりマシ」という結論になりました。

また、表現はプログラミングの本質、という言葉にグサッときました。
私がいつも考えていることを一言で言い表してるなと思ったからです。

————————————

この本に出てきた言葉か忘れちゃいましたが、ソフトウェアって不思議なもので、1000人のプログラマーがいる大企業が出している製品よりも、ガレージの二人組の方がいい製品を出している、ということは起こるわけです。
我々もガレージ側なので、得られたことを生かしてがんばらないとな！って改めて思いました。

そして、弊社では現在、新卒・中途のプログラマー・新卒の営業を募集しています！
採用情報はこちら。