クラス設計の手順
というスライドを作成しました。
<対象>
・プログラミングを始めて3年以上
・オブジェクト指向でプログラミングをしている
・クラス設計などを担当するようになったが、設計とはどうすればよいのかわからない
・なんだか設計が後一歩と感じる
クラス設計に関して、どういう設計がよいなどの論は多くあるが、どうやったら設計ができるのかという論はあまりないので作成しました。
良かったら読んで感想を教えて頂けると嬉しいです。
前回はこちら↓
というスライドを作成しました。
<対象>
・プログラミングを始めて3年以上
・オブジェクト指向でプログラミングをしている
・クラス設計などを担当するようになったが、設計とはどうすればよいのかわからない
・なんだか設計が後一歩と感じる
クラス設計に関して、どういう設計がよいなどの論は多くあるが、どうやったら設計ができるのかという論はあまりないので作成しました。
良かったら読んで感想を教えて頂けると嬉しいです。
前回はこちら↓
言わずと知れた有名な本ですよね!
設計とアーキテクトは一緒の意味。
クリーンなアーキテクチャーを作ることが早くソフトウェアを作るために必要、という話が冒頭にあります。
いや、本当にそうなんですよね。
人数がいくらいようと、微妙な設計のソフトウェアは生産性が地に落ちてしまいます。
なので、とにかく設計が大事です。
ただ、私は経営者でもあるので、市場に投入するスピードも必要だということも理解しております…。
ここは本当にジレンマなんですが、要はバランスとしか最終的に言えません。
あまりに設計がずさんなものは、いくら早くてもリリースしないほうがいいですし、かといって設計にこだわりすぎてリリースがずっとできないというのも問題なんですよね。
リリースしてから気づくビジネスニーズというのはよくあることで、そのために設計を直さないといけない、ということもよくあることです。
多くのプログラマが間違ってとらえている話があるそうです。
「システムが動作することと、簡単に変更できることとどちらが大切か?」
多くの人が、動作すること、と答えるでしょう。
しかし、簡単に変更できることの方が重要だと筆者のボブおじさんは言います。
完璧に動作するが、変更できないシステムと、変更できるシステムだったら、後者の方にバリューがあります。
まー、そりゃそうですね。
後者は動作するようにすればいいわけですからね。
私も、19年近くプログラミングをしていますが、本当に設計が大事です。
これがおろそかにされていたら、プログラマーは常にバグと戦わねばならず、プログラマーの仕事のほとんどがバグと戦う仕事になってしまいます。
なので、あるプロジェクトが後半になってきたとしても、設計に問題があるとなれば、ウチではリリースを延期することもやむを得ないと私は思います。
さて、この本については多くの人が解説を述べていると思うので、ここで詳細を書くのはやめにして、私が特に心にとめておきたいことだけ抜粋しておきます。
①安定した抽象に依存すること
またまた、ODIN リアルタイム配送システムにすごい機能が爆誕してしまいました…!
ドライバーさんのスキルや担当に合わせて最短の配送ルートを組む機能です。
運送会社、配送会社さんで何人かドライバーさんがいると、よく聞く話が
「このドライバーさんはこのエリア担当」
「このドライバーさんはあそこは出禁になっている」
などという話です。
それを考慮して、配車担当さんがドライバーさんがいつ、どの順番で配送先を回るかという配送計画を作るんですが、これは大変なことなんですよね。
配送先が20とか少なければいいんですが、それが数がもっと多い場合、その最短ルートを計算するのは人間にも難しいし、コンピューターにさえ難しいとされています。
その配車を組むときにミスがあったりすると、配送先やドライバーさんから配車担当さんが怒られてしまう…。
配車担当さんのストレスの原因だったわけです。
でも、もうそのストレスとはおさらばです!!
ODIN 配送計画が解決しますからね!!٩( ‘ω’ )
スキル考慮機能 イメージ
そして、今回さらに新しい機能も生まれたんですが、その名も「搭乗」機能。
俺はガンダムで行く!!
ドライバ―さんと車両の組み合わせを、配送計画にあらかじめ設定してルートを組む機能なんです!
今回、開発は設計を私が担当し、実際の実装は新進気鋭のS君、ちょっと難しいUI部分は若手のホープ、S君が(どっちもイニシャル一緒)担当してくれました!
ありがとう!!
ODIN リアルタイム配送システムへのお問い合わせはコチラからどうぞ!
私はうちのプログラマーさんに
「このメソッド(or クラス)が何をしているか、口で説明して」
と言う時があります。
多分、言われた方は
「え、なんで?後藤さんはコード見てもわからないからかな?」
「面倒だな…。」
と思うかと思います。(笑)
しかし、これは意図があってやっていることです。
どういう意図かというと、
そのコードがどういう意味なのか、その人がコードと違う形で出力する必要があるから
です。
大体、「口で説明して」と言って、スパッと帰ってこない場合は、そのコードがよくないケースが多いです。
そういうコードは
・やってることが多すぎる
・書いた本人も実行 or デバッグしないと結果がわからない
というコードなんですよ。
当たり前なんですよね、作った人が何をしようかわかってないのであれば、微妙なものができてしまうのは。
書く、言う、図にする。
これらは考えを人に伝えるために重要です。
そして、人というのは他人だけではなくて、自分も含まれます。
人に悩みを聞いてもらって、すっきりした経験がある方は多いと思います。
問題が明らかになるからだと言われていますよね。
プログラミングも一緒です。
プログラムを書いたことがない人にはわかりづらいかと思いますが、プログラミングって抽象的なモヤモヤっとしたことばっかりなんですよ!!
抽象的なモヤモヤっとしたことをいかにわかりやすくするか、というのがプログラマーの仕事なので、口で言うのは、自分で問題を整理する、そのプロセスです。
逆に、私もプログラミングの設計などで悩んでいる時に、スタッフの方に聞いてもらって解決することも多いです。
特にAI時代において、小難しいコードを書くこと、小難しいコードを読むことはAIを使えば誰でもできるスキルになっています。
しかし、モヤモヤしたこと、抽象的なことを整理することは、今のところ人間の方ができます。
なので、そのスキルを磨いたほうがよさそうです。
書いたり、話したりしていきましょう!
コーヒーでも飲みながら
PHPカンファレンス2024に行ってきました!
12月22日って… 厳しくない?M1もあるし!と思ってましたが、行きました。(`・ω・´)
昼過ぎから行きました!(本当は12時45分の成瀬さんの講演から聞きたかったのですが、前日飲みすぎて起きたらお昼でした(泣))
①APIデバッグとリバースエンジニアリング
https://speakerdeck.com/nagix/apidebatugutoribasuenziniaringu-7ebf6dc3-989c-46a2-9269-7b157195d94e
聞いてよかった!
Postmanの人が話すPostmanの話。
Postmanって本当にすごいツールで、かなりお世話になってます。
Postmanの中の人たちに足を向けて寝られないよ…(ノω・、)
Postmanのことについて聞くたびに、
「エッ そんな機能あったの??すごー!!」
って驚くんですけど、この日もそうでした。
下記の部分にマウス当てると、色々なことを教えてくれる。
ここを触ろうという発想すらなかったw
Postmanにconsoleという機能がありコンソールにログが出せる!
左下のここ!見たこともなかった!(ジョックロック風に)
Postmanがネットワーク接続とかできないとき、これで調べられる!
PostmanでクライアントアプリとAPIのリクエストを検査したり、トラフィックをキャプチャもできる!
(使う日が来るかもしれない)
②AlgoliaからOpenSearchに乗り換えてみた
https://drive.google.com/file/d/1sh9EE0kNmfcp_rotMq-RYiTYPYicE05-/view
ウチも検索の問題はあるので職務に直結するので大変ためになりました。講演者さんの実体験に基づくお話なのがよかったです。
・もともとはAlgoliaというツールを使っていたが、半角カナやへーべーなどが検索できないし、高額
・MySQLのFULL TEXT INDEXこれはかなりCPUを食うらしい。。。CPU100%になってしまったらしいです。
・AwsのOpenSearchへ乗り換えをし、コストダウン(4分の1になった)検索機能が向上
③責務を分離するための例外設計 – PHPカンファレンス 2024
https://speakerdeck.com/kajitack/ze-wu-wofen-li-surutamenoli-wai-she-ji-phpkanhuarensu-2024
この時間これしかやってなかったんですよね(笑)。でもためになりました。┌o ペコッ
例外って大事だよね~
・問題がある場合は早く例外を投げるべし
・入力値のチェックはバリデーションで行い、IDが想定外の場合、バリデーション実装のミスなので、LogicExceptionを投げるべし
そうすることによって、クラスの中の問題なのか、クラス外の問題なのかが切り分けられる、という意味なのかな、タイトルはそういう意図なのかな、と思いました。
<ライトニングトーク>
ライトニングトークはどれも素晴らしかったですが、印象に残ったものを残しておきます。
④var_dumpとvar_exportの理解から始めるPHPのソースコードリーディング
PHPのソースコードを読んでみようという話
⑤Xdebug ProfileによるCIパフォーマンス改善のためのボトルネック解析
Xdebug Profileを活用して、PHPUnitが呼び出すコード内のパフォーマンスを阻害するメソッドを特定する方法。
そう。PHPUnitを回すのにかなりの時間がかかっていませんか?ウチもやらないと…。
⑥Opcodeを読んでいたら何故かphp-srcを読んでいた話
https://speakerdeck.com/murashotaro/opcodewodu-ndeitarahe-gu-kaphp-srcwodu-ndeitahua
PHPのソースコードを読むのは大変だったら、Opcode(中間コード:オペコード)を読んでみるのがオススメ。
夜は懇親会でした!!
会社の子も参加してくれましたし、いつも楽しい会で、いろんな方とざっくばらんにお話できて楽しかったです( ˊᵕˋ )
なんとじゃんけん大会で勝ちまして、PHP Conference Tシャツを頂きました(^^)v
さて、タイトルにある参加10年目なんですが、このブログによると、なんと私はほぼ毎年PHPカンファレンスに行っている!!( ゚Д゚)
初出は2014年のこの記事なんですよ。
読みますと、HHVMの話を、Facebookの開発者、Paul Tarjan氏が話したセッションを聞いたという記憶がよみがえってきます。
PHPカンファレンスってすごいなー、わざわざ外国からすごい人が登壇するんだなー、というめちゃくちゃ良いイメージから私のPHPカンファレンスは始まったのです。
2018年が下記↓ このころは、ソシャゲの会社がスポンサーなイメージ強かったですね。
それにしても毎年言ってますけど、PHPカンファレンスって参加費無料ですごい勉強になるし、すごいモチベーションアップになるので、このまま続いていってほしいですね。
10年経っても、PHPという言語のポジションってあんまし変わってないですね。
個人的な感想ですが、PHPのポジションって、やっていてかっこいい言語じゃない、というとらえ方がどうも一般的な気がします。
いわゆるつよエンジニアを目指すみたいな界隈の人が
「やってるのが恥ずかしい」
「片手間にやれば十分な言語」
という感じみたいに言うのがちょっと残念ですね。
簡単で機能が少ないので、こういうことを言われるのかもしれません。
しかし、大AI時代になりましたので、もしかしたらこの辺が変わっていくかもしれませんね。
先週金曜日、次のプレスリリースを発表しました。
https://www.value-press.com/pressrelease/348447
久々の大型機能のリリースです!
ODINアプリ:レシートの画像を読み取って文字にし、日報に添付する操作イメージ
今回はですね、端的に言いますと、ODIN リアルタイム配送システムの運転日報に画像をつけられるようになった、ということです。
結構多い話が、
「高速代、ガソリン代を庸車に頼んでいるので、その経費精算をしたい。
エビデンスとしてレシートの写真がほしい。」
とか
「荷物を受け取る人がいることもあるし、いないこともあるので、納品した写真を撮っておきたい。」
とか
「作業したので、その写真を日報に記録したい。」
とかの場合に、写真と、その写真の位置情報があれば便利!というわけです。
画像があれば、日報の説得力がかなり増します。
多くのお客さんからご待望頂いていた機能でした。
なので、やっとリリースできたことが大変嬉しいです( ˊᵕˋ )
で、画像がつけられる動態管理製品は他にもあると思うんですけども、ODINはそれだけじゃないんですよ!!
AIによる画像認識で、文字が読み取れたり、バーコードがスキャンできたりするんです!
これは文字で説明するのは難しいので、動画にしました↓
詳しくは、プレスリリースを見て頂きたいと思います。
さてさて、開発ウラ話です。
今回はWeb側を設計を私が行い、実装は新進気鋭のS君+M君、Androidアプリを不肖私が実装させていただきました。(๑•̀ㅂ•́)و✧
実は、もともと画像アップロード機能というのはODIN内にあったんですが、特定のお客様だけが使っていて、それを今回他のお客様も使いやすいようにしたという流れなんです。
なので、一から開発ではないので工数はそれほどはかからない… 予想だったんですが、既存の機能は古い部分もあったので、API、アプリ関係は作り直した部分も多くなりました。
結局開発に4~5人月ぐらいはかかりました。
今後の展開としては、画像を配送先の軒先情報として活用できたりする予定です。
この機能にご興味ありましたら、コチラからお問い合わせください!( ˊᵕˋ )
若手プログラマーの疑問に答えていくシリーズ第2弾を書きました!
よかったら読んでみてください。⊂(^-^)⊃
対象者は下記のような方です。
-プログラミングを始めて2,3年以上
-オブジェクト指向でプログラミングをしている
-オブジェクト指向のプログラミングを理解はできるし、自分で書いているが、うまく書けているか自信がない
前回はこちら↓
ODIN リアルタイム配送システムの機能強化についてお知らせです。
ODINには、「停滞検知」 という機能があります。
どんな機能かというと、一定時間どこかに止まっていた場合、管理者さんにお知らせが来る、という機能です。
弊社の動態管理機能で、今どこに誰がいるかはもちろんわかりますし、記録も残るので、どこにいついたかもわかるんですが、ずっとは見てられないですよね。
なので、ODIN 動態管理では、止まっていた時間・場所をピックアップして知らせたり、記録に残すことができるんです。
これ、大変人気のある機能なんですよ!
以前からあった機能なのですが、9月に「停滞検知」をしない時間を設定できるようにしたり、無視するステータスを設定できるようになったんです!
ですが、9月にこのアップデートをした際に、お客様から
「メールを送る先を細かく設定したい。」
というお話があり、そのためのアップデートも10月25日に行いました。
派手な機能強化もいいんですが、こういう細かい使い勝手が、結局長い目で見たお客様の利便性にかかわっていくんだと思います。
ココ、一生懸命やっていきたいですね。(`・ω・´)
これからも、お客様の声にお応えしていきます!
この機能に興味があればこちらのODIN 動態管理問い合わせページからどうぞ!
トラック イメージ
一昨日、下記のプレスリリースを発表いたしました。
ソフトウェアの業界にいらっしゃっても、パッケージソフトなどを売ってらっしゃらない方には中々なじみのない世界だと思いますが、実はソフトウェアの流通網って細かいんですよね。
メーカー の次に、ディストリビューターさんと呼ばれる大手の卸の会社さんがあって、その次にリセラーさんと呼ばれる販売代理店があり、それが2社、3社もあることがあって、やっとエンドユーザーさんに販売されるというケースが多く存在します。
ダイワボウ情報システムさん(略称 DIS)は、そんなディストリビューターの中でも売上高8000億円を超える最大手の一社なのです!
そこでODIN リアルタイム配送システムを取り扱っていただけることになったので、リセラーさんはDISさんからODIN リアルタイム配送システムが買えるというわけです。
ODIN リアルタイム配送システムはリリースされてから早12年のシステムですが、さかのぼること12年前…。
私は以前はセキュリティソフトの会社にいたので、ディストリビューターさんに知人も多かったんですよね。
で、あるディストリビューターの方に
「ODIN リアルタイム配送システムを取り扱ってください」
とお願いしたところ、
「スポットならいいよ。」
と言われてしまいました。
それはつまり、1回1回の販売ならしてあげてもいいが、そのディストリビューターさんのいつものラインナップに載せること(商品登録と言います)はできない、という意味なのです。。。
卸売りの会社さんですから、ある程度販売ができると思えないと、取り扱って頂けないわけです。
悔し涙で枕を濡らす日々が続きました。(>_<)
(大げさに言ってるだけですが)
それから12年…。
なんと、天下のダイワボウ情報システム(DIS)さんに商品登録され、取り扱っていただける日が来たわけです!!
ヤッター⊂(^-^)⊃
ODIN リアルタイム配送システムがそれなりの販売額が見込める製品、ちゃんとした製品だと認めて頂いたということだと思っています。
DISの皆様、うちの担当スタッフの皆様、有難うございます!
これで、販路が増えましたので、例えば
「付き合いのあるリセラーさんから買いたい」
という場合や
「ODINの販売店になりたいが、ノルマがあるのはイヤだ」
などのお客様のニーズに素早く応えることができるようになりました!
ODIN リアルタイム配送システムって、スマホがあると便利なので、スマホの販売店さんが、販売代理店になっていただけるケースが多いんですよ。
運送・配送だけでなく、今は卸売り、メーカーさんなどからのお問い合わせも多く頂いています。
スマホってもう国内販売は頭打ちですが、業務用であれば2台持ちにしてもらうという市場があるんですよね。
ご興味があれば、ぜひお問い合わせください。
お問い合わせはコチラから!
株式会社SKL 代表取締役社長 松永様、営業部 主任 齊藤様、営業部 副主任 藤田様にお話を伺いました。
SKL様は、親会社がお酒の卸売り大手の「柴田屋酒店」様で、その物流部門を担う会社さんです。
私にとって、初回の商談に同行したり、「柴田屋酒店」の社長さんにもお会いしたりしたので、とても思い出深いお客様の一社です。
というわけで、今回のインタビューには私も同行させて頂きました!
皆さま、ご協力有難うございました。
詳しい事例はコチラ↓で公開しています!
さて、本題なんですが、SKLさんはODIN(オーディーン) リアルタイム配送システムを本当に使い倒して頂いているんですよね!
お酒をレストランさんなどに配送されているのですが、現在位置情報と、配送計画を合わせてみれば、進捗が一目瞭然なのです。(`・ω・´)
それを業務に生かして頂いている。
この大きい画面に、ODINのリアルタイムマップが映っています!地図がきれいだったことも決めての一つと松永社長さんがおっしゃってました( ˊᵕˋ )
また、日報も今まで個別に作成されていたものが、ODINで効率化されたそうです。
一つ興味深かったお話は、ODINを検討したきっかけとして
「お酒が好きな人が多く、社風的にも従業員同士で飲みに行くことが多いです。
その中で、「だれだれさんの配車は平等でない」「自分が楽できるような配車になっている」などの不満を抱くドライバーがいました。
それがシステムで配車することにより、効率的かつフェアな配車が出来るようになりました。
人の手で考えるより、システムに考えさせるとフェアになるので、ドライバーの説得ができています。」
という話ですね。
いや~ こういうお話って、本当に配送・運送をされている会社さんだとどこの会社でもありますよね。
私、時々思うんですけどODIN リアルタイム配送システムが解決している問題って「心の問題」なんですよね。
特に、今の時代、「生きづらい時代」と言われています。
中でも不公平を感じるというのはかなりのストレスです。
それを減らすには、「公平感」を出すことと、数字で「なるべく公平である」ということを証明するしかないと思っています。
そして、正直なところ機械を使わないと配車が公平であるのは難しいのではないかと思います。
心の問題を解決していきたいなと常日頃考えていますので、それができたというのは嬉しい限りです。( ˊᵕˋ )
また、基本的には回るルートが決まっていらっしゃるそうなんです。
「ウチはルート配送だから配送ルート計算する機能はいらないかな。基幹システムで注文とルートを作ってるし。」
と最初は仰ってたんですが、1日に数件ぐらい、急な注文や注文忘れなどでイレギュラーに何件か行かなければいけない配送があるそうです。
そのルートを考えるのが本当に苦痛だったそうです。
今はそれがODINで一瞬で終わるので、とても快適だというお話です。これもとっても嬉しいですね。( ˊᵕˋ )
ちなみに、固定ルートの方は、CSVなどでODINに取り込んで頂いて、日々の進捗や日報などに生かしていただいています。
マップを見ながら「今、これ帰ってきてるんだね」などとお話されています。
トラックはすべてリーファー車だそうです。リーファー車とは、外部の温度に左右されずに庫内の温度を調整できる機能を持つ車です。お酒は温度管理が大事ですもんね。
代表取締役社長 松永 様
後、SKLさんへお伺いすると、お互いに下の名前で呼び合ったりされていて、いい感じなんですよね( ˊᵕˋ )。
「お酒の会社なので、お酒が好きな人が多いので、基本的に飲みに行くことが多い。」
というお話を何度もお聞きしています。
「現場の声を重視し、経営に取り入れている。」
というお話も何度もお聞きするので、これはリンクしているんですよね。
飲みにケーションなんて役に立たない という話をよく聞きますが、それって本当なの?とも思いますね。
また、体制がしっかりされているので、有給も多いし、残業も少ないとお聞きしています。( ˊᵕˋ )
採用の面接の際に、ODINをその応募者の方が見て、
「しっかりと管理されている会社なので、この会社はブラックではない!」
と感じたというエピソードもお聞きしました。
そうなんですよ。(`・ω・´)
なんとODINは採用にも役に立つ。
嬉しいお話ですね!!
また、SKLさんの事例をまとめていて思ったのが、ウチのコンサルタントのA君が何度も足を運び、SKLさんの課題をお聞きしながら、ODINでできることを最大限使っていただけるようにご提案した甲斐もあったんだろうなと思いました。
A君にもありがとうですね!( ˊᵕˋ )
お客様の課題って、お客様ごとに複雑だと思うんですが、弊社そのあたりのサポートはかなり力を入れております!
御社の課題もぜひご相談ください。お問い合わせはコチラから。