第10話「ようやく『仕事を保存する』が形になった。」

第1話を書いた頃、私はArrowsのことを、

「タブを整理するためのツールではない。」

と書きました。

整理したかったのは、タブではなく仕事そのもの。

今ではArrowsの中心にある考え方ですが、最初からこの形が見えていたわけではありません。

むしろ、ここまでずっと作りながら考えてきました。

MOVEを作って、仕事中のタブを作業エリアへ移動できるようにした。

でも仕事が終わっても、タブを閉じられなかった。

そこでSAVEを作った。

今はやらない仕事を一度保存して、安心してタブを閉じられるようにする。

ところがURLだけ保存してみると、今度はブックマークと同じ問題が出てきました。

「これ、何のために保存したんだっけ？」

そこでAIを使って、あとから検索するときに必要になる情報を残すことを考えました。

こうして振り返ってみると、MOVE、SAVE、SAVED CASES、AI。

一つずつ作っていたときは、全部別の機能でした。

でも、あるとき気付きました。

これ、全部つながっているな。

MOVEは「整理する機能」ではなかった

最初に作ったMOVEは、タブを右へ移動するだけの機能でした。

仕事中のタブを決めた作業エリアに集める。

それだけです。

でもSAVEができてから考えると、MOVEの意味も少し変わりました。

MOVEはタブをきれいに並べるためのものではなく、

「今やっている仕事」を集めるためのもの。

そして、その仕事を今やらなくなったらSAVEする。

SAVEした仕事はSAVED CASESへ移動する。

必要になったら検索して、また開く。

つまり、

MOVE → SAVE → SAVED CASES → 再開

という流れができました。

タブを整理する機能をいくつも作ったつもりだったのに、結果としてできていたのは、

仕事を「今やる」と「あとでやる」の間で移動させる仕組み

だったんです。

ブックマークとの違いも、やっと説明できた

第3話では、私のChromeに219件のブックマークが残っていた話を書きました。

当時は、

「ブックマークでは仕事を管理できない。」

くらいに思っていました。

でも、なぜできないのかをうまく説明できませんでした。

第7話、第8話、第9話と考えてきて、ようやく自分の中ではっきりしてきました。

ブックマークは、

「このページを残しておきたい」

ときには、とても便利です。

一方、私がArrowsで残したかったのは、

「この仕事をあとで続けたい」

でした。

似ているようで、少し違います。

ページを残すことがゴールなのか。

そのページでやっていた仕事へ戻ることがゴールなのか。

Arrowsで作りたかったのは後者でした。

最初から設計できていたわけではない

こう書くと、

「最初にコンセプトを決めて、それに合わせて機能を設計した」

ように見えるかもしれません。

実際は全然違います（笑）

タブが増えて困る。

↓

MOVEを作る。

↓

閉じられない。

↓

SAVEを作る。

↓

URLだけだとブックマークと同じ。

↓

あとから探せない。

↓

AIを使ってみる。

ほとんどこの繰り返しでした。

一つ作ると、次の問題が見える。

その問題を直すと、また別の問題が見える。

それを何度も繰り返しているうちに、あとから一本の線になりました。

これはArrowsを作っていて面白かったところでもあります。

「機能」ではなく「流れ」で見る

開発中は、どうしても機能単位で考えてしまいます。

MOVEを実装する。

SAVEを実装する。

検索を実装する。

AIを実装する。

一つずつ完成すると達成感もあります。

でも、実際に使う人からすると、そんな区切りはあまり関係ありません。

「このボタンを押したあと、私はどうなるのか。」

「次に何をすればいいのか。」

「数日後に戻ってきたとき、続きを始められるのか。」

ユーザーが使っているのは機能ではなく、一連の流れなんだと思います。

Arrowsの場合、その流れはかなり単純でした。

今やる仕事は、作業エリアへ。

あとでやる仕事は、SAVE。

必要になったら、SAVED CASESから戻す。

ここまで来て、ようやく最初に言っていた、

「整理するのはタブではなく、仕事そのもの。」

が、言葉だけではなく機能として少し形になった気がしました。

💡今回の開発メモ

今回の経験から一つ学んだのは、

機能が増えてきたら、一度「ユーザーが最初から最後まで何をするのか」を通して見てみる

ということです。

機能一覧だけを見ると、

MOVEがあります。
SAVEがあります。
AIがあります。
検索があります。

となります。

でも、それでは何のアプリなのか分かりにくい。

一方、

と並べると、その機能が必要な理由も見えてきます。

新しい機能を追加するときも、

「この機能は、この流れのどこに入るんだろう？」

と考える。

どこにも入らないなら、本当に必要な機能なのか一度考えてみる。

これは今でもArrowsに機能を追加するときに意識していることです。

少しだけ次回予告

ここまでで、Arrowsの基本的な流れはできました。

ところが、自分で毎日使っていると、

「これで完成」にはなりませんでした。

むしろ実際に使うようになってから、

「ここ面倒だな。」

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

という小さな不満が次々に出てきます。

次回は、自分で作ったツールを自分で使い続けると、仕様書では見えなかった問題がどんどん出てきた話を書こうと思います。

◀ 前の話

▶ 次の話

📚 全話一覧