一度書き始めてみると、意外と書くことがあるものですね。くまちゃんです。
はじめに
これは 思いを持つということ、伝えるということ - 気まぐれエンジニア日記 の続編となる記事です。先の記事では、思いを持つ、他者の思いを伝えるということに注目しました。思いを持つとは、作るべきものを考え、多数の意見やアイデアから覚悟を持って選ぶことでした。その上で、著者なりのモノづくりとは、考え、覚悟を持って選び、表現するだと述べました。
この記事ではさらにその先、「思いを表現してモノを作るということ」について書こうと思います。「このアプリケーションはこういうものであれ、こういうことを理想とせよ。」という思いが固まった後、それをアプリケーションとして形にする際に著者が大切にしていることを整理します。
表現の制約を見つける
作ろうとするアプリケーションのあるべき姿を思いとして持ったとき、まず最初にやることは、思いをブレイクダウンして表現の制約に言い換えることだと考えています。
例を出しましょう。自分のお気に入りのテキストエディタを開発することを考えます。そのエディタは「文章を素早く編集できる」ことが理想であるとします。このとき「文章を素早く編集できる」ことはどのように言い換えられるでしょうか？例えば、以下のようなものが思いつきます。
- 文章を素早く編集できる
- キーボードから手を離さずに装飾を施せる
- シンプルな記法を書くだけで装飾を施せる
- キーボードショートカットで装飾を施せる
- 文字を全部打たなくても書きたいことを書ける
- 単語、短文の自動補完が出てくる
- すでに書いた文章のコピペが推薦される
- リンクを貼るだけでリンク先の文章が出てくる
- 文章の推敲が支援される
- 表記揺れの置き換えを一気にできる
- 段落の入れ替えが簡単にできる
- キーボードから手を離さずに装飾を施せる
この段階では、すぐにプログラムにできそうなものも、どうやって作ればいいかがまだはっきりしないものもあると思います。でも、それで良いのです。重要なことは、アプリケーションに込めたい思いを分解して、具体的なイメージを描く上での制約として並べることです。アプリケーションの画面の見た目や持っている機能を考えるときに「この制約を満たしていないから、考え直さないとな」という試行錯誤を確実に行うことができます。
見たことがあるものをよく観察する
表現の制約をある程度列挙できたら、具体的なアプリケーションのイメージを描きます。画面の見た目を作ってみたり、持っている機能を整理したり、「なんかこれを作っていけば動きそう」なものがイメージできればゴールです。
ですが、全く何もないところから、具体的な画面、機能のイメージを描くことはとても難しいことです。そこで、すでにあるものをよく観察してみます。テキストエディタであれば、Word、Hack MD、VSCode、Notion、Scrapboxなんでも良いでしょう。どこかで見たことや使ったことがあるものは、何らか優れているところがあるから、目に触れるほど広まっているはずです。一方、自分で新しく作りたい物があるということは、見たことや使ったことがあるもののどれもが解決できていない課題やイケてないところがあるはずです。
この優れているところとイケてないところをしっかりと言語化して整理します。これをやることで、既存のものをベースにして具体的なアプリケーションのイメージを描きやすくなります。また、優れているところは取り入れるように、イケてないところはそうならないようにという形で、表現の制約にさらに磨きをかけることもできます。
ここで取り上げる既存のものは、「一生懸命調査をして探し出す」必要はあまりないと思っています。もちろん、最終的にアプリケーションが出来上がった後に、同じようなものがないかの調査を行うのは良いことです。ですが、ここでやりたいことは、具体的な画面、機能のイメージを描くための助けになるものを見つけることですから、今までに見たことがある、使ったことがあるというのが重要だと思っています。
「真新しい」と「よくある」を線引きする
具体的なアプリケーションのイメージが湧いてきたら、いよいよ作っていきます。この段階で大切にしていることは、「真新しい」と「よくある」を区分けすることです。
自分が時間をかけて新しく作るアプリケーションとなると「今までにないものを作りたい！」という気持ちが強くなるのは当然のことです。でも、このとき、どの部分を自分のアプリケーションにしかない「真新しい」特徴にして、どの部分を「よくある」ものに留めるのかの線引きをしっかりと行うことが重要だと思っています。
「真新しい」機能や操作、見た目ばかりでは、アプリケーションを使う人はその世界観についていくことができず、いいものとは感じてくれないでしょう。逆に「よくある」機能や操作が中心で「真新しい」部分が奥に隠れてしまっては、使う人のほとんどはその真新しい部分に気づくことはできず、「もうこれ〇〇っていうアプリとして世の中にあるよね」と言われてしまうでしょう。このアプリケーションだけの特徴として押し出す機能は一部のユーザがついてこられないリスクを覚悟で作り込み、そうでない部分は「よくある」ものに寄せて作ることが重要だと考えています。
先から例に挙げているテキストエディタを考えてみます。「シンプルな記法を書くだけで装飾を施せる」では、記法を突飛なものにすることは重要ではありません。独自の記法を一部取り入れるのは良いと思いますが、Markdown等の記法を真似た方が、Markdownを使ったことがある人がすぐに使えるという利点を得られます。逆に、「段落の入れ替えが簡単にできる」では、こういった機能を持ったエディタは多くないでしょうから、独自の特徴として押し出すのが良いです。機能をわかりやすい位置に配置したり、ドキュメントに特徴として書きます。
このバランスは非常に難しく、著者もまだまだ勉強中ですが、特徴として押し出す機能は全面に出すこと、普通でいいものをわざわざ奇抜に作らないことを強く意識しています。
フィードバックを得て改善する
アプリケーションがある程度動いて見えるようになったら、なるべくフィードバックを得ます。実際に使ってもらえることが一番ではありますが、難しければデモンストレーションを見てもらって意見を言ってもらうだけでも良いです。
自分では気づかなかったアプリケーションの良いところや足りていないことを気づくきっかけになります。作っている側は、根本にある思いの部分は徐々に当たり前になっていき、どうしても細部に目がいってしまうものです。他の人の目を通すことで、思いは揺らぎないものになっているか、思いを分解した表現の制約は適切だったかという根本を見直すことができます。根本に目を向けなければいけないのは、フィードバックの怖いところでもあるのですが、勇気を持ってフィードバックに望み、改善をしていくのも「考え、覚悟を持って選ぶ」のうちだと思っています。
フィードバックの中で自分が意識して作った部分にちゃんと他の人が気づいてくれたりすると、創作の意欲にもつながります。自分の思いを支持してくれる人もいると思いながらモノを作るのはとても楽しいです。
おわりに
この記事では、思いを持つということ、伝えるということ - 気まぐれエンジニア日記 の続編として「思いを表現してモノを作るということ」について書きました。
アプリケーションのあるべき姿を思いとして持ったとき、まずは思いをブレイクダウンして表現の制約を並べることから始めます。アプリケーションの画面や機能に対して、こんな表現でないといけないという制約を整理し、考えやすくします。
次に、すでにあるものを観察して、優れているところ、イケてないところを言語化します。具体的なものをベースにすることで、アプリケーションのイメージをより明確にします。また、優れている部分は取り入れるように、イケてない部分はそうならないように、表現の制約の磨き上げも行います。
具体的なアプリケーションのイメージが湧いてきたら、実際に作ります。作る上で重要なことは、「真新しい」と「よくある」を区分けすることです。特徴として押し出す機能は全面に出すこと、普通でいいものをわざわざ奇抜に作らないことを意識して、独自の特徴を十分に伝える一方で、ユーザを置いていかないように工夫します。
ある程度アプリケーションが動くようになったら、フィードバックを得ます。フィードバックには、アプリケーションの根本にあった思いを見直すきっかけとしての価値だけでなく、思いに共感してくれる他の人の存在に気づくきっかけとしての価値もあります。
以上が「考え、覚悟を持って選ぶ」の後の「表現する」において、著者が大切にしていることです。
