agileTweet3つの大事なことまず全ての受託開発に適用できるかというと、それは難しいと考えています。これまでクレイに発注いただいた開発で、次のような案件に適用してきました。要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。次に規模ですが大きくても3,4人で半年から一年程度の小規模な開発が多かったです。これまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。次の3つが進めていくために大事なことと感じています。クライアントにプロジェクトに責任を持って参加してもらうアジャイルに適した契約にする開発プロセスを出来るだけ透明化するクライアントにプロジェクトに責任を持って参加してもらう「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでしょうか。責任を持って参加していないのでしょうか。本来クライアント自身のプロジェクトなので責任を持って参加していないことはありませんが、発注して任せておけばいいものが出来上がるだろうと思ってしまう部分があるのだと思います。私は、どこまで深入りしてもらうかが重要だと考えています。深く関わることでクライアントと受注側が一つのチームになり、目標を共有し、最大限に力を発揮し合うことができるようになります。お互いが責任を持って注力していれば、甘えを許さない緊張感を持ったチームとなります。弊社で受けているプロジェクトのいくつかは次のような関わり方をしてもらっています。関わり方かんがえるシート、ペルソナ、ユーザーストーリーマッピングなどを一緒に作る実際にシステムを作る前に、アプリやサービスのコンセプトや機能を見直し、少しでもムダな開発を減らして、本当に必要なものだけを作ることを目指します。ユーザーストーリーをタスク管理に追加して、優先順位を設定するユーザーストーリーとは利用者の視点から語られた要求仕様を簡潔に表したもので、開発チームは優先順位に並んだユーザーストーリーを一つずつ開発していきます。クレイではユーザーストーリー毎に受入条件や画面イメージなどが書かれています。クライアントだけではなく弊社側のPMも一緒に追加していきます。Googleハングアウトで毎朝10分程度のミーティングに参加してもらう開発チームの朝会に参加してもらうことで、コミュニケーションロスを防げるだけでなく、クライアントと開発者全員がビデオ会議をすることで、チーム意識が高まります。1ヶ月に一度ふりかえりをするお互い言いにくいことも月に一度ぐらいは出し合います。クライアントと開発チームでは視点が全然違うため、ふりかえりをすると意外なことを発見できたりします。(開発チームは一週間に一度ふりかえりをします)クライアントからすると面倒くさいと思ってしまうかもしれません。手間をかければかけるほど、よりいいものを作りたいという欲求に変わってきます笑クレイでは弊社側のPMがプロダクトオーナーとなって、ユーザーストーリーの洗い出しや受入条件の作成、各ユーザーストーリーの動作確認を行うことでクライアントの手間を減らすように意識しています。アジャイルに適した契約にする日本のソフトウェア開発では一括請負契約が多いと思われます。一括請負契約は、あらかじめ決まった仕様から開発期間と費用を見積もり、開発を行い、出来上がった成果物に対して費用が支払われます。開発期間と費用の見積もりについては、仕様変更を考慮して見積もりに上乗せします。仕様が決まっていて変更が少ない場合は一括請負契約で問題はありません。あるパターンなのですが基本アイデアは決まっていて詳細は詰まっていない場合は難しいことが多いです。全体を無理矢理見積もろうとするために、曖昧な仕様が多く、バッファの上乗せが大きくなってしまうことに、いつもモヤモヤしたものを感じていました。どちらにとっても不健康な感じですね。一つの契約形態が準委任契約です。決められた期間、契約した業務を精一杯がんばる(善管注意義務)契約です。エンジニアがクライアント先に常駐する時によく使われる契約ですが、海外ではアジャイル開発時に採用されることが多いようです。「いつ完成するかわからない」「コストが見えにくい」といったことがあるため、日本では採用が進んでいません。クレイでは準委任契約で受ける場合、「いつ完成するかわからない」「コストが見えにくい」というリスクを回避するために、開発前にサービス設計のフェーズを設けてもらう場合があります。サービス設計のフェーズではかんがえるシートの作成、ペルソナ設計、ユーザーストーリーマッピングを行い、主要機能を洗い出して、概算見積もりを行います。準委任契約のメリットはもちろん仕様変更に対応しやすいということもありますが、プロダクトの価値にフォーカスしやすいことです。一括請負契約の場合、仕様変更があれば当初の見積額に影響があるため、価値のある仕様変更でも提案しづらい場合があります。準委任契約の場合は、仕様変更を恐れず、積極的に提案していくことができます。工数を大きくするためにムダな開発をすることはあってはいけません。そのために透明性のある開発にする必要があります。開発プロセスの透明化については後述します。一括請負契約は受注側のリスクが大きく、準委任契約は発注側のリスクが大きいため、それぞれを組み合わせた契約もあるようです。アジャイル開発の契約方法に書かれている工数比例部分と成功報酬部分を組み合わせた契約など、ぜひ採用してみたい契約です。他の契約については、下記の記事が参考になりました。アジャイル開発を円滑に行うための契約モデルを考える開発プロセスを出来るだけ透明化する先ほど準委任契約の説明で透明性のある開発が重要と書きましたが、契約に関係なく、またアジャイルだろうとウォーターフォールだろうと開発プロセスを透明化するのは大事なことです。発注側から見て、何をやっているかわからないでは信頼関係は生まれにくいと思います。クレイでは次のようなことで透明化を図っています。透明化した結果、クライアントにとって次のようなメリットがあると思います。透明化のメリット日々進んでいることを実感できる常に出来上がっている最新の動作を確認できる安心して任せられる見えることで参加しやすくなる楽しい?楽しいです。アジャイルだから楽しいというわけではなく、いいプロダクトを作るために、発注側と受注側が一緒になって、日々改善を繰り返して、プロダクトも、チーム全体も良くなっていくことを実感できるのが楽しいです。大事なことは価値のあるプロダクトを作ることなので、そのために受託開発でもアジャイルを選択肢の一つとして採用できるようにしていきたいですね。Consoleで限られた操作ができるユ...「いいね!」で応援よろしくお願いします!このエントリーに対するコメントコメントはまだありません。date*日本語が含まれない投稿は無視されますのでご注意ください。fax.0422-26-9781お問い合わせはこちらからどうぞ。