はじめに
普段はトラックドライバーとして働いています🚛。
IT業界での実務経験はなく、Web開発を学び始めて約3カ月半。
まだまだ学ぶことだらけの初心者です🔰。
最初の頃は、自分もよく考えていました。
Pythonの次は何を勉強しよう？
Flaskの次は？
SQL？ Docker？ Rails？
次は何を覚えればいい？
そして、技術の名前を調べれば調べるほど思います。
いや、覚えること多すぎない……？👀
Web開発には、本当にたくさんの技術があります。
全部必要そうに見えるし、知らない言葉を見つけるたびに、
「これも勉強しないといけないのか」👀
と焦ってしまいます。
でも、個人開発を続けていて気づきました。
「今すぐ全部を覚えようとしなくてもいい」
大事なのは、
今、このシステムの何が分かっていない？
と考えることでした。
必要になったときに立ち止まって調べる。
理解したら実装して、確認して、また進む。
自分の場合、この繰り返しで学ぶ範囲が自然に広がっていきました。
最初は3件しかなかったpytestも、
3
↓
9
↓
51
↓
69
↓
87
↓
91
↓
114
↓
169
↓
181
↓
195
↓
201 passed
まで増えています。
201件はゴールではありません。
Guest Demo第4段階終了時点での通過点です。
開発はまだ続いているため、新しい問題が見つかればpytestもさらに増えていくと思います。
pytestを育ててきた過程は、これまで段階ごとに記事として残しています。
🧪 pytest強化シリーズ 👈️（タップで開きます）
この記事はpytestの書き方を解説する記事ではありません。
pytestを知らなくても大丈夫です。
今回は、個人開発を続ける中で、
「次に何を勉強するか」を探す学び方から、「今分からないこと」を掘る学び方へ変わった話
を書いてみます。
🐹この記事を3行でまとめると
- 「次に覚える技術」を探すより、開発中に出てきた**「分からない」**を掘るようになった
- 必要な場所を掘っていたら、DB・認証・認可・セキュリティ・CI・Mutation Testingなどへ自然に学習範囲が広がった
- 個人開発は、完成品を作るだけでなく自分が何を分かっていないのかを見つける場所になった
「次は何を勉強する？」をやめた
学習を始めた頃は、
Python
↓
Flask
↓
SQL
↓
Docker
↓
Rails
↓
クラウド
↓
さらに次の技術……
というように、
技術を順番に覚えていくもの
というイメージを持っていました。
もちろん、広く技術を知ることが悪いわけではありません。
知っている技術が増えれば、
「この問題には、こういう方法が使えるかもしれない」
という選択肢も増えます。
でも自分の場合、個人開発を始めてから少しずつ進み方が変わりました。
たとえば、
sales_data_appを開発
↓
「失敗したあと、DBは本当に元に戻っている？」
↓
rollbackを調べる
↓
pytestを追加
DBへの書き込み失敗やrollbackまで確認するようになった過程は、pytest強化シリーズの第2段階でも記録しています。
別の日には、
「ログインしていない人でも入れてしまわない？」
↓
認証を調べる
↓
Flask-Login
↓
アクセス制御
↓
pytest追加
さらに、
「全部GREENだけど、本当にバグを見つけられる？」
↓
Mutation Testing
Guest Demoを追加し始めると、
「Guest AにGuest Bのデータが見えてしまわない？」
「GuestからAdminへ越境できてしまわない？」
「AIに別Datasetのデータが混ざってしまわない？」
↓
認可
Dataset境界
セキュリティ
pytest追加
となりました。
最初から、
次は認可を勉強しよう。
Mutation Testingを覚えよう。
と決めていたわけではありません。
必要になったから調べました。
pytest 3件を積んで出発した
冒頭で書いた通り、自分の本業はトラックドライバーです。
なので、この学び方を運行に例えるとかなりしっくりきます。
最初は、
🚛 sales_data_app
荷台
📦 pytest
📦 pytest
📦 pytest
くらいの状態で出発しました。
走っている途中で、
👀「失敗したあと、DBは本当に元に戻ってる？」
という気になる場所を見つけます。
一度停車。
調べる。
必要な修正をする。
pytestで確認する。
問題がなければ再出発します。
🚛💨
また進むと、
👀「認証されていない人が入ってきたら？」
と気づきます。
また停車。
認証を調べます。
実装します。
pytestを追加します。
さらに進むと、
👀「CSRFは？」
👀「XSSは？」
👀「このGREEN、本当に信用できる？」
また寄り道です。
そうして気がつけば、
Python
Flask
PostgreSQL
SQLAlchemy
Alembic
Docker
pytest
GitHub Actions
Mutation Testing
Authentication
Authorization
セキュリティ
Dataset
Git
Codex
AI
と、扱う技術や考える範囲が増えていました。
でも、自分の中では、
たくさんの技術を集めた
という感覚はあまりありません。
ほとんどが、
sales_data_appを前へ進める途中で必要になったもの
です。
「分からない」は邪魔ではなく、次の教材だった
個人開発を始めたばかりの頃なら、
動いた！
だけで嬉しくなります。
自分もそうでした。
でも同じシステムを育て続けていると、少しずつ見る場所が変わってきます。
たとえば、
保存できた。
だけでは終わらなくなります。
次に、
不正な値が来たら？
と考えます。
さらに、
DBへの書き込み途中で失敗したら？
同じデータが二重登録されたら？
過去のデータまで壊れない？
と、次々に疑問が出てきます。
一つ理解すると、
以前は見えていなかった次の問題が見える。
これは結構面白い変化でした。
「分からないことが増えた」というより、
分からないことを見つけられるようになった
のだと思います。
自分にとっては、この「分からない」が次の教材になっていきました。
自分の学び方を「モグラ式学習法」と呼ぶことにした🐹
ここまで振り返ってみると、自分の学び方には一つ特徴がありました。
一本道をずっと進むのではなく、
「分からない」を見つけるたびに、いったん横へ掘っていく。
そこで勝手に、
「モグラ式学習法」
と呼ぶことにしました🐹。
最初は、小さな穴が一つあるだけでした。
個人開発
│
└── 🕳️ pytest
その穴も、最初は浅いものでした。
pytestって何？
↓
正常系を確認してみる
↓
異常系も確認する
↓
失敗時のrollbackまで確認する
↓
境界条件も確認する
↓
Mutation Testingで
「テストそのもの」まで確認する
同じpytestという穴でも、掘り直すたびに少しずつ深くなっていきました。
一方で、新しい穴も増えます。
🕳️ pytest
/
個人開発 ───── 🕳️ DB
\
🕳️ セキュリティ
\
🕳️ 認証
\
🕳️ 認可
\
🕳️ Dataset
開発を始めた頃より、
穴の数が増えました。
そして、
一つ一つの穴も深くなりました。
さらに、
穴と穴の距離も広がりました。
最初は、
画面が動くか。
という近いところだけを見ていたのが、
今では、
DBが壊れないか。
認証されていない人が入ってこないか。
別Datasetへ越境しないか。
AIへ渡すデータに別の利用者の情報が混ざらないか。
というところまで見るようになっています。
技術名だけを見ると、ずいぶん遠くまで来たように見えます。
でも自分としては、
必要になった穴を、一つずつ掘ってきただけ
なんです。
モグラが掘る場所は「システムの穴」でもある
ここでいう 「システムの穴」 は、バグやセキュリティホールだけを意味しているわけではありません。
- まだ確認できていない場所
- 自分が理解できていない仕組み
- 将来問題になりそうなのに、まだ守れていない部分
こうしたものも含めて、この記事では「穴」と呼んでいます。
たとえば、
「失敗したらDBは大丈夫？」
という穴をシステム側に見つける。
そこから、
rollbackとは？
transactionとは？
pytestでどう確認する？
と、自分の知識を掘っていきます。
理解できたら実装して、pytestで確認する。
すると、最初に見つけたシステム側の穴を補強できます。
システムの「穴」を発見
↓
🐹
調べながら掘る
↓
自分の知識が深くなる
↓
実装する
↓
pytestで確認する
↓
システムの穴を補強
そして面白いのは、ここからです。
自分の知識が深くなると、
以前なら気づかなかったシステムの穴まで見えるようになります。
また穴を発見する。
また掘る。
また理解する。
またシステムを補強する。
システムが育つ
↓
新しい穴が見える
↓
🐹
↓
自分が育つ
↓
システムがさらに育つ
この繰り返しです。
pytestは「多分大丈夫」を止めてくれる
開発が大きくなってくると、
一度画面で確認したから大丈夫。
では確認しきれなくなります。
そこでpytestに確認を任せます。
トラックの仕事でも、
積み込み
↓
数量確認
↓
荷姿確認
↓
出荷前確認
↓
問題なし
↓
出発 🚛💨
と、いくつもの確認があります。
開発でも、
機能追加
↓
pytest
↓
RED
↓
停止
↓
原因確認
↓
修正
↓
GREEN
↓
次へ
という流れになりました。
作った本人が、
多分大丈夫。
と思っていても、テストがREDなら一旦止まります。
自分の注意力だけに安全を任せない。
この考え方は、本業で行っている安全確認ともかなり似ていると感じています。
GREENなのに安心できなくなった
pytestを増やしている途中で、今度は別の疑問が出ました。
全部GREENだけど、このテストは本当にバグを見つけられるの？
そこで試したのがMutation Testingでした。
コードを意図的に少し変えて、
pytestがその異常を検出できるか
を確認します。
すると、
SURVIVED
するMutationがありました。
つまり、
pytestは全部GREENなのに、その変更を見逃していた
ということです。
そこで既存テストを見直し、必要なケースを追加します。
もう一度Mutationを入れ、
KILLED
になることを確認します。
このときの試行錯誤は、こちらの記事に残しています。
ここでも、
Mutation Testingを勉強しよう！
と思って始めたわけではありません。
pytestを育てていたら、
このテスト、本当に意味ある？
という新しい穴が見えた。
だから、また掘りました🐹。
Guest Demoを作ったら「認証」だけでは足りなかった
最近は、sales_data_appを誰でも体験できるGuest Demoへ育てています。
Guest Demoそのものも、一気に作ったわけではありません。
最初に既存AdminデータをDatasetへ移し、Guest領域を作るための土台を整えました。
その後、
第2段階①：Admin保護・Guest identity・Dataset認可の土台
と進めました。
最初は単純に、
ゲストでも触れるようにしたい。
という話でした。
ところが実際に考えてみると、
Admin
Guest A
Guest B
という複数の利用者が存在します。
すると、
Guest AにGuest Bの商品が見えてしまわない？
GuestからAdminの商品を書き換えられてしまわない？
Dashboard集計に別Datasetの商品が混ざらない？
AIへ渡すデータに別Datasetの売上が混ざらない？
と、次々に穴が見えてきました。
ここでは、
Authentication（認証）
だけでは足りません。
この利用者は、このデータへアクセスしてよいのか？
を見る、
Authorization（認可）
が必要になります。
そこで、同じDBの中でもDataset単位でデータを分離しました。
Admin Dataset
├─ Product
└─ DailySales
Guest A Dataset
├─ Product
└─ DailySales
Guest B Dataset
├─ Product
└─ DailySales
そしてpytestで境界を確認します。
Admin → Admin Dataset OK
Guest A → Guest A Dataset OK
Guest A → Guest B Dataset NG
Guest A → Admin Dataset NG
Guest B → Guest A Dataset NG
このDataset境界を本格的に固めたのが第3段階です。
Guestを通す前に「越境」を潰す。pytest 181→195件でDataset境界を固めた
Guest Demoという一つの機能を作りたかっただけなのに、
Guest Demo
↓
認証
↓
認可
↓
Dataset境界
↓
セキュリティ
↓
pytest
と、また穴が増えました。
しかも以前より、掘る穴が深い。
これも、
開発を続けることで、以前より深いところの問題が見えるようになった
ということなのかもしれません。
201件はゴールではなく、今いる場所
ここで最初のpytestの数字に戻ります。
3
↓
9
↓
51
↓
69
↓
87
↓
91
↓
114
↓
169
↓
181
↓
195
↓
201
201件は、
Guest Demo第4段階終了時点でのpytest件数
です。
第4段階では、正規Guestを実際のルートへ通し、
195 passed
↓
Guestを実際のルートへ通す
↓
商品
売上
Dashboard
AI
の越境を確認
↓
201 passed
となりました。
第4段階の詳しい内容はこちらです。
つまり、
201 passed
🎉 完成！
ではありません。
むしろ、
201 passed
↓
次の機能
↓
また新しい「分からない」
↓
🐹 また掘る
↓
必要ならpytestも増える
です。
pytestは、件数が多ければ多いほど良いという話ではありません。
大事なのは、
- なぜそのテストが追加されたのか
- 何を守るためのテストなのか
- 本当に守りたいものを検知できているのか
だと思っています。
201という数字より、
3件から201件になる途中で、どんな穴を見つけ、何を掘ったのか
のほうが、自分にとっては大事です。
「広く浅く」ではなく、必要な場所を掘っていた
扱っている技術だけを見ると、
色々なものへ手を出している。
ようにも見えます。
でも自分の感覚は違います。
開発
↓
問題発見
↓
🐹 掘る
↓
調べる
↓
理解する
↓
実装
↓
pytest
↓
元の開発へ戻る
これを繰り返してきました。
だから、
広く浅く
というより、
必要になった場所を、その都度深く掘る
という表現のほうが自分には合っています。
最初からセキュリティ、認可、Mutation Testingまで全部覚えようとしていたら、
おそらく、
覚えること多すぎる……。
で頭がいっぱいになっていたと思います。
でも、
今、このシステムに必要なのは何？
と考えれば、目の前の穴は一つです。
その一つを掘る。
必要なところまで掘ったら、地上へ戻る。
そして個人開発を続ける。
また穴が見つかったら、また掘る。
今すぐ地下全部を掘る必要はありません。
「学習記録」ではなく「成長記録」だった
これまでGitHubやQiitaへ残してきたものを、
学習記録
だと思っていました。
でも最近は、
成長記録
のほうが近いと思うようになりました。
しかも、成長しているのは自分だけではありません。
sales_data_appも一緒に成長しています。
最初は小さかったシステムに、
売上入力
↓
Dashboard
↓
DB強化
↓
pytest
↓
CI
↓
認証
↓
セキュリティ
↓
Mutation Testing
↓
Guest Demo
↓
Dataset境界
と、仕組みが増えてきました。
それと同時に、自分の見る場所も変わっています。
「動いた！」
↓
「DBは壊れない？」
↓
「失敗したら？」
↓
「認証されていない人は？」
↓
「認証だけで足りる？」
↓
「認可は？」
↓
「別Datasetへ越境しない？」
↓
「AIへ渡すデータも大丈夫？」
最初は浅い穴しか見つけられなかった。
でも、穴を掘るたびに知識が増え、
少しずつ深い穴まで見えるようになりました。
自分が成長することで、システムが育つ。
システムが育つことで、新しい穴が見つかる。
その穴を掘ることで、また自分が育つ。
振り返ってみると、
開発者とシステムが一緒に成長してきた記録
だったんだと思います。
学習初期にRailsを触って、離れた理由
実は学習を始めて間もない頃、Ruby on Rails 8も短期間だけ触りました。
CRUDを作り、Migrationを使い、Renderへ公開するところまで試しました。
最初に感じたのは、
めちゃくちゃ便利。
でした。
一方で、
今の自分には、便利すぎるかもしれない。
とも感じました。
RailsのGeneratorやAIの助けを使えば、システムをかなり速く大きくできます。
でも当時の自分の場合、
システムが育つ速度に、自分の理解が追いつかなくなる
と感じました。
その状態で、
このファイルは何の役割ですか？
と聞かれて、
「……作った覚えがありません」
となるのが怖かった。
ここで言いたいのは、「Railsは初心者に向いていない」 ということではありません。
Railsから学び始めて、内部の仕組みまで深く理解している人もいると思います。
あくまで当時の自分には、システムの成長速度よりも自分の理解が追いつくペースで進めることを優先したかった、という話です。
そこでRailsはいったん離れ、Flaskを中心に進むことにしました。
将来またRailsを使うなら、
Flaskでは自分で考えていたこの部分を、Railsはここまで肩代わりしてくれるのか。
と理解しながら、その便利さを使いたいと思っています。
AIやCodexも「使わない」のではなく「任せ方」を考える
現在はCodexなどのAIも開発に使っています。
AIを使わないほうが勉強になる、とは考えていません。
限られた時間の中では、便利なものは使いたいです。
ただし、
まず調査
↓
変更範囲を確認
↓
小さく実装
↓
pytest
↓
差分確認
↓
次へ
という形で使っています。
自分が気をつけているのは、
「何を任せたのか分からない状態」にしないこと
です。
AIが書いたから危険なのではなく、
誰が書いたコードであっても、確認せずに進めることが危険
だと思っています。
AIに掘削機を渡しても、
どこを掘っているのか分からない状態にはしない。
モグラ式学習法でも、ここは大事にしています🐹。
コマンドを知っていることと、理解していることは違う
たとえばAlembicなら、
alembic upgrade head
というコマンドを覚えること自体は、それほど難しくありません。
でも、
なぜMigrationが必要なのか？
既存データがあるDBでは何が起きる？
Migration途中で失敗したら？
本番環境ではどう安全に変更する？
まで考えると、学ぶ内容は一気に増えます。
pytestも同じです。
assert response.status_code == 200
と書けることと、
このテストは何を守っているのか？
を説明できることは別です。
自分は、
操作方法を覚えるだけでなく、「なぜ必要なのか」を説明できるものを少しずつ増やしたい
と思っています。
穴をたくさん掘ることより、
自分が掘った穴を説明できること
のほうが大事なのかもしれません。
初心者こそ、小さな個人開発をやってみてほしい
ここまで振り返って、自分と同じような初心者の方へ一つおすすめするとしたら、
小さくてもいいので、個人開発をやってみること
です。
最初から大きなサービスを作る必要はありません。
入力フォーム一つでもいい。
データを保存するだけでもいい。
簡単なWebアプリでもいいと思います。
作っている途中で、
「これ何？」
「なんで動くの？」
「壊れたらどうなる？」
「他の人が触ったら？」
という疑問が出てきます。
教材には、
自分が次に何を分からなくなるのか
までは書いてありません。
でも自分で何かを作ると、
自分専用の「分からない」
が勝手に出てきます。
つまり、
自分専用の穴が見つかります。
そこを掘る。
調べる。
試す。
失敗する。
直す。
確認する。
そして、また地上へ戻って個人開発を進める。
そうしていると、
「次に何を勉強するか」は、作っているもののほうから教えてくれる
ようになりました。
IT業界の実務経験はまだありません
だから、これが唯一の正解だとは思っていません。
ただ、少なくとも自分にとって個人開発は、
「次に何を勉強するか」を探す場所ではなく、
「自分が何を分かっていないか」を見つける場所
になりました。
まとめ
学習を始めた頃は、
Pythonの次は何？
Flaskの次は？
SQL？ Docker？
覚えること多すぎない？
と思っていました。
でも今は、
今すぐ全部を覚えようとしなくてもいい
と思っています。
必要になったときに、その場所で止まればいい。
そして、
今、自分は何が分かっていない？
と考える。
システムの穴を見つけたら、
🐹 モグラになって掘る。
調べる。
理解する。
実装する。
pytestで確認する。
穴を補強したら、また地上へ戻る。
そして開発を続けます。
最初は3件だったpytestは、Guest Demo第4段階終了時点で201件まで増えました。
でも201件はゴールではありません。
おそらく、ただの通過点です。
大事なのは、
201
という数字そのものではなく、
そこへ来るまでに、
どんな穴を見つけ、どこまで掘ったのか
だと思っています。
最初は穴が一つだけだった。
その穴も浅かった。
でも開発を続けるうちに、
穴の数が増え、
穴と穴の距離が広がり、
一つ一つの穴も深くなっていきました。
そして、その穴の多くは、
sales_data_appの中で見つけた「まだ分かっていない場所」
から始まっています。
これから新しい機能を追加すれば、また新しい穴が見つかると思います。
そのときは、また掘ります🐹。
全部を先回りして覚える必要はありません。
必要なときに、必要な穴を掘ればいい。
これが、約3カ月半個人開発を続けてきた自分なりの、
「モグラ式学習法」
です。
この記事を読んで、
「自分は今、何を基準に次の勉強を決めているだろう？」
と、自分自身の学び方を少し振り返ってみるきっかけになれば嬉しいです。