技術とマネジメントのあいだで　B332『アジャイルサムライ−達人開発者への道』（Jonathan Rasmusson）

  1. Home
  2. ≫
  3. ブログ
  4. ≫
  5. 読書記録
  6. ≫
  7. 技術とマネジメントの...

　2025-10-12 (日)　タグ：

Jonathan Rasmusson (著)
オーム社 (2011/7/16)

次は『LeanとDevOpsの科学』を読もうと思っていたけれども、少し息抜きがてらこちらの本を読むことに。

というか、アジャイルのこともろくに理解していないのでこっちが先かなと。

本屋でアジャイル関係の本をあさって悩んだ挙げ句これにしたんだけど、まぁまぁ良い選択だったと思う。数ヶ月前に本屋でみた時は本のタイトルから中級者以上向けだと思っていたけれども、今の自分にちょうどよい入門書だった。
（アジャイルにもいくつかの言葉遣いの違う流派があるようだけど、スクラムという言葉は体育会系的な匂いがしてあまり好みじゃないので避けた）

さて、本書に出てくるアジャイルに関する言葉をざっとAIにまとめてもらおう。

『アジャイルサムライ』に見られる用語の構成案とその意味（XP寄りの語彙を中心に）

I. アジャイル入門 ～ アジャイル全体の枠組み

  • アジャイル（Agile）
     変化を前提としつつ、小さく早く価値を届けながら適応していく開発の思想。
  • XP（Extreme Programming）
     アジャイルの技術実践重視の流派。著者は「可能な限りXP用語を使う」と書いている。pele-easj.dk
     「スクラム」よりも、コード実践・品質維持を重視する文脈で語られる。
  • イテレーション（Iteration）
     短い期間で機能を完成させ、顧客への価値提供とフィードバックを得るサイクル。
  • 顧客／関係者の参画（Engaged Customer）
     開発チームと距離を近く持ち、フィードバック・方向修正に関与する顧客。Zenn
  • インセプションデッキ（Inception Deck）
     プロジェクト着手前に共有すべき要素を問いとして整理するためのツール。方向づけを作る。

II. 方向づけ・計画づくりに関する用語

  • ユーザーストーリー（User Story）
     “誰が・何を・なぜ”を簡潔に記述する機能単位。要求仕様を小さな価値単位に分割する。
  • 見積り（Estimation）
     漠然とした要求を数値化／スコープ化する。アジャイルでは見積りは精密さよりも予測可能性・調整性を重視。
  • 計画づくり（Agile Planning）
     要求とリスクの変化を前提にして、優先順位付け、スコープ調整、バックログ管理を繰り返すプロセス。

III. プロジェクト運営・コミュニケーション

  • イテレーション運営（Iteration Management）
     スプリントの開始から終わりまで、チームを導き、進めていく実務の技法。
  • アジャイルな意思疎通（Agile Communication）
     距離を縮めた対話、コラボレーション、透明性を重視するコミュニケーションの設計。
  • 可視化（Visible Work / Visual Management）
     タスクボードなどで仕事の状態を見える化する。進捗やボトルネックを自覚できるようにする。

IV. 技術実践（XP的プラクティス）

  • ユニットテスト（Unit Testing）
     コードレベルで機能を検証する最小単位のテスト。品質保証と設計改善の基盤。
  • リファクタリング（Refactoring）
     機能を変えずにコードの内部構造を改善すること。技術負債を減らし、将来の変更に強くする。
  • テスト駆動開発（Test-Driven Development, TDD）
     テスト→コード→リファクタリング という順序で実装を進める方法。テストファーストの技法。
  • 継続的インテグレーション（Continuous Integration）
     頻繁に（毎日・数回／日）コードを統合し、テストを自動で走らせる。統合障害を早期に検知する。
  • 共同所有（Collective Ownership）
     コードの所有権をチーム全体で持つ。誰でもどこでも変更できるようにする。
  • シンプル設計（Simple Design）
     今必要な最低限の設計を採用し、不必要な複雑化を避ける。将来の変化に備えて柔軟に保つ。
  • 継続的リリース／小リリース（Small Releases）
     大きなリリースを待たず、小さく頻繁に成果を出し続ける。

V. 原則・価値観

  • 価値（Values）
     XPでは典型的に「Communication（コミュニケーション）」「Simplicity（単純性）」「Feedback（フィードバック）」「Courage（勇気）」「Respect（尊敬）」が掲げられる。ウィキペディア+1
  • 原則（Principles）
     価値を現実化するための判断規範。たとえば「早くフィードバックを得る」「変化を受け入れる（Embrace Change）」など。
  • 変化を受け入れる（Embracing Change）
     要求や環境が変わることを拒むのではなく、前提として受け止め、設計や優先順位を変えていく態度。
  • 最小限設計（You Aren’t Gonna Need It, YAGNI）
     将来必要になるかもしれないからという理由で拡張的設計をしない、という原則。
  • 技術的負債（Technical Debt）
     短期的な選択が将来のコストを生むこと。その負債を可視化し、定期的に解消する。

VI. 用語対応と注意点

  • 本書では「イテレーション」がスプリントと同義で使われることが多い（スクラム用語よりもXP語彙）
  • “マスターストーリーリスト”という用語が出る（プロダクトバックログ相当）
  • 本書の語彙は「実践視点」に寄せられていて、豪華な理論ではなく現場で使える語彙が多め

さて、なんとなくアジャイルの進め方やポイントのイメージはつかめたし、やはりXP寄りの言葉の方が自分の好みだ。（ただし、実践経験がないので、まだイメージの段階）

これまでの開発で問題になっているところもなんとなく掴めた。

インセプションデッキを作成したり、ユニットテストやリファクタリング、テスト駆動開発、継続的インテグレーションなどの試してみたいこともいろいろある。

また、もう少し詳しく知りたいという技術面での文献もかなり増えた。（こうして羅列してみると、この分野に関して自分がいかに素人かを実感する）

組織に関する知識と技術に関する知識。

これらは車の両輪だと思うけれども、どちらも素人に毛が生えた程度。

両方一度にマスターするのは現実的ではないし、そのための時間をとても捻出できそうにない。（そもそも両方を同時に実践することは構造的に無理があるように思う）

ここ最近はその負荷の大きさを実感する場面も増えていて、正直、このままではどちらの輪も回らなくなってしまいそうだ。
魅力的なプロジェクトが次々と動き出している今だからこそ、うまく回らなくなるのは避けたい。
せっかくの面白い仕事を、構造の問題で止めてしまうのは本意ではない。

個人的には技術的な研鑽を積んでどんどんアウトプットを出していく方が断然性に合っている。
とはいえ、組織づくりやマネジメントも避けて通れないテーマではある。

しばらくは少しずつでも両輪を回していこうと思うけれども、
できることなら――しっかりとしたPMやCTOのもとで、
開発に没頭できる環境で力を発揮したい、というのが正直なところだ。




僕は最適な環境をそれほど求めてはいないのかもしれない »
« 骨格と血流の設計　B331『チームトポロジー 価値あるソフトウ...


関連性の高い記事

B091 『藤森照信の原・現代住宅再見〈2〉』
新たにシステムを始動させる　B254 『メタアーキテクト──次世代のための建築』（秋吉浩気）
B116 『WordPress 2.2でつくる!最強のブログサイト』
B117 『藤森流 自然素材の使い方』