開発プロセス・方法論

スクラム

（すくらむ／Scrum）

一言でいうと

役割とイベントを定めた反復型の開発フレームワークです。正本のスクラムガイドは薄く書かれていますが、それは不備ではなく設計です。

Ken SchwaberとJeff Sutherlandが、1995年のOOPSLA（オブジェクト指向技術の国際会議）で初めて共同発表しました。スクラムガイドによれば、二人がスクラムを開発したのは1990年代初頭で、最初のガイドを書いたのが2010年です。現在の正本は2020年版になります。

ガイドは意図的に薄く書かれています。役割、イベント、作成物とそれらの目的だけを定め、具体的なやり方は各チームに委ねる構成です。これは不完全なのではなく、そう設計されています。

計画を長く固定できない状況で、チームが自律的に進む形を作ることが目的です。スプリントと呼ばれる短い期間で区切り、期間の終わりに動く成果物を確認し、そこで得た情報を次の計画に反映します。

役割を分けることにも意図があります。何を作るかの優先順位を決める人と、どう作るかを決める人を分離することで、片方の都合でもう片方が押し切られる構造を避けます。

プロダクトオーナー、スクラムマスター、開発者の3つの責任があります。スプリントという入れ物の中で、計画、日々の進捗確認、成果物のレビュー、振り返りを回し、プロダクトバックログとスプリントバックログで作業を管理します。

振り返りは省略されやすいイベントですが、進め方そのものを改善する唯一の場です。ここを飛ばすと、初期に決めたやり方のまま固定されます。

反復型の開発体制を敷いている、あるいは敷こうとしている組織です。ただし実態の幅は大きく、名前だけの運用も少なくありません。

この語は、本群では例外的に候補者検索に使えます。スクラムマスターという職種名が媒体のカテゴリにあり、認定資格が経歴に書かれるためです。ただし必須要件に置くと対象が狭まるので、歓迎要件に置いて面談で確認する運用が現実的です。

自社側では、誰がプロダクトオーナーの責任を持つのかを先に決めておきます。候補者には、直近の振り返りで何を変えたかを聞きます。具体的な変更を挙げられる人は、枠組みが機能する条件を知っています。