引き算による仕様の最小化でユーザへ多くの価値を届ける
こんにちは。
アスエネ VPoEの石坂(@ishisak)です。
稲刈りが終わり、新米が食べられる季節ですね。
物価の高騰でパンなど小麦粉を使う食材の値段はあがっていますが、
実はお米の値段は下がっています。(米農家の義父談)
みなさん、お米を買ってお米を食べましょう。
できれば地元の農家さんのお米を買って地産地消しましょう！
さて、本題です。
アスエネは半年間で多くの機能追加を実現してきたのですが、
大きな会社と比べて小規模な開発チームでどうやって多くの機能実装を実現してきたのかをお話しようと思います。
仕様の引き算による実装するものを最小化
結論からいうと、PdMとデザイナーが考えてくれた仕様/要件をたたき台に、ユーザにとって使いやすい状態でかつどこか最小の機能になるか徹底的に議論しています。
結果、作るものが少なくなる→開発期間が短くなる→多くの機能がユーザへ届く サイクルを実現しています。
アジャイル開発やリーン開発ではMVP（Minimum Viable Product）と表現されていますが、まさにMVPです。機能ごとにMinimumを探しているのでMVF（Minimum Viable Feature）とも言えますね。
なぜその方法をとるのか
搭載機能を最小限にしてまで多くの機能をユーザに届けるには目的があります。
リーンスタートアップでも下記のように語られていますが、学びの機会を多くすることが目的です。
従来の製品開発は長い時間をかけてじっくりと開発し、完璧な製品をめざすが、MVPは目的が学びのプロセスを始めることであってそれを終えることではない。プロトタイプやコンセプト検証と違い、MVPは製品デザインや技術的な問題を解決するためのものではない。基礎となる事業仮説を検証するためのものなのだ。
(著) エリック・リース
さらに、システム開発にまつわる風刺画として有名な画像があります。
顧客も自分の欲しいものが変わったり、作り手もそれぞれの立場から理解が異なっているというシステム開発の難しさを表現している絵です。
ユーザが本当に求めているものを届けるためにはユーザヒアリングやログから本当に求められるものを見極めが必要です。そのためにもアスエネでは小さく出して、ユーザの求めるものに育てていくスタイルをとっています。
アスゼロの核となるCO2排出量見える化のための集計業務は、運用方法を確立できていないユーザが多いこともあり、一緒に最適化された運用を探しています。
アスゼロを使うことでExcelでの集計業務よりも70%工数削減することができますが、まだまだ改善の余地がある業務です。その最適解を見つけるためなのです。
仕様の引き算とは具体的にどんな話し合いになるか
例えば、データ一覧画面があり、要件として「フリーワードで絞り込みをできるようにしたい」があるとします。
エンジニアから以下のような提案をします。
「このデータは登録頻度が1ヶ月に1回くらいの画面ですし、しばらくは絞り込みが必要なほどデータが登録されないですよね。
ユーザがどういう絞り込みをしたいか観察することにして、フリーワード絞り込み機能は最初のリリースでは実装しないのはどうでしょう。」
このような提案と議論がダラダラと続くと逆に作ってしまったほうが早くなるリスクもありますが、CPOの渡瀬(@wataset)が即断即決してくれるので、テンポ良く要件がシャープになっていきます。
もちろんエンジニアの提案がすべて採用されるわけではなく、「ユーザがこう使うことを想定してるから残す」と削らないパターンや、「無くすとユーザに優しくないからこういう機能にして実装しておこう」と折衷案のようなパターンも多くあります。
細かな要件の精査の結果、ユーザフレンドリーかつ最小限の機能に到達し、多くのリリースを実現しています。
気をつけること
仕様の引き算を提案するときは前提や仮説を丁寧に説明したほうが良いです。
「要らなくないですか？今は作らないほうがいいですよ。」
だけでは、ただのめんどくさがりな人として受けとられ、PdMもやりにくくなると思います。
要件の背景となる専門知識、業務知識、ユースケースを理解/把握することが大事です。それらが無いと、PdMに余計な説明コストを払わせているだけになります。前述した提案内容には「登録頻度」の想定がベースとなり提案されていましたよね。
仕様の背景となった情報をエンジニアが理解することが、建設的な議論のスタートラインだと思います。
最小限な機能をリリースして終わりではない
機能をリリースしてプレスも打ちました！完了！次はあれを作ろう！
では間違いなくユーザは離れていってしまいます。
アスエネでは仕様を最小化するときには「最初のリリースでは」という部分を強調しています。
アジャイル開発界隈で有名な画像を紹介します。新商品開発において上段がの悪い例、下段が良い例とされています。
上段は「こういう車が欲しいのだろう」という大きな仮説をもとに時間をかけて車を完成させています。
下段ではユーザの反応を見つつ少しずつ改良していき、最終的に車にたどり着いています。この絵ではユーザは最終的にスポーツカーが欲しかったようで、下段のほうがユーザ満足度が高くなることを表現しています。また、ユーザの欲しい物が実は自転車だった場合も下段では対応可能になります。
我々もユーザヒアリングやログを通して、ユーザにとって本当に価値があるものを届けるための機能進化を続けています。
さいごに
ここまで読んでいただきありがとうございます。
お察しの方はいるかと思いますが、特に独自性のあることはしていません。
昨今のプロダクト開発の手法としては当たり前になってきたことを実践しているだけです。
ただ、アスエネは「当たり前のことを当たり前にやる/できる」会社であることが伝わると嬉しいです。
アスエネでは「次世代によりよい世界を」つくるため仲間を募集中です。
まずはカジュアルにお話しましょう！
私の社員紹介の記事もぜひご覧ください。
この記事が気に入ったらサポートをしてみませんか？