Kくんの発案で、2月から、不定期に弊社の社内のプログラマーさん向けに勉強会を行っています。
講師は有志。
なんですが、弊社のデベロップメント課の皆さん（プログラマーのチーム）は大変意識が高いので(`･ω･´)
全員がやってくれました！⊂(^-^)⊃
なんとM君は2月~5月で2回もやってくれました。スバラC。
皆さん、やっぱりプログラマーになろうという人は勉強が好きなんですね( ˊᵕˋ )
学ぶことって楽しいですよね～。
私も、日々これ勉強ですし、何かを教えてもらえるってありがたいことです。感謝ですね！
勉強にプラス、社内の人たちが、
「あー、こんなこと考えてるんだ」
とか共有してくれるのは、なんか新鮮な驚きや発見があります。
今後も続けていきたいと思います。
弊社では、現在プログラマーと営業を募集しています！
採用情報はこちらからどうぞ！
弊社の開発・販売している「ODIN リアルタイム配送システム」ですが、社員さんから提案あり
「かなり頻繁にアップデートしているので、これをもっとアピールしていっては？」
ということでした。
なるほど。
それで、調べたところ弊社は2021年の3月で
をしておりました。
1週間に3回強、ですよ。
すごくないですか？
システムを作ったりメンテナンスしたりしたことのない方からすれば、何がすごいのかわからないと思いますが、これも今までの弊社スタッフの努力のたまものなのです。
アップデートすると、通常はそれがきっかけになってバグが発生することがあります。
それを防ぐために、自動テスト、アップデート時に必要な処理が自動に行われるためのCIという仕組みを作ったりしてきました。(`･ω･´)
プラス、もちろん、アップデートする人員とテストする人員がいてテスト・監視体制を強化してきたのです。
弊社の社内でやってますので（ごく一部分外注）、動きが早いんですよ。以前、弊社のアプリは3億円ぐらいの価値がありますよ、と下記に書きましたが
昨今、アプリというのはメンテナンスコストがめちゃくちゃ増大しています。
3億円だったのが2020年の1月ですから、今はおそらく4億円ぐらいのアプリになってます。
開発風景
皆さんいつもお疲れ様です。m(_ _)m
3月30日ですが、次のプレスリリースを行いました。
法人さんで使う車を、もちろん時々点検しないといけないですよね。
いわゆる「車検」もそうですが、会社さんによっては、もっと頻繁に通常は点検業務をされているかと思います。
ODIN リアルタイム配送システムを使われているある法人様から次のようなご相談がありました。
「何十台もある車の点検日が、次にいつ、どれを点検すればいいのかを把握するのが大変だ」
そこで、この機能の開発に至ったわけです。
皆さん、Excelとかで台帳を管理されてるんですかね。
毎日、誰かがその台帳を見て… とか確かに大変だ。
しかも、忘れていて重大事故などが起きたらさらに大変ですからね…。
ODINなら、メールや、管理画面にメッセージを通知するようになっているので、便利ですよ！
サクッと調べたところ、このようなマイナーな機能のツールってないんじゃないでしょうか？？
業界初、なのでは？
とも思います。
皆さん、どのように社用車を管理されているんでしょうか？
もしよかったら、ODIN 動態管理という月額1ユーザーあたり1200円の、一番安い製品でもこの機能がありますので、ご利用頂ければと思います。
昨日は4月1日、日本武道館で300人の新入社員を迎えて入社式を行いました。
…と言いたいところですが、実際は普通に会社の会議室で新卒の新入社員を迎えて入社式をしました。(´ω`)
なんとなんと、去年度面接を行った人数は…
でした。
下記の投稿を書いたときは、まだ80人だったんですが、
それから74名も面接したんですね…。（つД｀)
その話はいずれするとして。
その中で選ばれたS君が入社されました！パチパチパチパチ。
弊社を選んでいただいて、ありがとうございます。m(_ _)m
入社式に、一応私から新入社員さんにメッセージを伝えました。
”
S君は自分で会社ややる仕事を選んで、今ここにいますよね。
それを忘れずにいてほしい。
いつの間にか、「やらされている」にならないように。
そして、仕事を楽しくする秘訣の一つは、全力でやることです。
片手間にやってることは、面白くないんですよ。思い出にも残らないですし。
周りに流されて、ぐちぐちいう、土日しか楽しくない社会人にならないでください。
”
そのあと、うちの社員の皆さんの自己紹介や新入社員さんのためになる話を一人ずつしてもらいました。
柱合会議みたいでよかったです！( ˊᵕˋ )
さて、去年度はうちの会社にとって、ターニングポイントともなるべき年でした。
・年商〇円を突破
・会社が移転
・社員さんで初めて皆勤賞を受賞する方が出た
よかった×100。
これも、ひとえにいつも弊社製品をご愛顧いただいているお客様、パートナーの皆様、スタッフの皆様、応援してくださる皆様のおかげです。
感謝申し上げます。
しかし、順調そうな時ほど危機が迫っているものです。(`･ω･´)
色々とやらねばならないこと、やりたいことが山積み…。
今年度も皆様のお役に立てるようにがんばります。
社員一同、よろしくお願いいたします。
先日、下記のプレスリリースを行いました。
えー、簡単に説明しますと、今日はどこに配送に行くか、という計画を配送会社の方が立てます。
それを配送計画と呼びます。
例えば
「A、B、C、D」
という配送先に行くことにしますよね。
で、配送に出発して、A、Bはもう配送し終わった時に、
「急遽、Xに行ってからYに行ってくれ！」
という話があったときに、もう行ったA、Bは除いて
「C、D、X、Y」
のどれをどう回ったら最短か、というのを計算することができるわけです。
「地味な機能じゃね~？？」
と思われたかもしれませんが、この機能、地味ですが画期的なのです！！(`･ω･´)
なぜかというと、配送した場所がわかっているシステムじゃないと、これができないんですよ。
弊社の「ODIN リアルタイム配送システム」はそれができるんですね。
これがないと、まず配送計画を作る人が
「どこにドライバーさんがすでに行ったのか」
をドライバーさんに確認し、それからA,Bを目的地から除かないといけません。
この手間って大変なんですよ。
今回も、私が設計をしまして、弊社の俊英N君が実装をしてくれました。
爆速で実装してくれて素晴らしいです⊂(^-^)⊃
配送計画の関係を今、ゴリゴリと修正しておりまして、どう修正しているかというと、
「開発しやすい設計」
に変えています。
これからも、どんどん機能強化を行ってまいります。(`･ω･´)
いやー、私が紹介するまでもなく、有名な名著だと思いますが。
ほんっといい本。
しかし、超読みにくい。
翻訳のせいもあるのかもしれない。
分厚いのもありますが、7月から読み始めて、なんと8か月もかかりました。(´ω`)
ぜひ、プログラミング始めて3年目ぐらいの人たちに読んでほしい。
プログラミングというのは難しいな、と感じ始めた人たちに読んでほしいです。
特に、内容は自分がかかわらない分野の業務システムなどを作るプログラマーにとって必要な知識があります。
とはいえ、C向けのプログラムでも大切な内容も含まれています。
内容は豊富すぎるのですが、あえて私が注目したことをまとめておくと
①その業務分野のプロの話をよく聞くこと。
②言葉の定義をちゃんとする（ユビキタス言語）
〇〇さんの開発しているあの機能とか言わずに、ちゃんと名前にする
そして、共同作業するプログラマー全員がその言葉をちゃんと理解する
③モデルをちゃんと作る
モデルというのは概念。概念がちゃんとしていないと、よいプログラムにならない
ここで、①が重要になってくる。その業務分野のプロの話していることをちゃんと理解して、何が重要なのかをつかむことが大事。
④ソフトウェアを常に進化させ続けるために、しなやかな設計にする
作らないことにはわからないことが多すぎる。（本当に）
常に前進するのを恐れない。
特に、私が衝撃を受けたのは③ですね。
モデルとは概念なのだ！！
プログラミングとは、概念を読んでわかるようにすることなのだ！！
もうね、ヘレンケラーが
「Water！！！！」
と叫んだような衝撃ですよ。
そういわれればそうなんだけど、地球が大きすぎて見えないように、それに気づいてなかった。
私の今までやってきたプログラミングは小手先だったなと感じました。( ﾟДﾟ)
やりたいことをやるためにプログラムが存在し、将来の自分やチームメイトがわかりやすいようなコードを志してやってきてましたが、そうか、概念か。
逆に言うと、プログラミングをしていて、はっきりしてくる概念もあるわけです。
この体験を最近しまして、今弊社で「ODIN リアルタイム配送システム」にある機能をつけているのですが、そこで、なんか仕様がモヤモヤしているところがあるわけですよ。
コードを見ると、配列でいろいろif文を駆使してなんとかやっている。読むのが大変なやつです。
で、ドメイン駆動設計の考え方に基づいてクラス設計をやり直したら、驚くほどコードがすっきりしまして。
そしたら概念がクリアになったので、仕様がすっきりしました。
そしたら、弊社のソフトウェアが持つ特徴、他のソフトにはなく、うちがお客様に届けるべき価値も明らかになりました。
というわけで、杏寿郎、お前もドメイン駆動設計（DDD）をしてみないか。
おススメの本です。
先日、次のプレスリリースを行いました。
きっと、何のことだかわからない方も多いとは思います。💦
配送会社さんが、その日にどこに行ってほしい、というのをドライバーさんに伝えるのに「配送計画」とか「配車表」などというのを作って、
9時10分 A会社
9時30分 B倉庫
みたいな感じで指示します。
で、実際にドライバーさんが配送に行きますと、今度は9時30分にB倉庫に着くかどうかが問題になってきます。
もし、9時半に着かない場合、B倉庫さんに前もって遅延を連絡しないといけないのです。（延着と言ったりします。）
なので、進捗を管理するのは大事なことです。
で、弊社ではドライバーさんが持っているスマホアプリでGPSを追尾して、A会社さんやB倉庫さんに到着したかどうかが管理者さんにわかるようにするのですが、それを手動で直したいというニーズが思いのほかありました。
GPSにも誤差がありますので、そのせいで間違った到着実績をつけてしまうこともありますし、同じマンションやビル、工場に配送先が二つあってたまたま寄った場合などに到着したことになってしまいます。
また、他のドライバーさんが行ったのでもう行く必要がなくなった、などの理由から到着済みにしたいというお話もあります。
それを防ぐために、今までもドライバーさんがアプリから手動で直す機能がありました。
が、管理者さん側にもほしいというお話がありました。
そこで、この機能のリリースになったわけです。⊂(^-^)⊃
なんか、やっぱりよくわからないですよね、きっと（笑）
実際の画面はこんな感じです。白丸のところがついていないところ、色がついている丸が到着したところです。この丸をクリックすると、到着していないところを到着済みに、到着済みを到着していないことに切り替えができます。
いや、地味な機能ではありますが、お客様のニーズを叶えるためによい機能だと満足しております。
それにしても、裏でやらなければいけないことはかなり大変でした…！！
データベースの設計変更、モデルの変更があり、弊社にとってはこれは大改造だったわけです。（地味な機能なのですが…！）
私が設計をして、実装は弊社の俊英、Nくんが実装してくれました。
画面遷移しなくて済むようにするために、ちょっと複雑な画面設計になってるんですけどね。
ですが、とっても早くできて、実質2週間ぐらいで実装できたんですよね。( ﾟДﾟ)
すご！
そして、ありがたい！！o(>▽<)o
早い。それはよいこと。
この業界においては、特にそうですし、弊社では特に重きを置いています。
N君はプログラムを書くのもうまいですし早いですが、他にもほかの人に気遣いがすごくあるし、遅刻や病休もしないし、お客さん対応もできるし優秀なんですよ。⊂(^-^)⊃
そんなODIN リアルタイム配送システムのWebサイトはこちらです。
本日、下記のプレスリリースを行いました。
https://www.value-press.com/pressrelease/262411
ご愛顧ありがとうございます！⊂(^-^)⊃
出前というのは江戸時代からあったそうですね。
冷やすものや温めるものがない時代はどうしてたんでしょうか？？
お客さんになるべく早くおいしいものを届ける。
その一助になれていることがうれしいです。
これからも、ODIN フードデリバリーをよろしくお願いいたします。
二度目の緊急事態宣言が発令されて、フードデリバリーや出前に新たに取り組まれるお店も多いでしょう。
で、配達をUber Eatsや出前館に集客を依頼するお店さんも多いですよね。
自店で配達員を雇用しなくてよい、というのはメリットではあります。
しかし、そのマージン大変高く、割に合わないと感じていらっしゃる飲食店さんも大変多いとお聞きしています。
「でも、集客もやってくれるんだよな~」
という声も聞こえます。
自店の店員で配達を行うと次のようなメリットがあります。
・お客様との接点ができる
・自店の店員なので礼儀や食べ物の配達について心配しなくてよい
・マージンを払わなくてもよい
加えて、私の考えにすぎませんが、走ってるバイクや自転車って結構目につきません？
Uber Eatsは特に、よく目につきますよね。
♪バーニラ バニラ~ と同じですよ。人間、身の回りのものでかつ動いているものに目が行きやすいんです。
つまり、自店で配達をして、バイクなり、デリバリーボックスに自店のロゴ入れられたら、かなり目につきますよね。
「あ、あの店、デリバリーやってるんだ～。今度頼んでみようかな？」
と思われるかもしれません。
「いやいやいや、費用がかかるでしょ…」
と思われるかもしれませんが、ステッカーを貼ればいいんです。
ステッカーぐらいならステッカー代だけですみます。それに、すぐ自作できそうじゃないですか？
試したわけではありませんが、ググるといろいろな方法が出てきますね。
もちろん、塗装とか頼んで、色も変えた方が印象には残ると思いますが。
ODIN フードデリバリーは、自店の店員さんで配達を行うお店のためのシステムです。
効率化を促進し、売り上げを伸ばすためのシステムです。
こちらも合わせてご検討ください。m(_ _)m
今月の12日にPHPカンファレンスありましたね！
今年は、オンラインの開催で、リアルタイムにみる必要ないんじゃない？って思った方も多いかもしれませんが、私が思うこのセミナーのいいところはモチベの高いPGの集まりなので、刺激を受けて自分もモチベが高まるところですね。（去年も同じ話してますが💦）ちなみに去年↓
DiscordやYoutubeのコメントなどで、そういうのが感じられて、
「やっぱりIT業界はいいなぁ…。(^_^)」
と思いました！
また、このセミナーのいいところは、実際の実用的なアプリでどのように取り組んできて、どのような失敗があったかという話を聞けることですね。
知ってることとやったことは100倍ぐらい重みが違うので、ためになります。
PHPに関しては、悪く言われることも多い言語ですけど、私はもう10年ぐらいPHPやってきて、PHPやってきてよかったなー、と思っております。言語というのは、すたれない勝ち馬に乗ることも大切なので、今のところ、まだPHPがメジャーであるのは確かですし。Javaの次に好きな言語です。
弊社でもいつかこういうののスポンサーになって、誰か弊社のPGが壇上で話してくれるといいですね！( ˊᵕˋ )
では、内容ですけど、私が見たものだけ、まとめをさくっと書いておきますね。
１．PHPStan使う
・PHPの静的言語解析をするツール。できれば使っていきたいですね。
・PHPDocsちゃんと書きましょう。
・PHPStormでもuseで使う名前空間の並び替えとかやってくれるらしい。
２．テスト駆動開発の導入（シャドウバース）
・テストを書くための時間がないんじゃない、テストを書かないから時間がないんだ！（…刺さる…(>_<)）
・決まった時間にテスト実行しよう
・アプリDBとテスト用のDBを切り離そう
・大規模なリファクタをする場合、大きなスコープでテストを書いてから、小さなスコープに切り出しておく。
それでIN/Outが変わっていないことを確認。そうすると、失敗が少ない。
3.事業のスケールアウトをプログラミングで支える★
・アプリはリリースしてからが本番
・書き込みが多いアプリケーションはCassandra、DynamoDBなどを使っていく
・CQRSに取り組む
例えば、ランキングの取得とか いちいちDBにアクセスして集計していたら大変…。
でも、誰かがイイネを押したら、更新されないといけない…。
→前日にランキングのデータを作っておいて、後はイイネが押されたらDBのトリガーを走らせて、DBを更新するなど
・２フェーズコミットは難しいからやめたほうがいい
・イベントソーシング ApacheKafkaがいいよ
・分散トランザクションも難しいのでやめたほうがいいよ
Sagaというソフトがあるらしいけど、難しいのでやめたほうがいいよ
・Kappaアーキテクチャがおすすめ
4.Composer2の話
Composer2がだいぶ早くなったよー
OSSのソース見るのは勉強になります。読んでみよう！
来年も、これ見れるといいな。
運営の皆様に感謝です！
