よしはらです。暑い日は嫌いです。理由は聞かないでください。

さて、iPhoneアプリサービス事業部(通称プリサー)ではこの度スクラムを導入するになりました。第1回目はスクラムワークショップを実施しましたのでその内容をご紹介します。

ただ、詳しい説明は他にも素晴らしい文献がありますのでそちらに譲ります。

今回は実際に体験したわかったコトを書いてみます。

なんでスクラム組んだの?

なぜプリサーがスクラムを始めたのかということですが、今までは、各チーム毎に開発プロセスを決めていました。1年前ぐらいまでは、アプリ開発の規模も小さかったので、少人数の個の力でこなすことができていました。ただ、ココ最近はスマホアプリでも規模が大きくなってきており、よりチームで開発することも多くなってきました。またプリサーメンバーも毎月入社しており、人も増えてきたので開発プロセスをしっかり整えより良い開発を行っていきたいなということで、今回スクラムの導入がきまりました。スクラムについては実践経験の少ない私達は、アジャイルコーチにお願いすることにしました。

今回、アジャイルコーチを引き受けて下さった、木村さんと高江洲さん

スクラム講習

スクラム講習は以下のタイムスケジュールで行われました。ほぼ半日です。

1時間：スクラムについての座学
3時間：レゴを使ったスクラムシミュレーション

座学では、アジャイルソフトウェア開発宣言から始まりスクラムの全てを学びます。まずスクラムとは「複雑かつ変化の激しい問題に対応するための手法」であり「お客様にとっての価値あるモノ(システムorアプリ等)を届ける」ことにあります。

大きな特徴は

• 軽量
• 理解が容易
• 習得は非常に困難

そして

• 自己組織化されたチーム
• 2~4週間の"スプリント"を繰り返すことでプロダクトを進化させる。
• 要求事項は"プロダクトバックログ"と呼ばれるリストで捕捉する。
• 特定の技術的なプラクティスは定められていない。
• "アジャイルプロセス"の1つ

と説明を受けます。プリサーメンバー真剣に聞いています。

ここから具体的な骨組みと役割等の説明が入りますが、かんたんにまとめてみました。

スクラムの骨組み

3つのロール

• プロダクトオーナー
• スクラムマスター
• 開発チーム

4つのミーティング(イベント)

• スプリントプランニング
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

3つの道具(成果物)

• プロダクトバックログ
• スプリントバックログ
• インクリメント

によって構成されています。

ここからは、スクラムを行う上での各自の役割は以下になります。

プロダクトオーナー

• プロダクトの機能と特徴を定義し、リリース日とリリース内容を決める
• 製品が生む利益についての責任を持つ
• 機能の優先順位を定める
• 機能と優先順位を見直す
• 作業の成果を受け入れる、または拒否する

スクラムマスター

• スクラムプロセスの番人
• 外部の干渉からチームを守る
• プロジェクトマネジメントの代表
• スクラムの価値とプラティクスの実現に責任を負う
• 障害事項を取り除く
• チームが十分に機能し生産的であることを保証する
• 全ての役割の人たちが緻密に協力関係を保てるようにする

チーム

• 一般的に5人から9人
• 機能横断的
• メンバーはフルタイムプロジェクトへ参加
• チームは自己組織化されている

 

まとめてみれば、プロダクトオーナー、スクラムマスター、開発チームはお互いを信頼し自己組織化を図りながらお客様の求めるビジネス価値の高い商品を提供することが目的になります。商品を作るためには何を作るのか。それをとりまとめたのがプロダクトバックログです。

プロダクトバックログ

• 要求事項の一覧
• プロジェクト途中に求められる全ての成果と一覧
• 理想的には、各アイテムごとに利用者、顧客における価値が記述れていることが望ましい
• プロダクトオーナーによって優先順位付けされる(優先度ではない)
• 各スプリントの開始前に再度優先順位は振り直される
• 自分の領域的に一番聞き込んだのがこちらです。

このブロダクトバックログが開発されるものの一覧であり成果物にもなります。その為にはユーザーストーリーが必要になります。

ユーザーストーリー

<役割> として <機能や性能> が欲しいそれは <ビジネス価値> のためそしてそれを実行するためには、よいストーリーを作ること。

よいストーリーとは?

INVEST

• Independent (独立している)
• Negotiable (対話を引き出す)
• Valuable (ユーザ価値を提供する)
• Estimable (見積り可能である)
• Small (小さい)
• Testable (テスト可能である)

これは非常に重要なことだと思いながら話を聞き、
この後も相対的な規模の見積もり(プランニングポーカー)スプリント計画、スプリントバックログなど全てについて学んだところでいよいよワークシッョプの開始です。

スクラムワークショップ

ワークショップの流れは下記になります

1. 1.チーム分け
   2.プロダクトオーナー、スクラムマスター決定
   3.ユーザーストーリーに基づいてプロダクトバックログを作成
2. 1.スプリント
   2.スプリントプランニング
   3.デイリースクラム
   4.開発作業
   5.スプリントレビュー
   6.レトロスペクティブ

ここからは当日の模様を少しだけ実況ぽく説明していきたいとおもいます。

理想の街を作りましょう

レゴスクラムでは模造紙の上にレゴと折り紙で街を作ります。
まず2チーム作ります。 各チームは3人から9人で構成されます。これは、その程度の人数が成果物に適切であると考えられています。

チーム決めには、「グーパー」を用意ます。この時ちょっとした問題が発生しました。それは掛け声問題です。この問題の解決はなかなか難しいですね。色々とありましたが2チームできました。

次に、プロダクトオーナーとスクラムマスターを決めます。自分の経験に置き換えれば、
「プロデューサー」=「プロダクトオーナー」「スクラムマスター」=「ディレクター」
の立ち位置に近いかなと理解しました。

この時に見えない力によって自分がaチーム平家のプロダクトオーナーになります。

すなわちお客様の立場です。

テーマは「住みたい理想の街」

何ができたかは文末で発表しますのでもう少しお付き合いください。

依頼する体験と開発の難しさ

チームができたら、いよいよプロダクトバックログの作成です。 どんな街を作るか。コンセプトは「エンジニアが住みたい理想の街」チームメンバーから自由闊達な意見が出ます。 「未来の街だから車は空を飛ぶ。だから空飛ぶ車」そしてグーパーで決まった仲間という謎の連帯感があり後で苦しみます。

プロダクトオーナーの入れ替え。

青天の霹靂のような衝撃が双方のチームに走ります。自分達で決めたコトが違う人に開発されるのです。 この業界で言えば、突然プロジェクトリーダーがいなくなり代わりの人が入ることを示唆します。リアルに想像したらガクブルものですが、これはワークショップです。落ち着いていきましょう。とは言っても騒然としたのは本当の話です。これはスクラムにおける「不安定な状態を作り出す」の形ではないかと後で理解します。実プロジェクトでリーダーがいなくなったら本当に不安定になるのでオススメはしませんが、そんなことまで想像できる程プリサーメンバーは想像力豊かなのです(笑)そしてこの体験で新しい発見が得られるものとなりました。

スプリントを回してみた

ここからは実際の開発現場と然程変わらない光景が繰り広げられます。違うのはMacBook Airに向かうのでなくレゴなだけです。

そして予想通りaチームから呼び出しを受ける

「あのー空飛ぶ車ですが、プロトタイプは1台じゃダメですか?」
「ダメです。5台欲しいです」
「材料が足りないかもしれないし、ダメ?」
「5台ください」
「・・・。」

こんな楽しいやりとりを繰り広げながら学びました。

ただ、この笑ってしまうような空気でも真剣に物事に取り組むコトで得られるものは必ずあります。現実にはお客様から「仕様変更できないか?」「納期が・・・。」などの事が起きている事があります。普段開発してる立場からすれば「このタイミングでは無理」とか思う事も立場が変われば「ここで仕様変更できれば開発がラクになる・・・」なんて気持ちが体験できます。 ユーザーストーリーをタスクに落とし込む作業はまさにソレでした。

工数の見積りはプランニングポーカーで決めます。価値観(これまでの開発経験等)や勘をいい感じに平均化した上で見積もれま何故なら、開発に携わるチームの技術水準が全く同一でないからです。自分はディレクション方面が得意ですがコードは苦手です。方やエンジニアのメンバーはその逆だったりします。得意と不得意を相互に補いながら工数の見積もりを行うこのプロセスから自己組織化の一部が垣間見れてきます。

そして1スプリントを回してからのレトロスペクティブはKPTで行いました。このあたりから各自の協調性というか自己組織化が促進されてきてます。特に工数見積りについては最初こそ差異はありましたが、残タスク計算では全員一致するほどです。次のスプリントでは、タスクを各自が考え最適化された動きをすることで進捗が捗ることに気がつきます。気づけば自分たちで決めたスケジュールを達成してました。

「自己組織化なくしてスクラムなし」少しだけ理解しました。

空飛ぶくるまの街ができた。

車が空を飛んでいる未来の街。健康にも配慮した公園が中心にある街。
なぜか平家免震という意味不明な技術への探求まで盛り込まれました。
空飛ぶ車は駐車してるのとのこと。1台はマニュアル車(MT)で他は全自動とのことでした。

ショッピングモールもできた。

開発チームのデザイナーにより細部までこだわった街。
トイレの作り込みや花壇などはプロダクトオーナーから評価をされる

本当はもっともっとスプリント回して完成度高いの作りたかった両チームでした。
それぐらい楽しくアツく学んでおりました。はい。

スクラムできた?

率直な感想は「楽しく難しい」です。楽しさの裏に現実だったらゾッとする失敗を多数経験してることがあります。この失敗体験こそスクラムを行う上で重要だと感じます。そしてスクラム導入ハードルは高いと思います。これはトレーニングを積むなどして経験値を貯めてレベルアップするしかないでしょう。ただ、やってみることで得られる面があるのも事実です。すぐにスクラム導入しないでも普段の開発における気づきが得られます。機会があれば一度このようなワークショップを経験される事をオススメします!!チーム内でのコミニュケーションが闊達になる副作用?も効果的です。

まとめ

個人的にスクラムに違和感をあまり感じずにいました。自分が元々web・モバイルサービス歴が長いので、プロダクトオーナーやスクラムマスターの役割がプロデューサーやディレクターの役回りとフィットしてるのも一因かと思います。ただ概念の理解と共通認識をチーム一丸となって共有する事ができるのか。開発案件によって使い分ける必要がありそうです。