お客さまへの製品リリースが頻繁には行えない状況でのMVP（Minimum Viable Product）は、どうしても機能を盛ってしまうことになりがちと感じています。そんななか、チームにJoinして2、3年の若者二人による、ある機能開発で何を作るか？の検討会がありました。「それを落としてきたかー」「そこをそう変えてきたかー」と思うような提案をしてきて、わたしたち（開発者）よりもお客さまに近い立ち位置の人も混ざっていたので、内心ハラハラしましたが、話し合いの結果「まずはそれでやってみよう」となり、へーー、ここまで削っていいのかーーーと、たいへん勉強になりました。
製品としての「ちょうどいい」を見つけたいとき「少なすぎるくらいの内容で提案する」というのは言葉としては知っていますが（冒頭にも書きましたが、製品リリースやアップデートが頻繁には行えない状況で）本当にそんな提案をするのは難しいです。
少なすぎるくらいの内容で検討をはじめ、話し合いの中で「これは絶対落とせない」となれば真のMVPなので追加すればよい。それはそうだと思います。一方でスレスレMVPかそうでないかくらいの微妙なライン上にいる仕様を「削っていいんじゃない？」とは言いづらい。あったら便利だし、お客さまにも喜んでもらえるのでは・・・なんて思ってしまう。あった方が良いものと、絶対にないと成立しないものを選択する過程と分かっていても、その取捨選択は難しいです。少なくともわたしには。
今回うまくいった要因を考えてみました。
- 落とした仕様も議題にあげて、削った理由（自分たちなりの考え）を話した
- 当初想定していたものから大幅に変更した仕様も同様
- 検討会の前にエース級たちに相談して相当勉強して考え尽くしている（言葉の端々からわかる）
- 二人が想定してない使い方を指摘されたときも、それがないと本当に製品として成り立たないのかどうかの視点を最後まで持ち続けた*1
- 似たような既存機能でその仕様は搭載していないが、それはどう説明しますか？と良い問いかけができた（他の機能もよく知っていないとその場ですぐにこんな返しはできません）
- 作りはじめてからやっぱりここはどうしてもだめだね（お客さまが困る）となったら、そのときはもちろん検討して対応します、と始めに宣言した
言葉にすると普通なんだけど、当たり前のことが当たり前にできてすごいなと思います。
そうそう、検討会自体の進め方のアドバイスをプロの無職にもらっていて、それを素直にきいてやったのもうまくいった要因かもしれません。
- 議事録を先に書く（普通は検討会のあとに議事録を書きますが、先に議事録を書いてしまうアイデアです。検討会は議事録を見ながらやります。こんなへんてこりんなやり方、よく思いつくよな…）*2
- 時間切れになったらこの仕様でいきます！で始める（より重要なことから話そうとみんなが意識する。どうでもいい話は自然に抑制される。集中すべきことに集中できる）
検討会のあと、事務所に戻って若干興奮気味に具体的にどこが良かったか、素晴らしいと思ったか、二人からわたしが学んだことをそれぞれに伝えました。
わたしたちの製品はいったんリリースしてしまうと、あとから仕様を変更したり削除するのは簡単にはできません。入れてしまった仕様はこの先何十年も気にし続けながら開発／テストしなくてはならないのです。未来のコストも考えたら本当に素晴らしい提案だったと思います。
わたしが熱心に褒めるので気持ち悪くなってしまったのか「でもこれに集中してできるのも他の人たちの助けがあってのことで、チームでやってることなので…」と恥ずかしそうに言うので「そういう風に思えるところも素晴らしいよ」って伝えました。
