Scrum Gathering Tokyo2014から見える、新思考の渦

みなさん、こんにちは。DeNAの知花です。私はスクラムマスターとして、Mobageプラットフォームのエンジニアやサービス企画のチームのサポートを経て、現在はゲーム開発の企画・開発メンバーと日々研鑽を積んでいます。

アジャイル開発と共に発達してきたスクラムですが、私は昨年末に、社会人7年目にして初めてスクラムに出会いました。

今回は技術ネタではないのですが、Scrum Gathering Tokyo2014のセッションで登壇の機会がありましたので、そこで感じたことを皆さんにも共有したいと思います。

Scrum Gathering Tokyo2014

<参考> Regional Scrum Gathering http://scrumgatheringtokyo.org/2014/

①開発したいサービスがたくさんあるわりに、スピード重視で進めなければという焦りから、無駄な作業や失敗が数多く起こっている！？

誰のためのサービスなのか？
この機能はどのような課題を解決してくれるのか？
このサービスの売りはどこだろう？

目の前の作業に明け暮れ、こういったことをおざなりにして進めてしまい、結局何つくりたいんだろう？とプロダクトビジョンに立ち返る企業やチームは意外に多いようです。参加したセッションの中には、１ヶ月間、「何のために、どこまで何を作ったのか？」がわからないまま進んでしまった、という事例報告もありました。たとえ開発者であっても、ビジネスサイドの観点や発想を持つことで、こういったリスクは未然に防いでいきたいものですよね。スクラムの中には、常にこういったことが意識できるエッセンスが含まれています。

②予算・時間・スコープ　のコントロールですべてが決まる！

好きなモノを時間をかけて作りたい

－職人気質の人はどのような業界の方でもそう願うのが常。ただこのIT業界、ITビジネスにおいては、なかなかその通りいかないのが現実ですよね。プロダクトを作る時大体制約があるのは、予算と時間。残るは「スコープ（作る範囲）」でコントロールするしかない訳です。

「こんなサービスを作りたい！」希望する内容からいかに要件をそぎ落として、優先順位をつけられるか！？が意外と出来ないのだ、と発表をしている企業も多かったです。サービスを開発するエンジニアにとっても、「作ることが仕事！」から「作るための協働が仕事！」が肝になってくる時代なんだなあ、とつくづく思います。

スクラムでは、チームの稼働実績をベースにしてマイルストン設定やスコープコントロールを可能にします。

③上司の言うことや、チーム内の発想を頼りにするのは限界がある！？

アジャイル開発では、「より顧客の声を優先したものづくり」を大切にする、という方針があります。

よりクリエイティブか？ターゲットユーザーの課題は本当に解決しているのか？

この問の仮説検証をするには、チーム内に閉じこもって延々と議論を重ねるよりも、早々とリリースしてみて、市場の声や反応を得るのがコストも安くすみますし、リスクテイクにもつながります。反応が悪ければ、すぐにカイゼンに着手できる。早期撤退も考えられる。変化の多いIT業界には、アジャイル開発やリーンスタートアップ的な思考はますます必要になってくるでしょう。

そういったマインドチェンジは世界中で、ありとあらゆる業界・企業で確かな渦となって、沸き起こっています。

いくつかのセッションに参加する中で、こんなことを感じていたわけですが、私の登壇した

「Why do we use Scrum? ユーザ企業のスクラム導入事例～失敗体験から学んだスクラムの本質～」

という講演では、以下の４つのことをお伝えしました。

何のためにスクラムを導入するのか？を考えるところから始める（何を改善したいのか？）
ビジョン合意なくしてチーム運営しない（プロジェクト始める時は、ビジョンの定義をすり合わせる必要がありますよ。） →GROWモデルを使った、Vision Treeという手法を紹介しました。
なぜProduct　Ownerやチームが改善されないのか？の理由を探さないとダメ（あるべき論を話してもダメ。ヒアリングして考えて原因と対応策を一緒になって考えるべき。）
スクラム屋さんになって、押し付けをしてはダメ。(Scrum Slaves)

※主にスクラムマスターの観点から考えて

成功事例は事例以外の要因がかさなっての成功なので、主に失敗談を中心としたお話をさせていただきました。 SlideShareにも資料をアップしてありますので是非御覧ください！

http://www.slideshare.net/TakeshiKaise/why-do-we-use-scrum

以上です。