KNOWLEDGE
KNOWLEDGE

こんまりメソッドをサービス開発で使ったら|トキメキで判断する機能の断捨離術

片付け、断捨離と言えば知らない人はいない、「こんまり」こと近藤麻理恵さん。
こんまりメソッドで使われる「ときめき」は、日本のみならず世界にも受け入れられましたね!

…さて、今宵はサービスの世界。現実世界では断捨離が得意な方でも、サービスの世界ではどうでしょう。
みなさん断捨離できてますか?
そんな方にこそこんまりメソッドはピッタリ。ときめく機能の整理術で断捨離してみましょう。

サービスが機能であふれること、あるよね!

1サービス1目的

サービス開発において基本原則となるこの考え方は、今でも大前提として扱われています。理由は単純で目的の数だけサービスが複雑になるからです。

では実際世の中に出ているサービスはどうでしょうか?おそらくそのほとんどが、目的を複数持った「多機能/多目的サービス」です。

もちろんしょうがない部分もあります。
ビジネスをやっている以上その機能はどうしても入れる必要がある。
顧客シナジーを考えたら分散させるより機能集約させたほうが良い。などなど。

ただ、しょうがないに紛れて、「それ本当に必要?必要だとしても今?その仕様?」な機能が足されていくのもまた事実。

そうして膨れ上がったサービス。改めて整理すると「いらないかも…」な機能がズラリ。
長年運用していたサービスだと、「ずっとあった機能だからなくすのが怖い」「無いよりはある方がマシ、もったいない」、情が生まれてしまいます。

蓮舫ばりの「その機能必要ですか!!!」
をかましてしまったからにはチームのココロは閉ざされるばかり…

そんな時、役立つ断捨離術が「こんまりメソッド」です!

本質の幸せを考える断捨離術|こんまりメソッド

今は不要に思えるその機能。でも作った当時は何かの課題があって、その解決策として考えられた、想いが詰まったモノかもしれない。
そんな機能に感謝を伝えながらも、本質を見極め今を最適化する断捨離を行っていきましょう。

いつか使うは一生使わない

その機能がなぜ必要なのかを改めて整理しましょう。整理方法としては機能をシートに一覧化、使用可否を洗い出します。使用可否は以下選択肢がおすすめです。

  • 使ってるし、これがないと事業が成り立たない
  • 使ってるが、事業への影響はわからない
  • 使っているかわからない
  • 使っていない

整理のポイントとしては「必要かどうか」ではなく「使われているかどうか」の事実ベースで見ることです。自分で分析するのであれば問題ないですが、ヒアリングの場合必要かで聞くと不要な機能に対しても「必要かもしれない」の判断をしてしまうためです。

「使ってるし、これがないと事業が成り立たない」機能に関しては残します。
ではそれ以外の機能はどうか。事業への影響が無いとわかったら要らない機能です。いつか役立つは一生役立ちません。

…なんて言ってもすぐに断舎離する判断はできないですよね。そこで、魔法のコトバの登場です!

その機能で誰がときめきますか?

断捨離までもう一歩、ここで使うのが「ときめき」の観点です!

何かの仮説を元に検討された機能たち。その機能が今この時点で、誰の役に立っているのか、何を幸せにしているのか、問うてみましょう。論理構築だけでは打破できない感情に対する最適解。根拠はデータでも現場の意見でもユーザーの声でも構いません。

もしそれが一部の熱狂的ファンには必要な、「サーティワンアイスクリームの大納言あずき」的なものであれば残すべきですし、問うて明確な答えが出せなければ、だれにも必要とされていない機能なのです。

「その機能は誰の何をときめかせているのか?」

この本質を常に考え、正しい選択をすることが大切です。

こんまりメソッド活用事例

ここまでこんまりメソッドを使った機能の断捨離方法をご紹介しましたが、「どうやって実務で使うの?」と疑問が残ったままですので、実例をご紹介しましょう。

話はとあるサービスのリニューアルプロジェクトに移ります…


「全部必要みたいでして」

ユーザーヒアリングを任せたチームメンバーからの共有でした。

実はこのヒアリング、「聞いた結果から課題を抽出し最適解を導く」ことが目的。
しかし聞き方を誤っていて、「この機能は必要だと思いますか?」と誘導尋問的になっていたのです。

そう聞かれてしまうとユーザーは、「年に数回ですけど使うことはありますね。なくす事はできないのでその機能取っておいてもらえると嬉しいです。」
なんて答えますし、こちらとしても「じゃあ必要なんだ」と整理してしまいます。

結果どうなったかと言うと、ヒアリングの結果9割の機能が「必要」と判断されてしまったのです。

欲していたのはその機能…?

実は私自身、ヒアリングの前からある程度の機能が不要なのでは?と考えていました。
本来Aが最適なのに、B,Cと経由が必要だったり。

ただ機能を移すのではなく、何を解決したくてこの機能があるのか、それが本当の理想なのか、改めてヒアリングを行いました。

私:「前回こちらの機能が必要かもとのことでしたが、そもそもなぜこの機能が必要なのですか?」

ユ:「実はこの作業をする時に使うことがありまして。何回も作業を繰り返すのは面倒ですが、慣れもあって…」

私:「なるほど。では例えばの話ですが、これがこんな感じでカンタンに1回でできるとするなら、どうですか?(プロトタイプ見せ見せ)」

ユ:「お〜、こんな方法できるんですね!イメージできてなかっただけで違う手段はあるかもですね!」

私:「あと、ついでに言うと、いつも使ってるこの機能で代替できちゃうので、そもそも代替手段が適切に案内されるならこの機能要らないかも?シンプルで使いやすくなりますね!」

ユ:「確かに…たしかに!」

私:ときめきますね!

…ニヤリ、読み通りです。

結局ユーザーは「その機能自体が必要」と思っていたのではなく、「その体験が不便になるかもしれない不安」なだけで、機能を移すことが根本の解決策ではありませんでした。

そんなこんなでヒアリングし直した結果、半分近くの機能を簡素化、削除できたのです!

論理の先にある感情をも最適化する

ここまでの話をまとめるとこの一言に集約されると思っています。

事実のみならず情に対しても何が本質で最適解かを導く。デザインにおいて必要な思考/整理法なのですが、「断捨離考えてる時とデザイン考える時何か似てる?」から着想を得て実践してみました。

ぜひみなさんも明日からこんまりメソッドを使った機能整理術を実践してみてください!

その機能は誰の何をときめかせていますか?

事業/組織開発
アメリカ/ボストン生まれ。新卒のナビタイムジャパンでフロント/サーバーサイドエンジニアを経験後、グッドパッチでプロジェクトマネージャー、UXデザイナー、マーケティングを担当。2019年セブンデックスに入社。事業・組織開発として、マーケティング、プロジェクトグロースに従事。SalesfoceなどCRMを活用した事業支援を行なっている。