#navi_header|技術|

半分ネタ、半分本気。

* リズム駆動開発(Rhythm-Driven-Development)の目的

「リズム感」をソフトウェア開発に導入することにより、個々人のプログラマの生産性を向上させる。

* 実施方法

特に開発フェーズにおいて以下の３ステップをリズミカルに繰り返し、プログラマが ''快感と安心'' を得られるようにする。
+ コードを書く。
+ コードを実際に動かしてみて動作確認する。
+ コードを洗練する。(できれば設計も)

より具体的には、 ''例えば'' テスト駆動開発(TDD)が挙げられる。
TDDの場合、上の「コードを実際に動かしてみて動作確認する。」部分にxUnitなどのテスティングフレームワークを導入することで、この３ステップをコード全体で素早く回せるようにしている。また、続く「コードを洗練する。」のフェーズでデグレ予防の効果もある。

TDDと同様に、この３ステップは細かいサイクルで繰り返す。

: プログラマの快感 : 動くコードを書き、洗練させていく快感
: プログラマの安心 : 細かくコードの動作確認を行うことで、漸増的にコードを洗練させてもデグレを防ぐ安心感

これら「快感」と「安心」を得られる３ステップを繰り返すことで、開発作業に「リズム感」「心地よいテンポ」を導入し、生産性を向上させる。

** なぜ「テスト」ではなく「動作確認」という表記なのか？

+ 品質保証(QA)での「テスト」という単語と明確に区別したいため。
+ プログラマにとって「よし！出来た！」と思える水準が「動作確認」であり、次の「洗練」フェーズへ進む為の条件。極めて主観的な基準点であることを明確にしたいため。

** "「個々人の」"と限定しているのはなぜ？チームとは関係ないの？

「あ～、ノッてきたな」と思えるリズム感やテンポには個人差があるため、「プログラマ全体」ではなく「プログラマ個々人」と限定している。

ペアプログラミングを活用してチーム全体にRDDの３ステップを浸透させる事が可能であれば、チーム全体でRDDのメリットを享受出来る可能性はある。その場合はペアプログラミングと同時にTDDも併せて導入するとより効果的かも知れない。

** (参考)RDDと正反対の開発手法(ウォーターフォールの一例)

+ 設計を100%完成させる。
+ 100%完成された(と思われる)設計に基づき、ひたすらコーディングする。 ''この間、コンパイルはするが実行はしない''
+ 完成されたコーディングを基に、ようやく実行し、テストを開始する。

- RDDでは細かいサイクルでコードを実行し動作確認するため、未完成の状態でも、例えばある関数が動くようになれば気軽に実行・動作確認する。これは上記のサイクルとは相容れない。
- RDDでは「洗練」フェーズでコードの重複を取り除いたりクラス構成/メソッド・関数のインターフェイスを修正したりするが、これは「100%完成された設計に基づきコーディングする」という上記のサイクルとは相容れない。

** (参考)RDDが非常にやりづらい開発手法の例

以下のような条件が整った開発風土の場合、RDDの導入は難しいだろう。
+ ''コーディング段階で設計上の問題を指摘すると、「設計バグ」として品質管理上かなり問題視される。''
+ ''オブジェクト指向言語であれ、Cなどの構造化言語であれ、ファイルモジュールからロジックの詳細まで、ほぼ関数/メソッド呼び出しと一対一で対応するレベルまで詳細に記述された設計をドキュメントとして残し管理している。''

RDDでは ''プログラマ自身がコード、ひいては設計を洗練させる過程が重要'' で、これがプログラマの「快感」を引き出し、生産性向上につながると捉えている。
上記のような環境では、プログラマがオブジェクトの構成や関数/メソッドのインターフェイスを修正するのに多大なコストと心理的な抵抗が発生する為、「洗練」フェーズを思うように作業出来ずテンポが乱れる。

''ただしプログラマ側が「こういうやり方だ」と割り切り、「洗練」フェーズを無くした２ステップをリズミカルに繰り返せるのであれば、'' RDDの目的である「リズム感」により生産性向上を図れる場合もある。

「洗練」フェーズをスポイルすることで「快感」は減少するが、それでもプログラマ自身がリズム感を感じている限りは、RDDの目的は果たせているだろう。

* よくある誤解

: RDDやTDDを導入すれば幸せになれる : ''銀の弾丸など存在しない。''
: xUnitの導入が必須 : 必須ではない。もちろんRDDの手法の一つ、TDDを活用すればxUnitによる自動化されたテストスイートが ''結果として'' 出来上がるが、それは単なる副産物の一つである。重要なのは ''開発時にプログラマがリズミカルに開発に専念できること'' であり、それがxUnit以外の方法で達成出来るのであればそれでよい。「実際に動かして動作確認」→「洗練」のサイクルを、人間の手だけで素早く回せ、かつ洗練のフェーズでもデグレ防止で特別にxUnitによる自動化テスト一式が必要でなければ、それはそれでOK。
: テストファースト/TDDでなければならない : 上と同じ理由により、リズミカルにプログラミング・動作確認・洗練ができれば、テストファースト/TDDでなくとも良い。
: 何が何でもテストを書かねばならない : 上と同じ理由により、テストを書かなくとも良い。 ''テストコードを書くのはリズムを保つ為である。'' たとえばGUIのユーザインターフェイスであったり、並行/並列処理であったり、非同期処理であったり、入出力デバイスやネットワークとのインターフェイス部分などテストコードを書くのが難しい部分については、少なくともRDDにおいては、無理してテストコードを書く必要はない。重要なのはリズミカルな開発であり、 ''そうしたテストコードを書くのが難しい部分で"嵌って"しまうのは本末転倒'' である、とRDDでは捉えている。
: 品質向上に寄与する : RDDは、 ''極論すればプログラマが「ノリノリだぜ～ヒャーーーハハッ！！」状態で開発する為の技法'' なので、品質向上とは関係ない。慎重派のプログラマが「動作確認」のフェーズで、xUnitにより緻密なテストコードを構築して品質が向上する場合はあり得るが、そうでないプログラマが、例えxUnitによるテストコードを構築したとしても、正常系しかテストしていなかったり境界値分析やデータパターンのバリエーションが不十分であったりする場合も当然あり得る。特にテスト駆動開発を活用したRDDの場合、「テスト」という単語から品質向上/品質保証(QA)と関連があるのではとミスリードし易いが、 ''基本的には'' 無関係である。

* RDDにおけるxUnitなどによるテストコードの存在意義、そして「快感」と「安心」

RDDではテストコードは必須ではない。なぜなら、必須としてしまうと、自動化テストが難しい部分までテストコードを書こうとして、却ってリズムを崩してしまいかねないからだ。

とはいえテストコードを書けそうな部分であれば可能な限り書いた方が良い。なぜなら「洗練」フェーズにおけるデグレ防止のセーフティネットとして機能するからである。

: RDDでの「快感」 : 細かいサイクルで動くコードを洗練させていくリズム感。
: RDDでの「安心」 : テストコードを書き自動化テストを構築することで、特に「洗練」フェーズにおいて安心してコード、さらには設計を洗練できるようにする。

** 自動化テストを活用する時に、絶対にやってはいけないこと

''「xUnitのテストコードがあるんだから、Excelでぎっちり作り込んだテスト仕様書に従ってテストするなんて面倒くさくてやってられねぇよ！」''

''これは単なる思い上がりと怠慢である。''
何度も繰り返すが、 ''RDDにおいてはxUnitなどの自動化テストは品質保証とは関係ない。''

Excelでぎっちり作り込んだテスト仕様書に基づいたテスト作業が、組織の開発プロセスに組み込まれているのであればそれに従った方が良いだろう。規模が大きくなるにつれそうした現場は増えてくるだろうが、同時にプログラマのレベルのばらつきも大きくなってくる。そうすると当然、テストコードの質のばらつきも大きくなる可能性が高い。
テストコード自体のレビューを頻繁に行い、境界値分析・異常系・データ入力パターンの過不足・コードの網羅率などを全体で改善できるのであれば品質向上にも寄与できる。
しかし、そこまでのマンパワーが無い場合は「RDDで構築した自動化テストはあくまでも開発者のもの」と割り切って、品質保証としてのテスト作業を謙虚に実施した方が良いかも知れない。

もちろんケース・バイ・ケースではあるので、組織によってはTDD導入の結果得られた自動化テスト一式を以て単体テストレベルを担保できるケースもあるだろう。

なおあえてテスト仕様書の種類(単体/結合/システム)は特定しなかった。実際の組織や現場に応じて、xUnitによる自動化テストコードの立ち位置は調整が必要だろう。

（以下、思いついた時に随時追記）

#navi_footer|技術|