アジャイル開発において、技術と品質の重要性は不可欠だ（後編）。Agile Japan 2013

年に一度行われるアジャイル開発のイベント「Agile Japan」が今年も開催されました。今年の基調講演は、アジャイル開発の中で品質の重要性をあらためて位置づける目的で、James Gernning氏が「“Demand Technical Excellence”アジャイルにおける技術と品質の重要性」という題で行っています。

（本記事は「アジャイル開発において、技術と品質の重要性は不可欠だ（前編）。Agile Japan 2013」の続きです）

品質を作り込むプロセス

コンピュータサイエンティストとして有名なEdsger Dijkstraは、信頼性の高いソフトウェアが必要であれば、最初からバグを避ける方法を探さなければならないことに気づくだろう。と言っています。

つまり、バグを作り込まない、品質を作り込むプロセスにすることで、大事な時間をデバッグに使われないようにするのです。

テストドリブン開発（TDD）は、Dijkstraの方法論をある程度具体化したものです。テストを書く、通過させる。そしてリファクタリングですね。つまりテストと開発を並行して行うように、こういう流れを作らなければならないのです。

間違い、バグはだれでもあります。これをできるだけ早く見つける。3分前に作ったバグならあとから探すよりも容易に発見して修正できるでしょう。

ユニットテストはどうでしょう。これは絶対必要です。なぜかというと、ユニットテストでしかシステムを十分にテストできないからです。

例えば、10のステータスを持つ3つのオブジェクトが相互に関連するとしましょう。これを全部統合してテストするには1000個のテストが必要です。しかし1000個のテストを書くのは難しいでしょう。ところがユニットテストなら45個のテストで済みます。これなら十分にテストすることができます。

ユニットテストはこのように不可欠なものであり、そしてこれを自動化することも重要です。

なぜか。

よく、開発の工数に比例してテストの工数が設定されていることがあります。しかしこれは正しくありません。

なぜなら、1回目のスプリントでテストした内容は、2回目のスプリントでも、新機能のテストに加えてやらなければなりません。3回目のスプリント、4回目のスプリントと、テストすべき内容は増えていくのです。テストを手動でやっていたら、これはどこかで破綻します。そしてある晩、最悪のタイミングでバグが露呈するのです。

「テストを自動化している時間的余裕などない」という人がありませんが、逆です。「テストを自動化しないような時間的余裕はない」のです。

そしてこれが、技術的卓越性の一部です。

Martin Fowler氏は、どんなバカでもコンパイラが通るコードは書ける。スキルが必要なのは、人が分かるコードを書くことなのだ、と言っています。

テストを通過させることが技術的卓越性なのではなく、新しいスキルを身につけ、それを組織の中で伝播させていなかければなりません。

デベロッパー、マネージャ、スクラムマスターに望むこと

あなたの組織やマネージャは、よい構造のコードを書くことを推奨していますか？

コードの構造はなぜ重要なのでしょう？ そのコードが10年後、スパゲティコードのおかげで内容や機能を変更できなければ、変更や追加が可能だというソフトウェアが持つ大事な価値を失ってしまうのです。

だから、いまからデベロッパー、マネージャ、スクラムマスターにそれぞれ実行してほしいことがあります。

デベロッパーは、自分の職業のエキスパートになりたいですよね？ でもそれだけでは十分ではありません。スクラムでは、うまくいかない仕事も見せることが大事です。スクラムでスプリントごとに動くコードをリリースするのが大事なのは、うまくいかなかったらそれがだれの目にも明らかだからです。

顧客が「いま開発はどうなってる？」と聞いたときに「3カ月後に来てください」と返事をして、3カ月後にまだできていなかったらどうでしょう。開発状況が見える化されているとはいえませんよね。それでは信頼関係は築けません。

マネージャは、デベロッパーが自分の仕事を見える化するようにしなければならない、ということを気づかせなければいけません。マネージャがデベロッパーのモチベーションを下げるのは簡単です。非現実的な締め切りを設定したり、事実であることを責めるとか、質の低い仕事をわざとさせるとかです。

でもマネージャはモチベーションを上げることを気にする必要はありません。プログラミングは本来楽しいのですから。私も夜中の二時にコーディングが楽しくてしょうがないのに、妻に早く寝ろと言われます。マネージャはモチベーションを下げるものを取り除けばいいのです。

スクラムマスターは、チームが最新のプラクティスの知識をもてるようにしてください。プロジェクトの中には、スクラムコースで学んだことをそのままずっとやっているところがあります。振り返りもやっているのに、何も変えていないのです。

人は自分の知っている範囲の最適化しかできません。だからまず知ることが大事です。

ドグマとしてスクラムをやるのではなく、そこで問題が見つかれば、それを改善する活動をぜひ取り入れてください。スクラムマスターは、スクラムスレーブではないのですから。

そして改善する活動とは、継続的に振り返ってみて、そこで問題が発生したらそれを隠したり防御するのではなく、みんなで問題を直視して改善するのです。スキルは自分のものですし、顧客を満足させ、プロジェクトを炎上させたくないのですから。