配送計画が新しくなりました!

弊社のODIN 配送計画が新しくなりました!

とはいっても、今回はプレスリリースを出すわけでもないし、この機能がすごい!とかっていう感じではなく、地味かもしれません。

しかし、日々使っている方や、本気でこれからご利用を検討されている方にはとても使い勝手が向上するリニューアルになりました。

詳細な内容については、下記↓をご覧ください。

配送計画大型リニューアルのお知らせ

私的ハイライト☆彡をご紹介します。

【配送指示の導入】

・配送指示の項目はカスタマイズ可能。各会社さんで自由な項目を割り当てられる。

→これは結構大きいと思います!
配送の会社さんって、各社さん設定したい項目が違うんですよね。
何かのコードを入れたいとか、配送に紐づく項目を入れたいとかあると思います。
それが、自由に入れられるようになりました!

♪配送計画 is フリーダム~ ♪

【小口配送の導入】

小口配送とは下記のように集荷場所が1か所、配送が複数個所の配送のことを指しています。

このタイプの配送計画が設定しやすくなりました。

・会社の場所や営業所の場所を集荷先として選択可能になりました!

【集荷配送(集荷と配送が1対1)の設定がExcelインポートで可能に】

・以前はドラッグアンドドロップで集荷配送を設定できましたが、配送先が多いとやりづらいというご指摘を多く受けていました。
そのため、Excelを使って一括でインポートできるようになりました。

【集荷配送の設定がより柔軟に】

以前は、集荷と配送を同時に同じ場所で行うなどができませんでしたが、できるようになりました。
例)クリーニング業などで、配送先で汚れたリネン類の集荷ときれいなリネン類の配送を同時に行うなどの設定が可能に。

【その他】

・一つのルートで同じ配送先に行けるようになりました!
これも変な制約だったんですが、治りました。


ここからはウラ話です。

いやー、これですね…。

実は8月から取り組んでまして。

最初は「案件」というものを配車表だけでなく配送計画部分にも取り入れようということからスタートしたのですが、プログラムの「ある部分」がどうしてもネックでした。

その「ある部分」は今までもネックだったし、元はと言えば「ある部分」は違う「ある部分」のネックのせいでネックになっていたという感じでした。

ここを小手先でいろいろ直しても別にできたかもしれません。

ただ、そうするとまたもやほかの部分のネックになる問題が増えることが目に見えてました。

なので、根っこの問題を改善するという大改造に踏み切ったという感じです。

そして、今度発表するほかの大型機能もこれと連動しているので、こっちができないとそっちもリリースできない状況になってしまっていました(泣)

そっちを早く発表したいという時間的制約があって、これを早く仕上げないといけませんでした。

そしてこの大改造が思っていたよりエグい大改造で、チームの皆さんには本当に負担をかけたと思います。

が、弊社の秀逸、M君とS君が本当によくやってくれました(>_<)

二人とも素晴らしいプログラマーで、実装が本当に早いです。

ありがとう!!( ˊᵕˋ )

 

まぁね~ プログラミングをやったことがない人には

「最初っからちゃんと作ればそういうことにならないんではない?」

と思うかもしれませんが、どうしてもソフトウェアというのは複雑なもので、ちょい改造を重ねていると、いつの間にか複雑に絡み合った問題構造が生まれているものなんですよ。

エントロピー増大の法則、ということなんでしょうかね。

 

私も今回は後半から開発に加わってやってました。

今回はPHPを書くことが多かったです。

やらなければならないことが多すぎて、ガチで久しぶりにプログラミングばっかりやってました。

弊社の定時は10時~19時なんですが、没頭していると、昼ご飯を食べた後、時計を見るといつの間にか20時半ぐらいになってるんですよ。

そんで、その次は20時半から22時半ぐらいになるのが一瞬です(笑)

誰か共感してくれる人いないかな、コレ。

仕事してる時の20時~23時が一瞬ですぎる話。

「仕事ばっかりやっててかわいそう…」

と思われるかもしれません。

が、時間を忘れるぐらい没頭できる仕事ってある意味幸せかもしれないです(笑)

 

性格と価値観がプログラミングという仕事にあっているというか。

プログラミングにはパズルみたいな面があります。

何か複雑な問題があって、それに正解はないんですが、自分なりの最適解を見つけられて、それがハマっていく感覚がたまらないんですよね。

ドーパミンってやつなんでしょうか。

 

とは言っても、今回は私的にもキツかったですけどね(笑)

 

というわけで、使い勝手が大幅に向上したODIN 配送計画

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

 

業界初!ドライバーが徒歩、駆け足、運転中か確認できる『行動確認機能』をリリース

すすす すごい機能ができました!!!(/・ω・)/

本日下記のプレスリリースを行いました。

業界初!ドライバーが徒歩、駆け足、運転中か確認できる『行動確認機能』をリリース

 

ドライバーが徒歩、駆け足、運転中か確認できる『行動確認機能』

 

この機能にそんなに説明はいらないかもしれないんですが、要はスマホを持っている人が

・歩いているのか

・じっとしているのか

・走っているのか

・乗車中か

が管理者側でわかる、という機能なのです。

業界初です。(弊社調べ)

 

どんな時に役立つかというと、例えば急にドライバーさんに連絡したいと思っても

「車に乗っているときは避けたいな…。」

と思いますよね?それを解消してくれます。

また、配送の業界やチラシ配布などの業界では、「小走り」を義務付けられている場合もありますね。

でも本当に「小走り」状態なのかはわかりませんよね。

それが、これからは把握できるということです。

 

経緯としては実は別の目的で始まった開発でした。
プログラム的な用語でいえば、行動認識というものにあたると思うんですが、それをスマホアプリに実装しようと思ってたんですけど、

「ん?この情報って管理側で見れたら便利では?」

ということになって、急遽できた機能です。

なので、別の目的でこれを実装しようと思っていたほんの初期は、実は私自信がスマホアプリの開発をしてました。

開発の際は会社の周りの廊下を走ったり、歩いたり、走ったりしてました(笑)

いい運動になりました( ˊᵕˋ )

 

実際の実装は開発部の柱、M君が実装してくれました!

ありがとうー!⊂(^-^)⊃

 

この機能はなかなか面白いと思います。

お客様のほうで使えるシチュエーションがいっぱいありそうです。

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

 

「俺か、俺以外か。」ローランドという生き方 という本を読みました

旦那氏がローランドさんを大好きで、家にあったので読んだ本です。


面白かったですね!

私もローランドさんの動画を時々見たりしますが、この人は本当に言葉のセンスが抜群なんですよ。

複雑なことをズバっと端的に言ったり、わかりやすいたとえ話でたとえたりするのは相当頭がいい方なんだろうなと思います。

本の中に繰り返し出てくる言葉に

「俺は俺が大好き」

という話がありますが、非常にいい話ですよね。

「は?」

って思われるかもしれませんが、自分に自信があるというのはすごいことだと思います。

世の中、幸福度を決めるのは人間関係だ、という話を時々しておりますが、自信というのは人間関係の底の方で大事なんじゃないかと最近思います。

なんというか、日本社会では

「自信満々なイヤな奴」

という言葉がよくつかわれますが、なさすぎるのも問題だなと思います。

自信があまりにない人は、人間関係でよくトラブルを起こしているなというのが体感だからです。

多分、誰かの言ったことを悪い方向にとらえることが多いんだと思います。

自分を自分で否定するのは、ほどほどにしたほうがよいかなと思ってます。

 

 

 

「小さく賭けろ!」という本を読みました

この本は、以前「失敗の科学」という本の感想を書きましたが、その本に紹介されていた本です。

いや、いい本です。

失敗の科学にだいぶ内容が似ていますが、要は成功するためには、

「ちょこっとずつやって、ちょこっとずつ失敗することを積み重ねることが、成功のために大事」

ということです。

起業だけではなく、コメディアン、建築家、映画、戦争まで多岐な例にわたって、こういうことがいいんだよという話が紹介されています。

いくつか印象に残った話を書いておきます。

・事なかれ主義との決別

「時にはエラーを起こすのがクールだと教え込まないといけない。事なかれ主義の安全策を取ってはならないと覚えこませるのだ。」

「デザインとは複雑かつ把握困難な様相を呈する問題を解決に導くために、批判的かつ創造的な思考を適用してそれらの問題を理解し、視覚化し、描写するための方法論である。」

これ、どっかのスタートアップとかの話かな、と思うんですがアメリカ陸軍の話なんですよ。

意外ですよね。これも、数々の失敗を乗り越えてこのようなことを教えるに至ったそうです。

・失敗の心理的影響を克服する精神的強さと、当初はすばらしく見えたアイデアに固執せずに新しいアイデアを探る思い切りが必要

・「固定的マインドセット」対「成長志向のマインドセット」

固定的マインドセットというのは、例えば困難な仕事を与えられたときに

「この仕事をするのに能力があるから成功する or この仕事をするのに能力がないからから失敗する」

となる考え方ですね。

成長志向のマインドセットというのは

「この仕事をするのに自分はどんなことを学べるだろうか」

ということを考えるそうです。

固定的マインドセットの人は失敗したときはつまりその人に

「能力がない」

というレッテルを張られることなので、失敗を極度に恐れる、自分が失敗しそうなことはやらない、という傾向にあるそうです。

一方、成長志向のマインドセットの人は、失敗したときにもそれは自分の成長の機会ととらえられるので失敗を恐れない傾向にあるそうです。

まぁ~ この話はうなずけますよね。

周りにいる人も目に浮かぶというか。他人を批判しがちな人って失敗を極度に恐れますよね。

ちなみに、子供のうちからこういう傾向があるそうなのですが、

「能力をほめずに努力をほめる」

方がいいそうです。

子供が何か達成したときに

「あなたは頭がいいから○○なのね」

というと、失敗すると

「僕は頭が悪いと思われる」

と思って、失敗を避けるようになるそうです。

ですが、

「あなたはよく努力したね」

というと、次も努力すればいいので、失敗を避けるようにならないそうです。

 

・質問をする

人は6歳ぐらいから質問をしなくなる。なぜかというと、それは教育の問題で、学校に行くと自然と

「質問をして先生に面倒をかけるよりも、正しい答えを導く方が優秀な生徒」

という刷り込みが行われるからだそうです。

それね~。アメリカって日本と比べると人の考え方が自由なイメージありますが、それでもそうなんですね。

大人になって、いろいろなことを聞くと、

「こいつ、何も知らないアホなんか」

と思われたりするのが怖くて質問できないという人が多いと思います。

でも、質問をしないといろいろなことがわからないですよね。自分の思い込みでいろんなことを判断するのは危険すぎます。

 

というわけで、いろいろと得られるものの多い本でしたが、同じような話が、同じような人の実話で繰り返されるので退屈に感じる側面もありました💦

「失敗の科学」という本を読みました

これ、とってもいい本でおススメです!

読んだきっかけは、弊社に内定が決まった学生さんが

「この本を読んでアルバイトの改善をしました。」

というような話をしてくれたことです。

この本では航空業界と医療業界が取り上げられて比較されています。

飛行機の事故があると、どのようなことがあって事故にいたったのか、非常に細かく調べられます。

しかし、医療業界での医療事故があると、あまり調べられない。

医療ミスって皆さんが思うより頻繁に起きてるそうですね。

その結果、飛行機は事故率 0.0009%の非常に安全な乗り物になる一方、今日も医療事故で命を落とす人は多くいます。

イギリスでの調査では、10人に1人は医療過誤によりなんらかの健康被害を受けているそうです。

それほどまでに医療過誤は多いのに、失敗を振り返って分析するということがあまりにも行われていません。

 

さて、つまり何が言いたいのかというと、

「失敗を分析して対策しないと繰り返す」

ということなんですよ。

当たり前じゃん と思うかもしれませんが、この当たり前のことができている組織ってどれぐらいあるでしょうか?

医療過誤は、分析されていないから減らないそうです。

また、本書では

「失敗を報告しても、その人の責任を追及しない」

ことも必要だといいます。失敗を叱責されるとわかっていると失敗を隠蔽する組織になるからです。

また、何かを記録することが必要ですね。それは、ビデオとか音声テープとか、書類とかそういうものがよさそうです。
人の認知というのは、事実を後でゆがめてしまうものだからです。

誰でも、失敗を認めたくない。

のですが、失敗することが成功への近道なんですよね。

「そんなバカな!成功するということは、完璧な計画があって、それにそって組み立てられるもの!」

というのがよくないらしいです。

計画というのは絵にかいた餅であって、大体その通りに進まないので、試してみることが必要だそうです。

「人々は複雑な現実を単純にとらえすぎている。」

わかる~。

成功するだろうといわれて投資家から巨額の投資を得たスタートアップ、マーケティング時点では成功しそうだった新製品、その中でどれだけが生き残ったでしょうか。

 

非難しない、ということも大切なことだそうです。

どうやら、人間は人を非難したい生き物らしい。悲しいサガですね(>_<)

組織の中の仕事やプロジェクトが失敗すると、

「○○さんが悪かった」

とかいう話になりがちですね。そういうストーリーが受け入れやすいかららしいです。
本当は、もっと細かく分析したり対策すれば、建設的に次の失敗を防げるかもしれないのに、それが阻まれてしまいます。

あるいは、まったくその裏返しで、失敗を分析しようとする過程で

「なぜ私が責められるんですか!私が悪いというのですか!!」

という感情的な展開になり、

「いやいや、〇〇さんは悪くないから…。…。(面倒なことになったな)。まぁ、この件に関してはタイミングが悪かったよね。」

というなぁなぁな展開になることもあります。

人を責めるというのがとにかくよくないし、責められたと感じてしまってキレたりするのもよくないですよね。

 

他にこの本に書かれていたことで印象的だったのが、

「プロジェクトの6段階

1.期待
2.幻滅
3.  パニック
4.  犯人捜し
5.  無実の人を処罰
6.無関係な人を称賛

というくだりです。

仕事ではもちろん、これ、趣味のサークル・部活・転職・友人・恋人関係などでもよく見かけませんか?

最初はいいところばかり見えていても、中に入ったり親しくなればイヤなところももちろんあって、それで
「悪いのはあの人」
となって、その人を糾弾し→無関係の人がよく見えてきて、その人間関係を離れていく…。

ということがよくありますよね。

安易な

「○○さんが悪い」

というのはやめた方がいいですね。

 

私なりにまとめると

1.失敗は成功のために欠かせないので恐れない

2.失敗は原因をしっかり分析して繰り返さないようにしよう 安易な原因の推測で終わらせない

3.  失敗を責めることは失敗の隠蔽につながるのでやめよう

というところでしょうか。

 

とにかくよい本だったので、おススメです!

インパール作戦

8月15日は終戦記念日でしたね。

最近入社したアルバイトの学生さんが

「今度、インパール作戦をするんですよ。」

って言うんです。

なんかというと、探検部という部活に所属しているそうなのですが、第二次世界大戦の「インパール作戦」を日本で実行してみるということで、岐阜ぐらいから金沢まで長野の山を越えて10日ぐらい徒歩で歩いたりするそうです。

ひえ~ 大変だ~

と思いますが、なかなか興味深い試みですね。

で、インパール作戦について読んでみました。

https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%91%E3%83%BC%E3%83%AB%E4%BD%9C%E6%88%A6

Wikipediaさんの要約によると

「インパール作戦(インパールさくせん、日本側作戦名:ウ号作戦〈ウごうさくせん〉)とは、第二次世界大戦大東亜戦争)のビルマ戦線において、1944年昭和19年)3月[3]帝国陸軍により開始、7月初旬まで継続された、援蔣ルートの遮断を戦略目的として、イギリス領インド帝国北東部の都市であるインパール攻略を目指した作戦のことである。作戦に参加したほとんどの日本兵が死亡したため、現在では「史上最悪の作戦」と言われている。当作戦を始め、ビルマで命を落とした日本軍将兵の数は16万人におよぶ[4]

当初より軍内部でも慎重な意見があったものの、牟田口廉也中将の強硬な主張により作戦は決行された。兵站を無視し精神論を重視した杜撰な作戦によって多くの犠牲を出して歴史的敗北を喫したため、「無謀な作戦」「無為無策の戦術」の代名詞としてしばしば引用される。この記事は、コヒマの戦い英語版も併せて解説する。」。

ふむふむ。後ろのほうも読むとめちゃ長いのですが、興味深く読めました。

こういう失敗って、現代日本に通じるところがあると思うんですよね。

偉い人二人が話し合った時に、お互い責任を取りたくないから作戦中止のことを言い出せなかったとか。

日本だけじゃなく、人間の本質ってそんなに変わらないわけで、歴史に学ぶところって大いにありますよね。

 

私は第二次世界大戦の話を読んだり聞いたりするのが好きです。

以前も下記の投稿で書いたことがあります。(この投稿のタイトルが恥ずかしい~(*ノωノ))

https://summer-snow.onlineconsultant.jp/2014/08/21/%e6%a0%b9%e6%80%a7%e8%ab%96%e3%81%a0%e3%81%91%e3%81%98%e3%82%83%e3%82%84%e3%81%a3%e3%81%b1%e3%82%8a%e3%83%80%e3%83%a1%e3%82%88%e3%80%80%e3%83%80%e3%83%a1%e3%80%82%e3%80%80%e3%83%80%e3%83%a1%e3%83%80/

 

技術の軽視・制度変革に関する及び腰・問題の根本原因に対する軽視、とかがやがて大きな失敗になるわけで、少なくとも自分の会社ではそうならないように気を付けていきたいなと思います。

 

仕事における成長とは

私の個人的意見なんですけれども!!(ここは私のブログなので、当たり前ですが(笑))

 

仕事における「成長」とはなんだろうと考えました。

 

特にITの業界であれば、仕事=勉強なので、仕事をどんどんこなすことで、

「昨日できなかったことが今日できる」

ということで成長を感じられるし、満足感を得られるとは思います。

私も社員さんにできることが多くなってほしいですし、弊社では新入社員さんには勉強の時間を多く取って、知識を得てもらうようにしています。

とはいえ、こういう「昨日知らなかったことを今日知った」タイプの知識タイプの成長というのは世の人が思うほど「仕事」「会社」にとって価値がない気もします。

 

例えば、プログラマの仕事だと、転職サイトに書く場合もチェックボックスで並んでいて

「できる言語にチェックをつけてください
Java PHP Ruby C C# javascript Python Swift Kotlin」

にチェックをつけるんですよ。多いほうがよさそうな気がするじゃないですか。

でも、履歴書で一番見ないゾーンなんですよ。

 

こういう新しい言語が理解できる、新しい技術が使えるって時間さえあれば大体の人がWebとかで勉強を完結できる時代だし、お金を払ってスクールやセミナーに行っても身につくもんです。

つまり、時間orお金で得られるスキルですよね。

 

で、スクールやセミナーを否定するわけじゃなくってですね。

要はペン習字とか、英語とかと同じで、スキルは手段であって、目的じゃないんですよね。

こういうスキルがいくらあっても、画竜点睛を欠くというか。

仕事にとって、あっても困らないけど、なくてはならないものでもないんですよね。

仕事で身につけてほしい成長は、私にとってはお金や時間をかければできるようになるものではなくって、仕事の中で身につくもんだと思います。

 

仕事という大枠を見た際に必要なスキルって、毎日同じことをたとえしていたとしても、改善の余地はその中にいくらでもあるだろうし、それを見つけることだったり、変わり続ける時代環境に対応することだと思うんですよね。

そういうことを提案できる能力とか、問題を見つけることができる能力とか、世にある新しいものを自分の仕事に取り入れる能力とか。

あるいは、人と話し合って難しい問題を解決したり、利害が一致しない人とも折衝して落としどころを見つけることができる能力じゃないんですかね??

そして、

「〇〇さんの言うことなら取り入れるかねぇ」

と思わせる信頼獲得能力もそうだと思います。

 

信頼を獲得するって難しいことで、もう、日々の積み重ねなんですよ。

時間を守るとか、約束したことは守るとか、嘘をつかないとか、さぼらないとか、悪いことをした時は謝るとか、自分から行動するとかですね。

 

「そんなんもって生まれた性格じゃん!」

という人もいるかと思いますが、私はこういうことは努力だと思います。

「USJを劇的に変えた、たった1つの考え方」という本を読みました

「USJを劇的に変えた、たった1つの考え方 成功を引き寄せるマーケティング入門」

という森岡毅さんの本です。

しかし。

以前読んだ「マーケティングとは『組織革命』である」とほぼ内容がかぶっていて、あんまり新しい話はありませんでした…。

「マーケティングとは『組織革命』である」という本を読みました

マーケティングって本当に大事ですよね。

 

すごい秘密をお話します。

弊社では、

「配送会社のための『ODIN リアルタイム配送システム』」

と弊社製品を定義しています。

これねー、昔は『誰のための』を定義していなかったんですよ。

「こんな機能がありますから、ほしい人が選んで買ってください。」

というやり方でした。

全然売れていませんでした。

ある日、私はマーケティングということに本気で取り組みました。本を何冊も読んで勉強しました。

そこで言われていたのが

「誰のためのものかを定義しろ!!」

ということでした。

で、

運送・配送業のための『ODIN リアルタイム配送システム』」(当時はSmart動態管理という名前でした。)

と定義しました。

それまでは、いろんな業界に売っていたので、運送・配送業という業界に絞ることが、最初は怖かったです。

それ以外の業界の人に売れなくなるんじゃないかと思ったんです。

しかし、この定義づけをしてから、売れ出したんです。

お客様にわかりやすかったんです。

そして、開発する側も、開発すべき機能を絞り込むことができました。

 

なので、マーケティングは勉強する価値があることだと大実感しています。

 

さて、長くなっちゃいましたが💦、この本で私がこれは覚えておきたいなと思ったことは

①「顧客が本当に喜ぶもの」と「顧客が喜ぶだろうと作り手側が思っているもの」は必ずしも一緒ではない
作る側の間隔は、消費者から最も遠ざかることを意識する

②「技術力」だけじゃダメで「マーケティング力」と両方が必要

③最も重要な経営資源は人

ですね!

 

で、私は「マーケティングとは『組織革命』である」という本を先に読んでいたので、あまりインパクトを感じなかった部分もありますが、普通に見れば読みやすく、大変勉強になる本です。

マーケティングが仕事の人だけでなく、なにがしかの利益団体にいる人には参考になる情報があるかと思います。

オススメの本です!

【プログラマー向け】社内勉強会を行っております

Kくんの発案で、2月から、不定期に弊社の社内のプログラマーさん向けに勉強会を行っています。

講師は有志。

なんですが、弊社のデベロップメント課の皆さん(プログラマーのチーム)は大変意識が高いので(`・ω・´)

全員がやってくれました!⊂(^-^)⊃

なんとM君は2月~5月で2回もやってくれました。スバラC。

皆さん、やっぱりプログラマーになろうという人は勉強が好きなんですね( ˊᵕˋ )

学ぶことって楽しいですよね~。

私も、日々これ勉強ですし、何かを教えてもらえるってありがたいことです。感謝ですね!

勉強にプラス、社内の人たちが、

「あー、こんなこと考えてるんだ」

とか共有してくれるのは、なんか新鮮な驚きや発見があります。

 

今後も続けていきたいと思います。

弊社では、現在プログラマーと営業を募集しています!

採用情報はこちらからどうぞ!

「エリック・エヴァンスのドメイン駆動設計」を読みました

いやー、私が紹介するまでもなく、有名な名著だと思いますが。

ほんっといい本。

しかし、超読みにくい。

翻訳のせいもあるのかもしれない。

分厚いのもありますが、7月から読み始めて、なんと8か月もかかりました。(´ω`)

 

ぜひ、プログラミング始めて3年目ぐらいの人たちに読んでほしい。

プログラミングというのは難しいな、と感じ始めた人たちに読んでほしいです。

特に、内容は自分がかかわらない分野の業務システムなどを作るプログラマーにとって必要な知識があります。
とはいえ、C向けのプログラムでも大切な内容も含まれています。

内容は豊富すぎるのですが、あえて私が注目したことをまとめておくと

①その業務分野のプロの話をよく聞くこと。

②言葉の定義をちゃんとする(ユビキタス言語)
〇〇さんの開発しているあの機能とか言わずに、ちゃんと名前にする
そして、共同作業するプログラマー全員がその言葉をちゃんと理解する

③モデルをちゃんと作る
モデルというのは概念。概念がちゃんとしていないと、よいプログラムにならない
ここで、①が重要になってくる。その業務分野のプロの話していることをちゃんと理解して、何が重要なのかをつかむことが大事。

④ソフトウェアを常に進化させ続けるために、しなやかな設計にする
作らないことにはわからないことが多すぎる。(本当に)
常に前進するのを恐れない。

 

特に、私が衝撃を受けたのは③ですね。

モデルとは概念なのだ!!

プログラミングとは、概念を読んでわかるようにすることなのだ!!

 

もうね、ヘレンケラーが

「Water!!!!」

と叫んだような衝撃ですよ。

そういわれればそうなんだけど、地球が大きすぎて見えないように、それに気づいてなかった。

私の今までやってきたプログラミングは小手先だったなと感じました。( ゚Д゚)

やりたいことをやるためにプログラムが存在し、将来の自分やチームメイトがわかりやすいようなコードを志してやってきてましたが、そうか、概念か。

 

逆に言うと、プログラミングをしていて、はっきりしてくる概念もあるわけです。

この体験を最近しまして、今弊社で「ODIN リアルタイム配送システム」にある機能をつけているのですが、そこで、なんか仕様がモヤモヤしているところがあるわけですよ。

コードを見ると、配列でいろいろif文を駆使してなんとかやっている。読むのが大変なやつです。

で、ドメイン駆動設計の考え方に基づいてクラス設計をやり直したら、驚くほどコードがすっきりしまして。

そしたら概念がクリアになったので、仕様がすっきりしました。

そしたら、弊社のソフトウェアが持つ特徴、他のソフトにはなく、うちがお客様に届けるべき価値も明らかになりました。

 

というわけで、杏寿郎、お前もドメイン駆動設計(DDD)をしてみないか。

おススメの本です。