先進的な取り組みを続ける現場に訪問し、
【インタビューされた人】
和田修一（わだしゅういち）
Supership和田修一
改善によってうまく回り出したスクラム開発
- ──和田さんは株式会社nanapiの創業者・
CTOののち、 現在はSupership株式会社のエンジニアということで、 さまざまな立場から開発チームづくりや運営をされてこられたと思います。nanapiというサービスは最初は和田さんお1人で開発されていたそうですが、 チーム開発へと変わられたのはどんなタイミングだったのでしょうか？ 和田：エンジニア／
デザイナー含めて、 5～6名くらいまでは1人のときの延長線上でできるんですよね。そのくらいの人数であれば 「チームでいい感じにやろう」 と考えなくても雰囲気で何とかなっていたのですが、 それを超えてきたあたりから大きな開発が非常にやりづらくなったんです。皆できるものから進めてしまう癖があって、 1週間単位でかかる開発に手がつかなくなってきたんですよ。そうした状況からチームでうまく開発するにはどうすればよいかを考えるようになりましたね。そのときにスクラムを導入して管理し始めました。 - ──当時スクラムを導入してすぐにうまくいったんでしょうか？ それとも、
回り出すまでに時間がかかったのでしょうか？ 和田：時間はかかりました。中身としても、
当時はあまりできていなかったと思います。きちんとスクラムをやろうとすると、 スクラムの管理自体にコストや時間がかかりますよね。過去には時間をかけすぎていたなというときもあります。たとえば週に1回、 半日も使ってスプリント計画 [1] を立てたり、 バーンダウンチャート [2] をきれいにすることを目的とした管理になってしまったり。 - ──その後はバランスを取って、
うまくスクラムが回るようになってきたんですね。 和田：徐々に回るようになりました。そのうち僕自身の仕事として技術広報や採用、
プランニングといった仕事が増えていったので、 それからはほぼ現場に任せていましたね。あとは組織づくりや制度、 評価だったりとか、 役員業が多くなりました。 - ──その後nanapiの買収、
そして統合を経てSupershipでは現在新規サービスに携わっているということですが、 現在のチームはどういった体制なんでしょうか。 和田：今の体制は、
エンジニアが自分を含めて6人、 デザイナーが2人、 あと室長の1人を合わせて9名ですね。開発プロセスとしてはスクラムで、 スクラム用語でいうとデザイナー2人のうち1人がプロダクトオーナー [3] で、 室長はステークホルダー [4] に近いです。
うまく回すためには、振り返りとリズムが重要
- ──過去にスクラムをずっと利用し、
そのうえであらためて新しいチームを作り、 そこでもスクラムを回されているということで、 スクラムのノウハウについてぜひお聞きしたいです。 和田：そうですね、
今はスクラムをうまく回せているという実感はあります。スクラムで最も意識したのは振り返りですね。きちんと振り返りをして、 その結果を次のスクラムにしっかり活かしましょう、 というのを実施できています。以前は振り返りや次に活かすことがなく、 ダラダラやってしまったときもありました。 - ──スクラムはどのような周期で実施していますか？
和田：スクラムのスプリントは2週間にしていて、
最初に立てるスプリント計画、 毎日やるミーティングがあり、 そして2週間後に振り返りをやりましょう、 となっていますよね。うちではアプリの開発をやっているので、 リリースもこの2週間に合わせています。スクラムのサイクルと合わせて2週間単位でアプリを申請するというリズムです。毎週水曜日にアプリを申請するのですが、 申請の2日前の月曜日にはチームの皆で1時間アプリを触ってバグを出す会をやって、 その翌日に直して水曜日に提出するというペースです。 - ──面白いですね。大枠の2週間が決まっていて、
かつリリースのサイクルも合わせているからこそ、 ルールとしてうまく回りそうですね。 和田：はい、
こういったリズムはいろいろ試して振り返りをしながら、 一番気持ちの良い、 やりやすいペースを作ってきました。合わせて会議のペースも作っていまして、 わりとうまくできていると感じていますね。たとえばスプリントは水曜始まりにしていますが、 何曜始まりが一番気持ちが良いのかとか、 会議もこのあたりにまとめて入れたほうが良いとか。チームランチもこれに組み込んでいて、 2週間に1回、 定例でチームランチへ行っています。 - ──ランチまで組み込んでいるんですね。
和田：毎週って重いじゃないですか
（笑）。それでも 「2週間に1回くらいは行ったほうがいいかな」 みたいな。2日前になると 「店を予約しろ」 とbotが言ってくるので、 持ち回りで決まった担当が予約するようになっています。 - ──本当にいろいろリズムに沿って進められる状態になっているんですね。
和田：極力会議の実施内容について考えたくないじゃないですか。なので、
できるだけ何も考えずにできるようにしていますね。リズムというのはとても大事で、 ゴールデンウィークや年末年始のような長期休暇があると、 リズムが崩れてとてもやりづらくなるんですよ。そんなふうに、 リズムは大事なんだなと休暇のたびに思うので、 作ったリズムは極力崩さないようにしていますね。 - ──そうした改善や振り返りは和田さん主導で行われているんですか？
和田：はい。開発者とスクラムマスターを兼務しています。でも、
スクラムマスターの業務は全体の1割ぐらいですね。スクラムというのは、 最初と最後だけしっかりやっておいて、 問題がなければあとは定例のミーティングで終わるはずです。それが今はできていると思います。 - ──振り返り含めうまく回っているというお話でしたが、
実際に振り返りをやるうえで気を付けていることは何ですか？ 和田：振り返りで気を付けていることといえば、
極力ネガティブな感じにしないことですね。よくあるKPT （Keep, Problem,Try） で振り返っているんですが、 きちんと 「Keep＝よかったこと」 を多く出せるようにしたいねと話したり、 場の雰囲気をポジティブにするようなファシリテートをしたりしています。振り返りはこれまでたくさんやってきましたが、 機械的に管理しようとすると険悪になってしまうので。 - ──なるほど、
機械的だと険悪になるんですか。 和田：そうですね。
「じゃあ次。Problem、 問題を言ってください」 みたいな （笑）。うまく会議をファシリテートしてあげないとだんだん気まずくなるんですよ。Problemって、 誰のせいでもないものなら気にせず出してもいいんですよ。でも、 誰かのせいになってしまうものもあるじゃないですか。なので、 振り返りでは極力ポジティブになるような雰囲気作りをしています。たとえば 『すごい会議』 （注5） という本のやり方です。 - ──どんな手法ですか？
和田：会議のときに、
問題を話してから解決策を考えるという流れではなく、 「どうしたら◯◯ができるようになるだろうか」 という言い方に変えましょう、 というメソッドです。最初のころはそれに倣って極力ネガティブな表現をしないようにしていました。たとえば 「◯◯さんが時間どおりに来ない」 という言い方ではなく、 「どうしたら◯◯さんは時間までに来てくれるんだろうか」 って言うと、 少し柔らかいじゃないですか。 - ──いいですね。建設的に対処を考えられそうです。
和田：文句で終わらずに考えられますよね。率直に言いたいことを言うのはエンジニアのすばらしい文化だと思うんですが、
感じ悪く言うのは全然別ですからね。そこをうまくやれるように気を付けています。 - ──重要ですね。ファシリテーターの腕にかかっていますね。
情報共有も振り返りで改善する
- ──スクラムについていろいろ伺ってきましたが、
スクラム以外の取り組みで過去の経験が活きていると感じることはありますか？ 和田：スクラムに絡む話ではあるんですが、
情報をどうまとめておくのかは極力ルール化するようにしています。うちではQiita:TeamもGitHubもGoogle Driveも使っているんですが、 情報って油断すると分散しがちですよね。そういったものをきちんとルール化していって、 「こういう情報はここにこう置こうよ」 というのを定期的に見直したのは良かったですね。 - ──定期的に見直しているんですね。
和田：スクラムの振り返りでも情報共有の話がけっこう出るんですよ。
「このドキュメントがここにあるのはおかしいですよね」 みたいにメンバーが言ってくれます。仕様がGitHubのWikiとIssueに両方散っているのってありがちじゃないですか。 - ──ああ……、
どっちが新しいかわからない、 とか。 和田：
「これはどっちを正しいドキュメントにします？」 みたいな話が議論に挙がるんですよね。それを毎回毎回整理して、 このやり方は良くないからこうしましょうね、 というのをちゃんとやっている。イテレーションの終わりのタイミングで、 開発Issueのマイルストーンやラベルの運用を見直しているのも良いところですね。 - ──では情報共有のやり方なども含めて、
開発プロセス全体について振り返りのときにどんどん改善されていくということですね。とてもいいですね。 和田：普通のことではあるんですが、
普通のことをしっかりやって、 できているチームではないかと思います。いろいろなすごいこと、 大変なことをやろうとせずに。普通のやり方というのはもうだいたい決まっていますし、 それができるツールもたくさんあります。だから、 普通にやればうまくいくのかなと。
うまく進めるためにやめていく
- ──そうした当たり前のことを当たり前にやるのが難しいところはあると思うのですが、
逆に和田さんのところでできているのはなぜなんでしょうか。 和田：そうですね、
誰か1人、 できればスクラムマスターにですけれども、 意思決定をガツッとできる人がいるといいかもしれないですね。 - ──なるほど。
和田：話すと長くなっちゃうことってたくさんあるじゃないですか。たとえばスプリント計画をしていて、
「このあたりの見積りができない」 「仕様が決まっていない」 という話になるといったことです。そのときに 「ここはこうだから、 いったんこれでやっておいて。ここまででいいから」 みたいなことをその場で決められる人がいないと、 ダラダラ話してしまい結局スクラムがまともに始まらなかったりするんですよね。そういったところをある程度切ってあげて、 決めてあげる人がいるとうまく回るんだろうなと思います。長い会議って、 どうしようもないミクロなことに対していつまでもダラダラ話してしまって、 重要なことが話せていないってことがよくあるじゃないですか。 - ──ありますね。
和田：そこを切ってあげる人間がいると重要なことに集中できるので、
そうしたことは僕がよくやっています。どうしようもない議論のときは 「それを今話してもしょうがないから、 いったん次を話そう」 みたいな。プロダクトオーナーと僕もしっかり話しているので、 たとえば 「さすがにこれはもう無理だから次のスプリントに回そう」 といったことを僕のほうでガンガン決めているのは大きいかもしれません。 - ──そうしたファシリテーションやチームマネジメントでほかに意識されていることはありますか？
和田：コミュニケーションの量を増やすことですね。何かで読んだんですが、
良い関係のためにはコミュニケーションの内容よりも量が大事らしいんです。良いことでも悪いことでもいいので、 言い合っている数が多いのが大事ということです。方法はSlackやGitHub Issueなどオンラインでも良いですし、 1on1は2週間に1回はやったほうがいい、 そうやって接点の数は多く持ったほうがいいと思っています。ただ、 僕自身暑苦しいコミュニケーションはすごく苦手なので、 飲みに行くとかではなく、 Slackで人の発言に絡んでいくといったことをしています。ちゃんと絡んでいくっていうのが大事なので、 そうしたレベルでいいと思います。
良いことも悪いことも言い合える関係が良いチーム
- ──和田さんが考える良いチームの条件は何ですか？
和田：良いことも悪いこともちゃんと言い合える関係じゃないでしょうか。スキルよりもその関係がないと絶対にパフォーマンスが落ちると思うので、
ちゃんとお互いに言い合えるくらいのリスペクトがある関係っていうのが良いチームの一番の条件なんじゃないかなと思います。批判してもいいんですが、 ちゃんとリスペクトがある批判じゃないと意味がないと思うんですよね。批判が人格攻撃になってしまうのってリスペクトがない証拠で、 そういうことがあるとチームは良くなくなっていくと思うんです。ですので、 悪いことを言っても気まずくならないくらいのリスペクトがある、 というのが一番だと思います。 - ──批判ができて、
かつそれが攻撃にならないことは継続的に改善していくためにも重要ですね。今日はありがとうございました。
今回で本連載は終了です。全6回のインタビューにて、
本誌最新号をチェック！
WEB+DB PRESS Vol.130
2022年8月24日発売
B5判／
定価1,628円
ISBN978-4-297-13000-8
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！ - 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう - 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、 NFT