▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! Youtubeチャネルの登録はこちらから！
「イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント」【F17-1C】セッションの書き起し記事をいよいよ公開！10回シリーズ(その5)は、流行しているスクラム開発でイノベーティブなプロダクトは生めるのか？について議論しました。開発手法について知見を深めたい方も必見です。是非御覧ください。
ICCサミットは新産業のトップリーダー600名以上が集結する日本最大級のイノベーション・カンファレンスです。次回 ICCサミット FUKUOKA 2018は2018年2月20日〜22日 福岡市での開催を予定しております。参加登録は公式ページをご覧ください。
▼
【登壇者情報】
2017年2月21〜23日開催
ICCカンファレンス FUKUOKA 2017
Session 1C
イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント
（スピーカー）
岩田 和宏
JapanTaxi株式会社
取締役CTO
柄沢 聡太郎
株式会社メルカリ
執行役員CTO（※2017年4月より執行役員VP of Engineering）
平山 宗介
株式会社メドレー
取締役CTO
山崎 大輔
Supership株式会社
取締役 CTO室室長
（モデレーター）
松岡 剛志
株式会社レクター
代表取締役
▲
▶「革新的なプロダクトを生み出す開発マネジメント」の配信済み記事一覧
連載を最初から読みたい方はこちら
最初の記事
【新】イノベーティブなプロダクトを生み出す開発/エンジニアリング・マネジメント【F17-1C #1】
1つ前の記事
プロダクトリリースに求められる最低限のレベルとは？【F17-1C #4】
本編
松岡 次は「アジャイル開発は、イノベーティブなプロダクトに必須であるか」というテーマです。
▶︎編集注：ソフトウェア開発の手法として主に「ウォーターフォール開発」と「アジャイル開発」があります。「アジャイル開発」や「スクラム開発」については文中に説明があります。
アジャイル開発はイノベーティブなプロダクトに必須か？
松岡 今この会場には、社長さんが多く参加されているのでしょうか？
社長をしていらっしゃる方、手を挙げて下さい。
部下の方に「うちもスクラムじゃないとダメだ！」といったことを言われたことのある方？
思いの外少ないですね。どうしましょう。
柄沢 そういう人はあまりいないんですよ。
松岡 いないんですね。
柄沢 今、皆さんはスクラムですか？スクラムっぽいのかとか。
今、弊社にはプロダクトが5、6個あって、チームが5、6チームあるのですが、1チームだけはスクラムで取り組んでいて、PM（Project Manager）に権限を持たせていてやっていますね。
松岡 前提になりますが、言葉の定義として「アジャイル開発」と言われてピンときますでしょうか？
（会場挙手）
松岡 あ、結構大丈夫そうですね。ありがとうございます。
スクラムは？
（会場挙手）
ありがとうございます。
「ウォーターフォール開発」について簡単にご説明したいのですが・・・なるべくポジショントークを削って喋るのが難しいですね（笑）。
ウォーターフォールというのは、きちんと要件を定義して、次に外部設計をカッチリ作ってというように、時系列に作業工程を定義し、線表を使いならフェーズごとに順番に進めて、プロダクトを出すという開発スタイルです、結構大きなサイクルをしっかりと・・・というのは微妙に合っていないのですが（苦笑）。
柄沢 説明するのは難しいですよね。
松岡 難しいですね。
大きなサイクルを、しっかりと段階を踏んで進めていこうというのが「ウォーターフォール開発」です。
作る物が明確でスケジュールがタイトな場合などに、良いとされています。
「アジャイル開発」は、プロダクトは何が当たるか分からないから、なるべく小さな単位でクルクル回して小さな製品をなるべく速く出荷する、それを組み合わせて積み重ねて物を作っていくといったように、作る物が不明瞭な時代に作られた考え方です。
アジャイル開発は概念に近いようなものです。
それに対してスクラムというのは、そのアジャイル開発を行う上での一つのやり方、型のようなものです。
今、エンジニア界隈では、そのアジャイル開発や、スクラム開発をやっていこうというのが結構流行っています。そういった文脈があります。
何か僕の説明で分かり難いところがあったら、フォローして下さい。
柄沢 流行っているかというのは、ちょっと分からないですけれどもね。
平山 流行っているのではないですか？
柄沢 流行っているのですか？
平山 信仰者がいるのではないですか？
松岡 なるほど。
皆さんも、スクラム的なことはされているのですか？
柄沢 弊社の場合は、メルカリという1つのプロダクトに対して5、6個のチームがあり、1つのプロダクトに対してというと少し違うかもしれませんが、5、6個それぞれのミッションによってチームがあり、現在、1つだけスクラムをやっているところはあります。
アジャイル開発は先ほど申し上げたように「概念」なので、僕らは基本的にアジャイル開発だというのはたしかにそうなのですが、それでスクラムをやるべきかどうかというのが、どうだろうかというところなのではないですかね。
きちんとやるのって、結構難しいんですよね。
かつ、スクラム開発をきちんとやるにあたって何が難しいかというと、全員がきちんとスクラム開発のやり方を理解しているとか、エンジニア以外のステークホルダー、要するにプロダクトマネージャ―やその上にいるディレクターが、きちんとその概念を理解してそういう風に振る舞わないと成り立たないことです。
弊社の場合は、その（スクラム開発を行っている）1チームはUSにいるチームで、彼らは結構独立してそこで動いており、かつスクラム開発に対して知見のあるメンバーが何人かいるのでそこでしっかり回せているというのがあるのですが、日本にはそのようにスクラム開発をしっかりやっているチームはないですね。
スクラム開発は手法。プロダクトが目的。
平山 いつもとても疑問に思っているのですが、なぜ「スクラムマスター」のようなものが必要なのでしょうか。
スクラム開発の文脈で語る時というのは、プロセスで語る方がすごく多いんですね。
自分としては、むしろそういう人がもっとプロダクトに寄ればもっといいパフォーマンスが出るかなと思っているケースもあるんですね。
なぜスクラム開発は「スクラムマスター」のような人がいないとできないのか疑問です。
そもそも、普通に・自然にできればよいのに、教えなければできないような仕組みを作るのはどうなのかなと。
「アジャイル的な」で十分こと足りると思っています。
スクラム原理主義ってすごくいると思うのですが、そこは自分としては非常にナンセンスと感じていて、あくまでもプロダクトを推進するためにアジャイル的な文脈がいいというのが一番カッコいいし綺麗だなと思いますよね。
松岡 なるほど。
岩田さん、今何か飲み込まれましたか？（笑）
岩田 いえいえ（笑）
僕もそう思っています。
結構スクラムにこだわってしまう人がいて、「スクラムではなくてプロダクトでしょ」と言いたくなる時があるのです。
それはスクラムの手法ではないですよねなどと言われても知ったことではなくて、プロダクトが良いか悪いかという判断でやってくれないとという話はしますけれどもね。
例えば2週間に1回スプリントがあってというのも、突発的に出てきてしまうこともあったりする訳なので、緩いスクラムでいこうといったことは言っていますね。
あまり手法にこだわり過ぎると、何のためにというのが出てきてしまうので。
山崎 プロダクトということですよね。
柄沢 はい。
柄沢 まさにそこは全会一致だと思います。
山崎 そうですよね。
平山 結構往々として起きる現象だと思っていて、そこはトップがリーダーシップを発揮して、メッセージを出していかないと、そういったことに陥りやすいのではというのが自分の考えです。
松岡 なるほど。
スクラムは”普通”の人が一定の成果を出すためのフレームワーク
柄沢 もう一つ付け加えで、語弊を恐れずに言うと、スクラム開発というのは、チームを構成するメンバーの能力にばらつきがある場合に、それでも平均的に、一定以上のパフォーマンスを出すためのフレームワークだと思うんですよ。
山崎 なるほど・・・
柄沢 もちろんそうでないこともありますが。
すごく優秀な人達が、優秀なスクラムを回すことによって、ものすごくパフォーマンスが出るケースももちろんあるのですが、それは結構稀なケースというか。
そうではなくて、開発経験の浅いプロダクトマネージャや、見積もりの苦手なエンジニアなどがいたとしても、チームでそうしたばらつきを吸収して成長と改善をしていくことで、一定基準のパフォーマンスを出させることのできるフレームワーク、という意味です。
山崎 ペアプロ（ペアプログラミング）が流行ったじゃないですか。
柄沢 はい。
山崎 あれも強いエンジニア同士がやってしまうと、強度が強すぎてヘトヘトになってしまうんですよ。
40分やると40分休まないとダメみたいなくらい。
だからそれは何となく分かる気がします。
柄沢 ですから、またケースバイケースのような話になってしまうのですが、適用できる場面もあって、有効な場面もあるのだけれども、ゼロイチで開発が優秀な人達を集めているという前提においては、あえてスクラム開発をやる必要がないことが多いかなとは思いますね。
松岡 逆に、残念ながら優秀な人が集まりきらなかった場合は、こういうことをやった方がいいのではないかということですね。
柄沢 有効な手段の一つにはなり得ると思います。
松岡 平山さんどうぞ。
平山 それって機能するのかなと思ったのですが。
リズムを良くしようというくらいではないかなと思っていて、結局パフォーマンスを上げるというと、どちらかというと教育やそちらの文脈にかかるのかなと思っています。
松岡 リズムを良くするもの。
平山 リズムを担保するものですね。
よりシャープにリズムを回すためのものと言えば担保されると思うのですが、そもそもベースとしての教育はしないといけないと思います。
リズムが良かったとしても、その人がそのリズム通りのバリューを出せるとは限らないので。
松岡 確かに。
そういう意味で言うと、勉強する習慣が少し弱くなっている人にとっては、スクラム開発が流行ものとして入って来たのをみて「スクラムをやらなければならないんだ。よし、学ぼう！」とさせる意味では一定の効果があるかもしれないですね。
それは確かに柄沢さんのおっしゃったように、トップエンジニアはそういう世界で生きているのかというと、違うような話かもしれないです。
岩田 あとは、エンジニア自身のパフォーマンスが結構客観的に測れる手法ではあるかなと思うんですよね。
この期間内にこれだけやる、例えば「これは3人/日だよね」というように皆が合意した仕事が自分には倍や3倍かかった時に、自分の今の実力というのが自分で測れるかなと。
別にスクラム開発ではなくてもいいのですが。皆で合意さえしてしまえばと思うのですがね。
松岡 確かに、コミットしてやるもので、見積もりを外し続けるというのは少しおかしいのではないかといったのは、もしかしたらエンジニアリングマネージャーではない方でも見えるようになるという意味ではあるかもしれないです。
同時にスクラムにおいてベロシティ（速さ）を評価指標にしてはいけないという鉄則が有り、このあたりの文脈を理解して扱わねばならないことかと思いました。
次のテーマに移りましょうか。
これについて、他におっしゃりたいことはないですか？
もっと本質的な爆弾を放りたい方がいらっしゃれば（笑）。
大丈夫ですね（笑）。
(続)
次の記事を読みたい方はこちら
続きは 外注ではイノベーティブなプロダクトは生まれないのか？ をご覧ください。
▶平日 毎朝7時に公式LINE@で新着記事を配信しています。友達申請はこちらから！
▶ICCの動画コンテンツも充実! ICCのYoutubeチャネルの登録はこちらから！
編集チーム：小林 雅／榎戸 貴史／戸田 秀成／横井 一隆／立花 美幸／Froese 祥子
【編集部コメント】
スクラム開発は手法であって、プロダクトが目的。最終的なアウトプットを見失いたくないものです。（横井）
他にも多く記事がございますので、TOPページからぜひご覧ください。
更新情報はFacebookページのフォローをお願い致します。
