エクストリームプログラミング解説 その5:原則

| 3 min read
Author: makiko-nakasato makiko-nakasatoの画像

はじめに

#

中佐藤です。XP解説その5です。前回までで「価値」「プラクティス」の解説が終わり、今回は「原則」。本連載の最初に出した図を再掲します。

全体像

原則

#

位置づけ

#

この図、さんざん使ってきましたが、我ながら少々気持ち悪い図です。このどこにもつながっていない「原則」が何なのかがわかりません。XPの原則とはどういう意味を持つものなのか。

まず書籍に書かれていることを見ると、原則は価値とプラクティスをつなぐ橋のようなもの、と表現されています。価値は非常に抽象的で、逆にプラクティスは具体的だがなぜそれをするかが見えない、その間をつなぐのが原則であると。

公式見解に逆らうのもおこがましいのですが、本当かな、とちょっと疑問を呈したい。なぜ疑問を持つかをみなさんと共有するために、原則の一覧を見ていただきましょう。

一覧

#
  • 人間性
  • 経済性
  • 相互利益
  • 自己相似形
  • 改善
  • 多様性
  • ふりかえり
  • 流れ
  • 機会
  • 冗長性
  • 失敗
  • 品質
  • ベイビーステップ
  • 責任の引き受け

いかがでしょうか。原則は価値とプラクティスをつなぐ橋だというのであれば、ほどほどの抽象度で、かつ価値とプラクティスの結びつきの理解を促進するものであってほしいのですが、ちょっと微妙。。。 「ふりかえり」とかアジャイルをご存じの方にはすぐわかるものもありますが、「自己相似形」って?

アジャイルの世界で原則というと、アジャイルマニフェストに付属している12の原則が有名ですが、こちらのほうが文章になっているので、意図が明確です。

この位置づけの悩ましさゆえに、下手に価値やプラクティスと何らかの線で結ぶと混乱を招きそう、と思ったのが、冒頭の図の意図です。

どう使うか

#

私は少なくとも初めてXPに触れる方には、原則はあまり強調して説明しません。ただでさえ価値が抽象的なのに、さらに加えて単語を羅列して原則を説明してしまうと、「XPって考え方が抽象的でよくわからん」で終わりかねない。

それなら原則は何の役にも立たないかというと、それも違います。一定期間アジャイル開発を経験した方、ぜひこのXPの原則を折に触れ、しみじみと見直してみてください。それも単語だけでわかった気にならないで、書籍を読むことをおすすめします。意外なことが書かれていたりします。

一部解説:ふりかえり

#

一部をご紹介しましょう。例えば先にも挙げた「ふりかえり」、スクラムのスプリントレトロスペクティブそのものを指すというより、もう少し抽象的な意味で挙げられています。また、これって Kent Beck がコンサルやコーチをディスってるよなと思う記述も。どんなことが書いてあるかは、書籍を読む方の楽しみに取っておきましょう。

一部解説:相互利益

#

「最も重要であり、最も実行が難しいXPの原則」とあり、確かに難しいなと思うのが「相互利益」。この言葉だけだとわかりづらいですが、これが「文書化」に関係しています。「あらゆる活動は、関係者全員の利益にならなければいけない」ので、「大量の内部ドキュメントは、将来の見知らぬ誰かがコードを保守しやすいように、現在の開発速度を大幅に下げろと言われているのと同じ」で、相互利益に反するというわけです。

そうは言っても実際問題、多少の文書化はしておきたいんですよ、「将来の見知らぬ誰か」って実は自分かもしれないし、とか考えるとやはり難しいですよね。私はこの原則は「他の方法も考えたか?」という一種の警告と捉えています。例えばこの文書の問題で、ドキュメントの代わりの手段として挙げられているプラクティスのひとつが、(自動)テストです。テストは「現在の自分と将来の保守担当者の両方の利益になる」からです。

書くことになっているから何となく書く文書は大体腐ります。よりよい(相互利益になる)方法を考え抜いて、それでも必要と判断したものだけを書け、といえば、ちょっと理解できないでしょうか。リファクタリングにおける「コメント」の位置づけと似ていますね。

一部解説:冗長性

#

アジャイルを知っている方が非常に意外に思われるであろうものを、ひとつご紹介しましょう。それが「冗長性」、「困難な問題は複数の方法で解決すべき」とあり、冗長性を排除しようではなく、むしろ推奨しています。

更にここで冗長性の例として挙がっているのが、テストフェーズなのです。「開発終了後にテストフェーズを設けるのは冗長だと思うだろう。だが、テストフェーズを排除していいのは、何度かのデプロイで連続してひとつも欠陥が発見されず、テストフェーズが本当に冗長であることが実証された場合だけ」だと。

一般的にアジャイル開発では「フェーズ化」を避けようとします。あらゆる開発工程を可能な限りイテレーションの中で行って、Doneの定義を高くする、それによってリリース可能な状態を保とうとします。よって「○○フェーズ」は、ウォーターフォール的だと嫌われる傾向にある。それなのに、アジャイルの最たるものというイメージのあるXPが、それを許容(むしろ推奨)しているのは、とても驚かれるのではないでしょうか。

念のために付け加えておきますと、だからといって「XPの本に書いてあるからいいんだ」とテストフェーズを何も考えず従来通り設定する人がいたら、小一時間説教しに行きますよ。なぜテストフェーズが必要と言われているのか、逆になぜフェーズ化を避けようとするのか、自分たちの現在の状況で必要なことは何なのか、常に考えましょう。

次回に続く

#

これで、価値・原則・プラクティスが揃ったのですが、結局どう使うのか、ということは書いておいたほうがよいですね。それを次回の最終回としましょう。

豆蔵デベロッパーサイト - 先週のアクセスランキング
  1. 自然言語処理初心者が「GPT2-japanese」で遊んでみた (2022-07-08)
  2. Tauri でデスクトップアプリ開発を始める (2022-07-08)
  3. Deno による Slack プラットフォーム(オープンベータ) (2022-09-27)
  4. Jest再入門 - 関数・モジュールモック編 (2022-07-03)
  5. ORマッパーのTypeORMをTypeScriptで使う (2022-07-27)
  6. 第1回 OpenAPI Generator を使ったコード生成 (2022-06-04)
  7. 直感が理性に大反抗!「モンティ・ホール問題」 (2022-07-04)
  8. Rust によるデスクトップアプリケーションフレームワーク Tauri (2022-03-06)
  9. 箱ひげ図で外れ値を確認する (2022-05-18)
  10. Nuxt3入門(第1回) - Nuxtがサポートするレンダリングモードを理解する (2022-09-25)