この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。CX事業本部でデザインチームのマネージャーをしている小峰です。
前回の記事でデザインチームでスクラムをやろうと思い至った経緯と手始めに何を行ったのかを書きました。
今回は「アジャイル・スクラムとはそもそも何なのか？」というところを見つめ直しました。チームで取り組んでいくことになりますので、メンバーの皆さんの理解度向上につなげるべく、改めて私なりに整理してみました。よろしければアジャイルとスクラムの違いといった点で悩んでいる方の何らかの参考になれば幸いです。そして世の中に大量に溢れている類似の記事や書籍なども参考にして、ご自身なりの理解や解釈につなげていただけると嬉しいです。
なお、デザインに関する話題は今回もほとんど出てきません（笑）
まず結論
アジャイル = 原理原則・概念・マインドセット
スクラム = 方法論・開発手法
です。
アジャイルとは何なのか？
アジャイルソフトウェア開発宣言という文章を見たことがある方も多いかと思います。これが根っこの基本となる考え方です。
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
この宣言文は2001年に作られました。この時代、価値観・考え方・やり方が似た開発者達がアメリカ合衆国ユタ州スノーバードに集まり、その彼らによって書かれたものです。「アジャイル」という言葉はこの会議の中で誕生しました。
具体的な方法論としてはスクラムの他にXP、FDD、DSDM、ASD、Crystal Clear、Evo等があったようです。
この4つの宣言の他、アジャイルソフトウェアの12の原則（アジャイル宣言の背後にある原則）もあります。
重要なことは4つの宣言と12の原則の中身そのものですが、当時試行錯誤を繰り返し彼らなりの方法論を築きてきた開発者たちが集まって見い出された共通項である、という点も歴史的な経緯として重要です。経験から生まれたものということもまたアジャイルの本質のひとつだと自分は感じています。
スクラムとは何なのか？
アジャイルソフトウェア開発宣言は上述の通り、原理原則・概念・マインドセットでした。
対してスクラムは方法論・開発手法です。その中身はスクラムガイドとして無償公開されています。
先に書いたように、一口にアジャイルと言ってもその方法論は多種多様です。その中でも代表格となっているのがスクラムでしょう。
スクラムとは、Ken Schwaber 氏と Jeff Sutherland 氏が提唱した開発手法です。
彼らによる動機は、ソフトウェア開発プロジェクトが、
- 成功率が低い
- 管理者がいつも不機嫌
- 開発者が常にプレッシャーに晒されている
- 顧客は不満足
という状況を打破したいという思いからだそうです。耳が痛いですね（笑）
彼らは本質的に複雑さを有するプロジェクトを予見・予測的に進めようとするウォーターフォールはうまくいかないという現実を目の当たりし、複雑系の適応制御理論、IBMの外科医チーム、ゼロックスのParc研究所、その他の生産性の高い開発チームの分析などから、反復・漸進的なプロセスとして形式化しました。
ウォーターフォールのように事前に詳細な仕様に落とし込み、一気に開発し、一気にテスト・修正し、リリースするといった流れではありません。未来は予見できないという前提の元、反復によって実際の測定に基づく知識を獲得していきます。知識の獲得のためには「情報の透明性」が必要であり、それを確保した上で「検査と適応」を繰り返す、という流れになります。
こういったことから、
- 予測型アプローチ：ウォーターフォール
- 適応型アプローチ：アジャイル
と呼ばれることもあります。
変わらないアジャイルと変わるスクラム
ベースとなるアジャイルソフトウェア開発宣言では文言に「ソフトウェア」とあるように、主にソフトウェア開発を対象として考えられたものです。そしてその中身は2001年に作られたときから変わっていません。
対して、スクラムは不定期にアップデートがされています。これを書いている時点での最新版は2020年11月版です。ここではソフトウェア開発に限らず、チームで成果を作っていく活動全般に広く適応できるようにシンプル化されています。その前の版である2017年版よりも短くなりました。
このようにスクラムガイドそのものも時代や環境に合わせ適応していっています。
日本流の考え方も含まれている
「スクラム」という言葉が初めて使われたのは野中郁次郎氏と竹内弘高氏による「The New New Product Development Game」という論文です。80年代日本の新製品開発プロセスとNASA等の米国型のそれとを比較して論じられたものです。
この論文では開発プロセスがいくつかのタイプに分類されています。「各工程の専門家集団が文書で次の工程の集団にバトンを渡すようにリレーする」といったパターン、「ラグビーのチームのように一丸となってボールを運んでいる」といったパターンなどです。ここまで読んでくださった方やすでにアジャイルやスクラムの経験者などでしたら、前者がウォーターフォールっぽい、後者がアジャイルっぽいことは明白でしょう。
アジャイル型の開発手法やプロセスを導入したい、そのために上司やステークホルダーを説得しようと試みた方で、
「アジャイルってアメリカのやり方でしょ？ シリコンバレーみたいに優秀な人だけ集められればいいけど、日本じゃできないよ」と言われたことがある方もいらっしゃるかもしれません。実際私は言われたことがあります。
しかし上記の通りきっかけとなった論文の著者は日本人ですし、「スクラムチームのように一丸になってボールを運んでいる」事例としてはキヤノンやホンダが実例として挙げられていたようです。
またスクラムガイドには「経験主義」と「リーン思考」に基づいているという記載もあります。このうち、リーンとはいわゆるトヨタのジャストインタイム生産方式が源流です。「ムダ、ムラ、ムリ」を徹底的に排除して「必要なときに、必要なものを、必要なだけ」生産する、といったような考え方です。カンバン（スーパーマーケット方式）やアンドンといった言葉もこの辺りからですね。
ですので説得したいと思っている方はぜひ「いやいや、日本でも昔からやってるところありますよ！」と自信を持って伝えて大丈夫なはずです（笑）
ソフトウェアに留まらない広がり
COVID-19のワクチンを極めて短期間で開発したモデルナもアジャイルプロセスと聞いています（Scrum Interaction 2022）。また、イーロン・マスク率いるTeslaやSpaceXもどうやらアジャイルを元に独自の開発サイクルを確立しているようです（アジャイルやスクラムでも遅い？ TeslaやSpaceXがイノベーションを生み出せる理由：マネジメントはソフトウェアが代替 - ＠IT ）
中には「アジャイルってソフトウェア開発のやり方でしょ？ うちじゃ合わんよ」とソフトウェア以外の領域で言われたことがある方がいらっしゃるかもしれません。私はずっとソフトウェア開発に関連した仕事がほとんどだったので言われたことがありませんが、これも自信を持って伝えていただいて大丈夫なはずです（笑）
Don't just do agile, be agile
スクラムは導入することは比較的簡単です。4つのイベントをこなせばOKというシンプルなものです（リファインメントも含めれば5つ）。しかし、単に「スクラムをやる」だけではいけません。
- デイリースクラムやふりかえりが形骸化してしまっている
- スクラムイベントのファシリテーターがいつも同じ
- ステークホルダーやマネージャーによるマイクロマネジメントが行われている
- POとSMが兼任で大きなボトルネックになっている
- SMがチームを管理してしまっている
- POを経由せずに外部からタスクが追加される
- 皇帝のような開発者が全てをコントロールしている
- チームの人数が多すぎる
- ほとんど発言しないメンバーだらけになっている
等の様々なアンチパターンがあります。手法の導入が目的化してしまうことでこれらにハマってしまい、結果として上手くいかなかったという話はよく聞きます。
手法を採用するだけでなくその手法を上手く使ってチームがアジャイルな状態になることが重要です。そうすることができれば、ソフトウェア開発でもそうでない領域でも不確実性の高い現代社会において良い結果を出せる確率が高まると思っています。
「アジャイルな状態って何？」という疑問が湧いてくるかもしれませんが、それについてはまた別の機会に。
終わりに
アジャイルやスクラムが今後どうなっていくのか楽しみです。
昨今AIが話題を集めています。Stable DiffusionやChatGPTあたりが盛り上がっていて、新しいAIはもちろん、関連したサービスや機能もどんどん出てくるでしょう。弊社でも最近はOpenAI、ChatGPTに関する熱い情報交換や試行錯誤が行われ、このDevelopersIOでも多くの記事が投稿されています。
近い将来は人が手を動かす何らかの作業にはAIが踏み込んでくることが多くなってくるかなと思います。しかしチームワークであったりフェイス・トゥ・フェイスで話す領域にまでAIが踏み込んでくるまではまだ時間がかかりそうです。どの程度の時間がかかるかわかりませんが、いわゆる強いAI、汎用型AI（AGI）に至るのはそう簡単ではないでしょう。
現在のAIは確率的分析的な結論を出すことは得意ですが、まだAI自身が体験を得ることはできません。弱いAI、特化型AIとも呼ばれていますね。そういったAIは有効なツールとして人の活動をサポートするものになりつつあります。
例えば最近Notion AIを試してみましたが、要約がとても便利でした。議事録的な文書作成はもちろん、プランニングやレビュー、ふりかえりといった一連のスクラムイベントの中でも有効活用できそうです。
人が集まって相談・対話・議論を行い、その結果の整理をAIに効率的に行ってもらい、人は体験を通した知識活動により集中する、そんな未来はそう遠くない気がしています。
参考文献
「アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」 平鍋 健児 著, 野中 郁次郎 著, 及部 敬雄 著
「PMBOK®ガイド 第7版」 Project Management Institute, Inc. 著, PMI日本支部 監訳
75
