第11話 作った本人にも、使いにくかった。

第10話までで、Arrowsの基本的な形がようやく見えてきました。

MOVEで、今やっている仕事を作業エリアへ集める。

途中で止める仕事はSAVEする。

必要になったらSAVED CASESから探して、もう一度開く。

最初に困っていた「タブが増えすぎて、何をしていたのか分からなくなる」という問題に対して、自分なりの答えが少しずつできてきました。

ここまで来ると、ちょっと思います。

「これ、かなり使えるんじゃない？」

自分で作っているので、当然ちょっと甘めに評価しています（笑）

でも実際に仕事で使い始めると、すぐに気付きました。

作った本人にも、普通に使いにくい。

大事なことなのでもう一回

作った本人にも、普通に使いにくい。

作っているときには気付かなかった

開発中は、基本的に一つの機能を見ています。

MOVEを作っているときはMOVEを試す。
SAVEを作っているときはSAVEを試す。
SAVED CASESを作っているときは、ちゃんと保存されて、ちゃんと開けるか確認する。

当然ですが、動けばうれしいです。

「よし、できた。」となります。

でも、普段の仕事で使うと全然違いました。

楽天の仕事をしながらChromeを開く。
調べものをする。
ChatGPTを使う。
メールを見る。

別件が入る。

さっきの仕事に戻る。

また別の仕事を始める。

そういう普通の一日の中にArrowsを入れてみると、

「ここ、毎回クリックするの面倒だな。」
「これ、どこから開くんだっけ？」
「今ちょっとメモしたいだけなのに、SAVEするほどでもないな。」

みたいなことが次々に出てきます。

テストでは問題なかったのに、仕事の途中では気になる。

これが結構ありました。

「動く」と「使える」は違った

当たり前のことなんですが、自分で作ってみて実感しました。

機能が動くことと、その機能が使いやすいことは別でした。

たとえば3回クリックすれば目的の操作ができる。

機能テストとしては問題ありません。

でも、その操作を一日に何度もするとなると話が変わります。

一回なら気にならない。

10回やると、ちょっと面倒。

毎日やると、

「なんで毎回これやってるんだろう。」

となります。

しかもArrowsは、仕事を邪魔しないために作っているツールです。

Arrowsを操作すること自体が仕事になってしまったら、本末転倒です。

だから機能を増やすことより、

「Arrowsを意識しなくても使える状態」

の方が大事なんじゃないかと思うようになりました。

自分がユーザーになってみる

開発では、自分で作ったものを自分で日常的に使うことを「ドッグフーディング」と呼ぶことがあります。

言葉自体は以前から知っていました。

でも、実際にやってみると、思っていた以上に重要でした。

テストするときの私は「開発者」です。

どこにボタンがあるか知っています。

どういう順番で操作すればいいか知っています。

多少分かりにくくても、

「ここを押せばいい。」

と分かっています。

でも仕事中の私は、そんなことを考えていません。

早くメールを返したい。
早く調べたい。
次の作業へ進みたい。

Arrowsの操作方法は意識しません。

同じ人間なのに、開発している自分と、仕事をしている自分では、ツールを見る目が全然違いました。

これは面白い発見でした。

不満が出るのは、悪いことではなかった

最初は、自分で作ったものを使って、

「ここ使いにくいな。」

と思うと少し残念でした。

せっかく作ったのに、また直すのかと（笑）

でも途中から、考え方が変わりました。

実際の仕事で不満が出るということは、

次に直す場所が分かったということでもあります。

むしろ怖いのは、自分でも使わないまま、

「たぶん便利だろう。」

と思って公開することなのかもしれません。

Arrowsでは、この小さな不満を一つずつ拾うようになりました。

大きな新機能を思いつくというより、

「この1クリックいらないんじゃない？」
「ここから直接開けた方がよくない？」
「これ、SAVEするほどじゃないけど残したいな。」

そんな小さな違和感です。

そして、その中の一つが、次の機能につながりました。

「保存するほどじゃない。でも、残したい。」

仕事をしていると、SAVEとは少し違う場面があります。

あとで仕事そのものを再開したいわけではない。

でも、そのページを見たときに、

「ここ確認する。」

「この数字をあとで見る。」

「この部分を担当者に聞く。」

みたいなことを、ちょっとだけ残しておきたい。

以前なら、別のメモ帳に書いたり、頭の中で覚えておいたりしていました。

でも別の場所に書くと、

今度は、

「どこにメモしたっけ？」

が始まります。

だったら、そのページに直接メモを残せたらいい。

そんな小さな不満から、

Sticky Notes（付箋）

のアイデアが出てきました。

最初から「Arrowsには付箋機能が必要だ」と考えていたわけではありません。

自分で使って、

「SAVEするほどじゃないんだけどな……。」

と思った。

始まりはそれだけでした。

💡今回の開発メモ

今回の経験で一番感じたのは、

完成した機能をテストするだけではなく、その機能を使って本当の仕事をしてみることの大切さでした。

テストでは、「この操作が成功するか」を見ます。

実際の仕事では、

「そもそも、この操作をしたいと思うか」

が見えてきます。

これはかなり違います。

特に、自分自身もターゲットユーザーに近いプロダクトなら、実際の仕事へ入れてしまうのはかなり有効だと思います。

そして、そこで感じた違和感をすぐ新機能にするのではなく、

「なぜ今、面倒だと思ったんだろう？」

と一度考える。

Arrowsの機能の多くは、そういう小さな不満から生まれています。

派手なアイデアより、毎日感じる小さな面倒の方に、意外と次の機能のヒントがありました。

またこの使う＜ー＞開発のバランスが実際の使えるツールになるためには大事だなと感じてます。

この方式を「キャッチボール式開発」となずけて、このキャッチボールの回数を妥協なくやり切ることを意識しております。

少しだけ次回予告

SAVEは、仕事そのものを一度しまっておくには便利でした。

でも実際に使っていると、

「保存するほどじゃない。でも、このページにちょっとだけ残しておきたい。」

という場面が思った以上にありました。

別のメモ帳を開くのも面倒。

頭で覚えておくのも無理。

だったら、そのページにそのまま貼っておけばいい。

次回は、そんな小さな不満から**Sticky Notes（付箋）**が生まれた話を書こうと思います。

◀ 前の話

▶ 次の話

📚 全話一覧