最小の仕様、十分な品質

XP

未熟だ。

アジャイル開発手法、特に XP の特徴である「未来に向けた設計をしない」というプラクティスをどうも、長い間誤解していたようだ。
「必要最小限の実装でとどめる」ことを信奉し始めたきっかけは、ずるずると締め切りなどお構いなしに、自分の作りたいものを作り続けて、それがじゃまされると烈火のごとく怒ったり、無口になったりする人を多く見たからだ。彼らは優秀なチームにも、そうではないチームにも存在して、至極もっともなことを言っては、「品質」だとか「こだわり」だとかいう言葉を振り回す。それは、言い訳にすぎない。特に大きなチームになると彼らは増える傾向にあるようだ。チーム全体が危機に陥っても、罪悪感など感じていないように見える。そのくせ、空気を読むことだけは上手で、黙々と作業を続けるふりをしている。本当は、彼らはエディターやUMLツールと向き合う時間よりも、Webブラウザと向き合う時間の方が長いのに。そして、うまくいかず追いつめられると「難しい」、「自分にはできない」と居直る。
彼らの気持ちはよくわかる。彼らは僕の心にかつて住んでいたし、未だに隠れて生き延びているからだ。だからこそ、僕は彼らが嫌いなんだと思う。納得いくまでものが作りたければ、世捨てでもしていつまでも一人でやっていればいい。予算があり、締め切りがあるのだ。「未来に向けた設計をしない」は自分に対する戒めでもある。

だが、これが裏目に出た。品質を生むのは実装量であり、時間であると思う。品質を生むには技量とそれを得るための労力が必要だ。何かの機能があって、それが最低限何とか使える程度で止める必要がある場合、僕はいつも悩んできた。ある時はその実装を指示し、別の時はそれを止めさせたりした。僕のこういった場合における指示はいつも一貫性を欠いていた。どこまでも作りすぎてはいけない。しかし、品質は確保しなければならない。それは、小さなクラスや関数でも言えることだし、開発用の小さなツールでも言えることだ。しかし、これらユーザーの目に触れないところは特に品質を犠牲にしていた。使いづらかったり、穴があったりしたのだ。

XPが言わんとする「未来に向けた設計をしない」の意図するところは、「最小の仕様、十分な品質」であると思う。事前にスパイクや設計を入念に行い、オンサイト顧客から要望をきちんと聞き、「最小限の仕様」を絞り込む。これによって作りすぎ防止を確保した上で、「見積もり」を行う。それをオンサイト顧客に提示し、オンサイト顧客がタスクの優先度を決定する。ユーザーによる要求があり、なおかつ作りすぎの懸念がなくなった状態で、「十分な品質」を実現する。

iPod shuffle はこの好例だと思う。

  • 最小の仕様
    • シャッフル再生しかない
    • ボタンは数個しかない
    • 液晶ディスプレーもない
  • 十分な品質
    • デザイン
    • 「シンプルさ」として売りにすらなっている少ないボタン
    • 軽さ
    • バッテリーの持ち

ターゲット層にとっての優先度をよく調べ、仕様を絞り込んだ上での品質の追求。おそらく、ユーザーにふれることのない関数、クラス、ツールにこれほどまでの品質は必要ないと考えられる。用途、場面、状況に応じた「十分な品質」が必要なのだと思う。「未来に向けた設計をしない」というプラクティスはそれを否定するものではない。

こんなことに、今頃気づいてしまった。どこかの本に書いてあるのだろうか？最近、この分野の勉強が足りないことに気づいた。