天野 充広さん
  • コラボレーター
  • 株式会社クレイ
  • 天野 充広

受託開発におけるアジャイル開発

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet

はじめに

クレイはWebサービスやアプリ開発の依頼を受けて開発を行っています。その他、DocBaseという企業向けの情報共有サービスも開発、運営しています。

以前、受託開発にアジャイルは適用できるかという記事を書いてから2年半経った今では、受託開発でもアジャイルな開発を行いやすくなってきました。その後の経験や改善などを加筆修正したいと思います。

今回の記事は依頼を受ける開発会社の立場で書いていますが、アジャイルな開発でサービスを開発したいと考えている発注する側の方にも参考になると思います。

3つの大事なこと

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

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

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

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

  • プロジェクトのビジョンや目標の共通認識を持つ
  • アジャイルに適した契約にする
  • 開発プロセスを出来るだけ透明化する

それでは1つひとつ、具体的に説明していきます。

プロジェクトのビジョンや目標の共通認識を持つ

「クライアントにプロジェクトに責任を持って参加してもらう」ことは、ここ数年で当たり前になってきたように感じます。もう一歩進めて、「プロジェクトのビジョンや目標の共通認識を持つ」を大事なことだと今は考えています。これは、ビジョンや目標を発注側と受注側が共有することで、ひとつのチームになり、最大限に力を発揮し合うことができると感じているからです。

共通認識を持つために、弊社で受けているプロジェクトのいくつかでは次のようなことを行っています。

1. サービス設計を一緒に行う

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

2. ユーザーストーリーをタスク管理に追加して、優先順位を設定する

ユーザーストーリーとは利用者の視点から語られた要求仕様を簡潔に表したもので、開発チームは優先順位に並んだユーザーストーリーをひとつずつ開発していきます。クレイではユーザーストーリー毎に、受入条件や画面イメージなどを記載しています。クライアントだけではなく、弊社側にいるプロダクトオーナーのサポートを行うメンバーも一緒に追加していきます。

3. Googleハングアウトで毎朝10分程度のミーティングに参加してもらう

クライアントにも開発チームの朝会に参加してもらうことで、コミュニケーションロスを防げるだけでなく、全員のチーム意識が高まります。

4. ふりかえりをする

開発チームは毎週ふりかえりを行っていますが、クライアントにも可能な限り参加をお願いしています。クライアントと開発チームでは視点が全然違うため、ふりかえりをすると意外なことを発見できたりします。

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

ふりかえりについてはこちらをご参照ください。

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

日本のソフトウェア開発では一括請負契約が多いと思われます。

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

すでに仕様が決まっていて変更が少ない場合は、一括請負契約で問題ありません。よくあるパターンなのですが、基本アイデアは決まっていて詳細は詰まっていない場合は難しいことが多いです。

なぜなら全体を無理矢理見積もろうとするために、曖昧な仕様が多く、バッファの上乗せが大きくなってしまうのです。そこにいつも、モヤモヤしたものを感じていました。上乗せが大きくなってしまうため、発注側は高いと感じ、受注側はリスクが大きくて受けられないといったことが発生します。発注側、受注側、どちらにとっても不健康な感じですね。

もうひとつの契約形態が準委任契約です。決められた期間、契約した業務を精一杯がんばる(善管注意義務)契約です。

エンジニアがクライアント先に常駐する時によく使われる契約ですが、海外ではアジャイル開発時に採用されることが多いようです。しかし「いつ完成するかわからない」「コストが見えにくい」といったことがあるため、日本では採用が進んでいません。

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

準委任契約のメリットは、もちろん仕様変更に対応しやすいということもありますが、プロダクトの価値にフォーカスしやすいことです。一括請負契約の場合、仕様変更があれば当初の見積額に影響があるため、価値のある仕様変更でも提案しづらい場合があります。準委任契約の場合は、仕様変更を恐れず、積極的に提案していくことができます。

もちろん工数を大きくするためにムダな開発をすることはあってはいけません。そのために透明性のある開発にする必要があります。開発プロセスの透明化については後述します。

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

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

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

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

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

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

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

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

最後に

楽しい?

楽しいです。

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

またプロジェクト毎に課題は違うし、改善の方法も違います。その繰り返しが成長へと繋がっていると感じます。大事なことは価値のあるプロダクトを作ることなので、そのために受託開発でもアジャイルを選択肢のひとつとして採用できるようにしていきたいですね。

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet