3つの大事なこと

まず全ての受託開発に適用できるかというと、それは難しいと考えています。
これまでクレイに発注いただいた開発で、次のような案件に適用してきました。

  • Webサービス
  • スマートフォンアプリ
  • プロトタイプ、研究開発

要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。
次に規模ですが大きくても3，4人で半年から一年程度の小規模な開発が多かったです。

ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。
特に次の3つが進めていくために大事なことと感じています。

  • クライアントにプロジェクトに責任を持って参加してもらう
  • アジャイルに適した契約にする
  • 開発プロセスを出来るだけ透明化する

クライアントにプロジェクトに責任を持って参加してもらう

「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでしょうか。
責任を持って参加していないのでしょうか。
本来クライアント自身のプロジェクトなので責任を持って参加していないことはありませんが、発注して任せておけばいいものが出来上がるだろうと思ってしまう部分があるのだと思います。

私は、どこまで深入りしてもらうかが重要だと考えています。
深く関わることでクライアントと受注側が一つのチームになり、目標を共有し、最大限に力を発揮し合うことができるようになります。
またお互いが責任を持って注力していれば、甘えを許さない緊張感を持ったチームとなります。

例えば、弊社で受けているプロジェクトのいくつかは次のような関わり方をしてもらっています。

関わり方

  1. かんがえるシート、ペルソナ、ユーザーストーリーマッピングなどを一緒に作る
    実際にシステムを作る前に、アプリやサービスのコンセプトや機能を見直し、少しでもムダな開発を減らして、本当に必要なものだけを作ることを目指します。

  2. ユーザーストーリーをタスク管理に追加して、優先順位を設定する
    ユーザーストーリーとは利用者の視点から語られた要求仕様を簡潔に表したもので、開発チームは優先順位に並んだユーザーストーリーを一つずつ開発していきます。
    クレイではユーザーストーリー毎に受入条件や画面イメージなどが書かれています。クライアントだけではなく弊社側のPMも一緒に追加していきます。

  3. Googleハングアウトで毎朝10分程度のミーティングに参加してもらう
    開発チームの朝会に参加してもらうことで、コミュニケーションロスを防げるだけでなく、クライアントと開発者全員がビデオ会議をすることで、チーム意識が高まります。

  4. 1ヶ月に一度ふりかえりをする
    お互い言いにくいことも月に一度ぐらいは出し合います。
    クライアントと開発チームでは視点が全然違うため、ふりかえりをすると意外なことを発見できたりします。（開発チームは一週間に一度ふりかえりをします）

クライアントからすると面倒くさいと思ってしまうかもしれません。
でも手間をかければかけるほど、よりいいものを作りたいという欲求に変わってきます笑
クレイでは弊社側のPMがプロダクトオーナーとなって、ユーザーストーリーの洗い出しや受入条件の作成、各ユーザーストーリーの動作確認を行うことでクライアントの手間を減らすように意識しています。

アジャイルに適した契約にする

日本のソフトウェア開発では一括請負契約が多いと思われます。
一括請負契約は、あらかじめ決まった仕様から開発期間と費用を見積もり、開発を行い、出来上がった成果物に対して費用が支払われます。また開発期間と費用の見積もりについては、仕様変更を考慮して見積もりに上乗せします。

すでに仕様が決まっていて変更が少ない場合は一括請負契約で問題はありません。
よくあるパターンなのですが基本アイデアは決まっていて詳細は詰まっていない場合は難しいことが多いです。
全体を無理矢理見積もろうとするために、曖昧な仕様が多く、バッファの上乗せが大きくなってしまうことに、いつもモヤモヤしたものを感じていました。
上乗せが大きくなってしまうため、発注側は高いと感じ、受注側はリスクが大きくて受けられないといったことが発生します。
発注側、受注側、どちらにとっても不健康な感じですね。

もう一つの契約形態が準委任契約です。
決められた期間、契約した業務を精一杯がんばる（善管注意義務）契約です。
エンジニアがクライアント先に常駐する時によく使われる契約ですが、海外ではアジャイル開発時に採用されることが多いようです。
しかし「いつ完成するかわからない」「コストが見えにくい」といったことがあるため、日本では採用が進んでいません。

クレイでは準委任契約で受ける場合、「いつ完成するかわからない」「コストが見えにくい」というリスクを回避するために、開発前にサービス設計のフェーズを設けてもらう場合があります。
サービス設計のフェーズではかんがえるシートの作成、ペルソナ設計、ユーザーストーリーマッピングを行い、主要機能を洗い出して、概算見積もりを行います。

準委任契約のメリットはもちろん仕様変更に対応しやすいということもありますが、プロダクトの価値にフォーカスしやすいことです。
一括請負契約の場合、仕様変更があれば当初の見積額に影響があるため、価値のある仕様変更でも提案しづらい場合があります。
準委任契約の場合は、仕様変更を恐れず、積極的に提案していくことができます。
もちろん工数を大きくするためにムダな開発をすることはあってはいけません。
そのために透明性のある開発にする必要があります。
開発プロセスの透明化については後述します。

一括請負契約は受注側のリスクが大きく、準委任契約は発注側のリスクが大きいため、それぞれを組み合わせた契約もあるようです。
アジャイル開発の契約方法に書かれている工数比例部分と成功報酬部分を組み合わせた契約など、ぜひ採用してみたい契約です。

他の契約については、下記の記事が参考になりました。
アジャイル開発を円滑に行うための契約モデルを考える

開発プロセスを出来るだけ透明化する

先ほど準委任契約の説明で透明性のある開発が重要と書きましたが、契約に関係なく、またアジャイルだろうとウォーターフォールだろうと開発プロセスを透明化するのは大事なことです。
発注側から見て、何をやっているかわからないでは信頼関係は生まれにくいと思います。

クレイでは次のようなことで透明化を図っています。

開発プロセスの透明化を図る方法

  1. 朝会に参加してもらって毎日進捗を共有
  2. githubなどでのコードレビューの公開
  3. PivotalTrackerなどタスク管理に参加
  4. Jenkinsなど継続的インテグレーションの公開
  5. チームの稼働日数の公開

透明化した結果、クライアントにとって次のようなメリットがあると思います。

透明化のメリット

  1. 日々進んでいることを実感できる
  2. 常に出来上がっている最新の動作を確認できる
  3. 安心して任せられる
  4. 見えることで参加しやすくなる

楽しい？

楽しいです。
アジャイルだから楽しいというわけではなく、いいプロダクトを作るために、発注側と受注側が一緒になって、日々改善を繰り返して、プロダクトも、チーム全体も良くなっていくことを実感できるのが楽しいです。

大事なことは価値のあるプロダクトを作ることなので、そのために受託開発でもアジャイルを選択肢の一つとして採用できるようにしていきたいですね。