“スクラム”組んでます ~チームフレームワークとしてのスクラム~
ソリューション開発部の青山です。今回は2015年から始まった部のスクラムへの取り組みについて紹介いたします。
2015年から取り組みを始め、現在は6名が認定スクラムマスター(CSM)としていろいろな案件で活躍しています。2015年に私もCSMとなりました。2014年以前も個々人で勉強して案件やチームでスクラムのエッセンスを利用している状況でしたが、2015年からは部として計画的に取り組んでいます。
そもそもスクラムって?
スクラムの詳細は、Scrum Alliance等で公開されているスクラムガイドや、様々なサイトや書籍での有名な識者の方の解説にて概要を把握していただけます。
- The Scrum Guide 2016 (日本語翻訳版)
- 開発チームを改善するためのスクラムTips (@IT)
- SCRUM BOOT CAMP THE BOOK (西村直人, 永瀬美穂, 吉羽龍太郎 著)
- アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント (平鍋 健児, 野中 郁次郎 著)
スクラムをあまり知らない方向けに、詳細を知る前に知っておいてほしい点を2点ほど。
アジャイル + カイゼン な チームフレームワーク
スクラムはチームでの作業を加速していくための「チームフレームワーク」です。「複雑なプロダクトを作り上げていく」ためのチームに適用することを想定しています。また、「プロダクトに影響を及ぼす変化が多い」場合に特に有効なフレームワークとされています。またこのフレームワーク自体はとてもシンプルなものです。The Scrum Guide もたった17ページ(表紙・目次も含めて)となっています。
スクラムというと、ソフトウェア開発専用と思われがちですが、そういうわけではありません。ソフトウェア以外の商品開発などでも活用できるものだと思います。また、アジャイルの一部とか発展形というわけでもありません。アジャイルのエッセンスの一部をスクラムが取り込んでいるイメージが一番近いと思います。さらに、アジャイル以上にトヨタで有名なカイゼンの要素が多く含まれています。私の受講したCSM研修では、「アジャイル:カイゼン = 2:8 の比率でスクラムは構成されている」とCertified Scrum TrainerであるJames Coplien氏は解説してくれました。
スクラムは必ずプロジェクト全体に適用するものでもない
プロジェクトでのスクラム適用はいろいろなバリエーションが考えられます。
- アプリ・インフラ・運用開発を1チームとしてスクラムを適用
- アプリ開発の1チームでスクラムを適用。インフラ・運用開発はウォーターフォール
- 大規模なアプリ開発の1サブシステム開発チームでスクラムを適用
- etc…
バリエーションはいくらでも考えられます。極端に言うと、ひとりスクラム…自身のタスク管理だけに適用することも可能ではないかな、はたまた家族でスクラム組むってのもあるんじゃない?とか思っていたりもしています(私はやっていませんが、1ヶ月に1度、親子でレトロスペクティブをやっている方の記事を読んだことがあります)。
また、スクラムのエッセンスや、スクラムチームでよく利用されるツール(プランニングポーカー、カンバン、バーンダウンチャート、etc…)は、スクラムチーム以外…例えばウォーターフォール開発のチームでも有用だと思います。
ウォーターフォール開発のチームでも日次や週次といったスプリント的なペースはありますし、変更ゼロなんてことは私の知っている限り絶対にありません。ウォータースクラムフォールなんて揶揄されることもありますが、きちんとそのエッセンスやツールの効果を理解して適用すれば、少なからず良い効果に結び付くと思います。
特にプランニングポーカーはとても手軽に導入できると思います。その恩恵については、アプレッソ社エンジニアさんの技術ブログ で紹介されています。
なんで部で取り組んでいるの?
以前の話題となりますが、IT人材白書2014や各種書籍などでも解説されていたとおり、受託でのシステム開発は少しずつ減少していて、既存サービスの利用やビジネスの近く…内製化の中でのシステム開発など、システムを手にするための形態が変わってきているようです。そのような中、我々のお客様からも、ビジネス担当者の近くで要件定義だけでなく開発…特に保守開発を一緒にチームとして行って欲しいという要望が出てくるようになりました。
チームを組む…その上社外の方と長期で…となると、チームを成長させるための仕組みも必要になります。そこで目をつけたのがチームフレームワークであるスクラムでした。部内では常に同じツール(Wiki・BTS・リポジトリなど)を利用していたのである程度チームとしてのルールは確立できていました。ただここでお客様や一緒に働くビジネスパートナー各社ともルールを共有できるように、業界でも注目されていたスクラムに取り組むこととしました。
また、以下の様なスクラムの特徴も、組織として全員が習得することでプラスに働くと考えました。
- スクラムではチームとしてそれぞれのメンバーが自律的に動けることを目指す
- 伝統的な単一リーダーへの依存が薄まった自律的な組織ができることが期待できる
- チーム状況の計測、変化への気付き、フィードバック、カイゼンのプロセスが定義されている
- これらを自然に行えるようになることを期待できる
- 変化への対応プロセスが定義されている
- システム開発でほぼ必ず発生する変更に対して自然と対応できるようになることが期待できる
スクラムのシステム開発適用事例
上記のような部でのスクラムへの取り組みですが、システム開発での適用事例もいくつか出てきています。
- お客様の開発部隊に、ARKのスクラムマスターと開発メンバー3名が入って一緒にスクラムでの新規開発
- Redmineプラグインのカンバンやバーンダウンチャートを利用してチーム状況を計測
- お客様をプロダクトオーナーチームとして、ARKのスクラムマスターと開発メンバー4名が入って一緒にスクラムでの保守開発
他にも、いろいろなプロジェクトでスクラムのエッセンスを取り込み始めています。今後もCSMの社員を中心に、システム開発で役に立ちそうなスクラムTipsをブログでご紹介していく予定です。