はじめに
XP(Extreme Programming:エクストリームプログラミング)と聞いたら何を思い浮かべるでしょうか。
- 何かアジャイルで良い感じにするやつ
- ペアプログラミング・モブプログラミング
- テスト駆動開発
- 継続的インテグレーション
上記のような印象を抱く方も少なくはないかもしれません。
数ヶ月前からゴリゴリXPで開発をする職場に転職してみて、実践していますが、
「XPとは何か？」と問われたとき上手く言語化できないなということに気づいたため、
を読んで得た内容と、自分の経験をもとに
XPとは何ぞや？ というアウトプットをしてみたいと思います。
XPが目指すもの
XPは変化に柔軟に対応することを目指しています。
ソフトウェアには変更がつきものです。
社会の変化、ビジネスの変化、ステークホルダーの変化、チームメンバーの変化、技術の変化、要件の変化などなど、ソフトウェアを取り巻く環境の変化により、ソフトウェアは変更を余儀なくされます。
ソフトウェアを取り巻く環境の変化を止めることはできません。
変化が起こることを前提に、変化に対応できるようにすることがXPの本質です。
ちなみに、本の中では下記のように紹介されています。
XPとは、効果のない技術的/社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである。
XPとは、自分が今日やるべきことを十分に理解することである。
XPとは、明日をよりよくしようとすることである。
XPとは、チームのゴールに貢献した自分を評価することである。
XPとは、ソフトウェア開発で人間としての欲求を満たすことである。1
価値と原則とプラクティスと
ざっくり説明すると...
XPには、価値、原則、プラクティスがあります。
これらの中身の話をする前に、これらの関係性を明らかにしておきます。
価値とは、目的を達するにあたっての考え方のベースです。
原則とは、価値とプラクティスを繋ぐもので、価値をブレイクダウンしています。
プラクティスとは、1つ1つの取組み、行動です。
子供用のカレーを作るときの、価値・原則・プラクティス
上記の説明だけではよくわからないので、例を交えて考えてみましょう。
あなたは「小さな子供が喜ぶカレーを作る」という目的を持っているとします。
一旦、価値、原則、プラクティスなんか忘れて、「小さな子供が喜ぶカレーを作る」という目的を達成する方法を考えてみましょう。
例えば、「甘口のルーをつかってカレーを作る」というのはどうでしょう(甘口のルーのカレーで喜ばない子供もいるでしょうが、そういうのは一旦脇においちゃいます)。
多分、子供が喜ぶカレーになるでしょう。少なくとも、辛口のルーを使ってカレーを作るよりは喜ばれることでしょう。
この記事を読む多くの人が、なんとなく上記の考えを理解できるのではないかと思います。
この考えのプロセスを、価値、原則、プラクティスに分解して考えていきます。
価値
「小さな子供が喜ぶカレーを作る」という目的を達成するために、何を大切な考えとすれば良いでしょうか。
例えば、「美味しいこと」は「小さな子供が喜ぶカレーを作る」ためにはとても重要なことです。
何を当たり前のことを言ってんだと思う方もいるかもしれませんが、この「何を大切な考えとすれば良い」というのは非常に重要な考え方です。
例えば、仮に「おしゃれであること」ということを重要な価値とします。
おしゃれなテーブルに、おしゃれなテーブルクロスをひいて、おしゃれな皿にカレーを盛り付け、おしゃれなスプーンでカレーを食べます。
良い雰囲気の中で食べるカレーはとても素敵ですが、「小さな子供が喜ぶカレーを作る」という目的を達成するために、それほど重要となる考えではなさそうです(少なくとも「美味しいこと」の方が小さな子供にとっては魅力的に映るでしょう)。
価値とは、目的を達するにあたっての考え方のベースです。
「小さな子供が喜ぶカレーを作る」という目的を達成するためには「美味しいこと」が価値となるでしょう。
プラクティス
原則について考える前に、先にわかりやすいプラクティスについて考えてみます。
上述の通り、「甘口のルーをつかってカレーを作る」というプラクティスを使えば、「美味しいこと」という価値を満たし、「小さな子供が喜ぶカレーを作る」という目的も満たしそうです。
では、なぜ我々は「小さな子供が喜ぶ美味しいカレーを作る」という考えから「甘口のルーを使う」という発想を得られるのでしょうか。
これが価値とプラクティスの間に挟まる原則に絡んできます。
原則
我々は一般に「子供は辛いものが苦手である」ということを知っています。
したがって、「小さな子供が喜ぶ美味しいカレーを作る」という考えから「甘口のルーを使う」という発想を得られます。
この、「子供は辛いものが苦手である」ということが原則です。
価値からプラクティスを導出するための橋渡しをするのが原則です。
価値なきプラクティスはただのプラクティス
我々は「子供が喜ぶカレーを作るには甘口のルーをつかえばいい」と知っています。
価値とか原則とかプラクティスとか、そんな難しいこと考えなくても大丈夫じゃないか、と考える方もいるかもしれません。
しかし、価値や原則をすっ飛ばしてプラクティスに意識を向けるのは危険です。
価値がないとプラクティスは意味を失ってしまいます。
「美味しいこと」という価値を持たず、ただただ「甘口のルーをつかってカレーを作る」ようになったらどうなるでしょうか。
例えば、辛いものが大好きな家族のもとに生まれ、辛いものが大好きな小さな子供に対して、「小さな子供だから甘口のルーを使ってカレーを作れば喜ぶ」と考えるのは早計です。
「美味しいこと」という価値があれば、プラクティスを修正することができます。
不変の価値、可変のプラクティス
1つの目的を達成する場合、状況が変化しようとも価値が変化することはありません。
価値は考え方のベースとなるものであり、変化することはありません。
一方、状況が変化すればプラクティスは変わります(原則も変わります)。
今回の「小さな子供が喜ぶカレーを作る」という例は暗黙的に「日本という国において」という状況を背景としていました。
例えば、「インドという国において」という状況を背景に考えてみましょう(調べてないので本当かは知りませんが小さな子供もスパイスカレーなどが食べれるということにしておいてください)。
この状況において、「小さな子供が喜ぶカレーを作る」という目的を達成するため、「美味しいこと」という価値自体は変わらないでしょう。
しかし、日本という国においては「子供は辛いものが苦手である」という原則がありましたが、インドという国においてはその原則は成立しないでしょう(あるいは通用しないものとする)。
この状況において、「小さな子供が喜ぶカレーを作る」という目的を達成するためのベストプラクティスは「スパイスカレーを作ること」になるかもしれません。
このように、状況の変化により、価値は変化しませんが、プラクティスは変化します。
さて、価値・原則・プラクティスの関係性について確認したので、
XPにおける価値・原則・プラクティスについて確認していきましょう。
XPの5つの価値
XPには5つの価値があります。
- コミュニケーション
- シンプルさ
- フィードバック
- 勇気
- リスペクト
コミュニケーション
XPではチームで1つのソフトウェアを開発していくことを前提としています。
チームで開発を行っていく以上、コミュニケーションの質や量は大切になります。
特に直接のコミュニケーションに重きが置かれます。
また、変化に柔軟に対応することという目的に照らし合わせたとき、
例えば、
- 仕様が変更になった
- より良い設計が見つかり、設計を変更したい
- 同じ問題に遭遇した人がいる
などの状況において、コミュニケーションは必須です。
シンプルさ
できるだけシンプルな実装にすることが重要なのは、多くの方が賛同するところだと思います。
要件の変化などに柔軟に対応するには、シンプルさが必要でしょう。
ただ、シンプルさは、何もコードや設計に限った話ではありません。
ソフトウェアの開発を取り巻くあらゆる問題に対して、シンプルさを追求していきます。
例えば、「ビジネスサイドと合意した締切にむけて開発を進めていたが、開発を進める中で予想以上の工数がかかることがわかり間に合いそうもない。その中で開発メンバーの病欠が相次ぎ、どうしようもない」なんて状況に陥ったとします。
当事者になれば、パニック必至でしょう。
問題のシンプルな解決策は、「リリースする機能を最小限(MVP:Minimum Viable Product)まで削る」などでしょうか。
フィードバック
この世のあらゆる問題に対して「何が正しいのか」を突き止めるのは非常に難しいことです。
ましてや、あらゆることが急速に変化していく世の中において。
正解がわからないからこそ、素早いサイクルで「作る->フィードバックを受けて改善する」というサイクルを繰り返すことで、
変化に柔軟に対応することができます。
勇気
変化に柔軟に対応することという目的を達成するためには様々な意思決定が必要です。
時には今までのやり方を急激に変えたり、あるいは、今までのやり方を否定するような変化も必要かもしれません。
変えるという意思決定を勇気を持って進めていかないと、変化に柔軟に対応することはできません。
リスペクト
上述の通り、XPではチームで1つのソフトウェアを開発していくことを前提としています。
チーム内でのリスペクトが欠けていれば、
- コミュニケーション
- シンプルさ
- フィードバック
- 勇気
といった他の価値が薄れてしまいます。
原則
原則の中からいくつかピックアップして紹介します。
人間性
ソフトウェアの開発をするのは人間です。
ひとりひとりの人間が集まってチームを成し、ソフトウェアの開発を行います。
ひとりひとりが違う人格を持ち、人数の分だけ考えや欲求を持ちます。
一方、一つのチームとして見たとき、チームとしての目標(ソフトウェアを開発すること)があります。
メンバーがそれぞれ自分らしくいられるチームを作る必要があります。
ふりかえり
どんなに優秀な人も、成果を上げるチームも、初めから上手くできるわけではありません。
成功や失敗から学び続けることで、改善を繰り返していくことで学習に繋がります。
フィードバックは人を、チームを成長させていきます。
多様性
皆が似たような考えを持っており、仲良しこよしでソフトウェアの開発をすれば上手くいくというわけではありません。
ソフトウェアを取り巻く環境が変化し続ける中で、様々な考え、視点、スキルを持った人が集まることで、変化に対応できます。
これが多様性です。
ただ多様性があればいいというわけではありません。
多様性の中にはリスペクトが必要です。
多様なメンバーが健全なコンフリクトを起こすことで、変化に対応できるのです。
相互利益
ステークホルダー全員に利益がもたらされる状態を追求します。
例えば、ドキュメント(設計書)の作成が相互利益を失わせるいい例です。
ソースコードとは別にドキュメントを作成する必要があるため、開発スピードが落ちてしまいます。
ソースコードの修正が発生する度に、別途ドキュメント修正の工数がかかってしまいます。
将来の開発者に仕様を示すのであれば、テストコードという手段で良いでしょう。
自動テストであれば、将来の開発者も利用することができます。
ベイビーステップ
横着をして上手くいかないという経験を、誰しもしたことがあるでしょう。
大きな変更を一気にやってしまうのは危険です。
小さなステップに分割し、高速に繰り返すことが大切です。
冗長性
冗長な設計、コードは変化への柔軟性を失わせます。
冗長性という観点は、短期的な利益を追求するとついつい後回しにされてしまいます。
しかし長期的に負債として溜まってしまいます。
価値でも述べているようにシンプルさを追求していく必要があります。
プラクティス
多くのプラクティスがありますが、ここでは
- ペアプログラミング・モブプログラミング
- テスト駆動開発
がそれぞれ、どの価値・原則に紐づいているかを確認していきます(ペアプロやTDDが何かという説明はここでは省きます)。
ペアプログラミング・モブプログラミング
価値は例えば下記の項目に紐づいています。
- コミュニケーション
- ペアプロ、モブプロでは常にコミュニケーションをとっている
- フィードバック
- ペアのメンバーから即時のフィードバックをする/される
- リスペクト
- メンバーへのリスペクトも忘れてはならない
原則は例えば下記の項目に紐づいています。
- 人間性
- 違う考えや経験を持つ人同士がペアを組んで開発をする
- ふりかえり
- 書いているコードに対してのふりかえり(フィードバック)が得られる
- 多様性
- ペアの中で時には健全なコンフリクトを起こしながら開発を進める
テスト駆動開発
価値は例えば下記の項目に紐づいています。
- シンプルさ
- テストがあることでよりシンプルに(テスト->実装->テスト->実装のサイクルで小さく作れる)
- フィードバック
- テストファーストのため、実装が完了するとテスト結果というフィードバックが得られる
- 勇気
- 勇気を持ってリファクタリングすることも可能になる
原則は例えば下記の項目に紐づいています。
- 相互利益
- テストに仕様を連ね、テストが仕様を担保することで大量のドキュメントは不要となる
- ベイビーステップ
- テスト->実装のサイクルを小さく回して実装が進められる
- 冗長性
- 冗長なコードをシンプルに変更できるのはテストがあればこそ
重要なことは、プラクティスそれ自体ではなく、価値にそったプラクティスであることです。
状況が変われば、最適なプラクティスも変わります。
現時点では、ペアプロやTDDなどが良いプラクティスとされていますが、状況如何ではベストプラクティスが変わるかもしれないということに留意しましょう。
軽くまとめ
XPとは変化に柔軟に対応することです。
ペアプログラミングやTDDという単なるプラクティスを実践することがXPではありません。
価値、原則などを理解した上でプラクティスを実践していくことが肝要です。