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

有名な本なので、タイトルを知っている人は多いと思います。
私もタイトルは知ってましたが、この度初めて読みました! 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人のプログラマーがいる大企業が出している製品よりも、ガレージの二人組の方がいい製品を出している、ということは起こるわけです。
我々もガレージ側なので、得られたことを生かしてがんばらないとな!って改めて思いました。

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

 

 

「時間最短化、成果最大化」という本を読みました

これはたまたまアマゾンで目に入ってきて

「なぜ、あの人は私の150倍の成果が出せるのか」

という小見出しに興味を惹かれてしまいました。

そりゃ、150倍成果を出したいからね(笑)

この本は、要はスキルよりも考え方が大事という話が繰り返し出てくると思います。

いや~ ほぼ100%同意ですね。

スキルって大した違いじゃないんですよね。

皆さん、スキルさえあれば仕事がうまくいくって思っている人が多い気がしますが。

経験的に、仕事というフィールドにおいて、同じことに遭遇しても成果を上げられる人、上げられない人の差はスキルの差ではなくて、考え方の差なことが多いと思います。

最初に衝撃的な話があるんですが

「社会人になった最初の上司がどんな人だったか」

ということが、ビジネスパーソンとして成功しているかしないかの違いを最も作るらしいです。

それは、考え方というのをその人に刷り込まれるからだそうです。

へぇ。

これもよくわかりますね。

私は最初にサラリーマンとして働いていたときは外資系に勤めていたので、全員転職で入ってくるんですよ。

ただ、びっくりするんですけど、同じ会社から来た人って同じような考え方をしているんですよね( ゚Д゚)

そして、同じような不平不満を毎日言って、新しい職場になじめず、同じような期間で辞めちゃうんです。

 

さて、本自体は読みやすくてすぐ読めるし、たとえ話もあって腑に落ちながらも、非常に穿った内容なのでおススメです。

下記はメモです。


①後でゆっくり考えよう、を止める
打ち合わせは相手とのすり合わせ

②重要度と緊急度が一緒なら、早く終わる方を終わらせる

③10回やると1回成果が出る

④3歩歩けばチャンスがある

⑤面倒なことをやる。
面倒なことは他人はやらないから。

⑥宇宙でボールペンが使えないから、優秀な科学者が120億ぐらいつぎこんで宇宙で使えるボールペンを作った。しかし、ロシアは
鉛筆を作った。ボールペンを作ってないか、難しいことをやるのに悦に行ってないか考える。

⑦欠落的欠点は直したほうが良い。(仕事をしていくうえで致命的な欠点という意味です)
ケアレスミス
スケジュール管理ミス
タスク管理ミス

ケアレスミスが多い人には丁寧にチェックしてね、という

⑧会議では必ず発言しよう

⑨リアルな空間では自分の興味のあるなしに関わらず情報が飛び込んでくる。ネットでは、自分の興味あるものは深堀りできる
アマゾンは新しい発見に向いてない

⑩無理と思う問題をチームで話し合ってみよう

⑪「作る」までじゃなく、お客様に伝わるまでが仕事

空が高くなってきましたね

AIでプログラマーの仕事がなくなるのかという話

よく耳にする話ですよね。

ChatGPTがはやってから、さかんに言われるようになりました。

ノーコードの流行もあると思います。

私の今のところの推測では、

「AIのような仕事しかできないプログラマーはいらなくなるだろう」

と思います。

例えば、ちょっとした処理しか書けないとかですかね。

大体のプログラムが、情報をストレージから読み出して画面に描画し、また入力されたものをストレージに書き込む、というのがおおまかな役目だと思います。

単純に一つの画面に描画する、とかちょっと装飾をした画面にするとか、入力値を読み取ってちょっとしたバリデーションをして機械的にストレージに書き込む、ということしかできないプログラマーの場合、AIやノーコードに置き換えられてしまうと思います…。

ただ、プログラムってそんなに単純なものばかりではないんですよね。

私はプログラミングという仕事は小説家とか写真家とかに近いと思ってます。

プログラミングをしたことのない人にはピンとこない話ではあると思うんですが💦

入口の敷居は低くて、誰にでも小説を書いたり、写真を撮ったりすることができますよね。

しかし、人を感動させる小説や、美しいなと思える写真は一握りの人しか作れません。

それにはノウハウも大切だと思うんですが、積み重ねの実践も大事だと思うんですよね。

 

①複雑な対象物を観察する力

②それをすっきりとしたモデルにする力

③それを形にする力

④作ったものを多くの他人に批評してもらう力

⑤批評を取捨選択して取り入れて改善していく力

 

が必要だと思ってます。

 

AIに今のところできそうなのは③と④でしかないんですよね。

ちょっと話がそれますが、④ってのは、意外とハードルが高いものなのかなと感じています。

多くの人が、

「作品を作ったんだけど恥ずかしくて世に出せない」

という経験があると思います。コードレビューにまつわる問題も色々ありますよね。

仕事であっても、自分の書いたものが少しでも批評されると

「心が折れてしまう」

という人にはもしかしたらプログラミングもそうですが、クリエイティブな仕事には向いていないのかもしれません。

ここはAIは一抹のためらいもないでしょうから、自分の書いたコードを世にさらしてくれるでしょう。(笑)

 

前にも書きましたが

「古池や 蛙飛び込む 水の音」

まで世界をそぎ落とし、表すことができるような能力なんじゃないかなと思います。

 

ソフトウェアを作るというのは楽しい仕事です。

上述したように、まだまだ人間がやる余地があります。

むしろ末端のコードは最近はChatGPTで作れるので、より創造の余地がある仕事にシフトできている仕事だといえます。

弊社では新卒のプログラマーさんを大募集中です!

ウチでは運送業の問題を解決するソフトウェアを作っています。

一緒に世の中をよくする仕事をしていきましょう!

新卒募集の詳細はコチラから!

一緒に働く仲間を募集しています!

サイコロジー・オブ・マネーという本を読みました

サイコロジーって言葉、ちょっと怖くてキャッチーですよね。

日本語で言えば、心理学ってだけなんですが。

この本は、いい本です。( ˊᵕˋ )

お金持ちになる方法よりも、お金をめぐる考え方についての本、という意味でとっても面白かったです。

一瞬話はそれますが、ちょっと前まで言われていた

「若者のブランドもの離れ」

とか、最近あんまり当てはまらないなって感じてます。

今の20台前半ぐらいの若い人ってブランド結構好きって人増えてるよね。

なんの裏付けもありませんが、Youtuberとかがブランドものを一杯身に着けたりしているせいですかね。

で、この本曰く、

「ブランドものとかで身を固めている人はお金持ちではない」

という話です。

「お金を使っている人はお金持ちではない。」

ま、考えてみれば当たり前ですよね(笑)。

2000万円の時計を持っている人は、その人の現金の保有資産が2000万円減っているからです。

お金が減っているんです。

金持ちになるにはお金を使ってはいけないのです。

「は?そんな当たり前のことでしょ?そんなことを知るために、本を読みたくないよ!」

と思うかもしれません。

待ってください!

他にも、めっちゃいいことが書いてありますから~!!(By 波田陽区)

私なりに、読んでよかったなと思うところを抜粋しておきます。

 

①誰もが0.00000001%の世界で生きている

あなたの個人的な経験が、あなたのお金に対する考え方の8割を形成している。

冒頭の私の「最近の若者はブランドが好きだねぇ」という話も、私の周りの若者のサンプルによるものなので、これがまさにそうですね(笑)。

「人はお金を扱うときにおかしなことをするが、おかしな人は誰もいない。」らしいです。

②成功と失敗には運とリスクが強く影響している

優秀だから成功した、怠惰だから失敗した、というよりもこの世界は運要素が強いという話。

③この世界では、前例のないことが常に起きている

コロナとかもそうだったもんね…。日本では、地震・津波とかもありますし。

「歴史の終わり錯覚」というのがあるらしいです。

今の自分が、何十年後も変わらない価値観でいる、と思うことらしいです。

例えば、弁護士を夢見る10代の少年がいます。猛勉強して弁護士になります。

いざ弁護士になると、長時間労働に追われ、家族と一緒に過ごす暇もありません。そこで彼は、年収は低いが時間の融通が利く仕事に転職します。

だがその後、子どもを保育園に預けるには思った以上にお金がかかり、給料のほとんどが消えてしまうことに気づきます。

そこで彼は、配偶者の収入で生計を立て、自分は仕事を辞めて家で子育てに専念しようと決断します。

彼は「これでようやく正しい選択ができた」そう思います。

しかし70歳になったとき、働かなかったために、老後資金に余裕がないことに気づく…。みたいな話です。

結局、あんまり極端な選択は止めようね、という結論です。

④人間には知らないことを軽視し、知っていることばかりを注目してしまう癖がある

スタートアップ企業が成功するかどうかはその会社がどれぐらい努力するかと同じぐらい、競合他社の業績や市場の変化に左右される、らしいです。

⑤富を築くためには収入や投資リターンより、貯蓄が大事

傲慢にならないこと。富を築くために必要なのは自制心。

⑥お金よりも、人生を自分でコントロールしている人が幸せ

これねー。私、激しく同意します。

1000人の高齢者に聞いたアンケート結果では

・裕福になるために仕事を選ぶべきではない
・欲しい物を買うために仕事につくのはよくない

だそうです。

⑦うまくいかないことがあっても問題ないと考える

99%の事業で失敗しても、1%で成功すればよい。一つの成功のためにいくつもの失敗があるのです。

 

ところで、私はこういう洋書に出てくる小ネタが結構好きなんですよね。

日本のビジネス書って、あんまり小ネタが出てこないんですけど、洋書のビジネス本って小ネタの宝庫ですよね。

今回の小ネタで一番好きなのはナポレオンの名言

「天才とは、周りの者が正気を失っているときに普通のことができる者」

だそうです。( ˊᵕˋ )

ThoughtWorksアンソロジーという本を読みました。

 

この本、中古でなんと5900円もしたんですが、買って会社に持っていったら

M君「え??この本また買ったんですか??」

と言われまして…。 なんと2冊目を買ってしまったらしい(笑)

まぁ、詳しく話すと私が処分しようとしていたところを勉強熱心なM君が自宅に引き取ってくれたのを忘れていたといういきさつでした。

まぁ、古い本なんですけれども。

まだ2023年に通じるところはいっぱいあります。

 

1章 ビジネスソフトウェアの「ラストマイル」を解決する

 

プログラマーの皆さんは感じたことがありませんか?プログラムが出来上がってからが…長いと…!!

正確に言うと、98%ぐらいできてからが、その先の2%ぐらいにめちゃ時間がかかるんですよ。

Windowsの検索みたいだねっ!!

これは、他のお仕事とはだいぶ違うところで、ソフトウェアを作らない方にはなかなかわからない部分だと思います。

なぜかというと、ある程度できてからしかわからないことが多すぎるからです。

それを、ここでは「ラストマイル」と表現しています。

本書からの抜粋ですが

「ラストマイルで実施されるテストでは、システムのレスポンスタイム、トランザクションのスループット、可用性、セキュリティという

非機能要求が満たされているかを確認することに、多くの時間が費やされます。そして、それをテストできるのはソフトウェアが完成した後なのです。」

そう。そうなんですよ。

アプローチとしては本書曰く

「『システムのレスポンスタイムは5秒以下にする』、という決め方だとソフトウェアが完成してからしかテストできないが、

『ディスクへのランダムアクセスを1秒間に2500回以下にする必要がある』という決め方ならソフトウェアの作成段階でテストできるし、カウンタ機能をつくれば自動テストに組み込むことができる」

という話です。確かに!!

5章 オブジェクト指向エクササイズ

 

ソフトウェア設計を改善するために次の9つのことをやってみよう!という話です。

1.1つのメソッドにつき、インデントは1段階までにする

2.  else句を使用しないこと

3.  すべてのプリミティブ型と文字列型をラップすること

int とかは何の意味も持たない。時間とかなら、時間型しか渡せないので、ずっと保守性が高まる。

4. 1行につき、ドットは1つまでにすること

5. 名前を省略しないこと

6.すべてのエンティティを小さくすること

50行を超えるクラス、10ファイルを超えるパッケージは作らないこと

7.1つのクラスにつきインスタンス変数は2つまでにすること

クラスには2つ種類があんねん!とアンミカさんが言いました。

それは1つのインスタンス変数の状態を管理するクラス、2つの独立した変数を調整するクラスです。

ほう。

そして、それを混ぜてはいけません。

なるほど。。。

8.ファーストクラスコレクションを使用すること

実はですね!この本の、この部分だけを読みたくて、この本を買いました!!!

最近仕事で、コレクションをどうクラス設計すればいいか悩むことが多くあったので、ファーストクラスコレクションについて、詳しく知りたかったからです。

実際のところ、12行しか書かれていませんでした(笑)

大事なことは

・他のメンバ変数を持たせないようにする

・フィルタとか作ってもいいかもね。

・2つのグループの結合やグループの各要素に対するルールの適用なども扱ってもいいかもね

・コレクションはただのプリミティブな型の一種に過ぎないので、独自のクラスにラップする意味はある

12行だけでしたが、きっと三蔵法師がインドで仏典を手に入れたときぐらい満足できました。⊂(^-^)⊃

9. Getter, Setter, プロパティを使用しないこと

エッ

「求めるな、命じよ」

だそうです。

「求めるな、命じよ」については、下記の解説がわかりやすかったので、こちらを見てみて下さい。

https://zenn.dev/miya_tech/articles/2289a177cdf2ff


 

<これらのルールを見て思ったこと>

オブジェクト指向的に考えるのが難しい理由って、プログラムを書く時の思考はどうしてもオブジェクト指向と反対から始まることが多いからじゃないかと思ってます。

プログラミングの入り口は

「あるデータがあって、それをAという場合はBに、Cという場合はDに」

みたいに始まることが多いんですよね。そしてそれが膨れ上がっていくのが大体のプロセスだと思います。

そうすると、上のルールを守ることはまったくできません。

オブジェクト指向的な発想は反対側からなんですよね。

「あるデータとは何なのか。どういう役割なのか。構造はどうなっているのか。」

を決めることから始めないとなんですよね。

最近、プログラミングとは概念を構造的に伝える手段なんじゃないかと思います。

 

ところで、この本を中古で買ったんですが、めっちゃ線が入っていて、この本を持っていた人は大変な勉強家だったんだな!と思います。

なんかそういう本っていいですよね( ˊᵕˋ )

 

 

PHPerKaigi2023に行ってきた

今日はPHPerKaigi2023を現地に行って聞いてきました!

いつも私はこういうブログは1週間ぐらい経ってからしか書かないんですが(笑)

今日はモチベが高いので、今日中に書きます!(`・ω・´) 眠いけど…。

さてさて、木曜日から会社で業務の合間にオンラインで見てました。

見たセッションと、その感想をちゃちゃっと書いておきます。


木曜日

技術負債とプロジェクトと私たち

 

発表者さんのWeddingParkでは技術的負債をなんとかするために

①テストコードの導入
②カバレッジの目標を設定
→目標達成に追われないカバレッジ値の設定が必要だった

されたそうです。

そう。テストを作らねば。
なんですが、テストを作るのが面倒 (´ω`)
最初のうちは、意識高くカバーしていても、切羽詰まってくると
「この辺、そのうちリファクタするかもしれんし」
という言い訳などで、テストコードを書かない部分が増えてくる。

これはマジの技術的負債ですね!
なんとか、これを防がないといけないな…。

発表をしていたWeddingParkさんでは、テストコードを書きやすいように環境を整えたり、コード自体を書き直しされたそうです。
弊社も、環境はあるんだけどね…。

PHPUnit 10 概論

PHPUnit10で新しくなることで、印象に残ったのは下記のことです。

・テストイベントが新しくなるらしい。
・テストの結果とテスト自体の問題を区別するようになった。
いくつかのテストの結果やテスト自体の問題では、発生してもテストを中止しなくなった。

DataProviderという機能が紹介されてたんですが、これについて私は知らなかったので、勉強になりました。( ˊᵕˋ )


金曜日

見たいセッションあったんですが、業務多忙につき、一個もみれなかった。(>_<)


土曜日

練馬に行きました!

計測できるレガシーさを捉え、コード改善に対処する

 

途中からしか見れなかった(>_<)。

「レガシーコードだねぇ、おじいさんや。」

「そうだねえ、おばあさんや。」

と言ってるだけじゃなくって、ツールを使ってそのレガシーさを測るべしという話(だと思った。)

とにかくたくさんのlintが紹介されてました。

知らなかったツール→phpmd、Rector、PHP CS Fixer

PHPの配列の内部実装について学びたくなった。

 

そうなんだ~!ということばっかりでした。スクショいっぱい撮った。

JavaだとArrayListとかLinketListとかHashMapとかあるけど、PHPは配列だもんね。

なので、詳しくは上記のリンクにあるスライドを見ていただくのが一番いいかも。

成瀬の挑戦状

 

このセッションの10分ぐらい前に「ドメイン駆動設計入門」という本を読みましたという投稿で紹介した本を書かれた成瀬 允宣さんに直接お会いできて、色々話せたので嬉しかったです!( ˊᵕˋ )

で、その時に挑戦状を頂きましたが、まったくわからず

「?」

となってた私は本当にです。(´ω`)

クジラのこと、Dockerにつながってなくってw Twitterが落ちてる時に出てくるクジラかな?って思ってましたから(笑)

いやー、皆さん本当に頭がいいな~ それとも、競技プログラミングとか(?)こういうことに慣れてればすぐできるものなのかな。

シーザー暗号、とか初めて聞く言葉がいっぱいありまして、なんかいつも接していない分野のことが知れて面白かったです。

問題をもっと前に知っていればよかったな。

人生、宇宙、すべての答えは42らしい(笑)。成瀬さんの博学さに脱帽ですね!

プログラマーってSF好き多いですよね。

成瀬さんと!

PHPerチャレンジ解説セッション

 

こちらも、問題を解く系のセッションでした。最近ではカンファレンスでこういうのやるんだ~ ってなってました。

これも、事前に問題を知っていればもっと前のめりに聞けたかもしれないですが、問題を知らないので、ちょっとぼんやり聞いてました…。

しかし

「PHPのVMを書き換えてevalの動作を変えてしまう」

とか言っていて「マ?」って思ってました…。

「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」

って言葉を初めて知りました。


そして、懇親会!

懇親会が一番楽しかったです。( ˊᵕˋ ) 200人ぐらい参加されてたのかな?

元々、知らない人と話すのが好きなのですが、コロナからはそういう機会がめっちゃ減ってしまって、特にプログラマーさんと話す機会が減ってしまったので、久しぶりでした。

PHPだけじゃない、いろんな言語の話を聞いたり、他社さんの仕事の話を聞いたりするのは勉強になります。

ただ、私今回一人で行ったんですが、こういう飲み会の場で最初一人なののアウェイ感がつらい(笑)

(本当は弊社のK君が来るはずだったんだけど、急遽体調不良でオンライン視聴でした。弊社のほかの人もオンラインで見てたと思う。みんな横浜ずみだからね。)

 

現地に行く一番の収穫は、自分のモチベーションが上がるということだと思います。

PHPerKaigiって有料なんですよ。

会社から経費が出る方もいるかもしれませんが、自腹で来ている人もいるはずで、土曜日にお金出してこういうところに来る人って、意識がめちゃ高いですよね。

そういう人たちの勉強したい、プログラミングが好き、という純粋な気持ちが感じられて、自分の気持ちがアガるのが好きです。

また、すごいと思える人にいっぱい会えると自分が「井の中の蛙」だなって、まだまだがんばらないといけないなと思わせてくれます。( ˊᵕˋ )

 

ハイパワーマーケティングという本を読みました

この本は、私が好きなYoutuberのまこなり社長が紹介していたので読みました。

結果、読んでよかったです。

どうやったらお客様のためになるのか。

それをいつも考えているはずなのに、日々の業務に追われていると、時々忘れかけてしまいます。

お客様のためになることを考える。それが一番大切なことだと改めて気づかせてくれるのが本書の一番いいところですね。

各論でいいなという気づきは、次の点がありました。

 

①お客様が製品を試すときに、なんのリスクもないことを強調する。

→弊社も2週間お試し、というのをやってますが、確かにお客様からすると

「ん?何か契約させられるのでは?」

と思ってしまうかもしれませんね。

実際、なんのリスクもないです。これをもっとわかりやすくしないといけないですね。

弊社の販売しているODIN リアルタイム配送システムでは、申し込みなしでお試しができるんですよ。

これは、ビジネス用のソフトとしては非常に珍しいと思います。

他の会社さんは、まずは営業マンと話をしないとお試しができないのです。

私は、私がお客さんだったらまず試してみたい、と思いましたので、すぐに無料お試しができるシステムを用意しています。

競合他社さんがまずは営業マンと話さないとお試しができないようにしている理由もわかります。

まずは、お試しのシステムを作ることが面倒だし費用がかかる。

次に、競合の調査などで使われる可能性が高い、です。

弊社ではこのリスクを取ってます。

 

②会社の誰もがUSPを語れるようになる 

USPというのは端的に言うと「自社の強み」ということです。
USPを統一して発信する、特に営業部のメンバーが、これを全員語れるようにならないといけない、ということでした。
これは間違いなくやったほうがいいですね。(´ω`)
—————————————————————————————————————–
そのほか、私が印象的だったフレーズは

「レストランを始めるとしたら何がほしい?」

と著者さんが聞いたところ

「いいシェフ」とか「きれいなレストラン」「立地」

と答える人はいたそうですが、

「私はおなかをすかせた人がほしい」

というのが著者の答えだったそうです。

マーケティングの真髄ですよね。

 

ちょっと日本語訳が読みづらいところもありましたが、おススメです!

 

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

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

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

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

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

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

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

【配送指示の導入】

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

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

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

【小口配送の導入】

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

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

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

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

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

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

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

【その他】

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


ここからはウラ話です。

いやー、これですね…。

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

 

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

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

 

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

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

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

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

 

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

 

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

・歩いているのか

・じっとしているのか

・走っているのか

・乗車中か

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

 

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

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

 

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

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

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

 

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

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


面白かったですね!

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

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

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

「俺は俺が大好き」

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

「は?」

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

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

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

「自信満々なイヤな奴」

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

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

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

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