技術ブログやエンジニアセミナーなど、ソフトウェア開発に必要な情報を得る機会はたくさんありますが、系統だった知識をまとめて学ぶなら「本」は依然として便利ですし、繰り返し参照するにも適しています。
また本には人生を変える力があり、多くのエンジニアが書籍から知識を得るだけでなく、本と向き合うことでやり方や考え方を見つめ直しています。今回はAgile Journeyと関係のある8人の開発者に、エンジニアとして壁を乗り越え、アジャイルに取り組む契機になるような自分にとって大切な本を推薦してもらいました。
紹介する中には現在では入手の難しい本もありますが、機会があればぜひ手に取ってみてください。
- アジャイルやXP・スクラムをどう実践すればいいのだろう？
- ソフトウェア開発を成功させるにはたくさんの知識が必要だ
- 別の視点からアジャイルを見ると新しい発見があるかも
- あなたはどんな本と出会いますか？
- 合わせて読みたい注目記事
※ それぞれの書籍は基本的に出版社の書籍紹介ページを参照しますが、絶版やリンク切れなどの場合にはCiNii（国立情報学研究所 学術情報ナビゲータ）の書誌情報にリンクしています。
アジャイルやXP・スクラムをどう実践すればいいのだろう？
ここではタイトルに「アジャイル」や「XP」「スクラム」を冠する6タイトルを紹介します。初めてアジャイルに取り組むときに不安を解消し、具体的な進め方を教えてくれた本が選ばれています。
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
オーム社Recommender: 吉羽龍太郎（@ryuzee）さん（アジャイルコーチ）
本書を初めて読んだのは2008年ごろでした。当時私は大手SIerで企業向けのWebシステムを作る仕事に従事していたのですが、ウォーターフォール型の仕事のやり方からアジャイルへの移行を数年がかりで進めている途中でした。当時のSIerでアジャイルというと、一部の研究開発部門での取り組みや実験レベルでの試行が多かったのですが、自分たちは顧客の理解もあり、早い段階で実際のプロジェクトに適用を進めていました。もちろん全てがうまくいったかというと、全くそんなことはなく、試行錯誤の日々でした。当時、自分は技術系コミュニティに参加することもなく、知識の多くはインターネットや書籍から得ていて、そこで出会ったのが本書です。
本書では、スクラムやXPなどのフレームワークを体系的に説明するのではなく、アジャイルを実践するときに活用できるさまざまなプラクティスを45個紹介しています（自分が好きなのは「1. 成果をあげるのが仕事」、「6. チームに投資する」、「13. いつでもリリースできるようにしておく」、「23. ありのままの進捗を計測する」、「39. アーキテクトもコードを書くべき」です）。プラクティスはそれぞれ数ページで紹介され、互いに独立しているので、どのページからでも読むことができます。このコメントを書くにあたって再読しましたが、多くの内容は現在でもそのまま当てはまり、役に立ちます。
私自身はよく本書を職場の自席で読んでいました。適当にめくって出てきたページを読んで思考にふけることもあれば、自分たちの仕事のやり方を決めるときのリファレンスとして読むこともありました。簡潔で非常に読みやすい本なので、日々のお供になったことを覚えています。
仕事のやり方をもっとアジャイルにしたいと思っていても、さまざまな制約からいきなりスクラムなどのフレームワークを適用できるとは限りませんし、それが絶対に良い方法というわけでもありません。自分たちが置かれている状況を踏まえて、少しずつより良い方法を見つけ出そうとすること自体がとても重要です。本書はそのときのヒントになります。古い本ですが、手元に置いて時間のあるときにめくってみると、いろいろと気づきがあると思います。
参考：Agile Journeyにおける吉羽さんの出演記事「アジャイルコーチはなにをコーチングするのか？ 吉羽龍太郎さんに聞く、組織にアジャイルを取り入れるアプローチ」
アジャイルな見積もりと計画づくり 価値あるソフトウェアを育てる概念と技法
アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法
マイナビ出版Recommender: 粕谷大輔（@daiksy）さん（エンジニアリングマネージャ ）
この本は書名の通り、アジャイル開発における見積もりの仕方や考え方、開発全般の計画づくりについて書かれた本です。
2012年に人生で初めてアジャイル開発（XPをベースにしていました）に取り組んでいるチームで仕事をすることになり、そのときの上司に薦められて読んだのが最初です。以来、折に触れて何度も読み返した本でもあります。自分の蔵書の中で、再読した回数が最も多い本かもしれません。
転職の際に再学習するとき、スクラムマスターとして仕事をすることになったとき、開発チームのマネージャーになったとき、自著を執筆するときに参考文献としてなど、何度も読み返し、そのたびに新しい発見や気付きがありました。
世間では、計画に重きを置く従来型の開発手法に対して、アジャイルは規模の大きな開発や長期間に渡る開発には向かない、といった言説をたびたび見かけますが、そんなことはありません。アジャイルだからといって計画をしないことはなく、この本を読めばそういった疑問は全て解決します。
「アジャイル」という書名ではありますが、アジャイル開発に閉じることなく、計画的に仕事をする上で誰もが読んで損はないでしょう。発行が2009年と少し古い本ではありますが、いまだに全く色褪せない名著だと思います。
参考：出演記事「アジャイルリーダーシップの実践 - 権力ではなく影響力でアジャイルな組織をつくるために【対談】
塹壕よりScrumとXP
塹壕よりScrumとXP
InfoQRecommender: 永瀬美穂（@miholovesq.bsky.social）さん（アジャイルコーチ）
著者のHenrik Kniberg氏は、現在では生成AI系の企業を経営していますが、以前はMinecraftやSpotify、LEGOといった会社でコーチングをしてきました。Spotifyモデルでも有名で、日本語訳された『リーン開発の現場』（オーム社、2013）の原著者でもあります。
本書は、わたしが初めてのアジャイル開発を実践した15年前に参考にした電子書籍です。当時は実践事例が多くはなく、リアルワールドの事例がありありと伝わるようなこの物語が大変役に立ちました。無料PDFが配布されているので印刷してボロボロになるまで何度も読み込み、初めてアジャイル開発に挑戦するチームで読書会をし、上司や周囲に啓蒙するためのツールとしても使わせてもらいました。
運営するRegional Scrum Gathering Tokyoの第1回目にはHenrikを基調講演者として招聘し、本書を冊子にして参加者へのノベルティとして配布しました。今読むとスクラム用語などが最新でなかったり古びたプラクティスもありますが、チームが生き生きと自分たちの仕事を工夫していく様子は、自分の現場がうまくいっていない読者にとってはとても勇気づけられるものだと思います。
これの日本語版を作りたいという動機が、自著『SCRUM BOOT CAMP THE BOOK』を執筆するきっかけの1つにもなりました。
▶️ リーン開発の現場 カンバンによる大規模プロジェクトの運営 オーム社
▶️ SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 翔泳社
参考：出演記事「大学のアジャイル教育に奮闘した10年からの学び─短期の集中授業でアジャイルをどう実践するか？
アジャイルと規律 ソフトウエア開発を成功させる2つの鍵のバランス／アジャイルイントロダクション Agile開発の光と影
アジャイルと規律 ソフトウエア開発を成功させる2つの鍵のバランス
CiNiiRecommender: 和田卓人（@t_wada）さん（テスト駆動開発実践者）
書籍『アジャイルと規律』は、私が2004年に千人規模の大規模プロジェクトから4人のチームに移籍して、開発者だけでなくアジャイルコーチを始めたときに特に読み込んだ本です。当時はまだアジャイルソフトウェア開発は一般的でなく、伝統的な計画主導のアプローチに対する一種のアンチテーゼとしてもてはやされていました。
本書はアジャイルソフトウェア開発を持ち上げることなく、さりとて伝統的な計画主導アプローチを持ち上げることもなく、プロジェクトを規模（Size）・重要度（Criticality）・変化の度合い（Dynamism）・人（Personnel）・文化（Culture）の5つの軸で捉えて、アジャイルさ（Agility）と規律（Discipline）のバランスをどうやって取るのかを論じています。
冷静にアジャイルソフトウェア開発と計画主導アプローチの強みと弱みを比較し、どういうときにアジャイルが機能するのかをアジャイルムーブメントの外部の視点から記しているこの書籍は、コーチとして自己相対化を行う際にたいへん参考になりました。
和田さんにはもう1冊紹介いただいています。
今回紹介した『アジャイルと規律』は遙か昔に絶版になっており、入手が難しい状態です。いま手に入る書籍の中から「冷静にアジャイルの強みと弱みを分析し、どういうときに機能するのかをアジャイルムーブメントの外部の視点から記している」という観点で1冊選ぶとするならば、『アジャイルイントロダクション：Agile開発の光と影』をおすすめします。
オブジェクト指向プログラミング言語Eiffelを開発し、「契約による設計」という設計テクニックを生み出したBertrand Meyer博士が、アジャイルの「難点」「誇張」「利点」「非常にすばらしいこと」をムーブメントの外側の立場からまとめています。
アジャイルイントロダクション Agile開発の光と影
近代科学社参考：出演記事「テスト駆動開発のはじめの一歩｜t_wadaさんに聞く1人で始める自動テストのコツと考え方」
XPエクストリーム・プログラミング 適用編 ビジネスで勝つためのXP
XPエクストリーム・プログラミング 適用編 ビジネスで勝つためのXP
CiNiiRecommender: 林尚之（ユーザベース スピーダ事業CTO、Agile Journey編集長）
エンジニア2年目の2005年くらいに初めて手に取ったと思います。XPという開発手法があることを知って、白本（ケント・ベック『XPエクストリーム・プログラミング入門』※）の読了後くらいに読みました。
この本は「適用編」と書いてあるように、「XPを現場でいかに適用するか、どうやれば適用できるのか」を解説してくれます。なので、XPを1人で実践したり、チームで実践したりする際に何度も何度も読み返した記憶があります。「XPやアジャイルを勉強するために読んだ方がよい本があれば教えてください」と言われたら最初に答える本です。
その頃はXPやアジャイルの黎明期だったため「なぜXP（アジャイル）をやるのか？」をしっかりと説明してくれており、そういう意味でもおすすめできます。最近のアジャイル関連の本はどちらかというとHow寄りが多いのですが、この頃の本はWhyをしっかりと説明してくれています（今の本が悪いわけではないです）。
20年以上前の本なので、時代背景の違いからあまり参考にできない部分も多少ありますが、XPやアジャイルの本質を捉えているので今読んでも得るものは多いと思います。特に、今からXPやアジャイルをチームに浸透させたいと思っている人たちにはうってつけだと思います。
※ ケント・ベック『Extreme Programming Explained: Embrace Change』は何回か日本語訳が出版されています。そのうち『XPエクストリーム・プログラミング入門』というタイトルの初版と第2版旧訳の書誌情報は下記を参照してください。
参考：執筆記事「1人アジャイル」から始める、アジャイル開発導入のススメ｜Agile Journeyローンチによせて
ソフトウェア開発を成功させるにはたくさんの知識が必要だ
ここではソフトウェア開発に必要なさまざまな領域から、3タイトルを紹介しています。なおテスト駆動開発はXPのプラクティスですが、アジャイルではない現場でも始められるのでこのセクションに含めています。
デッドライン ソフト開発を成功に導く101の法則
デッドライン ソフト開発を成功に導く101の法則
日経BPRecommender: 曽根壮大（@soudai1025）さん（合同会社Have Fun Tech代表、株式会社リンケージCTO）
デマルコといえば『ピープルウェア』という印象の人も多いのではないでしょうか。でも、あえて『デッドライン』を勧めたいと思います。
『デッドライン』は「プロジェクトマネジメントのコツ」を、小説のようにストーリを進めながら紹介していく本です。この中で紹介されるプロジェクトマネジメントのコツは、25年たった今も現役で活用できる示唆に富む内容です。
この本を読んだことがない人は、必ず一度は読んでみてください。新卒の人からすると、プロジェクトマネジメントは想像できなくて、読んでも「そうか」と流し読みで終わるかもしれません。でもあなたの人生の中で、この本に出てきた課題とぶつかるときが必ずあります。
なので、以下のようなタイミングでぜひ読み直してほしい本です。
- プロジェクトのキックオフや大きなリリースなどの節目
- プロジェクトマネジメントに迷ったとき
- 転職したり、昇進するなどキャリアの節目
- 後輩や部下にプロジェクトマネジメントをアドバイスするような立場になったとき
私も何度もこの本を読み直しました。そのたびにたくさんのことに気付かされます。この週末もこの記事で紹介するために読みましたが、仕事を覚えれば覚えるほど解像度が上がり、新しい気付きを見つけることができますし、書いてあることの理解度が上がります。
▶️ ピープルウエア 第3版 日経BOOKプラス
参考：執筆記事アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと
テスト駆動開発入門
テスト駆動開発入門
CiNiiRecommender: 安井力（@yattom）さん（合同会社やっとむ屋代表、アジャイルコーチ）
私が新卒でSIerに就職したのが1998年、そのころ流行のオブジェクト指向設計、UML、モデリングやパターンなどを一生懸命勉強して、完璧な設計を目指していました。その少し後からXPやアジャイルが話題になり始めます。
そこで出会ったXPや、テスト・ファースト、そして本書『テスト駆動開発入門』はある種の衝撃でした。テストを書いてコードを書いて、設計は後から少しずつしていけばいいのだと。事前の完璧な設計は？ 美しいモデルは？ 設計書と作業分担なしでプロジェクトを進めるだって!?
一方で、これは良いやり方だと直感しました。実は手癖のように、コードを少し書いて動かしてみる、動かすためにちっちゃなコード（つまりテストコード）を書く、正しい結果が出るまでコードをいじり回すというやり方もしていました。イケナイことだなーと思っていたのですが、ケント・ベックはむしろそうしなさい、ただしもっと洗練されたやり方をしなさいと言ってきたわけです。レッド・グリーン・リファクタリングという手順、テストコードを資産にする規律、設計をコードとともに進化させるという手法です。
仕事の中でテスト駆動開発（TDD）を練習し、実践していくと、さらに驚くことが起きました。TDDでちゃんと動作するコードが完成する、しかも事前に考えた設計よりも、より必要十分で分かりやすい設計になるのです。完成したコードからUMLクラス図を起こして、これでいいの？ と眺めたら……これでちょうどよかったのです（なおWeb 2.0とかエンタープライジーなJavaや.NET Framework 1.0の時代です）。
TDDはさらに、やり方・考え方全般に影響しました。最終的なゴールを精緻に設定して計画し、後はひたすら働くというスタイルから、より近いゴールを徐々に設定し（レッド）、素早く達成し（グリーンとリファクタリング）、目指す方向を再確認する（次のテストケースを見つける）というスタイルに変わっていったのです。私にとってはテスト駆動開発がアジャイルへの門となりました。
プログラミングをする人であれば、アジャイルとは関係なく、今でも役に立つ内容だと思います。オーム社と和田卓人さんのおかげで、今でも容易に入手できます※。
著者のケント・ベックの近著『Tidy First?』も話題になっています。これを機会に再注目されたらいいですね。20年間でケント・ベックの考え方がどう変遷したのか考察するのも面白そうです。
▶️ Tidy First? 個人で実践する経験主義的ソフトウェア設計 オライリー・ジャパン
※『テスト駆動開発入門』の原書を和田卓人さんが訳し直した『テスト駆動開発』が2017年に出版されています*1。
テスト駆動開発
オーム社参考：執筆記事スコープ管理と調整技法を安井力が解説 - 開発チームが信頼を獲得し変化に対応するために
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
日本能率協会マネジメントセンターRecommender: 岸田篤樹（@pauli_agile）さん（エンジニアリングマネージャー、スクラムマスター、技術広報）
自分はスクラムチームのスクラムマスターから、 LeSSのスクラムマスターとなって複数チームを支援し、一定の自律性を保つことができました。 その後、これらを束ねるグループのマネージャーになり、さらに広い視野で見たときに、チーム同士が効果的かつ自発的に連携するにはどうすればよいかを考えました。また、チーム間で事業や技術的な知識に偏りができており、この環境下でアジャイルなチームに不可欠な「速いフロー」をどう実現するかが課題だと感じていました。
VUCAの世の中では、顧客価値を素早く、頻繁に、安定して届け、また障害を早期に復旧する必要があります。これを実現するため、先述のスクラムやLeSSのようなアジャイルソフトウェア開発の価値観やプラクティスを適用することでチームの練度を増していきましたが、この不確実性に適応する組織構造の考え方が自分の中に体系的にはありませんでした。
そんな時にこの『チームトポロジー』を購読し、チームを主軸に捉えたスケールドアジャイルとの親和性の高さから、さっそく開発部内に提案し、徐々に導入することにしました。
本書には、先述の「速いフロー」を阻害する要因や、どのようなパターンを適用することでこれを実現するのかのアプローチが記述されています。とくに、チームの構造と相互作用に焦点を当て、逆コンウェイ戦略をもとにした4つのチームタイプと3つのインタラクションモードにより、効果的なソフトウェア開発の促進を目指している点が特徴的です。
これにより、チームの認知負荷をどういった組織設計と連携で効果的な状態にし、またその変化をどう管理するのかを共通言語で語ることができました。
上記の整理で、私は（ここまで綺麗な整理ではないですが）それぞれ複数のストリームアラインドチームとプラットフォームチームのマネージャーであることを認識し、それぞれ事業・技術的な情報の溝およびそれに起因する連携不足が課題と捉えて直すことができました。 また、新たにこの組織を支援する、組織内でトップレベルの技術・マネジメント双方のスキルを有したイネイブリングチームを組成することで、組織全体のスキルの底上げや知識の平準化に寄与することができました。
現在では、この知識とパターン（およびモデリング手法）をもとに、関係者と組織戦略案の整理をすることができています。 チームのフローが担保できない、またチーム間の連携に課題感を感じている方は、このチームトポロジーを読むことで改善に向かうヒントとなるかと思います。
岸田さんからは関連してさらに3冊を紹介いただいています。
アジャイルソフトウェア開発宣言でも言及されている「対話」。組織内では計画やふりかえりなど、あらゆる場面で対話する機会があります。
しかし、対話そのものがうまくいかず、信頼関係を構築できなくて悩む方もいます。その「対話」をどのように考え、どのように実行すればいいのか？ これが体系的に説明されている1冊です。
▶️ Team Geek
チームで仕事する、またチームを構築するにあたり、必要な考え方がまとまっています。本書で紹介される「HRTの原則」は有名ですが、私がおすすめしたいのは、そのHRTの原則をもとに具体的に人、組織、その中での営みをどのように感じ、考えればよいのかが記されている点です。
例として「君は君の書いたコードではない」や、「有害な人」の問題は「その人自身」ではなく「その人の振る舞い」である点など、「人」に起因すると捉えられるおそれのある問題に対して否であると示されている点が好印象です。
自分たちが解決したい課題は何なのか？ またそれをどう設計・実装に落とし込むのか？ という点が整理されています。『チームトポロジー』とあわせて読むことで、解決したい課題とそれを実現する組織、その組織が何の範囲をどのような設計で開発するかがつながることが期待できます。
参考：執筆記事：後輩に提案されたスクラムにうまく適応できなかった私が開発チームのアジャイルを先導できるようになるまでに考え実践したこと
別の視点からアジャイルを見ると新しい発見があるかも
ここまでソフトウェア開発そのものの推薦本を紹介してきましたが、より広い視野からアジャイルについて考えさせられた書籍もあわせて推薦してもらいました。プラスアルファの5タイトルが集まりました。
リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす
リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす
日経BPRecommender: 林尚之
『リーンスタートアップ』で解説されているプロダクトに関する内容は、アジャイルと非常に親和性が高いです。むしろアジャイルな組織でなければ、リーンスタートアップを実践できないと感じます。素早くフィードバックサイクルを回しながら試行錯誤し、プロダクトマーケットフィットを目指す。この考えは開発者としてとても重要だと思っています。
また、リーンスタートアップは名前の通りスタートアップ企業に関する話ではあるのですが、「新しい価値をユーザーに届ける」という意味ではスタートアップでなくても新規プロダクト開発や、新機能開発時でも同じだと思うので、そういう場面でも大いに参考になると思っています。
ライト、ついてますか 問題発見の人間学／いかにして問題をとくか
ライト、ついてますか 問題発見の人間学
共立出版
いかにして問題をとくか
丸善出版Recommender: 曽根壮大さん
この2冊は、「問題と如何に向き合うか」という点で共通しています。アジャイルの本質は「正解がない世界で変化しながらゴールに向かっていく」ことです。そのときに必要な問題の見つけ方、問題の解き方に対して大切な視点を教えてくれます。
どちらも本としてはそれほど厚くなく、非常に読みやすい本なのでぜひ一度は読んでほしいですし、とくに新卒にはおすすめしたい本です。『デッドライン』同様に自分の経験が高まれば高まるほど読み直して新しい気付きを与えてくれますし、問題との向き合い方を考えさせられます。
銀河ヒッチハイク・ガイド
銀河ヒッチハイク・ガイド
Amazon.co.jpRecommender: 粕谷大輔さん
ダグラス・アダムスによって書かれた有名なSFコメディ小説です。Google検索に「人生宇宙すべての答え」と入力すると、計算結果として「42」が表示されるというイースターエッグがありますが、その元ネタになった作品です。とにかく発想が自由で、ユーモラスなキャラクターたちによるおかしなストーリーが展開します。
いつ読んだかは覚えていませんが、ちょうどコミュニティ活動を始めた直後に、そのきっかけの1つでもあったWebメディアの編集者とこの作品について盛り上がったことがあり、なんとなく自分のコミュニティ活動の原点としてよく思い出します。
アジャイルに関連した仕事をしていると「思考の枠組みを外す」ことがとても大事になるのですが、その時に「この本くらい自由な発想で枠を外してもいいのだ」と思い返します。実際、今回も「単純にアジャイルの勉強になった本を紹介しても面白くないな」と思ったので、思考の枠を外して考えようとしたときに「まさに自分が思考の枠を外すときに思い返す本があるじゃないか」と思い至ったのでした。
もっと思考の枠組みを外したい
最近も、枠に囚われ過ぎている自分を反省する機会が多くありました。年齢も40代中盤になり、会社でもそれなりに責任のあるポジションで仕事をすることが増えました。そうすると、マネージャーとしてあるべき姿やふるまい、40代中盤の社会人としての模範的な態度、といったものを気にし過ぎてしまい、とても自分が窮屈な状態であることに気づきました。
そういった気づきを得て「今こそ思考の枠を外して、あまりそういったことに囚われず、多少は自分の好きにしたらいいのではないか」と思うようになりました。今回この本を紹介したのは「このように思い切って自由な発想を持って、周囲の目を気にせずちょっとくらい好きにふるまってもいいんじゃないの」と思ったからでした。
あわてるな！ 現在は安原和見による新訳が刊行されています。
▶️ 銀河ヒッチハイク・ガイド 河出書房新社
上達論 基本を基本から検討する
上達論 基本を基本から検討する
PHP研究所Recommender: 安井力さん
基本の難しさ
スクラムの研修などでよく「守破離」という言葉が紹介されます。学習や成長の段階において、最初は指導通り、書いてある通り、真似るようにやりなさいと「守」を強調されることが多いと思います。
一方、本書では、基本を繰り返し練習する、素振りのようなアプローチを否定しています。
同じ状況は二度なく常に初見であり、初めての状況に対応できる力が大事なのだ。「正しいやり方」を練習で学んでしまうと初見への対応力を減じてしまう、そう説いています。
大事なのは、とにかく「体験してみる」事です。……そして「大づかみ」にでも情報を捉えることです。
これは稽古で言うと、まず「技を受ける」という事です。〔十一、技を「受ける」 より〕
……むしろ「理解をしていない」事こそが有効に作用する部分があるのです。……「理解をしていない」とは「解釈をしていない」という事です。〔十二、理解と吸収 より〕
「解釈」というのは……「元の情報」を変形させてしまっている……という事は、元の情報が「劣化」しています。〔十三、日本語英語 より〕
アジャイルソフトウェア開発において、朝会・ペアプログラミング・計画づくり・改善・仮説検証など、さまざまな場面があります。正しいやり方、この通りにやればうまくというやり方は、ありません。朝会のやり方が決まっていても、同じ状況で同じ話をする日は二度とありません。そんな毎回異なるものを、どうしたらうまくできるようになるのか。それには原理原則を知ることと、実践・実戦の中で練習し、体験から吸収することです。
「原則」とは何か。
それは、これまで生み出されてきた無数の技を貫く、一定の「秩序」と「共通点」〔二、原則 より〕
正解はない、しかしなんでも闇雲にやればいいかというと、そうではない。原則や原理があると言います。それが学ぶべき、身に付けるべき基本だというわけです。決まったやり方ではない。アジャイルソフトウェア開発宣言とその背後にある12の原則を思い出します。
まず人間ありき
本書は全112章を通じて、甲野善紀の古武術指導法や哲学を説明しています。私自身は古武術も格闘技も分からないのですが、しかし理解できる気がする、アジャイルと通ずると思えるところもたくさんありました。
「プロセスやツールよりも個人と対話を価値とする」と、アジャイルソフトウェア開発宣言にあります。そして背後にある12の原則は「顧客満足を最優先し」から始まります。まず個人、そして個人間のやりとりである対話に価値を置く。そしてもっとも重視する個人は、顧客あるいはユーザーです。ユーザーをはじめとする人と、人々のやりとりを大切にするのが、アジャイルの価値観です。
本書は古武術、武術を取り扱っているので、必ず自分という人間があり、相手の人間がいます。そこからアジャイルとの共通点が生じているのかもしれません。
この世界は、脳の飛距離＝「創造性」が切り開いているのです。……
……「現代の武術家は技を覚えるばかりで、作ろうとしないのが問題だ」……
……「武術」こそ本来「創造性」が発揮されるべき分野だからです。〔三十一、飛距離 より〕
アジャイルとは、ソフトウェア開発において創造性を発揮するためのアプローチでありマインドセットです。決まった正しいやり方、プロセスやツールをできるようになることではない、むしろ反対だなあとも思えます。それこそが人間だからこそできることなのかもしれないと、私には思えます。
誰に勧めるのか、なぜ勧めるのか
さて、本書はソフトウェア開発とも、ましてアジャイルともなんの関わりもありません。それをなぜ紹介しているのか。私はアジャイルコーチとして10年以上働いていますが、どこかに「自分はアジャイルできる」という意識があるように思えます。
しかし、アジャイルはユーザーと「組み合って」創造力を発揮することだと考えてみると、「アジャイルをできていない」気持ちが生じました。正直、楽しくないなと。本書がひとつのきっかけとなり、ユーザー価値を自分の手で削り出していく、ユーザーに直接向き合うアジャイルなプログラマーとして、考え方と態度がアジャイルである方がうれしいかなと思うようになりました。
この本をどんな人に勧めたらよいのか、私には見当がつきませんが、私の今に響いて、基本を考え直すきっかけになったのは確かです。
基本という意味では、まず「アジャイルソフトウェア開発宣言」や「スクラムガイド」そして『エクストリームプログラミング』を圧倒的に勧めます。そうした基本を押さえている誰かに、今この本が響くことがあるかもしれません。そんな微かな可能性に期待しています。それに「必要だから」ではなく「発見があるかもしれないから」というのは、とてもアジャイル的なんじゃないかなと思っています。
現在は『エクストリームプログラミング』第2版新訳が流通しています。
エクストリームプログラミング
オーム社あなたはどんな本と出会いますか？
この記事が、ソフトウェア開発やアジャイルに対する考えを深めるヒントになれば幸いです。もしよければみなさんも開発者として壁にぶち当たったり行動を見直したいと考えたりしたときに出会った本を、技術ブログやはてなブックマークのコメント、各種SNSなどでぜひ紹介してください。
編集・制作：はてな編集部
*1:参考：t-wadaのブログ「新訳版『テスト駆動開発』が出ます」
