リモートでアジャイル開発ってどうしてる？〜メルカリ、LINE、クオカードでの取り組みを公開します〜【後編】

2020年8月26日（水）、Findyが主催するエンジニア向けイベント「アジャイル開発最前線〜メルカリ、LINE、クオカードのエンジニア組織を徹底解剖！〜」がオンライン上にて開催されました。

新型コロナウイルスの影響により、私たちの働き方は大きく変化しました。こうした状況の中で、より良い製品を作り出すためには、単に働き方を変えるだけでなく、多様な働き方に適した組織体制やコミュニケーション、さらにはツール選定など、エンジニア組織や開発手法自体も、時代に合わせて考える必要があります。

今回は、長きに渡ってアジャイル開発を進めてきたゲストの方々をお呼びし、アジャイル開発のこれまでと直近の変化、今後のあり方について語っていただきました。その内容を、前編のパネルディスカッションパートと、後編のQ＆Aパートに分けてお届けします。

前編はこちらから

■登壇者プロフィール

鎌田 正浩／LINE株式会社 [@iratamak]

メーカーでの組み込みソフトウェアエンジニアとしてキャリアをスタートさせた後、 自社SNS、ゲームプラットフォーム、動画配信サービス、VR技術研究など複数領域でエンジニアとして働く。スタートアップでのEngineering Manager や、FOVE株式会社でのVPoEとしての経験をもとに、現在 LINEでアジャイルコーチとして、組織横断的に開発チームやEngineering Managerのコーチ業に従事。

齋藤 健一／株式会社クオカード [@saito400]

株式会社クオカード デジタルイノベーションラボ プロダクトグループリーダー。 フリーランス、SIerを経てベンチャー企業数社でCTOを歴任。 現在はQUOカードPay開発のプロダクトオーナー。CSM/CSPO。

白石 久彦／株式会社メルカリ [@hisahiko]

大学卒業後、さまざまな業務システム、インターネットサービスの開発プロジェクトにエンジニアとして携わる。ソフトバンクグループ、株式会社レコチョクなどにおいて、大規模新規サービスの立ち上げや技術組織の立ち上げを担当し、2014年ドリコムの技術担当役員に就任。技術組織の強化に取り組む。2018年より株式会社メルカリに参画、技術組織強化担当Directorに就任。他社の技術顧問も務めている。

■モデレーター

田頭 一真／ファインディ株式会社 [@taityo0911]

株式会社ドリコムでIP系ゲームアプリの開発ディレクターを経験後、2018年6月にジョイン。Findyでは、Freelance事業と転職事業のユーザーサクセスの立ち上げ〜グロースに携わる。

Q1：得意な人に得意な仕事が集まり、共有されない

ーーここからは参加者の方からいただいた質問をもとに、Q&Aに移ってまいります。まずは「チームとしてクロスファンクショナルにしていきたいが、得意な人に得意な仕事が集まってしまい共有されない」という課題をいただいています。これについて、いかがでしょうか？

齋藤：
最初は結構ありました。これはまず、クロスファンクショナルにすべきだということを言い続ける必要があると思います。あとは、ペアプロとかモブプロで強制的に情報が共有される形にする。それから、これはスクラムでやっている場合ですが、スプリントバックログの取り方が問題になりそうだという気がしています。 自分のやりたいものだけ取るような形になってしまっていると、クロスファンクションにはならないと思うので、ペアプロ/モブプロをしてない場合は得意でないものでも上から取るようにしないと変わらないんじゃないかなという印象を受けました。

鎌田：
組織によっては、クロスファンクショナルが良いと言いつつ、「なぜ」というところが抜けているケースもあるかなと。例えば、チームメンバーにまったく知識の偏りがない、完全にクロスファンクショナルな状態を100と置いて、全然そうではない状態を0とした時に、どの程度の数字をどれくらいのコストをかけて作っていくのかについて、チームで話し合ってもいいのかなと思います。

「それぞれが得意なところで成果を出す」ということもすごく価値のあることなので、無闇にクロスファンクショナルな状態を目指したり、それが出来ていないからダメだというように考えないほうがよいかなと思っています。チームに起きている問題から考えたときに、例えばここでいう「共有されないこと」によって起きている課題に対して、「クロスファンクショナルな状態になる」ということ以外にも対策があるかもしれません。どれくらいその問題にコストをかけられるかから考えるのも、1つのやり方かなと思います。

白石：
今は特に専門性が多岐にわたっていますから、分業制が理にかなってる面はあって、ビジネスに直結してスピードが出るとなると、それを施行してしまいがちなんですけど。最近メルカリでは、それぞれ”モバイルエンジニア”や”バックエンドエンジニア”じゃなくて、”全員ソフトウェアエンジニア”だよねという話をしています。

逆に、専門性の高い人たちから「フルスタックにならなきゃいけないんですか」と言われたりもするんですが、まったく専門性は否定していなくて。例えば、「バックエンドエンジニアの組織でその仕事をしているから、バックエンドしかできない」と思って欲しくない、みたいな感じなんですよね。

自分がやりたいところで大きなバリューを出すというのも、全然いいと思います。事業サイドと折り合いをつけなければならない難しさはあるんですが、ちょうどそれに取り組んでいるところなので、皆さん悩まれているんだなと思いました。

Q2：アジャイルを導入する時、最初に手を付ける部分は？

ーー続いて、「アジャイルを初めて導入する組織の場合、最初に手を付ける部分はどこになりますか？」という質問をいただいています。

齋藤：
アジャイルを初めて導入する場合、多くの場合は階層型組織に導入することになると思います。その場合、トップの方や意思決定者、ステークホルダーの理解を獲得するのが最初かなと思います。ルールを作ったり、就業規則を変えたりというのはその後しかできないので。

鎌田：
アジャイルは考え方で、導入するかしないかの0か1かではないので、なぜやるのかという部分が最初に必要だと思いますね。それによってやり方も変わってくるので、どれだけ組織としてコストをかけるつもりがあるか、アジャイルになるために必要なことが、組織として本当にやりたいやり方なのか、といったことを考える必要があります。

僕もアジャイルコーチという名前の職種ではあるんですけど、毎回アジャイルやスクラムを採用すべきとは思っていなくて、場合によっては「振り返りだけやりましょう」と言う場合もあります。いろいろな価値観や組織文化が関係するところなので、「たくさんコストを払ったけど、得られたものがあまりなかった」とならないように意識しています。

白石：
何を解決したいかによるかもしれないですね。アジャイルとかスクラムって、良いポイントはたくさんあると思うんですけど、一番マッチするのは、不確実性があって正解のないものを作る時や、コンテンツクリエイティブ要素が高いものを作る時だと思うんです。

スクラムもいろんな要素がありますから、例えば優先順位が決められていない場合に、プロダクトバックログをやるとすごくハマったりしますし、一番効果がありそうなところから導入するのもいいと思います。

Q3：リモートワークにおすすめのツールは？

ーー「リモートワークにおすすめのツールはありますか？」という質問もいただいています。

鎌田：
LINEでは、最近ようやく採用できたんですけど、Miroというツールを使っています。Miroは、オンライン上のホワイトボードツールで、付箋のようなオブジェクトを置いたりできるんですね。

そこにカンバンを作ったり、チームのワーキングアグリーメントを置いてみたりと、チームごとにいろいろとカスタマイズできます。それを使って、リモートワークにうまく移行できたチームもあったのでおすすめです。

齋藤：
うちもMiroとSlackとZoomとGoogle Meetくらいなので、ほとんど同じです。もともとリアルオフィスでホワイトボードをよく使っていたので、その代わりとしてMiroを導入しました。 言葉だけだと認識がズレがちなので、良いと思います。Miroは大喜利みたいなことが始まりやすいという学びがありました。

ーーリモートワークで活用するツールで、「こういう時はこのツールを使う」といった使い分けはありますか？ 例えば、こういう時はSlackコールで、こういう時はZoomで、など。

白石：
先ほど雑談が減ってしまったという話題が挙がっていましたけど、それでいうとSlackは良いなと思うんですよ。ただ、促さないとなかなかハードルも高いですよね。

「ちょっといいですか？」とメッセージを送って、Slackコールをかけるみたいなことはよく聞きますけど、僕自身まだあまりSlackコールを使っていないので（笑）。計画されたミーティング以外で突発的に話したいという部分を、どう埋めるかは課題かもしれないですね。

鎌田：
そうですね、僕もきっかけが難しいなと思っていて。Slackでbotに雑談のきっかけを投稿してもらったりしています（笑）。あとは、今日の元気度を絵文字でリアクションしてもらって、「みんな元気かな」というのをお手軽に共有したりしています。

あと、これは他社の方に聞いた話ですけど、朝にラジオみたいな形で、Zoomの部屋を誰かが立ち上げて来た人と喋っているのを配信したり、夜にはBarのような感じで、マスター役の人がいて自由に入って話したり。各社いろいろな試行錯誤をしているタイミングですよね。

ーーツールの導入について、メンバーの方からどういった提案であれば導入するかといった基準はありますか？

齋藤：
ツールですが、1人あたり月5～10ドル程度であればとりあえず導入してみて、ダメだったらやめればいいという進め方をしています。 まだ組織が小さいので、言語やフレームワークについては例えばシステムAがKotlinでシステムBがGo、システムCがPHPといった環境になると採用や育成等で厳しい部分が出てくるので、なるべく合わせるようにしています。

ーー人数が増えてくるとツールのコストも高くなると思うのですが、先ほどのMiroの導入などにあたってはいかがでしたか？

鎌田：
会社で使えるようにするには、ハードルがありますね（笑）。セキュリティチェックもありますし、有料ユーザーとして使っていくには予算の話もあるので、いいものだから全社ですぐ採用！ということは出来なかったりします。

Miroはたまたま昨年から検討していたので、コロナでリモートワークになった時に使えるようになっていて良かったな、という感じでした。ツールは選択肢としていろいろあった方がいいと思っているので、チームで試して良いものを探したりしています。

Q4：オンラインで実施する、レトロスペクティブについて

ーー続いて、「スクラムイベントをオンラインで実施する中で、レトロスペクティブが一番困っています」といただいています。

鎌田：
レトロスペクティブは、マンネリ化が起きやすいものの1つですね。いくつか解消のための方法はあるんですけど、「課題があまり出てこなくなった」という状態に対しては、理想のチームの状態を考えるということをすることがあります。課題というのは、理想と現実のギャップなので、課題が出てこないのは、無意識に理想の状態を手の届きやすいところに置いていて、そこにはもう到達したと考えているケースがあります。

理想のチームの状態を考えるのが大変な場合は、「今のチーム開発に点数をつけるとすると何点ですか？」と聞いて、70点や80点と返ってきたら、「それを100点にするためには、何を変えるといいですか？」というような質問をしてみたりします。

あとは、使っているフレームワークを、少し変えてみるというのもありますね。日本だとKPTが有名ですけど、KPTAを使ったり、DAKI（Drop、Add、Keep、Improve）を使ったり。そうやって質問やフレームワークを変えてみると、違うアイディアが出てくることがあります。

齋藤：
オンラインでやるときのツールって、何を使っていますか？

鎌田：
Miroのボード上でやることが多いですね。インターネットから画像を持ってきて、ちょっと楽しい感じにしたりとか。そこにアイディアをみんなで付箋に書き出して、というようなやり方をすることが多いです。オープンディスカッションが苦手な人でも、付箋に書き出してもらう時間をとることで、意見を出しやすくなる効果もありますね。

Q5：アジャイル開発は、エンジニア以外にも浸透している？

ーー続いての質問は、「アジャイル開発は、エンジニア以外のチームにも浸透していますか？」という内容です。

鎌田：
LINE全体でいうと、まず”アジャイル開発”と認識してスクラムなどをやっているチームの方が少数派だと思います。一方で、開発じゃなくても、アジャイルなやり方をしている例は結構あります。カンバンを取り入れていたり、開発と企画がそれぞれ別のチームで働いている大きな組織で、企画は企画チームの中でスクラムをやっていたりとかですね。

白石：
メルカリではなく顧問で関わっている会社さんのお話しなのですが、鎌田さんがおっしゃられたように、カンバンが上手くハマっているところは結構ありますね。僕も勧めたりしますし、開発ではないチームにも「こういうやり方があるよ」と教えると、結構ハマったりする気がします。

齋藤：
おそらく他の部署はアジャイル開発まではやっていないと思うんですけど、近いところだと「オープンコミュニケーションにしましょう」とか「今までメールで管理していたものを、バックログに入れるようにしましょう」といったものは個別に進めている感じです。

自分の部署が社内ベンチャーのような立ち位置なのでツールや進め方を最初に導入することが多く、それを社内に広めようとする動きが多いです。

Q6：組織の考え方について、理解者をどう増やす？

ーー「組織の考え方について社内で理解者を増やすために、どのような方法をとっていますか？」といった質問もいただいています。

齋藤：
うちは理解がある社長なので、そんなに難しくなかったんですよね。エンジニア経験はないと思うんですけど、簡単に資料を作って持っていくと、すぐに理解してもらえます。内容によっては、例えば「評価制度やめたいです」みたいな話はさすがに最初はダメと言われましたけど（笑）。

ただ、セキュリティ面は、うちも最初は大変でした。自分のチームだけルールを変えるのはそれほど難しくないんですけど、全社に関係するところはやっぱり時間がかかる事があります。例えば、最近パスワード定期変更ルールを廃止したんですけど、それは色々な所が出しているレポートを持っていって何度も説得したりとか。

なので、細かいところで制度を変えるために、いろいろ資料を作ったり何回も話をしたりと、地道な行動も結構ありました。そういうのは、どこの会社でも大なり小なりあるのかなと思うんですけど、うちでもやってきました。

Q7：ウォーターフォール的に進むチームとの境目について

ーーこちらで最後の質問とさせていただきます。「エンジニア側がアジャイルでやると決めても、ビジネス側を含むチーム全体がウォーターフォール的に進むと、間に立つアジャイルコーチは辛いと思います。どうやって解決してきたか教えてください」とのことです。

鎌田：
よくウォーターフォールとアジャイルって対比構造で語られることが多いんですけど、実際にはグラデーションがあると思います。

アジャイルでは、相対的に短いスパンでフィードバックを得て反映していくことが特徴のひとつですが、そのフィードバックは実際にプロダクトを使うエンドユーザーからでなくとも、社内の人がユーザーとして使ってみることで得ることもできます。例えば、誤動作が人命や顧客の財産にかかわるようなすごく要件が厳しい業界でも、社内でフィードバックを得ながらアジャイルに進めて、要求の厳しい部分や自社内だけでコントロールできない部分はウォーターフォールにするなどのケースもあると思います。

ご質問に回答すると、ビジネス側も開発側も同じ会社のメンバーとして、同じ目的のために仕事しているので、あまり境目がない方が良いというのは理想論として存在しつつ、まずどこから進めるのかで言うと、双方のメリットがある部分を探す所からかなと思います。それぞれの立場で現状の開発のやり方やビジネスの進め方は100点であることは少なく、みんな何かしら感じている課題があると思うんですよね。なので、その課題にフィットするものから採用して、小さい成功体験を作って、どちらにとってもメリットがある形で進めていくのが1つかなと思います。

例えば、ビジネス側の視点でいうと、顧客から何か新機能の要望をもらった時、その要望の実現が「1年後の夏に大型リリースを控えており、そこで...」という状態よりも、最短で3ヶ月後に実装できる可能性があるほうがうれしいですよね。そういった双方の嬉しいポイントを探すためのコミュニケーションから始めるかなと思います。

ーーそれでは、お時間となりましたので、イベントを終了させてきたいと思います。本日は貴重な時間をいただきまして、ありがとうございました！

以上で本イベントは締めくくられました。ここまで読んでいただき、ありがとうございました！

よろしければ、エンジニアの皆さまはFindyでご自身のスキル偏差値を測定してみてください。

[正社員の方]
ハイスキルなエンジニアのプレミアム転職サービス Findy

[フリーランスの方]
フリーランス・副業エンジニア向けの単価保証型の案件紹介サービス Findy Freelance

また、Findyでは年齢や勤務形態を問わず、様々な働き方で採用をしています。
興味のある方は、ぜひこちらからご応募ください！