皆さんこんにちは。
エコモットの板橋です。
弊社は、自社サービスを運営しており、継続的な機能の改善や強化に取り組んでいます。
そんな中で「サービスを今後どの様に発展させていくか」だったり「価値を高めていくか」といった事をよく考えます。
今回は、そういった場面で役立つ２つの考え方（概念）について書いていきたいと思います。
なお、”概念”と記載した通り、考え方はもちろん、場合によっては私の主観が含まれる内容です。
皆さんも、想像しながら読んでいただき、皆さんなりの受け止めや考えを整理してみると良いと思います。
相反する思惑
システムはリリースした時点で、最新の技術や世の中のニーズ、先見性など、そのシステムの価値が市場で客観的に評価されます。
評価するのは市場の皆さんであり、開発元ではありません。その為、市場での受け止められ方は、開発元の思惑とは異なる場合があります。
開発元の思いとしては、幅広く使ってもらいたいため、システムの各機能を汎用的に作り、多様なニーズに対応できるように作ろうとします。
その結果、表示内容や設定項目が増えてしまいますが、開発者たちはこれを「詳細な操作」「詳細な情報」と捉え、あまり問題視しません。
むしろ、「ここを操作するとニーズＡを満たせて、更に設定を加えるとニーズＢにも対応できる」という具合に、”売り”のイメージを持ちます。
一方、利用者の受け止め方は少し異なります。
利用者には達成したい目的があり、その目的は利用者により様々です。
更に、新しいものに適応するための手間（学習コスト）や、表示される情報から正しく情報を理解する為の思考（認知コスト）を非常に気にします。
その為、利用者の目的を達成するのに必要なこれら学習コストや認知コストがどれだけ低いかという点をとても重視しているのです。
※その他、サービス利用料・サポート体制など大きな要素はありますが、話がぶれてしまうので今回は除外します。
まとめると、開発者と利用者の間には、以下の様な相反関係があるのです。
汎用的で多機能が正義（エンジニア） vs シンプルで直感的（利用者）
とりあえず、立場の違いからこのような思いのすれ違いが発生するという点を押さえておきましょう。
広がる溝
私たちもそうですが、利用者であるお客様の一部から「とても素晴らしい。さらにニーズＣにも対応できると更に良い！」という麻薬のようなお言葉を頂きます。
日々、精神を削ってシステムを作り、地味で目立たない保守運用をしているエンジニアたちにとっては、日々の苦労が一瞬で消し飛ぶようなとても嬉しいお言葉です。
そして、さも利用者全体の総意であるかのように錯覚し、エンジニアたちは早速機能の追加を検討するのです。
システムの価値を最大化するため、エンジニアたちは高い確率で盲目的に機能を”付け加える”事で価値の向上を達成しようとします。
その結果、設定項目や画面が増え、ニーズＣが不要な利用者にとってノイズが増えるようなバージョンアップとなるのです。
更に「利用者全体の総意であるかのように錯覚している」ため、利用者の大多数がノイズに感じるという結果を招きます。
ここで改めて、相反する思惑のセクションで記載した内容を思い出してみてください。
「多機能は悪ではない」が「善でもない」という難しい状況なのです。
そして限界へ…
このような麻薬のようなお言葉（本当にうれしいんです！）に感覚を侵され、どんどん機能を追加していった結果、以下の様な結末を迎えます。
- 多様なニーズに対応するため表示や設定が複雑化
- UIの直感性も低下し操作に迷うようになる
- 肥大化するマニュアル
- 利用者の学習コストと認知コストが急上昇
- エンジニアの保守コストが激増
- 特定のエンジニアしかわからない属人化が急加速
どのタイミングでこのような状況を迎えるかは一概には言えませんし、必ずこのようになるとも断言できませんが、状況をコントロールせずに無秩序に機能の追加をしていくとおおよその確率でこのような状況を迎えてしまいます。
機能性を高め、対応可能なニーズも増えているのに、なにやら雲行きが怪しくなってきています。
「特化」と「洗練」で限界突破する
このような難しい状況を迎えてしまうわけですが、このような状況を打開するため、多くの現場では無秩序に肥大化してしまったシステムの「減量」を検討します。
ここでエンジニアたちが取るべき選択として大きく２つの道が存在します。
それが今回のテーマである「特化」と「洗練」という概念です。
どちらも、「利用者の負担（学習コスト・認知コスト）を下げ、システムの価値を再定義する」という目的は一緒ですが、アプローチの方向性は正反対のものです。
また、この仕事をしていると、「レガシーシステムの再構築案件」という話に出くわすことがありますが、これの根底にあるのは、時代の流れ（流行やニーズ）に対応させるために
長年、継ぎ足しで機能拡張したシステムがいよいよ限界（保守コストの増加や、利用部門の負担増）を迎えてどうにもならなくなった末の決断だったりするのです。
※当然、クラウド環境への移行や最新アーキテクチャの採用による技術的なリフレッシュも含まれます。
このような案件の目的として根底にあるのが「特化」だったり「洗練」という考えに基づくものなのです。
詳しく見ていきましょう。
特化について
分かり易く言うならば「選択と集中」のことです。ニュースや社長インタビューの際によく遭遇する言葉ですね。
つまり、不採算部門の人員を将来性があり今後も重要だと位置づける部門へ移動させ、会社の持つリソースを重点的に投下するという事です。
システムに置き換えると、利用者が減り、時代的なニーズもピークアウトしている機能を削除しシステムのボリュームをスリム化。
開発リソースを、利用者の多い主要な機能に振り向けるという事です。
そうすることによりシステムは、利用頻度の低い機能が淘汰され、逆によく使われる主要な機能のみを今後も伸ばしていくという戦略になります。
利用者としても、不要な機能や表示が削除されることにより「学習コスト」や「認知コスト」といったネガティブな部分が改善され、顧客満足度が上がるという嬉しい効果が得られます。
結果、特定の用途に限っては非常に強力なサービスだが、それ以外には利用できないシステム、、、つまり「特化する」という結果に繋がっていき、システムを売り込む際にも特定用途に特化していることから、顧客のターゲットを絞りやすく、市場に対するアピールも明確になるとメリットが出てきます。
洗練について
洗練とは、出来るだけ現状の機能や要素を維持したまま、利用者が感じる「複雑性」や「分かりにくさ」といったノイズを取り払うアプローチです。
利用者のニーズに従って現状の機能を取捨選択する特化とは違い、利用者が何処に複雑性や使いにくさを感じているかといった、客観的な評価と分析が必要になる分、特化させるときとは違った難易度の高さがあります。
これら、システムに対する印象は利用者の目的や年齢層、職業などの背景により様々で、かつ主観的な部分が大きいため、一方を優先するともう一方が犠牲になるというジレンマに遭遇することも多々あります。
その為、洗練の過程では、一時的に利用者からの批判にさらされる覚悟をもって実施する必要があります。しかし、それらの批判は時間の経過とともに減少していき、「慣れたらこっちの方がいいかも」というような逆転が起きることも多く、時間が解決してくれる内容が多いのです。
そのため、洗練による効果は時間をかけてじわじわと出てきます。
身近な例で例えると、iPhoneのOSアップデートの感覚に近く、最初は「使いにくくなった」「分かりにくくなった」という声が多いのですが、時間の経過とともにそういった声は減っていき、なんだかんだで色んな使い方を試しているうちに、不思議と馴染んでしまう感覚ってありますよね。
まとめ
「特化」とは必須な機能のみを残し、「何でもできます」というカオスな状況から、「これなら完璧にこなせます」という特定分野への全振りの発想で、機能的なシンプル性で利用者に分かりやすくするアプローチ。
「洗練」とは現状の機能性は維持したまま、複雑性を増長している要素を特定して「本当にそれ（表示や項目）は必要か」「必要な時だけ表示しよう」といった、見た目をシンプルにすることで利用者が迷わない様にするアプローチ。
雑にまとめると、両者にはこのような違いがあります。
今回は、「特化」と「洗練」について書きましたが、どちらが優れているかという話ではなく、システムに対して取るべきアプローチはその時々で異なります。
また、不思議なことに、「洗練」を繰り返していくと、なぜか「特化」してしまったという事も起きます。
異なる概念ですので、両方を採用する事だってできます。
そうすることで、自分たちの担当しているプロダクトの魅力が強化され、お客様もエンジニアも幸せになれると良いなと思います。
また、この話は、システムのUIや機能性に限った話ではなく、前回でも話したシステムの設計等にも応用できる汎用的な考えです。
是非、システムの拡張を行う際に、「加えること」と「引くこと」を同時に考えてみると良いかもしれません。
ではまた。
私たちと一緒にモノづくりをしていく仲間を募集しています。 弊社に少しでも興味のある方は、ぜひ下記の採用ページをご覧ください。
