読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第92回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。今回とりあげるのは「シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く (オライリー・ジャパン)」。とても有益で参考にしている「エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法」の続刊である。前著より視座・職位が…
あるところで「NASAのマーガレット・ハミルトンが自らの仕事を正当に評価させるためソフトウェアエンジニアという言葉を作り出した」という文章を読んで、あれ、そうだったっけ？ と考えて調べたこと。「ソフトウェアエンジニア」という肩書や、日々の開発の裏側にある「当たり前」のルーツについて。 ソフトウェアエンジニアの誕生 世間一般のイメージでは、プログラミングやシステム開発というと、なんとなく「コードをガリガリ書く職人仕事」みたいな見方をされがちだ。でも、歴史を少し紐解いてみると、そ…
AI要件定義サミットという興味深いイベント（知ったのは開催終了後だった）の基調講演を確認していたところ、要求工学に関する新しい知見としてINCOSEがガイドを出しているという。というわけで、ざっと読んでみたメモ。ai-requirement-definition-summit.comこの講演は良かった。INCOSE Needs and Requirements Manual: Needs, Requirements, Verification, Validation Acro…
アーキテクチャのモデリング記法であるC4モデルについての提唱者が書いた書籍「The C4 Model: Visualizing Software Architecture (English Edition)」がある。オライリー学習プラットフォーム上で実験的なAI翻訳版が出ていたので読んだメモ。www.oreilly.comちなみにこの本はとても短い。しかし為替の影響で原著がめちゃ高い。The C4 Model: Visualizing Software Architectur…
「エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定」で紹介されていた「Enterprise Architecture As Strategy: Creating a Foundation for Business Execution (English Edition)」をざっと読んだという話。エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定作者:Will Larsonオーム社AmazonEnterprise Architectu…
公共放送の影響で（プロジェクトXとか仕事の流儀とか）で、日本のプロフェッショナル像というのはけっこうあいまいになっている。ITエンジニアは、医師や弁護士と同等な「プロフェッション（専門職）」なのだろうか、ということを考えている。 プロフェッションを構成する6つの要素 放送大学の「共生のための技術者倫理」という講義を受講している。そこで技術者のプロフェッションについて紹介されていて興味深かった。一般論として、プロフェッションは6つの要素で構成されているということだ。 理論的知識…
読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第91回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。今回とりあげるのは「エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定」だ。エンジニアリングマネジメントの領域で良書を多数発表しているWill Larsonさんの新しい訳書であり期待値が高い。しかも前著でもトピックとして興味深かった「戦略」…
2026年1月～6月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あとコミック、漫画雑誌類もカウントからは除外。 この6カ月では80冊の本を読んだようだ（前シーズンは74冊）。概ね平常運転を継続。いつもどおり半期で読んだ本の中で良かったものをピックアップしてみる。 文芸書のおすすめ（一般編） 文芸書のおすすめ（趣味のSF編） 文芸書のおすすめ（趣味のミステリ編） 教養書のおすすめ ビジネス書のおすすめ 技術書のおすすめ この…
読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第90回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。今回とりあげるのは「Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方」だ。Alignedの意味は「揃える」で、ビジネス的な文脈でいえば「足並みを揃える」となる。まさに、組織の足並みを揃えるようなことが書かれているようだが、実際のところは…
日々の業務や個人開発の中で、「これって技術的には可能だが、本当にやっていいのだろうか」「波風を立てたくないが、このやり方は筋が悪い気がする…」とモヤモヤすることがある。ITエンジニアは、コードを書くプロセスからチーム開発のコミュニケーションに至るまで、常に「正解のない意思決定（倫理的ジレンマ）」に直面している。コンプライアンスや法律のギリギリのラインを攻める時だけでなく、日常的なチーム内の振る舞いにおいても判断に迷う場面は多いはずだ。そんな時、直感や感情、あるいはその場の空気…
本ブログでときどき言及している、超上流工程向けの開発方法論である「要求開発」というものがある。以前は書籍やコミュニティサイトでの公開文書などがあったのだけれども、現在は入手困難であったりサイトは閉鎖されている。というわけで、復刻してみたという話。Zennというエンジニア向けの情報コミュニティに掲載している。無料です。Zennの仕組みで感想などをフィードバックすることもできる。zenn.dev 復刻について どうやったのか 以前に存在していた要求開発のサイトのインターネットアー…
最近考えていること。AI駆動開発時代に、「要求開発」を見直してもいいんじゃないかと考えたこと。要求開発~価値ある要求を導き出すプロセスとモデリング作者:山岸 耕二,安井 昌男,萩本 順三,河野 正幸,野田 伊佐夫,平鍋 健児,細川 努,依田 智夫,［要求開発アライアンス］日経BPAmazon 「要求」は引き出すものではなく、開発するもの 『情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである』。これは、かつて「要…