請負開発とプロダクト開発のどっちに向いているか
アジャイルについて書かれている記事の多くは、請負開発プロジェクトではなくプロダクト開発を題材に論を張っています。MIJSのメンバーもまたパッケージベンダなのでプロダクト開発にアジャイルを適用しています。しかし、アジャイルはプロダクト開発には威力を発揮するけれど、請負開発には不向きなのでしょうか。
アジャイル信者なら間髪を入れずに（何も考えずに）、“もちろん大丈夫”と言うでしょう。でも、それならなぜ請負開発でのアジャイル適用の事例をあまり見ないのでしょう。筆者は、冷静に考えればやはり請負よりプロダクト開発や社内システム開発のほうがずっと向いて適用しやすいと思っています。
アジャイル最大のメリットはプロダクト開発に最適
ところで、アジャイル開発の最大の利点は何だと思いますか。生産性が上がる？ 品質が良くなる？ 楽しく仕事ができる？ いろいろな解答が出て来そうですね。筆者は「良いシステムが出来上がる」というメリットを一番享受しています。
開発の最中に何回もユーザー（オンサイト顧客）が制作途中のソフトを見て「これはちょっと使いにくい」「もう少しこうできない？」などとコメントできるので、出来上がったモノがユーザーにとって満足のいくものになります。ウォーターフォールでありがちな「こんなシステムを頼んだつもりじゃなかった」というはめになりにくいのです。
この特長は、プロダクト開発や社内システム開発には最適です。筆者も社員によく言っているのですが、プロダクト開発は作るのが目的ではなく、売れることが目的なのです。逆に言えば、納期を守り予算の範囲内で仕様どおりにできたとしても、売れないような製品なら元も子もありません。
この場合の売れる製品とは“顧客がお金を出してでも購入する”というものであり、ここでは完全に顧客視点での価値が求められます。つまり“当たり前品質”ではなく“前向き品質”が重要視されるのです。たとえ当初言ったことと違っても「こうするともっと良くなる」「こうしないと売れないなぁ」と思ったことは、どんどん取り入れていかなければなりません（あまりに多いので、いつも開発メンバーに恨まれてしまいますが……）。ウォーターフォールの場合、終盤段階でこうした改良点に気づくため、時すでに遅しで結局不満足なものを世の中に出してしまうはめになります。
請負開発に導入する際の課題
この「良いシステムが出来上がる」という特性は、請負開発でも一緒です。ただし、請負開発の場合は、次の2つの課題があります。
- 最初にスコープ（開発範囲）を契約で取り決める必要がある
- 忙しい顧客に開発途中のチェックを頻繁に頼みづらい
1の課題について
例えば、生産管理システムの開発を請け負ったとしましょう。要件定義を委任契約（1人月いくらという契約）で行なって、画面70、帳票20、バッチ処理10という機能を洗い出しました。各機能の難易度を基に開発コストを算出し、基本設計からカットオーバーまでの作業コストを3000万円と見積もって顧客と4000万円で契約したとします。
ウォーターフォールの場合、モック（まめ知識「モックとは」を参照）や設計書（紙）などを使って仕様を打ち合わせて基本設計書を作成し、レビューのコメントを反映したものを承認してもらったら基本設計工程は終了です。“仕様FIX”ということで、これ以降の仕様変更は原則として受け入れないか別途追加費用（日数追加も）がかかることになります。ウォーターフォール式が開発側にとってコストやスケジュールを計画しやすいのも一理ありますね。
もともとはモックアップ（木型）のことで、製品の外観の検討や機能の確認のために作られる模型を意味します。ソフトウェア開発においては、画面モック（モックアップ）と称して実際に即した簡単な画面を作成して、ユーザーにイメージや仕様を把握してもらいます。アジャイルはもちろん、ウォーターフォール方式の場合でも、紙ではなくこうしたモックを作って仕様確認するケースが増えています。
一方、アジャイル開発の場合は“仕様FIX”がなかなかできません。設計とプログラミングを同時並行的に行ない、都度確認してもらって変更を受け入れるという形なので開発者側にとってコストやスケジュールが収まるかどうかは最終段階まではっきりしません。確かに出来上がったモノの顧客満足度は高いでしょうが、営利目的のビジネスでやっているのでこうしたリスクを持ちながらの進行には二の足を踏むことになります。
2の課題について
顧客の協力体制という点でも課題があります。ウォーターフォールの場合は、基本設計工程と総合テスト工程が主に顧客が関わるところで、詳細設計～プログラミング～単体テスト～結合テストなどはレビューのような形で加わる程度です。なので、通常は自社の業務をこなしながら要所要所でこうした確認作業を行なうような兼務体制でプロジェクトに参画します。
一方のアジャイルの場合は、開発期間を通して“オンサイト顧客”（まめ知識「オンサイト顧客とは」を参照）の役割でずっと確認および仕様決定作業に関わらなければならず、実質的に開発現場に“常駐”してもらうことが求められます。慣れない顧客にとっては「プロに金を払って開発を依頼しているのに、いつのまにか自分が開発チームの一員にさせられている」ということで抵抗もあるでしょう。
また、大規模な基幹業務の場合は各部門ごとに業務の分かるエンドユーザーのキーマンがいるため、「現業があるのにとても全員参加させるのは無理」というような現実もあります。
開発チームに対してユーザー（顧客）の立場で意見や要望などを言う役割を担います。開発側の一員ではなく（金を出す）ビジネス組織側の人間ではありますが、オンサイトという名前のとおり開発チームの一員として開発プロジェクトに参画することが求められます。XPの中で紹介されているプラクティス（手法）の1つではありますが、ウォーターフォール開発においても実現できるのなら、仕様の誤解が生じにくい、判断や仕様決定が早いなど効果は大きいでしょう。
