zdogma's diary

徒然なるエンジニアな日々。

スクラム実践入門 を読んでみた

ことはじめ

今自分が所属している開発チームでは、発足当初から「スクラム」に則った開発を進めています。
当初は極めて少人数のチームだったこともあり、導入後も特に困難なく開発を続けていたのですが、チームの規模や事業の状況が変わるにつれて、だんだんとうまくいかないケースが増えてきました。
そんなこんなで悶々としていたところ、下記の書籍を会社の先輩に紹介してもらいました。

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

読んでみると、目からウロコな情報が詰まっていて、正直感動しました。
特に自分のような「スクラムやってるけど、ちゃんと体系立てては知らない」「他のチームだとどのように取り組んでいるのか知りたい」という方にはとてもオススメです。

今回は、その中でも自分的に「へぇ〜」と思った箇所について、ネタバレにならない程度に簡単に紹介します。

なぜ「スクラム」と呼ばれるの?

そもそもスクラムとは、「スクラムガイド」と呼ばれるドキュメントにより下記のように定義された、ソフトウェアの開発プロセスを指します。

スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り 価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

出典: スクラムガイド
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf

スクラムとは読んで字の如く、ラグビースクラムのことですが、なぜそのような名前になったのでしょうか?
現在スクラムと呼ばれているその開発手法は、1986年に「ハーバード・ビジネス・レビュー」誌に寄せられた竹内・野中論文に由来しており、その論文の中では、新製品開発の方法は大きく下記2つに分類されていました。

  • リレー競走型
    • バトンを渡していくように、各生産工程が交わる事なく順番に進んでいく
  • ラグビー

スピードと柔軟性を求められる現代の新製品開発の現場では、従来のリレー競走型の開発プロセスよりも、ラグビー型のアプローチを採用すべきだ、という趣旨で、ホンダの製品開発スタイルがベストな事例として紹介されているとか。

興味ある方は下記のWebサイトで原文が読めるそうなので、ぜひどうぞ。

hbr.org

なぜ作業を「時間」で区切るの?

いわゆるウォーターフォール型の開発だと、「Aという機能を◯月△日までに作る」など、成果物ベースでスケジュールを立てるのが基本だと思いますが、スクラムだと Sprint という期間、つまり時間で区切ります。
これはなぜなのでしょう?

スクラムによる問題解決の思想の原点は「経験主義」にあります。

スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。

出典: スクラムガイド
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf

スクラムでは、解決すべき複雑で変化の激しい問題に関して、事前に万全な計画を立てて取り組もうとはしません。
時間によって作業を区切り、時に方向を修正しながら少しずつ成果物を積み上げ、最終的な成果物に近づけていく、というアプローチを取ります。
それがスクラムガイドにある「反復的かつ漸進的な手法」ということなのですね。

スクラムのキーワード

本書の中で紹介されているスクラム系のキーワードを並べてみました。
興味あるものについては本書を手に取って確認してみてください。

ロール

  • プロダクトオーナー
  • 開発チーム
  • スクラムマスター

成果物

イベント

  • スプリントプランニング
  • リファインメント
  • デイリースクラム
  • スプリントレビュー
  • スプリントレトロスペクティブ

プラクティス

  • インセプションデッキ
  • リーンキャンバス
  • ユーザーストーリー
  • ユーザストーリーマップ
  • プランニングポーカー
  • スパイク
  • バーンダウンチャート
  • パーキングロット
  • KPT

おわりに

スクラムという手法が広く取り入れられるようになってからしばらく経ち、導入している企業も増えていると思います。
ただ、スクラムを実際に取り入れてみるとしみじみと感じるのですが、スクラム自体はとてもよくできた手法ではあるものの、どんなチームにも紋切り型で当てはめるだけでベストな成果が出る魔法のような手法というわけではなく、それをきちんとワークさせるためには、しっかりと各 Sprint を振り返り、改善を重ねていく根気と実行力が必要です。
そんな時にとても助けになるのは、実際にチームに適用したときの経験談や対処法だったりして、そのあたりもこちらの本にしっかりまとまっています。
どんなチームでも悩みどころはだいたい似通っているようで、結構ドンピシャな内容が載ってたりしますので、ぜひご一読をおすすめします。

参考にしたページ