XPのことを知らないのは微妙だなと元々思っていたのと、仕事上の思想のコアになった二冊 - 下林明正のブログの流れで基本に立ち返る気持ちが強まっていたので、この本を読んでみることにした。
もしかしたら、自分のような人間がXPに触れてこなかったというのは意外に思われるかも知れない。 個人的には、XPは一回り年上の世代というイメージがある(ちなみに、自分は1986年生まれで業界16年目くらい)。 自分の周りでは、自分と同じくらいか若い人たちはあまりXPそのものについては勉強したことがないという人は多かった。 逆に、自分より年上の人たちは当然知ってるよね、という雰囲気もあった。 おそらく、こういった知識を必要としたときに手を取りやすいところにあったのが、ある世代にとってはXPだったり別の世代にとってはスクラムだったりしたのだと思う。 実際のところは知らないので、憶測だけど。
なんにせよ、自分が参考にしているような知識体系の源流にXPがあることは知っていたので、今回勉強してみることにした。
そもそもXPとは何か、ということについては意外と簡潔にまとめられていなかった。「XPとは何か」という章に色々と書かれているので、それを読むのが良さそう。ただ、特定の手続きに則っていればXP、というわけでないことだけは確かだった。つまり、XPはルールやフレームワークなどではない。あえて自分なりにまとめるなら、XPとは仕事に対する態度、というように感じた。
基本的には、大部分の内容は同意できるものだったし、今でも十分に参考になるように感じた。 「大部分の内容は」というのは、分かりやすいところではテストファーストプログラミングやペアプログラミングといったプラクティスについてインターネット上で議論が発生しているのを過去見てきているということがある。 ただ、前述の通りテストファーストプログラミングやペアプログラミングをやってないとXPではないというものではないので、そういうところも含めての参考なのだと思う。
訳者あとがきにはXP本来のあり方とは、「価値、原則、プラクティス」のそれぞれを言葉にして、場合によっては利用者であるあなた自身が自分の言葉を生み出しながら、利用することに他ならない。とまとめられている。
なので基本的には、それらが絶対でないにせよ重要ではありそうだった。
ではまず、XPのプラクティスがどうなのか？というと、大部分が本の冒頭でも触れられている通り現代ではことさら当たり前の取り組み、少なくとも知識としては常識になっているものが多いと思う。
例えば、CIは本当に当たり前になった。「ストーリー」も知らないという人はいないと思う。他にもそういったものが多い。 ただ、全部がそうでもないように感じる。例えば「いきいきとした仕事」は自分はあまり聞いたことがなかった。
価値や原則についてはどうか？と考えると、部分的に別のところで聞いたことがあるような気がする(例えば、XPの価値のひとつである「勇気」は、スクラムの価値基準にも含まれている。「リスペクト」はTeam GeekでいうところのHRTにも含まれている、など)ものも多いが、あまり聞き慣れないものも多いように感じた。例えば、XPの原則にある「人間性」などはあまり言われている印象がない(あっても、機能しているチームを解体することほど愚かなことはないとかそういうくらいで、人間性というほど踏み込んでいない印象)。
今このタイミングでXPについて勉強する価値が特にありそうに感じたのは、きっとこういった(自分にとっては)失伝された知識に関することだと思っている。 もし後の知識体系において意識的に変更が加えられたものであれば、おそらく何らかの意図やアンチパターンがあったのだろう。あるいは、単に分かりやすい・使いやすいプラクティスだけが伝わってその背景が伝わってないのだとすれば、その背景を補完することでより本来の理想像を描くことができるようになる、はず。
前置きがかなり長くなったけど、その上で自分が特に気になったのは以下のような点だった。
- 制約があっても、最善を尽くすことはできる
- 制約に心を奪われると、ゴールから遠ざかってしまう
XPは(中略)実践するのがとても楽しい。- 原則
- 人間性
- 冗長性
ソフトウェア開発の重要で困難な問題は、複数の方法で解決すべきである。ひとつの解決策が完全に失敗しても、その他の解決策で惨事を食い止めることができるからだ。
- 自分にはこういう態度が足りてないと思う。原理主義的だし怠惰なので一つの解決策でなんとかしようとしがち
- 主要プラクティス
- いきいきとした仕事
- 長時間労働に対してここまで明確にNOを突きつけているのは珍しく感じる
- いきいきとした仕事
イニシアチブをとれる。いい表現だなと思った- リードする、とか言いがちだけど、またちょっとニュアンスが違う感じで便利そう
- 適当に調べたらこういう記事が出てきた。こういう感じで使い分けなどできると便利かも: 第89回『リーダーシップとイニシアチブ』 | チームビルディングジャパン
- 制約理論
- ボトルネックを潰していくことを制約理論と呼ぶとそれらしさが増す気がする
あまり効果がないことでおなじみのウォーターフォール型の開発スタイルだ。
- ここで純粋なウォーターフォール的な図で紹介されている
- やはりここでも対比的に紹介されていた
- 脇道に逸れるけど、個人的にはなぜこういった純粋なウォーターフォールが国内外で大流行した(らしい。自分は関わったことが無いが……)のか歴史的な経緯にちょっと興味がある。前世紀のテイラー主義、フォード主義的な思想が自然と受け継がれた結果だったのだろうか。マネジメントの世紀 を読んだ - 下林明正のブログはソフトウェア開発の文脈に限定されていなかったので、その答えにはなってなかったような記憶
経営幹部の支援がない場合は、たとえ評価や保護が得られなくても、自分自身でよりよい仕事をする覚悟を持たなければいけない。
- 第一版ではストーリーポイントを紹介していたが、この第二版では実時間での見積もりの方が好み、とのこと
- 理由はよくわからない
- 特定の個人に結びついた予想作業時間ではないことに注意。「ペア時間」という単位を紹介している。どうやら、平均的なペアが何時間取り掛かったら完了させられるか、という単位らしい
- 建築のメタファーがよく使われるが、根本的な欠陥があるという話
- 建築の世界では、逆方向に進めることが難しい。ソフトウェアの世界では簡単。という根本的な違いがあるため
論点となるのは、設計をするかどうかではなく、設計をいつするかである。
- 個人的にあまりピンときてない点として、実際には言うほど逆方向に進めることは簡単ではないというのがある
- もちろん建築と比べたら圧倒的に簡単なんだろうけど、ソフトウェア開発においても「経済性」の観点から実質的には逆方向に進めない、ということはよくある印象
- 最終責任時点の概念は分かる
- まあ、事前設計や初期設計が重要ではないと言ってるわけではないので、矛盾はしてないのかも。ただ、その重要性についてあまり言及されてないように感じる点に引っかかりがあるだけかも
- トヨタ生産方式
ムダを排除するために必要なフィードバックを手に入れるには、アウトプットをすぐに利用する必要がある。
- トヨタ生産方式がさらに源流にあることは知っていたけど、この一文でその辺りの理解がより明確になったような気がする
全体を通して印象に残ったのは、やはり「人間性」が重視されているように感じる点だった。 あまりここまで明確に重視されていることは多くないような気がする。 個人的には共感できる考え方なので、覚えておきたい。
訳者あとがきによると、パターンランゲージはXPのみならずアジャイル開発手法を理解する上で重要なものらしい。 アレクサンダーの書籍やパターン、Wiki、XP ―― 時を超えた創造の原則 WEB+DB PRESS plusを読むと良いとのこと。 この辺りもまた気が向いたら読んでみたい。
