機能は真似ていい。真似ないのはコードとデザインと名前でした

作ろうとしているものが、世の中にすでにあるサービスとほぼ同じでした。

気になったのは1点です。これはパクリになっていないか。
ポートフォリオとして人に見せるものなので、余計に引っかかりました。

線引きを調べて整理したら、かなり気が楽になりました。

整理した線引き

一般論として調べた限りでは、こういう分かれ方をしていました。

著作権が守るのは表現であって、その下にあるアイデアは守らない。
これが著作権制度の基本的な原則として説明されているもので、調べた範囲ではどこも同じ書き方でした。

ただし、アイデアと表現の境目は必ずしもはっきりしないとも書かれているので、「機能が同じなら何をしてもいい」とは読まないほうがよさそうです。
自分は表の下3行を守る運用にしました。

気が楽になった理由

整理してみて、引っかかっていたものが3つに分解できました。

ひとつ目は、機能が同じであること自体は問題にならないと分かったこと。
そうでなければ、世の中に同じジャンルのアプリが複数存在できません。

ふたつ目は、やってはいけないことが具体的だったこと。
コードをコピーしない、画面を見ながらデザインを再現しない、名前を似せない。
この3つは、意識すれば守れます。

みっつ目は、判断を毎回やり直さなくてよくなったこと。
表の形にしておけば、次に似た不安が来たときは表を見るだけで済みます。

一番効いたのは、READMEに書くことだった

対処として効いたのは、意外と単純なことでした。

READMEに「既存のサービスを検討した」と書くことです。

何を見て、どこを参考にして、どこを変えたか。これを書いておく。

隠すと後ろめたくなります。
でも書いてあれば説明になりますし、参考にしたと書いてあるものを盗んだことにはなりません。

ポートフォリオとして見せる場合、むしろ調査したことの記録になりますし、
似ているものを知らずに作っていた、より説明がつきやすいと思いました。

「パクリに見える」と「パクリである」は別

途中で気づいたのが、自分が心配していたのは前者だったことです。

コードもデザインも真似ていないので、後者ではありません。
気にしていたのは「見た人にそう思われないか」でした。

前者は説明で消えます。書いておけば済む話でした。

定番のアプリを作るのは減点になるのか

もうひとつ、ずっと気にしていたことがあります。
「よくある題材のアプリだと評価が下がるのでは」という不安です。

これも調べました。

未経験からの転職でうまくいった事例を9件集めて、共通している要素を数えました。
出てきたのは、動機の説得力・README・ER図・画面遷移図・TypeScriptの使用・継続の記録です。

新規性やオリジナリティは、入っていませんでした。

そもそも、着想元にした事例のひとつは「Zennの記事を取得して表示するブログ」で、
別の事例は「シンプルなレスポンシブの自己紹介サイト」でした。
どちらも珍しくありません。

見られていたのは題材の珍しさではなく、なぜあなたがそれを作ったかのほうでした。

気にしていたのは自分だけだった

記録を見返すと、この手の揺らぎは4月以降で5〜6回目でした。
毎回、似たようなことで手が止まっています。

今回は表の形で残したので、次に同じ不安が来たら読み返せます。

作りたいものが既にあるというのは、その需要が確認できているということでもあるので、そう考えると悪い状況ではありませんでした。