Tokyo2014から見える、新思考の渦Satoka.ChibanaKeywords:みなさん、こんにちは。私はスクラムマスターとして、Mobageプラットフォームのエンジニアやサービス企画のチームのサポートを経て、現在はゲーム開発の企画・開発メンバーと日々研鑽を積んでいます。アジャイル開発と共に発達してきたスクラムですが、私は昨年末に、社会人7年目にして初めてスクラムに出会いました。Tokyo2014のセッションで登壇の機会がありましたので、そこで感じたことを皆さんにも共有したいと思います。fullvirtue1開発したいサービスがたくさんあるわりに、スピード重視で進めなければという焦りから、無駄な作業や失敗が数多く起こっている!?誰のためのサービスなのか?この機能はどのような課題を解決してくれるのか?このサービスの売りはどこだろう?目の前の作業に明け暮れ、こういったことをおざなりにして進めてしまい、結局何つくりたいんだろう?とプロダクトビジョンに立ち返る企業やチームは意外に多いようです。参加したセッションの中には、1ヶ月間、「何のために、どこまで何を作ったのか?」がわからないまま進んでしまった、という事例報告もありました。開発者であっても、ビジネスサイドの観点や発想を持つことで、こういったリスクは未然に防いでいきたいものですよね。スクラムの中には、常にこういったことが意識できるエッセンスが含まれています。コントロールですべてが決まる!好きなモノを時間をかけて作りたい-職人気質の人はどのような業界の方でもそう願うのが常。このIT業界、ITビジネスにおいては、なかなかその通りいかないのが現実ですよね。プロダクトを作る時大体制約があるのは、予算と時間。残るは「スコープ(作る範囲)」でコントロールするしかない訳です。「こんなサービスを作りたい!」希望する内容からいかに要件をそぎ落として、優先順位をつけられるか!?が意外と出来ないのだ、と発表をしている企業も多かったです。サービスを開発するエンジニアにとっても、「作ることが仕事!」から「作るための協働が仕事!」が肝になってくる時代なんだなあ、とつくづく思います。スクラムでは、チームの稼働実績をベースにしてマイルストン設定やスコープコントロールを可能にします。3上司の言うことや、チーム内の発想を頼りにするのは限界がある!?アジャイル開発では、「より顧客の声を優先したものづくり」を大切にする、という方針があります。クリエイティブか?ターゲットユーザーの課題は本当に解決しているのか?この問の仮説検証をするには、チーム内に閉じこもって延々と議論を重ねるよりも、早々とリリースしてみて、市場の声や反応を得るのがコストも安くすみますし、リスクテイクにもつながります。反応が悪ければ、すぐにカイゼンに着手できる。早期撤退も考えられる。変化の多いIT業界には、アジャイル開発やリーンスタートアップ的な思考はますます必要になってくるでしょう。いったマインドチェンジは世界中で、ありとあらゆる業界・企業で確かな渦となって、沸き起こっています。~失敗体験から学んだスクラムの本質~」という講演では、以下の4つのことをお伝えしました。何のためにスクラムを導入するのか?を考えるところから始める(何を改善したいのか?)ビジョン合意なくしてチーム運営しない(プロジェクト始める時は、ビジョンの定義をすり合わせる必要がありますよ。Treeという手法を紹介しました。Ownerやチームが改善されないのか?の理由を探さないとダメ(あるべき論を話してもダメ。ヒアリングして考えて原因と対応策を一緒になって考えるべき。)スクラム屋さんになって、押し付けをしてはダメ。Slaves)※主にスクラムマスターの観点から考えて成功事例は事例以外の要因がかさなっての成功なので、主に失敗談を中心としたお話をさせていただきました。SlideShareにも資料をアップしてありますので是非御覧ください!http://www.slideshare.net/TakeshiKaise/why-do-we-use-scrum以上です。