ランドネット様

山木：アジャイル開発を導入することになった経緯をお聞かせいただけますでしょうか。

川上：もともと2～3年前、社内の基幹システムの開発をアジャイルでやりたいという声が社内で挙がり、検討したことがありました。ですが基幹システムだと、業務フローも大枠決まっているし、経営層を含めて実際に活用する事業部側でもある程度要件が固まっていたこともあって、従来のウォーターフォール型でやろうということで、いったんアジャイル導入を断念したんです。

そのような中で昨年、コロナの影響でお客様とのオンラインでの取引需要が高まってきていて、まずは媒介契約の取引を電子上で完結できることを目的として、「マイページ」を立ち上げることが決まりました。

ですが、Webサービスを社外向けに展開した経験が社内にほとんどなく、当然ながらエンドユーザーの要望もまだ情報としてはなかったので、この「マイページ」の新規開発をきっかけに、改めてアジャイル開発に取り組んでみたいという動きになりました。

板原：清水さんや安食さんは、アジャイルやってみたいよね、という話がきた時にどう感じられましたか？

清水：いよいよ来たかというのが率直な感想でした。今どきプロダクト開発はアジャイル、という風潮の中で、私自身ウォーターフォール型開発しか経験がなく、いつかやってみたかったので、本当にありがたい話だなと。また当社のエンジニア採用においても、社内でのアジャイル開発の実績が作れれば、いい影響をもたらしてくれるとも考えました。

板原：採用で開発手法は何かを聞かれるんですね（笑）

清水：かなり聞かれます（笑）。ウォーターフォールが良くないということはないのでしょうが、社でアジャイルでの実績がないとガッカリされることも多く、後ろめたさを感じていました。

川上：2～3年前は本当によく聞かれていましたね。「開発手法はアジャイルですか？」って（笑）

板原：安食さんはいかがですか？

安食：2～3年前もアジャイルという言葉はよく耳にしていましたが、全く未知の領域でした。また今回改めてアジャイルにチャレンジしようと聞いたときも、当社のメンバーだけで進められるのか、という不安がありましたね。

板原：実際にアジャイルに取り組むということになって、社内の他のチームの皆さまはどのような反応でしたか？

清水：うらやましそうでしたね（笑）。

板原：経営層の方々はいかがでしたか？　できるのかって雰囲気はやはりありましたか？

川上：実はアジャイルの存在自体は当社の代表もよく知っていました。メンバーズエッジさんから提案いただいた内容をもとに、是非チャレンジしたいという思いと、今回はアジャイルの実務経験やスクラムの資格を保有している方々と一緒にやれるということで強く訴えたら、申し入れを通してくれました。

板原：最終的にメンバーズエッジと一緒にやりたいと思ってくださったポイントはどこだったのでしょうか？

川上：メンバーズグループとはもともとお取引がありましたが、以前より「チームでの支援」を強く要望していました。他社様からチームでご提案いただくこともあったのですが、あくまで当社主導のもと、サポートとして入る内容が多かった中で、メンバーズエッジさんから「アジャイルでやってみませんか」と提案をいただきました。アジャイルもセットで提案してくれたのがメンバーズエッジさんだけだったんですね。ちょうど「マイページ」の立ち上げ時期でタイミングもぴったりでしたし、実務経験が豊富だったところが、やはり決め手になりましたね。

板原：私と渡邉が初めてジョインさせてもらった後、私がまず着手したのが「スクラム／アジャイルの知識レベルを全員で合わせる」ことでした。相応の時間と回数をかけて勉強会を実施しスクラムやアジャイルに関するインプットを深めたり、簡単なワークショップを通じて「アジャイルとはこういうものである」を体験してもらったりと、いきなり開発の手を動かすのではなく、全員の理解レベルの統一をまずは行いました。

従来型（ウォーターフォール）の開発だと、どこかからデザインが降ってきてひたすら開発していくケースが多く、全員が同じ方向を見ているかとか、同じ目的意識かといったことの確認はほぼ重視されませんし、開発の途中でそのような確認のタイミングもないことがほとんどです。一方でアジャイル開発では、インセプションデッキ等を用いて、プロダクトの目的とゴールを全員で理解一致させることから始まります。その中で自分たちの力でユーザーストーリーを作り、本当に必要なものMVP（Minimum Viable Product＝価値のある最小のプロダクト）を定めていきます。

上記に加えて、今回はドラッガー風エクササイズの実施やワーキングアグリーメントの作成なども行いましたし、始業時間や休業日も異なる私たちが「毎日絶対に集れる時間を作ること」にも注力しました。
またこれまでランドネットさんではテスト自動化の実績がほぼなく、リリースに苦労されていたと伺ったので、CI/CD（継続的インテグレーション/継続的デリバリー＝開発のステージに自動化を取り入れ、リリースの頻度を高める手法）を作ることも序盤に行ったことですね。

清水：半年くらい前で、すっかり懐かしいですね（笑）
導入時、インセプションデッキやエレベーターピッチなどの資料作りには、上席や経営層も巻き込みながらかなりの時間をかけました。当然、開発を始めてしまったほうが、みたいな思いも最初はあったのですが、インプットに時間をかけたり、ワーキングアグリーメントを決めたりするというのは、やるとやらないとでは全く違う、非常に意味のあるものだと思うようになりました。

「なんとなく分かっている」状態と、チーム内で認識や方向性が一致しているのでは、私を含むチーム一人ひとりのゴールへの意識が全然違います。良いプロダクトを作るぞ、という目標に全員が向かえたという実感がありましたね。また、板原さんや渡邉さんの豊富な開発経験や、技術の引き出しが多かったのも非常に助かりました。

アーキテクチャを作る段階から、こんなサービスありますよ、こんな手法ありますよ、むかしこういう風にやってましたなど、さまざまなアイデアをいただいて、本当にいいと思えるアーキテクチャができましたし、結果良いプロダクトにも繋がったと思います。

板原：私たちもいろんな提案を採用していただいて、チャレンジングな経験をさせてもらいました。非常に楽しかったですね。

清水：そうですね。あと安心感もありましたね。ダメでも板原さんたちがサポートしてくれそうとか（笑）そういう安心感のもとチャレンジできたのが非常に楽しかったですね。またアジャイルという枠組みなので、開発に入ってからも、1週間スプリントの中で方向修正は比較的簡単にできましたしね。

板原：AWSのサービスなども、いろいろ調査をして途中でアンプリファイからクラウドフロントに変えたりだとか、ネットワークだとか、そういうことも、ウォーターフォールでやっていたら方向転換が難しいところですしね。

清水：そうですね、「こうしておけば良かった」が最後に発覚！も多いにありえたかと思いますけど、機敏に方向修正ができましたね。

板原：川上さん、管理者視点ではいかがでしたか？なかなかモノができてこないという不安もあったのかと思うのですが。

川上：心配はあまりなかったですね。これまではプロダクトの方向性を私も含めて上の方で決めてしまって設計者・開発者に投げるという流れでした。でも今回はチームでインセプションデッキを作って目的合わせをしたり、チームや個人の価値観のすり合わせをしたりと1ヶ月をほぼ準備に使う中で、チームや組織の今後のあるべきイメージを垣間見ることも出来てよかったと思っています。

今までのやり方だと、どうしても個の能力に頼って、仕事ができる人にやってもらうことになってしまい、スキルの差がつきがちでした。技術知識・業務知識の差もバラつきがありました。ですが今回は、最初の知識合わせからすべて、チームとしてやる、というやり方を実際に見せてもらいました。非常に勉強になったなと思っています。

板原：メンバーズ側として入った渡邉さんは、どうでしたか？

渡邉：板原とともに参画した当時、チームビルディングは板原がほぼ整えてくれてましたが（笑）その傍らで私は今回のプロダクトで必要となる技術領域を中心に、アジャイルの考え方のひとつでもある「動くソフトウエアだけが進捗をはかる指標」というところを特に強く意識して立ち上げに取り組んでいました。

その中で今回はFlutterWebを採用してみるという話がどこかからか挙がってきて、簡単にサンプルを作ってランドネットさんに見ていただいたことがあったのですが、操作だけではなくて、「ソースはどんな感じ？」と中も見てくださったんですよね。常に中身もきちっと見て評価していただいた上で、GOなのかNGなのかをはっきり判断してくださるのは、私としても大きな安心感を得ることができました。

CI/CDもそうだったのですが、これまでに触れたことのない仕組みが登場すると、価値が分かりにくくて、「時間だけかかってそんなに効果ないんじゃないか」などの疑念を抱いてしまいがちだと思うのですよね。そこも簡単なサンプルを作って「あ、これ便利だね」ていうのを評価してもらえて、採用していただけたのがすごい良かったかな、と思っています。

板原：CI/CDはリリースしてはじめて効果が出てくると思っているのですが、いまでも大活躍ですか？

渡邉：清水さんがパワーアップさせてますよね！E2Eも導入したり。

清水：E2Eも毎日動かすようにしてます。CI/CDが入っているおかげでリファクタリングも継続的に行えています。リファクタリングを続けていかなければシステムがどんどん陳腐なものになってしまう中で、ユニットテストがないと、簡単な修正も億劫になって結果システム劣化の悪循環に陥っていくのですが、CI/CDが入っているおかげでリファクタリングにも前向きにチャレンジできています。いまではCI/CDがすでにチームの中の一要素、文化として根付いてきているのではないかと思います。

板原：リファクタリングは重要ですね。テスト自動化がされていないウォーターフォール開発だと、コストやスケジュール重視で劣悪なスパゲティコードが出来上がっていく。結果的に「動くコード」が「正」だから、触らないほうがいい、みたいな感じになって、リファクタリングからどんどん離れていくのですよね。そういった事象を防ぐにも、CI/CDはアジャイル開発には特に欠かせない要素だと思います。

清水：実際に現在の基幹システムがその状況だったという反省もあり、今回のマイページではむしろお願いする形でCI/CDを入れてもらいましたけど、入れてよかったです。

板原：安食さんは、この準備期間は別の案件にいらっしゃいました。外から見ていた印象と、そのあと実際に入られてからの印象はいかがですか？

安食：インセプションデッキを初めて見た印象は、スバリ全体像がぱっと分かる、です。これまでは自分が割り振られたものをやっていて、自分の担当部分しか意識していませんでしたが、全体を意識した実装の仕方なども、俯瞰的に捉えられるようになりました。あとはドラッカー風エクササイズを通して、チームの中で自分にはどういうことが求められているのか、どう動くべきなのかを直感的に考えられるようになれたと思います。

板原：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のチャットだったり、共有したいことが発生するたびにWeb会議に入ってもらう、などもあるのですが、どうしてもテンポが遅くなりますよね。
その点コアタイムはタイムロスも全くないですし、雰囲気も含めたすべてを共有する意識が芽生えてくる印象がありました。

実際にビデオを繋いで作業する経験がなかったので、最初は緊張したんですが（笑）慣れてきますし、メンバーの人となりも見えてきて、チームの結束が高まっていく感じでした。今では当社の他のチームでも採用されているようです。

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

板原：最初は反対する人もいるかもしれないですね（笑）打ち合わせ以外でビデオを繋いで一緒に作業をする、というのは緊張しますよね。

お互いの監視が目的ではないので、途中からはまったく気にならなくなるのですが。私は本来スクラムマスターとして、チームに課題があれば、本人たちに気づかせる形で改善を促す立場なのですが、コアタイムの効果もあって、比較的早い段階から「会社間の壁」を感じなくなっていました。

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

板原：安食さんも、テーマパークの話とかをたくさんしていただきましたね（笑）

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

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

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

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

渡邉：仕様にも口を出させていただけましたね（笑）こういう仕様で決まってきました、と清水さんからお話いただいて、それに対してこういう風なのも考えられませんか？と議論をさせてくれる。

まさにものづくりを一緒にしている感覚でした。技術的なアドバイスを求められることはこれまでもあったのですが、仕様を議論させてもらえるというのは、振り返ってみても実はこれまでなかなかなかったことでした。

清水：先日もランディングページに対して非常に良い案をいただいて、すぐ採用させてもらいましたね。
今日も小林さん（メンバーズのエンジニア）から、この時の挙動は良くないのでは？と指摘をもらうなど（まさにおっしゃる通りだったのですが）、メンバーズさんからも言いたいことを全部言っていただけて、チーム開発ならではの良さをとても感じます。

依頼した内容をやってもらうだけの関係では絶対に出てこないと思います。よりフラットな関係の中で、向き合っているプロダクトを徹底的に良くしようという全員での共通意識や、属人化しないよう仕様を常に交換しあうという文化作りが強いチーム力を生むと感じます。

最初の立ち上げから1ヶ月、2ヶ月の経過だけでもよくなった印象はありましたが、そこからさらにどんどん進化していってるので、またこれから先が楽しみだなと思っています。

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

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

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

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

板原：ペアプロだと、計算上は工数が2倍になってしまうのですが、ペアを組んで、レビューも兼ねて取り組んでいくのといかないのとでは、従事するエンジニアのスキルの伸び率が違ってきます。

長い目で見るとペアプロをしていた方が実は効率が良くなるケースが多いですね。この人はフロントエンド、この人はバックエンド、この人はこの機能、というように役割を固定するやり方も当然あるのですが、ある人の手が空いた時に、その人のやることがない、という話になってきます。

理想的には、どの部分を切り出しても誰でも出来る状態にしておくと無駄な時間が発生しません。またこのやり方の良いところは、専門領域にプラスでカバー領域も広がっていくことで、技術者としての視点や幅が広がるなど、キャリアアップのチャンスにもなります。
そして重要なのはこうしたことをチームの中に文化として根付かせていくことですね。

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

板原：7月にまずはMVPリリースを迎えましたが、アジャイル開発でのリリースを初めて体験してみて、実際にいかがでしたか？

渡邉：スクラムイベントで毎週優先順位を決めていたので、とにかく判断しやすかったです。要件も追加されて予定よりは少し延びたのですが、ウォーターフォールでやっていたらもっと時間がかかっていたと思います。ウォーターフォールでは、何をどこまでリリースしないといけないかが先に決められてしまっているので、開発においても優先順位をそこまで厳密に意識はしていませんでした。

アジャイル開発では、MVPへのコミットにフォーカスして毎週やるべきことを決めているので、まずマストな機能に全然手をつけられてないという事態に陥ることがなく、「じゃあこの機能は削ってリリースしよう」という判断を適正に下すことができました。

川上：リリースした時点では、ほかに盛り込みたかった機能もまだたくさんありました。でも、「ここの使い勝手が悪い」とか「ここの使い方が分からない」というユーザーからの実際の声というのは、リリースして初めて届くわけですよね。

まずは最低限のバリューで使っていただいて、その声をもとにまた優先度を組み替えて次に必要な機能にフォーカスしていく。MVPリリースの価値や良さを実感していますね。

板原：ユーザーからは早速フィードバックが来ていますか？

清水：事業部サイドを経由してのフィードバックにはなりますが、ログインしてみたけどここの使い方で分からない部分があった、みたいな声は何件か来ています。ではその部分はチュートリアル機能で対応していこう、といった具合で次に優先するところにフォーカスして方向性を決め、素早く継続して作り続けられる体制が出来ています。

無駄がないですね。声がない状態で最初に全部作りこんでしまうと「頑張ったけどそれ要らなかったじゃん」となりますが、それが全くないので、良い意味でのスモールスタートが出来たと思ってます。

板原：チュートリアルのようなものは欲しいよね、という話はチームの中でも挙がっていましたよね。でもまずはフィードバック受けてからの採用にしよう、ということで、初回のリリースにおいては優先度を下げたかと思います。リリースを経て、どの部分でのチュートリアルが必要かまで改めて検証することが出来た、ということですね。

清水：そうですね。SNS連携についても同様でした。リリースしてみて、実際にはGoogleを使っている方が多いという傾向が見えてきて、Yahoo!連携に加えてGoogleも追加していこうか、という風に利用状況を見てから次に必要な機能を入れていく判断ができています。
判断に無駄がないだけに、開発効率にも良い影響が出ているとも感じています。

川上：ログインのところは顕著でしたね。SNS連携も、今までならとりあえず、GoogleとかFacebookとか、とにかく全部盛りでないとリリースできません、という感じでしたが、マストじゃないものは後に回して進めていくことが出来たので、そこは良かったです。

板原：ウォーターフォールだと、リリースしてみたらチュートリルに無駄が多かったとか、この外部連携は効果が薄かった、という可能性もあります。それを確かめながらできるのは非常にいいかなと思います。
またアジャイルでは早くリリースすることが出来ますよね。短期間でお客様のフィードバックを取り入れて、早ければ毎週リリースできて、グロースハック的な感じでどんどん成長できるところがいいですよね。

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

安食：小さくリリースしている分、バグが出たときの対応が少なくて済むのも、アジャイルの大きな利点だと感じました。リリース当日も一部不具合はあったのですが、リリースが小さい分、他への影響も少ないためすぐに対応ができました。

そもそもバグに対応しなければならない量も「一気にドカン」より圧倒的に少ないので、小さくリリースすることは価値のあることだと感じました。

板原：従来型のやり方だと、リリース時にリグレッションテストに時間がかかったりしていましたよね。先ほども話に出たCI/CD環境がしっかりしていたとか、E2Eを拡充してきたとかで、リリースそのものも楽に感じられたのではないでしょうか？

清水：楽というのもありますが、安心感が違いますよね。どんなにテストしたと言っても漏れは発生するものですが、テスト自動化によりある程度保証されているというのはまず安心ですし、実際にバグも少なかったです。

E2Eテストも現在段階的に拡充しているところなので、今後さらに安心感は増していくと思います。そういった容易さや安心感と比例して、価値を届けるまでのスパンも短くなっていくし、必要な機能を必要なタイミングで追加していくスタイルが今後さらに整ってくるので、すでに先が楽しみですね。これからも大型の開発・リリースが控えていますが、上手くいく予感が持てています。

板原：ある程度自動化されていないと、大きいボリュームをリリースするときは不安が尽きないですよね。全部見直して、テストも他との影響を考えながら苦労も強いられる。CIはその辺りがすべて明快になりますよね。影響があれば、そもそもテストが通らないとか（笑）

清水：通らない仕組みになってますよね（笑）だからこそ、テストにおいては認証周りなどの特に重要で沢山手を動かさなければならない部分に重点をおける。そういう判断が出来るところも大きいですよね。

板原：リリース後、スクラムマスターとしての役割を渡邉にバトンタッチしました。今現在は主にどんなことに取り組んでいますか？

渡邉：チームの状態はすでに良かったので、そこからスクラムマスターとして何をすべきかを模索していくのが逆に大変でしたが（笑）、まずはバックログが徐々にタスクリスト化していきそうな傾向だったので、軌道修正して、改めて価値を持つ単位で作り直しました。

本来はPOの役割ではあるのですが、POだけが把握していればよいことではないので、バックログのリビルドについては私からチーム全体に対してプレゼンテーションして、理解を得た上で遂行できたのは良かったと思っています。

あとはレトロスペクティブを通じて、とにかく「成長を止めない」ことに強く意識を置いてファシリテーションを行っています。必ずTRYを出す、少しでも成長と改善を重ねる、それがスクラムの良いところだと思っています。証拠に、TRYがなかったスプリントは今まで1回もありません。

一同 （拍手！）

板原：私はずっと最前線でプログラムを書いていたので、スクラムマスターになって書きたい衝動を抑えるのに苦労をしたんですが、渡邉さんはどうですか？

渡邉：今でも抑えられない場面はありますね（笑）みんなが忙しそうだったら「よし！俺が！」ってなりますが、そういう衝動と戦いながら、あくまで開発チームとPOの支援というところに出来るだけフォーカスしようとはしてます。

板原：清水さんもPOの役割を川上さんから引き継ぎましたよね。心境の変化はありましたか？やはり書きたい衝動を抑えながらだと思うのですが（笑）

清水：POを引き継いだといっても、最終決定したり、要職に話を通したり、というところは川上さんの力を借りながらではあります（笑）POになって思ったのは改めて「大変だな」ということです。

決めるというのは大変ですね。責任もあるし、本当に正しいのか、ということが分からないので。本当はすべて自分で決めなければならないのですが、迷ったときは川上さんや、デザイナーさんや、ここにいる渡邉さんにもご意見をいただくなど、みんなで決めるという形で何とかやらせてもらってますね。

板原：自分だけで正解を判断できないなかで、POとして方向性やビジョンを示さないと開発メンバーが何を作っていいか分からない。方向性が合わなくなったりもする。難しいですよね。

清水：私も元々は開発者だったので、POとして方向性を決めるのにどうしても開発者視点が入ってしまうことに苦労をしています。開発チームにお任せするにあたって、これは大変だからやめておこう、とか、同じエンジニアという気質からすると申し訳ないという気持ちになることもありますし、急な方向転換など躊躇してしまう場面もあって、その辺りはまだまだ未熟さを感じています。なおさらチームでちゃんと話し合ってビジョンを示せるような存在になりたいなと思っています。

板原：清水さんへPOを引き継いでみて、第三者視点から見ていかがですか？

川上：業務の全体像という点ではまだまだ伝え切れていない部分もあるので、判断は大変だろうなと思います。ですが、清水も言っていたとおり、チーム内で相談できる環境がすでに出来上がっているのと、渡邉さんたちをはじめ皆さん積極的に意見を出してくれるので、チームが何とかしてくれるという安心感がありますね。

あとは清水くんや安食くんにお願いしたことで私自身に時間が出来たので、しれっと開発をやってみたり、ということも（笑）そこは書かなくていいですが（笑）

板原：でも大切ですよね、エンジニアとしてスキルを磨き続けていくというのは。

清水：書いていないと感じないこともたくさんありますからね（笑）

板原：安食さんはなんとスクラムマスターの認定も取られたと伺いました。スクラムマスターとしての道をまさにいま歩もうとされているのですか？

安食：そうですね（笑）アジャイルに対するイメージは当初から比べてかなり鮮明になりましたし、アジャイル開発を進める上でのスクラムでの手法には今回とても感銘を受けました。

「価値を素早く提供していく」というアジャイルのコンセプトにとても惹かれたのですが、その良さが社内全体にはまだ浸透していないし、全社でアジャイルの考えをもとに開発を推進できる域にはまだ達していないと思っているので、今後広めていきたいなと強く思っています。

川上：もう次世代が来ているから、私と清水は隠居も見えてきましたね（笑）

安食：まだまだです。人生百年時代ですから（笑）今私が入っているチームはスクラムで開発をやっています。全体としては複数チームあるのですが、全体でレトロスペクティブをやるなど、部分的に取り入れることから始めています。

川上：今朝も安食から、SAFe Scrum Master（SSM）認定取りましょうよ、と持ちかけられて、生きているうちにはと答えましたが、安食のスクラムに対する意欲はすごいですね（笑）

板原：成功体験を持った小さなチームが複数出来てくると、どんどんスケールしやすくなると思います。是非今回の「お客様Myページ」を足がかりとしていただきたいです。

川上：今回の開発では社内のローテーションにもチャレンジできました。安食に代わって基幹チームから2名若手を呼んで、チームの中で育てることも出来ました。今後もメンバーズさんにお力を借りながら、このサイクルもちゃんと回して広めたいですね。

板原：最後に、今後の展望についてお聞かせください。

川上：システム部門は、清水・安食を筆頭にすべてアジャイル開発に変えていきたいと思っています。

清水：他の基幹システムのチームにも徐々にですが、安食のもとでアジャイルの考え方が浸透してきていると思います。レトロスペクティブなどもやってもらっていますし、渡邉さんも入っていただいたりしています。新しく出来る賃貸チームもアジャイルで開発を進めていく想定はしています。

板原：よかったです。早くリリースできることで、色んなことが早くなっていきますよね。全部出来上がってだと、半年後でないと動かない、とか。

川上：そうですね。従来型ですと、リリースまでに状況が大きく変わっている、などは容易に想像がついてしまいます。

板原：コロナなど、これまで想定し得なかった時代がまたやってくると、色々な事象が急激に変わってしまいますからね。これまでの考え方や常識が根底から覆されるというか。アジャイルは、先が見通せない未来にあわせて適用できるのがいいですね。

清水：チームで価値観を共有し、良い価値を届けようという目的意識がチームの動力になる。それがアジャイルの優れたところだと思っています。
当社の開発チーム全体にそういう考えを広げていきたいですね。ただ機能を作るチーム、ではなくて、良い価値を届けようと思うからこそ開発もするし、仕事もするし、意見も言い合えるようなチーム。

アジャイルを広めて、みんなでいいシステムを作って、最終的には我々のような開発部門がビジネスに確実にインパクトをもたらせるようになることが、私自身の目標です。

板原：最近では社長もアジャイル開発に興味がおありとお伺いしました。

川上：プロダクトオーナーの資格を取りたいということで、将来的に毎週のスクラムイベントにも参加してもらおうかなと思っているところです。企業文化とも合っているし、アジャイルのエッセンスを経営にも取り入れていきたい思いがあるようです。

板原：アジャイルは開発現場だけでなく組織にも浸透させて、企業文化として形成させていくことに最大の価値があると思っています。
スクラムの考え方も、ソフトウエア開発だけではなく、ビジネスの色んなところにも適用できる考え方です。今回の取り組みが今後のアジャイル経営の一助になるのであれば、私たちも最初にご支援をしたということで非常に誇らしいです。私もまた皆様と一緒にやりたいです。

川上・清水：是非。すぐにでも！

アジャイル開発スクラム運用サービス

Webアプリケーション開発、AI、IoTなど高い専門スキルを持ったエンジニアを日本全国の開発拠点で顧客企業ごとに専任チームとして編成します。
アジャイル開発スクラム運用　＞

クライアント	株式会社ランドネット
所在地	東京都豊島区南池袋1-16-15 ダイヤゲート池袋 7階
URL	https://landnet.co.jp/

※取材内容は2021年10月当時のものになります