XPやScrum、PFにおける価値はどんな効用を持つのか？

XPの価値と原則の理解を読んで、XPやScrumに出てくる価値の意味が恥ずかしながらようやく分かった。
考えたことをメモ書き。

【元ネタ】
XPの価値と原則の理解

- eXtreme Programmingの魅力を探る

スクラム組んで開発しよう！

チーム一丸となって顧客要望に向かって進む ─ Scrum ─｜ニューインテリジェンス｜アジャイルジャパン公式サイト

- プロジェクトファシリテーションTOP

XPは「コミュニケーション」「シンプル」「フィードバック」「勇気」の4つの価値を持つ。(「XPエクストリーム・プログラミング入門」第2版では「尊重」も加わった)
Scrumでは「コミットメント」「専念(集中)」「オープン」「尊敬」「勇気」の5つの価値を持つ。
プロジェクトファシリテーションでは「対話」「行動」「気づき」「信頼関係」「笑顔」の5つの価値を持つ。

何故、価値がプロセスの最初にあり、重要なのか？
その理由は「XPエクストリーム・プログラミング入門 第２版」の第３章に書かれている。

(引用開始)
書籍から手早く園芸の基本技術を学習することはできるが、 だからといって園芸家になれるわけではない。 私の友人のポールは、園芸家である。 私は土を掘り、植物を植え、水をやり、雑草を取り除くが園芸家ではない。
ポールと私との違いは何だろうか。 まず、ポールは私よりも技術に詳しい。 どちらも知っている技術を行なう場合はポールの方が上手である。 何かを掘ったり植えるといった作業がなければ 園芸を行なっていることにならないので、技術は重要だ。 このレベルの知識と理解をプラクティスと呼ぶ。 プラクティスとは、何かを実際に行なうことである。 そして、日々行なうことである。
．．．．．．ポールと同じ園芸プラクティスを理解していたとしても、 私は園芸家にはなれない。 ポールは、園芸で何がよくて何が悪いかについての感覚がとても発達している。 庭全体を眺めて、何が機能し何が機能していないか直観でわかるのだ。 私が枝を正確に刈り込む能力に誇りを持っているとしたら、 ポールは木全体をどのようにすべきかわかるのだ。 その理由は、ポールが私よりも優れた剪定師だからではなく、 ポールは庭での作業において全体を捉える力があるからだ。 ポールにとってシンプルで明確なことでも私はわざわざ勉強する必要がある。
このレベルの知識と理解を価値と呼ぶ。 価値は、ある状況で何が望ましく、何が望ましくないかの根拠である。
．．．．．．価値がないと、プラクティスはそれ自体のために機械的に実施され、 目的や方向性が欠けてしまう。 したがって、価値を明示することは重要だ。 プログラマが欠陥を無視した場合は、技術ではなく価値に問題がある。 欠陥自体は技術の問題かも知れないが、 欠陥から教訓を得ようとしないのは プログラマが実際には学習と自己改善を重視していない表れである。
．．．．．．価値とプラクティスの隔たりを埋めるのが原則である。 原則は領域固有の指針で、いつまでも変わることはない。 ポールの園芸家としての知識は、 原則レベルでも私を上回っている。 私がイチゴの隣にマリゴールドを植えることを知っていたとしても、 ポールは隣り合った植物が互いの欠点を補うという 共栄植物を植えることの原則を理解している。 マリゴールドは、イチゴを食べる一部の害虫が発生するのを自然に防ぐ。 イチゴとマリゴールドを一緒に植えることがプラクティスである。 共栄植物を植えることが原則である。
．．．．．．これが１冊の本で私が伝えることのできる限界である。
ケント・ベック
「XPエクストリーム・プログラミング入門 第２版」より
(引用終了)

価値とは、行動の善し悪しを決める判断基準、価値観である。
今、自分は本当にこの作業をすべきなのか？と迷うとき、XPを実践しているならXPの価値に照らし合わせて、やるかやらないか、別の方法を試すか、判断を下す。
ScrumもPFも同様だ。

古くから言われる「ドキュメントを書くことは必要か？」という質問は、XPの価値である「コミュニケーション」「シンプル」に照らし合わせて、現場の文脈よりもチームと自分が判断すれば良い。
「コミュニケーション」の価値を重視するならドキュメントを詳細に書くし、「シンプル」の価値を重視するなら、必要最低限のドキュメントで残し手間をかけ過ぎない。

価値は原則やプラクティスの源である。
価値なくして、プラクティスを実践しても意味が無い。
プラクティスを実践して作業を阻む障害にぶつかった時、自分が今までやってきた作業が正しいのか悪いのか、価値に照らし合わせなければ判断の下しようがない。
価値観に沿っているならば、たとえ障害にぶつかったとしても、価値観のおかげで自分の行動の正当性が保証され、勇気(XPの勇気、Scrumの勇気)が出てくるだろう。

自分は今まで「テーラリング」という言葉を何気なしに使ってきたけれど、「チケット駆動開発」本を出版してから、この言葉を使うのにすごく違和感を感じるようになった。
その違和感の理由を探すために、Togetterでまとめたみた。

チケット駆動開発のテーラリング - Togetter

Twitter / akipii: 平鍋さんが提唱されたPFはアジャイル開発の日本風なテーラリングなのか？多分違う。平鍋さんはアジャイルのエッセンスを深く理解されていて、そのエッセンスをチームビルディングのプラクティス集として抽出した。PFを編み出すためにフィットギャップ分析や都合のよい解釈をしたわけではないはず

Twitter / akipii: @sugimoto_kei はいアジャイル開発は標準プロセスのテーラリングでは断じてなく、プラクティスというパターンの組み合わせから発生すると思うのです。チケット駆動開発も同じ文脈で説明するようにしたいです。

その理由を探していて、テーラリングには価値という価値判断の基準が存在しないから、と気づいた。
プロセスを現場に合わせてテーラリングする場合、プロセスが重視する価値を無視して、現場の既存の運用を残してしまうために、中途半端な効果しか出ないからだ。

また「開発現場に合わせて、そのコンテキストでカスタマイズすればいい」という言葉もよく使っていたけれど、「コンテキスト」という言葉にすごく違和感を感じるようになった。
その理由は、どの開発現場も独自の状況があり、アジャイル開発であれ結局、一部の導入だけ試して満足してしまう事例が多いから。
つまり、現場のコンテキストを重視するがゆえに、アジャイル開発に対して都合の良い解釈をしてしまい、アジャイル開発が持つ価値(本来のあるべき姿)がうやむやになってしまいがちだから。

開発プロセスの導入は、現場の既存のコンテキストの背後にある、今までの現場の価値観を打ち崩す破壊力がある。
Scrumでは特に、Scrumの運用が順調に進んで継続的に開発を阻害する要因を改善していくに従って、「組織的な阻害要因(Organization Inpediment)」にぶち当たり、最終的には組織と緊張関係に陥る所まで行き着くという。
この辺りの解説は、細谷さんの記事「スクラム導入で開発を取り巻く矛盾はなくなるのか？ - Yasuo's Notebook」がとても分かりやすい。

だからこそ、プロセスの導入は、従来の組織に緊張関係を与えない程度に部分的な効果にとどまるか、組織自身がそのプロセス(XP・Scrum・PF)の価値を取り入れて自己変身するかのいずれかしか選択肢がない。

「コンテキスト」「テーラリング」という言葉は、ソフトウェア開発のあるべき価値観を曖昧にしてしまう毒薬が含まれていると思う。

「チケット駆動開発」のAmazon書評に「チケット駆動とは何か、何を価値とするのか、単純な原則を抽出して改めて体系づけ直すべきではないか。」という指摘があり、この指摘を今は真剣に考えている。
最近の僕が、パターン言語について調査して思索している理由の一つは、アジャイル開発の価値・原則・プラクティスを生み出した背景にはパターン言語があり、そのアイデアを使ってチケット駆動開発を体系化できないか、色々考えているから。
近いうちに公開してみるつもりです。