政府のアジャイルやら契約やらなんやら

政府でも最近アジャイルが・・・なんて言いますが。

最近は、政府でもアジャイル開発と銘打ったプロジェクトをポツポツと見かけるようになりました。でも、正直言って、本物のアジャイルというものには、私個人、まだ出会ったことがありません。残念ながら。。。

まず、行政機関においては、まだアジャイル開発と親和性が高いと言われる準委任契約が請負に劣後して考えられる傾向が強いようです。予算要求をするときもにしてもIT室や財務省はもとより、省内でも、明確な成果物を定義しにくい準委任は説明が面倒ですし、会計検査のときにも「何を作ったのか、費用対効果はあるのか？」と問い詰められることを考えると、どうしても請負契約になりがちです。なので、どちらかというと、アジャイルらしく、バックログの優先順位を定めたり、場合によっては実装する機能の追加や削除を行うアジャイル開発らしいやりかたはせず、ただ、開発フェーズを細かく区切って、ユーザーが早めに動くものを見る機会を作ろうというところだけ、アジャイルのやり方を貰ってみようというプロジェクトが比較的多いような気がします。もちろん、J-Grantsの開発のように準委任でアジャイルというのもあるにはありますが、それも仕様書を見るとやはり"成果物"を明記しており、うーんやっぱりね。という感は否めませんでした。
このあたり、ここ数年で民間企業とは随分と差がついてしまった気がしますし、英国政府のGDSなどと比べると、随分遅れた感もあります。

政府も二の足を踏むアジャイルの危険

確かに、一般的にアジャイルには危険もあります。成果物が明確でないことから、いつまでも開発が終わらず、特にユーザー側にコストばかりがかさんでしまうことなどもそうでしょう。政府で言えば、一年たっても結局何も出来上がっておらず、全てが来年以降の開発に後ろ倒しされるようなことは、さすがに許されません。

いつまで経っても結果が出ないアジャイル。これを避けるためには、本来、アジャイルは、機能ではなく、例えば１年後に実現したい業務の姿やメリットを目的として捉えてやるべきだし、中間のマイルストーンまでに出来ていることを定め、その範囲において機能の抜き差しや作業順の入れ替えを行うものだという認識をもう一度確認する必要があります。機能ではなく実現したい業務を目的として定義し、それに向けて行うべき作業は、変更可能にする。そうした契約が必要なのだと思います。

マインドチェンジしましょ。アジャイルはシステムづくりではありません。

アジャイルで大切なのは機能ではなく、業務やメリットなので、プロジェクト中に必ずしも必要ないと感じたら、機能自体を捨ててしまうことも大切です。お年寄り向けに分かりやすい画面を作ろうと思ったが、やはりそれよりは紙を事務集中センターに送ってもらい、代理入力した方が良い。その方が顧客満足度が上がり、効率的でもあるという判断なら、お年寄り向け機能を落としてしまうこともできる。そこがアジャイルの醍醐味の一つだし、やっぱり、そうしたことをしたければ準委任契約なんだろうと思うわけです。目的とマイルストーン、機能の抜き差しの考え方、バックログにおける優先順位の付け方、変え方等について契約に明記することも有効だと思います。

また、アジャイル開発の危険としてはユーザー側の負担の大きさというのもあります。これはユーザー側の組織・体制に関わる問題です。ユーザー側担当者が開発への参加を"本業"として捉えることが必要。メッセージング、査定、組織など。その上で、大切なのが会議体計画。どの会議で何を決めるから誰々には必ず出席してほしい旨を契約書の別紙としてはどうかと思う。会議欠席はそのままリスクとなることも認識してほしいと思います。

契約書について言えば、繰り返しになるが契約の目的を分かりやすく具体的に書くこと、スプリントレビューやテストなどを双方が協力しておこなうこと。スクラムマスターやプロダクトオーナーなどの役割と責任を具体的に記述することなどが求められると、そんな風に思います。