一括の受託開発でアジャイル
スクラムのコーチとしてトレーニングに参加したりすると、必ず契約の話題になります。(質疑応答で100%でてきます)
- 「うちは一括でしか契約できないのですが、スクラムではどうしますか?」
- 「リリース日を約束しないとなると、契約上の納期に遅れそうな場合どうしますか?」
- 見積もりした結果に利益加算して契約するかと思うのですがスクラムでの契約はどうするんですか?」
などなど。よく言われているように日本のエンジニアは受託開発に従事されている方が多いので、そりゃ質問したくもなるだろうなぁ、とは思います。ただ、身もふたもない言い方をしてしまえば、今のところ答えは「準委任契約ですね」となってしまいます。
もちろん、契約モデルについては様々な試行錯誤がされています。価値創造契約も一つの形ですね。ものすごく細かく(それこそスプリント単位で)請負契約を分割するやり方も実践されています。
ただ、従来のウォーターフォールで慣れ親しんだレガシーな企業の契約形態はそうやすやすと変わることはありません。たとえお客様担当者に理解があったとしても、法務や調達部門の壁を壊すのは、なかなかムズイ。
そこで今日は、私の知る限りで、「一括請負でアジャイルやれているケース」について説明してみます。
ベロシティ実測してリスク取る
まず、ウォーターフォールでもよくある形なのですが、要件定義を準委任でやって、基本設計以降を一括で、というパターンの応用です。
要件定義フェーズで要件定義を行う(要件定義書を書く)のではなく、実際にスプリントを回すことでベロシティを計測し、残りのバックログの開発に関しては、このベロシティを前提とした費用(必要な期間と人数をはじき出す)見積もりを行い、一括での契約を行います(もしくは、プロトタイプ開発を準委任契約範囲で行い、本開発を一括で行います)。
なので、「アジャイル開発に理解はあるが、諸々の事情で一括契約しかできないお客様」にしか使えませんし、当然、開発会社のリスクはなくなりません。一括契約なので事前に要件を洗い出す必要があるため(じゃないと検収できない)、やりたいこと(バックログ)が、安定している必要はあります。
持久戦に持ち込み徐々にアジャイルトランスフォーム
次は、比較的大規模なシステム構築をアジャイル化していくパターンで、いわゆるハイブリッドなアジャイルを経由し、元々ウォーターフォールな開発を、時間をかけてアジャイル化していくことになります。相当根気が必要ですが、実はこれが最も現実的な取り組みです。
当社でこの取り組みをうまく続けているチームを観察すると、いくつかのポイントを見つけることができます。
1.しっかりウォーターフォールを成功させチームを安定化させる
顧客との信頼関係を築くのはもちろん、安定したチームを作るためにも、ウォーターフォール開発を成功させます。この成功体験を持ったメンバーで、徐々にアジャイル化をしていくことになります。正しくウォーターフォールすることでドキュメントも揃うため、業務知識の形式知化も進みます。
2.リリースを3か月から6か月程度にステップ分けする
大規模なシステムの場合、ファーストリリースされた後に追加開発が行われることは多いでしょう。もしくは、最初から「機能ごとに、段階的にリリースしていきましょう」などという提案を行います。それぞれのリリースはすべて一括契約で行うため、これにノーを出すお客様は少ないかと思われます。
もちろん、一括の範囲を狭くすることでリスクを下げることが狙いですが、リリース期間を短く繰り返すことで、アジャイル開発のリズムに慣れてもらうという効果もあります。
3.プロジェクトファシリテーションからスタートし改善の癖付けする
ここから徐々にハイブリッド化させていきます。取り組むプラクティスはふりかえりと朝会からがやりやすく、スクラムマスター候補にファシリテーターを任せたり、スクラムのトレーニングを受けてもらったり、アジャイル開発をしている別プロジェクトのメンバーとの交流も開始します。
ただしこの時点ではウォーターフォール前提のため、タスクはサインアップではなくリーダーによるアサインであったり、報告のためにガントチャートを作成しています。
自己組織化と機能横断的チームについては、次で説明する育成とワンセットで時間をかけて取り組みます。
4.育成には時間をかける
アジャイル化に向けた大きな課題はいわゆるT字型人材の確保・育成です。ウォーターフォール組織の場合、設計とプログラミングで担当が分かれてしまうことになりますが、アジャイルチームでは全員が設計とプログラミング両方できる必要があります。
これを実現するには、エンジニア本人がそうなりたいと思えないと本当にダメで、チームのサポートだけでなく、部署・会社組織としての取り組みが必要です。年間を通じた個人面談や各種勉強会の開催、資格取得に対する支援など、組織としてやれることは多いです。
5.ウォーターフォールの中に本物のアジャイルチーム
メンバーの意識とスキルが整い、お客様の信頼も高めた状態になってから、プランニングやサインアップ、バーンダウンチャートなど、その他のプラクティスを導入していくことで、ウォーターフォールの中に本当のアジャイルチームを作り出すことが可能です。
ちなみに、今回引き合いに出したプロジェクトは、ここにいたるまでに約2年かけています(ただし、「バーンダウンからガントチャートへの変換」は継続中ですが、必要コストとみているようです)。
6.要件定義という名のバックログリファインメント
今でも要件定義は実施しており、要件定義書もしっかり作成します。ただし、今では要件定義作成と開発期間をオーバーラップさせることで、すぐに次のステップの開発に入れるようになってきています。スクラムにおけるバックログのリファインメントとは意味合いは違いますが、そのステップに盛り込みたいストーリーすべてを「Readyの定義Done」にしておくイメージです。
7.お客様にアジャイルの良さをアピールし続ける
こうして時間をかけて実績を積み重ねながら、お客様にはアジャイル開発の意義をご提案というか啓蒙し続けます。 そして実は、時間をかけることのもう一つのメリットは、「世の中が追い付いて偉い人の耳にもアジャイルが届くようになってくる」こと、かもですね。
本当に大事なものは何?
現在はプロセスとしてはハイブリッド状態であり、完全なアジャイル化にはまだ時間がかかると考えています。ただ、安定し、自己組織化されたチームが実現できたことは、何事にも変えられない成果だと考えますし、ゆくゆくは、契約を一括から準委任に切り替えていくことも可能だと思えます。
ずいぶん長くなってしまいました。。いろいろ他にも書きたいことはありますが、もしよろしければ、続きは是非現場に見学に来て、実際のチームにいろいろ質問してください!ということで、宣伝しつつ締めたいと思います。(以下ページに見学申し込みフォームがあります)