幡ヶ谷亭直吉ブログ

のらりくらりとしていたい人です。娘のここねと格闘するエンジニア。

Tidy First? を読んで 〜 必要を感じた際の整頓について

読書メモ。2025年２冊目。
『Tidy First?―個人で実践する経験主義的ソフトウェア設計』を読んでの感想となります。（2025/1/4記載）

本の概要

乱雑なコードは厄介です。コードを読みやすくするには、管理できる小さなまとまりに分割する必要があります。本書は、エクストリームプログラミングの考案者で、ソフトウェアパターンの先駆者であるケント・ベックが、システム全体の構造を念頭に置き、コードを改善するには、いつどこで整頓するのがよいかを解説します。
整頓のしかたを一気に習得するのではなく、整頓を少しずつ試しながら自身の課題解決につなげます。コード行数の多い大きな関数については論理的にコードを小さなチャンクに分割する方法を学び、その過程で、結合、凝集、ソフトウェアシステムの経済的価値（ディスカウントキャッシュフローやオプショナリティ）などソフトウェア設計の背後にある重要な要素を解説します。
また、ソフトウェア設計の基礎理論とそれに作用するフォース、システムにおけるふるまいの変更と構造の変更の違い、先に整頓したりあとに整頓することによるプログラミング体験の向上、大きな変更を小さく安全な手順で始める方法、ソフトウェア設計を人間関係のエクササイズとしてとらえることなどを学びます。

引用：

www.oreilly.co.jp

å‹•æ©Ÿ

・一にも二にもケント・ベックの新刊。

感想

構造の変更と振る舞いの変更について解像度を上げて分離した意識ができました。
構造の変更については、つい「今はそのタイミングじゃない」に逃げがち（またはそれを許容しがち）ですが、
レベル感を意識した判断は重要で、「今後も触ることが見えてる機能なら今触る部分は軽くやっちゃおうよ」と言える空気は持っていたい。

第１部で紹介のある整頓は、＝リーダブルコード化といった印象を受けました。

www.oreilly.co.jp

10年ぐらい前に当初が発売された頃は、
自分がテックリードとしてほぼ一人でスマホアプリのバックエンド担当をしており、
開発のたびに随時整頓を繰り返していた記憶があります。

時が流れて、より価値のある開発の加速化が求められる現在、
「どれくらい？」「いつ？」を意識して整頓を行う必要があることを実感しました。
鵜吞みしてきたものに対する解体が必要なことに気付きます。

書き留めたメモ

  • ソフトウェア設計について
    ソフトウェア設計の他の記述では「どれくらい？」と「いつ？」が抜けている。
    まるで時間の制約が何もないところで設計しているかのように見えた。

    この文章を読むまで意図できていなかったことに気付きました。

  • 凝集について
    整頓により凝集度を高めれば、振る舞いの変更が容易になる。
    凝集度を高めることで、結合が受容できるようになる。

    必ずしも分離だけが正解ではない。

  • ひとかたまり
    コードの最大のコストは、コードを書くことではく、読んで理解すること。
    先に整頓することは、結合を減らし、凝集を高め、認知負荷を減らす。

    自宅の作業部屋のいつも見えるところに貼っておきたい内容。

  • 分けて整頓する
    レビュー速度もインセンティブになる。
    すばやいレビューは、多くの小さなプルリクエストを生む。
    焦点を絞ったブルリクエストは、レビュー速度をあげる。
    遅いレビューは大きなプルリクエストを生み、レビューがさらに遅くなる。

    チームの作業スペースのいつも見えるところに貼っておきたい内容。

  • バッチサイズについて
    次の振る舞いの変更をサポートするために必要な分の整頓を行う。
    はるか先の未来のためには行わない。

    自分がフルでプログラミングに従事できていたころは、気になったときに気になった分だけ行っていたことを思い出し反省。

  • 可逆的な構造変更について
    構造の変更は一般的に可逆的。
    簡単に戻せるので、間違いを避けるために多くを投資すべきではない。
        
    振る舞いの変更は不可逆。
    決定に大きなメリットがある場合でも、潜在的には間違ったときに大きなデメリットがある。
    そのため、可逆な範囲までレビュー、チェックなどを通し慎重にアプローチをする。

    ここまでの解像度を持ったアプローチに対する意識ができていませんでした。
    構造の変更についての意識は個人だけでなく全体で持っていたい。

まとめ

自分自身、プログラミングから少し離れてしまっているものの、
離れているからこそ、改めてこうした直接目に見える形では現れなくても、
開発を進める上で価値ある取り組みを意識していたいと思いました。

昨年の開発生産性カンファレンスでのミノ駆動さんのセッションも思い出しました。
合わせて意識していたい。

speakerdeck.com

今回の本はシリーズものらしく、次刊は「チームのプログラマー同士の関係を癒し、もっと大きな問題に言及する」とのこと。楽しみ。
『エクストリーム・プログラミング』を読んだのも10年ぐらい前なのでそろそろ読み直したい。

エンジニアのためのマネジメントキャリアパス を読んで 〜 偏見を剥がしエゴを飛ばす

読書メモ。2025年１冊目。
『エンジニアのためのマネジメントキャリアパス』を読んでの感想となります。（2025/1/2記載）

本の概要

本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT業界の管理職に求められるスキルを解説する書籍です。テックリードからCTOになった経験を持つ著者が、管理職についたエンジニアが歩むキャリアパスについて段階をおって紹介します。インターンのメンターから始まり、テックリード、チームをまとめるエンジニアリングリード、複数のチームを管理する技術部長、経営にかかわるCTOやVPと立場が変わることによって求められる役割について、それぞれの職務を定義しながらくわしく説明します。
さらに管理職の採用や評価、機能不全に陥ったチームの立て直し、管理職についてからの技術力の維持など、様々なハードルを乗り越えるための考え方やテクニックを多数紹介。技術系管理職の全体を視野に入れ、各段階で必要なスキルを学ぶ本書は、マネジメントのキャリアを志すエンジニア必携の一冊です。

引用：

www.oreilly.co.jp

å‹•æ©Ÿ

・『ソフトウェア・ファースト』での及川卓也さんの大絶賛で気になったのが発端。
・年齢重ねるごとに開発のリード、マネジメントを担当することが増えてるけど、自分でも役割を明瞭化した把握ができていない。
・今後エンジニアリング・マネジメントにおいて安定した活躍をしたい。

書き留めたメモ

  • 1on1について
    人間的なつながりを作るために行う。
    現状確認のための会議とせず、検討が必要な内容を話し合う定期的な場とする。

    これは気を付けていることのひとつ。
    昔、自分がしていただく側として、完全に儀式としてだけ開かれる1on1があって、あれは意味がなかった…

  • フィードバックについて
    フィードバックは、定期的なタイミングを待たず行うべき。
    自身で気付けない悪い習慣や失敗に対するフィードバックを行う。
    基本的に、褒めることは人前で行い、叱ることは1対1で行う。

    忘れてはいけないこと。何度でも自分に補正をかける。

  • テックリードについて
    エンジニアとしての実力だけじゃなく、コミュニケーション、優先順位の判断、プロジェクトに対する熱意などリーダーシップが求められる。
    「技術面での貢献」と「チーム全体のニーズへの対応」のバランスが求められる。

    ひとりが長期にわたってつく職位ではなく、チームの変化や進化に応じてさまざまな階級のエンジニアが引き受けられる属人化しない役割とする。

    昔、ウォーターフォール型の新規開発案件では、アプリケーションアーキテクチャを決定するアーキテクトという役割があって、テックリードに対して、ずっとそのイメージでいましたが、誤解していました。
    アーキは進化をし続けるし、設計は属人化すべきではない。

  • 人の管理について
    管理者はメンバーひとりひとりに多大な影響を及ぼす。
    直属の部下との関係の構築、定期的な1on1、フィードバック、各メンバーの成長に対する牽引を行う。
    優れたリーダーは任せ上手。放任ではなく委任を行う。

    ともすれば自分が何をしたらいいのか分からず、放任になりがちなので気を付けたい。

  • チームの管理について
    メンバーの意思決定がチーム全体や会社全体といった広範なコンテクストとの間でバランスが取れたものであることを確認する。
    すべての認知負荷の要因からチームを守るのではなく、対象に追ってはチームを巻き込みコンテクストに対する理解を促進する。
    コンテクストの把握は、チームが適切な判断を下すのに役立つ。
    管理者に与えられているのは自ら決定を下す権限ではなく、チームによる意思決定を主導する権限。

    チームの管理、ではなく、チーム成長の促進と捉えないといけない。

  • 複数チームの管理について
    評価される側が評価に影響する悪い情報を自ら話しに来ることを期待してはいけない。
    1on1やチームとのランチを行い、課題のヒアリングを継続する。
    マネジメントは文化に根差した仕事であり、自組織の文化を育む責任を負っている。

    今自分は２つの開発チームに所属する10名程度のメンバーと1on1をしているけど、おそらく15人ぐらいになると大変になる想定。
    そうなった場合にどう推進していくか。

  • すごい上司について
    話し合いに自分自身のエゴを持ち込まず意見の相違や争いを解決する名人。

    毎日の娘との悪戦苦闘で反省し続けているやつ。

まとめ

今自分自身が該当するのは６章に少し足がかかっているぐらい。
そのうえで、最後まで学びとなる１冊でした。
特にテックリードに対しては誤解もあったため、改めて整理ができました。

ブリリアントジャークについては、懐かしさがありました。
個人的に今までそうした類の人との案件で育てられた部分も大きいと思っており、
いかに一緒に共通の目的に向かって動けるかだと思っている部分があります。

昭和生まれのウォーターフォール育ちの因果か、マネージャーに対して剛腕トップダウンのイメージが染みついてしまっているけど、少しずつでも剥がしていかないといけないなと思っています。
そして、最後のすごい上司の記載に、最近反省しまくっている色々が含まれていました。
エゴに流されないためには、オーナーシップを持てる目的と健康な生活が大事。

自分の立場が変わるタイミングで読み返したい１冊でした。

備考

ここでの及川さんのお話も好きでした。

open.spotify.com

2024年に参加した技術イベント／カンファレンス

今年は多くのイベントやカンファレンスに参加しました。
オンラインでフリーのものを含めたら毎週何かのイベントに参加していました。

オフラインのカンファレンスは今年が初めてでしたが、充実すぎて可能な範囲で参加しまくりました。
セッションの内容だけじゃなく、エンジニアの文化的な部分で学びになった一年でした。

平日開催のものは炎上案件で参加を断念したものも多くあったため、来年は思う存分堪能したい。

オンラインでフリーのものを除いた履歴を残しておきます。

3/24 Object-Oriented Conference 2024

ooc.dev


5/26 技術書典16

techbookfest.org

 
6/16 JJUG CCC 2024 Spring

ccc2024spring.java-users.jp

 

6/29 開発生産性Conference 2024

dev-productivity-con.findy-code.io


7/13 大吉祥寺.pm

kichijojipm.connpass.com


9/21 ServerlessDays Tokyo 2024

tokyo.serverlessdays.io


10/13 Modern Infra & Apps Summit ’24

cloudonair.withgoogle.com

 

10/22 開発健全性ミートアップ ~ GitHub × Postman × Atlassian ~

postman.connpass.com

 

10/27 JJUG CCC 2024 Fall

ccc2024fall.java-users.jp


11/03 技術書典17

techbookfest.org


11/06 Microsoft Developer Day

microsoft-events.connpass.com


11/14 Developers X Summit

event.shoeisha.jp


11/26 アーキテクチャConference

architecture-con.findy-tools.io

hiliteeternal.hatenablog.com


11/27 スタートアップのQA集合！リアルな困りごとを語り合おう！

loglass-tech.connpass.com

hiliteeternal.hatenablog.com

 


11/30 PRODUCT HISTORY CONFERENCE 2024

lp-a.youtrust.jp

hiliteeternal.hatenablog.com


12/05,6 pmconf2024

2024.pmconf.jp

hiliteeternal.hatenablog.com

hiliteeternal.hatenablog.com


12/07 Developers CAREER Boost 2024

event.shoeisha.jp

hiliteeternal.hatenablog.com

 

12/14 Backlog World 2024 in Yokohama

jbuginfo.backlog.com

hiliteeternal.hatenablog.com

 

12/20 JaSST'24 Tokai

www.jasst.jp

hiliteeternal.hatenablog.com

 

12/22 PHPカンファレンス2024

phpcon.php.gr.jp

hiliteeternal.hatenablog.com

2024年読んだ本ベスト10

2024年は合計74冊の本を読みました。
去年まで大量に漫画をレンタルしていたTSUTAYAが閉店してしまい、
今年はビジネス本や技術書に比重が偏っています。

2024年に読んだ本ベスト10

2024年に読んだ本ベスト10です。１位から順に。

・及川卓也『ソフトウェアファースト第2版』

bookplus.nikkei.com

ソフトウェアを企業がオーナーシップを持って推進していくことの重要性について。
受託企業で育った身としては、刺さりまくります。
この文脈があるからこそ、
エンジニアリング組織論にしろチートポにしろt_wadaさんの講義にしろ深まる。

・宇田川元一『他者と働く』

publishing.newspicks.com

この１冊をもとに宇田川元一さんのファンになった１年でした。
いままで出ている３冊とも刺さるけど、何よりこの１冊が好きでした。

・馬田隆明『解像度を上げる』

解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と行動法eijipress.co.jp

個人的にものごとに対する理解が働くうえでも生活するうえでも重要と思っていて、
それをより立体的に整理できた一冊。馬田さんの本は来年もっと読みたい。

・マシュー・スケルトン/マニュエル・パイス『チームトポロジー』

pub.jmam.co.jp

案件での課題と重なり、チーム設計の重要性に気付かされた一冊。
開発チームの活動に対する外部アプローチを考える際はこの内容が主軸になっている。

・トム・デマルコ『ゆとりの法則』 

bookplus.nikkei.com

同案件のメンバーの推薦本。読後高稼働を後悔しまくった一冊。
30代前半でデマルコ本を読み漁った時期があり今回２度目だけど、実感通すと刺さり方が違う。

・エリック・シュミット/ジョナサン・ローゼンバーグ/アラン・イーグル『1兆ドルコーチ』

www.diamond.co.jp

リーディング、コーチングについて、ハウツーじゃなく理解できた１冊。
信頼を通したエンパワーメント。ここを目指していきたい。

・広木大地『エンジニアリング組織論への招待』

gihyo.jp

不確実性に向き合うことについて。恐らく時間をかけてもっと重要な１冊になる。
ソフトウェアファーストも、チートポも、限定合理性のような文脈から見るとより見え方が変わる。

・Nicole Forsgren Ph.D/Gene Kim/Jez Humble『LeanとDevOpsの科学』

book.impress.co.jp

変革的リーダーの５つの特製、ビジョン形成力、心に響くコミュニケーション能力、
知的刺激、支援的リーダーシップ、個人に対する評価。手にメモっておきたい。

・ウィル・ラーソン『エレガントパズル』

bookplus.nikkei.com

マネジメントとして複雑度の高いものを扱うことの重要性であったり、
無鉄砲な高稼働による課題解決の功罪であったり、持ち帰る部分が多い一冊でした。

・オワイス・ピア/ロナルド・カミングス・ジョン『LEADING QUALITY』

www.kadokawa.co.jp

品質・QAをより広義に捉えるきっかけとなった１冊。
今年12月のイベントでマークさんにご挨拶できたのも嬉しかったです。

その他感想

今年読んだ本の全量は以下Xのポストで管理をしています。

ふりかえってみて

本から得た知識に助けられている部分が多くあり、
逆にまだまだ知らないことは山ほどあり、
知っていた方がきっと楽にも楽しくもなるのだろうと思っています。
来年も楽しみ。

ちなみに、去年は確認したら47冊だったらしいです。
ビジネス書中心だったところから技術書に遷移してきています。

 

www.instagram.com

エンジニアリング組織論への招待 を読んで 〜 思考のリファクタをはじめる

『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』を読んでの感想となります。（2024/12/26記載）

本の概要

「コミュニケーションにおける不確実性を減らすには？」「技術的負債を解消する方法とは？」「経営陣とエンジニア間の認識のずれを解消するには？」
エンジニアリングにおける課題を解決する思考の整理方法やメンタリング手法を，さまざまな企業の技術組織アドバイザリーを務めている著者が解説。
若手を戦力として育て上げ，成長する組織を設計・運営するためにおすすめの1冊です。

引用：

gihyo.jp

å‹•æ©Ÿ

・今年色々なところでこの本の噂を聞き興味を持っている。

・最近EM.FMを聞き始め広木さんの考えをもっと知りたいと思っている。

・エンジニア組織のあるべき姿をもう少し立体的に捉えたい。

整理メモ

  • Chapter 1　思考のリファクタリング
     エンジニアリングとは何かを実現すること。
    実現するとは曖昧さ・不確実性を減らし、具体性・明確さを増やすこと。

    不確実性は未来と他人をもとに発生し、情報により低減する。
    組織における人間の不完全さは、情報の非対称性と限定合理性により加速する。

    事実を正しく認知し感情にとらわれず判断し、
    経験主義と仮説思考による問題の明瞭化を行い、
    システム思考を基に要素同士の関係に注目して問題の構造を解き明かすことで、
    健全な情報が生まれる。
  • Chapter 2　メンタリングの技術

    心理的な課題と技術的な課題は密接に関係する。
    エンジニアリングは不確実性を削減する工程であり、
    組織で実現するには人間の不完全さを削減することが重要。

    自立型人材を育てるには、上司部下間での期待値の調整が重要。
    自らの力で限定合理性の枠から抜けだし、知識を獲得することで、
    自己効力感が発生し、応用力が身につき、フィードバックループが生まれる。

    生産性に寄与する心理的安全性は、互いに対人リスクを取れる関係を築き、
    問題点の指摘、自身の弱みの開示、失敗の報告ができる状態で生まれる。

    ゴール認識には、願望、義務、欲求、意志、必然というレベルがある。
    意志の段階で初めて行動変化が生まれ、必然の段階で習慣が変化し始める。
    必然の段階になると、セルフマスタリーの状態が生まれる。

  • Chapter 3　アジャイルなチームの原理
    アジャイルな状態とは以下状態。これにより自己組織化の状態を作る。
    ・情報の非対称性が小さい
    ・認知の歪みが少ない
    ・チームより小さい限定合理性が働かない
    ・対人リスクを取れていて心理的安全性が高い
    ・課題・不安に向き合い不確実性の削減が効率よくできている
    ・チーム全体のゴール認識レベルが高い

    不確実性には、未来に対する環境不確実性と、他人に対する通信不確実性が存在する。
    環境不確実性は、方法不確実性と目的不確実性に分けられる。
    不安は通信不確実性を増大し、結果、目的不確実性、方法不確実性を増大する。

    アジャイル開発は、役割の分断と情報の非対称性を解消するため、
    顧客との協調、個人との対話、動くソフトウェア、変化への適応を重視する。

  • Chapter 4　学習するチームと不確実性マネジメント
    納期までに必要と考えられている３要素は以下。
    ・理想工期：工数人月／人数
    ・制約スラック：作業同士の依存関係による無駄
    ・プロジェクトバッファ：見積もりの不確実性を吸収する期間

    制約スラックを削減するためには、作業の属人化によるリソース制約、
    作業間の依存関係による依存制約を取り外す。
    見積りをノルマではなく予測として扱い、スケジュール予測の収束を管理する。
    予実幅を見える化し透明性を保ち、効率よく削減する。
    タスクごとのバッファではなく、プロジェクトバッファを用意することで、
    スケジュール不確実性の削減を見える化する。

    スケジュール不安に対するマネジメントと、マーケット不安に対するマネジメントには対称性がある。
    時間境界型プロジェクトでは、納期の手前にバッファを設けて不確実性に備える。
    機能境界型プロジェクトでは、計画した機能とMVPの差を用意して不確実性に備える。
    ２つの不確実性を考慮し、全体のバッファを用意する。

    スクラムイベントで、目的不確実性、方法不確実性、情報非対称性を軽減する。

  • Chapter 5　技術組織の力学とアーキテクチャ
    システム実現のための組織構造が最適化されていない場合、
    組織全体の情報処理能力は下がり、組織構造の問題が技術的負債として組み込まれる。

    組織課題を改善するにはコミュニケーション構造のリファクタリングが必要。
    技術的負債が問題となる最大の理由は、追加機能とアーキテクチャに対する情報の非対称性。
    技術的負債を非機能要件として整理し、エンジニアと経営者の認識の差を低減する。

    企業の内側にあるべき事業上のケイパビリティを外部依存すると、大きな取引コストが生まれる。
    外注すべき領域と内製すべき領域は明確な線引きをし、
    システムアーキテクチャで持つことで取引コストをコントロールできる。

    内製においても、組織設計ミスや構造的問題により、限定的合理性に起因する取引コストは発生し、組織的負債となる。
    機能横断チームと機能別チームをバランスよく運営することで解消する。

    目標設定は目標が限定合理に陥らないように相互に役割を正しく認識し透明性を保つことが重要。

    ビジネスを完全に明晰な言葉で表現しなおすのがプログラミング。
    システム開発においてシステムアーキテクチャが、
    企業活動においては組織構造が動きやすさの要因となり、相互に影響を与える。
    コミュニケーションを通じて、ビジネスの向かうべき方向に一致させる。

まとめ

エンジニアリングとは何か、それを実現するための組織はどうあるべきかを
ミクロからマクロまで叩き込まれました。
ウォーターフォールの受託文化で育った自分としては、
この論を自分のベースに入れ替えたいと真剣に思います。
それこそ、思考のリファクタリングなのか。

特に【局所最適化】による問題は割と身近なところにあり、
企業間の契約にしろ、受発注の関係にしろ、工程間のやり取りにしろ、
リファクタしたい部分いっぱいあるよなー、となりました。
ただ、それをもっと俯瞰してどうプロダクト開発に影響があるかの理解ができました。

また、アジャイル開発に対して改めて考え直すためのきっかけとなりました。
スクラムマスターの役割もの根本もファシリテーターというざっくりな捉え方でいてしまったけど、
Chapter3のアジャイルの状態の実現と考えると、見え方が全然変わります。

いずれにせよ、もっと早めに頭に入れたかった１冊でした。
最後に広木さんが自分と同じ1983年生まれと知り驚愕です。

何度か読み直したい。


備考

後追いですが、以下の紹介動画も分かりやすかったです。ありがたい。。

youtu.be

youtu.be

 

作り続けるためにいかに作らないかのメモ

すべてのものは作った瞬間に陳腐化がはじまるという話と、
高速ごみ製造機をより好む、という話について。

  • 頭の引っ掛かり
    先日『その機能、今作る必要ある？』というオンラインイベントに参加以来、
    「すべてのものは作った瞬間に陳腐化がはじまる」という言葉が頭に残っています。
    hiliteeternal.hatenablog.com

  • 引っ掛かりの取っ掛かり
    ずっともやもやしていたのですが、取っ掛かりは一か月ぐらい前に参加したイベントでの、
    KDDIアジャイル開発センター北浦さんの『システム開発の残念な原理原則』だと気付きました。

    youtu.be

    システムは
    ・何もしなければ壊れる
    ・何かしても壊れる
    ・壊さないように努力しすぎると何もできないし、努力を怠ると使ってもらえない
    という話です。

  • 取っ掛かりの浸透
    そんなことが頭に残る中で２週間くらい前に参加したpmconf2024での
    LayerX加藤さんのお話で作るものを選んでいく重要性が浸透していました。

    hiliteeternal.hatenablog.com

    youtu.be

    speakerdeck.com

    作らないことを続けるためには、
    ・作らないものを決める
    ・作るものを削る
    ・作るものを尖らせる
    ことが重要であり、それをいつでも実施続けることが重要というお話でした。

  • 頭の取っ掛かり

    そして、先週の作らないものを決めることにフォーカスした
    『その機能、今作る必要ある？』というお話。
    offers.jp speakerdeck.com

    作らないものを決めるためには、どうした観点で精査すべきかというお話でした。

  • 取っ掛かりから引っ掛かりのフィードバック

    そして、今朝。
    最近聞き始めたポッドキャストに北浦さんが登場し、
    冒頭の話を忘れていたことに気付きました。

    open.spotify.com

    オンラインイベントの時には、残念な原理原則の話と以降の話の関連性を見失っていましたが、
    ポッドキャストでのやり取りから、
    壊れない／壊さないために適切な運用監視が必要である、という文脈であったと気づきます。 
    陳腐化を防ぐためのコストが発生しだす、と理解しました。

  • 引っ掛かりの起源

    そのうえで、KDDI北浦さんのオンライン登壇と同日にあった、
    こちらの高速ごみ製造機をより好む、という話も頭の中でくすぶっていたことに気付きます。
    www.youtube.com

    speakerdeck.comプロダクトの成長速度より、プロダクトで実現したい期待が増える速度の方が早いため、
    やらないことは決めつつも、アウトプットを評価していく。
    そして、作るものを尖らせていく。


この１か月ほどで浴びた情報の整理。
すべてのものは作った瞬間に陳腐化がはじまるという話と、
高速ごみ製造機をより好むという話についてでした。
改めて、すごい人達のアウトプットに支えられています。

PHPカンファレンス2024 に行ってきました

PHPカンファレンス2024 に行ってきました。
初PHPカンファレンス。初大田区産業プラザPiO。
そして、今年最後の技術カンファレンス参加です。

 

イベントの概要

PHPカンファレンスは、PHP関連の技術を主とした技術者カンファレンスです。
2000年に日本のユーザ会によってPHPカンファレンスが初めて行われ、今年で25回目の開催となります。
これからPHPをはじめる方から、さらにPHPを極めていきたい方まで幅広く楽しめるイベントになるよう様々なプログラムをご用意しております。

引用：

phpcon.php.gr.jp

イベント参加の背景

・今年通して技術カンファレンスに味を占め始めている。
・その中でPHPカンファレンスの面白そうな噂をよく聞く。
・PHPは贔屓のレコード屋さんのサイトメンテぐらいしか経験ない。（ほぼモグリ）
・だけど、勇気を出していってみる。

※レコード屋さんサイト

cdsoftcase.com

持ち帰るところの多かったセッション

お昼に行ってLTは帰りの電車にて。

  1. PHPで学ぶプログラミングの教訓／PHPで学ぶバックエンドソフトウェアアーキテクチャ選定の勘所
    GMO成瀬さんのセッション。
    ・PHPで学ぶプログラミングの教訓

    speakerdeck.com

    ・codeの話。
    DRY、OAOOは気付いた時から対応する。

    ・designの話。
    シンプル≠イージー。シンプルでハードは成り立つ。
    継承は子クラスの進化の管理ができない。

    ・spiritの話。
    どんなコードでも読もうと思うべ読める。
    統一感が最適解ではない。良くないものはよくない。新しくいいものをやる。
    自分が手に入れたところはきれいにする。

    ・PHPで学ぶバックエンドソフトウェアアーキテクチャ選定の勘所
    ・ヘキサゴナルアーキテクチャ
    ビジネスを中心に見立てそれ以外を交換可能とする。
    ビジネスロジックを点在させない。

    ・クリーンアーキテクチャ
    ヘキサゴナルと同様ビジネスロジックを中心としている。
    外側はヘキサゴンより詳細に記載している。

    開発チームが自走できるならヘキサゴナルを基本路線に。
    チームが成長段階であればレールの整ったアーキテクチャ。
    できるチームなら制約は増やさなくてよい。

    その他
    今年の頭頃に聞いたこちらの内容をまた聞けて嬉しかったです。

    findy-code.io

    　
  2. そーだいさんに聞く！コミュニティとともに在るエンジニアの良いキャリアの歩み方

    speakerdeck.com

    18歳から警察官。20歳で一番苦しい時を過ごした。
    エンジニアとしての体験でなくても、エンジニアとしての経験に活きている。

    エンジニア初期では作業環境が良くなかった。
    目の前の課題を改善したのがエンジニアとしての成長を生んだ。

    勉強会で出会った人が次のつながりを生んだ。
    コミュニティとの出会いにより、外の世界を知った。
    学習とアウトプットの好循環が生まれた。
    コロナ後は、年上の世代からだけではなく
    若い世代から学びの型を見つけることができた。

    自分の軸を見つける。
    楽しくないもの（持続性のないもの）は対象としなかった。
    問題解決が好きということが、
    パフォーマンスチューニング、チーム形成への対応に繋がった。

    何かが良いと思ったら、今日からやることが重要。
    バッターボックスに立つことでチャンスが増える。
    バットを振ったことから次に繋げることが重要。
    キャリアを積み重ねることで見えていくことが増える。

    憧れるだけだと乗り越えられない。
    理想を体現していくことが大事。

    xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com


    その他
    ここの話の延長戦をお聞きすることができました。

    hiliteeternal.hatenablog.com

  3. 20年続くレガシープロダクトに10年携わったエンジニアが思う、システム長期運用のカギ

    fortee.jp

    ブライダル会社。口コミ情報サイト「WeddingPark」の話。
    エンジニアは、デザイン思考と具体化力で事業成長をリードする。

    変化に強いプラットフォームにするためには、
    様々な取り組みに対するリードタイムを低減する。
    プロダクト維持には、運用保守をいかに短く実行するか。

    5->7へのアップデート時に不要な機能が多くあった。
    アップデート後は不要な機能はそぎ落とし、新機能を載せる際も吟味した。
    オンプレからクラウド移行でメンテナンスがしやすい状態に。

    仕様のキャッチアップ、ドキュメンテーションに課題あり。
    システムだけでなく、再現性のある開発体制にする必要がある。
    常に人・組織が安心して決断できる状態に。

    …最後のお話には、やっぱり及川卓也さんいうところの手の内化が重要と実感。

出展ブース

カンファレンスのブースを回るたびに、
我々の生活にとってのソフトウェアの重要性を感じます。
エンジニアとしての立場を離れても、魅力的なサービスはたくさんあって、
妻や娘へのプレゼントにはギフトモールさん使いたいなー、とか、
猫は飼ってはいないけど猫IoTとかすごいな、とか、
娘の保育園でSENさん導入していたら写真いっぱい買っちゃうよなー、とか。
あまり各企業様のブース出展の目的にはあっているか分からないものの、
お話聞かせて頂くのをいつも楽しみにしています。

感想とまとめ

想像以上の熱量にびっくりしました。
もちろん、技術的に分からない内容も多くあるものの、
こうしたイベントで同じ技術に携わるエンジニア同士でそれが共有されることが
いかに重要であるかは、なんとなくでも想像ができます。

ただ、それと同時に「じゃあ自分はどこで何を言える人なのか」は考えたい。
来年の目標は外部イベントでの登壇。

PHPカンファレンスまた行きたい。