blog

DeNAのエンジニアが考えていることや、担当しているサービスについて情報発信しています

2014.03.06 イベントレポート

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

by Satoka.Chibana

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

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

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

Scrum Gathering Tokyo2014

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

LicenseCopyright All rights reserved by fullvirtue

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

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

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

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

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

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

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

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

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

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

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

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

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

LicenseCopyright All rights reserved by fullvirtue

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

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

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

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

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

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

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

以上です。

最後まで読んでいただき、ありがとうございます!
この記事をシェアしていただける方はこちらからお願いします。

recruit

DeNAでは、失敗を恐れず常に挑戦し続けるエンジニアを募集しています。