Q. 社内でアジャイル開発標準を作るときの注意点を教えてください
アジャイルソフトウェア開発宣言では、
よりよい開発方法を見つけだそうとしている
とあり、またこれに付随する「アジャイルソフトウェアの12の原則」では
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します
とあります。 これらが意味するのは、どんな形で開発するといいのかはチームごとに違うこと、それぞれのチームが自分たちの状況にあわせて改善していくことに価値があるということです。 つまり、アジャイル開発標準を作って、それを強制することは、アジャイルの価値観そのものを毀損することになります。
誤解を避けるために繰り返しますが、アジャイル開発の標準を作ること自体は役に立つ可能性はあります。 ですが、この利用や遵守を強制してはいけません。強制したところで標準化自体が生産性や成果の向上につながるわけではありません。 あくまで、チームが「よいよい開発方法を見つける」のに役立てることを目的にしましょう。 つまり、テンプレートとして使えそうなものを集めておき、みんなが自由に使えるようにしておくということになります。 その前提で、標準を作るようにしてください。
また、標準を作るときは、理想論を文書化するのではなく、うまくいったチームをベースにして考えるようにしてください。 理想論を標準にしたところで、自分の組織やチームで役立つかどうかはまったくわかりません（つまり、外部のコンサルタントにアジャイル開発標準を作ってもらおうとするのは悪手です。止めましょう）。 一方で、うまくいったチームをベースにすれば、組織特有のコンテキストなども踏まえたものになっている可能性があるためです。
開発標準とは少し離れますが、リリースプロセスやQAプロセスのような「規定」についてもあわせて考えておきましょう。 組織がそれなりの規模になると、組織でリリースやQAの規定を持っていることが多いです。 もし、この規定が従来型開発手法を元に作られているのであれば、その規定はアジャイル開発の足を引っ張る可能性が高いです。 このような場合は、スクラムマスターやプロダクトオーナーが中心となって、組織に対する働きかけをして、アジャイルなやり方にあったQAやリリースができるように規約の変更を働きかける必要があるでしょう。
