はじめに
この記事は、高校一年生が初めて個人開発を行う上でプログラミングや技術的な面とは別の面で苦労した点やプログラミングはあくまで目標を達成するためのツールなんだ！ということを気づくきっかけとなった話を主にしています。
個人開発というものはこうしなければいけないといったルールがないが為に何をすればいいのかが分からなかったりします。そこでこの記事を通して何か参考になる点があれば幸いです！
目次
わたしはだれ？
私は、高専ではなく 普通科高校に通う高校一年生です。(2020年現在)
高専ではなく 普通科高校です。よく間違えられるので二回書きました。
主にはウェブ系と呼ばれる言語を得意としますが、Pythonなども再び興味を持ち始め遊び感覚で触っています。
作成しているもの
現在作成しているものは、現在わたしの学校においてこんなサービス・アプリがあるとこの問題は解決されるのではないか！という発想から生まれたものです。
もともと学校の現状として、希望した生徒のみがお昼ご飯を購入できる制度があるのですが、その商品の注文は一時間目の授業後の間にクラスの代表者に頼みお金を渡し集計してもらうとすぐにお弁当を販売している業者さんのもとへ直接行かなければならないという様なものでした。
事実ベースで見ると以下のような問題がすでに存在していました。
- 注文の集計にミスが発生してしまう
- 授業の間の休み時間なので次の授業に間に合わない
- だれが注文しているかわからなくなってしまう
- コロナ禍の状況で直接会って購入しなければならない
- 毎日商品が変わるので今日は何が販売されているか直接行って確認しないといけない
毎日のようにミスや問題が発生しているという事実から何か変化を起こし、今までとは違ってもっと簡単に・もっと手軽に・もっと便利にならないのかと考えた結果 ウェブアプリケーションを用いて商品の注文を行い、だれがいつ注文して支払いはしているのか？を自動で管理してくれるようなアプリケーションを企画・開発する様になりました。
さぁ！実装の前に
「こんなサービス・アプリケーションがあったらいい！」と思い付いているなら早く手を動かして開発をしたらいいではないか！と昔の私はそう考えてすぐにコードを書くということをしていました。
ただ、これって結構本末転倒してしまうことが多いんですね。。中でも起きたのが、「この機能いる？」「これってだれが使う機能だっけ？」「なんの権限が必要なの？」など具体的な要件や方針が決まっていなかったのです。そこで私はプログラミングする前の大きく分けて必要だった4つの工程の中で3つの工程を飛ばしていることに気づきました。
このプロジェクトの工程というのは、プログラミングするということと違って、ルールや制約もないので極端な話自由です。ただ、必要な工程を飛ばしていると壁にぶつかってなかなか思うようにプロジェクトを進めることができないなどそれによる副作用は数多く存在することを身をもって体験し、必要な工程は具体的に何があるのかを調べることにしました。
中でもとても参考になったのが引用: 要件定義～システム設計ができる人材になれる記事というものです。下記のプロセスにおける図を引用させてもらったのですが、企画と実装の間に大きく3つのプロセスがあります。
- 業務設計
- 要件定義
- 設計
こちらについては、下記の記事にてとても詳しく記載されているため、ここでの説明は割愛させていただきます。
フレームワークという存在
今は昔、まだプロジェクトの初期の段階の話です。当時はログイン関連の処理をフレームワークやライブラリを使用せずに作っていました。しかし、そのログイン方法の仕様を変更したいとなった時修正がなかなか大変でした。そこに現れたのが Laravel というフレームワークでした。
Laravelはログイン・認証関連のパッケージが用意されており、カスタマイズも容易に行えるPHPのフレームワークです。意外と最初の個人開発でありがちなのが、フレームワークを使用しないということです。フレームワークを使用することで、セキュリティの面もフレームワーク側がある程度サポートしてくれるので是非使用を検討してください。
ちょっとくらゐPHPで動くコードが書けるようになっていい気になってるのかもしれないが、初心者こそフレームワークが必要なことは確定的に明らか。急げば回れという名セリフを知らないのかよ。
初心者を戒めるPHP - Qiita
技術的な問題
上の図はプロジェクトのcommitに基づいて作成されているGitHubで確認することができるグラフです。最初はフレームワークについて理解ができていなかったためcommit数が低いものの次第に理解できた部分が増え、グラフが上に上がってきます。ただ、ある時を境にガクンと落ちてしまっています。何が起きていたかというと DB構造・リレーション の部分でつまづいてしまいました。1つのテーブルから該当するだけのデータを取得・作成・変更することはできても複数のテーブルか関係してくるとなかなか思う様に取得することができませんでした。
このように躓く箇所が人によって違っても、個人開発となるともちろん自分の今のスキルだけでは解決が困難な場合は必ず訪れてくるかと思います。その場合実際に自身がどのように進んでいったのかを3つに分けて紹介したいと思います。
ドキュメントを読む！
どの言語でも必ず学習する際は公式のドキュメントを確認するはずです。言語以外でもライブラリ・フレームワークのドキュメントも存在してきます。沢山の人が色々な記事に分かりやすく説明をしているのですが、一番信用していいものは公式ドキュメントに限ります。
先述したように私の場合は、データベースのリレーションの部分でかなりてこづりました。ドキュメントに記載されているものを確認してみるものの堅苦しい言葉でなかなか理解に苦しみました。ドキュメントに記載されているもので説明が不十分であったり、理解できない部分がある際は次に書かれている記事を探すというのは個人的にとてもいいと思います。
公式Docを確認する -> 分かりやすい記事を確認する
ひたすらGoogle先生
自分の行いたいことの8割以上は先人がすでにやっている。といったことを聞いたことがあるのですが、実際にGoogleで調べてみると自分の行いたいこと・実装内容を先人の先輩方が行っており、丁寧にその際の実現方法も記載してくれています。
Hello コミュニティ
多くの有名で人気なプログラミング言語やフレームワークではコミュニティというものが存在します。DiscordであったりSlackであったりとその存在は各々で違うのですがたくさんのユーザが存在し、質問することができます。
ただ、多くのコミュニティは日本人のためだけのものではないので英語を使用して質問・会話していきます。こちらは英語が苦手な人だとかなり難しいかもしれないですが、英語の良い勉強にもなるかと思います！
初めての個人開発から得たこと
- 最初から完璧を求めない
- 一度に全ての機能を求めずに1つずつ作っていく
- DB設計は大切！
実際の運用の前に
実際の運用の前に、著作権や情報漏洩について意識しなくてはならない問題もあります。そちらについては、過去の判例を読み解き実践で使えるノウハウを詳しく解説している著書があります。
こちらは、個人開発の視点を中心に記載されたものではないため、会社や団体に属する方のほうが、参考になるかも知れませんが、とてもおすすめできる著書となっております。
成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック - Amazon
※アフィリエイトではありません
まとめ
自分で問題を見つけ、何が問題なのか問題分析を行い、それに基づいた仮説を自分で立てる。ではその仮説に基づいて自分では何ができるか考え、企画し、何かを作るということ。
この一連の流れを通して問題解決とその改善を行っていくことができることがわかりました。この個人開発をするまでは、プログラミングのある言語の文法ばかりを学習していました。ただ、実際に開発してみるとその文法というのは全てが全て必要というわけではないのです。。もちろん一定量の知識は必要不可欠ですが、適時ドキュメントを確認するくらいで、プログラミングというものはある問題や実現するためのツールでしかないということに気づきました。プログラミングで何を作るかということも重要だとは思いますが、何を得るか？が重要になってきてその手段がプログラミングだと思います。
まだ、身の回りにはたくさんの問題が存在します。来年はより多くの問題に挑戦したいと思います。
最後まで読んでいただきありがとうございます！
ぜひ、参考になった際や共感する部分があった際はLGTMを押していただけると幸いです!!
それでは少し早いですが良いお年を！