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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

平たく言うと、

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

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

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

というお話です。

 

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

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

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

 

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

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

 

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

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

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

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

 

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

 

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

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

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

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

@logibon

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

♬ アイドル – YOASOBI

 

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

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

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

とか

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

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

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

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

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

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

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

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

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

 

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

開発にかかった時間、

わずか1日弱。

 

すご！

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

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

 

 

 

 

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

 

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

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

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

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

 

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

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

例えば、

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

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

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

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

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

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

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

 

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

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

お試しはコチラから。

 

この本はどっかで読んだ本に紹介されていたのと、タイトルにいつも私が考えていることに共通することがあったので、手に取りました。

多分、プログラマーをしている人には普通に面白い本ですが、私にとって衝撃を与える、思い出に残る一冊になりました。

ハッカーと画家　コンピューター時代の創造者たち

 

まず、ハッカーという言葉に「物騒だな」と思われたかもしれませんが、これはここでは「優れたプログラマー」という意味で使われています。
「エンジニア」という広い意味ではなくて、「プログラマー」ですね。
著者のポール・グレアムさんという方は、後のYahoo！Storeとなるソフトウェアを作り、ベンチャー創業者として大きな成功を収めたことで知られる方、だそうです。

 

①アメリカ人はどうしていいプログラムを書くのか

 

冒頭の「メイド・イン・USA」という章にのっけから衝撃を受けました。
「アメリカ人はどうしていいプログラムを書くのだろう。」

どひゃー。これは、私もずっと考えてきたことなんですよね。私も日本人ですから、よく言われる
「日本ってさー　何かを改善するのはうまいけど、クリエイティブなものを作るのは苦手だよね~」
ってやつ、ほんとムカつきますよ。（アニメとかゲームとかはクリエイティブなもの作れてると思いますしね）

一瞬話はそれますが、私が会社を作った目的は
「日本にGoogleみたいな会社を作る」
ということなんですが、それは
「なんで日本にはソフトウェアの世界的に有名な会社がないんだろう？？」
と思ったことが理由です。

車や車の部品を作ることはうまいのに…。

本書の抜粋ですが、
「米国人は一度何かをしたいと思い立つと、それがうまくできないんじゃないかとか、世間的に角が立つんじゃないかとか、そういうことを気にしない。
何かしたくなったら、ナイキのコマーシャルみたいにするんだ。Just do it.というやつだ。」
映画やソフトウェアはこれでうまくいく、だそうです。

まだ抜粋が続くんですが
「「几帳面」なんて言葉は、優れたプログラマがソフトウェアを書く仕事ぶりからは最も無縁なものだ。
コードはピラミッドみたいに、慎重な計画をしてから苦労して組み立てていくものではない。
（どうして日本ではよい車が作れるのかという話で）日本人の文化に、デザインと職人の仕事を尊ぶところがあるのが重要なのだと思われる。…彼らは、ものをうまく作ることに取りつかれているんだ。」

うわー。
職人を尊ぶ文化は、よいソフトウェアを生み出すのには向いていない
と言い換えていいと思います。

さて、プログラマーとは、「職人」なのか。「芸術家」なのか。
日本では、「職人」に近いと思っている人が多いと思います。
きめ細やかな仕事、整理整頓されたコード、素晴らしいアーキテクチャー。

ここで、職人と芸術家を私なりに定義してみました。
・「職人」→　過程にこだわり、例えば「裏側を見せてもキレイ」とか「細部もめちゃくちゃちゃんとやってある」にこだわる
・「芸術家」→　成果物にこだわり、「裏側はぐっちゃぐちゃ」、「細部はメインの引きたて」

確かに、日本は「職人の手仕事」が大好きで尊ぶところがあると思います。
それがカッコイイと刷り込まれて生きています。
プログラマーは「芸術家」なのか、「職人」なのか。

非常に定義が難しいです。
そして、私が思う「職人」と「芸術家」の最大の違いは
・「職人」　→　他人が指定したもの、あるいは期待したものを作る
・「芸術家」　→　自分が作りたいものを作る
だと思います。

プログラマーと一口に言っても、仕事や会社によって全然変わってくると思います。
受託開発・SES・Sier・下請け企業のプログラマーさんは圧倒的に職人でいることを求められると思います。
自社開発でやってる会社さんでも、企画は企画部がやって、プログラマーは完全に職人でいることを求められていることがあります。
弊社は、プログラマーさんも仕様を考えて実装するので、芸術家の割合が高いです。
ちなみに、これは職人がいいとか悪いとか、職人さんをディスする話ではありません。
何より、「ご飯を食べていく」ことを考えれば、普通に芸術家は職人よりも貧乏であることが多いですからね（笑）。

でも、ポール・グレアムさんの主張に確かにそうなのかもな…　と思ってしまいました。
「職人を尊ぶ文化は、よいソフトウェアを生み出すのには向いていない」
というのは私の会社を作った目的に対するヒントを与えてくれるものでした。

②常識を尊ぶ人はハッカーに向いていない

 

これもなんかわかるなって感じでした（笑）。
「ちょっと変人だな」
という人が優秀なプログラマーには多いものです。（その逆は真ではないけども）

他大多数の人と同じことがしたいと思っている人が、同時に革新的なことを生み出せるはずはないのです。
品行方正・成績優秀な優等生が優秀なプログラマーかというとそうではないんですよね。
「口にできないこと」「異端であること」には価値がある、「道徳には流行がある」なども考えさせられました。

③優れたプログラマーは画家に近い。

 

わかる～。本書の抜粋で
「優れたソフトウェア設計者は、建築家がエンジニアではないのと同じように、エンジニアではない。
ハッカーは、画家が絵具に関する科学を理解するのと同程度にコンピューターサイエンスを理解していればよい。」

そうなんですよ。よく、
「文系だからプログラマーとかなるのは無理です。」
みたいなことを言う人はいるんですが、それはおかしいんです。

なぜなら我々がやっている仕事のほとんどが、現実という複雑な事象から、何かを抽象化して抜き出すことだからです。
それが画家のスケッチに近いと言われれば、そうなのかもしれない。
何か絵を描くときに、いきなり細部から描けませんね。

「作家や画家や建築家が作りながら作品を理解していくのと同じで、プログラマはプログラムを書きながら理解していくべき」
わかる～。
だから、上流工程とか下流工程、とかが分かれているプロジェクトってうまく行かないことが多いんですよね。
そして、スケッチというのは、書く練習が必要なんですよ。
優れた芸術作品というのは才能ではなくて、膨大な書く練習の上に成り立ってます。

ピカソとか、15万作も作ったらしいですからね。
経験から言っても、プログラマーはいっぱい書いたほうがいいです。

私も、プログラマーの新人に、
「うまくコードを書いてくれ。」
と言いません。
「とにかくいっぱい書いてね。」
と言います。

そして、書いただけではダメで、できれば誰かに継続的に使ってもらうことが必要だと思います。芸術というのは他人に評価されてなんぼだからです。

「多くの企業はハッカーにエンジニアたれと強要する。それがよくない。」
確かに、プログラミングをしていて思うことは、プログラミングに必要な能力って、エンジニアに必要な能力とちょっと違うんですよ。

ただ、あんまりこんなことを言う人はおらず、大体
プログラマー＝エンジニア
と世の中で理解されているように思います。

この話も、いずれ別のところで語りたいなと思います。

④サポートはプログラマーと密にやる

 

これはですね、弊社でも意識していることだったので、ポール・グレアムさんの会社でもそうだったのかと思って嬉しかったです。
抜粋＆要約ですが
「大企業ではユーザーサポートはユーザーの機嫌を取るためのものだ。ユーザーから電話がかかってくると、サポート部門は決まった形式にそれを入力し、時間が経ってからそれをプログラマのやることリストに加える。
Viaweb（ポール・グレアム氏の会社）では、ユーザーからバグ報告があがってきて1分もたたないうちに、サポートスタッフはプログラマの横に立っていて、プログラマが
『あちゃー、これはバグだね』
というのを聞いている。」

うちもですね、ODINの開発にあたり、同じような体制でやってます。(`･ω･´)

ODINのサイトに書いてあるんですが、
「サポート担当者と、システム開発者が机を並べ、緊密に連携を取って迅速にお客様へのご質問にお答えします。どうぞお気軽にご相談ください。」。
こうすることが、お客様の満足度を上げるだけでなく、よいソフトウェアを作ることにつながっていると感じています。

 

⑤ベンチャー企業について

 

「ベンチャーはほかのベンチャーと同じことをやっていてはいけない。ベンチャー企業の平均的な成長とは、すなわち、つぶれてしまうということだ。」
うう　そのとーりで肝に銘じないといけないですね。

 

うわ、めっちゃ長くなっちゃった。

でも、この本についてまだ書ききれないぐらいです！

 

新機能ができました！

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

長かった~(>_<)

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

ありがとう！

 

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

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