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

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

今日は3連休の中日でしたが、蒲田で行われたPHPカンファレンスに行ってきました！

実は…。

ここ最近、PHPしか書いてない！！！

ぐらいPHPにどっぷりつかっている私です。(`･ω･´)

（プルリクはJavaとかjsとか見ますが）

何をやってるかというと、先日書いたように、弊社のお客様が3000社を突破したんですよ！！！

ありがたいことなんですが、エンジニアの方ならよくわかっていただけると思うんですが、お客様が増えると…

・トラフィックが増える

・データが増える

・想定されていなかった使い方をされるお客様もいっぱい出てくる

という技術面の問題に直面しています。(´ω`)

そして、めちゃくちゃソフトウェアアップデートをしてるんですよ。機能がめっちゃ増えてます。

複雑性というのが増えてます。

少ない人数で素早いリリース、素早い不具合対応、スケールの問題に対処するかのヒントを得るために、こういう機会は私にとって重要です。(`･ω･´)

昼過ぎから行きましたので、下記のセッションから見ました。

下記には私的なメモだけ書いておきます。

後日スライドなどが公開されると思います。（内容が間違ってたら申し訳ないです。）

Webアプリケーションのパフォーマンス・チューニングの勘所

https://fortee.jp/phpcon-2023/proposal/9dd2a5e3-5a3d-4d3b-b39f-0fb3e17bbd15

曽根 壮大さんという方のお話ですが、この方の話は以前も聞いたことがあって、とてもためになりました。

・Cloud watch log insightsが便利

・サーバーの状態を調べるのに、最初にOSのメトリクスを見るのがよい（CPU使用率とか）
病気の検査で体重を測るのと同じようなもの。

・デッドロックが頻発すると、CPU使用率が上がる

・デッドロックを完全になくすのは難しい。逆にタイムアウトを短くして、アプリでリトライするのがよいと思う。

・キャッシュは使わなくて済むなら使わないほうが良い
壊れたときに不具合対応が難しいから

・キャッシュは必ず一次データから取り出すべし

☆目の前のコードを直すことができるのは自分たちだけ　という言葉が印象的でした。☆

スケーラブルサービス――疎結合に成長するシステムに不可欠な要素

https://fortee.jp/phpcon-2023/proposal/d81f49cf-009c-4953-af24-1582a827edef

成瀬 允宣さんという方のお話で、3月にもPHPerKaigiでこの方のセッションを聞いてとてもためになったので聞きました。

・サービスをスケールさせるのは、ソフトウェアをメッセージ駆動にするのがよい

・メッセージキューはありものを使ったほうがよい。Kafkaの名前が挙がってました。

・ただ、メッセージキューは使うのが難しい。順序保証やトランザクションの話が上がってました。

・イベントソーシングにする。ステートソーシングとは違う概念。
成瀬さんが、イベントソーシングにすると、よりオブジェクトの状態にあう、という話をされていたのが印象的でした。
インピーダンスミスマッチを解決できるのではないかという話でした。

はは~。インピーダンスミスマッチという言葉を私はこの日初めて知ったんですが、なるほど！と腑に落ちましたね。
インピーダンスミスマッチとはDBの中身は、ある日ある時の状態（ステート）なんだけど、コード上のオブジェクトは「なう」な状態を扱っていることが多いのでミスマッチになっていくという話みたいです。

イベントの方がオブジェクトのプロパティなどに近いので、このインピーダンスミスマッチを解決できるという話。

・イベントを記録しておく。そうすると、イベントのリプレイが可能
なんとDBを消すことさえできる。イベントをリプレイすれば戻せるわけなので！

・イベントの設計図を作る

・LaravelでもKafka使えるよ！しかし、Javaとかで使ったほうがいいです…。

実は今、私イベント駆動でちょうどイベントの設計を作ったりしているところなのでジャストにためになりました！！(｀・∀・)ﾉ

成瀬さんに後でその感動を伝えたところ、前にお会いしたことを覚えてくれて
「あ、後藤さんですよね？」
って名前を覚えて頂いていたので感動しました！°(´ฅωฅ`)°｡　成瀬さんは芸能人みたいな方ですね！( ˊᵕˋ )

安全にPHPでWebアプリ開発するために実践していること

篠田 北斗さんという方のお話でした。

いかにうまくPHPのソフトウェアを開発・メンテナンス・運用していくかということで実践的なお話ばかりでためになりました。

・readonly 使ってこ。（個人的な話ですが、使うの忘れちゃうんで！）

・MTTRの短縮化を目指す

・エラートラッキングツールとチャットツールを連携させる。ここではSentryの名前が挙がってました。
オオカミ少年にならないように毅然とした態度をとる。

→この話、どうしたらオオカミ少年にならないのか、毅然とした態度とは何なのか、懇親会で篠田さんに直接聞いちゃいました！
ウチでも、同じような構成（Sentry＋Slack）でオオカミ少年化しているところが結構あるので…。(´ω`)
「Sentryでignoreするエラーを選べるのでそれでミュートすべし」
「Slackでエラーが来たらちゃんとつぶしていく」
おおー。教えて頂いてありがとうございました！┌o　ﾍﾟｺｯ

・ノートラブルシステムへの道　というスライドがよいので見る。
→見ました。https://speakerdeck.com/yamaz/notoraburusisutemuhenodao?slide=25
確かにいい話です。「機能追加がなくても、売れればシステムは傷み始める」というのがまさしくその通りだなと。

その後は、ちょっと休憩してて、LTを一通り見ました。

PHPInsightsで技術的負債の可視化始めました

・Gitで直近1年間のファイル別変更回数を出す。その後、循環的複雑度を出す。
変更回数 × 循環的複雑度 = ソフトウェア保守のコスト

うわああああ　確かに！！

入社半年を迎える新米エンジニアがカンファレンス・勉強会から得た学び〜半年後の自分に伝えたいこと〜

・知らないことは調べようがない

単純だけど、真実だな！って思います。

ネットだけで調べものしていると、「知らないことに遭遇できない」ということがよくあると思います。

なんと、今回900人ぐらいの人が参加したそうです！

大盛況ですね。

各地でPHP Conferenceが行われるらしいです。

その後、懇親会で多くの方とお話させて頂きました。

どんなプログラムを書いているかとか、今注目している技術とか、組織がかかえる問題とか、その方のキャリアとか、よもやまテックなことだけじゃないお話ができて楽しかった~　o(>▽<)o

Github Copilot導入しようか迷ってたんですが、結構導入しているとか、便利だよって話をお聞きして、ウチでも使って行こうと思いました！

皆さま有難うございました！！！

PHPカンファレンス

なんとなんと！

弊社のODIN リアルタイム配送システムの導入企業数が

3000社

を超えました！！！

パチパチパチパチ。

有難うございます！！！！！！！

配送業向けに11年やってますからね。

配送の進捗が一目でわかる

久しぶりに、口コミサイトのITトレンドを見てみました。

ITトレンド口コミでNo1

カテゴリー満足度ランキング、相変わらずの1位です！！(`･ω･´)

おすすめ度・機能への満足度・使いやすさ・サポート品質・価格

どれもバランスが取れている、というご評価です！⊂(^-^)⊃

口コミを一つご紹介させていただきます。

口コミを書いてくださった方

送迎業務の送迎計画策定と動態管理のコスト面からの乗り換え

他の口コミなどは、下記からご覧頂けます。
https://it-trend.jp/logistics-system/12280/review#tab_all

お問い合わせはぜひ、コチラまで！

今日は、弊社の創立記念日でした！

2006年に創業したので、なんと17周年で、18年目に突入します！

日ごろご愛顧いただいているお客様、パートナー企業の皆様、そして何より、がんばっているスタッフのみんなのおかげです。

ありがとうございます。

18歳ともいえばもう大人ですね…。(´ω`)

感慨深い。

さっき、なんとなく会社のホワイトボードにイラストを落書きしていたら、S君が

「後藤さん。消しておきますよ。」

と言ってさっと消されました（笑）。

昔は、ホワイトボードの落書きとか放置してたのにな…。そこに落書きを重ねてくれたりとかしてたのにな…。

と一抹の寂しさを感じました。

でも、少し大きな会社になったということですね( ˊᵕˋ )

まぁ、まだやんちゃなところが残っている会社だとは思いますが。

あああー！！今日、空の写真を撮り忘れちゃったー！！！(>_<)

今日は、少し曇りでしたが、晴天だったと思います。

毎年、この日は晴なんですよ。

去年の今日は、何を言っていたかというと、下記のようなことを言ってました。

https://summer-snow.onlineconsultant.jp/2022/10/02/%e5%89%b5%e7%ab%8b%e8%a8%98%e5%bf%b5%e6%97%a5%e3%81%a7%e3%81%99%e3%80%8217%e5%b9%b4%e7%9b%ae%e3%81%ab%e3%81%aa%e3%82%8a%e3%81%be%e3%81%97%e3%81%9f%ef%bc%81/

毎日、青空のようにスカッと生きていく。

それを志していきたいです。

仕事では、2024年問題が巷で話題です。

弊社も、日本の運送・配送の問題を解決していくのに必死です。

もっと、いい製品にして、皆様の問題を解決していくことができたらいいな、と日々思います。

今回、空の写真がないので2006年のころの写真ないかな？って探してみました。

→なかった。

なので、2008年にやったセミナーの写真と仕事してた時の写真があったので、貼っておきます。

変な服（笑）眉毛ほそっ（笑）

2008年当時は、マンションの一室で、3人で仕事してたんですね~。懐かしいな。

モニターに時代を感じる

T氏も若かった（笑）

T中氏

さっきも話したように、落書きは消されてしまうけれども。

創業当初の挑戦者魂とか、ウチの会社を「日本のGoogleにする」という夢は捨てていません！(`･ω･´)

あんまし私、昔を思い出して、昔はよかったなって思わないんですよ。

今が一番楽しいし、幸せです！

去年に会社のイベントでプレジャーフォレストへ行った時。

それが一番幸せもんな話ですよね。( ˊᵕˋ )

本当に、会社のスタッフの皆さん、お客様、パートナー様、友達、周りの皆様のおかげだな、と毎日感謝しています。

重ねてありがとうございます！！！(/□≦､)ｴｰﾝ!!

これからも、オンラインコンサルタントと、従業員一同ともどもよろしくお願いいたします。