新機能ができました！

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

 

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

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

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

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

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

 

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

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

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

ぜひ使ってみてください！（無料お試しはコチラから）

 

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

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

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

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

長かった~(>_<)

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

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

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

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

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

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

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

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

技術的負債を返すのは大変だ～（泣）

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

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

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

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

 

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

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

ありがとう！

 

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

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

 

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

このたびは

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

です。

現役プログラマーの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人のプログラマーがいる大企業が出している製品よりも、ガレージの二人組の方がいい製品を出している、ということは起こるわけです。
我々もガレージ側なので、得られたことを生かしてがんばらないとな！って改めて思いました。

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