容易にリファクタできてこそのAgileである - Clean Agile 基本に立ち戻れ

こんにちは、佐藤＠読書好きプログラマーです！　無駄な知識など存在しないをモットーに雑多に本を読んでここで吐き出しています。

今回は「簡単に改善できないなら、それはアジャイルじゃないよね」という話をします。

あなたはソフトウェアの開発に関係する仕事をされていますか？
もしされていないのであれば、ここから先を読む必要はありません。アジャイルは小さなソフトウェアを小さなチームで作るためのノウハウであり、それ以上でもそれ以下でもありません。これを念頭に置くべきです。

もしかしたら別の場所でも使うことができるかもしれませんが、使う前にそれは簡単に変更することができるものか考えてください。もし、簡単に変更することが出来ないなら、アジャイルを使うことは出来ません。

なぜなら、アジャイルは小さな改善のループを素早く回すことで、見積もりを正確にしながら安定度の高いものを作成する開発手法だからです。

大きなものを大集団で作ることは昔から行われており、ある程度手法が固まっています。わざわざそこにアジャイルを使う必要はありません。
作るものが作成時には不明確で、作りながら完成形を探っていくボトムアップな開発にこそアジャイルは使用すべきです。

ソフトウェアを守る鉄の十字架

そもそも、ソフトウェアはソフト（変更しやすい）であるウェア（製品）のことです。言葉が表すとおり、変更しやすい製品である必要があります。
顧客が望むのであれば、仕様は変更出来なければいけません。ただし、仕様が変更されるのであれば、納期も変更できなければありません。顧客と開発者の関係は対等であり、どちらの変更も許容できる必要があります。

開発に鉄の十字架という掟があることを覚えておいてください。
鉄の十字架とは「品質」「費用」「速度」「完成」のうちに3つしか選ぶことが出来ないという掟です。なので、品質がよく、費用が安く、開発速度が早いプロジェクトは完成しません。どれか一つを諦める必要があります。

ソフトウェアは出来上がるまで顧客が本当に望むものがわからないという性質があります。なので、作成中に仕様変更が入ることは免れません。
作り手は仕様変更を拒んではいけませんし、顧客は仕様変更によるスケジュールや費用の変更を拒んではいけません。

鉄の十字架を守りながら、小さな改善のループを回すことこそが、本当に顧客が望むソフトウェアを作る唯一の方法だと理解しましょう。

Agileとテストコードの関係

変更しやすいコードを書く上で必須なのがテストコードです。
すべての機能に対してその機能が正常に動くことを保証するテストコードを書きましょう。

あなたの変更したコードは思わぬ箇所に影響が出る可能性があります。Aという機能を変更したにもかかわらずBという機能が動かなくなることは往々にして起こります。なので、なにか変更した場合は、すべての機能が正常に動くことをもう一度テストする必要があります。

このテストを毎回手動で動かしていては機能が増えるごとにテストコストが増えていくことになり無駄が増えます。これを避けるために、機能が増えたら必ずその機能が正常に動くことを保証するテストコードをあわせて実装してください。
テストコードがあり、既存の機能が確実に動くことが保証されることで初めて自由に心理的に負担なくコードを変更することができるようになります。

小さな改善のループを繰り返すためにテストコードは必要です。TDDとAgileがセットで話される事が多いのはこれが理由です。

スケジュールの変更と信頼関係

製品と同じようにスケジュールも変更できるようにするべきです。
鉄の十字架を守りながら柔軟にスケジュールを変更していきましょう。

しかし、柔軟にスケジュールを変更可能という言葉を聞くと、いきあたりばったりで開発し、問題に直面したら変えればいいと思うかもしれませんがそれは違います。最初に大雑把に見積もることを許容し、適宜見積もりを修正することでブレを減らしているのです。

短いサイクルの開発を繰り返し、一つの開発が終わるごとに今の開発スケジュールで問題ないか再見積もりをします。作成した機能の組合わせ方法の検討や次に作る機能との複雑さの比較により、機能ができていくごとに見積もりは正確になります。

見積もりが正確になったことでスケジュールに変更があれば、顧客に共有しスケジュールの変更を依頼します。顧客はスケジュールの変更を受け入れられなければ、鉄の十字架に従い何らかを削減する必要があります。

また、短いサイクルで開発されるごとに顧客に成果物を納品します。
顧客は納品物を動かした結果、作成物のイメージがずれている場合は仕様変更を依頼することが出来ます。仕様変更を受けた開発者は仕様変更によるスケジュールを見積もり顧客へと返答します。
仕様変更を受けつけないということはしてはいけません。顧客が必要なものは顧客が望むものです。開発者が望むものではありません。必要な仕様変更は柔軟に受け入れる必要があります。

仕様変更とスケジュールの変更はワンセットです。何を作るかを決めるのは顧客であり、どう作るかを決めるのは開発者です。どう作るかによってスケジュールは決まりますが、何を作るかによってスケジュールはコントロールすることが出来ます。

なので、開発は開発者と顧客で強固な信頼関係なくしてうまくいきません。スケジュールと仕様の関係が切って切り離せないように、開発者と顧客の間に強固な信頼関係を結ぶようにしましょう。

銀の弾丸は存在しない

開発に銀の弾丸はありません。どんな場面でも使うことができる便利な開発手法はありせんし、どんな場面でもうまく使えるフレームワークもありません。

Agileは一つの開発手法であり、これが絶対の正義ではありません。ウォータフローが馬鹿にされたりしますが、ウォータフローの開発のほうが適した場面もあります。

色々なことをまなび、場面に最も適した開発手法・言語・構成を考えられるように勉強を続けていくしかありません。頑張りましょう。

◇

これまで書いてることは以下の本に記載されていることを僕なりにまとめたものになります。
この本はプログラマーなら一度は読んでおいたほうがいいと言われたことがあるであろうCleanCodeを書かれた方の本で、Agileの開発でも同じように進められる本になるんじゃないかと思います。
コードについての記載はあまりなく開発手法に特化した本なので、プログラマーだけではなくマネージャーや発注側でも読んでおけば、Agileの利点と特性を把握できるのでスムーズに開発ができるようになるんじゃないかと思います。

Clean Agile 基本に立ち戻れ

レビュー依頼やおすすめがあれば以下のリンクから教えてくれると嬉しいです。よろしくおねがいします！

おすすめの本置き場 - ナンカツンデッテ