追加配車機能をリリース

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

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

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

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

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

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

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

 

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

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

案件から配車を選ぶ

案件から配車を選ぶ

 

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

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

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

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

 

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

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

便利ー!!

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

ありがとうございます。

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

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

 

去年ハワイに行った話(後編)

ハワイに行った話(前編)の続きです。

次の日はコンドミニアムタイプの場所に連泊。
キッチン、お風呂が付いてる普通のマンションみたいなところに泊まるわけです。ホテルじゃないので毎日掃除はついてません。
でも、こういうところってリーズナブルなんですよ。別に汚くないしね。
海外旅行というと、ホテルを選択する方が多いかと思いますが、こういうところは安いしいいですよ!(ただ、鍵がどこにあるのかわからず難易度は高かった)

さて、やってみたかったことがあります!
いつも海外旅行に行くと、見たことない珍しい食材を見ても、食べれないで終わってません??
最近は国内への食料品の持ち込みに対して厳しいですしね。

なので現地で現地の食材を料理して食べてみるのを一度やってみたかったんですよ!
決行!
というわけで、スーパーに行き、ステーキ用の肉と野菜などを買ってみます。

肉。でかああい!説明不要!

物価もたかああい!当時は1ドル140円ぐらいで本当に高かったです。(今は156円。一体どこまで上がるのか)

小さいキッチンがついているので、料理できる。

謎の野菜。ステーキと一緒に炒めたらおいしかった!

 

その夜はステーキにしたんですが日本のスーパーで買う肉よりなんか美味しく感じました。
次の日ステーキの残りの脂などを使ってチャーハン作りましたが、これも私史上一番美味しいチャーハンでした。

チャーハン。おいしく見えないと思いますが、めっちゃくちゃおいしかった( ˊᵕˋ )。

 

なんだろねー、この玉ねぎ代わりに入れた野菜がいい味出してるのか、にんにくが美味しいのか??
水の相性がいいのか?

お寿司も美味しかった。
以前、イタリアのナポリに行った時に、現地の人に
「何がおすすめですか?」
と聞いたところ
「スシ」
と答えてもらったんですが、行かなかったんですよね。
日本人が、海外に来て寿司はなかろうと。だって、日本でいくらでも美味しいお寿司食べれるじゃん。
でも、食べてみたらよかったな、と後で後悔しました。

なので、今回はお寿司食べてみます。

結論を言います。
ぜひ、海外でもお寿司食べてみてください。
日本で食べるお寿司とはちょっと違う、でも美味しいお寿司が食べれます。

マグロの上に唐辛子が乗ってる、その名もGod of Fire。でも、これめちゃおいしかった!

動物園に行ったり

ホノルル動物園。コモドドラゴンを見ました。

目がなんか怖い鳥

虎。

マノアの滝というのを見に行きました。

マノアの滝。道中、ちょっとジャングル感あって面白かったです。入っている人もいる。パワスポらしい。ご利益があったかどうかは不明。

古の古代兵器が隠されている場所。

2マナ 1/1 人間。

 

ショッピングしたり

KAI COFFEEというこのコーヒー屋さん、めっちゃ美味しかった!コーヒー好きな人にはお薦めです。パンもおいしい。( ˊᵕˋ )

コーヒー大好きなんで、ここぞとばかりにコーヒーを飲みまくる。ハワイはコーヒー有名ですからね!!

サーフボードってあるだけでおしゃれだけど、これだけあるとおしゃれのメテオ

海に行ったり

日焼け止めを塗るのが嫌いなので、紫外線対策は帽子か日傘が多いです。あんまりよくないのかな。

ダイアモンドヘッドが見える

ワイキキビーチ!

この色合いめっちゃ好き

いろんなところに食べに行ったり

一杯3000円ぐらいする日本のラーメン。これは日本の方が絶対おいしかった(笑)

ハードロックカフェ 天井にギターがいっぱい飾ってある!!(。゚ω゚)

やはりギターを持ったらイングヴェイポーズ

旦那氏がマジックザギャザリングが好きなので、カードショップに行ったり

海馬くん!カードショップの入り口に置いてあって嬉しくなっちゃった!( ˊᵕˋ )

カードショップ店内。遊戯王も人気だそうです。遊戯王って世界で一番売れたトレーディングカードゲームなんだって。

 

夕焼けを見ながら、早い時間からワインとか飲んでいると、心から幸せだな…と感じました。

ほぼ砂浜でディナーができるのがすごい。

 

なんか、海外旅行に行った時、幸せを強く感じる瞬間があります。
「そりゃー、海外旅行に行ったらお金もかけてるし、美味しいものばっかり食べたり、楽しいことばっかりしているから当然だろう!」
って思うかもしれませんが、それだけではない気がします。
楽しい、というのと幸せを感じるというのはちょっと違うんですよね。

私にも当然嫌なことは日々ありますが、それが海外に来ることによって俯瞰できるからなのかもしれない…。
と思いました。

最近、よく聞く話が、幸せを感じられるのは遺伝が50%で、行動によるものが40%、環境が10%だそうです。
「幸福度の50%は遺伝、10%は環境で決まる」では残り40%は…心理学の研究が明かす驚きの”幸福度の円グラフ”

なので、「お金を持っている」とか「結婚している」とか「彼氏・彼女がいる」とかそういうことって幸福度にそれほど影響を与えないというのが証明されつつあるらしいです。

もちろん、大変優しい良い旦那様がいて、悩みを話せる友人がいて、会社のスタッフもいい方ばかりで幸せなんだと思いますけどね。
周りの皆様にはいつも感謝しても足りることはありません!
ありがとうございます。⊂(^-^)⊃

 

旦那氏の誕生日祝いでルースクリスというお店で、トマホークというステーキを食べました!!

ワンピースとかに出てきそうな骨付き肉!!かなり大きいけど、二人でペロッと食べれるぐらい美味しかった!

はぁぁー 美味しかったー!

というわけで、オアフ島を満喫できてとっても楽しかったです。

最初の日に聞いた
「ハワイで何を食べても日本の方がおいしいですからね~」
というのは、そんなに感じませんでした。
もちろん、日本の外食の方がレベルが高いとは感じます。
ですが、選べば美味しいものがある!

それか、このコメントされた方は、多分、お金持ちだと思うので、海原雄山みたいに日本でも私が普段食べるものよりレベルが違うものを食べているのかもしれませんけどね( ˊᵕˋ )

去年、ハワイに行った話(前編)

忙しくて旅行関連全然かけてなかったのですが!ちょいちょい書いていきます。( ‘ω’ )

去年の8月に、ハワイへ行ってきました!
私の一生の夢… 色々あるけど、そのうちの一つに
「ハレアカラへ行く!」
というのがあります。

ハレアカラというのは、ハワイのマウイ島にある大きな山で、2001年宇宙の旅という映画の中で月面のシーンが出てきますが、そのロケが行われたというので有名な場所です。
ぜひ、その月のような場所に行ってみたいと思いまして、やっと今回行くべし!!ということになりました。

が。。。
旅行の三日前。
ホテルをBooking.comを通して予約してたんですが、そのホテルから
「ホテルが燃えてなくなったので来ないでくれ。違うホテルを紹介するよん。」
というメッセージが来ました。

「え?」
と思って検索したところ、マウイ島で山火事が、というニュースがかろうじて出てきました。

が、この時はまだ日本であまりこのニュースが広まってないころで。
なので、まだのんびりしていて違うホテルを紹介してもらうかー、とか思って上記のメッセージに返事したところ、返事がない。

そのうちニュースも入ってきて、マウイ島の山火事が大変なことが徐々にわかってきました。
「どうしよどうしよ」
と旦那氏とオアフ島だけにするか、それとも旅行自体取りやめるか、右往左往して迷ってました。
ちなみに、現在でもマウイ島の火事で家を失った方々はホテル暮らしなどだとネットで見ました。
災害の被害にあった方には心よりお見舞い申し上げます。

私個人はハワイは二回行ったことがあるので、オアフ島だけというのはな~
(実は社員旅行で2018年に行っている
と思ったんですよね。
オアフ島ってショッピングってイメージあるんですけど、私はあんまり海外でショッピングしないほうなんですよ。
でも、旦那様も仕事が忙しくて長期休暇はお盆とかにしか取れないので、勿体無いから行くか、という結論になりました。

というわけで、マウイ4泊+オアフ3泊のはずがオアフ7泊の旅になりましたが、出発ー!!

ホテルも1日前だったのですが、Booking.comで一応見つかりました。

さて、ホノルル空港について、街中へ行くのに方法がよくわからず、その辺にいた乗り合いバスのようなものを利用。
中に日本人夫婦の方がいたので、話しかけてみました。

ご夫婦「私たち、ハワイが好きで10回もハワイに来てるんですよ。ハワイ初めてですか?」
私「(旦那氏は初めてなので)はい!10回はすごいですね!
オススメのレストランとか教えて下さいよ!」
ご夫婦「いやー、何を食べても日本の方が美味しいですよ。」
…。

10回もハワイに来ている方が仰るのなら本当なのであろう。
「いやー、何を食べても日本の方が美味しいですよ。」(エコーがかかりリピート)
しかし、目の前が暗くなるような気がした…。

街中につき、ホテルに荷物を預けたら、ご飯へGO!

ワイキキのビーチ

これぞハワイ!という風景が広がる

ショッピングモールのフードコートでご飯。
唐揚げが入ったポキ丼というものを食べました。

唐揚げとマグロのポキ丼

 

唐揚げとマグロという2大スターの夢の共演!!!
美味しくないわけがない!!!
がっ…!!
絶望的に、まずかった(笑)

v2みたいに、やはり夢の2大スター共演はうまくいかないようだ。
マグロと唐揚げは死ぬほど相性が悪く、他にもパイナップルとワカメと枝豆とフリカケみたいなのが全部が不協和音を奏で、本当にまずい。(笑)

旦那氏が頼んだエビバーガーもめちゃまずく、先程の
「何を食べても日本の方が美味しいですよ〜」
という声が頭の中でリフレインするのであった。

ご飯が終わり、街の中をブラブラしてみるととにかく大きなショッピングモールがいっぱいあります。

 

ワイキキビーチ近くのメインっぽい通り。この日はお祭りがあったらしく、屋台が並んでいた。

前述もしましたが、私はあまり海外で買い物をしないんですが、お店をブラブラ見るのは楽しいですね!

で、ショッピングモールの中をブラブラしていると、鬼滅の刃のイラストがめっちゃある店が!!

このお店の人は炭次郎が好きそう

何のお店かというと、VRのお店だった

一生懸命シューティングゲームをやる私。楽しかった!

 

 

その後屋台で食べた豚串はめちゃ美味しかった!
よかった!ハワイにも美味しいものは存在している!!!

豚串を焼いている屋台

 

さて、夜中。ホテルの近くでクラブがいくつかあるらしく、そこから爆音で音楽が流れてきて、めちゃくちゃうるさい。

1日前に予約できたホテルなので仕方ないのか…。
時差ボケで寝れないのもあるけど、疲れてるはずなのにうるさくて寝れない(泣)
仕方ないので、旦那氏と様子を見に行きました。
すごいのが、クラブがうるさいだけではなく、クラブの前にたむろしている人々が色んなスピーカーを持ってて、爆音でそれぞれ好きな音楽をかけている。
「俺のオススメを聞け!」
ということなのであろうか…??さすが自由の国だ。

ちなみにクラブの下にあるお店でピザ買ったらかなり美味しかった(*^^*)

深夜のおいしかったピザ

次の日はハレイワという場所にGO!

トラックが屋台になっている。ここのガーリックシュリンプ有名らしい。

ガーリックシュリンプ。めちゃくちゃおいしかったー!!

お店がかわいい。アメリカンな感じの色とか好きですね。

かき氷(シェーブドアイス)はハワイでめっちゃ流行っているみたいで、ここで食べている人が多かった

 

とにかくお店がかわいいですね!
でも、この辺はレンタカー借りて来るべきです。我々はUber で来て、徒歩で回ったので結構キツかった!!

なんかかっこいいイラスト

ハレイワの海。きれいだけど、風が強かった。

こういうタイプのシャワーフォトジェニックですよね

My husband.

夜ご飯食べたところ。こういう家の造りってアメリカっぽくっていいですよね!こもおいしかったです( ˊᵕˋ )

 

移動については公共のバスがめちゃ安く、そして便利です!

公共のバス。安い。GoogleMapで見れば行き方に迷わないので便利!

この日は古い昔の民家のホテルに泊まったんですよ。
お風呂の電気がつかなかったりしました(笑)。

ゴゴゴゴゴ

 

でもアメリカンな古風な家って可愛らしいですよねー(^o^)
風と共に去りぬとか、赤毛のアンとか大好きだったので、ちょいテンション上がりました。

オールドアメリカンな感じがよい

ゴゴゴゴゴ

ゴゴゴゴ。サイコに出てくる家みたいですよね。その観点で見るとちょい不気味。

 

後半に続きます!

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

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

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

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

 

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

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

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

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

 

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

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

例えば、

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

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

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

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

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

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

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

 

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

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

お試しはコチラから。

 

「ちょうぜつソフトウェア設計入門」という本を読みました

ちょうぜつソフトウェア設計入門」。

うちのプログラマーS君が

「おススメですよ!」

と言ってくれたので、読んでみました。

結論→よい本です!

かわいい絵がついていますが、中身は本格派!

普通に技術的なとっつきにくい話が展開されていますが、かわいい絵がついていることにより、とっつきやすい感じになっているのがすごい。

プログラマーの初心者向けというよりは、中級者、2年目とか3年目の方が読むとちょうどよさそうです!

 

ソフトウェアの設計って本当に大事ですよ。

この前、XにPostしたんですけど、一番大事なのはDBの設計ですが、次に大事なのは、クラス設計だと思ってます。

ただ、クラス設計についてまったくわからずにプログラミングをしている方も多くいると思います。

別にわからなくてもできるし、ソフトウェアは動くからです。

しかし、設計についてわかってやっている方が、他の人の開発が早くなるし、バグも少なくなります。

その逆も真です。

また、クリーンアーキテクチャーの一番内側に近い部分の設計がダメだと、技術的負債が膨れ上がります。

外側に近いほうはダメでもまだなんとかなるのですが。

 

この本は、いろんな手法をある程度の深さまで紹介してくれる点で優秀だと思います。

ぜひ、設計をちゃんとやってみたいという志がある方は、この本を読んでみてください!( ˊᵕˋ )

 

以下、私が読んでよかったなとか知らなかったことなどをメモしておきます。

①パッケージ原則

ちゃんとパッケージに分けましょう。

②オブジェクト指向とかSOLIDとか

オブジェクト指向の紹介と、SOLIDというソフトウェア設計の原則について紹介されています。

SOLIDは次の原則たちの頭文字です。

・Single Responsibility Principle 単一責任原則

・Open Closed Principle 拡張に対してオープン、変更に対してクローズドであるべき
この本の中で
「洋服をいっぱい着てというのはいいけど、痩せろとか胸を大きくとかは難しい、というのに似ている」
と紹介されていて、このたとえはわかりやすいな!と思いました。

・Liskov Substitution Principle リスコフの置換原則

・Interface Separation Principle  単一責任原則のインターフェース版

・Dependency Inversion Principle 依存関係逆転原則

 

ちなみに、SOLIDとは別で「デメテルの法則」というのが紹介されていて、すごい重要と思わないですが、これに名前がついてたのか!というのを知らなかったのでメモしておきます。

詳しくは下記を読んでいただきたいですが、
デメテルの法則を厳密に守るにはどうすればいいの?

現場ではこうなってるプログラムっていっぱいありますよね。

$this->car->getEngine()->start();
$this->car->getEngine()->getheat();
$this->car->getEngine()->getVoilder->getId();

 

みたいなやつ。

いや、もうEngineクラスに書きなさいよって。でも、書いてる時は夢中で書いちゃうから気が付かないんでしょうね。

③テスト駆動開発やデザインパターン

 

スタブとかモックとかをあんまり使い分けていなかったので、大変参考になりました。

・スタブはテスト用の疑似オブジェクト 仮に期待通りの答えを得たとしたら、を仮定するダミーオブジェクト

・モックは使われ方を検証するための疑似オブジェクト(呼び出し回数とかをちゃんとチェックする)

 

④アジャイル開発

 

アジャイル開発とは何か、というだけではなく、ソフトウェア開発の歴史が書いてあって、非常に参考になりました。

私の師みたいな人がよく

「歴史を知ったほうがいい」

ってよく言ってるんですが、その意味がよくわかります。

ウォーターフォールについて、一般に誤解があることもわかりました。

ドキュメント偏重とか、SIの歴史なども勉強になりました。(o_ _)o))


 

それにしても、ソフトウェア開発って苦労することばっかりですよね。

世に目を向ければ、ソフトウェア開発の失敗のニュースがよく飛び込んできます。

日本のシステム開発が少しでもよい方向に行ったらいいなと思います!

 

さて、弊社でも新卒・中途でプログラマーを募集しています!(営業も募集中)

ソフトウェア開発、設計とか考えてやりたいと思っている方がいれば、ぜひ弊社に応募してください。

イチから教えます!(`・ω・´)

応募はコチラから!

ちょうぜつソフトウェア開発設計入門を手に持つS君

 

「ハッカーと画家」という本を読みました

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

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

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

ハッカーと画家

「普通のやつらの上を行け」という帯が若干恥ずかしい(笑)

 

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

 

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

 

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

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

 

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

新機能ができました!

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

長かった~(>_<)

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

ありがとう!

 

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

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

 

「超」入門 失敗の本質という本を読みました

「超」入門 失敗の本質
https://amzn.to/3TBZr0k

元々、「失敗の本質」という本があるらしいんですけど、それをもっと簡単にして要約してくれたのがこの本だそうです。

簡単に言うとこの本は、

「日本がアメリカに負けた…

その原因って、現代にも通じるところがあるよね~ 反省していこうね~」

という話です。

 

私は第二次世界大戦の話が好きなんですよね。

ちなみに三国志とかも好きです。キングダムも好きです。

戦争の話って現代の企業やいろんな組織に通じるところがあって、結局何かの目的を達成しようと人が集まれば、人間関係や組織のことが問題になってくるんだと思ってます。

第二次世界大戦と三国志って時間的に1500年ぐらいの経過があるんですよ!

1500年の人類のテクノロジーの進化ってすごいと思うんですが、戦争・失敗・すれ違い・組織の問題って、第二次世界大戦の話も三国志の話もあんまり変わらない気がします。

つまり、テクノロジーが進んでも、人間の本質って変わらないんだろうな~。

では本題なんですが、本の内容でよかったな~ と思うことを抜粋していきます。


①戦略が大事

 

「戦略とはつまり指標」

というのがすごい刺さりましたね~。

日本軍が追いかける指標がバラバラだったのがよくなかった。

ノモンハン事件、ミッドウェー、レイテ海戦、インパール作戦など、大本営からの戦略がなかったのでバラバラな意思決定をしてしまったので敗北につながったという話です。

また、ホンダがアメリカでスーパーカブをヒットさせた話も例に上がります。

ホンダはもともと大型バイクをアメリカで売りたかったのですが、たまたまホンダの社員がスーパーカブという小型のバイクをアメリカで乗っていたら、アメリカ人がとても興味を持ってくれたというヒントからスーパーカブを売り出して大ヒットとなったという話です。

ただ、筆者はこれもたまたま勝利しただけで、再現方法がわかっていなければ再現できない。

体験的学習で新戦略を察知したことは再現しづらい、と書いています。(辛口だなぁ…)

再現力が大事、というのはその通りとは思います。

 

②ゲームのルールを変えたものが勝つ

 

まず、日本軍は個人技能の精錬に頼りすぎという話。

日本軍のパイロットが敵の飛行機を打ち落とせるように猛特訓しても、アメリカは敵に当たらなくても爆発するVT信管の開発により、それを上回ってしまったという話。

いや~ わかりますね。なんというか、日本人ってやっぱり精神主義というか、侍がカッコイイというか、何か一つのものを収斂してその道の達人になることが、すごいカッコイイことなんですよね。

でも現実の戦争においてはそれは大して役に立たなかったという話。(>_<)

当たらなくても爆発する、という爆弾の開発により、「がんばって敵にあてたものが勝つ」というゲームのルールが変わってしまったという話です。

日本人はこれが苦手だよね~ と言われると悲しい気持ちになりますが それをおしてこの本を読んでいるわけですから、続きを行きますとアメリカはどうしてこれができたのかというと

ヒト、技術、運用 の創造的破壊ができてたからできた、ということでした。

③新しい指標を作って古い指標をひっくり返す

 

②と似たような話にはなりますが、
・戦場の勝敗を決している指標を見抜く

・敵が使いこなしている指標を無効化する

・支配的だった指標を凌駕する新たな指標で戦う
ことが大事。そうしないと、やみくもに同じことを繰り返して敗北してしまう。日本軍が最初のうちは白兵銃剣主義で勝利していたのですが、そのうち巻き返されてしまった話が載っています。(´ω`)
ダブルループ学習で、そもそも問題の設定自体が間違ってるのでは、と見直すことが大事。
また、米軍はレーダーを活用して、日本軍の奇襲などを後半戦では防いだ話は有名ですが、日本でもレーダーは開発されていたそうなんですよ。しかし、海軍は

「そんなものはいらん!」

と一蹴してしまったそうで。。。今考えるともったいない話ですよね。

④人事の失敗が組織を敗北させる

 

迅速な行動力と勝利への執念がある人を高く評価するべし、だそうです。

この本では、日本軍では結局大きな作戦に失敗した将校も特にその後責任を取らされたりしなかったので、論功行賞がうまく行ってなかったという話が載っています。

いや~ 私も、実は人事で失敗をしたことがあります…。

人事の失敗ってなかなか取返しがつかないんですよね。

その反省を胸に刻まないといけないなと思いました。(´ω`)

⑤現場の情報を活用する

 

アメリカ軍の戦闘機を作った会社の社長が真珠湾まで来て、ゼロ戦と戦ったパイロットにインタビューした話などが載っていました。

ゼロ戦って最初はすごかったんですよね。「風立ちぬ」とか好きな映画です。

ただ、防火性能を高めた戦闘機、1対1でゼロ戦と戦わないようにした戦術などの前にだんだん負けるようになってしまったというのは悲しい話です。

 

⑤場の空気に支配されない

 

これも、日本あるあるな気がしますね。(´ω`)

外国にももちろんこういう場面があるとは思いますが、日本人って本当に空気ばっかり大切にしてますよね~。

ここでは、戦艦大和が沖縄に出撃するときに、そんなことは作戦としては普通に見て悪い作戦だ、と反対意見を言おうとしていた将校が、参謀に

「海軍がここまでやるんだから」

という一言を言われて、それなら仕方ないですねと一瞬で引き下がってしまった逸話が載っています。

何かを強く主張して、後で恥をかきたくない、人に合わせておけばラクという側面も感じられます。

また、例えば

「靴を脱いだ時に揃えない人はダメな人」

とかそういう少しの情報で大局を判断してしまうのはよくない、という話も載っています。

私も常々仕事の場で「空気を読むのがよくない」と思ってます。

もちろん、仕事の場で、ということであって、お葬式でいきなり大声で笑いだすとかそういう配慮のなさはよくないです。

仕事で大事なことを決める時には、コミュニケーションすること、反対意見があっても反対意見も聞くことが大事だと思います。

今はSNSとか動画で、

「ヤバい人を見抜くたった一つの特徴」

とか

「ブラックな会社を見抜くたった一つの特徴」

そういうの多いですよね!

こういうのって、こういうタイトルや中身だとPVが伸びるからこういうタイトルになっているだけなんですよね。

たった一つの特徴だけで全体を判断するのが人気なのは、簡単なことだからだし、依存性があるからなんですよ。

でも、長い目で見るとあまりよくないという話ですね。

 


以上なんですが、侍の話をした時にちょっと連想したことがあります。

日本のプログラマ界も、今少し白兵銃剣主義の世界に近くなってきている気がします。

「つよつよプログラマー」という言葉に代表されるように、個人技が大事、スキルさえ磨けばなんとかなるというのがちょっと目立つ気がしますね。

私自身もプログラマーですし、「つよつよプログラマー」にもなりたいという気持ちは当たり前に必要だし、組織の構成として強いプログラマーさんがいたほうがいいと思いますが、ビジネスという戦場でそれがどれぐらい大切なことなのか、一旦振り返ったほうがいいかもしれません。

いくらすごいプログラマーが何人もいても、戦うべきところを間違えていたら、結局勝利しないと思います。

ちなみに、似たような本で失敗の科学という本がありまして、こちらもおススメです!

 

 

人狼みたいな面接

さて、弊社で今は新卒と中途の採用を行っています!

中途採用、めっちゃ応募頂いています!

ありがとうございます!!

いや、うちの会社ってやっぱり人気あるな(笑)人手不足ってよく言いますけども。

面接で忙しいです(笑)

本当にありがたいことです。┌o ペコッ

 

しかし、最近思うことがあります。

中途の採用すると、必ず前職をやめた理由をお聞きします。(聞かない会社はないと思うけども)

その時に

「前職に不満はないんですよ。不満があって辞めるわけではないので」

って言われる人が多くなったんですよ!

なんかですね~ 『転職を成功させる』とか『面接の極意』とかで

「転職の面接で前職の不満を言うのは絶対NG!!言うにしても、ポジティブに言うこと!!」

とかって書いてあるから皆さんそれをそのまま信じてらっしゃるんでしょうか。

 

もちろん、本当にプログラマーを目指したいとか、IT業界に入りたいとかとか、引っ越しとか、出産で仕事を辞めたとかで前職に不満がない場合もあると思いますけども。

 

私は前職の不満、全然聞きたいですよ。本当に退職につながった理由をお聞きしたいです。

そして、志望理由もそんなに着飾った理由でなくてもいいです。

「御社の理念に共感して!」

とおっしゃいますけども、(まぁ弊社の理念が素晴らしいのはさておき)、これも転職エージェントが作ったまとめサイトのマニュアル通りだったりするんですよね。

その人が思う本当の理由、

「休みが多そうなので」

とか

「プログラマーって、将来的に年収が高くなりそうなので!」

とか平たい理由を教えてほしいんですよね。

 

なんでかというと、結局面接で本音を言わないと、会社の方針や仕事内容と自分のやりたいことに齟齬が出てしまって幸せな仕事人生を送ることができないと思うんですよ。

新卒ならまだ仕方ないと思いますが、何年か働いてきた方であれば、仕事というのは長時間地味なことをするのであって、合わないことって苦痛でしかないってわかっているかと思います。

 

転職活動って大変なので、だんだん面接に合格することが目的になってしまうというのもわかるんですけどね。

本音をオブラートに包んで、面接に合格することが目的になっていると、近い将来離職につながってしまいます。

面接というのはお互いの価値観を語り合って、本当にその人にとってうちの会社の仕事が向いている仕事なのかを双方が真剣に見極める場です。

「どうせそっちもこっちが本当のことを言うとは思ってないでしょ」

というような、人狼をしているような面接は止めてほしいです。

 

さて、弊社の新卒&中途採用ですが、コチラに募集要項があります!

営業&プログラマーの募集をしております。

どちらも、今のところ新卒でも中途でも枠があります!

ご興味があれば、ぜひご応募ください。(o_ _)o))

位置情報が取れないときに原因がわかる機能が追加!地味だけどこれは効く

アプリログ機能、という弊社のODIN リアルタイム配送システムのスマホアプリのログが管理画面で見れる機能が誕生しました!

パチパチパチパチ。

どういった機能かというと、アプリのいろんなログが管理画面で見れるという機能です。(さっきと同じこと言ってる)

うわー、地味!!

配送計画がサッと作れるようになりましたとか、行動検知ができて、ドライバーさんが運転中かどうかわかるようになりました、とかと比べてめっちゃ地味ですよね。

しかし、これは結構大切な機能でして(`・ω・´)

弊社によくあるお問い合わせが

「山田さんっていうドライバーさんの位置情報が更新されてないんですけど~」

というようなお問い合わせです。

しかし、すぐに弊社でもわかりません。

 

というのは、大体のケースで原因は

・そのドライバーさんの持っているスマホのネットワーク接続がない

・電源が切れている

・GPSの設定がオフにされている

などですが、その場に端末がないのでどうにもわからないんですよね。

これは電話をかけてきたお客様も同じです。

なので、従来はここでお手上げでした。

 

が!!!

このログ機能により!

どういう状況なのかが、瞬時にわかるようになったんですね~。(ネットワークがない、電源が切れている場合はログ自体がありませんが、そのことにより、ログが送信できない状態だとわかります。)

これにより、お客様のイライラを解消し、弊社のサポートの品質も爆上がりするんですよ(๑•̀ㅂ•́)و✧

しかも!!!!

これ、お客様にも見て頂ける画面にあるので、お客様がログを見ていろんなことがわかるんです。

見方はこちらに書いてあります。

アプリログ画面 スクショ

【アプリログ機能】ODINで位置情報を取得できない時の分析方法

実は、この機能は社内で反対する人もいました…。(>_<)

理由は

・ログを見るなんて面倒。英語のメッセージとか、絶対に読みたくないからお客様は興味がないはず!

・ライバル会社さんにいろんなことがわかってしまうのでは?

という話でした。

まー、私はユーザーだったら使ってるアプリを使い倒したいときはこういうの見ますけどね。

レアな方だとはわかってます。

しかし、私としてはお客様の満足度向上のほうが上だと思いましたので、反対の声を押し切って実装してもらいました。

今、かなり!役に立ってます。

 

こういう直接的な機能じゃない機能って結構大事だと思うんですよね。

我々の時間を増やす機能なんですよ。

我々の時間が増えれば、結局お客様の役に立つ別のことができますからね!⊂(^-^)⊃

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