[注意]
この記事は、2016年9月に執筆された記事です。株式会社アプレッソは2019年4月1日をもって株式会社セゾン情報システムズに合併されており、現在は募集は行っておりません。ご注意ください。

はじめに

我々アプレッソはDataSpider Servistaという製品を開発しています。そしてDataSpiderを主力として、自社開発のソフトウェア群で100%ビジネスをやっています。受託開発などは一切やらずに、新しいソフトウェアの開発と、自社の製品をより良くする開発にフォーカスしているわけです。

DataSpiderはv1.0のリリースから10数年。その間さまざまなソフトウェア開発手法の試行錯誤をしてきました。より素早く、より品質の高い製品を作るためにはどうすればいいか？　その実現に向けて、品質保証チーム(QAチーム)の立ち上げや、ペアプログラミングを導入したり、プロダクトサステイニングチームの整備などさまざまな施策を行ってきました。

そしてDataSpiderの次のバージョンは4.1。このリリースに向けて、大胆に開発手法を変えました。それが「スクラムの導入」です。

スクラムを導入し始めていろいろ変わったものがありますが、その中でも大きく変わったのが「働き方」です。これまでの「組織で作る」あり方から「チームで作る」という風に大きくイノベーションが起きつつあります。

なぜ開発手法を変えなければいけなかったか、そして「スクラム」を選んだ結果、どのように変わったのか、ということをこのブログでは紹介したいと思います。

「個人」ではなく「仕組み」を改善する！

ソフトウェア品質は高くあるべきです。とはいえ、品質を高めようとするとテストフェーズでやるべきことが増えてしまい、リリースまでの時間が多くかかってしまいます。

DataSpiderは最初は製品開発者がテストを行っていました。しかし徐々に規模が大きくなるに従ってそれでは対応できなくなり、QAチームが立ち上げられ、開発フェーズとQAフェーズで大きくリリースまでのフェーズが分かれることになりました。

最初はそれでうまく回っているように思いましたが、徐々に問題が出てきました。特にテストフェーズでのバグの発見に伴うリリーススケジュールへの影響が大きく、問題となってきました。

実際、半年前に開発したものの指摘をされても修正するのに時間がかかることは容易に想像できます。また、そもそも根本的な仕様バグがあった場合、もっと開発初期に見つかれば対応が容易だったものがひどく困難になることになりました。

基本的に開発者個人でコンポーネントを持つ仕組みであったので、開発者個人で頑張って対応してきましたが、限界があります。

これは個人の問題ではなく、仕組みの問題なのではないか？

開発部内部からこのような提案が出てきました。検討をした結果、「できるだけ早く定期的に動く機能を作り上げる」ための仕組みとしてアジャイル的手法、特に「スクラム」を導入してはどうか、という声が上がりました。

スクラム起動！

▲Product Backlog Itemの見積りを行う。製品を見ながら意見を出し合い、プランニングポーカーで見積りポイントを算出する。全員の同意を得るまで必ず行う重要なMTGだ

ということで「スクラム」をやりましょう。といってもまずはどうやればいいのかを開発部の有志で研究しました。いろいろな書籍を読んだり検討会したり、そして実際にやってみたり。

その中でやはり「軸となる知識がほしい！」ということで2名(そのうちの一人が私です）がScrum Alliance認定スクラムマスター研修を受け、認定を取得して晴れてスクラムマスターに。

そしていよいよスクラム起動しました。

実際にやってみて・・・

スクラム良いです！

ってすっ飛ばしてしまいましたが、スクラムの内容や実践の詳細については開発部ブログの方で今後紹介していこうと思うので、ここでは深く扱いませんが、簡単に概要を記します。

特に良かった点として「1週間のスプリント」と「役割と責任の明確化」があります。この2つのもたらしたものについて以下に紹介します。

1週間スプリントによるスピード感と改善アクションの取りやすさ

スプリントは1～4週間とするのがルールですが、我々のチームはその中でももっとも厳しい「1週間」を導入することにしました。

なぜか？

我々は世界一のチームになりたいからです。

っていきなり話がでかくなりましたが・・・・実は認定スクラムマスター研修で講師の方が挑発的に以下のようなことを言っていました。

「現在世界のパフォーマンスが高いスクラムチームはスプリント1週間でやっています。もしあなたのチームが世界一のチームになる自信がなければ、2週間以上を採用してください。もし世界一のチームになる可能性があると信じているならば、1週間を採用してください」

いや、正確にはこういう言い方ではなかったような気もしますが・・・だいたいこういうことを言ってました。

ではなぜ1週間がベストなのか？　その大きな理由としてはSprint ReviewとSprint Retrospectiveという作ったものに対するフィードバックを得る機会と、自分たちが振り返って改善アクションを考える機会が最も多く取れるからです。

で、実際にやってみると1週間は大変です。大変ですが、1週間で動いてテストされている機能を作るスピード感は実際にやってみると非常に心地よいものがあります。

そして、1週間であると「次の週まで何をやるべきか」「今回までで何をやったか」の見通しが非常に立てやすく、振り返り会も次々と「改善するべきこと」「そのためのアクション」の案が出てきます。

実感として、人が具体的に把握できる時間の単位は1週間が限界なのでは、という気もします。例えば今週金曜日に何をしているかは確定的な想像ができますが、来週金曜日に、となると一気に予測が曖昧になります。

ということで、この1週間というスプリントはチームの強力な武器になっています。

▲スプリントが終わりSprint Retrospectiveを行う。KPTの中で次のスプリントで行う「アクション」を決めようと議論している

役割と責任分担が明確になり、より強いチームに

これまでの開発部は、一般的な会社と同じくピラミッド型の組織を軸に開発を行っていました。マネージャーやリーダーがメンバーに指示を行い、それに従って開発するという仕組みです。

スクラムチームは、「プロダクトオーナー」・「チーム」・「スクラムマスター」という3つの役割で構成されます。いろいろと役割はあるのですが、その中でも大きいのは「プロダクトオーナーはWhat(何を作るか)に責任を持ち、チームはHow(どのように作るか)に対して責任を持つ」ということです。スクラムマスターはその双方のやり取りを円滑にし、障害を取り除きます。

スクラム導入以前、マネージャーとリーダーはHowもWhatも特に気にせずに指示していました。もちろんメンバーと話し合った上で決定はしていたのですが、どのように役割分担をするか、誰が責任を持つのかという境界線は曖昧でした。

またメンバー同士もそれぞれの担当コンポーネントを持っていて、集中できるようにお互いに情報交換は最低限になるようにしていました。そのため、担当者が居ないと対応できない、ということがよく発生していました。

▲スクラム導入前の組織概要。マネージャーやリーダーからHowとWhatが指示される

導入後は、以下のように指示系統はありません。WhatとHowの責任範囲があるだけです。プロダクトオーナーは適切に「What」を管理しチームに伝えることが求められ、チームは「How」を責任を持って取り扱い「What」を実現することを求められます。

▲スクラム導入後のチーム。上下関係はなく、役割と責任範囲がある

単に手法を導入しただけではあるんですが、この役割分担によって大きくチームの中の意識と議論の内容が格段に変わりました。これまで「機能を開発する」というのが開発者の役割でした。そのため、その機能に関する仕様や進捗などが会話のメインでした。現在では「より良い製品を作るためにはどういう手段が良いか？」「より早く作るためにはどういう働き方が良いのか？」という議論が普通の会話で（飲み会とかでも！）行われるようになり、活発な議論になりました。

「チーム」でゴールを目指す楽しさ　　

▲Sprint Planningを行うチーム。あらゆる情報を持ち寄ってスプリントの計画を立てる

ということでスクラムの導入により、大きく社内のイノベーションが起きています。今までは「組織」で作る、指示の通りに作る、という働き方だったのですが、現在は「チームでゴールを達成するための働き方」をチームで考えて動くようになれました。

そして単に指示の通り働く、ではなく、自分達で作戦を考えて実行する、失敗しながらも改善していっています。

例えるならば、サッカーで試合前に「あそこでゴール前にパスを出すのであそこまで走っていってくれ」「あの敵は手強いのでマークしてくれ！」と作戦会議をしているようなものです。実際に走りながら、「もっと前に出て！」とか「パスするよ！」とか声をかけながらワーワースプリントを駆け抜けています。

また、スプリントでタスクが達成できなかったとしても「今回はあそこの連携がうまくいかなかった！　次はこの作戦でいこう」とか「こういう無駄があったので、やらなくても良い方法無いかな？」などワイワイ話し会っています。

実際、「ペアプログラミングを導入しよう！」とした際に定着するのがなかなか難しかったのですが、このチームでは自然にペアプログラミングが定例化しています（時には5人になるときも)。なぜならば「ペアプロの方が効率がいいから」。そのような自律的な改善が随所で行われています。

▲5人プログラミングを行うチーム。

こう言うとといろいろ語弊があるとは思うんですが、この感じ、ものすごくサッカーとかラグビーのチームスポーツっぽいです。楽しいです。

いかに1週間後のスプリントのゴールを達成するか、そのために作戦を考え、失敗は反省し次のアクションを考え、成功はチーム全員の成果として全員で喜ぶ。そんな楽しく苦しい開発スタイルを今、私たちは手に入れようとしているところです。