進化を先取る現場から

最終回 Supership 和田修一―2週間ごとの定期リリースを「当たり前」にするスクラムの勘所

この記事を読むのに必要な時間:およそ 4 分

先進的な取り組みを続ける現場に訪問し,チームや個人としてどう成長していくべきかを取材するインタビューの第6回です。今回は@wadapとしても知られるSupershipの和田さんに,チーム開発,スクラム開発のノウハウについてお話を伺いました。nanapi,そしてその買収・統合を経たSupershipという,規模もメンバーも異なるチーム,組織にて,CTOChief Technical Officer最高技術責任者)⁠エンジニア,スクラムマスターという立場でどのように開発プロセスを改善してこられたのか,その結果見つけた良い開発サイクルの回し方などを教えていただきました。

画像

【インタビューされた人】
和田修一(わだしゅういち)
Supership⁠株⁠

改善によってうまく回り出したスクラム開発

─⁠─和田さんは株式会社nanapiの創業者・CTOののち,現在はSupership株式会社のエンジニアということで,さまざまな立場から開発チームづくりや運営をされてこられたと思います。nanapiというサービスは最初は和田さんお1人で開発されていたそうですが,チーム開発へと変わられたのはどんなタイミングだったのでしょうか?

和田:エンジニア/デザイナー含めて,5~6名くらいまでは1人のときの延長線上でできるんですよね。そのくらいの人数であれば「チームでいい感じにやろう」と考えなくても雰囲気で何とかなっていたのですが,それを超えてきたあたりから大きな開発が非常にやりづらくなったんです。皆できるものから進めてしまう癖があって,1週間単位でかかる開発に手がつかなくなってきたんですよ。そうした状況からチームでうまく開発するにはどうすればよいかを考えるようになりましたね。そのときにスクラムを導入して管理し始めました。

─⁠─当時スクラムを導入してすぐにうまくいったんでしょうか? それとも,回り出すまでに時間がかかったのでしょうか?

和田:時間はかかりました。中身としても,当時はあまりできていなかったと思います。きちんとスクラムをやろうとすると,スクラムの管理自体にコストや時間がかかりますよね。過去には時間をかけすぎていたなというときもあります。たとえば週に1回,半日も使ってスプリント計画注1を立てたり,バーンダウンチャート注2をきれいにすることを目的とした管理になってしまったり。

─⁠─その後はバランスを取って,うまくスクラムが回るようになってきたんですね。

和田:徐々に回るようになりました。そのうち僕自身の仕事として技術広報や採用,プランニングといった仕事が増えていったので,それからはほぼ現場に任せていましたね。あとは組織づくりや制度,評価だったりとか,役員業が多くなりました。

─⁠─その後nanapiの買収,そして統合を経てSupershipでは現在新規サービスに携わっているということですが,現在のチームはどういった体制なんでしょうか。

和田:今の体制は,エンジニアが自分を含めて6人,デザイナーが2人,あと室長の1人を合わせて9名ですね。開発プロセスとしてはスクラムで,スクラム用語でいうとデザイナー2人のうち1人がプロダクトオーナー注3で,室長はステークホルダー注4に近いです。

注1)
チームとして定めた時間枠(=スプリント。2週間など)内に何をやるのかを決め,タスク化することです。
注2)
チームとしてどれだけタスクを完了できたかを可視化するためのグラフです。
注3)
チームとして取り組む開発の優先順位を決める責任を負う人です。
注4)
管理職や顧客など,スクラムチームメンバー以外の利害関係者です。

うまく回すためには,振り返りとリズムが重要

画像

─⁠─過去にスクラムをずっと利用し,そのうえであらためて新しいチームを作り,そこでもスクラムを回されているということで,スクラムのノウハウについてぜひお聞きしたいです。

和田:そうですね,今はスクラムをうまく回せているという実感はあります。スクラムで最も意識したのは振り返りですね。きちんと振り返りをして,その結果を次のスクラムにしっかり活かしましょう,というのを実施できています。以前は振り返りや次に活かすことがなく,ダラダラやってしまったときもありました。

─⁠─スクラムはどのような周期で実施していますか?

和田:スクラムのスプリントは2週間にしていて,最初に立てるスプリント計画,毎日やるミーティングがあり,そして2週間後に振り返りをやりましょう,となっていますよね。うちではアプリの開発をやっているので,リリースもこの2週間に合わせています。スクラムのサイクルと合わせて2週間単位でアプリを申請するというリズムです。毎週水曜日にアプリを申請するのですが,申請の2日前の月曜日にはチームの皆で1時間アプリを触ってバグを出す会をやって,その翌日に直して水曜日に提出するというペースです。

─⁠─面白いですね。大枠の2週間が決まっていて,かつリリースのサイクルも合わせているからこそ,ルールとしてうまく回りそうですね。

和田:はい,こういったリズムはいろいろ試して振り返りをしながら,一番気持ちの良い,やりやすいペースを作ってきました。合わせて会議のペースも作っていまして,わりとうまくできていると感じていますね。たとえばスプリントは水曜始まりにしていますが,何曜始まりが一番気持ちが良いのかとか,会議もこのあたりにまとめて入れたほうが良いとか。チームランチもこれに組み込んでいて,2週間に1回,定例でチームランチへ行っています。

─⁠─ランチまで組み込んでいるんですね。

和田:毎週って重いじゃないですか(笑)⁠それでも「2週間に1回くらいは行ったほうがいいかな」みたいな。2日前になると「店を予約しろ」とbotが言ってくるので,持ち回りで決まった担当が予約するようになっています。

─⁠─本当にいろいろリズムに沿って進められる状態になっているんですね。

和田:極力会議の実施内容について考えたくないじゃないですか。なので,できるだけ何も考えずにできるようにしていますね。リズムというのはとても大事で,ゴールデンウィークや年末年始のような長期休暇があると,リズムが崩れてとてもやりづらくなるんですよ。そんなふうに,リズムは大事なんだなと休暇のたびに思うので,作ったリズムは極力崩さないようにしていますね。

─⁠─そうした改善や振り返りは和田さん主導で行われているんですか?

和田:はい。開発者とスクラムマスターを兼務しています。でも,スクラムマスターの業務は全体の1割ぐらいですね。スクラムというのは,最初と最後だけしっかりやっておいて,問題がなければあとは定例のミーティングで終わるはずです。それが今はできていると思います。

─⁠─振り返り含めうまく回っているというお話でしたが,実際に振り返りをやるうえで気を付けていることは何ですか?

和田:振り返りで気を付けていることといえば,極力ネガティブな感じにしないことですね。よくあるKPTKeep, Problem,Tryで振り返っているんですが,きちんと「Keep=よかったこと」を多く出せるようにしたいねと話したり,場の雰囲気をポジティブにするようなファシリテートをしたりしています。振り返りはこれまでたくさんやってきましたが,機械的に管理しようとすると険悪になってしまうので。

─⁠─なるほど,機械的だと険悪になるんですか。

和田:そうですね。⁠じゃあ次。Problem,問題を言ってください」みたいな(笑)⁠うまく会議をファシリテートしてあげないとだんだん気まずくなるんですよ。Problemって,誰のせいでもないものなら気にせず出してもいいんですよ。でも,誰かのせいになってしまうものもあるじゃないですか。なので,振り返りでは極力ポジティブになるような雰囲気作りをしています。たとえば『すごい会議』注5という本のやり方です。

─⁠─どんな手法ですか?

和田:会議のときに,問題を話してから解決策を考えるという流れではなく,⁠どうしたら◯◯ができるようになるだろうか」という言い方に変えましょう,というメソッドです。最初のころはそれに倣って極力ネガティブな表現をしないようにしていました。たとえば「◯◯さんが時間どおりに来ない」という言い方ではなく,⁠どうしたら◯◯さんは時間までに来てくれるんだろうか」って言うと,少し柔らかいじゃないですか。

─⁠─いいですね。建設的に対処を考えられそうです。

和田:文句で終わらずに考えられますよね。率直に言いたいことを言うのはエンジニアのすばらしい文化だと思うんですが,感じ悪く言うのは全然別ですからね。そこをうまくやれるように気を付けています。

─⁠─重要ですね。ファシリテーターの腕にかかっていますね。
注5)
大橋禅太郎 著『すごい会議』大和書房,2005年

著者プロフィール

海野弘成(うみのひろしげ)

京都大学工学部にて情報工学を専攻。在学中にはてなやGoogleにてソフトウェアエンジニアとしてインターン,アルバイトを経験。iOSアプリ開発などを担当する。2011年,友人2人と作ったプログラマーのための技術情報共有サービス『Qiita』を公開。大学卒業後の12年2月,Increments株式会社を設立し,代表取締役に就任。主なサービスに,『Qiita』のほか,チーム内情報共有ツール『Qiita:Team』がある。

Qiita:http://qiita.com/yaotti

コメント

コメントの記入