標準化のトレードオフ その６ - スクラムの形式知が大切な理由 -

標準化のトレードオフで最も気になるのは、スクラムが規律であることです。

実装優先の視点で考えるとアジャイル開発は、実装優先時に考慮すべき点をパッケージングした開発法です。アジャイル開発には実装優先に、自律的組織、繰り返しのリズム、メトリクスやふりかえりによる改善といった特長が加えられています。

そのようなアジャイル開発の代表格であるスクラムを標準化のトレードオフで考える前に、歴史を振り返ってみましょう。

アジャイルと規律

ベーム先生が「アジャイルと規 律 ～ソフトウエア開発を成功させる２つの鍵のバランス～ 」という本を出されたように、アジャイル開発1次ブームを牽引したXP(extreme programming)は、標準プロセスの規律のアンチテーゼとしてとらえられました。

ベーム先生は「アジャイルと規律」で、TSP/PSPを規律の例、XPをアジャイルの例として挙げています。共に会議を開きますが、TSP/PSPでは規律に従って再計とドキュメントの変更とレビューを休日出勤を含めて行い、XPではスコープの変更とテストコードを使ったリファクタリング(変更)の様子を示しつつ、そこでCRACKと呼ぶ顧客の代表に求められる特性を示しています。

CRACKは、協力的(Collaborative)、意見を代表する(Representative)、権限を持つ(Authorized)、献身的(Committed)、知識がある(Knowledgeble)の略です。XPは価値(価値観)とプラクティスを定めて開発者たちの自律的なチームづくりを推進しますが、開発チームと顧客との関係の規律は定められていなかったのです。

スクラムの特徴

スクラムは組織パターンを考慮したアジャイル開発のフレームワークです。開発チームだけではなく、プロダクトバックログを管理するプロダクトオーナーというロールなどが定められています。

プロセスをどのように構成するか、必要最低限の標準化によって一から考えなくて良いようにフレームワークが形式知として構成されています。スクラムが特徴的なのは、認定スクラムマスターを初めとする多くの資格が研修で与えられることです。

フレームワークという標準の形式知を与えながら、研修による暗黙知で正しい方向に導くというバランスの取れた仕組みができています。

標準化の危険性

しかし、これも標準化であるので、思考停止に陥り易い、問題を見極めなくなる、応用できない、過去の経験に引きずられる、といった問題の可能性があります。

このような危険性があるのは、規律が形式知である一方で、アジャイル開発の良さは文章では伝えにくく、主に経験を通じた暗黙知で伝達されるからです。特にトップダウンアプローチで導入される場合は形骸化しやすい危険性があります。

一般に、コミュニケーションや自律的な組織、サーバントリーダーシップといった経験を通じた方が得易い暗黙知は、管理が容易な規律という形式知に比べて、以下のような特性があります。

• 経験が必要なので伝わるのに時間がかかる
• 連結による組合せや体系化ができない（参考：[#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん＠SEA関西 - ）
• 様々な制約や政治的な理由から自律よりも管理が優先され易い

スクラムの形式知

このような規律の特性に引っ張られないためには、スクラム開発で大切なことをきちんと学ぶしかありません。勉強会などを利用して、スクラムを味方につけることが大切です。

しかし、上述の様にそのスピードは規律に比べて遅く、組織的な導入には追いつきません。そこで、アジャイル開発とスクラムでその基本を学び（壁を打ち破れ！ - アジャイル開発とスクラムを読んで -）、SCRUM BOOT CAMP THE BOOKを読んで実践方法を学んでおく必要があると思います（日本文化に仕立て直した実践書、使えるアジャイル開発の本、学び 、工夫が凝らされた構成、日本でスクラムを実践するなら読んでおきたい本）。このような経験を形式知化した情報が、組織的な導入には必要です。

アジャイル開発でも、アジャイル開発だからこそ、形式知として公開し、学ぶことはとても大切だと思います。