オフショア開発でもスクラムを実施して短期間で新規サービス立ち上げを成功できた秘密

国内の開発リソース不足という社会的な課題を解決するためのサービス「セカイラボ」の運営を始め、各種アプリ開発や運営で知られているモンスター・ラボ。いまや、「セカイラボ」の拠点数は9カ国17拠点だそうで、言語や文化・習慣を異にしても問題なく同じチームの一員として開発を進められるようにしっかりしたマネジメント体制が築けることも同社の開発体制の魅力。
今回は、そのオフショア開発にも関わらずスクラム開発を選んでしかも新サービス立ち上げを成功したというその具体例を伺いに、同社スクラムマスターの船山さんにお話を伺いました。

船山さん プロフィール:

1990年生まれ。モンスター・ラボ入社3年目。国内・海外拠点の開発チームとともに、アジャイル開発の手法を取り入れたプロジェクトを多数手がけている認定スクラムマスターの有資格者。

ところで、社名にある”monstar”という言葉は、怪物を表す”monster”ではなく、フランス語で「私の」という意味の”mon”と、英語の「星」”star”を組み合わせて創った言葉で「私にとってのスター」という意味を表しています。

モンスター・ラボ社内では、ほぼ初めてのスクラム事例となりました

大井田:

本日はよろしくお願い致します。では、今回のプロジェクトについての概要を簡単にお話いただけますか?

船山:

大手通信キャリアグループからの受託案件の話が決まったのが、昨年の春。開発は5月から始まりました。9月にはサービスリリースになり、それ以降は機能追加をしながら現在に至るまでプロジェクトが続いています。スクラム開発でいこうというのは、クライアント側担当者さんの強い意思でもあったというのが印象深いですが、短期間の要件不安定な開発になりそうだったのでスクラム開発はうってつけと思いましたし、スクラムマスターの資格を持つ私に白羽の矢がたったという始まりでした。

大井田:

当然、オフショア開発も前提なわけだったのですよね? 不安はなかったのですか?

船山:

はい、中国で開発メンバーをアサインして、国内ではデザインや設計メンバーを加える体制でした。チームメンバーとしては20人ほどで、これは現在も概ね変わりません。メンバーのほとんどがスクラム開発は初めてでしたから、開始前のレクチャーは数回私が行ないました。教本としては、公開されている『スクラムガイド』(http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf)を使いました。まずは、スクラムのメリットや注意すべきことを細かくインプットすることを進めたのですが、実際に始めてみないと理解できないこともあると思っていましたから、開発を始めてからも躓くたびにレクチャーの機会を設けました。

オフショア開発だからこその問題をまず解決しなきゃいけなかった

私自身は、やはり単一言語、単一拠点でチーム構成したほうが良いスクラムができるだろうと思っていました。これは、単純にコミュニケーションコストの問題です。デイリースクラムと呼ぶ朝礼を毎朝15分と決めて開催し、「昨日やったこと」「今日やること」「課題」をメンバーが発表するのですが、当初は中国メンバーも全員参加していました。日本語ができないメンバー(かつ、日本側は私も含めて中国語ができないメンバーばかり)ばかりでしたから、翻訳する手間がかかって時間もオーバーするし理解もままならないということがすぐにわかりました。そこで、あるタイミングで、中国側にスクラムやプロジェクト管理に対する知識があり、日本語が堪能なメンバーを加えました。中国側の調整を現地で行なうことと日本側とのコミュニケーションを担っていただくためです。これを早期に実現できたことが、このプロジェクト成功の大きな要素だったと今振り返っても思いますね。デイリースクラムの参加もこのメンバーだけにしたことで、円滑に進むようになったのです。

大井田:

コミュニケーションという問題以外で気になることはあったのですか?

船山:

実はもう2つ大きな問題がありましたね。まずは、離職率が高かったということ。開発が始まってしばらくしたら、メンバーが退職して再アサインしなきゃいけないということがありました。そのタイミングで大きくパフォーマンスが下がってしまったのですね。スクラム開発では、ベロシティ(生産量)が下がると表現します。これがあったので、スクラム開発では一般的に詳細なドキュメントを作らないのですが、引き継ぎがスムーズにできるように考慮したドキュメントは他のスクラムプロジェクトに比べるとかなり量的にも質的にも多いと思います。もう一つは、品質に対しての意識の問題です。もともと詳細設計に類するドキュメントがありませんでしたから、「とりあえずこれくらいで」とエンジニア自身が判断してタスク終了するということが相次ぎました。スクラム開発ではスプリント単位でテスト実行しますから、当初は「なぜこんなレベルでテストするの?」とプロダクトオーナーであるクライアントさんから声が上がるくらいの低品質となってしまっていました。

大井田:

それは具体的に、どのように解決なさったのでしょう? かなり深刻な課題ですよね

船山:

品質の担保については、「マインド」と「仕組み」の両面からの対処が必要でした。マインドというのは、具体的には日本のユーザーがサービスの品質には非常に厳しい姿勢で接するという開発者側も甘えを許さない心持ちで参加してほしいということを事例を踏まえて説明していきました。仕組みの面では、タスク終了時に確認すべき「チェックリスト」を用意してその確認を徹底するようにしたのです。ただ、この問題発見については、スクラム開発を選択したからこそ早期発見ができ、早々に対処できたということはメリットとしてちょっと太字にしておいていただきたいですね(笑)

モンスター・ラボならではのスタイル

スプリント計画は、プロジェクト全体を通して設定されたストーリーポイントに基づいて

大井田:

では、改めて御社のスクラム開発の具体的な流れについてご説明ください

船山:

大雑把な流れをまずお話すると、「計画」+「レビュー」+「スプリント振り返り」がスプリント1つずつの流れです。ちなみに、スプリントの単位は2週間にしています。スプリント計画からお話しましょうか。ここでは、ストーリーポイントも活用しています。

引用:

ストーリーポイントについての説明
スクラムはチームでの成果を重視する。個人のパフォーマンスはチームを支えるが、個人にはあまり着目しない。そういう原則がスクラムにはある。
スクラムにはストーリポイントという工数の尺度がある。これは、ウォーターフォールなど他の開発プロセスが採用する尺度とかなり異なる。ストーリポイントは時間ではない。相対的な尺度と言われる。
ポイントで見積るようになると、チームメンバー全員が共通した基準で見積ることができるようになる。

https://sugoiku.c16e.com/13/

このストーリーポイントについても、導入当初は使用されないはず(※ フィボナッチ数列を利用することが多く、本プロジェクトでもそれを利用)の数字が入ることがあり再レクチャーをした経緯があります。ストーリーポイントが与えられたユーザーストーリーをタスクに落とし込むのは各メンバーです。これの管理は、Redmineを使っています。

Redmineでのプロジェクト管理についても、導入当初は「どう使っていいかわからない」という声が噴出して逐次説明機会を設けたことを覚えていますね。タスク化の話に戻しますが、ストーリーポイントはあくまで相対的な数字です。これをタスク化する際に時間見積もりを加えているのですね。ストーリーポイント1が24時間というルールでももちろんありません。この流れと考え方は、このプロジェクトのひとつの肝ではないかと思います。

SlackとGitHubを併用して、コミュニケーションとコード管理

さらに、現実のコミュニケーションにはエンジニア必携ツールともなったSlackとGitHubを使っています。特にSlackでのやり取りは、Redmine側に転記するようにして極力一元管理できるように注意を払っています。ベロシティが下がることも憂慮されるので、ドキュメント化というポイントにおいても、チャットでやり取りされる経緯・履歴がきちんと管理されることは重要なポイントです。

GitHubへは、タスクそれぞれの画面からリンクを必ず貼っていて、これも管理しやすいようにしています。
こうした一連の動作がメンバー全員がこなれてくるまでには、2ヶ月くらいはかかりましたね。単純に「慣れ」が大きかったと思っています。いまでは、運用面での課題はほぼなくなったと感じています。実際にメンバーが変わるタイミングでも安心できていますね。

スプリント振り返りはKPT管理を採用

大井田:

レビューやレトロスペクティブ(振り返り)はどうですか?

船山:

これも当初は迷いながら進めていった、が正直な告白です。振り返りについては、クライアントさんもプロダクトオーナーとして参加していただいています。KPT(ケプト)管理の方法で振り返りミーティングを行なうようにしましたが、当初は、Pでいう「プロブレム」しか意見が上がらなかったです。「どうしたらいいか?」なんていつも考えていましたね。現在は、うまく回るようになっていますから、逆にTでいう「トライ」が生まれにくくなっているなと感じています。

引用:

KPT管理について
KPTとは、Keep、Problem、Tryの頭文字をとった造語のことです。
プロジェクトの振り返りをするときによく使われる手法で、振り返りをする際の基本といって良い手法だと思います。
Keep:続けること
Problem:問題点
Try:次にすること

http://hisa-magazine.net/blog/ref/kpt2/

ちなみに、このKPTの議事録はGoogle Docを使っています。Redmineのドキュメントでは機能不十分でその選択をしました。ですから、SlackやGitHub同様にRedmineからリンクを貼っている運用手法です。

もう一つ、振り返りでの特徴というか現在のプロジェクトとしては残念な点を付け加えると、振り返りにバーンダウンチャートがうまく活用できていないことです。redmineでこれを表示させる機能は追加できているのですが、全体共有してバーンダウンチャートを見ながらのミーティングができていないのです。これをうまく活用する方法はないものか、と検討が続いていますね。いい方法があればぜひ教えていただきたい(笑)

今後の開発スタイルの展望

モンスター・ラボではスクラム事例が増加中

大井田:

現時点で、このプロジェクトを振り返っていただいての一番の感想は?

船山:

そもそもメンバー全員が初体験ということを踏まえて、まずは9月の時点でのサービス公開は感慨深かったですね。以降は、機能追加を繰り返すという非常にスクラム開発らしい運用ができていて、オフショア開発でもここまできちんとできるぞという自信をつけられました。また、クライアント担当者さんが非常に優秀な方で「プロダクトバックログ」のメンテナンスはほぼお願いできていた状態であったことも、成功の一因だと思っています。これも太字にしておいてください(笑)

大井田:

船山さんはいまいくつのプロジェクトを抱えておられるのですか?

船山:

本プロジェクト含めて複数を見ていますね。このプロジェクトが試金石になっていますから、他のプロジェクトでも同じように運用しているという点では今日お話したポイントはほぼ踏襲されています。ただ社内的には、スクラムマスターがそこまで多いわけではないですから、スクラムマスターを増やす動きがあります。新しく立ち上がるプロジェクトをサポートすることもあります。おかげさまで忙しいですね。

大井田:

そんなお忙しいところ、今日はありがとうございました。いまの船山さんが考えるもっと良い開発のありかたってどんなものですか?

船山:

社内で立ち上がるプロジェクトを見ていて考えるのは、もっと早くチームの組成ができないかということです。もちろん、開発スタイルとしてのスクラムももっと改善できると思っていますが、スクラムの価値がわかっているエンジニアを増やして同じ意識でチームを組めると自ずとパフォーマンスも上がると思うのです。
自分自身も話しながらプロジェクトの振り返りをさせていただいた感じがします。良い経験になりました。

大井田:

いえいえ、具体的なスクラムの現場のお話を伺うことができてとても勉強になりました。ありがとうございました。

取材を終えて

プロジェクト詳細は明らかにできませんが、今回はモンスター・ラボ様のご厚意であるCtoCサービス開発のプロジェクトについて実際のスクラム開発の現場感あるお話を伺うことができました。自社サービスでなく受託開発でのスクラムというのも珍しいかと思います。加えて、オフショア開発のメンバー半数と国内メンバーが混在してのスクラムチームという構成も非常に稀有なのではないかと思います。
これを見事成功裡に導いたのが、船山さんです。

スクラム開発の失敗事例は少し検索するといくつも発見できますが、ある固定のフレームに固執しないということが成功の秘訣なのではないかとお話を伺いながら確認できた気がしました。さすがスクラムマスターと感じられる決断・判断を彼の言葉の端々から、読者のみなさんも感じていただけるのではないでしょうか。

TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。

【PR】 タスクの管理方法にお困りですか?

TeamHackなら、プロジェクトの管理から情報共有まで、これ1つで全てが完結します。ソート機能で誰が何をやっているか明確に。タスクごとにチャットができるから、情報の錯綜もありません。プロジェクト管理者も作業者も、驚くほどタスク管理が楽になります。

事例に学ぶ

愚者は経験に学び、賢者は歴史に学ぶと言います。ビジネスについても同じことが言えるでしょう。
他の企業の戦略や取り組みを分析し、そこから抽出した要素を組織に取り入れてみることで、あなたのビジネスを成功に導く鍵が見つかるかもしれません。

詳細を確認する

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

同じタグのついた記事

同じカテゴリの記事