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

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

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

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

 

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

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

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

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が伸びるからこういうタイトルになっているだけなんですよね。

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

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

 


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

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

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

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

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

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

 

 

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

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

パチパチパチパチ。

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

うわー、地味!!

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

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

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

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

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

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

 

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

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

・電源が切れている

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

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

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

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

 

が!!!

このログ機能により!

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

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

しかも!!!!

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

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

アプリログ画面 スクショ

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

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

理由は

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

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

という話でした。

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

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

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

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

 

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

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

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

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

 

スマホの位置情報で配送先の近くに来たら自動で配送先に通知できる機能ができました!

オーディーンリアルタイム配送システムに、さらに便利に使える機能ができました!

よくお客様からリクエストのあるのが、
「ドライバーさんが納品を始めたら知りたい」
「緊急事態などにすぐわかりたい」
というリクエストです。

すでに、オーディーンでは上記のような件に関しては、

①メッセージ機能
②位置情報で、いつ、どこで誰が何をしているかはわかる
③過去の位置情報の記録も見れる
④日報でも見れる
⑤配送先の人が、自分のところに来るドライバーさんの位置情報が近くなったらわかる

もあったんですが、パッとドライバーさんが通知を送って、それがどこで起こったのかを管理者が知る方法ってのはなかったんです。

が、ウチの若手のホープ、Sくんがこの度作ってくれました!

最近成長著しいSくんですが、この機能も凝った設計の割にサササと作ってくれ、すごいなと思いました!!(⁠≧⁠▽⁠≦⁠)
ありがとうー!!

色んな使い方ができます!

①事故を起こしてしまったので、管理者へ知らせたい
事故の際などは忙しいし、慌てているので場所が正確に報告できない場合などもあるので、便利です。
②納品先に入ろうとしたら納品先が込み合っていて待機になってしまったので、会社へ知らせたい
③納品が開始されたら、納品先にメールで知らせたい(置き配的な配送などにピッタリですね!)
④営業さんの直行時の報告(ここで仕事を開始します!というような通知)

私は、旦那様への帰るLINE代わりに使ってます(笑)

GPSで自動でできるんで、便利ですよ!!(๑>◡<๑)

しかも、これすごいのが、使い会社さんによってメールの文面まで変更できるんですよ!!٩( ‘ω’ )و
下記は設定画面のスクショです。

記録開始検知 メール機能

記録開始検知 メール設定

お問い合わせはコチラから。

営業研修をプルデンシャル生命の凄腕支社長にしてもらった → アポイント獲得率が2倍近くになった話

ある時思いました。

「ウチの製品(ODIN リアルタイム配送システム)は素晴らしいけれども、世の中に今まで存在していなかったものなので、何なのかを把握していないお客様が多いのでは?
お客様の課題をちゃんと話し合えてるかな??」

と。
もちろん、うちの営業チームはすごい人達がすでにそろっているのですが、もっと強くなれると感じていました。

そこで、それを相談するのに、やはり営業のプロに相談してみようと思い立って、個人的に知り合いだったプルデンシャル生命の横浜中央支社の田中支社長に相談しました。

田中さん
「え、今、私、そういう講義を大学などでやってるんだよ。」


「えー!!マジすか。」

田中さん
「御社の営業さんにも教えてあげるよ!」

ということで、プルデンシャル生命の田中支社長が直々に弊社の営業チームを指導してくださいました!

これって本当にすごいことで、営業研修っていくらでもあるんですが、教えてくれる人の実力ってどうなの?というのが正直あります。
座学のセミナーなどは今までも営業の皆さんに受けてきてもらってましたが、実際に営業という戦場で生き抜いてきた方に教えてもらうことのはまたとない機会ではないかと思いました。

たとえて言うなら、格闘技を柔道習っていた先輩に習うのか、現役のグリーンベレーの人に習うのか、という違いみたいなものです。(`・ω・´)

田中さんの略歴ですが

・プルデンシャルで支社長11年

・経営学修士MBA

・大学で客員講師として営業学を教えている

・東北大学で産学連携教育イノベーター

でいらっしゃいます!

営業とは、という体系的な話から、実践的な話まで。私もところどころ参加させて頂きましたが、目からローリングサンダーが落ちる思いでしたね(⁠。⁠◕⁠‿⁠◕⁠。⁠)⁠➜

特に刺さったのが

「営業とは価値を交換する仕事をする人」

というお話でした。

なんというか、営業という仕事が
「モノを一方的に売りつけてくる人」
というイメージを持っていらっしゃる方もいると思います。(>_<)

ですが、お客さんにモノやサービスなどの価値を提供し、その対価としてお金を頂く、という価値を交換しているんだなと改めて思い、営業とは大切な仕事だなと実感しました。

何時間も講義していただき、営業チームの皆さん、とても勉強になったということでした。

私から視てもお客様への話し方、営業の姿勢、問題の深堀り、調査などが本当に変わりました。

すでに、アポイント獲得率が28%だったんですが、これがなんと50%になる、という結果が出ています!!

営業の皆さんのプレゼンの仕方、話し方などもすっごい変わりました!

すごくないですか??(`・ω・´)

 

本当にありがとうございました!!

お写真ないですか?って言ったらその場で撮ってくださいました!

また、弊社では現在営業さんも募集しています!

ぜひ、世の中に意味のある価値交換をしたいという方、待ってます!

採用情報はコチラから。

なぜうちの会社はちょっと突飛な求人広告を出すのか

求人広告を新しくしました。

このたびは

「目を輝かせて仕事をしている人がいます」

です。

現役プログラマーのS君に登場して頂きました!ありがとうー!!

目を輝かせて仕事をしている人がいます

この広告に至った経緯なんですが、最初は

「どんな人に来てほしいかわかる&キャッチーで人目をひく」

ってのを考えていて、

「豆から挽いたコーヒーが飲めます」

にしようかなと思ってたんですが、なんかイマイチだなと。どんな人に来てほしいのかもわかりませんしね!(コーヒーが好きな人が来そうではある(笑))

 

で、一方社内に目を転じてみると、プログラマーのS君がすごい楽しそうに仕事をしてたんですよ。

ちょっと前からS君が急にすごい勉強するようになって、中でも「ちょうぜつソフトウェア設計入門」と「クリーンアーキテクチャー」という本がすごく気に入ったそうで、

「このクラスはこれこれこうやっていいですか?やっぱり単一責任原則に基づいて設計していかないとですよね!!」

「なるべくインターフェースをいっぱい作ってテストとかを先に作っていきたいです!!」

「クリーンアーキテクチャーにするためにここはモデルにして、この役割はアプリケーションにして…」

とか言って、猛烈に「よい設計」を目指して仕事をするようになったんですよ。
(ちなみに、写真の手に持っている本にもご注目ください( ˊᵕˋ ))

また、S君は効率化ということにとても興味があって、よく画面構成・機能などについても

「お客さんは30分以上かかってたら赤くなってたらすぐわかって便利じゃないですか?パッと見でわかるし。」

など顧客目線に立ってどんどんアイデア出してくれます。

S君はまさに目を輝かせてパソコンに向かってました。

 

私はそれを見て純粋にメチャクチャ嬉しかったですね!( ˊᵕˋ )

そして、社員さんが健全に仕事を楽しんでやってくれているというのは、すごいことなんじゃないかと思います。

ご本人の資質もあると思います。

が、正直楽しめる仕事って世の中に多いですか?

 

で、ある時

「ん?この状態をそのまま求人広告にしたらいいのでは?」

と思いました。

熱意のある人に来てほしい、という我々の意図も伝わると思いますし!

実は、頭に浮かんでたビジュアル案としては、「推しの子」の星野アイちゃんみたいに目にガッツリと☆を入れたかったんですが。

やっぱり実写だとそれは厳しかったですね

なるべく流行りものを取り入れたいなとは思ってるんで。

ちょっとタイミングがずれてたら、猫ミームになってた可能性はある(笑)

 

さて、今までも突飛な求人広告をよくやってきてたんですけど、どうしてそういうのにするのか、というのは書いておきたいと思います。

①人目を惹きたい

 

大きな会社ではないですから、多くの求人広告がスクロールされていく中で目を止めてもらわないといけません。

キャッチーな写真、キャッチーな一言、は必要だなと思います。

 

②本当にイノベーティブな人に来てほしい

 

これねー、いろんな価値観はもちろんあるとは思いますが、イノベーティブってなんでしょう?

挑戦すること、革新的な何かを作れること、ですが、私は他の多くの人と違う方向に行ける、ということも一つあると思います。

それって実は、すっごい難しいことなんですよ。

 

なので、本当にイノベーティブな人を探したいので、ちょっと突飛な求人広告を出しています。

「うわー、こういうのひくわ…。」

という人にはウチの会社はあわないと思うからです。

大手の会社が、

「イノベーティブ人材を求む!」

とか

「チャレンジできる風土です!」

とか、青空をバックに、若いビジネススーツを来た学生の男女がダッシュしてる、みたいなビジュアルの求人広告ってめっちゃ多いですよね(笑)。

そういうので本当にイノベーティブな人が入ってくるのでしょうか?大手の人事部の方に聞いてみたいです。

 

 


 

というわけで、なんとまだ2023年度卒の新卒を募集していますし、第二新卒・中途も募集中です!

 

今年度も多くの方に応募して頂いております。

ありがとうございます。(>_<)

上述したように、こんな変な求人広告を見て応募してくださっただけで、私としては全員採用したいぐらいですが!

 

ウチの会社が何をやっているかを改めて書いておくと、配送会社さん向けのシステムです。

スマホの位置情報と配送計画が連動しているのが特徴です。

今まで世の中になかったソフトウェアなんですよ。

「会計システム」「帳票システム」「ショッピングカート」など、今まで世の中に存在した製品ではありません。

だから、イノベーティブな人が必要なんです。

新しく何かを作るということは、楽しく、責任があって、失敗も多い仕事です。

 

そして、配送・運送の世界って今大変なんですよ 人手不足やガソリン代高騰のところに2024年問題が来ようとしています。

それをお助けするための仕事です。

 

こんな方↓に来てほしいです。

 

①弊社の理念と目標に共感し、長い視点で仕事ができる

②コミュニケーション能力が高い人
-「何かを察してほしい」というのではなく、自分で発言できる
– 困った時には誰かに相談できる
– 問題を提起できる

③顧客の問題を理解し、顧客の問題を解決したいという情熱のある人
-自分がお客様気分ではない
-顧客・社会の役に立つことを喜びと思える

④責任感の強い人
– 困難にぶつかったらすぐに何かを放り出したり、他人のせいにするのではなく、自分の責任で自分の仕事をできる人
– 挑戦している人を評論したりするのではなく、自分が挑戦することができる人
– 勉強・成長を続けていける

 

要はハートだと思ってます。

プログラミングや営業は、今できなかったとしてもガチで我々が教えます!!(`・ω・´)

当てはまるな、という方はぜひエントリーしてください!

エントリーはコチラをお読みの上、問い合わせフォームからご連絡ください。┌o ペコッ

 

「人月の神話」という本を読みました

有名な本なので、タイトルを知っている人は多いと思います。
私もタイトルは知ってましたが、この度初めて読みました! Amazon: 人月の神話

なんと、1976年に書かれた本だそうです。
いや、時代を超えて語り継がれる名著ってやっぱり違いますね~。

何より驚くのは、ソフトウェア開発、つまりプログラミングというものにまつわる難しさの本質が、この48年前からほとんど変わっていないということです。
つまりは人間が何人か集まって、複雑なものを作ろうとすると発生する問題というのは同じなのかもしれませんね。

私が読もうと思ったきっかけは、弊社も少ない人数で開発していますから、
「いかに少数精鋭でよいソフトウェア製品を作るか」
ということを常に考えています。そんな時に、この本のことをAWSのセミナーで上げてらっしゃる方がいて、この機会に読んでみようと思いました。

下記に私が大事だなと思ったところを上げておきます。

①人月について

人月って言うのは、システム開発業界でよく言われる用語なんですが、「5人のプログラマーが5か月かかって作る」場合、5×5で25人月となります。

・人と月は交換可能ではない
コストは人と月に比例するけども
・人と月が比例するのは、作業者の間でコミュニケーションを図らなくても仕事が分担できる場合だけ
・コミュニケーションの労力は、人数が多いほどかかる。
・特に新しく追加した人は経験者から仕事に対する教育、訓練を受けないといけないので、それに3名が1ヶ月かかるとすると、3人月がもとの見積もりになかった人月がかかる。

→人員を投下しまくったり、後から開発に追加したりしても、なかなか成果が上がらないということです。
単純作業だったら、人を追加したらいいかもしれませんが、システム開発というのはコミュニケーションが大事だからです。
遅れているソフトウェアプロジェクトへの人員追加はさらにプロジェクトを遅らせるだけってよく言いますよね。

②スケジュール組について

ソフトウェア開発のスケジュールは
1/3 計画
1/6 コーディング
1/4 単体テストおよび初期システムテスト
1/4 すべてのコンポーネントを統合して行うシステムテスト
(あれ?この計算合ってます?(笑))

→計画が大事ってことですね!キモに命じます。

③コンセプトについて

少数精鋭チームは10人以内が理想的。
外科手術のチームように行う。
機能などで分担を分けるのではなく、執刀医と副執刀医はプログラムのすべてを把握し、判断する必要がある。

大勢で考えたほうがよいとか、そのほうが民主的とか、そういう問題もある。
が、重要なのはコンセプトの完全性なので、貴族政治の方がよいわけ。
アーキテクトとインプリメンテーションは違うタイプの創造的仕事。

ソフトウェア製品にとって、コンセプトの完全性がとても大事。
コンセプトの完全性は、デザインは一人または互いに意見が同じで共鳴するごく少数の頭脳から、考え出さないといけない。
重要な仕事は、製品を定義すること。

→これもわかる~×100。ですね。
昔、爆笑問題の太田さんがテレビで話していた逸話ですが、太田さんが映画を作ろうと思ったことがあったんですって。
で、映画を作っていると、太田さんは映画を作るのが初めてだから、美術監督は「これをこうしたほうがいい」、
照明さんは「あれをこうしたほうがいい」脚本家からは「こうしなきゃダメ」とか言われて、全員の言うことを聞いていたら、まったく面白くない作品になってしまったんですって。

これ、作品というか何か創造物というのは本当にこの側面があるんですよね。

④コミュニケーションについて

コミュニケーションの欠落が抗争、憎悪、嫉妬につながる。
そのうち内輪喧嘩するよりは一人でいたほうがいいと思い、バラバラになり始める。
マネージャーにとって重要なのは、全員を同じ方向に進ませること。
そして、組織の在り方というのは大事だし、組織にどんな人を追加するのかがとても重要。

→身につまされる話ですね。

⑤工数見積もりについて

プログラムを書く時間は、大体倍の時間かかる。
大体のプログラマーが、勤務時間の2分の1しかプログラムにかけられない。
機械が故障して使えないとか、ミーティングとか書類作成、社内事務、病気、私用など。

→わかる~。実際にそうですよね。

⑥スケジュールについて

1日毎の遅延
昨日はキーパーソンが病気
今日は機械の故障
顧客との緊急ミーティングなど、どんどんスケジュールは遅れていく。
が、3か月の納期とかってなってると、1日ぐらい遅れても、取り戻せるだろうと思っている。

しかし、結局1日の遅れを取り戻すことが難しい。
ハッスルプレイ、一生懸命になること、1日の遅れも取り返すために躍起になるべし。

→ううう その通りだと思います。

⑦ソフトウェアを作るということが、なぜこんなにも難しいのか

表現はプログラミングの本質。
仕様書や文書でコミュニケーションを図る必要がある。

何を構築するのかを決めるのが非常に難しい。
にも関わらず、後から変更するのがこれほど難しいものもない。

→弊社で、最近変えたことがあります。
それは、仕様書をもっと作っていく、ということです。今までは、テスト仕様書はあったんですが、プログラムの仕様書については、作ったり作らなかったりでした。
ソフトウェア製品の仕様書って難しいんですよ。すぐに仕様書が古くなってしまうからです。
コードが仕様書、テストコードが仕様書、という状態は多いと思います。

ただ、どうしてもそれじゃ表せない仕様がある。UMLもシーケンス図も足りないとい思うときが多いです。
図や絵じゃないと表せない仕様ってあるんですよ。
えてしてそういう仕様が複雑かつ大事なんですが、コードもテストコードもUMLもシーケンス図もそれを表すことができない時があります。
で、Outdateな仕様書だとしてもそういう絵や図を含むものが「ないよりマシ」という結論になりました。

また、表現はプログラミングの本質、という言葉にグサッときました。
私がいつも考えていることを一言で言い表してるなと思ったからです。

————————————

この本に出てきた言葉か忘れちゃいましたが、ソフトウェアって不思議なもので、1000人のプログラマーがいる大企業が出している製品よりも、ガレージの二人組の方がいい製品を出している、ということは起こるわけです。
我々もガレージ側なので、得られたことを生かしてがんばらないとな!って改めて思いました。

そして、弊社では現在、新卒・中途のプログラマー・新卒の営業を募集しています!
採用情報はこちら