スマホで荷積み・荷下ろしを記録する機能ができました!

またまた… ODIN リアルタイム配送システムにすごい機能ができてしまった…!!

【業界初】当日の荷物の内容と場所を“見える化”!スマホで荷積み荷下ろし機能

荷積み機能と荷下ろし機能はスマホで荷積み、荷下ろしが記録できる機能です。

え?それで何が嬉しいんですか??

という声が聞こえてきそうです。

これはですねー、元々はあるスーパーさんにこういう機能があったらいいなといわれたのです。

スーパーさんって荷物がどれぐらいあるか、市場に行かないとわからないんですよね。

青果を運んでいる業種ではよくあることです。

で、ドライバーさんが何をいつどれぐらい運んだのかを日報として記録するんですが、それが手書きなんですね。

で、荷主さんに運んだ荷物の量で請求をするんですが、その際にその手書きの日報から事務員の方がExcelに転記するわけです。

手書きは読むほうも字が汚くて見えないとか、どこかに行ってしまうとかで管理が大変です。

それで、これをODINのスマホアプリでできないか、というご相談があり、作ったわけです。

 

他にもいろいろな業種の方から同じような機能はご要望頂いてました。

産廃業、回収業、貴重品を輸送する会社さんなどからです。

貴重品の輸送に関しては、今もう荷積みが終わったのか、運ばれているのか、荷下ろしされているのか、どこにあるのかがわかりたいということです。

荷物追跡マップ 荷物が地図上でどこにあるかわかる

荷物追跡マップ 荷物が地図上でどこにあるかわかる

また誤配を防ぐ機能もついてます。

誤配って大きな問題で、運送・配送では絶対について回る問題なんですが、誤配の何が問題かというと、それが紛失につながったり、再配送になって人件費がかかるということが挙げられます。

運送会社さんによっては、誤配1件につき、いくら支払うという契約をされている場合もあるようです。

誤配防止機能

誤配防止機能

機能についての詳細は、下記のページにもあります。

・荷積み・荷下ろし

・荷物追跡マップ

今回、大変だった点は、アプリなんですが、項目をフレキシブルにしたいというお客さんの要望に応えるために、

画面をどうにでもできる

ようにしたんですよ。プログラム書く人だったら、この大変さをおわかりいただけるだろうか。

項目、項目の順番、どのように表示するか(選択式、自由入力、自由入力+選択)を、全部お客さんが選んで好きに表示できるようにしたんですよ!!

荷積み 荷物記録機能 スマホ画面スクショ

荷積み 荷物記録機能 スマホ画面スクショ

上記の荷物の入力画面を、下記のようにシンプルにもできます。

荷積み記録機能 荷物入力 シンプル版のスマホスクショ

荷積み記録機能 荷物入力 シンプル版のスマホスクショ

入力画面は、他にもオートコンプリートという機能をつけまして、これもかなりイケてる!!

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

さて、今回は追加した機能でできることが多すぎてプレスリリースに何を書くべきかめちゃくちゃ迷ったぐらいです。

ここ3年ぐらいで一番大きなバージョンアップとなりました。

オーディーンにとってのターニングポイントになりそうな機能です。

開発期間、半年超、変更したソースコードは○万行を超えています。

 

ホントに大変でした。

ただ、うちのプログラマーさん達が優秀だからできたわけで。

若手のホープs君、まだ勉強中ながら熱意をもって開発してくれたs君のおかげです!

ありがとうー!!

不肖私も、設計をしAndroidアプリを作り、とかなりこれにかかりきりでした。設計は、一部S君に任せた部分もあります。

早く、多くのお客様の役に立ったらいいなと思います( ˊᵕˋ )

ご興味あれば、ぜひコチラからお問い合わせください!

PHPカンファレンス2025の感想

昨日、PHPカンファレンス2025に行ってきました!

感想を書いておきます!

今回は6月にあるというのをすっかり失念していたので、危うくいかないところでした。
また、仕事が最近重めのプロジェクトがやっと終わったところで、プログラミング大好き人間の私でも
「週末ぐらいはプログラミングと離れていたい…」
と思っていたところだったので、ちょっと参加に迷いましたが、いつもなんだかんだ行ってよかった!となるので、重い腰を上げていきました!

結果、やっぱり行って200%よかった!です!


拝見したトークについて書いておきます。

皆さんがスライドを上げていてくれるので、とても便利で助かります!

①MySQL5.6から8.4へ 戦いの記録

私は最近はDBのことは任せているので、他の担当者の参考になるかな?という目線で聞いていました。
実際の体験記はやっぱり価値があります!
ゼロ日付気を付けないとですね…。

②PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則

プロパティフックという機能ができるのは知らなかったので、勉強になりました!
後、スピーカーの方が
「リスコフの置換原則の『共変・反変』という言葉が僕は大嫌いなんですよ!」
と言われていたの、100%同意(笑)です。⊂(^-^)⊃

そう、『共変・反変』って何なん?と私も常々思います。
難しいし、日本語でも意味がわからないし。はんぺん?はんへん?

リスコフの置換原則を巡っては、私もこれがなんか難しく伝えられすぎているのでは?と思うことがあります。
いつかスライドのネタにしようかな。

③AIプログラマーDevinはPHPerの夢を見るか?

今はやっぱりAIでコード書けるの、どこまで行けるかは皆さんが気になるネタだと思います。
Devinはどうなのかな?と気になっていたので、聞いてみました。

「リーダブルコードを読ませて、これに沿ってリファクタして」
と言ってみて、
・何を学んだか、何に苦労したか
・指示の出し方は適当だったか
・自分で自分をほめてあげたいところ
・後輩に伝えたいこと
・挑戦したいこと
を聞く、というのは私の発想にはなかったので、面白かったです!

本当に、人間の新人プログラマーみたいな答えが返ってくるんですね(笑)

タイトルは有名なSF小説ですが、SFの世界になったな… と改めて思わせられました。

④設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
https://speakerdeck.com/panda_program/how-to-write-clean-objects

立ち見が多く、人気のあるお題なのかな?と思いました。
プログラマー同士会話するときの前提を合わせておくってだいじですね。
オブジェクト設計スタイルガイド、早速購入しました!!


で、オフライン参加の目的としては、やはり飲み会も大きな比重を占めております!
リアルにいろんな方の顔を見て本音が聞けるのは大きい!
プログラミングの話題だけでなくって、会社の話、転職の話、採用の話など、聞きたい話題がいっぱいです。

もちろんね、こういう知らない人だらけのパーティー、苦手!って人多いと思います。
私も苦手です。
でも思い切って話しかける!を毎年がんばってやっております。

今回の感想は、
「女性が増えた!」
ってことですかね。
PHP界隈は女性のPHPerさんがSNSとかで盛り上げてくれているからでしょうか?
嬉しいことです。

じゃんけん大会で名古屋のPHPカンファレンスのTシャツももらえました!
名古屋出身なので、これは嬉しい!

めちゃくちゃ大きいサイズでもらいました。XXXLとかかな?

 


さてさて、末尾ではありますが、弊社はプログラマーの勉強会参加も奨励しております!
休日に参加したら、その分「勤務」扱いになり、代休とお給料が出ます。(事前申請と許可は必要)

ぜひぜひ、話を聞くだけでも結構なので、弊社にご興味ありましたらご連絡ください!
採用情報はこちら↓
https://onlineconsultant.jp/recruitment/

 

クラス設計の手順

 クラス設計の手順

というスライドを作成しました。

<対象>
・プログラミングを始めて3年以上
・オブジェクト指向でプログラミングをしている
・クラス設計などを担当するようになったが、設計とはどうすればよいのかわからない
・なんだか設計が後一歩と感じる

クラス設計に関して、どういう設計がよいなどの論は多くあるが、どうやったら設計ができるのかという論はあまりないので作成しました。

良かったら読んで感想を教えて頂けると嬉しいです。

前回はこちら↓

どうして僕の作ったクラスが手続き型と言われなきゃいけないんですか(プログラミング)

「クリーン・アーキテクチャー」という本を読みました

言わずと知れた有名な本ですよね!

設計とアーキテクトは一緒の意味。

クリーンなアーキテクチャーを作ることが早くソフトウェアを作るために必要、という話が冒頭にあります。

いや、本当にそうなんですよね。

人数がいくらいようと、微妙な設計のソフトウェアは生産性が地に落ちてしまいます。

なので、とにかく設計が大事です。

ただ、私は経営者でもあるので、市場に投入するスピードも必要だということも理解しております…。

ここは本当にジレンマなんですが、要はバランスとしか最終的に言えません。

あまりに設計がずさんなものは、いくら早くてもリリースしないほうがいいですし、かといって設計にこだわりすぎてリリースがずっとできないというのも問題なんですよね。

リリースしてから気づくビジネスニーズというのはよくあることで、そのために設計を直さないといけない、ということもよくあることです。

多くのプログラマが間違ってとらえている話があるそうです。

「システムが動作することと、簡単に変更できることとどちらが大切か?」

多くの人が、動作すること、と答えるでしょう。

しかし、簡単に変更できることの方が重要だと筆者のボブおじさんは言います。

完璧に動作するが、変更できないシステムと、変更できるシステムだったら、後者の方にバリューがあります。

まー、そりゃそうですね。

後者は動作するようにすればいいわけですからね。

 

私も、19年近くプログラミングをしていますが、本当に設計が大事です。

これがおろそかにされていたら、プログラマーは常にバグと戦わねばならず、プログラマーの仕事のほとんどがバグと戦う仕事になってしまいます。

なので、あるプロジェクトが後半になってきたとしても、設計に問題があるとなれば、ウチではリリースを延期することもやむを得ないと私は思います。

 

さて、この本については多くの人が解説を述べていると思うので、ここで詳細を書くのはやめにして、私が特に心にとめておきたいことだけ抜粋しておきます。

①安定した抽象に依存すること

コード本体もそうだけども、画面などの変わりやすいものにテストが依存しないようにする。
テストを直すのが面倒すぎて、画面を直したくないという事態になる。
②フレームワークを選択するのは結婚、不平等な契約である。
③SOLID原則を大切にする。
特に、オブジェクト指向の一番の良いところは、SOLIDのDにあたる、依存性逆転の法則が使える、というところだという視点は目から鱗でした。
④ソフトウェアアーキテクトはプログラムを書き続けないとダメ
そうですか…。でも、これめっちゃわかります。。。
実は、私は2年前ぐらいまで、第一線でコードをあまり書いていない時期がありました。
結果、あんまりよくない事態に終わった気がします。

 

 

コードの動作を口で説明してもらう

私はうちのプログラマーさんに

「このメソッド(or クラス)が何をしているか、口で説明して」

と言う時があります。

多分、言われた方は

「え、なんで?後藤さんはコード見てもわからないからかな?」

「面倒だな…。」

と思うかと思います。(笑)

 

しかし、これは意図があってやっていることです。

どういう意図かというと、

そのコードがどういう意味なのか、その人がコードと違う形で出力する必要があるから

です。

大体、「口で説明して」と言って、スパッと帰ってこない場合は、そのコードがよくないケースが多いです。

そういうコードは

・やってることが多すぎる

・書いた本人も実行 or デバッグしないと結果がわからない

というコードなんですよ。

当たり前なんですよね、作った人が何をしようかわかってないのであれば、微妙なものができてしまうのは。

 

書く、言う、図にする。

これらは考えを人に伝えるために重要です。

そして、人というのは他人だけではなくて、自分も含まれます。

人に悩みを聞いてもらって、すっきりした経験がある方は多いと思います。

問題が明らかになるからだと言われていますよね。

プログラミングも一緒です。

プログラムを書いたことがない人にはわかりづらいかと思いますが、プログラミングって抽象的なモヤモヤっとしたことばっかりなんですよ!!

抽象的なモヤモヤっとしたことをいかにわかりやすくするか、というのがプログラマーの仕事なので、口で言うのは、自分で問題を整理する、そのプロセスです。

逆に、私もプログラミングの設計などで悩んでいる時に、スタッフの方に聞いてもらって解決することも多いです。

 

特にAI時代において、小難しいコードを書くこと、小難しいコードを読むことはAIを使えば誰でもできるスキルになっています。

しかし、モヤモヤしたこと、抽象的なことを整理することは、今のところ人間の方ができます。

なので、そのスキルを磨いたほうがよさそうです。

書いたり、話したりしていきましょう!

コーヒーでも飲みながら