「何を勉強すればいいか分からない」...身近な不便を解決してみるのはどうでしょう

新人エンジニアになったばかりの頃は、学ぶことが多すぎます。

JavaScript、React、Vue、Java、Spring Boot、SQL、Git、Docker、クラウド、テスト、設計、セキュリティ……。

「何から勉強すればいいんだろう」

そう思うことは、かなり自然なことだと思います。

もちろん、基礎を学ぶことは大切です。

ただ、漠然と技術書を読んだり、チュートリアルを順番にこなしたりしているだけだと、途中でこう感じることがあります。

これ、結局どこで使うんだろう？

私もそういう感覚になることがあります。

昔から言われていることですが、学習テーマは「世の中にないすごいもの」から探さなくてもいいということです。

やはり、自分が普段感じている小さな不便を解決しようとした方が、学習は続きやすいのではないでしょうか。

基礎を軽視しているわけではないです。

ここで、最近の自分の事例を少し紹介します。

最近、Windows アプリと Android アプリを同じリポジトリで管理する構成を AI に提案されました。

いわゆるモノレポ構成です。

同じアプリの Windows 版と Android 版を並べて管理できるので、構成としては自然に見えます。

一方で、少し気になることがありました。

それは、コミットログが混ざって見にくくなることです。

Windows 側の修正、Android 側の修正、README の修正、記事用メモの修正などが、同じ履歴に並びます。

小さいプロジェクトなら問題ないかもしれません。

でも、あとから見返すときに、

Android 版だけの変更履歴を見たい

Windows 版だけの修正を追いたい

このフォルダに関係する変更だけ見たい

と思う場面があります。

以前の私は、これを「モノレポだから仕方ない」、「いっそ別々のほうが管理しやすい」と思っていました。

あるいは、「自分が 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 log

git diff

git show

のようなコマンドを、アプリケーションの内部からどう扱うかを考えることになります。

Git の理解が、単なる操作から一段深くなります。

「フォルダ一覧」「コミット一覧」「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 에 이야기하면,

그것은 기존 툴의 문제일 수 있다는 것

그렇다면 작은 전용 도구로 만드는 가치가 있을 수 있다는 것

처음에는 이 MVP 만으로 충분할 수 있다는 것

이렇게 정리될 수 있습니다.

이는, 신입 엔지니어에게 매우 도움이 되는 방법이라고 생각합니다.

AI 를「답을 내는 선생님」と서 사용하는 것보다,

「자신의 불편함을 기술 테마로 바꾸는 벽 타기 상대」と서 사용하는 것이 더 좋다고 생각합니다.

그方が, 학습에도 개발에도 연결되기 쉽습니다.

그렇다면, 어떻게 주제를 찾아야 할까?

일단 큰 아이디어를 찾는 것은 필요 없습니다.

평소 작업에서, 다음을 생각하면 충분합니다.

• 매번 같은 절차를 반복하지는 않는가
• 조금 보기 어려움, 찾기 어렵다고 느끼는 것은 없는가
• 기존 툴을 사용하면서, 한 걸음 부족하다고 느끼는 장면은 없는가
• 자신만의 규칙을 매번 수동으로 지키지 않는가
  -「仕方ない」と 생각하여 방치하지는 않는가

예를 들어, 다음 것들도 소재가 됩니다.

• 로그 파일을 보기 쉽게整形하는
• 자주 사용하는 SQL 을 관리하는
• README 의 템플릿을 생성하는
• 로컬 환경의 시작 절차를 버튼화하는
• 이미지 크기를 일괄 변환하는
• Git 의 특정 조작을 GUI 화하는
• 작업 메모를 날짜별로 정리하는

모두 화려하지 않습니다.

하지만, 자신이 정말 불편해한다면, 만드는 의미가 있습니다.

그리고, 자신이 불편해하는 것은, 다른 사람도 불편해할 가능성이 있습니다.

신입 엔지니어는, 반드시「놀라운 것을 만들어야 한다」と 생각하게 될 수 있습니다.

하지만, 처음부터 놀라운 것을 만들어야 하는 것은 아닙니다.

오히려,

자신의

「반경 85cm～♬」의 불편을, 기술로 조금만 편안하게 만드는

정도로 괜찮지 않나요?

그方が, 만드는 이유가 명확해집니다.

만드는 이유가 명확하면, 조사하는 이유도 명확해집니다.

조사하는 이유가 명확하면, 학습은 조금만 편안해집니다.

이번의 모노레포의 커밋 로그 이야기도, 처음에는 단순한 작은 불만이었습니다.

하지만, 조금 깊이 파고들면,

• Git 의 경로 지정 로그
• 커밋 메시지의 스코프 설계
• GUI 툴의 사용성
• 모노레포에서의 이력 읽기 방법
• 작은 전용 툴의 MVP 설계

이런 학습 주제로 변했습니다.

불편은, 제대로 언어화하면 과제입니다.

과제가 되면, 기술로 해결할 수 있는 대상입니다.

신입 엔지니어에게, 배울 것은 정말 많습니다.

그래서, 모호하게 배우는 것이 아니라, 자신의 가까운 불편에서 주제를 찾는 것이 효과적이라고 생각합니다.

이번의 깨달음은, 다음 것들이었습니다.

-「仕方ない」と 생각하여 불편함은, 학습 주제로 변합니다

• 기존 툴에 부족한 도로는, 작은 앱 아이디어가 됩니다
• 큰 서비스라도, 자신이 사용하는 툴이면 만드는 의미가 있습니다
• AI 는 코드 생성뿐만 아니라, 불편함을 정리하는 벽 타기 상대가 됩니다
• 가까운 과제에서 시작하면, 학습에 목적이 생깁니다

무엇을 만들지 모르겠다면, 먼저 자신의 평소 작업을 되돌아보면 좋다고 생각합니다.

「조금 번거롭다」

「매번 같은 일을 한다」

「이 화면, 보기 어렵다」

「이 조작, 더 간단해지지 않는가」

그런 작은 불편함은, 훌륭한 개발 테마의 씨앗입니다.

신입 엔지니어에게서, 가까운 불편에 깨달을 수 있습니다.

그리고, 그 불편을 조금만 해결하려고 하는 것이, 실천적 학습의 첫걸음이 된다고 생각합니다.