Feedback Loop

個人開発で色々作っていて、Webサービスは最初の設計が大事だなと感じる。ここでいう設計とは仕様とかデザインとか技術選定とか色々なものを含んでいて、何か新しいサービス・新しい機能を作るときに考えること、みたいな広い意味。良い設計は変化に強くて柔軟性がある。

Webサービスはリリースして終わりではなく継続的に改善していく。改善の方向は自分の好みだけでなくユーザーからのフィードバック、AIなどの世の中の技術トレンドによっても影響を受け、リリース時点では思いもよらぬ方向に伸びていくこともある。そうなると重要なのが、変化に柔軟に作ること。例えばメモアプリを作るとして、最初は書いたテキストを保存できるだけのものを想定していたとする。しかし、将来的にはテキストだけでなく画像や動画もメモとして書きたくなるかもしれない。太字や斜体などの装飾をつけたくなるかもしれない。パソコンで書いたのをiPhone/Androidアプリで同期したくなるかもしれないし、書いたメモをURLにして知人にシェアしたくなるかもしれない。出発点はシンプルでも、改善を重ねるごとにどんどん複雑度があがっていく。

書いたテキストの文字数をカウントして表示するような、アドオン的な機能は後からでも作りやすい。iPhone/Androidアプリにも同期するような、システムの根幹に影響するようなものは後から作ると時間がかかる。最初から考慮して設計できていれば比較的容易に作れる。最初にどれだけ拡張性高く作れているか？が後の機能追加のスピードに影響する。

ただ、常に最大限柔軟に作れば良いのかというとそうでもない。柔軟に、汎用的に作ると変化には対応しやすくなるが、何でもできすぎると逆に理解や管理のコストが高くなる。ソースコードを見たりデータベースの構造を見たりするときに、なんでこういう作りなんだっけ？と毎回自問することになる。汎用化すると基本的にはコードベースは膨らむので、少しの機能追加にも時間がかかるようになる。作っているサービスに将来どういう機能がつく可能性があるかを考えて、抽象度を適切にコントロールする必要がある。

用途をある程度絞った方がよいのはユーザー的にもそうで、「これで何でもできます」というサービスは基本的に使われない。インターネットは広く様々なサービスに溢れているので、ユーザーと接する短いタイミングで「あなたがやりたいコレを叶えるサービスですよ」と伝える必要があり、そうなるには特定の分野に絞って提供するのが理にかなっている（Notionは例外で何でもできて売れているので本当にすごい）。例えばメモアプリにはApple TVにミラーリングする機能はいらないだろう。プライベートな内面を書く日記アプリでは書いた内容を全世界に公開する機能はいらないだろう。こうやって必要・不要を精査しながら仕様と設計を落とし込んでいく。

設計が上手くなるには設計を経験していくしかない。いろいろなものを作ったり他サービスを研究したりする。他の成熟したメモアプリにはどういう機能があるかを見ておくとイメージを膨らませられる。最近流行ってるサービスは複数人で共同編集できるものが多いな、とか知っているとその機能が必要かどうか早い段階で検討することができる。いろいろ作っては設計を後悔して、次やるときはもう少し上手くなる。そんな感じで日々設計力を磨いている。