アジャイルコントラクト(agile contract)再び

第16回エンピリカルソフトウェア工学研究会でIPAソフトウェアエンジニアリングセンタの鶴保所長の講演を聴いた。トピックの1つは、ソフトウェア開発の契約方式やプロセスとしてアジャイルコントラクト、アジャイル開発を導入すべきという話だった。イテレーション開発やアジャイル開発のように発注側がコミットメントをもって開発に参加していくことが重要というものだった。交流会でも、民間同士であればアジャイル開発のほうが効率がよくなるだろうという話をされていた。ソフトウェアエンジニアリングセンタのメルマガの第20号に書かれたそうなので、詳細は参照いただければと思う。

アジャイルコントラクト自体はソフトウェア開発用に特化した契約方式ではなく、開発プロセスとしてアジャイル開発を強制するものでもない。アジャイルコントラクトは、一般的な請負契約のように発注時に要件、条件、成果物のすべてを決定してから開始するのではなく、受注者、発注者の両者が信頼感をもって臨み、一部を開発中に決めていく契約方式の呼称である。アジャイルコントラクトについてはここに書いた。

鶴保氏の講演を拝聴して思ったのだがアジャイルコントラクトに何らかの（比較的計測がラクで客観性のある）メトリクスを導入することでアジャイルコントラクトの問題の一部を解決できるのではないかと思った。ちょうど、ここに書いた、AppExchangeがアプリケーションプログラム自体と単体テストコードを預ける際に単体テストコードのテストカバレッジに条件を持たせるようなイメージだ。カバレッジだけではテストの妥当性ははかれないが、妥当性の一部をはかることはできる。同様にソフトウェア開発のアジャイルコントラクトにも何らかのメトリクスを導入することにより、導入が進むのではないだろうか。

スコープや成果物を決めないイテレーション開発やアジャイル開発が持つ問題点は、発注、請負の両方の立場に、高いモチベーションと高いモラルが必要になることだと私は考える。「これを作っている」「ここで働ける」というような特別な気持ちを維持できる理由が必要な場合が多いように思う。また、双方に信頼感がなければ、そもそもアジャイルコントラクト自体が成立しない可能性が高い。高い生産性を維持するために、信頼感を持つことやモチベーションを高く保つ努力をしていることが多いように感じるが、私は必ずしもすべてのソフトウェア開発においてそのようなモチベーション、モラル、信頼感を期待できるわけではないと思っている。それを補完するためのある程度の取り決めとして、メトリクスが貢献できるのではないかと思う。