2018.10.14

スクラムプロダクトオーナー（LSPO）研修を受けて

日記
IT

Pocket

アジャイルという言葉を聞いたことがある、という人は多いのではないでしょうか。

なんかIT業界で、使われているらしい、何となく新しそうな開発方法の名前ですね。

ではスクラムという言葉は聞いたことがあるでしょうか。ラグビーの用語として聞いたことぐらいはあると思いますが、まさにそれを語源した言葉になっています。

スクラムは、顧客のフィードバックを得ながら短いサイクルで開発を行う、アジャイル開発のフレームワークの一つです。

これらの説明でアジャイルとスクラムを理解できる人はIT業界以外では少ないでしょう。

本当はIT以外にもアジャイルとかスクラムは適用できるのですが、作り直しの容易なソフトウェア開発に特に効果を発揮しやすいし、日々変化を続ける業界ならでは文化にも非常にマッチしたので、IT業界からスタートしたと思われます。なのでアジャイルは、迅速かつ変化に柔軟なソフトウェア開発を行う軽量な開発手法群の総称としての意味合いが大きいです。

話を戻すと、アジャイルというソフトウェア(以外にも使える)開発思想があり、その思想にあった具体的な方法論(フレームワーク)の一つがスクラムというわけです。

今回はスクラムの研修を受けてきたので、スクラムの紹介をしたいと思います。

ちなみにスクラム以外にも、アジャイルソフトウェア開発の代表的な手法としてXP(エクストリームプログラミング)がありますが、このエントリーではスクラムとの比較を含めて説明は割愛します。

もう一度、スクラムという言葉を振り返ってみると、「顧客のフィードバックを得ながら短いサイクルで開発を行う」ということは、「顧客はフィードバックにより要求を変えてくるかもしれないので、ちょっとずつ小出しに製品を出すことでその都度反応をたくさんもらおうぜ」ということを言っているのですが、さらにスクラムとしてはスクラムチームとして、「その反応をもとに得た新しいゴールに到達するため、開発チームが一体となって働くこと」も含みます。

つまり1人じゃ出来ない、ということです。(1人でできる開発であればスクラムを使うまでもない、とも言えます)

チームとして成果を最大化するために、チームの決まりごと、ルール的なものがあります。それがスクラムの方法論、フレームワークで規定されているというわけです。

ルールの一つに、スクラムチームの役割、というのがあります。スクラムを組むメンバーには以下の役割を担います。

プロダクトオーナー(PO)
スクラムマスター(SM)
チーム
リーダーシップ(所謂トップマネジメント。Scrum Inc.の研修に登場したけど、一般的にはスクラムチーム外なので出てこない)

このうち、チームは実際にプロダクトを作り出す役割を担当します。作業方法はチームが決めて、ただし作業結果には責任を持ちます。一方POは顧客の代表者として振る舞い、ビジョンと価値を明確にして優先度(作る順番)を決めます。これはROI(費用対効果)を最大化する役割とも言えます。そしてSMはスクラムのフレームワークが正しく機能するためのファシリテーター(調整役)として動きます。チームやPOがその役割を全うできるように支援する、縁の下の力持ち的な役割ですが、外部干渉からチームを守ったり、コーチ役になったり、スクラムのイベント(セレモニー)を調整したりと幅広い動きが求められます。これらのチーム、PO、SMが一つのスクラムを組んで、共通のゴールを目指します。

ちなみにリーダーシップという役割は、スクラムチーム内でどうしても解決できない問題が出てきてしまった時に、出現する役割です。チームメンバーが複数人同時に病気になってしまった、とかPOがプロダクトのビジョンさえもコロコロ変更するような一貫性のない言動が治らない、などの人的資源マネジメント的な部分がそれにあたるかもしれません。

さて、このスクラムというフレームワークは、顧客からすれば、途中で変更要求をしても良いという仕組みは最高に思えます。今まではリリースのXか月前までには仕様をFixさせてくれ、という情報システム部からの非情な宣告に従わなくてもすむのですから。しかし、スクラムといえども万能ではありません。

鉄の三角形という言葉をご存知でしょうか。「担当省庁、政党または議員、利益集団」を思い浮かべた人もいるかもしれませんが、今回のお話は、「時間、コスト、スコープ」を頂点とした三角形です。

ウォーターホールに代表される従来型の開発では、スコープは決まっている前提でした。見積もりをお願いするときもこんなことをやりたいんだけど、時間とコストはどのくらいかかる？と言った感じです。大抵のプロジェクトではリリース日(=時間)も決まってしまっているので、動かせるのはコスト(=残業代や休日出勤手当、火消し部隊の追加投入費用)だけだったりもします。

一方、スクラムでは時間とコストを固定します。例えば5人のチームで1週間働く、という前提にして、その中でできるスコープを考えます。たくさんの変更要求があれば、その分リリース日は遠退いていく仕組みとも受け取れます。このあたりは従来型の開発の方が良いと考える顧客もいるでしょう。ただし、本当に重要なもの、価値の高い機能は先に作ってしまうことで、必要最低限の機能さえリリースしてしまうことができれば良いという考え方もあるので、人の命や厳密なお金の計算等間違えることが許されない機能以外では、できている部分だけリリースしちゃえ、ということもできます。

アジャイルもウォーターホールもそれぞれ一長一短があるけど、スクラムの場合は、POが優先度を適切に設定することで短所を打ち消すこともできるかもしれません、というお話でした。POの優先順位決定は非常に重要な作業ですね。

スクラムは、スプリントという短い期間に分割して仕事を行います。スプリントが終わったら、顧客にレビューを行いすぐにフィードバックを貰います。そしてPOが価値ある順番に開発する機能の優先度を並び替えて、次のスプリントに挑みます。もちろんスプリントの期間は決まっている(大抵は2週間程度)ので、その中で作れるものだけを計画します。作り方はチームにお任せします。仕事のやり方はチームが一番よく知っていて、そしてプライドもあるからです。こうしたスプリントのサイクルを回すことで、結果的に価値の高い順番に小さなプロダクトが生み出されて行き、先にフィードバックをいただくことで大きなやり直しも少なくなり、結果的に素早くかつ柔軟にプロダクトが完成するのです。

以上、少し駆け足の説明になってしまいましたが、スクラムの概要をつかんでいただければ幸いです。

最後に、研修中に印象に残ったことを紹介してこのエントリのまとめとしたいと思います。