この記事は、技術の解説ではなく、学び続けるための考え方や取り組み方についての記事です。
みなさんは普段、学び続けるためにどんなことをしていますか？
特に初学者の方やIT業界へ来たばかりの方は、まだ自分に合ったやり方を模索しているかもしれません。
そんな方に向けて、自分がどうやって学び続けているのかを、この記事で紹介できたらなと思います。
株式会社日本システム技研でWebアプリの開発をしている、kanayamaです。
最近はフルスタックで開発するようになり、学ぶ範囲がぐっと広がりました。
でも入社したての頃は、どう勉強したらいいのか、そもそも何を勉強したらいいのかもわかりませんでした。すごく悩んで、よく先輩に相談していました。
この記事で紹介するのは、そんな自分が仕事と個人開発の中で見つけた、自分なりのやり方です。
まずは、お仕事に全力で
いきなりですが、まずはお仕事に全力で取り組んでください。
やはり、仕事の中で学ぶのが一番効果的だと思います。
……そんなの知ってるよ、と思われたかもしれませんね笑
では、こうしましょう。
自分は、なぜ仕事での学びが一番多いと言ったのでしょうか。
考えてみてください。
いろいろな意見があると思いますが、自分は次の3つだと考えています。
- やらなくてはいけない状況がある
- 予算や手段に制限がある
- 相談できる相手がいる
仕事である以上、品質を上げて成果を出さなくてはいけません。だから、必然的に知識がついていきます。
また、限られた予算や手段の中で、要件やお客様の意見を反映しなくてはいけません。当然、試行錯誤しますよね。
そして、自分の判断は正しいのか迷ったときは、先輩や上司に相談できます。
この3つが、仕事で学び続けられる基盤になっています。
結論：同じ状況を、個人開発で作ればいい
ここまで来れば、答えはシンプルです。
学び続けたい、学び方を知りたいと思うのであれば、仕事と同じような状況を自分で作ればいいのです。
……そんなの難しくてできないでしょ、と思われるかもしれません。
でも、完璧に再現する必要はありません。ちょっとした工夫で、それに近い状況は作れます。
では、どうすれば良いのでしょうか。
おすすめは個人開発です。自分の学びたいことを自由に盛り込めるので、非常に有効です。
ただし、リリース前提で考えてください。
誰かに使ってもらうとなると、要件や品質を真剣に考えるようになります。
それに、運用にかかるお金、つまり予算のことも考え始めます。
無料でリリースする方法もありますが、「無料枠に収まるのか」「超えたらどうするのか」を考えること自体が、予算を考えるということです。
先ほどの3つは、個人開発では次のように再現できます。
| 仕事にあるもの | 個人開発での作り方 |
|---|---|
| やらなくてはいけない状況 | やる理由を作る |
| 予算や手段の制限 | 予算と品質を自分で決める |
| 相談できる相手 | AIやコミュニティを頼る |
1. やる理由を作る
なかなか続かないのであれば、やらなくてはいけない理由を作りましょう。
理由はなんでも構いません。
2. 予算と品質を自分で決める
ここが一番のポイントです。
「なるべくお金をかけたくない」「0円で作りたい」というのも、立派な制限です。
ただ、それだけだと仕事の制限とは少し違います。
| 予算 | 品質 | |
|---|---|---|
| 個人開発（費用だけ決めた場合） | 決まっている | 下げて調整できる |
| 仕事 | 決まっている | 要件なので下げられない |
個人開発で費用だけを決めると、困ったときは品質の方を下げれば済んでしまいます。
一方、仕事では「ここまでは必ず守る」という品質も要件として決まっています。どちらも自分の都合では動かせないので、その間で試行錯誤することになります。
なので、予算だけでなく、守るべき品質（データの整合性、可用性、セキュリティなど）も先に決めてください。
両方が決まっているからこそ、ぶつかったときに本気で悩みます。その悩みが学びになると思います。
3. AIやコミュニティを頼る
相談相手がいないなら、最近はAIを壁打ち相手にできます。
Xなどのコミュニティに助けてもらうのも良いと思います。
実際に自分がやっていること
ここまでの内容は、自分が個人開発と仕事の中で体験してきたことです。
具体例を紹介します。
やる理由をこじつける
自分はいま、社内向けアプリを個人開発で作っています。
もともとは自分で使いたくて考えていたアプリです。
ただ、「自分が使わなくても、社内の誰かは使ってくれるはず。せっかく社内向けに作るなら、ちゃんと設計から続けよう」という理由で開発しています。
正直なところ、自分の学びのために理由をこじつけている感じです。
でも、他の人に使ってもらう前提だと、品質も自分の都合だけでは下げられなくなります。
制限をかけたことで見えたこと
このアプリは、なるべく費用をかけないように、Cloudflareだけで完結するように設計しました。
ところが、ここで問題が見つかりました。Cloudflareの提供しているDBサービス「D1」には、完全なトランザクション機能がなかったのです。
似たようなことができる機能はあるものの、このアプリに必要な機能は揃っていませんでした。
ここで、個人開発と仕事の違いがはっきり出ます。
以前の自分なら、なるべく安く済ませられる選択肢を選び、必要なら品質の方を妥協していたと思います。これだけでもかなり勉強になります。
でも仕事なら、データの整合性は譲れない要件です。予算の範囲で別の方法を探すのか、費用をかけて構成を変えるのか。予算と品質の両方を見ながら判断しなくてはいけません。
そこで今回は、仕事と同じように考えてみました。
「Cloudflareだけで完結させる」という方針は手放し、D1以外のDBを検討しました。候補はAmazon RDSやPlanetScaleなど、いろいろありました。
このとき、候補の比較はAIに相談しながら進めました。
最終的に選んだのはSupabaseです。
費用と要件を照らし合わせて、このアプリならSupabaseで事足りると判断しました。
一番安いものでも、一番高機能なものでもなく、要件を満たす中で費用に見合うものを選ぶ。まさに仕事でやっている判断だと思います。
だからこそ、なるべく具体的に、実際の仕事に近い制限をかけるのがおすすめです。
しかも、ここまでの話はすべて、実装に入る前の要件定義・設計・技術選定の段階で起きたことです。実装しなくても、こういった壁にはちゃんとぶつかれます。
続かないときはハードルを下げる
先ほど「リリース前提」と書きましたが、実際にリリースまでやりきる必要はありません。大事なのは、本番で使われるつもりで要件や品質、予算を考えることです。
開発を継続するのが大変なら、実装はしなくて構いません。
作りたいシステムの要件定義・設計だけをやってみてください。それだけでも得られるものはとても多いです。
ワクワクするものなら、自然と実装したくなると思うんです。
また、インフラで料金を発生させたくないなら、要件定義・設計、もしくは実装までにとどめましょう。
インフラは構築せず、模擬練習の形でも十分身につきます。
まとめ
- 仕事で学べるのは「やらなくてはいけない状況」「制限」「相談相手」があるから
- 個人開発で、この3つを自分で作る
- 特に、予算だけでなく守るべき品質も決めて、仕事に近い制限をかけるのがポイント
- 続かないときは、要件定義・設計だけでもOK
自分はこういった経験から、学び続けるための基盤を少しずつ作ってきました。
もし学び続けるのが苦しくなったら、「こういう自分の乗せ方もあるんだな」と思い出して、参考にしてもらえたら嬉しいです。
みなさんの学びと成果物が、より良いものになりますように。