インボイス制度開始に伴い求められたプロダクトの対応　「やらないことを決める」ために実践した意思決定要素の構造化

紀井氏の自己紹介

紀井美里氏：それでは「MVP開発をするための要求の詰め方」というところで、本日お話しします。

まず簡単に私の自己紹介をします。私は紀井美里と申します。現在は「楽楽精算」のプロダクトマネージャーを担当しています。これまでの経歴ですが、新卒のエンジニア職としてラクスに入社して以来、ずっと「楽楽精算」の開発に従事しています。

まずはプログラマーからエンジニアとしてのキャリアを歩み始めて、RAKUS Vietnamというオフショア開発チームがあるので、そこでBrSE（Bridge SE）という役割をやり、あとは設計業務を経てプロジェクトマネージャーを担ったあとに、プロダクトマネジメント専門の組織で製品管理課が発足した時からプロダクトマネージャーをしています。

本セッションで話すこと

本日は、インボイス制度対応を事例に、MVP（Minimum Viable Product）開発とするために、どのような工夫をして要求を詰めていったかを話します。

実際の工夫としては、今日何回か出てきたと思うのですが、プロダクト4階層を用いて意思決定要素の構造化や、やらないことを決めること、あとはステークホルダーと適切な単位ごとに合意形成をするところ。これら3つのアクションを今回取っていきました。

インボイス制度とは何か

本題に行く前に、インボイス制度とは何かについて簡単に触れます。2023年10月1日から施行された新しい消費税の制度です。国が定める「適格請求書発行事業」の登録を受けた事業者で、個人事業主や法人（がそれ）に当たるのですが、その対象に対して発行する適格請求書に基づく消費税しか、原則として仕入税額控除を認めないとする制度というところで、（この文言は）国税庁から抜粋をしています。

「楽楽精算」を利用しているユーザーへの影響として何があるかというと、適格請求書発行事業者が交付した適格請求書であるかの判断と、適格請求書の保存が必要です。

上記を判断した上で、税額の計算をする必要があります。これを仕入税額控除と言います。「長々とどういうことなんだ」となると思うのですが、一言で言うと、事業者は原則回避することができない法律が施行されるので、なんらかの対応をしなければいけないところに陥っているというところになります。

あまり身近ではない方が多いかなと思うのですが、「10月から社内での経費精算ルールが変わったと聞いたことがあるような気がする」とか、あと、消費者として一番身近に感じられるところでいうと、レシートですね。コンビニエンスストアやスーパー、普通に飲食店でもいいのですが、実はレシートにTから始まる13桁の番号がつくようになっているので、そういうところを見てもらえると、インボイス制度の影響度合いがわかるかなと思います。

インボイス制度によって「楽楽精算」を取り巻く環境がどう変わるか

ここから徐々に本題に入っていきます。プロダクトを取り巻く環境がどういう状況なのかというと、インボイス制度に関連するところでは、経理業務のドメイン領域があって、その一部としてインボイス制度があります。

（スライドを示して）これはすごく簡易的に書いているので、細かいところは厳密には違う部分はあるのですが、経費精算、経費管理は企業の仕入れに属しているもので、「楽楽精算」は経費管理のところにあるので、この場合、仕訳データが最終の成果物の1つとなります。

あとは、普通に売上の管理や原価ですね。一般的に通常の企業はそういうところはちゃんと見ていると思うのですが、会計システムにしっかり取り込まれて計算されたあとに、決算報告書や確定申告書の数字に反映される処理が会計システムで行われています。というのが、このプロダクトを取り巻く環境です。

対応の要求を決めるにあたってプロダクト4階層に当てはめる

こういう状況というか外部環境で、インボイス制度に対応していくためにどういうことを考えなければいけないのかといったところを、意思決定要素の構造化の面から話します。

どんなに大きい課題だとしても、基本的にプロダクト4階層を念頭において考えると、だいたいなんでもできるのかなと個人的には思っています。本日何回も出てきたプロダクト4階層というものは、プロダクト開発を進める時に効果的だとされている考え方です。

私たちはふだんからこの考え方を意識してやっています。既存のプロダクトの機能開発の場合でいうと、WhyとWhatのところですね。ここにある観点での情報収集や整理・分析を行って、PRDと呼んでいる製品要求仕様に落とし込んでいきます。

インボイス制度の対応の要求を決めていくにあたって、まずプロダクト4階層のWhyとWhatの、「誰をどんな状態にしたいのか」というところと、ユーザー体験と、あとロードマップ……。ロードマップというよりかは、どういう優先順位でやっていくかになるのですが、ここにフォーカスをして、どういう意思決定の要素をどういう順番で決めていくかを構造化をしていきました。

意思決定要素の構造化

（スライドを示して）実際に構造化したものがこちらです。Whyの部分の、誰をどんな状態にしたいのかというフェーズで考えなければいけない要素でいうと、ユーザーに提供する価値は何なのかというところです。

その中にある下の依存関係でいうと、プロダクトの価値提供としてやらないことはなにか。その下に紐づいていくものが、課題の仮説の立案とMVPの機能の策定のスタンスです。

その下にMVP開発で提供する状態をどういう状態にするのかと、その中でも今はやらないことは何なのかを決めていくような構造です。どういう要素をどういう順番で決めていくか。それは4階層のうちのどこに当たるのかを構造化したものになります。

（スライドを示して）まず、依存関係が物事を考える順番を上から順番に考えていきます。今回は基本的にはシリアルな構造になっているので、まず「ユーザーに提供する価値は何なのか」から順番に決めていきました。

次に、コアと書いてある部分がありますが、これは「この要素において変更しないもの」と定義しました。何のためのコアなのかというと、「迷った時に立ち戻るところ」です。

例えば、課題仮説の立案のところで、「それって本当に今回やるべき課題なのか？」と話が発散する場合は、1つの上に帰っ、立ち戻って検討することができるんですね。なので、コアはブレるといろいろまずいので、基本的には変えないものを定めるところになります。

次が、今回は「この要素の中にやらないことを決める」とあらかじめ含めるようにしたのですが、これに関してはこのあと説明をします。

MVPを決めるためにやらないことを決める

こういう構造のもとで進めていくのですが、その前に「MVPとはなんぞや」というところに一度触れていきたいと思います。

MVPとは、ユーザーに最小限の価値を提供できるプロダクトのことです。（スライドを示して）こちらの図はMVPの説明によく出てくるものですが、私は「初期の顧客を満足させてフィードバックや実証を得られる機能をデリバリーせよ」という考え方と認識をしています。

なので、MVPを決めるためにやらないことを決める、本当に必要なことだけを決めて価値を提供していくところが今回のポイントになります。

（スライドを示して）ここでの思考プロセスの順番でいくと、MVPを決定するプロセスを、右から左へ順に考えていきました。このあと、実際の工夫に対してのアクションにフォーカスして説明をしていきます。

（次回に続く）