組織の足並みを揃える「Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方」を読んだ

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第90回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

今回とりあげるのは「Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方」だ。Alignedの意味は「揃える」で、ビジネス的な文脈でいえば「足並みを揃える」となる。まさに、組織の足並みを揃えるようなことが書かれているようだが、実際のところはどうだろう。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方

物語形式が読みやすく、しかしウッとなる

さて、本書の特徴はストーリー仕立てであるということだ。古くは有名な「ザ・ゴール」形式というか、主人公がいて、様々な困難に立ち向かいながら（都合よくいろんな人にアドバイスを貰って）解決していくという仕立てになっている。これが本書のテーマであるステークホルダーとの関係性の構築にうまく当てはまっていて、素晴らしいというのが感想である。特に人間関係に関するテクニックを学ぶ際に重要なのは共感だと考えている。いくら方法論やフレームワークを習得しても、困った時に出てこないと困るのだ。そういう時に、ストーリーで理解しやすい私たちの脳に物語でスッと入ってくる点が良い。ハマった時に「そういえばアイリーはこんな時……」と思い出すことができるだろう。たぶん。

というわけで先走ってしまったが、本書は健康系のアプリを開発する会社にプロダクトマネージャーとして転職してきたアイリーという主人公が奮闘する物語を中心に展開していく。同じようなシチュエーションになったことがないので実際のところがどうなのかはわからないが、オンボーディングが超雑で驚き、その後も組織がカオスで泣ける。

組織マネジメント、リーダーシップ論ではないのが良い

組織の足並みが揃っていない状況でありがちなのが、組織マネジメントの問題であったりリーダーシップの課題だと考えることだ。まあ、もちろんそれらの機能不全が原因ということはあるのだと思うけれども、往々にしてないものねだりになってしまう。

本書では組織の足並みが揃っていないという課題に、（主にアイリーが）権限を持たない立場で周囲を巻き込んでいくというアプローチとなっている点が良い。メンバーの立場からもアクションできるからだ。

人を動かす　改訂文庫版

チーミングや自己組織化の話ではないのも良い

組織の足並みが揃っていない状態というと、チームビルディングの問題じゃないか？　アジャイルの文脈からするとチームの自己組織化に課題があるのでは？　コーチを入れると良いのでわ……みたいな話にもなりがちだが、本書はそういった方向性からも距離を取っているという点も良いと思っている。

もちろんチーミングがうまくできたり、自己組織化に成功すれば良いのだけれども、あくまで当事者として対処するのが本書の流儀のようである。というわけで、アイリーはあくまで1人の担当者として考えていく。

その他本書で勉強したこと

というわけで本書は一種のステークホルダー分析と対策の話なのだが、いくつか興味深いテクニックや解決策の提示もある。個人的に気に入ったものをピックアップしておく。詳細は書籍を参照。

• パワープレーヤー見極めのための「支配的職能のための質問」
• 「上流ステークホルダーと下流ステークホルダー」身も蓋もない分類だけど、なるほどと感心した
• 「DACI意思決定モデル」RACIモデルは知っていたけど、これは知らなかった。
  • DACI：意思決定フレームワーク | Atlassian Team Playbook
• 「ステークホルダーキャンバス」なんでもキャンバスにするのは反対だけど、ステークホルダー一覧としてみても良い整理という印象
• 「衝突を探るテクニック」たとえばワークショップで意図的にひどいアイデアを紹介して判断基準について探るなど、実際にやれるかは別としてテクニックとして知っておくのは良いと思う
• 「ノーと言うときのコツ」こう言うのはいくらでも持っておきたい

でも本書はプロダクト開発のときの話なんでしょう？　いや、そうでもない

というわけで、なかなか良い本だと思っている。だけどタイトルにもあるように「プロダクト開発」向けの本である。ではその他のソフトウェア開発プロジェクトでは活用は難しいだろうか。いや、そうでもない。

• 受託開発などでも、複数部門が関与する大規模プロジェクトでは似たような話になりがち
  • たとえば基幹システムとか、ERPの導入など
  • システム部門の人など、組織のアラインメントが取れなくて、よく引き裂かれているので参考になるのでは

そもそも、大変に読みやすい本でもあるので、プロダクト開発にスコープを狭めず手に取ってみれば良いのではないだろうか

というわけで、本書の感想はここまで。さて次は何を読もうかな。
引き続き気になっている本はこれ（消えた本は実はもう読んでしまっている）

• アーキテクチャモダナイゼーション【リフロー型】 組織とビジネスの未来を設計する
• GROWTH――「脱」でも「親」でもない新成長論
• エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定
• シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く (オライリー・ジャパン)
• シンプリシティ ―持続可能かつ人間的で効果的なソフトウェア開発

エンジニアの「モヤモヤ」を言語化する倫理的意思決定の「セブン・ステップ・ガイド」

日々の業務や個人開発の中で、「これって技術的には可能だが、本当にやっていいのだろうか」「波風を立てたくないが、このやり方は筋が悪い気がする…」とモヤモヤすることがある。

ITエンジニアは、コードを書くプロセスからチーム開発のコミュニケーションに至るまで、常に「正解のない意思決定（倫理的ジレンマ）」に直面している。コンプライアンスや法律のギリギリのラインを攻める時だけでなく、日常的なチーム内の振る舞いにおいても判断に迷う場面は多いはずだ。

そんな時、直感や感情、あるいはその場の空気に流されるのではなく、論理的かつ多角的に解決策を導き出すための強力なフレームワークが存在する。
それが、イリノイ工科大学（IIT）のマイケル・デイビス（Michael Davis）博士が提唱した「セブン・ステップ・ガイド（Seven-Step Guide to Ethical Decision Making）」だ。

参考リソース：

• Seven-step Guide to Ethical Decision Making（金沢工業大学 科学技術応用倫理研究所による翻訳・解説資料 PDF）
• Ethics and Statistics（ペンシルベニア州立大学による同ガイドの解説ページ・英語）

直感を論理に変える「7つのステップ」

セブン・ステップ・ガイドは、複雑な問題を解きほぐすために、以下の7つのプロセスに沿って思考を整理するアプローチだ。

1. 問題を明確にする (State the problem)
   • 自分が直面しているジレンマの本質は何かを言葉にする。
2. 事実を収集・整理する (Check facts)
   • 憶測や思い込みを排し、「客観的に分かっている事実」と「不確かなこと」を切り分ける。
3. ステークホルダーを特定する (Identify relevant factors)
   • 自分の決断によって影響を受けるすべての人や組織（ユーザー、会社、同僚、社会など）を洗い出す。
4. 複数の選択肢を考案する (Develop a list of options)
   • 「やるか・やらないか」の二択ではなく、実行可能な第3、第4の行動案を5つほど列挙する。
5. 選択肢を倫理的にテストする (Test the options)
   • ここがガイドの最重要パートである。出した選択肢に対し、以下の5つのテストを行う。
     • 危害テスト: もたらす悪影響（リスク）が一番少ないか？
     • 公開テスト: この決断が世間に広く報じられても、自分は堂々としていられるか？
     • 可逆性テスト: もし自分が影響を受ける側（被害を被る側）だとしたら、その決断を許容できるか？
     • 徳テスト: 人として、プロフェッショナルとして誇れる行動か？
     • 専門家テスト: 同僚や業界の専門機関は、これを支持してくれるか？
6. 行動を決定する (Make a choice)
   • テスト結果を総合的に判断し、最も妥当な方針を決定する。
7. 再発防止策を検討する (Review / Preventative measures)
   • 今後同じようなジレンマが発生しないための仕組みづくりや予防策を考える。

考えてみてほしい2つのケーススタディ

このガイドが実際の場面でどう役立つのか。最近IT業界で話題になった2つの事例を共有しよう。わたしの考えた「正解」は書かない（そもそも正解はない）。 ぜひ皆さんで、先ほどのセブン・ステップ・ガイドに当てはめて「自分ならどう評価し、どう行動するか」を試してみてほしい。後述するが生成AIあたりと壁打ちするのが手軽でおすすめ。

ケース1：非公式クライアントの実環境テスト

ある若い技術者が、大手飲食チェーンの公式注文システムのUXに不満を持ち、非公式の注文クライアントツールを自作した。これを「試しに」実際に稼働している店舗のサーバーに繋いで注文のテストを行い、その実行結果をネット上に公開しようとしている。
（「自分だけで試すだけなら誰にも迷惑をかけないのでは？」という直感は、5つのテストを通すとどう評価されるだろうか）

ケース2：筋が悪そうに見える方針への介入

同僚や他チームが進めている仕事の方針が、どう見ても「筋が悪い（非効率、無駄が多い）」と感じている。しかし、口を出すと相手のやる気を削いだり、人間関係に波風が立ったりするリスクがある。「静観する」か「あえて口を出す（介入する）」か。プロフェッショナルとしてどう振る舞うべきだろうか。
（参考事例：筋が悪そうに見える方針に口を出す - Konifar's ZATSU）

生成AIを「倫理の壁打ち相手」にする

とはいえ、この7つのステップを一人で、頭の中だけで完結させるのはなかなか骨が折れる。どうしても自分に都合の良いバイアスがかかってしまうこともあるだろう。

そこで推奨したいのが、生成AI（ChatGPTやClaude、Geminiなど）を「壁打ち相手」として活用することだ。
何か判断に迷った時、「今こういう倫理的ジレンマに直面している。セブン・ステップ・ガイドのフレームワークを使って、私が取るべき選択肢を一緒にテストしてくれないか」とプロンプトを投げてみてほしい。

AIは感情に流されることなく、「ステークホルダーに〇〇が欠けている」「公開テストの観点から見ると、その選択肢は炎上リスクが高い」といった客観的なフィードバックを返してくれる。一人で悩むよりも、はるかに解像度の高い意思決定ができるはずだ。
倫理的な意思決定とは、「絶対に正しい一つの答え」を探すことではない。「なぜ自分はその行動を選んだのか、論理的かつ誠実に説明できる状態を作ること」である。

次に業務で「モヤッ」とする状況に直面したら、そのまま見過ごす前に、ぜひこのガイド（とAI）を活用して、納得のいく意思決定を試みてほしい。というか、わたしはやってる。

本質から考え行動する科学技術者倫理 (科学技術者倫理教育のテキスト)

↑ いまこれをベースにした放送大学の授業を受けている。本書は未読

プロダクト倫理: あなたのプロダクトは誰かを傷つけていないか

↑ ソフトウェア開発における近年の倫理的問題などを取り上げており、よい本だった

哲学史入門Ⅳ　正義論、功利主義からケアの倫理まで ＮＨＫ出版新書

↑ 第四巻は倫理学がテーマ。連続性はないので興味があればいきなりⅣ巻から読んで問題ない。よかった

「要求開発」を復刻してみた（かも）

本ブログでときどき言及している、超上流工程向けの開発方法論である「要求開発」というものがある。以前は書籍やコミュニティサイトでの公開文書などがあったのだけれども、現在は入手困難であったりサイトは閉鎖されている。というわけで、復刻してみたという話。Zennというエンジニア向けの情報コミュニティに掲載している。無料です。Zennの仕組みで感想などをフィードバックすることもできる。

zenn.dev

復刻について

どうやったのか

以前に存在していた要求開発のサイトのインターネットアーカイブから当時の資料を取り出して、AIに入力して下書きを書かせ、ブラッシュアップして作成している。とはいえ全自動ということはなくて、だいぶ試行錯誤をしている。元のサイトの文章のコピーでもない形にはなっているはずである。
また、現在（2026年）の時点で明らかに古すぎる情報や、現代の読者にわかりにくい表現なども見直すように心がけている。またコラムという形で過去にはなかった、わたしの意見も少し足している。

どうしてやったのか

以前にに記事で言及した通り、改めて見直されても良い方法論のように考えたからである。
agnozingdays.hatenablog.com
あとは、ついカッとなってやりました。

権利的に問題ないのか

参考にしているアーカイブ上の要求開発のサイトでの掲載情報はそもそもクリエイティブ・コモンズのCC-BYというライセンスで公開しており翻案することが許諾されているという点で、問題ないはずだ。また、ややこしい話だが、そこで掲載されていた文書というのは、当時コミュニティのメンバーとしてわたしが執筆していたということもあり問題ないだろう（誤解のないように補足しておくと、要求開発という手法を考えたのはわたしではない。わたしは分散している各種の資料を統合して、Openthology Ver1.0の文書化をしていたに過ぎない）。

なお、要求開発は出版社から2冊の書籍として発売されている。これらの書籍については手元になかったので参考にしていない（わたしは出版に関与もしていないので、原稿すら持っておらず、AIにも入力していない）。この点でも権利上の問題はないはずだ。

なぜZenn？

これは単に使ってみたかったかから。ブログやNoteなどで掲載することも考えたが、ひとまとまりのEブック的な塊で情報提示するのであればZennは良いサービスだと思う。

クイックリー？

Eブックのタイトルは「要求開発クイックリー」というタイトルにしている。これはDDD Quicklyというドメイン駆動開発に関する短いブックレットを模している。骨子を紹介する短い本にしたかったのでこの形にしている。

• Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 - InfoQ

今後の展望について（？）

特に考えていることはない。ただこの復刻作業を実施して、いくつか考えたことがある。それらは本ブログで掲載するかもしれない。

AI駆動開発時代に「要求開発」が再浮上する（かも）

最近考えていること。AI駆動開発時代に、「要求開発」を見直してもいいんじゃないかと考えたこと。

要求開発~価値ある要求を導き出すプロセスとモデリング

「要求」は引き出すものではなく、開発するもの

『情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである』。これは、かつて「要求開発」という上流工程の方法論が提唱した中心的なコンセプトである。

agnozingdays.hatenablog.com

従来の「要求分析」や「要求定義」という言葉は、あたかも要求がユーザーの中に最初から存在しており、それをヒアリングして文書化すればよいという錯覚を与えがちである。しかし実際には、作ってみないと分からない部分が多く、何度もトライ＆エラーを繰り返すわけにもいかない。そこでシステムを作る前に、ビジネス価値を入力として「要求を創造・開発する」というプロセスが必要だ、というのが要求開発の根本的な考え方である。

要求開発では、ビジネスの全体像をモデリング（可視化）し、それを中核にステークホルダー間で要求に関する協議と合意形成を進める。このアプローチは非常に芯を食っていたが、その後に台頭したアジャイル開発やプロダクト開発の進展の陰に隠れ、大きなトレンドにはなりきらなかった。
しかし、AI駆動開発が現実のものとなった今、私は「改めて要求開発のアプローチが必要なのではないか」と強く感じている。

AI時代は「コンテキストの正確性」で勝負が決まる

AI駆動開発によって、設計や実装といったソフトウェア開発の中核プロセスは爆速で実行できる時代に入りつつある。それに伴い、「上流工程がより重要になる」という議論が様々な場所で交わされている。

しかし、肝心の上流工程について、従来型の要件定義のフォーマットを埋める作業として語られていることに違和感を覚える。AIを使えば立派な要件定義書を瞬時に作成できるが、「その要件は、本当に正しいのか？」という本質的な問いが残されたままなのだ。

企業情報システムにおいては、精度の高い要求を開発するために、要求開発のアプローチを再考すべき時期に来ている。そこには以下の3つの理由がある。

1. 要求はそもそも「最初から定義できるもの」ではない

現代のシステム開発では、「業務や既存システムを隅々まで理解している設計者がもういない」「業務全体が巨大化しすぎて、全体像を把握している人がいない」という事態が頻発している。要求は、多数の利害関係者の頭の中に、ぼんやりとした形でしか存在していない。存在しないものをAIが引き出すことは不可能である。

2. 「コタツモデル」による集合知の形成が必要である

無矛盾の要求を定義するためには、ビジネスオーナー、業務担当者、開発者が知識を持ち寄り、共に議論する必要がある。要求開発ではこれを「コタツモデル」と呼ぶ。各自の暗黙知をモデリングによって可視化し、構造化することで、初めて欠落を補完し、真の合意形成に至ることができる。

3. 「なぜ作るのか」というコンテキストの強度が結果を左右する

システム化の目的と手段の連鎖を明確にし、それが常に追跡可能（トレーサブル）であることが、今後の開発品質に直結する。AIに無数のトレードオフの中から最適な選択をさせるためには、単なる機能要件の羅列ではなく、「なぜこのシステムが必要なのか」という圧倒的なコンテキストの量と正確性が必要不可欠だからである。
AIがコードを生成するスピードが上がるほど、「何を、なぜ作るのか」を人間同士がモデリングを通じて合意する「要求開発」の領域が、プロジェクトの成否を分ける最大の要所となるはずである。

「要求開発」をモダナイズして再公開する

上記のようなことを思いながら、公開中止されてしまった「要求開発」の復刻について考えている。当時の資料はネット上では非公開になってしまっているが、CC-by-2.5であったし手元にはおおむね揃っている。生成AIなどを使って再整理、モダナイズして公開すれば、良い議論ができるんじゃないかと考えている今日この頃。

ソフトウェア要求　第3版

ケース・スタディとケース・メソッド

中上級の技術者教育について考えている。経験的に有効な手法の一つに実際の事例を用いたグループワークがある。これをより改善するための方法を調べたり、考えたりしたことの覚え書き。

ケース・スタディとケース・メソッド

自分は実際の事例を用いたグループワークのことを雑に「ケース・スタディ」と呼んでいたのだけれども、どうやらこれは正しくないようだ。世の中にはケース・スタディとケース・メソッドという学習方法があるということを最近知った。

ケース・スタディ	ケース・メソッド
事例の発端から結末までが明示されていて、それを第三者の客観的な立場から分析する。具体的状況の分析を通じて問題の原因を知り、再発防止のための教訓を学ぶことを目的とする	結末が明示されておらず、特定の状況での問題解決のための行動案を、当事者の主観的な立場から検討する。具体的状況について問題点を自ら発見し、それを解決していくための判断力を実践的に養うことを目的とする

うーん、自分はだいぶ混同していたことがわかる。

• 「ふりかえり／レトロスペクティブ」「失敗学」のようなアプローチはどちらかというと「ケース・スタディ」に近しい。教訓抽出の取り組みである
• メンバーの学習、スキルアップを目的とする活動は「ケース・メソッド」を使うべきだ
  • 結末は明示すべきではないらしい。この点をあまり意識していなかったな

土木学会「建設ケースメソッドのためのケース作成の手引き」に学ぶ

いろいろと調べていて学びが深かったのが土木学会が公開している建設ケースメソッドのためのケース作成の手引き（PDF）だ。

「ケースメソッド」の手法は、決まった答えのない領域において当事者が適切に判断し行動する能力を養うのに優れた方法であると言われています。それは、受講者が現実に起こった事例を基に作られた「ケース」を読み込み、そこに描かれる「修羅場」に対峙し、登場人物になりきって思い迷いながら判断、決断することによって、さながらその実体験したかのような効果（疑似体験）をもたらすします。そして、グループ討議や全体討議を通じて他者との間で掘り下げた意見交換を行うことにより、より深い考察や新たな気付きが生まれ、幅広い視野を持った実践対応力の涵養が行われるとされています。
建設ケースメソッドとは、この「ケースメソッド」の教育手法を建設分野に応用するものであります。
（同、1. 建設ケースメソッドとは　より）

これだ、と思っている。素晴らしい資料だ。

• 若手が決断を迫られる機会が減少しており、対策が必要という問題意識
• 擬似体験を通じて実践対応力を育む
• 現場で直面した「板挟み」を教材化する
• ケースの肝は「修羅場」（単なる苦労話ではいけない）
• 結末、結果はあえて書かない（正解をなぞるだけ、にしない）

実際に作成されたケース例などが以下のサイトで閲覧できる。参考にしたい
committees.jsce.or.jp

どんな用途で使うのか

（わたしの仕事である）ソフトウェア開発については、いくらでも使い所はありそうだ。プロジェクトマネジメントの領域でも、アーキテクティングでも良さそう。実際にPM教育では似たような取り組みをやったこともある。事例がベースになるので、各種のポストモーテムと関連させてプロセスに組み込んでしまうというのも良いかも。

• プロジェクトマネジメントの領域
  • 計画：複雑な（もしくは困難な）プロジェクトの計画をどうやるか？
  • 交渉：クライアントからの要求で、トレードオフを考えながらどう交渉する？
  • 問題解決：プロジェクト中に発生する困難な問題にどう対応するか
  • 炎上対応：QCDの達成が難しい局面で、どうするか
• アーキテクティングの領域
  • 設計判断：うーんよく考えてみたら、システム設計の面接試験 でいいような気がしてきた
  • 性能問題：どう対処するか
  • トラブル：どう対処するか

AIに書かせてみればいいんじゃない？

ここまでいろいろ考えてきたが、よく考えてみたら雑にAIに書かせてみればいいんじゃないか？という考えが降りてきた。これはちょっと研究してみよう。世の中に存在する豊富なトラブル事例をもとに、適当に合成できるのでは？

ケースメソッド教授法入門―理論・技法・演習・ココロ

新　失敗学　正解をつくる技術

心理的安全性のその先へ行くための本「失敗できる組織」を読んだ

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第89回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

今回とりあげるのは「失敗できる組織」だ。著者のエドモンドソンは心理的安全性に関する有名な書籍「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」の著者であり、本書はその続編と言っても良いだろう。でも、あまり話題になっていないような・・・

失敗できる組織

日本の「失敗学」とは異なるアプローチの「失敗できる組織」

ビジネス上の失敗を扱う議論としては先行するものとして日本の「失敗学」がある（残念ながら本書では言及されていない）。まず、両者の違いについて整理しておくと良いだろう。

新　失敗学　正解をつくる技術

• 失敗から学べ、というゴールは一緒
• 失敗学は工学的な考え方が中心であり、エドモンドソンの「失敗できる組織」は心理学・組織行動学がベースとなっている。
  • つまり、エドモンドソンの「失敗できる組織」の方が射程は長い。組織戦略までを含んでいると言える
• 失敗学は、報告された失敗を最大限活用することに強く着目しいている
• エドモンドソンの「失敗できる組織」は、失敗を恐れない文化の醸成に強く着目している

心理的安全性のその先へ

前著で説明された心理的安全性は重要ではあるものの、重要なのはその先にあるチームとしての学習である。これを促進するために、失敗に向き合う必要がある。これが本書の骨子である。
そして、心理的安全性が確保されていてもまだ、失敗から学ぶためには考慮すべき点（心理的な阻害要因など）があるとして、この点について説明されているところが興味深い。

• 失敗について「忌避」「混乱」「恐怖」する傾向がわれわれには存在する。これが失敗からの学習を妨げる。
  • 畑村先生の失敗学では日本人の特性として失敗を恥とする文化を挙げていたと思うが、本書では似て非なる整理がされている
• 本書は心理学的な観点から書かれており、各課題についての対策もちゃんと考察されていて参考になる（と言ってもリフレーミングなど、ではあるが）

心理的安全性はネーミングも含めて、いろいろな議論の尽きないテーマだった。その先の目標として、本書が言うような「失敗できる組織」が実現するできているのか。これは心理的安全性よりもわかりやすく、良い整理の仕方だと思う。

失敗の分類がよかった

本書ではさまざまな形で失敗を分類している。世の中にはいろいろな整理の仕方があるようだが、本書の整理は明解で、考えるきっかけとして良いものだと感じている。

• 失敗：望んでいた成果から逸脱した結果
• ミス：＝過失。あらかじめ指定された基準（手順、ルール、方針など）から意図せずに逸脱すること
• 違反：個人が意図的にルールを逸脱すること
• 失敗の基本形
  • 賢い失敗：進歩に欠かすことのできない「良い失敗」
  • 基本的失敗：誤りやしくじりが原因で起こるもの
  • 複雑な失敗：複数の原因があり、不確実性が加わるもの

本書の前半ではこれらの分類についての説明が、豊富な事例として語られている。失敗好き（？）にはたまらない

そして名言の宝庫

というわけでなかなかに興味深い本なのだが、もう一つの注目点は本書が「失敗に関する名言」の宝庫ということだ。エピグラフをはじめとして、良い言葉がたくさん紹介されている。

個人的に好きなのはこれ。

「打たないシュートは100％入らない」（アイスホッケーのスーパースター、ウエイン・グレツキー）
失敗できる組織 第一章「正しい失敗」を求めて

というわけで、本書の感想はここまで。さて次は何を読もうかな。
引き続き気になっている本はこれ

• バイブコーディングを超えて ―AI時代を生き抜く開発者の未来
• ソフトウェア開発者のキャリアハンドブック ―キャリアの不確実性を進み続けるためのガイド
• アーキテクチャモダナイゼーション【リフロー型】 組織とビジネスの未来を設計する
• GROWTH――「脱」でも「親」でもない新成長論
• Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
• 責任あるソフトウェアエンジニアリング ―現実社会におけるGoogleのケーススタディとともに (オライリー・ジャパン)

「ソフトウェア開発者のキャリアハンドブック」（旧Being Geek）の更新点を確認

今年のはじめに発売された「ソフトウェア開発者のキャリアハンドブック ―キャリアの不確実性を進み続けるためのガイド」を読み始めている。この本はもともと「Being Geek ―ギークであり続けるためのキャリア戦略」だったものの改定版だ。目次を見ながら更新点をチェックした、という話。原著でいえば旧著は2010年、新著は2023年に発売されたものだ。

ソフトウェア開発者のキャリアハンドブック ―キャリアの不確実性を進み続けるためのガイド

Being Geek ―ギークであり続けるためのキャリア戦略

今回の新版には、新たに8つの章を加え、「ギーク」という言葉はほぼすべて排除した。それは思っていたよりも簡単なことだった。元来、リーダーシップに強い関心のある人間が書いた本だったのもあり、「ギーク」という言葉を単純に「エンジニア」や「リーダー」に置き換えるだけであとは何の修正もいらないということがほとんどだった。旧版にはあったが、時代の変化に合っていないなと感じた章をいくつか削ってもいる。技術の進歩もあり、古くなって時代に合わなくなった記述を修正した箇所もある。
ソフトウェア開発者のキャリアハンドブック ―キャリアの不確実性を進み続けるためのガイド はじめに、より

追加された8つの章

冒頭のはじめに、で8つの章が追加されたとあったので目次をながめて特定した。おそらく以下が該当する

1. 第8章 集中力：集中力の重要性に関する短い文章
2. 第23章 暗黙の役割：リーダーという役割には、明文化されずに求められるものがあるという話
3. 第24章 人に親切に：マネージャーには３つの役割（リーダー、フィクサー、コーチ）がある
4. 第28章 私たちが失ったもの：コロナ禍以降に「リアルの価値」が失われたという話
5. 第35章 やっていないことリスト：インポスター症候群対策について
6. 第36章 意思決定は焦らずに：決断が早いほどいいというのは正しくない
7. 第37章 ともかく決断する：それでも決断しなければならない時はある
8. 第44章 ソーホースクエアのチェロ：卓越（Sティア）を目指すことについて

最初に本書が書かれたのは2010年で、もちろんコロナ禍前だ。著者はその後にSlack、Pinterest、Appleなどのテック企業を経ているという変化もある。そう考えると、意外と追加された章は少ないという気もする。むしろ既存の章の中身が変化しているのかもしれないが、そこまで細かく読んでいないというところだ。今後チェックしてみたい。

本書をつまみ食いしながら考えたこと

本書の初版であるBeing Geekが発売されたころはまだソフトウェア業界が十分に成熟していないこともあって、特にITエンジニアの多くがマネジメントの道を進むべきなのか悩んでいた。というわけでこの本はすごい興味深かった。このあたりは、初版Being Geekの「推薦の言葉」からも読み取れる。

推薦の言葉

ソフトウェア開発者のための書籍と言えばまず思い浮かぶのは技術書だが、本書では技術書では触れられないような、上司や同僚、さらには自分が働いている会社そのものの評価の仕方や、面接や転職、条件交渉等に関する各種ティップスが紹介されている。本書はキャリア形成や現在の職場に関する悩みを抱えるエンジニアが自分自身の状況に対する客観的な視点を得ることを手助けしてくれる書籍であると言えるだろう。

• • 小野 和俊（アプレッソ 代表取締役副社長 CTO）

ギークって何だろう。ギークになるにはどうしたらいいのだろう。そしてギークでありつづけるには。技術者がどのようにキャリアを築くのか。そのような悩みに本書は正面から答えようとしている。キャリアの形成、マネージメント、日々の仕事に必要なスキル、転職などについて記されている。「自分は次にどうすべきか」について考えるヒントに満ちている。

• • よしおか ひろたか

エンジニアとして世の中を生きるための指南書。技術・マネージメント・キャリア・転職、漠然と思っていたことが、この本を通してかみ砕いて理解することができ、エンジニアとしての生き方についてじっくり考えさせられた。

• • 舘野祐一（クックパッド）

しかし現代ではITエンジニアのキャリアパスについては、良質な書籍から様々な先達のインタビューまで、多様な情報にあふれている。そういう意味では、いまから読む本として本書がオススメなのかというのは若干悩ましいところだ。著者によるNetscapeやBorlandでの話は興味深いのだけれども、そういった企業を知らない人も多いだろう。と、本書の差分を読みながら考えたりしたのだった。