なかなかに開発者の印象に残る出来事だったのではないでしょうか。
ユーザーに便利さを提供するつもりで機能を闇雲に増やしても、それが逆に操作をわかりづらくしてしまったり、サービスの本質を見えなくしてしまったりしてしまっては、本末転倒です。第6回でドロワーメニューを利用することで「機能をそぎ落としてアプリを磨く」あるいは「使い勝手をとことん追求する」という努力をサボれてしまうという問題に触れましたが、機能の追加についても同様のことが言えると思います。なぜなら、機能を追加することよってユーザーに新しい価値を提供できていると錯覚してしまい、ついつい「自分たちがいいものを提供できている」という満足感を得られてしまいやすいからです。これは、参考書を買ってきたり、勉強の計画を立てただけで勉強をしてしまった気になっているのと似ているかもしれません。
新しい機能は魅力的なのか？
我々サービス提供者は、いわばそのサービスやアプリケーションを最もよく使っているユーザーの1人でもあります。毎日そのサービス、アプリをどうすればより良いものにできるかを考えていますし、そうあるべきです。マイクロソフトで生まれたとされるEat your own dogfood（人に勧める前に、自分で食べてみなさい）という有名な言葉がありますが、もし開発者であるあなた自身がヘビーユーザーでないなら、それはあまり良いことではないと思います。
一方で、ヘビーユーザーであり、毎日それについて考え、そのサービスやアプリの機能を隅々まで知っているからこそ、陥りやすい罠があるとも思っています。それは、「新しい機能がより魅力的に見えてしまう」というものです。新しい、まだ自分が得られていない機能をつけることが、そのサービスやアプリの価値をすごく上げるように思えてしまうのです。なぜなら、既存の機能のことを隅から隅まで知っているからです。多少使いづらくても、裏側まで知っているので、問題を回避することはかんたんです。今ある機能でできることには別段の新しさはないですし、特に困ってもいないかもしれません。そういう立場から、「じゃあ、サービスやアプリの価値を上げるためにできることはなんだろうか？」と考えると、「新しい機能をつける」というアイデアが頭をもたげてくる可能性は非常に高くなります。
特に開発者である我々には、新しいものが好きな人が多い気がします。少なくとも、筆者は好きです。サービスに新しい機能が加わることで、そのサービスの可能性がさらに広がって、より魅力的になるような気がしてしまうのは、我々開発者の性というか、ある程度はしかたのないことかもしれません。
しかし、すでに述べたように、そうやってどんどん新しい機能を追加していくと、どんどんとサービスが複雑化していってしまいます。そうなってくると、初めてそのサービスやアプリを使い始めた人には、いったいどんな機能があるのか、それらをどうやって使えばいいのかがどんどんわかりづらくなってきます。しかも、開発者であるあなたは隅から隅まで機能を知っているので、複雑すぎて使いづらくなってもなかなか気づけないかもしれません。
ユーザーの要望を聞きすぎない
機能を増やしてしまうもう1つの要因に、ユーザーから寄せられる改善要望があります。ユーザーから寄せられる要望は、時にこれまで自分たちになかった新しい視点をもたらしてくれるものです。そもそも、自分たちががんばって作ったサービスを使ってくれるユーザーの存在はとてもありがたく、ユーザーの希望はぜひともかなえてあげたくなるのが人情というものです。
だからといって、寄せられる要望すべてをかなえようとするのは、大きな問題です。なぜなら、「それぞれ要望が、はたしてその要望をくれたユーザー以外にも便利であるかどうか？」はわからないからです。
Excelぐらい大きなプロジェクトになれば、1万人に1人しか使わない機能をつけてもいいかもしれません。しかし、一般的なサービスでは、ごくわずかな人しか使わない機能にかける時間はないはずです。
また、「たしかに、あると便利だ」といえる機能の要望であっても、ホイホイと実装してしまうのは危険です。たとえ「あると便利」な機能であっても、無計画にたくさん積み重ねていくことで、使いづらいサービスができあがるのは、ここまで考えてきたとおりです。よくよく吟味して「ないと困る」機能でなければ、実装はいったん考えなおしたほうがいいかもしれません。
スマホUI考（番外編）顧客やユーザーの要望に全て対応すると、アプリは99%破綻するという記事では、「Twitterを日本の大手メーカーが買収したらどうなるか？」という想像をもとに、TwitterのiOSクライアントがどんどんと糞アプリへと変容を遂げていく様が描かれています。これは、本当にいろいろなアプリで起こっていることだと思います。
たしかに、ユーザーの意見は非常に貴重ではありますが、それはそのまま鵜呑みにするために利用するのではなく、「その意見の背景に何があり、どうすれば要望をくれたユーザーを満足させられるか？」を深く考え、よりシンプルに、なるべく機能を増やさない形で調整していくのがいいのでしょう。
一度つけた機能を削るのは大変
新しい機能を追加することの問題は、ほかにもあります。「あとからその機能を削除するのはとても大変」ということです。なぜかというと、たとえ開発者がその機能は不要だと考えていたとしても、一部のユーザーはそう考えていない可能性があり、削除した際にネガティブな評判が立ってしまう危険性があるからです。
もちろん、ネガティブな評判が上がることを承知のうえで、覚悟を持って機能を削ることは意味のあることだとは思います。しかし、不用意につけた機能を削る際に多くの心労を抱えるのは、精神衛生上あまりよいものではありませんし、機能をどんどん追加してはどんどん削るような運用体制では、「便利だと思った機能がバージョンアップで消えてしまうかもしれない」という印象をユーザーに与え、今はまだ機能の削除の影響を受けていないユーザーをも失ってしまう危険性があるでしょう。
MacにはiWorksというソフトウエアがありますが、2013年のバージョンアップの際に、旧バージョンにあった機能がいろいろとなくなりました。Appleは「単に不要だから削ったのではなく、一から書き直したために起こったことだ」と発表しましたが、ユーザーから不満の声が上がり、その機能を一部復活するという発表をすることになってしまいました。
機能を「ないと困る」と「あったら便利」に分けて考える
そもそも、サービスを開発する際の開発リソース（開発者の数とか、時間とか）は限られているわけですから、機能が多くなってくれば個々の機能に手をかけられる時間も削られていきます。機能が増えるときにかかる手間は、その機能を最初に開発するときだけにかかるものではありません。維持にも当然手間がかかります。ほかの機能を追加した時、既存の機能のなにか重要な部分に手を入れた時、それがほかの機能と結びついていて、そちらにも手を加えないと整合性がとれなくなる、なんてことも十分に考えられます。
手をかけられる時間が減るということは、その機能を洗練する時間も少なくなるということですから、たくさん機能を追加していくと、「なんだかいろいろな機能はあるけれど、どの機能も中途半端で使いづらい、よくわからないサービス」がいともかんたんにできあがることは、容易に想像できます。そして、「多機能だけど、洗練されていないサービス」と「機能は少ないけれど、よく練りこまれたサービス」ではどちらがよりユーザーにとって利益をもたらすのかは、言うまでもないことです。
どんなサービスにも、解決したい一番重要な課題、あるいはコアとなる最も重要な機能があるはずです。その機能にリソースを集中させて、その機能のユーザーにとっての使いやすさ、使い心地の良さを追求することは、結局のところ「使いやすい素敵なサービス」を作るための最短経路であるように思います。
筆者はいろいろなスタートアップで創業期の開発の手伝いをすることが多いのですが、1つ1つの機能が本当に必要なのかを、プロダクトオーナー（多くはCEOや社長）とよく話すようにしています。その際に言うのが、機能を「ないと困る」と「あったら便利」に分けて、「あったら便利」な機能はいったん開発をやめる、というものです。スタートアップの初期は、開発者も少ないですし、開発の速度には限界がある一方で、プロダクトオーナーの気持ちは非常に前のめりになっているので、どんどんと新しい機能の提案をされたりします。その気持はすごくわかるし、やりたいことをいろいろと実現してあげたいのも事実ですが、まずはコアとなる「解決したい課題」の解決に集中したほうが、結果としていいものができるのではないかと思っているからです。
外部のサービスで使えるものは最大限使う
最近では、単機能に特化したサービスをAPIとともに公開し、ほかのサービスと組み合わせて使うことで価値を見出す、というスタンスのサービスも増えています。たとえば、電話やSMSなどをAPI経由で操作可能なTwilioは、電話をかける・受けるといったことに特化していて、ほかのサービスからSMS経由での電話番号認証に使ったり、サポート電話の自動応答システムを作ったりできます。かつてはRead It Lator（あとで読む）というそのままの名前であった、Pocketも、ブックマークの機能に特化しています。こうした単機能のサービスは、その機能に磨きを上げ、使いやすさに注目しているように思います。
また、Pocketのようなサービスは、同じような機能を自分たちで開発しそうになった時、代わりに使うことでそこに割くリソースを削減できるものとして、極めて重要です。たとえば、最近では「キュレーションメディア」などと呼ばれている情報系のサービスが流行っていますが、そういったサービスのモバイルアプリケーションにクリップ機能、つまり気に入った記事を保存しておけるブックマーク機能が付いているケースがあります。しかし、Pocketを愛用している筆者としては、いつ使わなくなるかもわからないアプリに情報を保存することにはあまり価値を感じず、Pocketやはてなブックマークに保存できるほうがよっぽどありがたいのが事実です。なので「ログインするとクリップなどの便利な機能が使えます！」などと言われても、まったく心にグッときません。もちろん、それは人によるもので、だれもがそうしたブックマークサービスを使っているわけではありませんし、ログインをさせることでさまざまな情報が取れるわけですから戦略としてわからなくもありません。でも、わざわざクリップの機能を作るより、外部サービスに流したほうがはるかに工数が少ないでしょうし、ユーザーとしてもいつも使っているブックマークに入れられたほうがありがたいはずですから、サービスの性格によっては外部サービスに流すほうがメリットがあるのではないかと思います。
特にサービス開発の初期では、クリップ機能のような「あったら便利」な機能はまずは自分たちで開発したりせず、外部のサービスで使えるものは最大限使い、もっと重要な「ないと困る」機能に目を向けるべきです。
Excelのマネをしてはいけない
さて、「めちゃくちゃ高機能なアプリケーション」というと、多くの人にはマイクロソフト社のExcelがまず頭に浮かぶのではないでしょうか。開発者なら、Excelの使い方の質問をされてイラッとした経験が一度はあるはずです。「Excelはくわしくないから、操作方法がわからない」と答えると「あんなに毎日パソコンいじってるのに？」などと言われたりします。たしかに、自分たちは日がな1日PCの前で作業していることも多いわけですが、それでもExcelの使い方がまったくわからないのは、Excelが高機能すぎてやりたいことをどうやればいいのか、あるいはそもそもどんな機能が備わっているのかすらわからないからです。しかも、Excelで複雑な処理をするくらいなら、スクリプトを書いて解決してしまったほうがかんたんだったりしますしね。
そんな高機能なExcelではありますが、とはいえ、だれでも基本的な機能はなんとか使えるようになっているのはすごいことです。それを実現するために、マイクロソフトはExcelの開発に優秀な技術者をたくさんつぎ込んでいます。しかもExcelは、Wikipediaの記述によれば1985年9月にMacintosh版が発売されたとありますから、すでに30年の歴史を持っています。これだけの時間と開発リソースがあれば、こうした超特大級のソフトウエアを作ることも可能かもしれません。ただ、その結果、「すごく使いやすい」ものができるとは限りません。
Excelは、すでにユーザーに受け入れられ、世の中の標準のアプリケーションになっているからこそ、多少使いづらくても、みんなお金を払ってでも勉強して使いこなしてくれようとします。しかし、まだ無名のサービスに、限られた時間、少ないリソースで多くの機能を突っ込もうとすれば、それはもうだれにも理解できない、理解しようとすらしてもらえないものになってしまう可能性が非常に高いでしょう。サービスをシンプルにするということには、少ないリソースを集中させるというほかに、「単純明快でわかりやすいものにする」というメリットも含まれていると言えます。
多くのサービスには、「管理画面」と呼ばれる、サービス運営側が使う機能が必要です。サービスを開発する際にそうした管理画面を作っていると、運用を行う人たちから「Excelより不便」「Excelでできるこんな操作が同じようにできるようにしてほしい」といった要望が出てくる場合があります。そういうときに、開発者は「それは開発がすごく面倒だし、時間をかけるだけの意味ないから、そんなにExcelが良ければExcel使ってよ」って思ったりします。
そうした場合、要望を出した人には開発にかかる工数などに関する知識があまりない場合が多く、素直に自分の要望を伝えているだけなので、費用対効果を説明して納得してもらうのも1つの手です。また、Excelデータをインポート／エクスポートする機能をつけて、「あとはExcelでご自由にどうぞ」とやるのが一番手っ取り早いケースも多くあるように思います。多くの言語ではExcelのファイルを読み書きするライブラリが公開されており、それを利用することで、そうしたインポート／エクスポートの機能が比較的かんたんに作ることができます。そうした機能を実装することでも、外部のサービスとの連携で省力化する工夫の1つといえると思います。
“機能を増やしたい病”に注意
今回は、機能追加と使い勝手について考えてみました。繰り返しになりますが、一般的に、開発者は新機能を開発するのが好きです。なぜなら、楽しいからです。原因のサッパリわからない根の深いバグを修正するより、手間のかかるわりに違いのわかりにくい性能の向上に手をかけるより、創造的でやりがいがあって、結果もはっきり見えるからです。だから、開発者は同時に複数のタスクが割り当てられている場合、新機能の開発を先にやってしまう可能性が高いのです。
そのため、タスクの優先順位をきちんとつけ、「できるだけ機能を増やさない」という意識のすり合わせをきちんとやっておかなかった場合、あるいはサービスのディレクション自体を開発者がやっている場合、新機能の開発が優先して行われてしまうことがままあります。その結果、「あったら便利」な機能がサービスに次々と追加されてしまい、全体としてなんだかよくわからないものになってしまったりするんですよね。
もちろん、「面白そうなもの」「興味のあるもの」を開発するのは開発者のモチベーションとしては重要です。しかし、「新しい機能を実装したい欲」が心のなかに沸き起こった場合、一度冷静になってサービス全体を考えて、「それ、本当に一番大事なんだっけ？」といろいろな角度から考えていく必要があります。
以前、筆者が見たことのあるケースとしては（筆者が所属していたチームではなかったのですが）、同じ部署のチームが海外のチームと一緒に仕事をしており、海外のメンバーがとにかく優先順位を無視して新しい機能の実装を優先してしまうため、以前からある機能のバグが直らないままバグがさらに増産される恐ろしい状態になっている、というものがありました。結果として、そのサービスはユーザーからするとバグが多くて謎の機能が多い、使いづらくヒドイものになり、ユーザー数は全然伸びませんでした。傍から見ていたら当たり前のことなのですが、機能を開発していた開発者たちが気づいている気配はまったくなかったので、残念な気持ちになったことを覚えています。
これはもちろん、「開発者は開発の優先順位をまともに決められず、開発しか脳がない奴らで、こちらで全部やってやらなければならないんだ」ということではありません。そういう人もいるかもしれませんが、“機能を増やしたい病”は、別に開発者だけがかかる病ではありません。重要なのは、「機能を増やすのは相当に慎重にやるべき」ということを常に共通の意識として繰り返し確認しながら、「何をまず優先してやるべきか？」という意識合わせをちゃんとしましょう、ということです。
