株式会社ランドネット（以下、ランドネット）が2021年7月にリリースした、電子媒介契約サービスのマイページ機能。 メンバーズエッジでは、当機能の内製開発ならびにランドネットでは初の試みとなるアジャイル開発の導入をチーム提供型で支援した。 今回は対談という形式で、アジャイル導入の経緯から今後の展望まで、実際のエピソードを交えながらアジャイル開発に対する考えや思いをお伺いした。

※この記事は2021年12月に執筆されました。当社は2023年4月付で、EMCカンパニー、 メンバーズキャリアカンパニー、 メンバーズエッジカンパニー、ビジネスプラットフォームカンパニーの4カンパニーを統合し本部制を導入しています。

対談者プロフィール

▼株式会社ランドネット 

▼株式会社メンバーズ

1.導入準備

アジャイル導入のきっかけは、オンライン取引需要の拡大に対応するための「新規プロダクト」の開発だった

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

川上 もともと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を入れてもらいましたけど、入れてよかったです。

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

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

次回は3ヶ月後のMVPリリースに向けた開発も始まる中、序盤の苦労からスプリントの本質的な価値を認識していくまでの過程を通じて「強いアジャイルチームとは何か」に迫っていきます！
1週間スプリントでの価値提供プロセスなどをご紹介していきますのでお楽しみに！