アジャイル開発について思うこと
自分は前職Estoniaの技術を日本に持ってくるスタートアップ企業にいたため、どっぷりアジャイル開発（正確にはSCRUM開発）に使っていた。今回、自分が大企業において受託開発でアジャイル開発工程を採用したプロジェクトに参画して、以下の記事と同じようなことを感じた。
公共調達は完成物を受け取る前提で契約を結ぶ。アジャイル開発は「どこで成果物を受け取ったことになるのかが決めにくい」（開発契約に詳しい足立昌聡弁護士）。なじまないのも当然だ。
国立情報学研究所の佐藤一郎教授は「アジャイル開発やクラウド利用では、事前に費用の全体像を見積もることが難しく、入札を通じた調達がしづらい。専用の基金を作っておくなど予算の作り方を柔軟にする必要がある」と説く。米国では、連邦政府が認定したクラウド事業者からあらかじめ価格表を提出してもらうことで「機動的に契約できるようにしている」（吉田室長）という。
大企業も公共調達と同じで、完成物を受け取るという考え方であり、予算も既に決まっているものが多い。この形式だとアジャイル開発にはそぐわない。
また、私の関わったプロジェクトも典型的な事例だと思われるが、施主側がアジャイル開発を希望したのではなく、開発ベンダー側がアジャイル開発工程で進めるという提案をしてきたことに流された形であったのもプロジェクトを難しくした一因であると考える。
アジャイル開発は
・顧客のニーズを取り入れ、顧客と開発項目を決め、
・開発（改善）を実施し、
・出来上がったものをすぐ確認してもらう
というサイクル（スピリント）を短期間（通常２週間単位）で回していく工法で、こうすることによって、顧客の求めるものが開発しやすいとされている。ウォーターフォール開発における検収段階で顧客ニーズと違うものが出来上がるということは避けられる工法である。
これもよくアジャイル開発においてよく出る話題です。
『アジャイル開発 vs ドキュメント』
上記記事にも記載されていますが、誤解の根幹は以下の文面でしょう。
＜アジャイルソフトウェア開発宣言＞
包括的なドキュメントよりも、動くソフトウェアを（価値とする）
原文：Working software over comprehensive documentation
（参照先）http://agilemanifesto.org/iso/ja/manifesto.html
よく言われていますが、アジャイル開発においてドキュメントは要らないとは言われていないです。動くソフトウェアの方が優先されるというだけで、開発後のメンテナンスや次期バージョン開発が同じメンバーで継続されるわけではないため、ドキュメントはコミュニケーションの一つとして重要です。
こちらも面白いスライドなので、記録として残しておきたい。
■所感
私は良いプロダクトを作り上げるにはアジャイル開発は最適だと考えています。ただし、アジャイル開発を進めるのに適しているのは、
・自社サービス開発のケース
・施主側がアジャイル開発をしっかり理解して進めら得るケース
だと考えています。
こういうことを理解・判断できる人材（ＤＸ人材）が企業側に必要でありますが、絶対的な人数が足りないというのが現状だと認識しています。
ここにこそ、弊社が貢献したい機会点があると考えます。