お疲れ様でした！ 今回は実行委員 + 登壇者として参加してきました！
今回の登壇では、MySQL5.6 から 8.4 へアップグレートした際の話をしました。このあたりの詳細な話は勤務先のテックブログに記載します！
2024 の時と同じく、スピーカー担当として事前準備や当日運営に携わりました。
2024 の事前準備では、不慣れなこともあり、大部分を実行委員長が助けてくれました。今年こそはできることをもっと増やそうと決意して取り組んだことを覚えています。
結果、前年比でやれたことは多かったと思います。また、来年も実行委員をやります！
PHP カンファレンスの運営に関わって数年、知り合いの方が増えてきました。皆さん暖かく、本当に PHP コミュニティが大好きです。
これからも推していきます！！！
今回読んだ本はこちら。
Google Chrome チームでエンジニアリングチームをリードしてきた著者の知見の詰まった一冊になります。
効果的にエンジニアリングチームのリードする方法を考え方や実践方法をベースに解説しています。
本書の構成は下記の通りです。
構成としてまとめましたが、「効率性と効果性と生産性について」では、効果的にする条件や効率性・効果性・生産性の違い、3 つの E モデルと本書を読み解くうえでの基本的な概念の解説が行われています。感想で記載しますが、効率性・効果性・生産性の違いは、当たり前の内容ではありますが、言われてみる意識できていないことも多いかもしれません。
本書で一番印象的だったのが「効率性・効果性・生産性の違い」を明確に定義している点です。キーワードは「正しいことを正しく行う」です。
効率性
効率性はインプットに焦点を当てています。
タスクやプロジェクトを最小の時間や労力で完了させることが効率性が高い状態です。無駄を廃止し、プロセスを最適化することで効率性を高めることができます。
生産性
生産性はアウトプットに焦点を当てています。
特定の期間内に多くの成果物を生み出すことが生産性が高い状態です。 AI などのツールやテクノロジーを駆使することで効率性や生産性は高めることができます。
効果性
効率性ではいかに上手く行うか、生産性ではいかに多く行うかに焦点が当てられています。しかし、生み出された成果物はビジネスにおいて価値のあるものでしょうか？
このインパクトやアウトカムに焦点を当てているのが効果性です。ニーズに合致するものやユーザーにとって価値のあるものを生み出すことこそがビジネスの目的であるため、アウトカムを無視してエンジニアリングは語れません。
そのための手法として、OKR といった組織の目標をチーム・個人目標とマッチさせる方法についても言及がされていました。
まとめ
インプットやアウトプットだけでなく、アウトカムにも焦点を当てた効果性を意識することが大切です。当然ではありますが、振り返ってみると内省することが多いように感じます。
詳しくは触れていませんが、マネージャーとしての最低条件や立ち振舞についても言及されていますので、ぜひ一読してみていただけると幸いです。
今回読んだ本はこちら。
エフェクチュエーション 優れた起業家が実践する「5 つの原則」
社内で話題になっていたので読んでみました。
今回は珍しくビジネス書寄りの内容になります。
KPI や目標を定め、逆手で手段に落とし込んでいくコーゼーションに対し、現状の手札から行動を元に目標を定めていくエフェクチュエーション。
そのエフェクチュエーションの考え方を説いた入門書となります。
本書の構成は下記の通りです。
エフェクチュエーション実践者の解説以前と以後では著者が変わります。
エフェクチュエーションの原則紹介では下記の原則を説いています。
起業家や実業家に多い思考パターンとしてエフェクチュエーションを紹介していましたが、コーゼーションとエフェクチュエーションはどちらが良い悪いではなく、事象によってどちらを重視するかが変わるだけの関係です。
そのため、組織の成長段階によってはコーゼーションを選択することもあります。しかし、不確実性の高い状況では、事前の見通しがしにくいことからエフェクチュエーションを選択することが最適になりやすい印象でした。
平たく言ってしまうと、とりあえずやる。色々な人を巻き込んで、FB から学習していく。そんな印象を受けました。
下記に簡単に原則を記載します。
手中の鳥の原則
手中の鳥の原則は、今持っている手札から何ができるかを考えるといったものです。何が足りない、何を得るではなく、今の自分が出せるものを活用することでまずは行動に移すことが大切です。
また、自覚していないだけで他者にとって、自身の持っているものが価値のあるものの可能性もあります。
許容可能な損失の原則
従来のコーゼーションでは売上予測などの得られるものをベースに行動を定義します。
しかし、不確実性が高い環境では得られるもの自体が不確実です。そのため、最悪の事態に陥ったとして、どのくらいまでなら許容できるかを事前に考慮したうえで行動を行います。
レモネードの原則
行動を起こすということは、当然失敗も起こります。その中で仮に満足の行くものでなかったとしても、新たなる機会の拡張だと捉えることで、ネクストアクションを行うことが大切です。
クレイジーキルトの原則
コーゼーションにおいては、他社を当初の目的の競合や脅威にカテゴライズしてしまうこともあります。しかし、エフェクチュエーションにおいては、誰が何をもたらすかはわかりません。
そのため、様々なバックボーンを持った関係者が予想もしない関わり方で予想もしない展開を見せることがあります。
他社を巻き込み、推進していくことが大切です。
飛行機のパイロットの原則
不確実性の高い環境では、事前の予測が難しいため、エフェクチュエーションではコントロールすることを重視しています。
不足の事態が起こったとしても、適宜操縦桿を握り、進路を取ることで新たな機会への進んでいきます。
まとめ
何をするにおいても、他者と如何に関わっていくかが大切だと感じました。また、行動を起こすことの大切さも感じます。
以前、PHP カンファレンスで聞いて記憶に残っている一言「伸びる人は素直な人。そしてすぐやる人」を思い起こしました。
そのためには普段から、様々な人と関わっていくことが大切だと思います。
今回読んだ本はこちら。
Terraform の知見が少なく、良いレビューができなくなっていることを恐れ購入しました。
余談ですが、O’REILLY は電子書籍が Amazon で購入できないため、O’REILLY で購入しました。その際に EPUB を Kindle にインポートすると、Kindle 本と同等に扱える上にファイルも手元にある。ということで最高でした。
Terraform の使い方を勉強する。その過程で AWS や k8 が出てきますが、主題ではありません。
本書の構成は下記の通りです。
正直、tfstate という Terraform のステート管理の仕組みや、チーム開発では s3 等に tfstate を格納する等を全く知りませんでした。そのため、全ての内容が新鮮であり、現在のプロジェクトに当てはめると腑に落ちる部分が多分にありました。
また、module の書き方を知った当日に Terraform を書き換える必要があり、すぐに役に立ちました。
今でこそ、AI に聞くことで、ある程度の知識量でもなんとなく進めることができてしまいます。しかし、知っている方がより良い実装ができますし、レビューに活かすこともできます。
AI 時代はガードレールが重要ですが、そのためにも日々精進していくべきだと再認識できた一冊です。 Terraform 初心者にはおすすめです。
今回読んだ本はこちら。
Lean と DevOps の科学 テクノロジーの戦略的活用が組織変革を加速する
現状のチーム、プロダクトの状態に危機感を抱いており、SRE や DevOps の概念をもっと理解していき取り入れようと思い読みました。
Lean と DevOps がどのようなものなのか、またその根拠を示すものとなっています。
本書の構成は下記の通りです。
IT 組織における膨大な調査・研究から見えてきたものを紹介しています。その中では、今となっては聞き慣れた「コードはバージョン管理システムで管理」や「CI を拡充していくことの必要性」などといったことを論証を元に説明しています。
様々なところでこの本が引き合いに出されることからも、業界に与えた影響は大きいのだろうと想像できます。現在では、よく聞く DevOps の重要性やその方法を根拠を元に知れる点が非常に価値があります。
しかし、よく聞くようになってしまった今となっては新たな知識というより、既存の知識の裏付けといった側面が多いのも正直なところです。
この本にとどまらず、チームやプロダクトをより改善していくための本を読み続けようと思います。
今回読んだ本はこちら。
X で「おすすめの本ありませんか？」と募ったところ、長南さんに紹介していただきました。
組織開発とは何か、なぜ必要なのか。本書では詳細な手法というよりは概念を説いていた印象です。
本書の構成は下記の通りです。
組織開発と呼ばれる分野の歴史的な流れや、必要性を中心に説明されており、大変わかりやすかったです。詳細な理論や手法は割愛することで、「なぜ必要なのか」であったり「何を意識するのか」といった概念的な部分が強調されています。
中でも印象深かったのは、組織開発を下記の 2 つに分類している点でした。
ハードな側面、ソフトの側面のどちらかに注力するのではなく、どちらも実施することが望ましい。しかしハードな側面は過去にも注目されてきたが、ソフトな側面は今まで注目されてきておらず、近年注目されているそうです。(2015 年の当時)
Change Agent や Talent Management という単語を聞くことはあったものの、詳細な意味までは知らなかったので良い勉強になり、今後掘り下げていく必要性も感じました。本の分量的にも読みやすく・読み返しやすいです。
ご紹介いただきありがとうございました！
今回読んだ本はこちら。
X で「おすすめの本ありませんか？」と募ったところ、けんちゃんくんさんが紹介してくれました。
知識を得るための積極的な読書の意義とその方法論。これに尽きると思います。
知識を得る部分を主題としているので、小説等の娯楽的読書は後半で少し触れる程度です。
本書の構成は下記の通りです。中でも読書の方法論に関しては大部分のページを使って論じています。
学術書(我々で言うと技術書)をどのような方法論で読むと、知識を得るという目標を最大化できるかを解説しています。
まず、作者が熱い。熱量を非常に感じます。本当に本が好きなんだと。その一方「読むに値しない悪書」についても述べている点は印象的でした。
読書の方法としては、以下を挙げています。
点検読書は本の全体を点検します。題名や目次、序文から全体の構成を理解した上で読むことの大切さ、全体を点検して内容を把握することの大切さを説いています。
分析読書では、本の内容を解析していくことで、著者の主張や、内容に対する是非を判断していくことになります。
シントピカル読書では、類似の複数の本から知識を学ぶ方法であり、その実践方法を紹介しています。
正直、一度では理解しきれたとは言い難いため、時期を置いて再読していくことで、より理解を深められる本だと思いました。素敵な本をご紹介いただき、ありがとうございました！
先日受けた vibe coding 研修に触発されて、静的サイトジェネレーターでブログを作成しようと思い立ちました。
夜中にほぼ初挑戦の Next.js を使い、Cursor でゴリゴリコードを書かせていて気づきました。「車輪の再開発では？」と。
というわけで、Go 言語の静的サイトジェネレーター Hugo を使って、いい感じにするのを AI に手伝ってもらうことにしました。
ブログでは、今まで Qiita で書いていた技術的な記事、日々の日記、書評を載せていきます。よろしくお願いします。
このブログは Hugo を使って作成しています。ブログといえば Wordpress の PHPer 的には「今って CMS 使わないのか」と驚きを隠せません。
調べたところによると、SEO 対策やセキュリティの観点から、静的サイトジェネレーターを使って、静的ファイルを設置するのが主流だそうです。確かに、DB もログイン画面も不要ですし、サーバーも最低限のスペックで充分かもしれません。
CMS を使う場合も、バックエンドとフロントエンドを分けるヘッドレス CMS というものがあるようです。その場合、下記流れになります。
記事を Git 管理したいのか、DB 管理したいのか。エンジニアなのか非エンジニアなのかによって選択肢も変わると思いますが、時代の変化に驚いています。
