メモの置き場としてGmailを使っている。誰かに聞いたおすすめ本、忘れたくないTODO、Webサービスのアイデアなど色んなものをすべて自分宛にメールで送る。定期的に受信箱を上から見ていって、そのメモが完了したらアーカイブして整理する。本当はそれぞれの登録に最適なサービスがあるだろうが、メモする時点でカテゴリ分けを考えるのも面倒なのでこの方法が定着した。メールならパソコンからでもスマホからでも送れるので環境も選ばない。

自分にメールを送るアプリとして「Note To Self Mail」というアプリを使っている。このジャンルではCaptioという人気アプリがあったが最近サービス開発が終了。代替となるものを探して、一番操作感の良いこのアプリに切り替えることにした。

Macにもこのアプリを入れてるが、頻繁にメモするのでショートカットでメモを送信する機能が欲しいと思って問い合わせてみた。数時間後に返信が来て、「Cmd+Sでできるよ！でも提案してくれたCmd+Enterでの送信も直感的だと思うので検討するね。気に入ったらAppStoreでレビューを書いてね！」と書かれていた。すでにある機能の案内、要望の受け止め、返信の早さなどなんとなくカンジが良く、AppStoreのレビューを書いた。元々気に入っていたアプリではあったが、こういう体験があると単なるユーザーからファンに近づく。

昔Smoozというブラウザアプリを使っていたが、要望を送ると創業者の方が自らすぐ返信してくれ、その後機能追加されるとまた連絡をくれて良いサポートだなと思った記憶がある。ファンになれば長い間使い続けてもらえるし、良い体験は人に話したくなるのでサービスを広げるのにも一役買うことになる。新卒の頃にザッポス伝説を読んで顧客ファーストがつくる面白い世界に感銘を受けた。こういう経験はいつまでも覚えている。

単機能のTodoアプリは元々シンプル。それが機能が膨らんでいくとどんどん複雑になってくる。カレンダー表示したくなったり、Todoに画像を入れたくなったり、期限の数時間前に通知が欲しくなったり、「Todo」「Done」以外にもステータスが欲しくなったり。放っておくと複雑になるものをシンプルに保つところにデザインの価値がある。

例えば、すべての機能を表示すると画面が煩雑になるなら、必要なタイミングで必要な要素を表示する。何か操作メニューがあるとして、いきなりすべて表示するのではなくマウスカーソルを合わせたら表示されるようにする。機能の絞り込みもある。期限が来たタスクの通知をメールで受け取るのか、アプリのプッシュ通知で受け取るのか。いろんな方法で受け取れたらもちろん便利だが、設定が何千パターンもあってもそれを使いこなすのは難しい。ほとんどの要望を満たせるいくつかのパターンを作り込んで実装し、残りはAPIを提供するなどしてユーザーが自作できるようにしておけばそれで良いかもしれない。

理想としては一見シンプルに見えて、使い込んでいくと実は柔軟にいろんな使い方ができるような体験がよい。いきなりすべての機能表をドーンと見せられても圧倒されてしまう。主体はあくまで人。「自分たちで使えそう」と第一感を持ってもらい、まず使い始めてもらう。使い込んでいくとその機能を理解できて、さらに自分たちにあったカスタマイズした使い方もできる、みたいな流れが美しい。これを実現するにはユーザーを理解する必要がある。最近は思い込みで作らずユーザーにインタビューしようという流れが強いが、見事なものを作るには深い理解が不可欠になる。

機能が増えれば普通は複雑になる。それをどこまでシンプルに抑えられるか、この複雑度の差分がデザインの力だと思う。何か困ってることがあってそのサービスに頼るのに、そのサービスの使い方でまた困っているようでは本末転倒である。いろんなサービスが登場して飽和気味になり、ユーザーから求められる水準が高くなっている今こそシンプルさは大きな要素になる。

DeNAの創業者で現在は会長の南場さん。AI時代の戦い方についての講演を読んだがとても面白かった。近い将来のAIシフトを分かっていながら、参加しているプレイヤーがとても少ないというのは自分も感じるところ。DeNAは既存事業に割く人数を半分にして残り半分をAI領域にフォーカスするらしい。この規模の会社でそこまで割り切れたら強い。

南場さんの言葉は心に素直に入ってくる。著書の「不恰好経営」にDeNA創業時の一枚の写真が掲載されており、「技術」「ユーザー」「お金」など、異なる軸を好きなメンバーが集まってひとつのサービスを作ったという。スキルや情熱がぶつかりあって良いものが生まれる瞬間はいつでも美しい。

新卒何年目かの頃、いろいろ周りも見えてきて社内の評価制度について少し思うことがあった。そんなとき出会ったのが「コトに向かう力」（これも講演の書き起こし）で、ヒトではなくコトに向かうことの大切さ、シンプルさ、楽しさなどを教えてもらった。周りの評価ではなく自分で意義を感じられるか。人との比較より目の前のことを前進させられたかというのは自分のなかのテーマとしてあって、それはこのスピーチの影響を少なからず受けている。

AI時代はリスクもあるがチャンスもある。個人や少人数のチームとしてはアプリケーションレイヤーは狙い目で、多種多様のユーザーの課題は大手資本が一気に解決するよりももう少し細かい。AppStoreに各ジャンルのアプリが並ぶように、各領域に特化した使いやすいアプリケーションが生き残っていく形になる。

仕事ではプロダクトマネージャーという役割をやっていて、次に作る機能の優先度をつけたりしている。優先度決めは難しい。自分たちの作りたい機能、お客さんから求められている機能、不具合修正など、属性の違うものを比べてひとつの軸にのせる作業。プロダクトマネージャー界でもよく議論されており、「こうやって分けるといいですよ」のフレームワークをいろんな人が考案していたりする。

フレームワークは各アイテムにスコアをつけて同じ平面上に置いていく。スコアを求める算出式があり、例えば対象となるユーザーの数や開発にかかる工数などがあり、掛け算して出たスコアを使って優先度の根拠としましょうということだ。さて、この数式の中に「確度」という採点基準がある。これは仮説の確からしさを表しており、「これまでの経験からこれはいける」と「よくわからないけど直感がそう言っている」ではスコアには差がつくべき。Webサービス開発では「作ったけどそれを欲しい人は誰もいませんでした」がよくある。事前のインタビューや調査で確度を高めることを意識させる基準となっている。

確度は確信度とも言い換えられるが、普段の行動でも確信度によって結果が変わることがある。「この資料作る意味ないでしょ」と思いながらスライドを作っていても良いものは出来にくい。「これは本当に必要なものだ」と思えれば頑張れる（最近よく聞く納得感はこれ）。他にも尊敬してない人からのアドバイスは受け入れがたいし、誰が使うか不明な機能を作り込むのは相当エネルギーを消耗する。昔読んだ本に結果とはスキルとモチベーションの掛け算だという式が出てきたが、モチベーションを分解した中にこの確信度が含まれていそうだ。

仕事の話をしていて指摘されたくないと思ったり、なんとなく言及を避けている部分に自分のプライドが隠れている。一個人としては触れてほしくない部分はあってもよいが、仕事は割り切ってなんでもオーケーというスタンスに近づけたい。日本人は議論が下手で反論を自分への個人攻撃と捉えてしまうという話があるが、これは数をこなして慣れていくしかないと思っている。

プライドがあって良いことはない。何か壁に当たったとき、プライドは自分の心を折る方向に加速させてしまう。自尊心、誇りはないほど身軽で良い。個人の信念、ポリシーはあって良い。それは自分のなかの決め事で、「こういう人間でありたい」という思いはしんどい時の拠り所になってくれる。プライドと信念は似ているようで違うもの。

プライドの種を見つけたらその場でほぐして解き放ちたい。荷物は少ないほど身軽に動ける。強靭な壁をつくってもいつかは壊れる。そもそも壁がなければ壊れることもない。