スクラムとは何か

私は20年前、ほんの2年間だけプログラマだったが、その頃に比べるとソフトウェア開発の現場は大きく変わってきたように思う。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

これはアジャイルマニフェスト（後述）の一節だが、完全に組織開発の思想だ（素晴らしい！）。いったい、いつからこうなったのか。

アカツキ社内の現場でも使用されているソフトウェア開発のフレームワークScrum（スクラム）について学んでみたい。

前回はスクラムと野中郁次郎とのつながりについて概念的に紹介したが、もっと実感を持ちたい。そこで、アカツキで実際にスクラムマスターをしている馬場さんに、その考え方と実践について執筆をお願いしました。

馬場さん、よろしくお願いします！

スクラムの始まり

スクラムの始まりは、1995年のOOPSLAカンファレンスだ。Ken SchwaberとJeff Sutherlandが自らの経験からの学びを『スクラムガイド』として共同発表した。

スクラムとは『現状を把握するためのフレームワーク』である。

あくまで自分たちが今置かれている問題の状況を把握するためのツールであり、導入すれば生産性が向上する魔法の杖ではない。生産性が向上するか、課題が定義できるか、課題が解決するか、それは利用する人々の力量による。

（ちなみに似た概念であるアジャイルとは、スクラムやXPなど各フレームワークの提唱者達によって、それぞれの考え方の共通項をまとめたものだ。スクラムはその原則のベースとなっている。
参考：アジャイルマニフェスト）

現場によっては、スーパーなマネジャーが１人で現状把握から課題特定までやっているかもしれない。しかしチームで戦う現場においては課題の特定に至るまでがなかなか難しい。ソフトウェア開発のような複雑な領域であればなおさらだ。

ソフトウェア開発の複雑さを表したのが下記の図になる。

ソフトウェア開発においては、日々変化する要件を新しい（不安定な）技術を利用して実現するといったいくつもの複雑さをかけ合わせた場面が多い。スクラムはこのような複雑度が高い領域において、現状把握を手助けし、自分たち直面している問題に気づきを与える。

逆に、変化の少ない領域においては、現状把握よりも一つひとつの作業を洗練させていくことが優先されるため、スクラムは苦手とする範囲となっている。

生産性の向上。よくマネジャーがこの役割を担いがちだが、スクラムでは開発チーム（メンバー）がここの責任を負う。

スクラムには3つ役割が定義されている。それぞれのミッションは以下のとおりだ。

私がスクラムを実践するうえで面白いと思っている点は、これまでマネジャーに集中していた役割をチームで3つの役割に分担してプロダクトのゴールに向かう考え方にある。

一人の天才ではなくチームの力を信じるアカツキの考え方に合ったワクワクする手法だと感じている。

馬場さんのスクラム講義はまだ続きます。次回は、具体的な手法について。