ユーザーに価値を問い続けることで自律的なチームとなる『スクラム』

スクラムのプロセスはチームの自律を促す

img_4806.jpg

以前お伝えしたとおり、スクラムとは複雑なソフトウェア開発の「現状を把握するためのフレームワーク」だ。

そして、これまでマネジャーに集中していた役割をチームで分担してプロダクトのゴールに向かう、一人の天才ではなくチームの力を信じるワクワクする手法だが、逆に言えばメンバーには「主体性」「自律」が求められ、スクラムの語源であるラグビーの陣形のように仲間と「力を合わせる」ことが必須となる。

だから「誰かがやってくれる」「自分のこと だけやってたい」と思っているメンバーばかりだと開発は進まない。

これまでの開発(ウォーターフォール型と呼ばれる)手法ではユーザーに製品を届けるまで長い検討時間が必要だったが、スクラム開発ではスプリントと呼ばれる一定の周期(1~2週間が多い)毎に「動く製品」を出し続ける。

これまでの開発の全てを否定するわけではないが、変化が早く複雑なソフトウェア開発においては、ユーザーからのフィードバック開発チー ムの課題解決のループ「短期間」で何度も回し製品を磨き続けるスクラムが適しているようだ。 なぜなら、それは「チームを自律的にする」ことにつながるからだ。

さあ、スクラムの具体的なプロセスについて見ていこう。今回もアカツキ開発現場のスクラムマスター馬場さんに教えていただく。馬場さん、よろしくお願いします。


IMG_5068.PNG
スクラムのプロセス

1.プロダクトバックログ(製品ロードマップ)

「プロダクトバックログ」は長期の製品ロードマップのことだ。ここには製品の開発項目が すべて「優先度」の高い順に記載されている。

プロダクトバックログに開発項目を追加する権利は開発メンバーなら誰でも持っているが、優先順位の決定はプロダクトオーナーのみが権利を持つ。プロダクトオーナーのミッションはRoI(投資対効果)の最大化だからだ。

プ ロダクトオーナーがRoIを判断するために、プロダクトバックログには開発項目を実現する ための工数も載っている(開発メンバーが見積もる)。

日々状況が変わるソフトウェア開発において計画の見直しはとても重要だ。例えば、製品開発中に新たにユーザー価値を高める機能を思いついたり、技術的な課題が見つかったりする。これらの発見を定期的にプロダクトバックログに反映することで、プロダクトの現状がより分かりやすくなり、チームは次に自分たちが何をすれば良いのかという理解が進み、自律的に動きやすくなる。

 

2.スプリント(実施サイクルの期間)

「スプリント」とは前述したとおり、ある一定の期間であり、チームはその期間で完了定義を満たした完成品を作れるようにする。期間は、チームによって様々で1週間や2週間、長いところでは1ヶ月の期間だったりする。

完了定義は、システムテストが完了していることや、デモ環境で動作し、かつ機能仕様書のレビューが完了してることといったように様々である。 ここでチームが重要視しないといけないのは、アジャイルマニフェスト(包括的なドキュメ ントよりも動くソフトウェアを!)に則って、スプリント毎に「動作するソフトウェア」を アウトプットすることである。

これにより「長い開発のあと実際に出来上がった製品がまったく違う」といった悲劇を回避できる。現状を正しく把握することが重要なのだ。

 

3.スプリント計画(実施計画)

各スプリントは「スプリント計画」とよばれる期間内で実施する計画によって行われる。スプリント計画では、自分たちのチームで決めたスプリント期間内に、プロダクトバックログの上位(優先度が高いもの)からどこまでをコミットするかを開発チーム自身で決める

計画と実際の実現方法の間には、どうしてもズレが発生する。チームが実現方法を考えた上で、プロダクトオーナーとチームメンバーとで協力して計画を立てること重要だ。

 

4.デイリースクラム(朝会)

スプリントが開始されてからは毎日「デイリースクラム」を行う。私たちは毎朝「朝会」と 呼んで実施している。内容はメンバーそれぞれの「昨日やったこと」「今日やること」 「困っていること」の共有である。

ソフトウェア開発では日々予想外の出来事が起こる。作業上の障害に早く気付き、どうやってその障害を乗り越えるかを、自ら決めて進むことが生産性に大きく影響を与えるため、毎日顔を合わせた朝会は大切な時間である。

 

5.カンバンボード(状況の見える化)

今自分たちがどういう状況なのかを見えやすくする工夫(見える化)はチームによって様々だが、「カンバンボード」を使うことが多い。アカツキではホワイトボードを「ToDo(や ること)」「Doing(やっていること)」「Done(やり終わったこと)」に区切って付箋を貼っていく形式をよく行っている(挿絵のカエル君たちが使っているものだ)。

カンバンボードの作り方はチームによってカラーがよく出ており、アカツキでも可愛い女の子やイケメンのイラストの上にDoing付箋を貼っておき「早く彼女(彼)を見えるようにしよう!」と、付箋をDoneに移していく動機づけにする遊び心のある面白い工夫を行なっているチームもある。自分たちのボードを改善するために他チームのボードを見て回るといった動きもよく見られる。

型が決まっていることで、その中での工夫が促進される。つまり 「自律」「主体性」が促される仕組みになっているのだ。 カンバンについては@ryuzeeさんの【資料公開】カンバンのキホン  が非常に分かりやすいので参考いただきたい。

 

6.スプリントレビュー(評価)

スプリント期間が終わると「スプリントレビュー」を実施して、スプリント計画でコミット した内容が実現しているかを確認する。

ここでは達成していない項目を次のスプリントに持ち越すと判断したり、達成していても、想定と違えば新たな問題として取り上げ、どうすれば解決できるかを自分たちで話し合ってプロダクトバックログに項目追加をしたりする。

 

7.スプリントレトロスペクティブ(振り返り)

最後に「スプリントレトロスペクティブ」という振り返りとも呼ばれる活動について説明する。ここでは、開発チームが生産性を向上するために次のスプリントで実行させる具体的なアクションを決定する。 問題を表出化するための方法はによって様々で、私のチームではKPT(Keep良かったこと 継続したいこと・Probrem改善したいこと問題・Try挑戦したいこと)というフレームワークをよく使っている。

 

ユーザーに価値を早く届け続けることが自律につながる

以上がスクラムのプロセス、スプリントで行われる活動の概要である。ほとんどの活動は開発メンバーそれぞれが主体的に行動をすることが主眼になっていて、これを実践するとチームは自律的になっていく

私がプロダクト開発においてスクラムを好むのは、チームが自律的な組織を目指す上で 「ユーザーに早く価値を届ける」ことが重要だと思っているからだ。

なぜなら、作った物の価値を決めるのは、自分たちではなくユーザーだからである。価値を短いスパンで数多く届 けることによって真の問題に早く気づくことができ、自分たちが今取り組んでいる活動の 「意義と目的」が明確になるからだ。


馬場さん、ありがとうございました。これでテーマ7.組織開発は終わりである。

image
テーマ7.組織開発