顧客が満足するものをどのように知り、どう早く提供するか　ユーザー価値を最大化するスクラム開発の流れ

塚原氏の自己紹介と、株式会社M&Aクラウドの事業紹介

塚原彰仁氏：よろしくお願いいたします。あらためて、株式会社M&Aクラウドでスクラムマスターとエンジニアをやっている塚原と申します。Twitterをやっているので、まだフォローしていない方がいたらフォローをいただけると幸いです。noteとかでもスクラムに関する記事を何本か書いているので、よろしければ見ていただいて、気に入ったら「いいね」を押してもらえるとうれしいです。

弊社M&Aクラウドでは、M＆Aと資金調達における、売り手と買い手のマッチングサービスを提供しています。スライドの中盤でサービスの参考例が出てきます。その時に、M＆Aの“売り手”と“買い手”というキーワードを使うので、マッチングサービスの売り手と買い手の話はこのあたりを思い出してもらうと、わかりやすいと思います。ぜひ覚えておいてください。

本日のセッションで伝えたい「スクラムマスターの経験は役に立つ！」

本日のスライドでお伝えしたいことを一言でまとめるならば、ずばり「スクラムマスターの経験は役に立つ！」です。スライドを最後まで見たあとに、「ちょっと気になるな」とか「スクラムマスターをやってみようかな」と興味を持ってもらえたら幸いです。

スクラムマスターでどんな経験ができるかと言うと、スクラムで開発することで、プロダクト開発でいかにユーザー価値を提供するかを意識できるようになります。もちろん開発メンバーでも意識することはできますが、特にスクラムマスターはスクラムのチームに考え方や取り組み方を伝える立場なので、チームの中でもより学びが強化されると考えています。

また、エンジニアを経験するだけではなかなか身に付かない、スクラムマスターに求められるスキルセットがあるので、新しい経験と学びがおすすめです。

（スライドを示して）今回はこういう方たちに刺さるといいなと思ってスライドをまとめています。1つはキャリアとしてマネジメント方面を考えている方。また、マネジメントのキャリアが自分に向いているのかわからない方。さらに、マネジメントに興味はあるけれど、スクラムには興味がないというか、やったことがないという方です。

スクラム開発とは何か

スクラムで開発をしたことがないという方もいると思うので、まずはスクラムについて簡単に紹介させていただきます。

「スクラムとは複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである」と、スクラムをやる人はみんな一度は読むであろう教科書的な『スクラムガイド』に書かれていますが、少し抽象度が高くて難しいですね。私もこれをすごくわかりやすく説明するのはなかなか難しいと思います（笑）。

ポイントを押さえようと思うと、「透明性と検査と適応が大事だ」とよく言われています。チームで現在の状況の問題点を明らかにして、定期的に進捗状況をチーム内やチーム外と共有してフィードバックを受ける。そのやり方に問題があれば改善していくサイクルを、1週間や2週間の一定期間で繰り返していくことが重要です。

これを繰り返すことで経験を蓄積して、どんどん良くなっていく仕組みが、スクラムの主な流れです。透明性を担保して検査して、どんどん適応していく流れのステップです。

株式会社M&Aクラウドがスクラムを導入することになったきっかけ

弊社がスクラムを始めたのはちょうど1年ぐらい前です。スクラム開発をやる前はゆるーいスクラムというか、ふりかえりはするけれど、チーム外の開発の途中経過を十分に共有できていませんでした。なので、社内の開発部署以外のメンバーが実装された機能を知るのは、リリースされたあとになっていました。

そのため、リリースされたあとで部署外のメンバーが実際に機能を触った時に「ここを修正してほしい」などのフィードバックがポンポン出てくる状態でした。

すでに別の開発が始まっているので、もらったフィードバックになかなか対応できないという悲しい状況や、気合いを入れて実装をした機能が、蓋を開けてみればなかなかユーザーに刺さらないこともしばしばありました。

この課題を解決すべく、弊社ではスクラムを導入することになりました。

スクラムイベントを実施することで、開発部署以外のメンバーから毎週フィードバックを受ける機会を設けることができました。リリース後に修正要望を受けることも減り、ふりかえりの中で、チームの関心事が技術寄りのものばかりではなく、プロダクトの開発プロセスやチームの成長についての議論が増えていったように思います。

顧客が満足するものをどうやって知って、どうやって早く提供するのか

ここで弊社の開発の様子を紹介させてもらえればと思います。プロダクトを開発する上での大前提として、ユーザーが使うものを提供する必要があります。それらはユーザーの声から変更していったり、プロダクトマネージャーがユーザーヒアリングをしてニーズをあぶり出したりすることで、「こんな機能が必要だろう」というところから考えていきます。作った機能を使ってもらえない、悲しい事態を避けるための取り組みだと思います。

先ほどの前提を活かした上で、顧客が満足するものを1日でも早く提供することが重要です。弊社のサービスで顧客が満足するものは、案件のソーシングや成約までのサポートなどが考えられます。

ユーザー価値を最大化するには1日でも早くリリースして、ユーザーがサービスを利用する時間を増やしてあげる。あとは、ユーザーが満足するものをちゃんとリリースすることで、ユーザー価値がどんどん大きくなっていくという算段です。

では実際に、具体的にどうやっているのか。顧客が満足するものをどうやって知って、どうやって早く提供するのか。ここでやっとスクラムの開発の仕方に入っていきます。

まず、顧客が満足するものを知るところでは、ユーザーとユーザーに一番近い人にヒアリングをしていく。ユーザーに一番近い人というのは、カスタマーサポートや営業です。開発チームは、フィードバックを基にユーザー目線で開発していきます。制作物に対して、ユーザーやユーザーに一番近い人からフィードバックを得て、確からしいものをちゃんと作っていくという流れです。

（スライドを指して）これは1つの参考例、開発時のタスクです。実装する機能ベースで考えるのではなく、ユーザーストーリーを理解して「なぜこの機能を実装するのか」「そのために何を用意する必要があるのか」という目線でエンジニアも開発しています。

エンジニアとしては「○○を実装すれば満たせるんでしょ？」みたいな考え方になってしまいますが、「なぜこの機能が必要なのか」からちゃんと考えるようにしています。

リリースの仕方も、こまめに出して使ってもらえる時間を最大化しています。参考例で言うと、遠くに行く手段として、いきなり車を開発すると完成するまでに時間がかかってしまいますが、まずは自転車を用意することで、より早くユーザーに移動手段を与えてあげるというやり方が1つあります。

あとはこまめに見てもらって、無駄を抑えて使ってもらう時間を最大化することです。（スライドを指して）例えばこちら。口に手を当てている状態で最後の色付けまで行ってしまってから「ここに手は置かないでくれ」というフィードバックがあると、かなり手戻りが発生してしまいます。そうならないように、下書きのタイミングでフィードバックをもらえば、無駄なものを作らずに、より早くユーザーにリリースできます。

株式会社M&Aクラウドの機能リリースまでの流れ

弊社のある機能のリリースまでのステップを紹介します。Web上で、売り手企業に向けて買い手を紹介するサービスを締結してもらう機能をリリースすることになりました。

その時、最初にプロダクトマネージャーがワイヤーフレームを作って、ステークホルダーからフィードバックを受けます。スライドのような同意する画面があって、確認があったら、きっと機能として満たせるだろうというものです。

それを受けて、デザイナーがデザインを完成させてくれます。

それを、エンジニアが初期実装で、ステークホルダーからフィードバックをもらう状態にしています。今までは一気に作ってリリースするところでしたが、ステークホルダーからいったんフィードバックをもらうようにしています。

そうすると、ワイヤーどおりに作ったものの「実は利用規約のチェックは1つじゃ足りない」とか「実はこのボタンの色はこれじゃないのがいいんだよね」というフィードバックをいただきました。

最終的に完成したのがスライドのページで、恐らくユーザーが求めていたものに一番近い状態にたどり着くことができました。これは1つの例ですが、弊社はこのようなステップでスクラム開発を実施しています。

（次回に続く）