入念な下準備を行う傍らで、3ヶ月後のMVPリリースに向けた開発も始まっていく。
序盤の苦労から、スプリントの本質的な価値を認識していくまでの過程を通じて、強いアジャイルチームとは何かに迫る。

2.スクラム開発編

いきなり1週間1スプリント！ハードなサイクルが、徐々に快感へと変わっていく

板原 MVPのリリース自体が3ヶ月後ということで、スプリント期間を1週間にしましょうという話をさせていただきましたよね。1週間というのはタイトでしたか？

清水 「慌しいな」と最初は思いました。週5日働く中で1日はほぼスクラムイベントで潰れることになりますから、開発効率がかなり落ちるのではないかという心配も正直ありました。
実際、最初の1～2週間は大変で、4日で作って1週間で見てもらって、振り返って、とかなり慌しいスケジュール。
ですが今では、1週間で正解だったと思っています。スプリント期間を1週間にすることのメリットは、1週間という短い時間でも十分に達成できる分のTRYをきちっと活かしながらスプリントをこなせることです。
無理のない分量だからこそ、TRYをどんどんこなせる＝結果どんどんと改善されていって、週を越すごとにいいチームになっていっているなという雰囲気を感じました。まさにアジャイルの良さですね。
ゴールデンウィークのような長い休みに入る期間は2週間で設定することもありましたが、2週間1スプリントというのは今ではむしろ不安です。膨大なTRYをこなさなければならなくなるし、期間が長い分、方向修正によるリスクも大きくなってしまう。今では1週間ではないと怖い身体になってしまいました（笑）

板原 私も当初は1週間と2週間で悩んだのですが、3ヶ月でリリースをするのに、1スプリント2週間だと振り返りのチャンスが5～6回しか設けられないんです。タスクの見積もりという点でも、2週間後のことまで予測するよりも1週間後の方が精度も上がるんですよね。

川上 私も最初はスクラムイベント（レビュー）にしか入っていなかったのもあって、実質稼動4日でどれだけのパフォーマンスが出るのか気になっていました。
ですが、振り返りを経るごとにどんどんこなせるタスク量も増えていって、むしろ思ったよりも速いスピードでモノができていく姿を見て、心から安心感を覚えました。
作ったものを週1回見せてもらうのですが、これまではコードレビュー程度で、「実際に動作して動く」というレビューの仕方やフェーズは設けていなかったので、実際の動作まで確認できる機会や時間が出来たのは、本当にありがたかったです。

板原 「ん？ちょっと動き違うな」というフィードバックをレビュー時にもらえたので、軌道修正がすぐできましたね。

川上 ウォーターフォールだと本当に数ヵ月後にふたを開けてみたら......というのがよくあったので（笑）例え想像と違った部分があっても、その方向性のズレが最悪1週間で済む、というのは助かりました。

安食 私も、当初1週間のスプリントはしんどかった記憶があります。スクラムイベントで1日取られてしまうことは「えー！」でしたし（笑）でも現在では、スクラムイベントこそチームとしての結束力を強める重要なツールだと思うようになりました。
チームでお互いのことを理解した上で、自分だけでなく彼らのタスクの内容も考えてみるなど、これまでになかった視野が生まれました。
TRYを編み出しチャレンジする時間も設けられたことで結果的にベロシティは上がるし、品質もどんどん上がっていく。私は現在基幹システムに携わっていますが、そちらでもスクラムイベントのエッセンスは少しずつ取り入れています。
メンバーからの意見も出やすくなり、チームの雰囲気が良くなっている実感がありますね。

板原 広めていただけて、とても嬉しいです！

渡邉 序盤の方は未完成でスプリントが終わってしまうことも少なくなかったですよね。ただそこから、どうやったら改善できるかというのをチームで考えることができたのがよかったわけですが、導入時の準備段階で結束力を高められていた、お互い言いたいことを言い合える関係が構築できていた、というのが大きかったと思っています。
どういうところで効率が落ちているのかとか、完成の定義が厳しすぎないかとか、幅広く議論しながら作っていけましたし、立ち上げから1ヶ月、2ヶ月経過していくごとに、関係がより安定をしてきていたなというのは私自身も実感としてありました。

全員がリアルタイムで繋ぐ「コアタイム」は、フルリモート開発のスタンダードに

清水 当社の開発者はリモート勤務が多いです。ほぼフルリモートの人もいます。
今回の「お客様Myページ」も、メンバーズエッジさん含めてほぼフルリモートで、実質全員違う場所で従事していましたが、そのような環境下でご提案いただいた「コアタイム（リアルタイムで繋いでいる時間）」は、今後のフルリモート環境では必須かなと感じています。
普段から顔を突き合わせていられるならいいですが、フルリモートの環境ではそれができない。今回のコアタイムは1日2時間（午前午後1時間ずつ）という形でしたが、その時間の中でお互いの顔を見て仕事をしたり、雑談コミュニケーションを取ったりするのはいい効果だったと思っています。
コミュニケーションの手段としては、1対1のチャットだったり、共有したいことが発生するたびにGoogle Meetに入ってもらう、などもあるのですが、どうしてもテンポが遅くなりますよね。
その点コアタイムはタイムロスも全くないですし、雰囲気も含めたすべてを共有する意識が芽生えてくる印象がありました。
実際にビデオを繋いで作業する経験がなかったので、最初は緊張したんですが（笑）慣れてきますし、メンバーの人となりも見えてきて、チームの結束が高まっていく感じでした。今では当社の他のチームでも採用されているようです。

安食 そうですね。私のチームでもコアタイムを設ける予定です！

板原 最初は反対する人もいるかもしれないですね（笑）打ち合わせ以外でビデオを繋いで一緒に作業をする、というのは緊張しますよね。
お互いの監視が目的ではないので、途中からはまったく気にならなくなるのですが。私は本来スクラムマスターとして、チームに課題があれば、本人たちに気づかせる形で改善を促す立場なのですが、コアタイムの効果もあって、比較的早い段階から「会社間の壁」を感じなくなっていました。

清水 渡邉さん板原さんが最初盛り上げてくれたから、というのもあると思いますね。

板原 安食さんも、ディズニーランドの話とかをたくさんしていただきましたね（笑）

安食 覚えてないですが（笑）リモートしている人と雑談ができるのは大きいですね。雑談がないと、コミュニケーションとしては連絡事項しかなくなってしまいますし。

板原 LINE WORKSで雑談する手もありますが、残すまでもない取るに足らない会話もたくさんありますしね（笑）文字を打つのも手間ですし、文章だけでは伝わらないような、面と向かって表情見ながら話をすることで生まれる効果は絶大ですね。

強いアジャイルチームを形作るのは、「フラットな関係性」作りと「属人化の撲滅」

渡邉 雑談もよかったですが、雑談以外でもランドネットさんから常にフラットにお話してもらえたのがとてもよかったです。こちらからのさまざまな提案に当たり前のように耳を傾けてくださったのはとても嬉しかったですね。

板原 対等にお話してくれたというのはとても嬉しかったですね。別の企業にいる者同士で仕事をする中では、開発が踏み込めない領域も多く、議論にも参加させてもらえないケースが多いですが、それが非常に少なかったのが、とてもやりやすかったです。

渡邉 仕様にも口を出させていただけましたね（笑）こういう仕様で決まってきました、と清水さんからお話いただいて、それに対してこういう風なのも考えられませんか？と議論をさせてくれる。
まさにものづくりを一緒にしている感覚でした。技術的なアドバイスを求められることはこれまでもあったのですが、仕様を議論させてもらえるというのは、振り返ってみても実はこれまでなかなかなかったことでした。

清水 先日もランディングページに対して非常に良い案をいただいて、すぐ採用させてもらいましたね。
今日も小林さん（メンバーズエッジのエンジニア）から、この時の挙動は良くないのでは？と指摘をもらうなど（まさにおっしゃる通りだったのですが）、メンバーズエッジさんからも言いたいことを全部言っていただけて、チーム開発ならではの良さをとても感じます。
依頼した内容をやってもらうだけの関係では絶対に出てこないと思います。よりフラットな関係の中で、向き合っているプロダクトを徹底的に良くしようという全員での共通意識や、属人化しないよう仕様を常に交換しあうという文化作りが強いチーム力を生むと感じます。
最初の立ち上げから1ヶ月、2ヶ月の経過だけでもよくなった印象はありましたが、そこからさらにどんどん進化していってるので、またこれから先が楽しみだなと思っています。

渡邉 属人化はかなり減った実感があります。余裕がありそうな時は、苦手意識がありそうな人にそのタスクを振ったり、阿弥陀くじでタスクを決めたり、誰でもどこでもやれることは多くなってきましたね。

清水 本当に、誰にどこを任してもきちんと結果が返ってくるのでびっくりしています。

板原 機能単位で人をアサインして、というやり方をしてしまうと、1週間でなかなか出来上がらないというケースが実は多いです。
全員で役割分担をしながら、次のレビューで見せるもの、価値のあるものを作り上げる、というやり方が適していて、そのためにペアプロなども実施させていただきました。

清水 コアタイムの中で、実際にペアプロをやっているところを見させていただきました。当社の若手をチームに入れてもらって、メンバーズエッジさんの新卒エンジニアの方々と共にペアプロ形式で教えてもらっているのですが、成長スピードが全然違うなと感じます。
エンジニアの立ち上げでの序盤の遅さをカバーできる良い方法だと思いました。

板原 ペアプロだと、計算上は工数が2倍になってしまうのですが、ペアを組んで、レビューも兼ねて取り組んでいくのといかないのとでは、従事するエンジニアのスキルの伸び率が違ってきます。
長い目で見るとペアプロをしていた方が実は効率が良くなるケースが多いですね。この人はフロントエンド、この人はバックエンド、この人はこの機能、というように役割を固定するやり方も当然あるのですが、ある人の手が空いた時に、その人のやることがない、という話になってきます。
理想的には、どの部分を切り出しても誰でも出来る状態にしておくと無駄な時間が発生しません。またこのやり方の良いところは、専門領域にプラスでカバー領域も広がっていくことで、技術者としての視点や幅が広がるなど、キャリアアップのチャンスにもなります。
そして重要なのはこうしたことをチームの中に文化として根付かせていくことですね。

清水 専門性に縛られないからこそ、色々な技術に触れることもでき、エンジニア自身もそれを「楽しんでいる」ような感じもするので、そういう意味でも大事かなと思いますね。色んなところにチャレンジできるチームでありたい、ともやはり思いますし。

次回は取り組んで3ヶ月が経過し、いよいよMVPリリースを迎えることになります。リリース時のエピソードから今の皆さんの状況、そしてランドネットさまが考えるアジャイルの今後の展望までをお伺いしております！
MVPでリーンに実現していくプロダクト開発は実に参考になりますのでお楽しみにお待ち下さい！