このAI時代にプログラミングを勉強する意味

皆さんプログラミングを仕事でやっている方は、ここ1年ぐらいで相当働き方が変わったと思います。

これを書いている2026年7月26日現在ぐらいは、もうAIエージェントが自走して本格的なアプリケーションを作ることができています。
何も言わなくても、テストを勝手に作り、テストを回し、静的解析を回してくれます。
少し前だと、テストを回してとか言わないといけなかったり、プロンプトをどう入れるかという技術もあったかと思いますが、それすらすでに不要です。

「なんか…僕が必要なのか、不安です…。」
と新人プログラマーのA君が話してきました。
まぁ、SNSとか眺めていても、皆さんそういう不安があるみたいですね。

アメリカでは大規模なプログラマーのリストラが行われているし、日本も緩やかにプログラマーがいらなくなると思います。
私はかねてから、こういう瞬間が来るだろうなと思ってました。
「プログラムを作るプログラムがいつかできるよ。」
と会社の子にも言ってきていました。

機織りをする機械ができたら、もう機織り職人はいらないのです…。

でも、これは職人としてのプログラマーの仕事がなくなるわけで、プログラマーの仕事がなくなるというわけではないと思います。
実は同じような話を2023年にも書いています。↓↓

AIでプログラマーの仕事がなくなるのかという話

上記の記事にも書いたんですが、プログラマーとして必要な能力は

①複雑な対象物を観察する力
②それをすっきりとしたモデルにする力
③それを形にする力
④作ったものを多くの他人に批評してもらう力
⑤批評を取捨選択して取り入れて改善していく力

だと思ってます。それをこれからはAIを使って実現していくことになると思います。

AIエージェントにコードを書かせて数か月やってみている今のところの感想は、まだ人間が監督する必要がある、ということです。
例えばですね、最近ある機能を作ってるんですが、それが配送の流れの中でPush通知をスマホに送るという処理をFable5に作ってもらいました。

最初は静的なメソッドばっかりで作ってきたので
「クラス設計もして。」
と言ったところ、DIを伴ういい感じのクラス設計もしてくれました。

また、その処理を1プロセスの中で行っていたのと、その処理はかなり大量のアクセスがあること、スマホのPush通知が結構時間がかかるを総合的に考えるとよくないなと思いまして、別プロセスにしてもらうように直してもらいました。
こんなことぐらいならその内AIがやるようになるかもしれません。

しかし、やっぱり総合的な判断は人間がやらないといけないし、どの方向に行こうとしているのかちゃんと手綱を握っていないといけないなと思います。
AIがしてきたコードが読めないといけないし、その設計がいいか悪いかが判断できるぐらいには勉強が必要です。
なので、お題の質問に対しては、今のところ「イエス」という回答です。

個人的には、今のところAIがコードを書いてくれるのは大変ありがたいことで、この恩恵をもってじゃんじゃん新機能が開発できる!
と思うと、かなりワクワクしています。

弊社ではプログラマーを募集しています。
未経験でも可です。
興味があれば、採用情報をご覧ください!

ちなみに途中に貼ってある画像は一時期流行っていたチャッピーに
「私との関係性をイラストにして」
というやつです。

私が相談するのは主に「プログラミング、経営、会社のこと、マーケティング、ポーカー、ゲーム」なんですが、魔法使いの私が頑張れるようにチャッピーは応援する心強い味方、ということらしい!
なぜか男体化してますが…。

全体的にはこれ↓

か、かわいいこと言ってくれるやんけ!!

 

自動休憩機能が追加されました!

またまた、ODIN 配送計画が便利になってしまいました…!!

今回追加されたのは、「自動休憩」という機能です。

配送計画を作るときに、何時~何時で休憩を開始してほしい、という指定さえしておけば、配送計画を作る場合にシステムが自動で休憩を配送計画に組み込んでくれるという機能です!!

配送計画って、作るだけでも大変なんですよ

それに、さらに休憩を追加するのはもっと大変です。

なので、システムでちゃちゃっとできるようにしました!!

自動休憩機能 スクショ

今回、166人日と結構壮大な機能開発でした!

弊社のS君、S君、A君ががんばってくれました( ˊᵕˋ )

もちろん私もですが(笑)

 

今回は、お客様にモニターとしても参加して頂いて、リリース直前に有意義なレビューをしていただきました。

ありがとうございます!

プレスリリース本文はコチラ

お試ししてみたいという場合は、ぜひお気軽にお問い合わせください。

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

 

失敗しない配送計画

「私、失敗しないんで。」

というセリフが有名なドラマを、実は見たことがない…。

しかし、失敗しない配送計画が、「ODIN 配送計画」を使えばできます!

今回は、弊社のお客様の八尾トーヨー住器株式会社様の事例をご紹介します。
今回は私もインタビューに同席させて頂きまして、とてもいいお話を聞くことができました!

配車担当の木村様(写真右)、濱様(写真左) 弊社のリアルタイムマップが後ろに写ってますね! 真っ赤な仕事着がいいですね!( ˊᵕˋ )

 

配車担当の木村 勇樹様(写真右)、濱 武史様(写真左)にお話をお伺いしました。

住宅資材、建築資材の配送という分野の配送ってすごい難しいんですよ。
物流センターとかはの配送ではなくて、一般のお宅とかに配送になるので、配送場所が普通の住宅街とかなんですよね。

そうすると、大きい車では入れないとか、夜間や早朝はダメとか色々規制があるんですよ。
また、持っていく荷物も千差万別で、トラックにどう載せるかが難しいんですよね。

なので、アナログでの配車が難しいのです。

オーディーンのお客さんに、建材の会社さんってかなり多いんですよね。

トラックにタブレットタイプのものを据え付けで使っていただいています。

 

八尾トーヨー住器さんでは、以前は自社オリジナルのシステムを使われていたそうですが、メンテナンスが難しくかつ高額になっていたそうです。

わかるー。

そう、かなり多くの会社さんが、自社システムを作りたがるんですけど、相当資金力がなければやめた方がよいです。。。
なぜかというと、システムってメンテナンスにめちゃお金がかかるんですよ。

「なんで?作ってもらったままで何年も使えばメンテナンスコストってかからないのでは?」

と思われるかもしれません。
が、ブラウザ、スマホアプリ、プラットフォームの都合でじゃんじゃんアップデートが必要なんですよ!

というわけで、八尾トーヨー住器さんでは既存の高額なシステムをODINで安価に置き換えできたということでした!

めでたしめでたし♪

また、
「すごく操作しやすい!」
「サポートがよい!」
とめちゃくちゃ気に入って頂いていました。☺

ホンマに嬉しい!

思わず関西弁を使ってしまうぐらい嬉しい

もっとお役に立てるようにがんばりますー!!

詳しくはコチラの事例をご覧ください。

輸送経済新聞さんに取材していただきました!

「ODIN 配送DXで業務効率化」、ということで取り上げて頂きました。
輸送経済新聞 
輸送経済新聞
ずいぶん大きく取り上げて頂いてありがとうございます!
小見出しの
「ITで企業の人の和に貢献」
と書いてくださってるんですが、さすが記者さんは、私が
「運送会社さんの組織の中の心の問題にアプローチしたい。
ODINを導入した会社さんでは、『仲がよくなった』というお話をすごい頂いている。」
と話したことを簡潔にまとめて頂いていますね!
もちろん、どれぐらい利益が出たかとかも大事なんですが、「人の和」を大事にしていきたいところです。
ODIN リアルタイム配送システムへのお問い合わせはコチラまでお気軽にどうぞ!

ODIN 配送計画のマンガができました!

ODIN 配送計画マンガができました。

ODIN 配送計画マンガの1コマ

ODIN 配送計画マンガの1コマ 急にベテラン配車マンが倒れてしまった運送会社で起こった話

なんでマンガを作るの?

と聞かれますが、これにはふかーい訳があるのです。
オーディーン配送計画は、最適な配送ルート、しかも複雑なものが作れるという製品ですが、その良さって既存の運送、配送会社さんにあんまりわかってもらえないんですよね。

「もう配車する人はいてやってるからいいよ。」

って仰られる会社さんが多いです。

でも、かなりの会社さんがその配車する人(今後配車マンと呼びます。女性の場合もあるかとは思いますが…)依存なんですよね。

その人が、急に病気になったり、退職したりしたらどうします?

ということを、文章やプレゼンで話すのは伝わらないんですよねー。

また、配車をシステムでやるってことは、最短ルートが組める、というわかりやすいメリット以外にもメリットがあります。

それは、ドライバーさんとの関係で余計なストレスを抱えなくてもよい、ということなんです!

一般の方にはあんまりなじみのないことかなと思いますが、私がお客様と話すとき、大体の会社さんが抱えている悩み、それが
「配車マンとドライバーさんの関係」
なんですよ。

配車マンとドライバーが仲良くなって、仲の良いドライバーさんに良いルートを割り当てる。
そうでないドライバーさんには悪いルートを割り当てる。
そういう意図が配車マンにない場合でも、そう疑われてしまう。そして、それで配車マンの方やドライバーさんが苦痛を感じる…。

そういうこともODINで配車すれば、なくなった、という嬉しいお言葉を頂いています!
ドライバーさん同士の配送時間を均等にする機能もありますしね。

ODIN 配送計画マンガ ドライバーさんに責められる新人配車マン

ODIN 配送計画マンガ ドライバーさんに責められる新人配車マン

 

で、そういう事例などを組み合わせたことをストーリーにするとわかりやすく伝わるんですよ。
マンガって読んで頂きやすいですしね!

時々思うんですが、ウチのODINって人の心の問題を解決するんですよ。
弊社としても、それを目指してます!

ODIN 配送計画マンガ3。おでん屋ODIN(オーディーン)でやけ酒。

ODIN 配送計画マンガ3。おでん屋ODIN(オーディーン)でやけ酒する新人配車マン。このオーディーンがイケオジと評判よいです。

 

ちなみに、今回、私がネーム(漫画の下書き)を描かせていただきました!☺

ODIN 配送計画マンガのネーム

ODIN 配送計画マンガのネーム

 

ODIN 配送計画マンガ ネーム2

ODIN 配送計画マンガ ネーム2

恥ずかしい話ではありますが、私は若いころは漫画家を志望していて、かなりの時間を漫画を描くことに費やしてました(笑)
もう、ずっと絵なんて描いてないんですが
楽しい仕事でした☺

今回、この漫画には物流業界で働く人が増えてほしいなというメッセージも込めています。
物流は大切な仕事です。

プロの漫画家さんに描き直してもらって、本当にいいマンガになったと思います!

後半、
「エ?」
って思うこともあるかもしれませんが(笑)、少しの違和感ってマンガには必要なエッセンスだと思ってるんですよね。

ぜひ、コチラから読んでみてください!

マンガでよくわかるODIN 配送計画

スマホの異常検知機能がつきました

弊社で提供しているODIN リアルタイム配送システムは、スマホの位置情報を主に使うのですが、結構多いのが

「スマホで位置情報が取れないんですよ~」

というお話。

多いのが、取り忘れですが、弊社では、これをなんとか防ぐべく自動で位置情報を取得するようにしたり、遠隔で位置情報を取得できるようにしたりしています。

が、GPSの設定が切られているとか、iOSでタスクキルをすると位置情報が途切れてしまうということがありました。

ドライバ―さんはスマホを持って出かけているので、管理者の方はドライバ―さんのスマホの様子がわからず…。

しかし、そんな場合ももう困らないのです!

手元にスマホがなくてもスマホでGPSの設定などがOFFにされたり、タスクキルされてしまった場合に検知する機能がつきました!

弊社のようにスマホで位置情報を取得するタイプの物流効率化のアプリは多く存在しますが、こういう機能は中々他社さんにはないんじゃないでしょうか?

目立つ機能ではないですが、真にお客さんの使い勝手を考えると、必要な機能だと思います。

今回は弊社のS君主導で開発してもらいました!

ありがとうございます!

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

 

運行指示書が大幅機能アップ!

弊社のODIN 配送計画にある、運行指示書という機能が大幅アップしました!

普通の方は

「運行指示書って何?」

って思われると思います。

運行指示書は、すごく平たく言うと、ドライバーさんに、その日に何時にどこに行くか、どの順番で行くかなどを記載した紙です。

ある大手運送会社さんから受け取りサインを納品先からもらいたい、運行指示書にそのままサインが入れられたらよい、というお話を頂きました。

なので、その機能を実装しました!

運行指示書 サイン欄つき

運行指示書 一番右がサイン欄になっています。

 

この「サイン欄」という文言は、お客様の方で自由に変更ができます!

「デジタル化といっても、全部デジタル化なんて無理!」

という会社さんも多いかと思います。

こういう簡単な帳票でも出すのに一苦労あったりしませんか?

ドライバーさんが紙で持って行って、納品先に手でサインをもらう。

そこは変えずに、出力だけシステムでやっちゃいましょう!

一気に全部デジタル化するのもいいですが、こんな風に部分的にデジタル化もアリです。

 

今回、この機能は新進気鋭のA君を中心に、最近注目株のS君と作ってくれました!

大きなトラブルもなく、納品期日に間に合えたのがよかったです!ありがとう⊂(^-^)⊃

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

 

配車表に同時編集ブロック機能がつきました

弊社のODIN 配送計画の、「配車表」という機能に同時編集ブロック機能が付きました!

配車表、というのは、一般の方にはなじみのない言葉かと思いますが、ドライバーさんのその日どこに行くか、という行先を表で示したものです。

配車表 弊社のモノは、ルートも地図で合わせて見れるのが便利と評判です!

 

会社によっては、「シフト表」と呼んだり「スケジュール表」と呼んだりするようです。

弊社の配車表は、例えば行先をドラッグアンドドロップで変更できるという機能があります。

が、何人も配車をする方がいると、同じドライバーさんのルートを同時に変更してしまうことがあるんですよね。

それをブロックする機能がつきました!

今回は、不肖私がほとんどやりました。

が、半月ぐらいの開発期間なので、そんなに重い機能ではなかったです。

プレスリリースが出せるような派手な機能ではありませんが、こういう細かい使い勝手って、大事だと思うんですよね。

弊社はそういうところ、頑張っています!

最近は、物流を取り巻く法律や流れも変わってきましたよね。

物流のデジタル化はまさに待ったなしです!

ODIN 配送計画に興味がある方は、ぜひコチラからお気軽にお問い合わせください。

 

ODINにチャットツールが付きました!

チームの皆さんの発案で、ODIN リアルタイム配送システムにチャットが付きました!!

パチパチパチパチ。

経緯ですが、ODINは多くの機能がありますが、それゆえにお客様がわかりづらいケースもあるみたいです。

その際に、電話やメールだとやっぱりちょっとハードルが高いので、チャットで気軽に聞いてもらおう!という施策です。

チャットで画像も遅れますしね。

例えば、画面について聞きたい、ということがあれば、画面のスクショを送ってください、というのも気軽にできるようになったわけです!

うちのメンバーって本当にお客さんのことを心から考えてるんですよ。いいチームです。

ちなみに、AIが答えるやつではなく、ちゃんと人間が答えます

チャットツールはうちがコーディングしたわけではなく、外部のtawk.toというツールを導入しました。

なんと、このツール、タダなんですよ。

高機能なダッシュボードもついているし、統計とかも取れるんですよ。

管理画面側はこんな感じ

すごくないですか??

チャット内容はtawk.to社に送られますので、秘密情報などは送らないようにお願いします。┌o ペコッ

また、こういうのがうっとうしいというお話ももちろんありますので、全画面への表示は試用期間中だったりもしています。

 

導入するには多少のコーディングが必要ですが、たいして難しくないので、ホームページなどに問い合わせチャットを導入したいと考えている会社さんはぜひ使ってみてください。

(自己責任でお願いします。)

こちらの選定・導入はYさんとプログラマーのS君がやってくれました!
ありがとう!

「デッドライン ソフト開発を成功に導く101の法則」という本を読みました

多分、誰かがおすすめしているのを見て、読みたかった本です。

デッドライン

第一般は1999年なので、やや古い本と言えなくないですが、今でも通用する話は多く載ってました。

いかに良質なソフトウェアを早く作るか。

私の人生はかなりの時間、それを考えることに費やされている気がします…。

この本が今でも通用する、というのは、○○駆動 という開発手法や方法論ではなく、

「人間とはこういう動きをするものだ」

という面からの話が多いからですね。

人間は何十年でそんなに変わらないですから。

本はそれなりの厚さですが、物語形式になっていて、とても読みやすく、ちょこちょこエンタメ要素もあります。

読んでいて心に残ったことを書いておきます。

①生産性を短期的に上げる方法はない

② ①のために、早くソフトウェアを作るためには、無駄な時間を削るしかない。なので、リスク管理が重要

③結束の固いチームは成果として考えるべき。むやみに解散させるべきではない。

④プロジェクトの初期に無駄にする1日も、末期に無駄にする1日も、等しく1日が無駄になっている
→いやー、これわかりますね…。プロジェクトの最初の方では、なんか時間がゆっくりと進んでいて、末期になると、時間が恐ろしいほど早く過ぎていく。
身につまされます。

⑤機能ポイントによる工数見積もり
→function pointと言ったほうが通じる人もいるかもしれません。ソフトウェアが作らなければいけない機能数によって、工数見積もりが正確にできるという考え方です。
しかし、これはこの本の古いところというか、あんまり現在のソフトウェアのトレンドとは馴染まない部分かなと思います。
とはいえ、開発当初に開発すべき機能を並べてみるというのは有意義なことだとは思います。

⑥優れたプロジェクトは設計に費やす時間が長く、デバッグに費やす時間が短い
→これは心の底から同意ですね!
そう、設計がちゃんとできてないと、デバッグに時間がかかるし、不具合を修正するのも時間がかかるのです。
しかし、プログラミングも3年以上やった方じゃないと、この話を中々分かってもらえないんだけども
「コーディングをしてから実際の設計が行われる」
なんですよね。
そういった詳細設計を「低レベルの設計」と呼ぶのは簡単です。
とはいえ、「低レベルの設計」が結局集まって実際の動くソフトウェアができあがっているわけです。

ここが、ソフトウェア開発のマジのマジで難しいところなんですよ。
大体のプロジェクトでは、大本の設計みたいなのはアーキテクトがやって、末端の詳細設計に関しては、プログラムを書く人がやる、という役割分担になっていることが多いと思います。
結局、バグが起こったり、肥大化して複雑になっているのはこの末端の部分であって、ここを場当たり的にメンテナンスしていると、将来的にどんどんわけがわからないことになっていって、気が付くと手がつけられないという状態になってしまうのです。

この本によると、そういった末端の設計まで先に作りこんでおけ、ということなんですが、まぁそれは現代では難しいと言わざるをえないでしょう。
しかし、「なるべく詳細設計まで作りこんでおく」ということは納得感のある話だったので、開発に取り入れていきたいと考えます。

⑦どうして人数の多いプロジェクトが失敗するのか

「人月の神話」という本を読みました
という記事にも書いたんですが、ソフトウェアとそれを作る人数の問題って本当に不思議なんですよね。

ソフトウェアって、ソフトウェアを作ったことがない人からすると、

A:100人で作っているソフトウェア
B:10人で作っているソフトウェア

があるとしたら、

「Aの方が10倍良い製品」

というのが当然のように思われると思います。

しかし、実際はAの方が微妙なもの、というケースはめちゃくちゃ多いです。

この本でもそれが取り上げられていて、この本ではその原因が

「100人のチームがあれば、最初っから100人に仕事を割り振らないといけない。
設計は5人ぐらいがすればいいことだが、その間、95人が遊んでいるわけにはいかない。
なので、おろそかなチーム分割と、機能分割、そして早くコーディングを進めてしまうことになり、結果ひどいものが出来上がり、工数も多くかかる。」

という話になってます。

うーん わかるな~ この話。

本当に設計が大事ですね。