Web系エンジニアのアウトプット練習場

エンジニアリングと書評が中心。たまに全然関係無い話もします。
トップページ/スクラム/チームにスクラムを導入するために勉強したことと試したこと/
2019年04月11日

チームにスクラムを導入するために勉強したことと試したこと

スクラム読書

最近チームにスクラムを導入したのですが、導入するまでに勉強したことと、導入してから試してみたこと、得られた知見等をまとめておきたいと思います。

スクラムとは

スクラム（英: Scrum）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。(Wikipediaより抜粋)

スクラムは、開発時に前工程への手戻りを許さない開発手法であるウォーターフォール型と対にして語られることの多い、アジャイル型の開発手法のうちの1つとなります。
アジャイル開発というと、Plan->Do->Check->Act(PDCA)サイクルを素早く回して、市場や顧客といった外的要因によるものも含めて、様々な変化にも対応しながら開発を行うことができる手法です。
そのアジャイル開発の手法の1つであるスクラムは、ジェフ・ザザーランドによって、

  • どのようにしてチームの生産性を高めるか
  • どのようにしてチームのムダを削ぎ落とせるか

を突き詰めていった末に完成された手法です。
スクラムのイメージ

何故スクラムを導入しようと思ったか

私は社内システムの開発をチームで行っておりますが、システムの品質やスケジュール等にシステムの全体の責任を一人で持っていました。
そのシステム開発を始めた際は、「こうやって作ろう、あぁやって作ろう」とチーム内で夢を語り合い、全体の士気も高かったように思います。
しかし、実際に開発を始めてしばらくたつと、「この作り方ではこの機能は作れない」といった新たな問題の発生や、そのシステムを使うユーザーである社内の部署から、プロジェクトが進むにつれて次々と新たな要求が噴出するといった問題が発生してきました。
我々チームは何回も痛い手戻りを繰り返しながらプロジェクトを進めてはいたのですが、ついには耐えきれないところまで問題が発生してしまい、プロジェクトが振り出しにもどってしまいました。

  • ユーザーが要望を出すのが遅すぎ、そんな大事なことはもっと早く言えよ
  • もう少し私以外の他の開発チームが主体性を持って変化に対応できていたら・・・

といった、愚痴混じりなことを考えてしまうこともありました。
しかし、よく考えてみると、私は今までチームリーダーを何回か経験したにもかかわらず、チームマネジメントについてきっちりと勉強をしたことがありませんでした。
なんとなく、感覚でうまくいっていたような気がしていたからです。
しかし、今回の問題はチームマネジメントをしっかり責任者が勉強して運用すれば、防げたかもしれない・・・ そう考え、色々とネットで調べているとソフトウェア開発においては、「スクラム」という手法を実践しているチームが多いことがわかりました。
皆が実践してるってことはそれだけの理由があるのだろう、そう考えた私はまず本を買ってスクラムの概要を知ることにしました。

スクラムを理解する上でオススメの書籍

私の場合、以下の2冊をオススメします。

  • カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
  • スクラム 仕事が4倍早くなる"世界標準"のチーム戦術


カイゼン・ジャーニー

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

1人から始めるプロジェクトの進め方カイゼン方法から、チームにスクラムを初めて導入する方法、スクラムの具体的な方法論やツールの紹介等がストーリー仕立てで一挙に紹介されています。
この書籍は著者が日本人なこともあり、「日本の現場」にありがちなストーリーとなっており、読みやすい内容となっています。
また、「たった1人からはじめて、「越境」するチームをつくるまで」というサブタイトルの通り、1人から気軽に始められる内容もあるため、はじめてスクラムに触れる方には特にオススメできる一冊となっています。

スクラム 仕事が4倍早くなる"世界標準"のチーム戦術

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術

カイゼン・ジャーニーでざっくりとスクラムのやり方と効果を勉強した後は、スクラムの生みの親であるジェフ・ザザーランドの「スクラム 仕事が4倍早くなる"世界標準"のチーム戦術」をオススメします。
この本はスクラムのやり方の解説というよりも、スクラムが何故どのように何を考えて生まれたのか、スクラムがどのような効果を期待しているのか、といったスクラムの哲学を勉強するのに最適です。
カイゼン・ジャーニーを読んだだけでも、一通りスクラムをやってみることはできると思うのですが、ジェフ自身の考えを読み、スクラムの哲学を理解することによって、スクラムの取り組み方、工夫の仕方、カイゼンの仕方がより洗練されるものと思います。

スクラムを導入した効果

実際スクラムを導入してどうなったのよ、というところですが、結論から言うと大幅に良くなりました。ざっくり列挙していきます。

問題の早期発見が可能になった

一番大きいのは問題点が早期に発見できるようになり、手戻りというムダを大幅に削ることができたことです。 日々のデイリースクラム、スプリントレトロスペクティブといった、振り返りの時間を細かく取ることでメンバーも問題点を共有しやすくなりました。
Working Agreementを定義することによって、問題点を気軽に共有する文化もできていますし、スプリント毎にインクリメント(スプリント毎に完成する製品)を毎回システムを使用する社内部署も交えてレビューするようにしたことで、要望も早期に上がってくるようになっています。
これも問題の早期発見の要因になっています。

価値観がチーム内で共有できている

プロジェクトの進行のおいて何か問題が発生するたびに、インセプションデッキやWorking Agreementを更新することにより、再発を防止するとともに、働き方や価値観をチーム内で共有することが可能となりました。
前は私が一日休むと、チームメンバーは何をすべきかわからなくなることがありましたが、今はユーザーストーリーも含めてチームメンバー全員でプランニングを行っているため、そのような場合でも問題なく主体的にメンバーそれぞれが行動することができています。
また、タスク1つ1つのクオリティも価値観が共有できていることにより、確実に上がっています。 これもユーザーストーリを共有することで、その機能のどの使い勝手を重視すべきかまでチーム内で共有できているおかげだと感じています。

ムダなタスクをチーム全員が洗い出せるようになった

明らかにムダなタスクは以前も当然削っていました。
今は納期に間に合わせるために不必要なタスクを時間を取って探し出す時間も設けるようにしています。 常にチーム全員が納期やクオリティや予算等を意識し、その観点でムダを省いていくことができるようになりました。

チーム内にリズムができ、生産性があがった

毎日デイリースクラムで問題点や今日やること等を整理してから作業に取り掛かるため、チームメンバーはリズムを持って優先度の高いタスクに集中できるようになりました。
また、Working Agreementによって、なるべくチームメンバーの集中が切れないようなルールも作りました。
その結果、ベロシティが2倍になり、チーム全体の生産性が大きく上がりました。 まだまだ問題点残っているのでそれを1つ1つカイゼンしていけば、もっともっと生産性は上がると思います。

まとめ

スクラムを実際に試すことによって、様々な良い効果をチームにもたらすことがわかりました。 問題の発見とカイゼンを繰り返すことによって、どんどん生産性が上がることがとても楽しく、致命的な問題が出てきてもどこか楽しむ余裕を持つことができるようになりました。
私はスクラムを実践し始めた初心者ですが、スクラムによるチーム開発を極められるよう精進いたします！