プロダクトが担う範囲を理解する、やらないことを決める…　法改正に伴うMVP決めで重要なポイントとは

外部環境・内部環境の把握

紀井美里氏（以下、紀井）：まず、「やらないことを決める」ところにフォーカスすると、意思決定要素のWhyのユーザーへの提供価値のところで、まず何を提供するかという定義を決めます。

今回のユーザーに提供する価値というところでいうと、インボイス制度で法律が変わるので、ユーザーが法律を遵守した適切な経理業務ができる価値と、あとは業務負担の軽減をまず定めました。

ここに依存する価値の中で提供しない・やらない部分でいうと、プロダクトの担う役割以外はやらないと決めました。なので、会計ソフトが担っている役割はしないことになります。

（スライドを示して）ここのViableという、やらないところを決める上での重要なところは、プロダクトの取り巻く外部環境と内部環境をしっかり理解することです。あとはドメインとインボイス制度の影響範囲や、プロダクトが担っている役割をしっかり理解する必要があります。

（スライドを示して）こちらが、プロダクトを取り巻く環境を把握するところでの外部環境と内部環境を、今回の内容で簡単に書き出しているものです。

外部環境から簡単にいくと、法律ですよね。インボイス制度の法律が変わっていくところと、それに対してユーザーの「楽楽精算はきっとこういうことをしてくれるだろう」とか「こういうことを期待している」というインサイトがあるところですね。

そういうものと、あと競合が何かやってくるか。どういう機能を提供する・しようとしているのかといったところと、経費精算を取り巻く、ほかの関連システムの会計ソフトなどがどういうことをやろうとしているのかの把握です。

あとは、内部環境のところでいうと、自社のプロダクトが担う役割をしっかり把握することです。「楽楽精算」でいうとベストオブリードなので、経費精算の業務に特化しているというところですね。

あとは、社内の関係部署というところでPMM（Product Marketing Manager）との連携だったり、マーケティングがプレスリリースを打つという話があったり、カスタマーサクセスがインボイス制度対応の案内するためにLPを公開していくといったところもしっかり把握して進めていく必要があります。

あとは経営資源で、開発期間や開発リソースは本当に限られているものなので、ここに対してもきちんとオファーをして、現実的なことを落とし込んでいくところが基本的には重要かなと思っています。

これらの外部環境や内部環境のプロダクトを取り巻く環境は、基本的にはこのプロダクト4階層の「なぜ自社がするのか」という市場分析や競合分析の中で、自社の立ち位置を知るためのものなのかなと理解をしています。

ドメイン・制度・製品の関係性を理解する

紀井：重要なポイントの2つ目。ドメインと制度と製品の関係性を理解する部分です。（スライドを示して）これは簡単に表したものですが、経理業務のドメインの中にインボイス制度があって、その中に売上の管理と仕入れの管理があります。

これらの管理された情報は、基本的には仕訳のデータになって、会計システムにデータがインポートされていくというのが主な流れになります。会計システムに入ったあとでいうと、固定資産とほかの情報がどんどん集約されて、最終的には最初に少し話したような決算や法人税、消費税などが確定申告の情報となっていろいろ算出されていきます。

つまり、今回で言うと、価値というものに対して、インボイス制度に沿った状態というのは、仕訳データをしっかり会計システムにインポートできるところになります。

実際には、会計システムを提供している会社からインボイス制度対応でどのような対応を行うのかを調査したり、事前に何社か情報交換会の場を設けさせてもらって、インボイス制度の対応の考え方をヒアリングしたりしました。

実際、制度の開始前なので、ユーザーにインタビューをするというとろは正直機能しないところもあって、関連システムの情報から決定をしていったような背景があります。

やらないことを決めるというところでいうと、最後の課題仮説の立案がバリューのところで残っているのですが、結局ここでのポイントは、どういう価値を提供するかという、「あるべき」ところを決めるのがメインなので、ここが決まれば課題が何なのかは、現状の外部環境や既存の機能の内容、制約前提といったところから自ずと決めることができます。

「MVP機能の策定」と「MVP開発での提供状態」をどのように決めたか

紀井：続いて、意思決定要素の中のWhatの観点ですね。MVP（Minimum Viable Product）の機能策定をどういうスタンスで決めていったかと、その次にMVP開発での提供状態をどういうふうに決めたかを話します。ここでは最終的にMVPのMinimumの中でやらないことを決めます。

MVP機能の策定スタンスとして、法要件に対してどういうスタンスでものを作っていくのかでいうと、インボイス制度の対応において、あくまで「楽楽精算」、プロダクトの立場としては、お客さまの業務を支援する立場であるというような立ち位置を決めます。

決めた上で、お客に提供する価値の依存関係でいうと、もちろん法律を遵守できることを前提として、業務の負担軽減があるので、まずは法律を遵守できる、遵守するための業務支援にフォーカスをした開発を行って、その次に業務負担の軽減を順番にやろうという優先度を決めます。

そこからMVP開発で提供する状態でいうと、仮説課題の立案のところで課題の立案をやっているので、そこの内容から課題仮説の分類を行って、課題の解決方針として機能開発でしか実現できないのか、代替手段として運用回避や別の手段があるのかの分類を一斉にしました。

結局これが何につながるかというと、「今は開発をやらない」という決定に関わってきます。提供する機能として、今は作らないというようなところで、課題の解決方法に運用回避がある場合は運用回避、代替手段で実現できるので、「Minimumとしてはやる必要はないよね」という考え方です。

ここで必要なこと、重要なことは、プロダクトの取り巻く外部環境と内部環境をしっかり理解することです。そしてなによりも自分が携わっているプロダクトの理解が重要で、制約や前提を今今一度把握している必要があります。

ステークホルダーと適切な単位ごとに合意形成する

紀井：最後のポイントは、ステークホルダーと適切な単位ごとに合意形成することです。（スライドを示して）ここでは、よく連携するPMMとの連携の話になるのですが、基本的に何かを決めたり相談したりする時の単位や順番は、結局この要素の単位で依存関係の上から順に話をして、いろいろと合意形成していきました。

なので、ユーザーに提供する価値をすり合わせて、そのあとプロダクトの価値提供として「これはやらないよね」というところをすり合わせる感じで、その単位で単位ごとに進めていきます。

「この進め方で良かった」と思うところが、時間がない中で、でもしっかりと深い議論をしていきたいとなった時に、効率が良い方法がなにかないか考えていたところ、「この順番でやればそんなにブレないな」と途中で気づきました。なるべくこの順番で、細かく話をして進めていくところにたどり着いたというのが経緯です。

結果的に、スコープがそれぞれすごく絞られているので、議論のポイントが明確で発散しにくいといったところがあって、けっこうスムーズにいろいろなことを決められたのかなというのが個人的な感想です。

MVPを決めるためのアクションで重要なポイントは3つ

紀井：ここまで具体的なアクションを紹介したのですが、最後にまとめです。

MVPを決めるためのアクションはいろいろあると思っています。（スライドを示して）これだけじゃないと思うのですが、今回の例で言うと、重要なポイントは3つかなと思っています。

1つ目がプロダクトを取り巻く環境で、外部環境、内部環境をしっかり理解しましょうというところです。それから、ドメインの理解で、経理業務の範囲と、今回の法制度に対しての影響範囲が何なのかと、あとはプロダクトの担う役割の範囲の理解です。あと最後は、やらないことを決めることです。この3つが今回重要だったポイントなのかなと考えています。

ご清聴ありがとうございました。

司会者：紀井さん、ありがとうございます。けっこう難しい内容だったかなと思うのですが、いろいろなフレームを使っている印象を持ちました。「なんとなくで決めてないんだな」みたいなところをすごく深く感じました。

みなさん、もし質問があればと思うのですが……。内部環境、外部環境みたいな話がありましたが、今回のポイントは、ドメイン理解のところでもインボイス制度がけっこう大きく関わってきたのかなと思っていて。

そういうドメインの理解みたいなところで、例えば新しい制度でまた（何か別のものが）生まれてきたりすると思うのですが、そういった時に、例えば紀井さんはどうやって勉強したりキャッチアップしているのか少し気になりました。もしおすすめの勉強法があれば（笑）。

紀井：おすすめと言われるとちょっとわからないんですが、とりあえず法律（という点で）は、その制度を理解するところだとは思います。その制度がそもそも何のために作られたか、何を目的としているのかにポイントを置いてみると、その法律の仕様じゃないですが、やりたいことが見えてくるのかなとは正直思っています。

司会者：なるほど、ありがとうございます。「なんで？」というところは、PdMが常にとっている思考のフレームなのかなと思いました。ありがとうございます。