2020年版「よっしゃWebアプリ作って面白いことしたろ！」と思い立ったときに読む記事

この文書は、
「よっしゃWebアプリ作って面白いことしたろ！」
と思い立った方向けに
2020年版のオススメの方法を書きます

私自身が、そう思ったタイミングで書いてます

読みづらい点もあるかと思うので予めご了承ください
途中ではしょりすぎている部分は、必要に応じて追記していきます

登場する技術：
Git, Github, Visual Studio, ASP.Net Core, C#, Angular, TypeScript, Azure, App Service

アジェンダ

第1章 つくるものを決める
第2章 つくる
第3章 使う＆使ってもらう

第1章 つくるものを決める

何らかの動機でつくりたいものが出てきた
または、特に決めてないけど何かアクションを起こしたい

技術を度外視してつくるものを決めたいところですが、
個人でつくるものには、「予算（お金）」、「時間（作業量）」に制限が掛かってきます

そこをカバーするのが「技術力」です
お金を掛けずに、時間も掛けずに実用化に耐えるものをつくることは可能です

「～を記録するアプリをつくりたいな」
「～を検索するアプリをつくりたいな」
「写真を撮って～のAPIで加工するアプリをつくりたいな」

最初は、このくらいの簡単なものを目標にしてみてください
いきなり、何でもできるものをつくろうとしたら、必ずと言っていいほど途中で投げ出してしまいます

その後、重要になってくるのが、
そのつくりたいものを構成する要素は何かを考えて、「プロダクトバックログ（完成形に対して足りていない要素）」として箇条書きしていくことです

この「プロダクトバックログ」という用語は、開発用語なのですが、
何をするにしてもゴール・有るべき姿というものがあって、それまでの道のりというものがあるはずで、
それを表現する言葉だと捉えていただければよいかと

箇条書きしていく先は、GithubのIssueがオススメです

何も無い状態からプロダクトバックログを書き起こしていくのは技術が要りますが、
まずは基本となる操作を箇条書きしていき、それに付随する操作や機能追加を足していけば良いと思います
逆に、管理者権限を用意して、管理者のみが実行できるようにするという制限を掛けるバックログというものもあるはずです

箇条書きできたら、それらに「優先度」を付けます
最もやりたいことを最優先として、それらに付随することや操作性向上はそれよりも優先度を下げます
やりたいんだけど最優先ではないな～というものも、とりあえず箇条書きして、優先度低で登録しておきます
この「やりたいんだけど・・・」という部分が、このプロダクトの最も重要なファクターになってくるので忘れずに

Github Issue では、優先度をタグとして表現するのがオススメです

こんな感じで分類すると良いでしょう。意味合いは以下の通りです
bug-high ・・・ 重大なバグ。基本的な操作が出来ない状態。最優先
bug-low ・・・ 軽微なバグ。後々対応していく
enhance-high ・・・ 優先度の高い機能追加
enhance-low ・・・ 優先度の低い機能追加
future-feature ・・・ 将来的にやりたいな～ということ
kaizen ・・・ 機能追加ではないが、改善したいこと

さあ、Github Issue に書き出せましたか？

これにて、つくるものを決めるというフェーズは完了と言いたいところですが、
これらのフェーズは、一方通行ではないので、行ったり来たりします

先に進みましょう

第2章 つくる

つくる方法としてオススメしているのが、
ASP.Net Core ✕ Angular です

「うわぁ・・・なにそれ意味分かんない・・・」

そんな声が聞こえてきます

そして、それらと親和性の高いAzure のApp Service で稼働させます

さらに意味わかんねーよ、という声が出てきそうですね

ここで挫折する方が大勢だと思います

上記未経験の私でも、3ヶ月程度でだいたい使えるようになりました
プログラミングについて全く経験の無い方に対しては、これは良い機会です
1ヶ月単位でメキメキと技術力が上がっていくことが実感できるので、めちゃくちゃ楽しいです
苦労するだけ自分の成長が期待でき、じきに「苦労している状況」に身を置かないと居ても立ってもいられなくなるようになるでしょう

手順をザッと書きます

① Gitリポジトリを用意する
② VisualStudioを使って、ASP.Net Core ✕ Angular のテンプレートでプロジェクト新規作成（ここで一度リポジトリにプッシュ）
③ 機能追加（追加するたびに、リポジトリにプッシュ。対応するIssueと紐付けてCloseしていく）
④ Azure App Service にアップロードして公開する

以上

①、② は、最初に1回だけ、
③は、Issueの数だけ繰り返す、
④は、パブリックなWebアプリとして公開したいタイミングで行います

IssueがCloseされるたびに、徐々に出来上がっていくことでしょう

ある程度形になった時点で、Lightning Talkの場にでも持っていって話すと、良いと思います
人からの意見に左右されないように、自分がやりたいようにやっていくことが最初は大事です

途中で投げ出すのも、自身の意思です
どこで投げ出そうが、そこまでやったという結果は紛れもない事実です

失敗は無いと思います
全てが自身を構成する要素なので、ただひたすらに行動あるのみです

次に進みましょう

第3章 使う / 使ってもらう

ある程度形が出来てきたら、自分で使ってみます
（自分で使えるアプリになっている時点で、もう一種の成功と言ってもよいかと思います）
すると、使いづらい点、もっと欲しい機能が出てくるかと思います

また、信頼できる知人がいれば、使ってもらうのも良いでしょう
当初に、「〇〇グループの人に使ってもらいたいなー」という思いがあれば、その方々に使ってもらうのがよいです
ただし、興味を持ってもらえない相手からは良い意見は出てこないです

人に見せて褒めてもらいたい、なんていう承認欲求は捨てて、ただガムシャラに創作に取り組むのです

それが無駄足だったとしても、必ず自身のキャリアになります

あとは、これら挙がってきた改善事項をIssueに書き起こして、つくって、使って、を繰り返すだけです

第4章 事業化

第3章で終わりかと思いきや、その後の展望を書きたいと思います

使えるアプリが出来たら、それを事業として起こすことを考えてみます
そのためには、ビジネスモデル というものが必要になってきます

どうやってお金をもらうか、なぜユーザはお金を払ってくれるのか

お金を支払う仕組みが複雑だと、ユーザは登録してくれません
既に無料で使えるものに対しては、ユーザはお金をはらってくれません

お金を支払う仕組みについては、既存のプラットフォームに乗せる、広告費で稼ぐが挙げられます
一方、ユーザが「これを使いたい！（他じゃ出来ない）」と思ってくれることについては更に深く考える必要があります

ここで、第1章で書いた「やりたいんだけど・・・」という部分が、重要になってきます
簡単に実現できてしまうことは、他の人も考えて実行していることです

想像付かないような斬新な試み、普通じゃありえない組み合わせ、
そして他人が真似できないような要素を使って今後の展望を考えてみるのもよいかと思います

サラリーマン開発者に向けて

私自身、月々の給料をもらってはたらくサラリーマン開発者です
このサラリーマン開発者にこそ、事業化の考えをもってもらいたいと思っています

この事業はいつ黒字化するのか
この開発は、いつリリースされて、どのくらいのユーザ数が見込めるのか
このタスクをこなしたら、どれだけの利益貢献ができるのか

皆様一人ひとりが信念を持って開発に取り組んでもらえることを願っております

おわり