#あすみかんの上にあすみかん

#たのしいことしかかかないことをここに決意します

PJで「最少市場化可能機能セット」を握って最少単位でリリースしよう

ごきげんよう、あすみです! これはNE Advent Calendar 2022の22日目の記事です! 昨日書いた記事、社内の人から良かった〜と数人から言われて嬉しかったです🙌 実際にフィードバック貰えるのは嬉しいですね!

まだ読んでない方はどうぞ!

asumikam.com

さて、今日も今日とて読んだ本の紹介をしたいと思います! 本日は「レガシーコードからの脱却」という本の紹介をしていきたいと思います。 300ページの本で、プログラミングにおける重要概念から実際のプロダクト開発の手法の記述まで幅広く取り扱っているため、サクッと1日で読む、という感じではなく、1日1〜2章ずつじっくり読んでいきました。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

どんな本?

既にあるレガシーコードから脱却するためのハウツー本・・・という訳ではなく、レガシーコードを書かない様な"開発文化"を作ろうね、そのハウツーはこんなだよ、といっている本に思えました。 一部、基本的なプログラミングの原則に触れつつ(単一責任の原則、オープンクローズドの原則)、大半はアジャイル開発のススメ(とりわけスクラム開発、ちょっとXPのハナシ)をしている感じ。

私はこの本の前にSCRUM BOOT CAMP THE BOOK を読んでスクラム開発とはこんなものだよ〜という入門を済ませていたこともあり、その知識を呼び起こしながら「なぜこの方法がいいのか?」の肉付けをする感覚で読み進めました。 (そのため、アジャイル開発の文脈の記憶が色濃く残っているのもあるのかも。)

余談ですが、去年のアドベントカレンダーにてSOLID原則について触れている記事があるので、是非ご一緒にどうぞ。

asumikam.com

この本のスキな部分

最少市場化可能機能セット(MMF)という概念

ソフトウェアではスコープはとても柔軟だ。開発者は間違ったものを作ったり、正しいものを作りすぎたりすることが多い。私たちが最初に見るべきはスコープを柔軟にするところだ。最少市場化可能機能セット(MMF)、ストーリーの分割などのテクニックを使ってスコープを決定する方法を理解すれば、適切なサイズの機能セットを決定するのに役立つ。

(第6章 小さなバッチを作る)


バックログは基本的に、作りたいと思っているストーリーのリストだ。機能(ストーリー)をさまざまな方法で整理する。(中略)リリースできるように機能を集めていくことが求められる。これのことを最少市場化可能機能セット(MMF)と呼び、プロダクトが生き残って役立つものであるためにリリースで絶対必要なものを教えてくれる。

(第6章 小さなバッチを作る)

私はこの本の中で6章が一番好きなのですが、その理由が、MMFという概念との出会いでした。 「Minimam Marketable Features」の略で「絶対必要な」「機能」を定義して、その単位でリリースしていきましょう、という概念です。

「開発者は間違ったものを作ったり」「正しいものを作りすぎたり」する。 .... その通りすぎる。いままでの人生で経験がありすぎますね😮‍💨 使ってもらわないとマジで意味がないのに、作り込み過ぎてしまうんです。ユーザの声を聞いてもないのに「これはあったらユーザ喜ぶっしょ」ってどんどんやることリストが増えすぎるんです。そして遅れるリリース予定日・・・。

そうならないために、PJメンバー(エンジニアに限らず、営業やマーケ、CSも含め)とMMFを握る。「ユーザーにいち早く価値を提供したいので、最少機能でリリースするとしたらなんでしょうかね?」の軸で話すということ。 この気持ちをPJメンバーに伝え、一緒に話していくのめっちゃ良いなと。そして、すぐに実践しました(やってみて思ったことなどの体験記は後述)。

ただ、前提として「ユーザーにいち早く価値を提供したいので」の部分からPJメンバー全員の方向性を合わせておく必要がある、とも思いました。 そして私気づいちゃった、アジャイルにおけるインセプションデッキの1つ「トレードオフスライダー」がピッタリということに(バビュン)(効果音) インセプションデッキ自体、割と「意識を合わせる」において使い勝手が良いので「私たちはなぜ、ここにいるのか?」「エレベーターピッチ」などは何かしらのキックオフやアイスブレイクとして使ったことがあったのですが、「ああ、これやらなきゃな」とガチっとハマったのでマジで気持ちよかった。

ここで「いやいや、価値提供より、最初から完璧な機能を提供するのがこのPJのミッションだよ」となれば、ちょっと話は変わってくるので、そこの部分からPJメンバーとPJの方向性を合わせておくのはマジで大事っすね。

ところで、MVP(Minimam Variable Product)と何が違うの?

Is there a Difference Between MVP and MMF?

多分、大事なことは全部ここに書いてあるのですが、、、、、、自分なりの解釈を書いておくと、 両者の違いはフォーカスしている部分だと思っていて、プロダクトにフォーカスしているのはMVP、機能にフォーカスしているのはMMF、といった理解です。

MVPの文脈では、わりと検証がセットになっていることが多いかな、と個人的に思っております。 最小限の機能をリリースしてみて検証、そしてまた最小限の機能をリリースしてみて検証、...そうやって価値のある"プロダクト"を作りましょうという話。 で、じゃあここの「最小限の機能とは!?」と議論する部分がMMFなんじゃないかなーと思っています。

MVPの方が、最終的な着地点が"サービス"に近いイメージ、より大きいイメージ。 MMFの方は、最終的な着地点が"機能"。サービスの中に含まれる提供物なイメージ。

・・・な、イメージなのですが、実際のところ細けぇこたぁわからないです。結局やりやすくて良い感じ〜にPJが進められるのはどっち!?でしっくりきた方でいいと思ってます。(私はMMFがとてもしっくりきた。)

しっくりきたので、実際に「MMF」をPJに取り入れてみた

どのように?

前準備:トレードオフスライダー

前述で触れた様に、まずは「トレードオフスライダー」でPJの意思を決定しました。

トレードオフスライダーの一部

Miroを使って、1人1星与えて自分の気持ちをスライダーに表す→微妙な違いについて議論して「この辺だよね」の感覚を全員で合わせる(透けてるデカ白星)、という方法で進めました。

話してみてわかったのですが、見て分かる様に、細かな個人の思想は違うものの、基本的な路線は全員一緒だったのでかなりスムーズにいった方なんだろうな、と思います。

ただ、これが明示的にあることで、話し合いの際などに「このPJの意思としてはこっちなので〜」と話せる指標になるのでめちゃくちゃ良いものだと思います。

本チャン:MMF

まずは、考えられる機能やユースケースを洗い出した上で、

全員で機能やユースケースを発散させる

MMFMMF+α・MMF+α+α・今じゃない、を一人一人考えました。

MMFMMF+α・MMF+α+α・今じゃない

MMFはファーストリリース、その後にセカンドリリース・サードリリースと続きますが、「今じゃない」も用意して、このPJのスコープ外、ユーザからの反応がよくさらに機能開発が必要になった段階でやるようなものだ、という機能を置くスペースも用意しました。

そして、議論し、それぞれの機能をいつリリースするかを決めました。

全員の意思が揃ったMMFたち

よかった点

前提のトレードオフスライダーで「最速最少価値提供リリース」の合意ができていたので、大事にする部分の共通価値観を軸に本当に必要な機能について話し合えたのでめちゃくちゃ会話が建設的でした。

うちのPJでいうと、「並び替えの実装」はMMFには入らなかった、という例があります。 他の機能で「並び替え機能」があるので機能の洗い出しの時点では挙がっていたのですが、「最少」という軸に照らし合わせた時に、MMFで定義された他の機能を使えば、疑似的に「並び替え」が実現できる、だからMMFではない、と意思決定した場面がありました。これは「最少価値で提供する」の体現だなぁと感じています。 (もちろん場面により「並び替えの実装」がMMFに入ることもあると思います。あくまでうちのPJのハナシ)

これのおかげで「これも大事だしあれも大事だなあ・・・優先度どうしようかなあ・・・」と悩むところは少なかった様に思えます。 ただ、それでも意見が割れちゃう時はあって、これは決めの問題だなーってところはPJのルールとして最終的には「より、ユーザーに近い人の意見を採用する( = セールスやCS)」でやりました。

改善しようと思った点

これ、割とマジで時間かかるんです。時間をかける部分ではあるのですが、ここに時間をかけ過ぎてもリリース日が遠のくだけなので、ある程度「決め」でいく必要がありますね、、。

一番失敗したのはMMFMMF+α、MMF+α+αを、初期の段階で割と解像度高く決めたことです。 「この機能は+αで、あの機能は+α+αだね」というところまで初期で決めてました。 時間がかかる上に、ファーストリリース後に「やっぱこれ重要機能じゃね?」ってなること普通にあるなと、、、最初はMMFだけでよかったなと思ってます。

次やる時は、MMFは解像度高くきめて、MMF+α、MMF+α+αはだいぶ解像度低く決める、で行きます。

まとめ

実際に読んだ時に「これやりたいなー」と思ったのを取り入れやすかった状況ということもあり、この本から、アジャイル開発・スクラム開発の部分にて知識・やり方をだいぶ吸収しました。 ブログではだいぶそこに触れましたが、本書のタイトル通り「レガシーコードをリファクタリングする方法」や「テストコードの重要性」にも触れており、本当に幅広く大事なことが書いてあるので、おすすめです〜