はじめに
「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜」に参加してきました。#devlove - HOW TO GO というブログエントリに
受託でアジャイルはどうなのか？
という記述がありました。世の中には受託でアジャイルをどうやって始めるのか悩んでいる人がいるらしいので、体験談を書きます。
請負契約でアジャイルっぽくやるための方法です。 業務委託で契約できるなら（開発側は）リスクが低いのでその方がおすすめです。*2
それから「ディシプリンド・アジャイル・デリバリー」は未読です。読んだ人には釈迦に説法かもしれません。
三回以上の分割納品
始めるのは簡単です。お客さんにスケジュールを提示する際に納品を3回以上にすればOKです。 最初に提示すれば納品回数を一回に変更したがるお客さんはいません。 同じメンバーで同じシステムの開発を繰り返すことができます。*3
イテレーション
分割納品する際に一つ一つの納品期間を同じぐらいにすると、前回の納品と今回の納品のどっちが上手く行ったか比べ易くなります。 一定期間で開発を繰り返すことをアジャイルソフトウェア開発ではイテレーションと読んでいます。 一般は1週間から2ケ月が推奨されています*4。
分割のデメリット
納品の度に試験しないといけないで手間が増えます。 イテレーションごとに一定のペースで機能が増えると仮定すれば、機能テストはイテレーション数*(機能数+1)の半分*5行うことになります。
最初のイテレーションでは1機能ですが、第二イテレーションでは2機能。累積して3機能分の試験が必要です。 第三イテレーションでは提供機能3に対して機能試験は6になります。
| 第1イテレーション | 第2イテレーション | 第3イテレーション | |
|---|---|---|---|
| 追加機能数 | 1 | 1 | 1 |
| 機能試験数 | 1 | 2 | 3 |
| 累積試験数 | 1 | 3 | 6 |
10イテレーション行う場合は55に達し、一括納品の5倍を超えます。*6 TDDで単体テストを前倒しにしたり、テストを自動化したりする等の工夫が必要です。*7
分割のメリット
リリース後のバグが減る
最終イテレーションより前にリリースした機能はある程度使用されます。契約終了後にバグが出て瑕疵対応することが減ります。次の案件との掛け持ちが減るので技術者は楽になります。バグが多すぎていつ技術者の手が空くのか分からず、次の営業が掛けられない営業上のリスクも減ります。
キャッシュフロー
検収も分割にできるとキャッシュフロー的にもうれしいです。また検収後支払いが遅延した場合もリスクが低減できます。
コミュニケーションコストの低減
一回納品をするとお客さんと技術者の間に信頼感が生まれます。 第2イテレーション以降からは腹の探り合いが減るためコミュニケーションコストが下がります。
失敗と成功の間を評価できる
おそらくこれが最大のメリットです。
開発側視点
何回も納品すると1回は期日通りにバグもほとんどなく納品できることがあります。 1回でも成功していれば別のイテレーションで失敗してもお客さんに「この業者さんは頑張ってくれているけど今度の機能は難しかったんだ」と分かってもらえます。 全1回の納品で失敗すると「やれると言ったのに出来ないじゃないか、この業者は技術力は怪しいし言うことが信用できない」と思われる可能性が高いです。
発注側視点
発注側にもメリットがあります。成功失敗以外の中間値が取れるため「大体8割ぐらい成功する技術力がある業者」とか「3割ぐらいしか成功しないけど単価が安い業者」とか発注先をより細かく評価することができます。
「システム・インテグレーション崩壊」のすすめ - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japanでは
相互不信の構図が、今のSIビジネスに内在している
とあります。これは1回の納品で業者を評価するからです。システム開発において1回の納品で期日通りにバグもほとんどなく納品できることは稀です。このため慣れている発注者ほど「納品間際にバタバタして受入試験でバグも出てる。でも業者さんは夜遅くまで対応頑張っているみたい」という評価になります。どの業者でも同じ評価になり、差が分からないため信用できるか判断できなくなります。
分割する際の注意
イテレーション期間
短い方がいい
基本的に納品数が多くイテレーション期間は短い方がプロジェクトは上手く進みます。繰り返し回数が多ければ全ての納品に失敗する可能性は下がります。また、後述しますが最終イテレーションは難航し失敗する確率が高いです。1回失敗しても繰り返し回数が多ければ目立ちません。
打ち合わせ回数による
しかしイテレーション期間はお客さんの拘束時間に依存します。 開発者と毎日同席*8できれば2週間以下のイテレーション期間も可能です。 週に一回丸一日の打ち合わせが設けられるなら一ヶ月のイテレーションが可能です。 2か月以上は繰り返し回数が少なくなるためお勧めできません。 分割納品しない方が安全です。
最終イテレーション
タスクはゼロに
最終イテレーションのタスクは少なくします。 ゼロが理想です。 お客さんが空白があるスケジュールを受け入れてくれない場合は、なるべく簡単な機能を配置します。
「当初に想定した機能を全部つくる」リスクに備える
受託開発には「当初に想定した機能を全部つくる」リスクが存在します。 イテレーションを繰り返すと「当初に想定した機能」より重要な新しい機能が見つかります。 そこでシステム担当者と調整し、要らなくなった機能の実装をやめ、新たに必要になった機能を実装します。 しかし最終納品直前に担当者の上司の方に、提案書に記載した「当初に想定した機能」を盾にひっくり返されることがあります。
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!で言われている
「アジャイル開発では当初に想定した機能を”全部”つくらない」
が成り立たないことが一般的です。
やっつけでもなんでもいいので「当初に想定した機能」を実現するためのバッファを用意しておいてください。身を守るための準備は大切です。*9
やった結果
話が速い
第2イテレーション以降は動くシステムを見ながら「ここを直してほしい」と具体的に修正案を出してもらえます。 修正で何かしらの影響が出る場合にも、画面を見ながら「ここを直すとこっちも直さないとまずいです」と具体的に提案すると伝わりやすいです。 紙の設計書からイメージした空想上のシステムの話をするよりも話が速いです。開発者と発注者、双方の決断コストが節約できます。
ソースが汚くなる
動いているシステムを変更していくとソースコードが汚くなります。 汚いソースコードはデバッグや機能追加の手間が増えるため、理想的には修正するたびにリファクタリングすべきです。
業務系の開発者にはリファクタリングできる人は少ないです*10。 繰り返して修正しているうちに変更が少ない部分が分かるので、変更されない部分は汚いままで良いと割り切ってしまうのも一手です。
汚くなると言っても一括納品で納品間際に仕様変更をたくさん受けた場合に汚くなるのと同じ程度です。
ドキュメント
アジャイルソフトウェア開発ではドキュメントを作らないイメージがあるかもしれませんが、ある程度必要です。
マニュアル・議事録
何回も修正していると、正しい仕様が分からなくなってきます。 特にしばらく修正していなかった機能の仕様は記憶があいまいになります。 以前と動きが変わったのが記憶違いなのか、バグなのか分からなくなります。 議事録やユーザマニュアル等をマメにメンテナンスしておくと混乱が防げます。
テーブル定義書
テーブル設計がわかるお客さんの場合は、テーブル定義書を作ると打ち合わせがスムーズになります。
仕様書・設計書
納品物として作成する仕様書や設計書などは最終イテレーションで作成すれば問題ありません。
システム担当者の学習速度が上がる
システムを理解するには作って動かしてみるのが一番です。 一括納品では受入試験からシステム担当者の学習が進みますが、 分割納品の場合は納品された機能から順次学習していくことができます。 必要な機能、必要でない機能などを明確に把握できるようになります。
学習速度が上がると担当者が上司の方との交渉に苦労することがあります。 担当者の方はどんどん学習しますが、上司の方があまりシステムを使っていない場合は学習速度が追いつきません。 前提知識の異なる相手との交渉は時間が掛かります。
受託の壁
分割納品にすれば受託アジャイルを始めることはできます。 しかし、受託である以上、ユーザー企業の「担当者より上の方々」を変えるのは難しいです。
これを指して
受託で顧客を巻き込む必要はないんじゃないか
と言われているのかもしれません。
受託でアジャイルソフトウェア開発をする上での今後の課題だと思います。
参考
アジャイルソフトウェア開発についてもう少し知りたい場合は次の本が参考になります。
おまけ
これは実はサムライ・エピソード - 達人出版会に書きたかった話です。大分伝わらない文章が書いてあるので気になる人が居たら読んでみてください。
*1:グラス片手にアジャイル開発 第4回 － ハイブリッドアジャイルの実践法
*2:特に後述の「当初に想定した機能を全部つくる」リスクがなくなります。ただし発注側は追加予算が必要になる可能性があり、柔軟な予算運用ができる会社でないと難しいです。
*3:開発期間中、メンバーを増減させながら開発する会社さんの場合には社内で受け入れられないかもしれません。転職してください。
*6:これにはデバッグの工数は含まれていません。バグが出ずにテストを完遂できればテスト要員を増やすことでカバーできますが、システム開発ではデバッグが進まずに試験が止まってしまうこともよくあります。
*7:受入試験は自動化する工数が大きく手動で実施した方が効率が良いことも多いです。
*8:オンサイト顧客
*9:バッファが余ったら追加の機能に使えばいいのですが、マーフィーの法則に則ってバッファを使い切った後に限ってこういった事態が発生します・・・。
*10:リファクタリングには「影響範囲を見極め、ソフトウェアが動かなくなる時間が最小な修正手順を設計する」専用のスキルが必要です。
