行動すれば次の現実

ほどよくモダンなシステム開発を目指しています。メインテーマは生産性、Ruby、Javascriptです。

実装しない勇気

私はWebサービス(SaaS)を開発・保守しています。

サービス開発をしているとついつい「あの機能も必要かな?この考慮も必要かな?」と考えを巡らせます。 実装が終わってみると予定よりも多くの機能が出来上がり、大きな満足感を得ることが出来ます。

しかし、その機能は本当に必要だったのでしょうか。

そのような経緯で生まれた機能は、実際に開発して運用してみると使わなくなることが往々にしてあります。

私もこのような経験を数多くしてきました。 このような自体に陥らないために、実装するかどうかの私なりの判断基準を解説したいと思います。

サービス開発・保守を担当している方はぜひ一つの参考にしてください。

実装するのは誰でもできる

実装するという選択を安易に選んではいけません。

なぜなら「実装する」ということは、その機能を責任持って保守をし続けると確約することだからです。 (安易にペットを飼ってはいけないという感覚に近いと感じます)

筆者は「実装する」と選択するよりも、「実装しない」と選択するほうが難しいと感じます。

機能を実装する(作る)かどうかを判断する上で以下のカテゴリに分類されます。

  1. 作る必要がある機能
  2. 作る必要がない機能
  3. 作ったほうが良い機能

この内「3. 作ったほうが良い機能」を「作る」という選択を安易にしてしまうのは非常に危険です。 なぜならそのような機能を実装する理由が実装者の思い込みによるところが大きいためです。

この機能があったほうが便利だろう、という理由は実装者の感覚でしかなく何も根拠がないからです。 この機能は絶対使われると確信できないのであれば、いっそのこと作らないと選択したほうが良いです。

作ったが使われなかった場合、その作業に費やした工数。今後その機能をメンテナンスしなければならない工数は全て無駄になってしまいます。

それでも作るのであればそれは実装者のエゴか、保身としての選択になります。 ある意味「逃げの選択」と言い換えることもできます。

※ ただし、新育のためにあえて無駄な機能を作る(作らせる)のはありだと思います。教育という明確な目的があるためです。

実装しないという選択

では、どうすればよいかというと「作る必要がある機能」のみ作れば良いです。

「作る必要がある機能」のみを搭載した最低限の状態(MVP Minimum Viable Product)で顧客に使用してもらい、本当に必要な機能を見極めてもらいます。これはMVP戦略と呼ばれています。

MVPを使用した上で、顧客から意見をフィードバックしてもらいます。そのフィードバックから生まれた機能は「作る必要がある機能」として確信をもって実装することが出来ます。

この時、前提として「作ったほうが良い機能」については、初期開発では無駄な機能は開発しない旨をあらかじめ顧客に提案して合意もらっておく必要があります。

合意をもらうというアクションは極めて重要です。これをしなければ、なぜ作ってもらえないのかと顧客から反発を受ける可能性があるためです。

実装を捨てる勇気

すでに実装してしまった場合は最後まで責任持って保守し続けるしかないのか、というとそうではありません。 根拠を持って実装を捨てれば良いです。

いきなり捨てるのではなく、以下のようなアクションを経て捨てる根拠を見出します。

  1. 顧客からその機能を使っているかヒアリングする
  2. GoogleTagManagerやサーバーログからその機能の使用数を測定する
  3. ABテストでその機能を一時的に塞いで反響を見る

これらのいずれかの方法で捨てても良い根拠を見出だせたらその機能を捨てることが可能となります。