Agile contract(アジャイル コントラクト)に関する2件の講演のまとめ

本エントリはオルタナティブブログの2007/6/13, 2008/3/13で公開したものである。

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

□ ICSE2007での講演 by Mary Poppendieck

ICSE2007のセッションの1つで、agile contractsの例としてトヨタとサプライヤの良好な関係について語られていた。トヨタがbest contractorとして挙げられ、サプライヤとのwin-winの関係を築いていること、信頼を基本とした共通のゴールをサプライヤと作れているところ、契約を必要以上に細かく作りこんだり、責任を必要以上に細かく分類していくことは所詮ゲームに過ぎないということを認識しているところ、において優れていると述べられていた。スピーカはMary Poppendieck氏。

セッションの内容は、国際会議にしてはちょっとローカル（米国）色が濃い感じが否めなかったが、母国である日本のもの（トヨタ）が褒められるのは気持ちがよかった。

業界の方の講演を聞き比べるとわかるが、トヨタに限らず自動車関連の組込みソフトウェアの開発は、製造業の組込みソフトウェア開発やエンタープライズ系ソフトウェア開発とは大きく異なる。たとえば、ソースコードの著作権の扱いやサプライヤがグローバルな市場に向いている点にも現れており、win-winの関係はここでもうまく醸成されているように思う。

□ 発注側にコミットメントを持たせよう by 鶴保氏

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

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

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

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