MEGUMI SHIMABUKURO

普段スクラムで開発してるが、XPについてはあまり知らなかったので読んでみた。この本は1999年に書かれた本だけど、今読んでも全く不自然じゃないし（むしろ今でも刺さる内容がたくさんあった）、この考え方を20年以上前の開発者がすでに編み出していたと思うと本当にすごい。とてもいい内容だったので、古い本だけどまだ読んだことない人にはとてもおすすめしたい一冊。

エクストリームプログラミング | Ohmsha

優れた技術力と良好な人間関係をもってしてソフトウェア開発を成功に導く、ケント・ベックによるXP（エクストリームプログラミング）のすべてを集約した名著 “Extreme Programming Explained: Embrace Change” の新訳版。アジャイル開発の原点を知る、必読の一冊です。

https://www.ohmsha.co.jp

以下、各章ごとの感想とメモ

タイトル通り、XPとは何かについて書かれた章。章の最後に以下のように書かれていた。

• XPとは、効果のない技術的／社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである。
• XPとは、自分が今日やるべきことを十分に理解することである。
• XPとは、明日をよりよくしようとすることである。
• XPとは、チームのゴールに貢献した自分を評価することである。
• XPとは、ソフトウェア開発で人間としての欲求を満たすことである。

抽象的な説明が多かったので、よくわからなかった箇所も多々あったが、後続の章に詳しく書いてそうなので読み進めると良さそう。読み終わったときに、なぜXPが経済的に有効なのか、チームよってXPのやり方も成功の度合いも違う、とはどういうことか、XPとはなんぞや、という問いに答えられるようになっておきたい。

XPとは何なのかを運転に例えた説明が書かれた章。地平線を目指して運転してるとどこに進んでるかわからなくなるので、注意して運転しつつ、次にどこに向かうかを毎週考えることは重要。何がゴールに近づけて、何がゴールから遠ざけるかわかるようにするのが大事、といった感じのことが書かれた章。

XPを運転に例えた説明わかりやすいなと思った。

「運転というのはね、車を正しい方向に走らせることじゃないの。常に注意を払って、こっちに行ったら少し戻して、あっちに行ったら少し戻して、そうやって軌道修正していくものよ」

XPは、価値、原則、プラックティスの3つの要素で構成されてるらしく、この３つの関係性について書かれてた章。

この章も抽象度が高くて、価値、原則、プラックティスの関係について、一読だとよくわからなかった。各要素の具体例を知ってから読み返すと理解が深まりそうだと思った。

価値について書かれた章。価値とは、チームにとって大切なこと。

3章で、急に「価値、原則、プラクティス」という言葉が出てきて理解できなかったけど、この章で「価値」について詳しく説明があり深掘りできてよかった。実践しつつ繰り返し読み返したい。

XPで開発する時の重要な価値

• コミュニケーション
• シンプリシティ
• フィードバック
• 勇気
• リスペクト

価値は抽象度が高いので指針となる原則が必要。原則について書かれた章。

原則は、価値を守るためのガイドラインというようなイメージ。XPの価値を守るために何をしたら良いのか迷ったときに読み返すと良さそう。原則は結構多いが、個人的に好きだったのは「失敗」の原則。議論自体に時間をかけるより、失敗のリスクを受け入れて実行した方が速いということが書かれてる。他にもXPな振る舞いをするための原則が書かれているので、読んでて勉強になった。

XPの原則

• 人間性
• 経済性
• 相互利益
• 自己類似性
• 改善
• 多様性
• ふりかえり
• 流れ（デリバリー）
• 機会（問題は改善・学習の機会）
• 冗長性
• 失敗
• 品質
• ベイビーステップ
• 責任の引き受け

XPのプラクティスについて書かれた章。XPをどう実践するか書かれていて、プラックティスは、主要プラクティスと導出プラクティスがある。

XPを実践する際に読み返すと良さそう。個人的に良いと思ったプラックティスを挙げると、開発者は目の前のストーリーに集中しちゃうので、四半期の計画を振り返った方がいい や 計画が遅れた時に外せるような優先度の低いタスクも計画に含めた方がいい（slack）など良さそうだと思った。他にも実践していきたいプラックティスがたくさん紹介されていたので迷った時に読み返したい。

XPのプラックティス

• 全員同席
• チーム全体
• 情報満載のワークスペース
• イキイキとした仕事
• ペアプログラミング
• ストーリー
• 週次サイクル
• 四半期サイクル
• ゆとり
• 10分ビルド
• 継続的インテグレーション
• テストファーストプログラミング
• インクリメンタルな設計

XPの始め方について書かれた章。この章以前の章で、XPの価値、原則、プラックティスについてわかったので、この章では実際にはじめてみる場合どうしたらいいか書かれてる。

スクラムに似てるなと思ったが、スクラムもXPもアジャイルな考え方がベースにあるので似てるのはそれはそうという感じかもしれない。XPは、自分一人でも始めることができ、自分を変えることが、良いプロセスを作るための第一歩、と書かれてるのが良かった。何か新しいことを始めるには、まず自分から変わらなければいけない。

主要プラクティスができている場合に、さらに開発プロセスを改善したい場合のプラックティスについて書かれた章。

主要プラックティスができてる前提でさらに改善した場合のアプローチが色々書かれてて勉強になった。本物の顧客もチームの一員という考え方は良かった。

チーム全体を通して、XPにおける各ロールの概要が書かれた章

チームの全体像がわかって良かった。チームは所属する組織によって違うと思うけど、各ロールの職業について、（経営幹部、PM、デザイナー、テクニカルライターなど）解説されてて、勉強になった。

制約理論について書かれてる。制約理論はシステム全体のスループットを見るための考え方。

制約理論について洗濯機の説明わかりやすかった。洗濯(45分) → 乾燥(90分) → 畳む(15分) のステップがある場合、乾燥の部分が制約になっている。これを改善するには、乾燥する方法を別で追加するか、乾燥する時間を早くするしかない。開発プロセスの場合も同じで、乾燥するに相当する問題を見つけることで、改善することができる。XPを取り入れ、開発の生産性が上がると、制約が開発プロセスの外にでき、そうなると開発自体が一旦いらなくなるので、チームが解散させられるという話、興味深かった。

見積もりや計画づくり、スコープの管理について書かれてた章。スケジュール通りにいかない場合の再調整やり方などが書かれてる。

ペアプロとソロプログラミングを比較したときに、単独で作業した方がペアでやるよりも２倍以上時間がかるらしい。最近よくモブプロで作業してるが体感と近い気がした。ストーリーの見積もりはをポイントではなく時間でやる方が好みと書かれていたのが意外だった。実時間にした方が認識合いやすくて良さそうだと思った。

ソフトウェアの欠陥とそれを防ぐためのテストについて書かれた章。ソフトウェアで欠陥が生じると信頼が失われる。テストは信頼を守るために重要なものでXPにおけるテスト重要性が書かれている。

何のためにテストコードを書くのか、に対する答えとして、安全にコードを変更できるやバグを防ぐ、品質を守る、などいろいろと回答あると思うけど、信頼を守るためという表現はすごく良いと思った。ソフトウェアに欠陥があれば、顧客や同じチームのメンバー、ステークホルダーからの信頼が失われる。信頼されなくなると、使われなくなったり、仕事がうまく回らなかったりする。信頼を守るために、テストコードを書くことはとても大事だなと改めて感じた。

インクリメンタルな設計を受け入れる理由について書かれている。インクリメンタルな設計とは段階的に設計していくことだ。設計には、直感で考えた設計、熟考した設計、経験に基づいた設計 と段階があり、経験に基づいた設計 が一番品質が高くなるので、設計するのは経験するまで遅らせることがポイント。シンプルに保つことも重要で、設計のシンプルさについての評価基準も書かれてる。

設計をシンプルに保つための４つの評価基準がとても良かった。設計する時の観点として常に意識したい。特に、対象者に適している、最小限である、の考え方好きだ。良い設計をするためには、シンプルさを意識しつつ、経験を積むしかないなと、改めて思った。

評価基準

• 対象者に適している
• 情報が伝わりやすい
• うまく分割されている
• 最小限である

設計がいかに見事で洗練されているかは重要ではない。その設計を使うべき人たちが理解できなければ、それはシンプルではない。

情報が伝わりやすい。伝えるべきすべてのアイデアがシステムに表現されている。システムの要素は、用語集の単語と同じように、未来の読者に情報を伝えるものである。

うまく分割されている。ロジックや構造の重複は、コードの理解や修正を困難にする。

最小限である。上記の3つの制約を守った上で、システムの要素はできるだけ少なくする。要素が少なければ、その分だけ必要なテスト、ドキュメント、コミュニケーションが少なくなる。

XPがスケールする方法が書かれてた章。人数や組織の規模が大きくなったときに、XPをどう適用させればいいかが書かれてる。

人数が増えた場合は、問題を分解して小さくして、増えた人数を小さなチーム分割して、各チームで小さな問題を解いていくようにする。そうすることで、チームが大きくなる前のやり方と同じように問題に取り組めるし、さらに人数が増えていっても似たようなやり方でスケールすることができる。大きな問題を解くときはまず小さな問題に分解していくこと大事。

問題を小さな問題に分割する。

簡単な解決策を適用する。

問題が残っていたら、複雑な解決策を適用する。

SabreAirlineSolutions社の航空製品開発シニアバイスプレジデントであるブラッド・ジェンセンのインタビュー。XPを導入していて、XPの成果や推しポイントについて書かれてる。

ブラッド・ジェンセンさんは、XPの推しポイント（利点）として、欠陥が少ない、生産性が40%向上したと言っているが、生産性が高いとはどういうことか、具体的に知りたい。

XPのはじまりの物語について書かれた章。リリースまで残り2ヶ月を切ってるが、プロジェクト自体はトラブルだらけだった。そこで、XPの価値、原則、プラックティスを導入して、0から立ち上げ直したことについて書かれてる。著者が初めてXPを使ったプロジェクトの原体験。

残り2ヶ月しかない状態でプロジェクトを最初からやり直す決断をしたのはすごい。ここからXPが始まり、その知見が現在に生きていると思うとXPすごいなと思った

テイラー主義とソフトウェア開発について書かれた章。テイラー主義とは、工場の生産性について科学した結果として得た知見のことで以下のようなものだ。ソフトウェア開発では、テイラー主義に委ねるべきではない。

通常、物事は計画どおりに進む。

局所最適化は全体最適化につながる。

人はほぼ代替可能であり、何をすべきかを指示する必要がある。

テイラー主義とソフトウェア開発は合わなそう。テイラー主義という言葉を初めって知ったが、計画通りに行く、リソースが代替可能という考え方が、アジャイルの思想とは合わなそうと思った。

トヨタ生産方式（TPS / Toyota Production System）について書かれた章。TPSの開発プロセスでは作業者が作業のやり方について意見を述べて無駄を改善していくなどTPSのプロセスについて書かれてる。

ソフトウェア開発とも類似性があって、XPの要素も多いのでソフトウェアを開発するでも参考にできることが多そうだと思った。ソフトウェア開発は作り直すことが可能だが、車の生産は不可逆（作ったら戻しずらい）ので、類似性はありつつ、物理的なものを作る開発は難しそうと思った。

XPの適用や適用後の改善活動についての注意点などが書かれた章。

XPのプラックティスをひとまずやってみるだけならすぐ試せそうだけど、プラックティスに紐づいた価値や原則も一緒に組織全体で理解して実践するのは時間がかかりそうだなと思った。XPを適用する際、まずは自ら学ぶことが重要であったり、適用後も改善を繰り返すことが大事だったり、結果を出すためには地道に頑張らないとなと思った。

自分たちのチームがエクストリームであるかどうかどう判断すればいいか、に対する回答が書かれた章。個人やチームがXPかどうかを判断する方法は基本的にはない。基本的にはないが、ラ・レーチェ・リーグのリーダー認定モデル を使うというのが一つのやり方で、どうやるかというと、自己申告でチーム内外のメンバーとお互いに同意をとってそれを公にするというやり方。このやり方でXPであるかを認定して、判断する。

チームが XPかどうかはというのはそんなに重要じゃなくて（成果が出ていればXPじゃなくても良くて）、XPの価値・原則・プラックティスを実践してて、チーム内に共通の認識があり、成果が出ていることが大事だよなと思いました。

オフショア開発と今後のグローバルなソフトウェア開発のの展望について書かれた章。グローバルなソフトウェア開発のシナリオは二つあって、一つはコストの高い国が政治的な力を利用してコストの低い国を利用し続けるシナリオ。もう一つは世界中のプログラマーが無駄を排除して、信頼性や効果の高い安価な新世代のソフトウェアが生み出し、グローバル市場が盛り上がるシナリオ。

オフショアという概念があまり好きではないので、無駄を排除して盛り上がってほしい。

ビジネス的な関心ごと技術的な関心ごとが一致しない問題について書かれた章。ソフトウェア開発は、プログラマーとその他大勢で成立するものではなく、関係者全員の関心ごとが一致していないと貢献できない人が出てきて成功しない。XPは、経営幹部、マネージャー、顧客も含めたチームのメンバー全員が、自分のできることを全力で貢献するかどうかにかかっている。

プログラマーの世界だけでXPやっても仕方がなくて、チーム全体でXPをやらなければいけない。

コミュニティーとXPの関係について書かれた章。コミュニティーはソフトウェア開発の偉大な資産。

コミュニティーで話すより聞くスキルの方が重要なのは、話を聞いてくれる人（話を聞いてくれる人 = 解決策を持っている人 = Giveしてくれる人）が多いと、自分一人で解決できないことを解決できて、さらに自分も Give できるようになる好循環が生まれるからなのかなと思ったりした。僕もコミュニティで学んできたこともあるし、コミュニティーや文化は大事だと思った。

この章まで書いてきたXPについてのまとめ。XPとは、あなたが自分の理想について考え、その理想にもとづいて行動するための方法だ。

とてもいい本だった。ソフトウェア開発に対する、価値や原則、理想などを考えたことがなかったので、この本を読んでとても影響を受けたし、XPの価値や原則を受け継ぎたいと思った