荷主企業さんからの問い合わせが増えています

弊社のODIN リアルタイム配送システムですが、私も時々お客さんのところに行くんですが、最近多いお問い合わせが

「自社で配送をしているわけではなく、外注で配送をしているが、その配送を管理したい。」

というお話です。

つまり、荷主さんや荷主から発注を受けた配送の1次請け、などの会社さんですね。

そういう会社さんが、なぜ弊社のシステムに興味を持って頂いているかというと、おそらくスマホなので簡単に外注さんに使ってもらえるということだと思うんですよね。

デジタコなどの車に取り付けるタイプのものだと、自分たちの会社の車ではないのでハードルが高いんですよね。

弊社のサイトでも、ハマキョウレックス様で2次請け、3次請けの管理をしている、という事例をご紹介しています。

 

また、もう一つの要因が、2024年問題です。

2024年問題で、よく話に上がるのが、トラックドライバーさんのお仕事って運転するだけじゃなくって、納品までですから、着いた先、または荷物を積む作業もあったりします。

で、その着いてすぐ納品、とかできればいいんですけど、場所によってはトラックが2台しか入れないから後に来たトラックはちょっと待っておく、とかそういうことがよくあります。

その時間が結構長いんですよね。2時間とかかかったりしている場合もあるそうです。

で、これがもちろん待たせている側、つまり荷主が悪いでしょう!という話になりつつあって、国土交通省さんが、トラックGメンなるものを設置しました。

 

それで荷主さん企業の方も、2024年問題に敏感になってこられたという背景があると思います。

ただ、荷主さんの方が全部悪いのかというとそんなことももちろんなく、まずは

・運送のどこにどのように時間がかかっているのか把握する

 

が必要です。

そういう時に、弊社のODIN リアルタイム配送システムが役に立つってわけですね。

どこにどんな作業をしていてどれだけ時間がかかったか記録できますからね。

また、外注さんや庸車さんのルートが最適なのかどうか知りたい、という方もいらっしゃいます。

そういうことにも使えちゃったりします。

 

ぜひ、荷主企業さんでも、ODIN リアルタイム配送システムを試してみたい、という場合は無料お試しが2週間できますので、お気軽に利用してください!

無料お試しはこちら

【2024年問題】年間時間外労働960時間までのカウントダウンが一目でわかる機能を追加しました

これはですね、すごい機能というよりは、めちゃ役に立つ機能だと思います。(`・ω・´)

2024年問題について、ご存じでしょうか?

ちょいちょい、このブログでも取り上げていますが、2024年4月から、運送業・配送業の方の年間時間外労働が960時間に規制されることによる問題です。

一般的には、スーパーにモノが並ばないとか、そういうことが取り上げられていたりしますね。

運送業・配送業の方には大きなインパクトのある法改正です。

で、その年間の上限の960時間まであとどれぐらいなのか、が一目でわかれば便利なのではないかと考えまして、ODIN リアルタイム配送システムにそんな機能を追加しました。

『960時間カウントダウン機能』

一目瞭然で後何時間残されているかわかる、というわけです。

で、弊社のものはただの勤怠管理ではなく、GPSがついてますので、位置情報と一緒に管理できますから不正打刻も防ぐことができます。

また、時間外労働が多い順や少ない順で並び替えできるので、余裕がある/ないドライバーがすぐにわかります。余裕のない人から、ある人へ仕事を割り振ることができます。

おススメの会社さんは、長距離輸送が多い、直行直帰のドライバーさんが多い、残業が把握できていない、という会社さんです。

プレスリリース全文はこちら↓

【2024年問題】年間時間外労働960時間までのカウントダウンが一目でわかる機能をリリース

 

今回は結構地味なところが大変な開発でした。

営業とプログラマーの二刀流のS君がリーダーで、別のS君の2名でやってもらったんですが、残業時間の計算って気が遠くなるほど大変なんですよね。

所定労働時間って会社さんによって違うところから始まって、残業時間の計算を本当に丁寧に作ってくれました。

本当にスピード重視で、集中的に作ってくれました。

ジブリのキャラが走る速さぐらい早かったですね。

そして、早いということはとっても価値があることです。

なぜかというと、もう2024年問題まで時間がないからです!

大きな会社さんだと検討に半年とかかかったりするので、もう商品として用意しておかないと、2024年の4月の運用開始に間に合わないと思ったからです。

ODIN リアルタイム配送システムは、これからも2024年問題に向き合っていきます。

 

興味がありましたら、ぜひコチラからお問い合わせください。

 

 

ThoughtWorksアンソロジーという本を読みました。

 

この本、中古でなんと5900円もしたんですが、買って会社に持っていったら

M君「え??この本また買ったんですか??」

と言われまして…。 なんと2冊目を買ってしまったらしい(笑)

まぁ、詳しく話すと私が処分しようとしていたところを勉強熱心なM君が自宅に引き取ってくれたのを忘れていたといういきさつでした。

まぁ、古い本なんですけれども。

まだ2023年に通じるところはいっぱいあります。

 

1章 ビジネスソフトウェアの「ラストマイル」を解決する

 

プログラマーの皆さんは感じたことがありませんか?プログラムが出来上がってからが…長いと…!!

正確に言うと、98%ぐらいできてからが、その先の2%ぐらいにめちゃ時間がかかるんですよ。

Windowsの検索みたいだねっ!!

これは、他のお仕事とはだいぶ違うところで、ソフトウェアを作らない方にはなかなかわからない部分だと思います。

なぜかというと、ある程度できてからしかわからないことが多すぎるからです。

それを、ここでは「ラストマイル」と表現しています。

本書からの抜粋ですが

「ラストマイルで実施されるテストでは、システムのレスポンスタイム、トランザクションのスループット、可用性、セキュリティという

非機能要求が満たされているかを確認することに、多くの時間が費やされます。そして、それをテストできるのはソフトウェアが完成した後なのです。」

そう。そうなんですよ。

アプローチとしては本書曰く

「『システムのレスポンスタイムは5秒以下にする』、という決め方だとソフトウェアが完成してからしかテストできないが、

『ディスクへのランダムアクセスを1秒間に2500回以下にする必要がある』という決め方ならソフトウェアの作成段階でテストできるし、カウンタ機能をつくれば自動テストに組み込むことができる」

という話です。確かに!!

5章 オブジェクト指向エクササイズ

 

ソフトウェア設計を改善するために次の9つのことをやってみよう!という話です。

1.1つのメソッドにつき、インデントは1段階までにする

2.  else句を使用しないこと

3.  すべてのプリミティブ型と文字列型をラップすること

int とかは何の意味も持たない。時間とかなら、時間型しか渡せないので、ずっと保守性が高まる。

4. 1行につき、ドットは1つまでにすること

5. 名前を省略しないこと

6.すべてのエンティティを小さくすること

50行を超えるクラス、10ファイルを超えるパッケージは作らないこと

7.1つのクラスにつきインスタンス変数は2つまでにすること

クラスには2つ種類があんねん!とアンミカさんが言いました。

それは1つのインスタンス変数の状態を管理するクラス、2つの独立した変数を調整するクラスです。

ほう。

そして、それを混ぜてはいけません。

なるほど。。。

8.ファーストクラスコレクションを使用すること

実はですね!この本の、この部分だけを読みたくて、この本を買いました!!!

最近仕事で、コレクションをどうクラス設計すればいいか悩むことが多くあったので、ファーストクラスコレクションについて、詳しく知りたかったからです。

実際のところ、12行しか書かれていませんでした(笑)

大事なことは

・他のメンバ変数を持たせないようにする

・フィルタとか作ってもいいかもね。

・2つのグループの結合やグループの各要素に対するルールの適用なども扱ってもいいかもね

・コレクションはただのプリミティブな型の一種に過ぎないので、独自のクラスにラップする意味はある

12行だけでしたが、きっと三蔵法師がインドで仏典を手に入れたときぐらい満足できました。⊂(^-^)⊃

9. Getter, Setter, プロパティを使用しないこと

エッ

「求めるな、命じよ」

だそうです。

「求めるな、命じよ」については、下記の解説がわかりやすかったので、こちらを見てみて下さい。

https://zenn.dev/miya_tech/articles/2289a177cdf2ff


 

<これらのルールを見て思ったこと>

オブジェクト指向的に考えるのが難しい理由って、プログラムを書く時の思考はどうしてもオブジェクト指向と反対から始まることが多いからじゃないかと思ってます。

プログラミングの入り口は

「あるデータがあって、それをAという場合はBに、Cという場合はDに」

みたいに始まることが多いんですよね。そしてそれが膨れ上がっていくのが大体のプロセスだと思います。

そうすると、上のルールを守ることはまったくできません。

オブジェクト指向的な発想は反対側からなんですよね。

「あるデータとは何なのか。どういう役割なのか。構造はどうなっているのか。」

を決めることから始めないとなんですよね。

最近、プログラミングとは概念を構造的に伝える手段なんじゃないかと思います。

 

ところで、この本を中古で買ったんですが、めっちゃ線が入っていて、この本を持っていた人は大変な勉強家だったんだな!と思います。

なんかそういう本っていいですよね( ˊᵕˋ )

 

 

2024年問題対応で65%の会社が既にシステムを導入済み 

2024年問題対応で65%の会社が既にシステムを導入済み

https://www.value-press.com/pressrelease/319562

というプレスリリースを出しました。

 

ちょっと意外な気がしますよね。

元々、今年度は2024年問題にフォーカスしていこうと決めまして、それで弊社のメルマガを購読してくださっている皆様に、2024年問題についての意識調査を行ったんですよ。

大変参考になりました。

ご回答いただいた皆様、有難うございました!

 

2024年問題については一般の方も最近では見聞きすることが多いと思います。

2024年(来年ですよ!!)に、法律が変わることにより、運送業界・配送業界では起こる問題がいっぱいあるのです。

業界が直面する大きな課題です。

繰り返しにもなっちゃうんですが、弊社では今年度は2024年問題にフォーカスしていきます!

今後もそれに対応した機能拡充をしていきます。

配車表の機能が大幅にアップデートされました

またまた、すごい機能ができてしまった…。

弊社のODIN 配送計画に、以前から「配車表」という機能がありまして、端的に言うと、

「その日のドライバーさん達のルートが一目でわかる。」

というモノなんですが、これがめっちゃ強化されてアップグレードしました!!

新配車表

新配車表

パチパチパチパチ。プレスリリースは下記の通りです。

ドライバーさんの配送スケジュールが一目で管理できる『新配車表』をリリース

https://delivery-system.com/press-release/2023/05/23/shin_delivery_shift/

何がすごいかと言いますと!

①2024年問題対応ができる

上記の配車表は、ドライバーさんの拘束時間が少ない順や多い順で並び替えができます。

拘束時間が多い順などでソートができる

拘束時間が多い順などでソートができる

それに、ルートの横に拘束時間や移動距離が書いてあります。

2024年問題で、ドライバーさんの残業を減らすことが運送会社さんでは頭の痛いところだと思いますが、一つの解決方法に、

「残業が多いなら、少ない人に仕事を回せばいいじゃない」

というのがあります。

それが、これで、できてしまうんです。

5人ぐらいだと、パッと誰が多くて、誰が少ないのかすぐわかると思うんですけど、20人とかいたら、誰が多いのか、少ないのかわからないですよね?

そこはそれ、ITの力です!!(`・ω・´)

これを使って並び替えてください!!

②急な配送の追加に対応しやすい

急な配送があった時に、その場所がどこか、どのドライバーさんのルートが近いのかがわかります。

そして、それをちょいちょいドラッグアンドドロップで動かせるんですよ!

なので、例えば急に「沼津へ配送に行ってほしい」というスポット配送の依頼があったとして、

「ドライバーAさんがいいかな~。」

と、ドラッグアンドドロップで配車を割り付けできます。しかし、やってみたら、意外と走行距離がかさんでしまった場合、

「ドライバーBさんにしてみよ」

と言って、ドライバーBさんにドラッグアンドドロップですぐに割り振り直しができるのです。

そうやってルートの組みなおしをすると、組み替えたルートの総移動距離、総拘束時間などが瞬時に出るんですよね。

ルートを変更したときにすぐ総距離や総拘束時間がわかる

「見せてあげよう、これがラピュタの雷だ。」

…じゃなかった、しかし、これはExcelや紙で配車をやっているとすぐ把握できない部分なので、便利だと思います。

ルートは地図上に描画するので、目で見ながらルートの割り振りの試行錯誤に便利なんです

 

③地図上でルートを見れる

目で確認する。これ以上に便利なことがありましょうか。いや、ない。

④ドライバーさんを見つけやすい

スキルで絞り込み

スキルで絞り込み

結構これこだわってまして、例えばスポット便があった場合に

「大型トレーラーのドライバーさんって誰だっけ…。」

ってなってしまう場合もあると思いますが、ドライバーさんの免許やスキルなどで絞り込みができます。

また、名前で検索・表示ができますので、例えばドライバーAさん、ドライバーBさん、ドライバーCさんだけで入れ替えをしたい、という場合、その3人を検索すれば、3人だけを表示することができます。

また、配送先の名前や、住所などでもドライバーさんを探したいことがあると思います。

先程の例で行くと、沼津へ急に行かねばならなかった場合、「静岡」で検索すると、静岡方面へ行くドライバーさんを絞り込めるというわけです。

こういった機能も、5人ぐらいのドライバーさんの会社さんというよりは、20人以上のドライバーさんがいて、こういうことに時間がかかっている会社さんでは非常に役に立つ機能なのではないでしょうか!!

 


えー、ほかにもめっちゃすごい機能がいっぱいあって、全部紹介したいのですが、とりあえずは上記4点に絞らせていただきました!!

今回は、なんと!弊社のプログラマーさんの主力8割がこのプロジェクトにかかわって完成させました!

プロジェクトリーダーのM君以下、皆さん結構大変な状況もありましたが、がんばってくれて、本当にいいものができたと思います。(๑•̀ㅂ•́)و✧

 

ぜひですね、皆様にお試し頂きたいと思います。なんと、無料で2週間お試し頂けます。

オススメしたいお客様としては

①20人程度のドライバーさんがいる

②急な配送がある

③ドライバーさん間のルートの入れ替えが頻繁にある

④配送ルートを配車マンorウーマンさんが、じっくり練りたい

という配送業・運送業・サービス業のお客様です。

ODIN 配送計画のお問い合わせはコチラからお気軽にどうぞ!

 

 

 

PHPerKaigi2023に行ってきた

今日はPHPerKaigi2023を現地に行って聞いてきました!

いつも私はこういうブログは1週間ぐらい経ってからしか書かないんですが(笑)

今日はモチベが高いので、今日中に書きます!(`・ω・´) 眠いけど…。

さてさて、木曜日から会社で業務の合間にオンラインで見てました。

見たセッションと、その感想をちゃちゃっと書いておきます。


木曜日

技術負債とプロジェクトと私たち

 

発表者さんのWeddingParkでは技術的負債をなんとかするために

①テストコードの導入
②カバレッジの目標を設定
→目標達成に追われないカバレッジ値の設定が必要だった

されたそうです。

そう。テストを作らねば。
なんですが、テストを作るのが面倒 (´ω`)
最初のうちは、意識高くカバーしていても、切羽詰まってくると
「この辺、そのうちリファクタするかもしれんし」
という言い訳などで、テストコードを書かない部分が増えてくる。

これはマジの技術的負債ですね!
なんとか、これを防がないといけないな…。

発表をしていたWeddingParkさんでは、テストコードを書きやすいように環境を整えたり、コード自体を書き直しされたそうです。
弊社も、環境はあるんだけどね…。

PHPUnit 10 概論

PHPUnit10で新しくなることで、印象に残ったのは下記のことです。

・テストイベントが新しくなるらしい。
・テストの結果とテスト自体の問題を区別するようになった。
いくつかのテストの結果やテスト自体の問題では、発生してもテストを中止しなくなった。

DataProviderという機能が紹介されてたんですが、これについて私は知らなかったので、勉強になりました。( ˊᵕˋ )


金曜日

見たいセッションあったんですが、業務多忙につき、一個もみれなかった。(>_<)


土曜日

練馬に行きました!

計測できるレガシーさを捉え、コード改善に対処する

 

途中からしか見れなかった(>_<)。

「レガシーコードだねぇ、おじいさんや。」

「そうだねえ、おばあさんや。」

と言ってるだけじゃなくって、ツールを使ってそのレガシーさを測るべしという話(だと思った。)

とにかくたくさんのlintが紹介されてました。

知らなかったツール→phpmd、Rector、PHP CS Fixer

PHPの配列の内部実装について学びたくなった。

 

そうなんだ~!ということばっかりでした。スクショいっぱい撮った。

JavaだとArrayListとかLinketListとかHashMapとかあるけど、PHPは配列だもんね。

なので、詳しくは上記のリンクにあるスライドを見ていただくのが一番いいかも。

成瀬の挑戦状

 

このセッションの10分ぐらい前に「ドメイン駆動設計入門」という本を読みましたという投稿で紹介した本を書かれた成瀬 允宣さんに直接お会いできて、色々話せたので嬉しかったです!( ˊᵕˋ )

で、その時に挑戦状を頂きましたが、まったくわからず

「?」

となってた私は本当にです。(´ω`)

クジラのこと、Dockerにつながってなくってw Twitterが落ちてる時に出てくるクジラかな?って思ってましたから(笑)

いやー、皆さん本当に頭がいいな~ それとも、競技プログラミングとか(?)こういうことに慣れてればすぐできるものなのかな。

シーザー暗号、とか初めて聞く言葉がいっぱいありまして、なんかいつも接していない分野のことが知れて面白かったです。

問題をもっと前に知っていればよかったな。

人生、宇宙、すべての答えは42らしい(笑)。成瀬さんの博学さに脱帽ですね!

プログラマーってSF好き多いですよね。

成瀬さんと!

PHPerチャレンジ解説セッション

 

こちらも、問題を解く系のセッションでした。最近ではカンファレンスでこういうのやるんだ~ ってなってました。

これも、事前に問題を知っていればもっと前のめりに聞けたかもしれないですが、問題を知らないので、ちょっとぼんやり聞いてました…。

しかし

「PHPのVMを書き換えてevalの動作を変えてしまう」

とか言っていて「マ?」って思ってました…。

「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」

って言葉を初めて知りました。


そして、懇親会!

懇親会が一番楽しかったです。( ˊᵕˋ ) 200人ぐらい参加されてたのかな?

元々、知らない人と話すのが好きなのですが、コロナからはそういう機会がめっちゃ減ってしまって、特にプログラマーさんと話す機会が減ってしまったので、久しぶりでした。

PHPだけじゃない、いろんな言語の話を聞いたり、他社さんの仕事の話を聞いたりするのは勉強になります。

ただ、私今回一人で行ったんですが、こういう飲み会の場で最初一人なののアウェイ感がつらい(笑)

(本当は弊社のK君が来るはずだったんだけど、急遽体調不良でオンライン視聴でした。弊社のほかの人もオンラインで見てたと思う。みんな横浜ずみだからね。)

 

現地に行く一番の収穫は、自分のモチベーションが上がるということだと思います。

PHPerKaigiって有料なんですよ。

会社から経費が出る方もいるかもしれませんが、自腹で来ている人もいるはずで、土曜日にお金出してこういうところに来る人って、意識がめちゃ高いですよね。

そういう人たちの勉強したい、プログラミングが好き、という純粋な気持ちが感じられて、自分の気持ちがアガるのが好きです。

また、すごいと思える人にいっぱい会えると自分が「井の中の蛙」だなって、まだまだがんばらないといけないなと思わせてくれます。( ˊᵕˋ )

 

配達状況が一目瞭然! という口コミを頂きました

以前の投稿で、ITトレンドというサイトで弊社製品、ODIN リアルタイム配送システムの口コミが見れますよ、という話をしましたが、また新しい口コミが増えました。⊂(^-^)⊃

卸売・小売業・商業(商社含む)のお客様で

——————————————————————————————————–

配達状況が一目瞭然!★★★★☆

 

この製品のいい点

弊社では、配送計画業務が特定の人でしかできない状況であり工数も多い状況でした。また顧客先から荷物の到着時間の時間の問い合わせが多く、運転手との連絡が取れず回答するまでに時間がかかっていました。この配送システムは全車両が何処にいてどこまで業務進行状況を一目瞭然で確認できます。また操作が簡素化されており、簡単でコストパフォーマンスが高いのが魅力的です。アフターフォローも抜群です。

ODIN リアルタイム配送システムの改善してほしい点

日報を記入するのが各配達先ごとに1件ずつ入力するようになっているので、ドライバー目線では操作がわかりにくいと感じました。
システムの不具合 →配送計画で、時間の入力ミスをした場合、エラー内容が表示されず原因がわかるまでに時間が掛かった事が数回ありました。

ODIN リアルタイム配送システム導入で得られた効果・メリット

既存の受注システムと連携できれば、受注→配送計画→配達(バーコード等で誤配達のチェック)→完了→日報のオートメーション化ができるのではないかと期待しております

検討者にオススメするポイント

圧倒的にコストパフォーマンスが高い
https://it-trend.jp/logistics-system/12280/review
——————————————————————————————————–

ありがとうございます!!

仕事をやっていてよかったな、と思う瞬間ですね。( ˊᵕˋ )

そして、今も弊社製品が、このITトレンドさんのサイトの「配送管理システム部門」では

口コミダントツ一位

 

(2023年3月23日時点 )
です。

ありがとうございます!!!o(>▽<)o

配送管理システム 口コミ

今、配送・運送の世界って2024年問題で揺れてまして、弊社も、2024年問題に関するお問い合わせをよく頂きます。

配送プロセスの効率化にご興味ありましたら、ぜひお気軽にお問合せください。

お問い合わせはコチラから!

WBC侍ジャパン優勝おめでとう!とても明るい気持ちになれました!

 

「ドメイン駆動設計入門」という本を読みました

この本は、会社のM君が読んでいて、この本の話をよくされるので、「私も読んでおくか~」となって読みました。

この本を読んで、ドメイン駆動設計の復習になりましたし、新しい知識もあって大変勉強になりました!⊂(^-^)⊃

忘れてたことも多いしね(笑)

 

この本は、ドメイン駆動についてコードをベースにわかりやすく紹介してくれているのが特徴かなと思います。

前にドメイン駆動と言えばこれ みたいなエリック・エヴァンスという方の本があって、そのレビューを書きましたが

「エリック・エヴァンスのドメイン駆動設計」を読みました

上記の本は、いい本なんだけど、とにかく読みにくいし、長い!

エリック・エヴァンスの本は、考え方、みたいなのについて述べられている部分が多いので

「とにかくコードで見たい」

という方には退屈になるだろうなと思うんですよね。

実際、私も読んでいる間、何度も昼寝しました(笑)。

 

なので、手っ取り早くドメイン駆動を学びたい、コードで紹介してほしいという方にはこっちの「ドメイン駆動設計入門」がおすすめかもしれません。

ただ、「ドメイン駆動設計入門」にも書いてあることですが、私としてはエリック・エヴァンスの「エリック・エヴァンスのドメイン駆動設計」とセットで読んでほしいなと思います。


下記、メモです。

<値オブジェクトとエンティティ>

値オブジェクトは、電話番号とか、名前とか、ユーザーidとか。
ユーザーidが例えば6文字以上、とか名前が性と名からなるとか、そういうのをオブジェクトにしておくと制約をコードにしておけるので作りやすい。不変にしておくのがよい。
エンティティは、ユーザー、とか。ユーザーの年齢が変わっても同じユーザー。
識別子で識別されて同一性が担保される。

<凝集度>
クラスのプロパティが、どのメソッドで使われているか。
すべてのプロパティが全部のメソッドで使われていたらめちゃ高凝集。

<集約>
UserクラスとCircleクラスがあって、たとえばユーザーをサークルに追加する処理、というのを
ユーザーアプリケーションに
circle.members.add(member) としてはいけない。
例えば、サークルに人数制限がある場合、circle.members.add(member)  とするたびに、サークルのメンバーが30人以下かどうか、という確認をcircle.members.add(member)する前に確認するとする。
すると、circle.members.add(member) を呼び出すたびにそれをしないといけないと、プログラム上DRYの原則に反しているし、Circleというクラスにその人数制限の表現ができていないから。
CircleクラスにJoinというメソッドを作ってそこで定義するべき。

<仕様>
仕様をプログラムにするのもいいかも。
前述のCircleで例えると、メンバーを種別で分けることになり、例えばプレミアムユーザーは5人まで、とかルールが複雑になっていくことが考えられる。
その場合
CircleMembersFullSpecipication
というクラスを作って、そこでサークルメンバーに対する複雑な仕様を書いておく。
そうすると、サークルメンバー追加という場合に、CircleMembersFullSpecipicationを呼び出して、仕様にあっていれば追加、とすればよいので楽だしコードが読みやすい。


プログラムの書き方って本当にどうやって書いたって自由なんですよ。

私の好きな言葉に “Code is Poetry” (コードは詩である)というものがあります。

詩はどう書いたって自由です。

が、読むほうにすれば、やはり優劣があります。

いい詩はスッと入ってきますね。

言葉と概念の選び方なんだと思います。

詩人ってセンスが大切みたいな思うかもしれませんが、めちゃくちゃ作品を書いてるんですよね。

松尾芭蕉も確認されただけで1000句も詠んでいたらしいです。

コードもやはり、書いてきた量とプログラマーのスキルというのはある程度比例するなと思うときがあります。

「古池や蛙飛び込む水の音」

ぐらいなプログラムが書けれたら最高ですね⊂(^-^)⊃

 

お客様の声紹介:普段運転しないが効率のいい配送計画を問題なく作成できる

お客様の事例紹介です。

株式会社TTS様 配送計画の作成時間を半減

TTS様はインターネットの販売代理店で、チラシの配布をする際に、車でマンションにチラシを配布するそうですが、どの順番で回るか、という計画の立案にODIN 配送計画を使っていただいています。

今まではご担当者様がGoogle Mapを使用しながら配送計画を作っていましたが、物件ごとの移動距離をひとつひとつ確認しながら行っていたため、計画の作成に7~8時間ほど要していらっしゃったそうです。

株式会社TTSのご担当者の皆様

それが、ODIN 配送計画の導入で、半分の時間の4~5時間で作成できるようになったそうです!

嬉しいことですね~⊂(^-^)⊃

他にも、メリットとしていろいろ仰って頂いたのですが、私が印象的だったのが

・普段運転しないので、関東の地理を熟知しているわけではないのですが、ODINを使って効率のいい配送計画を問題なく作成できています。

というお話ですね。

そうなんですよ。

別に、運転しなくても、道に詳しくなくても配送ルートが作成できてしまう。

それが、ODIN 配送計画のいいところです!

 

あと、時々思うのですが、

Google Mapを使用しながら配送計画を作る。

これ↑、やってらっしゃる会社様がまだまだ多いと思います。(>_<)

1台の計画だったらいいと思うんですが、複数台の車両、時間制限などがあると一気に難しくなると思います。

ODIN 配送計画は月額ドライバーさん一人につき、2千円なので人件費を考えると相当コストパフォーマンス良いと思います。(初期費用は16万5千円)

 

TTS様でも

「少ないランニングコストで毎週3~4時間ほど削減できるようになり、その分他の業務に取り掛かることができるようになったことや配布ができる件数も増えたため費用以上の効果が出ております。
使用方法が簡単で業務の効率化を図ることができ、配布量も増やせているためコストパフォーマンスとしてはとても高いと感じております。

というお話でした。

 

ODIN 配送計画へのお問い合わせはコチラからどうぞ!

 

 

 

ハイパワーマーケティングという本を読みました

この本は、私が好きなYoutuberのまこなり社長が紹介していたので読みました。

結果、読んでよかったです。

どうやったらお客様のためになるのか。

それをいつも考えているはずなのに、日々の業務に追われていると、時々忘れかけてしまいます。

お客様のためになることを考える。それが一番大切なことだと改めて気づかせてくれるのが本書の一番いいところですね。

各論でいいなという気づきは、次の点がありました。

 

①お客様が製品を試すときに、なんのリスクもないことを強調する。

→弊社も2週間お試し、というのをやってますが、確かにお客様からすると

「ん?何か契約させられるのでは?」

と思ってしまうかもしれませんね。

実際、なんのリスクもないです。これをもっとわかりやすくしないといけないですね。

弊社の販売しているODIN リアルタイム配送システムでは、申し込みなしでお試しができるんですよ。

これは、ビジネス用のソフトとしては非常に珍しいと思います。

他の会社さんは、まずは営業マンと話をしないとお試しができないのです。

私は、私がお客さんだったらまず試してみたい、と思いましたので、すぐに無料お試しができるシステムを用意しています。

競合他社さんがまずは営業マンと話さないとお試しができないようにしている理由もわかります。

まずは、お試しのシステムを作ることが面倒だし費用がかかる。

次に、競合の調査などで使われる可能性が高い、です。

弊社ではこのリスクを取ってます。

 

②会社の誰もがUSPを語れるようになる 

USPというのは端的に言うと「自社の強み」ということです。
USPを統一して発信する、特に営業部のメンバーが、これを全員語れるようにならないといけない、ということでした。
これは間違いなくやったほうがいいですね。(´ω`)
—————————————————————————————————————–
そのほか、私が印象的だったフレーズは

「レストランを始めるとしたら何がほしい?」

と著者さんが聞いたところ

「いいシェフ」とか「きれいなレストラン」「立地」

と答える人はいたそうですが、

「私はおなかをすかせた人がほしい」

というのが著者の答えだったそうです。

マーケティングの真髄ですよね。

 

ちょっと日本語訳が読みづらいところもありましたが、おススメです!