虎の穴開発室ブログ

虎の穴ラボ株式会社所属のエンジニアが書く技術ブログです

MENU

アジャイル開発とスクラム 第2版 を読みました

こんにちは。虎の穴ラボの大場です。 通販マーケティングチームのスクラムマスターになって2年ほど経過しました。

チーム内でのスクラムを改善するネタが無いかなと思ってアジャイル本を1冊読みました。 今回は『アジャイル開発とスクラム 第2版』を紹介します。

アジャイル開発とスクラム第2版

概要

本のタイトル通りですが、アジャイル開発とスクラムに関しての解説書です。

2013年の初版発行から8年の時を経て改訂されたこともあり、 最新のスクラムガイドに沿ってブラッシュアップされた内容となっています。

どんな人向け?

  • アジャイル開発を知りたい経営層の方
  • 他社のアジャイル開発導入事例を学びたい方
  • 実践するだけではなく、もう一歩踏み込んでスクラムを理解したいスクラムマスターやプロダクトオーナーの方

本書の対象読者としては、エンジニアよりも経営者やマネジメント層の方に読まれることを想定しており、 初版と比較して技術面での記述量が削減されています。

一方、ターゲットとなる読者(経営者やマネジメント層)にとっては気になるであろう情報が随所に組み込まれています。 特に第2章では、よくあるシステム開発現場での問題点例にあげ、「なぜアジャイル開発を行うべきか?」をビジネス的視点や歴史的背景を踏まえ説明しており、 開発現場だけにフォーカスせずにアジャイル開発の必要性を説いているところが本書の特徴だと感じました。

著者

  • 平鍋 健児さん:株式会社永和システムマネジメント代表取締役。
  • 野中 郁次郎さん:一橋大学名誉教授。「スクラム」という言葉の名付け親の一人。
  • 及部 敬雄さん:SilverBulletClub(チーム名)所属。 ※本書著者紹介より引用

各章の感想

第1部

アジャイル開発の基礎的な方法論について解説されています。 既にアジャイル開発に親しんでいる方は第2部から読み進めて良さそうです。

第1章:アジャイル開発とは何か、スクラムとは何か

とある企業がスクラムを導入した事例をもとに、そもそもスクラムとは何か?を簡潔に説明しています。基礎的な内容はここで把握できます。

第2章:なぜアジャイル開発なのか

比較的経営観点で、アジャイル開発を勧める理由が記載されています。 市場・ビジネス・ITの三者関係性から考えたとき、従来の手段で開発した際の問題点をあげ、 アジャイル開発ではそれが解決できることを図を用いて解説してます。

第3章:スクラムとはなにか

この章からスクラムに関する技術的な内容に入っていきます。 初学者の方は、専門用語が多くて戸惑ってしまうので別の章から読むことを推奨しており、 はじめてでも読み進めやすいように工夫されていることを感じました。

第4章:アジャイル開発の活動(プラクティス)

具体的なアジャイル開発における活動をいくつか取り上げて紹介しています。

例をあげると、朝会(デイリースクラム)、ふりかえり(レトロスペクティブ)といった、 とらのあなラボの開発現場でも実践している内容が紹介されていました。

※ 朝会(デイリースクラム):昨日やったこと、今日やること、障害や困っていることを共有する

※ ふりかえり(レトロスペクティブ):チームで活動を振り返り、良かったこと、悪かったこと、改善したいことなどを話し合う

実際に、とらのあなラボでもスクラム開発を行っていますが、全てのプラクティスを取り入れているわけではありません。 自分たちのチームに合ったプラクティスを利用していった結果が今であり、メンバーが納得する形でスクラム開発を形成していく望ましいかたちが取れていたことを再認識できました。

第5章:アジャイルの進化とスケールフレームワーク

アジャイル開発は10人以下の小さなチームに適したフレームワークです。 この章では、10人を超えた大きなチームになった場合に適用できる新しいフレームワークを紹介しています。

具体的な手法の紹介に入る前にアジャイル開発をスケールアウトする上で、必ず気をつけるべき注意事項が書かれていました。 この注意事項を確認しスケールアウトすることが適切でないと判断した場合は、 ただ単純にチームを分割し5人単位の小さなチームに分割しなおすというのもアリだと思います。

とらのあな通販チームも過去、10人を超えたタイミングで3チームに分割した経験があります。 チームを分割したことと同時に、全員参加だったMTG規模を縮小し、チーム単位で開発案件に取り組む方針に変わったことで、 認識合わせの為のやりとりの手間が解消されたように感じました。

第2部

ここからは、日本国内でアジャイル開発を行っている各社の導入事例の紹介になります。 アジャイル開発に慣れ親しんでない方は、ページを飛ばし先に6章以降を読んでイメージをつけてから、 第3章で具体的な手法を学んでいくという読み方を推奨しています。

第6章:NTTコムウェアにカルチャー変革の航路

6000名もの社員を抱える中で、アジャイル開発の文化を広げていった事例が紹介されています。 社内で小規模な勉強会からスタートし、3年で社内にアジャイル推進組織を発足しており、 日本の大企業でも諦めず地道な活動を続けることでゼロからアジャイルを導入出来たことが実証されていました。

第7章:アジャイル受託開発を成功させる ANAシステムズと永和システムマネジメントによる共創型開発に至る道のり

ユーザー会社・システム子会社・開発ベンダーの3社に跨ってのアジャイル開発を行ったという珍しい事例でした。 プロダクトオーナーの役割が開発ベンダーが担うのではなく、システム子会社側が担っている点が少し特殊ですが、 完全なリモート環境下においてアジャイル開発を成し遂げており、昨今のリモートワークが増えている状況下では、 参考になる事例だと思います。

第8章:小さな成功から築き続けるIMAGICA Lab.のアジャイル文化

進捗のブラックボックス化や、顧客との認識ズレによる手戻りなど様々な問題を抱える中で、 現状を打破するためにスクラムを導入した映像制作会社での導入事例です。 特筆すべきなのはアジャイル開発を内部に浸透させていく際、 エンジニア以外のメンバー(同僚や部下のみならず社長までも)を巻き込んだことで、 組織全体を巻き込む形でアジャイル文化を導入していきたい場合に参考になりそうな事例でした。

第9章:KDDI DIGITAL GATEにおけるスクラムチームファーストな働き方

スクラム開発では一般的にチームメンバーを固定する事が定石ですが、 KDDI DIGITAL GATE(KDG)では独自の単位でチームを編成しているそうです。 また、案件内容を内部向けに説明した際に、それを聞いたエンジニアが「面白そう!」と感じたら、 自ら声を上げてチームへ参加できる仕組みにもなっているとのことです。 上からの指示だったり自分しかやれる人が居ないからという理由からではなく、 案件を自分で選択する事が出来るというのは内発的動機づけができている良い環境だと思います。 エンジニアが意欲をもって学べることを重視したチームを作りたい場合に参考になりそうな事例でした。

第3部

アジャイル開発とスクラムが持つ本来の意味についての考察に入っていきます。

第10章 竹内・野中のスクラム論文再考

1986年に書かれた論文をもとにスクラムの原点を知ることができる章となってます。 また、執筆者の中のひとりである野中先生による論文オリジナルと現在のアジャイル開発を比較しての考察が広げられています。

第11章 スクラムと知識想像

スクラムを通して得られる知識を暗黙知と形式知にわけ、 「ふりかえり」によって2つの相互作用を繰り返していくことで、 ソフトと一緒にチームも成長していくといった内容が記載されています。

自分達の活動では暗黙知と形式知の変換が繰り返されているか強く意識してなかったので、 「ふりかえり」の中でナレッジが積み重なっているかについても今後考えていこうと思いました。

第12章 スクラムと実践知リーダー

前の章を踏まえて、実践知についての解説が行われています。 リーダーは形式知と暗黙知を兼ね備え、さらに目的や本質から逸れない判断を下せることが求められます。

具体的に実践知を発揮するための6つのポイントが紹介されており、 例をあげると、「何が善かを判断する」「本質をつかむ」といった具合ですが、 ここだけ切り取ればスクラム以外にも適用できる考え方だと思います。

なかなか紐解くのが難しい内容でしたが、 「知識」ではなく「知恵(知識をどう使うか)」こそが価値があるといった話と似ているなと感じました。

まとめ

「アジャイル開発とスクラム」が現在の形に落ち着いた経緯や生まれた背景から原点の思想を詳しく知ることができる1冊だと思います。

私は他社のアジャイル開発導入までの話をあまり見聞きしたことがなかったこともあり、 第2部について興味を持って読み進めることができました。 どんな会社やチームでも環境に合わせて、アジャイルの本質を抑えながらも柔軟に変化できるのがスクラムの良さだと再実感しました。

実践するだけではなく、もう一歩踏み込んでスクラムを理解したいスクラムマスターやプロダクトオーナーの方や、 アジャイル開発を知りたい経営層の方は一度手に取ってみてはいかがでしょうか。