個人開発をはじめよう！クリエイター 25 人の実践エピソード

『技術の泉シリーズ個人開発をはじめよう！クリエイター 25 人の実践エピソード』（ゆずたそ，インプレス R&D，2020年4月3日）を読了。

サービス内容は「ひとことで言える」ことが大事です。機能が多すぎると，結局何のためのサービスか分からなくなります。開発の負担も増えます。まずはひとつの機能に絞りましょう。（位置 No. 284）

機能が多いと，何のサービスなのかわからなくなる。

英語が得意でなくても，google 翻訳を使えばそれなりの英語になります！コツは，日本語を翻訳した後，さらに英語を日本語に翻訳すること。読める日本語かチェックし，読めれば問題ありません。意味不明なら，微調整して再度翻訳を繰り返しましょう。（位置 No. 1263）

英語で発信するときのテクニックとして覚えておこう。

ここまで小さいと滅多に不具合も出ないし，仮に何かあってもすぐに直せます。いわゆる MVP (Minimal Variable Product) という考え方です。MVP の状態で長期運用できるように設計しておくと，芽が出るまで放置して育てることができます。（位置 No. 2946）

まずは，ミニマムなサービスを完成させる。

「エンジニアは 2 度以上同じ作業をしたら自動化するべき。」

会社のエンジニア上司に言われた一言です。

その言葉にならって「自分の作業を定型化できるものはないかな？」「自動化する余地はないかな？」と，社内でも趣味の時間でも常に自動化の機会をうかがっています。（位置 No. 3071）

「エンジニアは 2 度以上同じ作業をしたら自動化するべき。」は，わかっているが，いつも実践できているわけではない。

Slack や Twitter，日常の会話の中で「xxx が面倒くさい」「xxx できるともっとイイ」のようなメッセージを見つけます。共感できる課題があれば，頭の中でざっくりと設計してみます。実現できそうだと判断したら，短期間で「えいや！」と作ります。それを「どやっ！」と提供して，フィードバックを楽しみます。（位置 No. 3415）

「不」を解消するサービスを企画して，開発する。