追加配車機能をリリース

さてさて、ODIN リアルタイム配送システムにまた便利な機能が追加されました!

その名も「追加配車」機能!!(๑•̀ㅂ•́)و✧

一度配送計画を組んだ後に

「いや、ここにも急遽行ってくれる?」

などと、荷主さんなどから注文があるのは、配送の世界ではよくあることです!

それを、完璧に最適なルートを組んだ後の、一体どこに入れたらいいんだー??というのは、配車をする方にとって、頭の痛い問題でした。

が、今後はそれをODIN リアルタイム配送システムが解決します!!!(`・ω・´)

 

「配車表」という機能があるんですが、そこにまず、案件を登録します。

その案件の右にある「配車」というボタンをポチッ とするだけ。

案件から配車を選ぶ

案件から配車を選ぶ

 

すると、複数人のドライバーさんのルートの「どのルートのどの部分に出したら一番早いか」を自動で算出します。

しかも、ベスト5まで出すんですよ!

追加配車で、どのルートのどこに追加したらよいかを提案する画面のスクショ

追加配車で、どのルートのどこに追加したらよいかを提案する画面のスクショ。

 

なので、自動にするわけではなく、どれにするか選べます。

しかも!配送先には時間の指定がついていることがあると思いますが、それが追加配車することによってずれてしまうのであれば、上記の画面の赤文字のように、警告してくれます。

便利ー!!

この機能は多くのお客様から要望がありましたし、早くも実装してからすぐに

「便利になってヨイ!!」

と数件コメントを頂いております!ありがとうございます。( ˊᵕˋ )

 

さて、この機能、なんと今回、不肖私が作りました!

もちろん、全部私とは言えず、案件周りも色々変更が必要だったので、そちらを主にS君に手伝ってもらいました!

S君はプルリクもきっちり見てくれるし、色々アドバイスもくれるし、モデルの組み立て方なども議論できるし、仕事が早い!!

本当に優秀なプログラマーです。( ˊᵕˋ ) ありがとうー!

以前、「配車前からルートの総時間がわかる新機能が追加」という記事の時に書いたんですが、5月に配送計画周りをかなり変えたんですよ。

専門的に言うと、リファクタしたと言いますか。

その時めちゃくちゃ苦労したんですが、その時からこの追加配車機能はどう実装しようか見えていました。

なので、こういう機能実装が早くできるようにリファクタしてありました。

なので、今回はスムーズに開発が進み、着手からほぼ1か月弱でリリースでき、しかも良いものが作れました!!

ちょっと苦労したポイントと言えば、最初は一番早いルートにすぐ追加したほうがよいかと思っていたんですが、自分で触っているうちに、

「いや、選べた方がいいな。」

と思いまして、上記のスクショのようなダイアログで選択にしました。

プログラマーの方だったらわかっていただけると思うんですが、こういう処理の中にダイアログを出すとかちょっと大変なんですよね

でも、これを出したことにより、配送計画を変更する人の意思が反映させやすいのでそうしました!

私的にも、自分でも使いやすくて気に入っている機能であります。

プレスリリース全文はコチラから。(急な受注に即時に対応できる追加配車機能がリリース

 

ODIN リアルタイム配送システムなんですが、6月は1日に4件も発注が入るなど、多くの引き合いを頂いております!!(>_<)

ありがとうございます。

今後もお客様が便利に使える機能をどんどん作っていきます!(`・ω・´)

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

 

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

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

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

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

 

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

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

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

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

 

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

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

例えば、

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

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

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

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

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

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

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

 

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

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

お試しはコチラから。

 

配車前からルートの総時間がわかる新機能が追加

新機能ができました!

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

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

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

 

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

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

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

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

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

 

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

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

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

ぜひ使ってみてください!(無料お試しはコチラから)

 

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

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

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

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

長かった~(>_<)

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

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

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

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

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

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

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

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

技術的負債を返すのは大変だ~(泣)

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

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

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

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

 

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

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

ありがとう!

 

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

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

 

スマホの位置情報で配送先の近くに来たら自動で配送先に通知できる機能ができました!

オーディーンリアルタイム配送システムに、さらに便利に使える機能ができました!

よくお客様からリクエストのあるのが、
「ドライバーさんが納品を始めたら知りたい」
「緊急事態などにすぐわかりたい」
というリクエストです。

すでに、オーディーンでは上記のような件に関しては、

①メッセージ機能
②位置情報で、いつ、どこで誰が何をしているかはわかる
③過去の位置情報の記録も見れる
④日報でも見れる
⑤配送先の人が、自分のところに来るドライバーさんの位置情報が近くなったらわかる

もあったんですが、パッとドライバーさんが通知を送って、それがどこで起こったのかを管理者が知る方法ってのはなかったんです。

が、ウチの若手のホープ、Sくんがこの度作ってくれました!

最近成長著しいSくんですが、この機能も凝った設計の割にサササと作ってくれ、すごいなと思いました!!(⁠≧⁠▽⁠≦⁠)
ありがとうー!!

色んな使い方ができます!

①事故を起こしてしまったので、管理者へ知らせたい
事故の際などは忙しいし、慌てているので場所が正確に報告できない場合などもあるので、便利です。
②納品先に入ろうとしたら納品先が込み合っていて待機になってしまったので、会社へ知らせたい
③納品が開始されたら、納品先にメールで知らせたい(置き配的な配送などにピッタリですね!)
④営業さんの直行時の報告(ここで仕事を開始します!というような通知)

私は、旦那様への帰るLINE代わりに使ってます(笑)

GPSで自動でできるんで、便利ですよ!!(๑>◡<๑)

しかも、これすごいのが、使い会社さんによってメールの文面まで変更できるんですよ!!٩( ‘ω’ )و
下記は設定画面のスクショです。

記録開始検知 メール機能

記録開始検知 メール設定

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

「人月の神話」という本を読みました

有名な本なので、タイトルを知っている人は多いと思います。
私もタイトルは知ってましたが、この度初めて読みました! 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人のプログラマーがいる大企業が出している製品よりも、ガレージの二人組の方がいい製品を出している、ということは起こるわけです。
我々もガレージ側なので、得られたことを生かしてがんばらないとな!って改めて思いました。

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

 

 

新年明けましておめでとうございます

新年明けましておめでとうございます。今年もよろしくお願い申し上げます。

さて、毎年元旦にはその年の目標を決めていますので、今年もやりたいと思いますがっ!

その前に、去年の目標はどうだったか、と言いますと…。

 

2023年の目標は

①とにかく仕事。仕事に全力投球!

②週に3回は体動かす。

 

でした。

 

については、相当やりましたね。。。

特に、年末辺りはとても忙しくて、本当に仕事ばかりの毎日を送っていました。

でも、やりたいなと思ってやっていることなので、なんにも後悔もないですし、年始にやるって宣言してたわけだから、できてよかったなと思います。✧٩(ˊωˋ*)و✧

 

②ですが、まー、何を運動というかによりますが、仕事ばかりしていたので、体が本当になまってしまってまして(^_^;)

かえって体を動かしたいな~ と思うことは増えて、夜中に家に帰ってから5分ぐらいは筋トレかHIITをやったりしてました。

なので、やったことにしてもいいかなって思います!(((^-^)))

 

さてさて、今年の目標ですが、次のように決めたいなと思います。

①会社の売上◯円!

です。公表はできないんですが(^_^;)

去年みたいに漠然とした目標だとやっぱり計測しづらいんで、やっぱり数字が必要ですよね。

 

②週に3回は体を動かす

これは継続ですね。しかし、今年は「家で筋トレ」とかだけじゃなくって、水泳とか、スケートとか、ジョギングとか、バドミントンとか屋外で誰かとする本格的なスポーツをもっとやりたいですね!

 

③新しい趣味を作る

去年は、人間関係が広がったこともあり、色々新しいことに誘ってもらえることもありました!今年もそんな感じで新しいことやれたらいいなと思います(((^-^)))

 

④姿勢をよくする

写真とか見ると私って姿勢悪いな~ としみじみ思いまして。姿勢をよくしたい!

 

さて、新年の今日はなんと香川にいます!

大晦日で閑散とする商店街と旦那氏。こういうアーケード、懐かしいですね。

 

旦那氏の実家をご訪問させて頂いてます。(❁´ω`❁)

今日は、お墓参りに行ったり、親族の皆様にお会いしたりしました。

初めてお会いする親族の方に

「暁子さんのブログを拝見しました。」

と言われて

「エッ…エッ…˚‧º·(´ฅωฅ`)‧º·˚」

とちいかわみたいに慌てちゃいましたね…。しかしこんなお目汚しなブログを読んでいただいてありがとうございます!

 

私の実家はお正月に親族で会ったりしないので、新鮮なお正月です★

その後、高松の有名な公園である、栗林公園へ行きました!

結構広い!

 

松がきれいに刈り込まれててきれいでした。

 

栗林公園。池の鯉がきれいでした!が、その写真は今手元にないのでした…。

 

2023年はいろんなことがあって、山あり谷ありでした!

しんどいと思うこともありましたが、周りの皆さんのおかげでなんとかやってこれたところがあります。

特に、私をいつも支えてくれて、美味しい料理を作ってくれる旦那氏と会社のスタッフの皆さんには感謝しています!
そして、友人の皆さんも話を聞いてくれたりアドバイスをくれたりありがとうございます。

最近はなんとか恩返しができるといいなと思う日々です。

 

ODINについて言えば、2023年は2024年問題対策に力を入れました。
予想していたことではなかったですが、お客様の層に変化があるのを感じています。
実際に配送をする方だけでなく、荷主企業さんや配送・運送は下請けに出している、という運送会社さんなどから多くの商談が入ってきています。

そして弊社に相談されることも結構複雑になってきているなという印象です。

物流/運送に対する課題が難しくなってきているなというのをヒシヒシと感じています。

 

運送向けパッケージソフトの業界では配送計画を立案できて、スマホでトラックの位置情報をリアルタイムにわかることができる製品というのは増えてきていますが、まだ弊社製品が一日の長があります。

 

そして、2024年がついに来ました…!!

ついに来たかという感です。

が、2024年問題について、まだ放置、なんとかなるだろうという会社さんも多いみたいです。( ˃ ⌑ ˂ഃ )

でも実は不安があるとか、少しでも業績を良くしていきたいという運送・配送会社さんは、ぜひ弊社にご相談ください。

ご相談はコチラから!

 

12月の後半はポンポン注文が入ってきて嬉しかったですね!

12月後半に発表した「全額返金保証」は2024年問題対策で、少しでも多くの会社さんにシステムで効率アップということを体験していただきたいという満を持しての施策なので、気軽にお試し、導入をしてみてください。

 

では、2024年も社員一同、オンラインコンサルタントをよろしくお願いいたします!

11月に社内イベントで御殿場に行ったとき。この時の話はこまた別で上げたいなと思ってます!

 

業界初!「全額返金保証」を始めました

メリークリスマス!ですね。

さて、弊社のODIN リアルタイム配送システムをご検討いただけるお客様にはクリスマスプレゼントになるといいなというお知らせです。

なんとなんと、ODIN リアルタイム配送システムで返金保証をすることにしました!(プレスリリース全文はコチラ

全額

です。

1年間

です。

台数制限ナシ

です。

ODIN リアルタイム配送システムは全額返金保証をします。

もちろんですね、やるのには葛藤もありました。

「こんなことやっちゃって大丈夫かな…。」

「返金保証って、個人向けの商品(ライザッ〇さんとか、英会話スクールとか)ではよく見かけるけど、法人向けの製品では中々見ないからな…。」

という不安です。

ただ、うちの製品に自信があるかと言われると、これめっちゃあるんですよ!

お客様の口コミがダントツ1位という事実99%という高い継続率。

導入して頂ければ、ものすごい費用対効果がある製品なのです。

導入しないなんて

「モッタイないよ~!」

と思っています。(`・ω・´)

 

ただ、導入に二の足を踏まれている方もいらっしゃるのは理解しています。

そのネックがやっぱり「費用」だと思うんですよね。

「費用を払ってしまって効果が出なかったらどうしよう…。(お金がもったいない)」

「使いこなせなかったらどうしよう…。(お金がもったいない)」

と思われると思います。

また、ちょっと効果が出るのに長い時間がかかる場合もあります。

2週間はお試しできるのですが、大体のお客様が、2週間がっつり使うというよりは、1日2日とかちょっと機能を触ってみられる、というケースが多いんですよね。

皆さん本格的にお試しするのが面倒なんだと思いますし、まずは購入稟議を上げるステージに乗るかどうか、ほしい機能があるかどうかだけをそこで試されていて、中々本格的に導入効果を図らないケースが多いようです。

つまり、「お試し」という段階ではお客様側では導入効果は推測に過ぎないと言えます。

そこで、

「うーん。これで本当に効果が出るのかな?」

「稟議出して上役から『本当にこれで効果が出るのか』とか『費用対効果はあるのか』とかなんだかんだ言われるのが面倒…」

「効果が出なかった場合に自分が責められたらイヤだな…」

となって導入を見送られるのはモッタイナイ!というのもあります。

 

しかし、そういうお客様に安心して導入していただきたい。

リスクは我々が取ります。

そのための、全額返金保証です。

 

こっから裏話です。( ˊᵕˋ )

これね~  返金保証をやるのは、相当製品に自信がないとできないとわかりました。

検討に1年ぐらいはかかってますからね。

きっかけは、ハイパワーマーケティングという本を読んだことでした。これが1月のことだったんですね。

いろんな数字を検討したり、やっぱりやっていいのかな感があって悩みました。

 

最終的にはリスクをどっちが取るかという問題なんですよ。

弊社では弊社製品に自信があると分かっているので、ウチが取ればいいだけの話なんです。

と結論づけました!!

 

代理店販売、App Store、Google Play経由などでは対象外です。

その他注意事項もありますので、詳しくはプレスリリース全文をお読みください。

お問い合わせはコチラまで!

配送計画と実績がわかりやすくなりました!!

なんと、この投稿から新しいURLに変わりました!!!

なんと今まで、さくらのレンタルサーバーのサブドメインで運用していたのですが、ちゃんとonlineconsultant.jpのサブドメインになりました!

あらためて、よろしくお願いいたします。m(_ _)m

 

さてさて、ODIN リアルタイム配送システムの配送計画と実績がわかりやすくなりました!!

配送計画と実際走行したルートの差分をわかりやすく表示します。

前にもあった画面と機能なんですが、以前はルートの確認ができるだけでした。

が!!!

弊社オーディーンの強みといえば!

計画と実績が一気通貫なので、照らし合わせが容易なことです。

 

配送計画がいくらうまくできても… 実際の走行がそれにあっていなければ、意味がありませんよね??

実際のコストとは実際の走行から算出されるものです。

配送計画を作った時に計画でコスト分析ができたとしても、実際に出て行くお金とイコールではありません。

なので、計画通りに走れているかは重要な情報です。

 

細かくブレークダウンすると、行った順番や、作業時間や待機時間が予想通りだったのかですよね。

特に、2024年問題で問題になっているのが待機時間です。

運送会社の社長の皆様、

「いや~ 待機時間が長いという話はあるんだけどな~」

で終わっていませんか??

〇月〇日、〇時~〇時までどこどこで待機でした、という情報があれば、例えば時間をずらしていくとか、荷主さんに交渉するとかなどの対策が打てます。

また、予定した配送計画通りに走っていないドライバーさんもわかります。

配送計画と実際走行したルートの差分

配送計画と実際走行したルートの差分をわかりやすく表示

 

今回のリニューアルで、次のような機能が増え、配送計画と実際の走行の差分がわかりやすくなりました!⊂(^-^)⊃

・配送計画の到着予定時間と、実績の何時到着かの差分を確認できる。 

 ・差分が±30分の場合差分の時間が赤くなる。 

・各配送先の到着希望時に間に合っていない実績時間が赤くなる。 

・ドライバーが行ってない行き先などがある場合通知。 

・ドライバーが順番通り行ってない行き先があったら通知。 

・配送計画と実走の全体的な差分を確認する。 


 

また、余談ではありますが、KPI分析、できてますか??

経営改善には大事な指標です!!

下記のような方法でも、ODINを使って経営改善ができますので、参考にしてみてください。

https://delivery-system.com/blog/2021/12/22/delivery-cost-reduction/

 

また、配送計画を作るときにも実際の待機時間、作業時間を計画に反映させることが大事です。

そういった配送ルート作成の改善にもつながります。

 

ぜひ、2024年問題対策、経営改善に役立ててみてください。

実際のプレスリリースはこちら

 

 

今行こうとしている配送先が指定できる機能ができました!

これはですね、ちょこっと地味な機能ですが。

大切な機能なので、書いておきます。

弊社のODIN リアルタイム配送システムは、配送業の皆様向けに、スマホの位置情報を使ってドライバーさんが今どこにいるか、何をしているかがわかる機能がついています。

そして、それを使って後で日報を作る機能があります。

日報にドライバーさんがいろんなコメントをつけられたり、報告ができたりします。

そして、そんなのいちいちやるの面倒だよ!と思われると思うので、これGPSを使って配送先の近くにいたら、たとえばA株式会社というところへ納品したとすると

「A株式会社」

というのを自動的に判定して記録してくれるんですね~。

ですが!

お客様の業態によっては、配送先が隣接していたり、場合によっては同じビルに入っていたりすると、このGPS判定がどっちになるかわかりません。

そこで、ドライバーさんがアプリから任意に到着した場所を選択したい、というニーズがずっとありました。

で、今回実装に至ったわけです。

今行こうとしている配送先をアプリから指定することができる画面サンプル

 

昔は、これの実装について難しく考えていたんですよね。

しかし、発想の転換があって、

「ん?これなら簡単に実装できるんじゃね?」

って思いついてできました。

実際に実装してくれたのは、弊社の開発の柱、M君と若手のホープS君です。o(>▽<)o

ありがとー!!⊂(^-^)⊃

 

機能開発って、プレスリリースするようななんか派手なこともそりゃ大事なんですけど、小さな使い勝手を向上していくことも大事だなと思ってます。(`・ω・´)

現在、2024年問題に向けて、導入のお問い合わせを多く頂いております!

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

 

 

 

PHPカンファレンス 2023 に行ってきました

今日は3連休の中日でしたが、蒲田で行われたPHPカンファレンスに行ってきました!

実は…。

ここ最近、PHPしか書いてない!!!

ぐらいPHPにどっぷりつかっている私です。(`・ω・´)

(プルリクはJavaとかjsとか見ますが)

何をやってるかというと、先日書いたように、弊社のお客様が3000社を突破したんですよ!!!

ありがたいことなんですが、エンジニアの方ならよくわかっていただけると思うんですが、お客様が増えると…

・トラフィックが増える

・データが増える

・想定されていなかった使い方をされるお客様もいっぱい出てくる

という技術面の問題に直面しています。(´ω`)

そして、めちゃくちゃソフトウェアアップデートをしてるんですよ。機能がめっちゃ増えてます。

複雑性というのが増えてます。

少ない人数で素早いリリース、素早い不具合対応、スケールの問題に対処するかのヒントを得るために、こういう機会は私にとって重要です。(`・ω・´)

 

昼過ぎから行きましたので、下記のセッションから見ました。

下記には私的なメモだけ書いておきます。

後日スライドなどが公開されると思います。(内容が間違ってたら申し訳ないです。)

 

Webアプリケーションのパフォーマンス・チューニングの勘所

https://fortee.jp/phpcon-2023/proposal/9dd2a5e3-5a3d-4d3b-b39f-0fb3e17bbd15

曽根 壮大さんという方のお話ですが、この方の話は以前も聞いたことがあって、とてもためになりました。

・Cloud watch log insightsが便利

・サーバーの状態を調べるのに、最初にOSのメトリクスを見るのがよい(CPU使用率とか)
病気の検査で体重を測るのと同じようなもの。

・デッドロックが頻発すると、CPU使用率が上がる

・デッドロックを完全になくすのは難しい。逆にタイムアウトを短くして、アプリでリトライするのがよいと思う。

・キャッシュは使わなくて済むなら使わないほうが良い
壊れたときに不具合対応が難しいから

・キャッシュは必ず一次データから取り出すべし

☆目の前のコードを直すことができるのは自分たちだけ という言葉が印象的でした。☆

 

スケーラブルサービス――疎結合に成長するシステムに不可欠な要素

https://fortee.jp/phpcon-2023/proposal/d81f49cf-009c-4953-af24-1582a827edef

成瀬 允宣さんという方のお話で、3月にもPHPerKaigiでこの方のセッションを聞いてとてもためになったので聞きました。

・サービスをスケールさせるのは、ソフトウェアをメッセージ駆動にするのがよい

・メッセージキューはありものを使ったほうがよい。Kafkaの名前が挙がってました。

・ただ、メッセージキューは使うのが難しい。順序保証やトランザクションの話が上がってました。

・イベントソーシングにする。ステートソーシングとは違う概念。
成瀬さんが、イベントソーシングにすると、よりオブジェクトの状態にあう、という話をされていたのが印象的でした。
インピーダンスミスマッチを解決できるのではないかという話でした。

はは~。インピーダンスミスマッチという言葉を私はこの日初めて知ったんですが、なるほど!と腑に落ちましたね。
インピーダンスミスマッチとはDBの中身は、ある日ある時の状態(ステート)なんだけど、コード上のオブジェクトは「なう」な状態を扱っていることが多いのでミスマッチになっていくという話みたいです。

イベントの方がオブジェクトのプロパティなどに近いので、このインピーダンスミスマッチを解決できるという話。

・イベントを記録しておく。そうすると、イベントのリプレイが可能
なんとDBを消すことさえできる。イベントをリプレイすれば戻せるわけなので!

・イベントの設計図を作る

・LaravelでもKafka使えるよ!しかし、Javaとかで使ったほうがいいです…。

実は今、私イベント駆動でちょうどイベントの設計を作ったりしているところなのでジャストにためになりました!!(`・∀・)ノ

成瀬さんに後でその感動を伝えたところ、前にお会いしたことを覚えてくれて
「あ、後藤さんですよね?」
って名前を覚えて頂いていたので感動しました!°(´ฅωฅ`)°。 成瀬さんは芸能人みたいな方ですね!( ˊᵕˋ )

安全にPHPでWebアプリ開発するために実践していること

篠田 北斗さんという方のお話でした。

いかにうまくPHPのソフトウェアを開発・メンテナンス・運用していくかということで実践的なお話ばかりでためになりました。

・readonly 使ってこ。(個人的な話ですが、使うの忘れちゃうんで!)

・MTTRの短縮化を目指す

・エラートラッキングツールとチャットツールを連携させる。ここではSentryの名前が挙がってました。
オオカミ少年にならないように毅然とした態度をとる。

→この話、どうしたらオオカミ少年にならないのか、毅然とした態度とは何なのか、懇親会で篠田さんに直接聞いちゃいました!
ウチでも、同じような構成(Sentry+Slack)でオオカミ少年化しているところが結構あるので…。(´ω`)
「Sentryでignoreするエラーを選べるのでそれでミュートすべし」
「Slackでエラーが来たらちゃんとつぶしていく」
おおー。教えて頂いてありがとうございました!┌o ペコッ

・ノートラブルシステムへの道 というスライドがよいので見る。
→見ました。https://speakerdeck.com/yamaz/notoraburusisutemuhenodao?slide=25
確かにいい話です。「機能追加がなくても、売れればシステムは傷み始める」というのがまさしくその通りだなと。


その後は、ちょっと休憩してて、LTを一通り見ました。

PHPInsightsで技術的負債の可視化始めました

 

・Gitで直近1年間のファイル別変更回数を出す。その後、循環的複雑度を出す。
変更回数 × 循環的複雑度 = ソフトウェア保守のコスト

うわああああ 確かに!!

入社半年を迎える新米エンジニアがカンファレンス・勉強会から得た学び〜半年後の自分に伝えたいこと〜

・知らないことは調べようがない

単純だけど、真実だな!って思います。

ネットだけで調べものしていると、「知らないことに遭遇できない」ということがよくあると思います。


なんと、今回900人ぐらいの人が参加したそうです!

大盛況ですね。

各地でPHP Conferenceが行われるらしいです。

その後、懇親会で多くの方とお話させて頂きました。

どんなプログラムを書いているかとか、今注目している技術とか、組織がかかえる問題とか、その方のキャリアとか、よもやまテックなことだけじゃないお話ができて楽しかった~ o(>▽<)o

Github Copilot導入しようか迷ってたんですが、結構導入しているとか、便利だよって話をお聞きして、ウチでも使って行こうと思いました!

皆さま有難うございました!!!

PHPカンファレンス