はじめに
新人エンジニアになったばかりの頃は、学ぶことが多すぎます。
JavaScript、React、Vue、Java、Spring Boot、SQL、Git、Docker、クラウド、テスト、設計、セキュリティ……。
「何から勉強すればいいんだろう」
そう思うことは、かなり自然なことだと思います。
もちろん、基礎を学ぶことは大切です。
ただ、漠然と技術書を読んだり、チュートリアルを順番にこなしたりしているだけだと、途中でこう感じることがあります。
これ、結局どこで使うんだろう？
私もそういう感覚になることがあります。
昔から言われていることですが、学習テーマは「世の中にないすごいもの」から探さなくてもいいということです。
やはり、自分が普段感じている小さな不便を解決しようとした方が、学習は続きやすい気がします。
基礎を軽視しているわけではないです。
自分が「仕方ない」と思っていた不便
ここで、最近の自分の事例を少し紹介します。
最近、AIと相談しながら、WindowsアプリとAndroidアプリを同じリポジトリで管理する構成を考えていました。
いわゆるモノレポ構成です。
同じアプリのWindows版とAndroid版を並べて管理できるので、構成としては自然に見えます。
一方で、少し気になることがありました。
それは、コミットログが混ざって見にくくなることです。
Windows側の修正、Android側の修正、READMEの修正、記事用メモの修正などが、同じ履歴に並びます。
小さいプロジェクトなら問題ないかもしれません。
でも、あとから見返すときに、
Android版だけの変更履歴を見たい
Windows版だけの修正を追いたい
このフォルダに関係する変更だけ見たい
と思う場面があります。
以前の私は、これを「モノレポだから仕方ない」、「いっそ別々のほうが管理しやすい」と思っていました。
あるいは、「自分がGitに詳しくないから不便に感じているだけかもしれない」とも思っていました。
実はGitには、すでに解決手段がある
調べてみると、Gitにはフォルダ単位で履歴を見る方法があります。
たとえば、次のようなコマンドです。
git log -- path/to/folder
特定フォルダに関係するコミットだけを表示できます。
また、コミットメッセージにスコープを付けておけば、あとから検索しやすくなります。
feat(android): add exact alarm scheduling
fix(windows): redraw timer after resize
docs(article): add article draft
このように書いておけば、android や windows という単位で変更を探しやすくなります。
つまり、問題は「Gitに機能がないこと」ではありませんでした。
機能はあります。
ただ、自分が普段使っているGUIツールの中で、それを自然に使える導線が弱いと感じていたのです。
ここで少し見方が変わりました。
自分が不便に感じていたものは、単なる不満ではなく、小さな開発テーマになるのかもしれない
そう思いました。
不便は、学習テーマになる
ここで大事なのは、いきなり大きなサービスを作ろうとしなくてもいい、ということだと思います。
- 「世界中の人に使われるサービスを作る」
- 「まだ誰も思いついていない画期的なアプリを作る」
- 「ポートフォリオとして完璧なものを作る」
こう考えると、かなりハードルが上がります。
でも、最初のテーマはもっと小さくていいはずです。
たとえば今回なら、
モノレポで、フォルダ単位のGit履歴を見やすくする小さなツール
くらいで十分です。
最低限として考えるなら、機能はこれくらいでもよさそうです。
- ローカルのGitリポジトリを選ぶ
- ルート直下のフォルダを一覧表示する
- フォルダを選ぶ
- そのフォルダに関係するコミットだけ表示する
- コミットを選ぶと変更ファイルとdiffを表示する
これだけでも、自分が感じていた不便にはかなり刺さりそうです。
すごいサービスではないかもしれません。
でも、自分にとっては明確に意味があります。
そして、こういう題材には学習要素がたくさん含まれています。
小さなツールでも、学べることは多い
たとえば、このようなツールを作ろうとすると、いろいろな技術に触れることになります。
Gitの理解
単にコミットやブランチを使うだけではなく、
git log
git diff
git show
のようなコマンドを、アプリケーションの内部からどう扱うかを考えることになります。
Gitの理解が、単なる操作から一段深くなります。
UI設計
「フォルダ一覧」「コミット一覧」「diff表示」をどう並べるかを考える必要があります。
たとえば、次のような3ペイン構成が考えられます。
左: フォルダ / スコープ一覧
中央: コミット一覧
右: 変更ファイル / diff
これは単なる画面作りではなく、ユーザーがどう情報を追いたいかを考える練習になります。
エラー処理
- Gitリポジトリではないフォルダを選んだらどうするか。
- Gitコマンドが失敗したらどうするか。
- 巨大なリポジトリで履歴取得が重かったらどうするか。
こうした処理も、実際に作ろうとすると避けて通れません。
技術選定
- Windows向けに作るなら、C# / WPF / WinUI でもよいかもしれません。
- 軽量なデスクトップアプリとして作るなら、Tauri も候補になります。
- Flutter desktop で作れば、将来的にmacOSやLinuxにも広げやすいかもしれません。
このように、小さな不便から始めても、設計、UI、Git、エラー処理、配布方法など、かなり実践的な学習につながります。
「勉強のための勉強」より、「困ったから調べる」の方が続きやすい
新人エンジニアの頃は、どうしても「まず体系的に勉強しなければ」と思いがちです。
もちろん、それは間違いではありません。
ただ、すべてを先に勉強してから何かを作ろうとすると、なかなか手が動かなくなります。
個人的には、次の順番でもよいと思っています。
- 普段の作業で少し困る
- なぜ困るのかを言語化する
- 小さく解決する方法を考える
- 作るために必要な技術を調べる
- 作りながら足りない知識を学ぶ
この流れだと、学習に目的が生まれやすいです。
たとえば、ただ「Gitを勉強しよう」と思うと範囲が広すぎます。
でも、
フォルダ単位のコミット履歴を表示したい
という目的があると、調べるべきことが絞られます。
git log -- path/to/folder
を知るだけでも、Gitの見え方が少し変わります。
AIは「答えを出す道具」だけではなく、「不便を整理する相手」になる
今回、もう一つ感じたのは、AIとの壁打ちはアイデア整理にかなり向いているということです。
AIにコードを書かせることばかり注目されがちですが、それ以前に、
- これは不便なのか？
- 既存の解決策はあるのか？
- 作る価値はあるのか？
- 最初の機能はどこまで絞ればいいのか？
を相談できるのが便利です。
自分では「ただの愚痴」だと思っていることでも、AIに話してみると、
それは既存ツールの導線の問題かもしれない
それなら小さい専用ツールとして作る価値があるかもしれない
最初はこのMVPで十分かもしれない
という形で整理されることがあります。
これは、新人エンジニアにとってもかなり心強い使い方だと思います。
AIを「正解を出す先生」として使うよりも、
「自分の違和感を技術テーマに変える壁打ち相手」として使う。
その方が、学習にも開発にもつながりやすいと感じます。
身近な不便を探すときの観点
では、どうやってテーマを見つけるか。
いきなり大きなアイデアを探す必要はありません。
普段の作業の中で、次のようなことを考えるだけで十分です。
- 毎回同じ手順を繰り返していることはないか
- 少し見づらい、探しづらいと感じているものはないか
- 既存ツールを使っていて、あと一歩足りないと感じる場面はないか
- 自分だけのルールを毎回手作業で守っていないか
- 「仕方ない」と思って放置していることはないか
たとえば、次のようなものでも題材になります。
- ログファイルを見やすく整形する
- よく使うSQLを管理する
- READMEのテンプレートを生成する
- ローカル環境の起動手順をボタン化する
- 画像サイズを一括変換する
- Gitの特定操作をGUI化する
- 作業メモを日付ごとに整理する
どれも派手ではありません。
でも、自分が本当に困っているなら、作る意味はあります。
そして、自分が困っていることは、他の誰かも困っている可能性があります。
新人エンジニアに伝えたいこと
新人エンジニアのうちは、どうしても「すごいものを作らないといけない」と思ってしまうかもしれません。
でも、最初からすごいものを作る必要はないと思います。
むしろ、
自分の 「半径85cm～♬」 の不便を、技術で少しだけ楽にする
くらいでいいと思います。
その方が、作る理由がはっきりします。
作る理由がはっきりしていると、調べる理由もはっきりします。
調べる理由がはっきりすると、学習は少しだけ楽になります。
今回のモノレポのコミットログの話も、最初はただの小さな不満でした。
でも、少し掘り下げてみると、
- Gitのパス指定ログ
- コミットメッセージのスコープ設計
- GUIツールの使い勝手
- モノレポでの履歴の読み方
- 小さな専用ツールのMVP設計
という学習テーマに変わりました。
不便は、ちゃんと言語化すると課題になります。
課題になると、技術で解決できる対象になります。
まとめ
新人エンジニアにとって、学ぶべきことは本当にたくさんあります。
だからこそ、漠然と学習するだけではなく、自分の身近な不便からテーマを見つけるのも有効だと思います。
今回の気づきは、次のようなものでした。
- 「仕方ない」と思っている不便は、学習テーマになる
- 既存ツールに足りない導線は、小さなアプリのアイデアになる
- 大きなサービスでなくても、自分が使うツールなら作る意味がある
- AIはコード生成だけでなく、違和感を整理する壁打ち相手になる
- 身近な課題から始めると、学習に目的が生まれる
何を作ればいいかわからないときは、まず自分の普段の作業を振り返ってみるとよいと思います。
「少し面倒だな」
「毎回同じことをしているな」
「この画面、見づらいな」
「この操作、もう少し簡単にならないかな」
そういう小さな違和感は、立派な開発テーマの種です。
新人エンジニアだからこそ、身近な不便に気づけることもあります。
そして、その不便を少しだけ解決しようとすることが、実践的な学習の第一歩になるのだと思います。