設計と開発のための技術の分野は進化し続けているのだから、そうしたシステムをデザインするためのプロセスも進化すべきだ。
投資のためなのか、製品の開発を手助けするためなのかは別として、起業家や企業にとって、その製品の長期的な影響を考慮し、よりよく気を配った慎重なアプローチを熟慮することの必要性を伝えることは重要なことだ。
製品化のためのプロセスは、常に次の順序で実行する必要がある。まず戦略、次に設計、最後にエンジニアリングだ。これらのプロセスの柱に対して、「なぜ？」という態度で臨めば、より優れた製品、より高い消費者の関心が得られるはずだ。そして拡張し続けるインターネットに対しても、有益な貢献ができるかもしれない。
フェーズ１：製品戦略
この製品戦略の柱の中では、製品を開発できる人がいるからといって、必ずしもその人に開発を任せるべきとは限らない、ということを覚えておくことが重要だ。ある種の技術が利用できるからといって、それが使いやすさを向上させるとは限らない。目的が製品開発を推し進めるのはであって、技術自体ではけっしてない。
最近開催された第40回のInternational Conference of Data Protection（国際データ保護会議）で、その会議のホストであるGiovanni Buttarelliは、「法律に準拠していて、技術的に実現可能でありさえすれば、道徳的に持続可能だというわけではない」と述べた。言い換えれば、「それを開発すべきなのか？」という問いを、この段階では常に問い続けるということになる。このフェーズを真に理解するためのヒントは、「このフェーズを始める前と、終えた後で、自分の考えがどのように変わるのか？」と自問してみることだ。
考え方が発展すればするほど良い、ということになる。
フェーズ2：製品設計
もし設計者がフェーズ１と２の間を行ったり来たりするようなら、それは良い兆候だ。フェーズ１で消えてしまうアイデアは、それにどれだけの作業や時間が費やされていたとしても、成功と見なされるべきだというを覚えておこう。
そして製品設計のフェースに移行する際には、消費者は飽きている、本当に飽き飽きしている、ということを意識しておくのは非常に重要となる。
従来的技法のほとんどに、もはや消費者は共鳴しないと仮定すべきだ。それは技術の燃え尽き症候群が広まったような状態、App Fatigue（アプリ疲労）というべきものなのだ。この完璧な例は、通知や、思慮を欠いた警告に見られる。
通知によって使いやすさは増すだろうか？ 通知があることによって、ユーザーはそのソフトウェア、アプリを使いたいと思うようになるだろうか？ もしそのように問われたら、それには大声で「ノー」と答えることになる。戦略フェーズに戻り、顔を洗ってやり直すべきだろう。
ここで質問すべきことは非常にシンプルだ。「通知や、似たような小細工を使わずに、この製品を使い続けたいとユーザーに思わせるものは何なのか？」ということ。
顧客と共鳴できるようにするには、どのような体験を作り出せばよいのだろうか？ もしユーザー体験が、全般的に個々のユーザーと共鳴するものであれば、彼らは通知機能などなくても、喜んで使い続けるだろう。これは自明で簡単なことに思えるかもしれないが、自明な答えというものは、概して答えるのが最も難しく、そのために無視されがちだ。
Uberがタクシーを呼ぶために、あるいはAirbnbが休暇の賃貸のために何をしたか、ちょっと立ち止まって考えてみよう。これらの企業は、消費者にとって本当に有意義で豊かな機会を提供する製品体験を可能にするための技術を利用している。彼らは、消費者をつなぎ留めておくために通知は必要としなかった。 消費者がその必要性に気付いていなかったサービスを提供しているのだ。それは、独創的な差別化されたアイデアだった。問題は、障害を乗り越える新たな飛躍が遂げられるか？ ということなのだ。
開発者が戦略段階を経て、設計すべきコアな機能を理解したら、エンジニアリングのアーキテクチャとユーザーのデータについて、より安全で配慮の行き届いた体験を提供できるようにするため、新たなエンジニアリングの解法に集中べきときだ。
フェーズ３：エンジニアリング
現在、Facebook、Google、Amazonのいずれの会社でも、ほとんどのユーザーデータは集約されたサーバー内に格納されている。これはセキュリティとプライバシー上の懸念を生じさせている。
こうした数の限られた大手ハイテク企業のどれかに託すのではなく、もっと配慮の行き届いた方法でユーザーデータを扱うために、開発者はどうすれば良いだろうか？ フォロワー、友達、その他の似たようなメカニズムを利用して製品上の人々を結び付けるようなアーキテクチャでは、データを暗号化して、集約型のサーバーではなく、ネットワークで接続された電話機内に保存すべきだろう。簡単に言えば、ユーザーデータのバトンを、大企業ではなく、あなたの友達に手渡すのだ。
まだ初期段階のものだとしても、このようなアーキテクチャは、将来の世代のアプリに焦点を合わせた全般的な製品体験と、うまく組み合わせることができるはずだ。それによって、企業ではなく、消費者に有利な分散型アーキテクチャを作り出すことができる。これも、配慮の行き届いた「ユーザー優先のアプローチ」の例の１つだ。これは、スタートアップにとって大きな飛躍となる得る。この場合は、ユーザーデータとセキュリティに関して、新しいアプローチについて考え、常に規範に挑戦し続ける好例となる。
それらをすべて統合して
以下のようなケーススタディを青写真として考えてみよう。ここでは、本質的にソーシャルなアプリケーションの開発を提案することを想像してみる（この例は現実的だ。というのも、多くの若い起業家は、依然として彼らの中核にソーシャルを位置付け、多くの企業はソーシャルが、重要な第一の差別化要因であると信じているから）。
この回答例は、「なぜそのようなソフトウェアを開発したいと思っているのか？」というもの。さらに、「それが、人々や社会に対して、ポジティブな、あるいは生産的な方法で役立つと感じているか？」と続く（別に彼らの注意を引こうとしているわけではない）。これらの的を絞った質問は、ソフトウェアの行く末の重要性と、それが社会に及ぼす大きな影響に焦点を合わせたものだ。
これ以降は、高レベルの戦略（何を開発しているのか、そしてそれはなぜ？）から、具体的な機能（設計フェーズ）に焦点をシフトしてみよう。通常は、友達やフォロワーという、つながりのモデルがある。それによって人の活動を見ることができるが、ある程度の煩わしい通知や、入力の要求、あるいはアップデートもある。
それから、こうした標準的な機能に代わる、配慮の行き届いたソリューションを提供することに焦点を合わせる。製品が提供しているものを明確にするために、友達リクエストの数を制限することを検討すべきだろうか？ あるいは、開発がもう少し先に進んでいる場合には、広告は見たくないという潜在的な顧客のために、有料コンテンツを設定することも考えてみるべきか？ または、一定のアルゴリズムによってコンテンツを並び替える代わりに、ポストされたらすぐにコンテンツを表示するのか、あるいは消費者にオプションを提供するのか、といったことも考慮すべきだろうか？
いくつかの企業は、こうした類の選択肢を模索し始めている。Appleが、最近のiOSのリリースで、マップ共有のために採用した方法を考えてみよう。Googleも、それに追従している。
ソフトウェア設計および開発の世界では、現在も将来も、少ないほど効果が多い、と言われる。そして、配慮の行き届いた思慮深い決定が、次世代のアプリと、より大きなソフトウェアのエコシステムの基盤を強化することにつながる。
混雑した市場で価値を提供するのは、非常に困難だが、やりがいのあることだ。配慮の行き届いたアプローチを製品設計に取り入れることによって、合理化されたアーキテクチャーが可能になる。それによって、時間を節約し、人々が本当に使いたいと思う製品を開発するための枠組みを提供することができるのだ。
[原文へ]
（翻訳：Fumihiko Shibata）
