初心者の初心者による初心者のための個人開発のコツ

こんにちは
SEになりたい学生です。

これまでクラウドなどで様々なものを開発してきましたが、

- 完成して役割を果たしたもの
- モチベーションが続かず挫折したもの
- 技術不足で完成させられなかったもの

などがあったので、これらの経験をもとにした教訓を、自分へのメモも兼ねてまとめてみます。

初投稿として、[はじめてのアドベントカレンダー](https://qiita.com/advent-calendar/2024/first-time)に便乗して執筆します。

:::note warn
まだ経験の浅い身ですが、「こんな考え方もあるんだな」くらいの軽い気持ちで読んでいただけると幸いです。
マサカリは豆腐に投げるくらいの気持ちで...
:::

# 1 テーマを見つけるために

## 1.1 環境が変わった時に探す

周囲で何か変化が起きた際に、不便だと感じたことをメモするのが効果的です。

例：

- 使い始めたサービスが痒いところに手が届かない
- アプリがアップデート後に使いづらくなった
- 進学や転職で所属する組織の情報伝達方法が変わった

不便さに慣れる前にメモしておくことが重要なので、どこかに書き留めておくことようにしています。
私はスプレッドシートを活用して、不便に感じたこととその改善策を記録しています。

## 1.2 思いついたことをすぐにスプレッドシートにメモ

私がスプレッドシートを使用する理由は以下の通りです。

### 1.2.1 簡単に使用・デバイス間共有可能

これは言わずもがなですね。
スプレッドシートだけでなくスライドやドキュメントでもよくお世話になっています。

### 1.2.2 計算がその場で可能

サービスの利用料金の試算を始め、計画の中では頻繁に計算を行います。
特に試算の段階ではユーザー数やAPIコールの回数が不明なので、色々なパラメータを簡単に変更して再計算できるのが便利です。

### 1.2.3 二次元方向に記録可能

これはアイディアを思いついた端から書き出したり、自分に対する会話形式で書いたりすることで、思考を整理できます。
私のスプレッドシートにはよくこんなパターンが現れます。
![スクリーンショット (40).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3886914/4126b35d-8796-636c-536d-a278ee7aaca9.png)
こんなかんじで自分の思考をひたすらアウトプットしていくことで、文章に起こす際に整理され、頭の中で曖昧だった定義がある程度明瞭になってきます。
さらに思考の軌跡を残すことで、既に検討したことを再度考え直すことが減ります。

### 1.2.4 履歴を辿れる

後から別の場所の影響で、既に決定したことを考え直す必要が出てくることがあります。
そんなときに1,2時間おきにスナップショットを保存しておいてくれるので、それを参照することで同じことをまた考え直したり調べ直したりする手間を減らせます。

### 1.2.5 作図できる

セルの幅を高さと同じくらいに調整して正方形にすることで、簡単な作図ができます。
複数セルを結合できるため要素のサイズは可変ですし、要素の移動も"表計算ソフト"という特性上、楽にできます。

## 1.3 制約による不便さを逆手に取る

中高生などで保護者や学校の制約がある場合、それを逆手に取って工夫することで開発のモチベーションに変えられます。

あまり良くない例ですが、私はWindowsにかかった時間制限を超えるためにLinuxを使っていました。しかしそのときに必要に迫られて得たCUIによる操作方法やOSについての知識が、現在かなり役立っています。

# 2 モチベーションを保つために

## 2.1 自分のためのものを作る

個人開発で最も大切なポイントだと思います。

対象が自分であることで、

- サービスの必要性を感じやすい
- 機能や必要な範囲を具体的に想像しやすい

というメリットが生まれます。

## 2.2 類似のサービスが無いか探す

作るものが決まったら、同様のサービスが存在するか調査します。
逆の主張をする人もいますが、「後から下位互換でしかないことを知って全てのモチベを失う」デメリットが大きいので、私にはこちらのほうが合っています。

既存サービスと比較したうえで、

- 個人開発ならではの価値
- 自分自身用だからこそ無視できる要素
- 複数サービスの統合
- 特定のニーズに特化したオリジナル要素

を探すことができます。

## 2.3 大風呂敷を広げない

開発計画中に

- 新技術を試したい
- 多機能化したい
- 高度なサービスを取り入れたい

などの誘惑がありますが、適切に切り分けることが重要です。

期限を始めとする制約が少なく、自由度が高いことこそ個人開発のメリットです。しかし開発作業が長期化すると、だんだんとモチベーションが落ちていきます。

失敗例としては「ただのヘルパースクリプトに過剰なアーキテクチャを取り入れたことによる、幾度とない作り直し」などがあります。

そこで、

- 計画を切り分け、着手した部分は変更しない
- オーバースペックか冷静に考える
- サービスへの理解度よって取り入れるかを決める

ということを意識するようにしています。

ただし<font color="red">**セキュリティは別**</font>です。認証を軽視して不正アクセスされそうになったことがあるため、セキュリティ関係は例え他に影響が及ぼうと優先的に実装するようにしています。

## 2.4 開発を並行しない

開発の同時進行によって「詰まったら一旦別の開発を進める」という癖がつくと、どちらも詰まった場合に開発が完全にストップしてしまうリスクがあります。

開発の並行はできるだけ避け、詰まったときは開発とは全く関係ないことでリフレッシュするようにしています。


# 3 詰まった時は

## 3.1 とりあえず動かす

これは「手」でも「プログラム」でもそうです。

ドキュメントが理解できない、不可解なバグが起きている、そんな中で目の前にある情報だけを、数分前と同じ経験/知識の頭でこねくり回してもほとんど何も得られません。

ドキュメント：

- コードに起こして静的解析ツールの反応を見る
- Curlや[Postman](https://www.postman.com/)で試しにAPIを叩く
- リソースを作ってみて設定画面を観察

プログラム：

- 至る所でログを吐かせる
- 一部の変数の値をハードコーディングしてみる
- 時間経過で変わるのか確かめてみる

など、やりようはいくらでもあります。

## 3.2 AIを活用する

### 3.2.1 複数のAIを使い分ける

それぞれのAIの得意分野を活用します。（※これは私の体感です）

|AI|長所|短所|
|:-:|:-:|:-:|
|ChatGPT|質問の理解に柔軟性がある<br>回答が論理的|正確性が低い<br>時々矛盾した回答を生成|
|Perploxity|正確性が高い<br>出典のURLを提示|質問の理解が苦手<br>創造的な質問に弱い|

APIやサービスの仕様を始めとした明確な唯一の正解が存在する質問はPerploxityに、意見やプログラムのロジック、命名などの創造性が必要な質問はChatGPTにするというように使い分けています。

### 3.2.2 質問を途中まで入力してみる

これは有名な「掲示板に投稿するつもりで質問を書くことで、書いてる途中に自然に整理されて自己解決できるかもしれないし、そうでなければそのまま投稿ボタンを押せばいい」という話に似たものです。

しかしAI相手だと、

- 相手が人間でない分、質問しようと決めるハードルが下がる
- 人間ほど柔軟に理解してくれないため、より整理して正確に書く必要がある

ことから、私はこの手法に掲示板ではなくAIを使っています。

## 3.3 公式ドキュメントを隅々まで読む

ページ数が膨大でも、更新が遅くとも、日本語でなくとも、検索にヒットしなくても、どこかに答えが書いてある可能性は充分にあります。

実際、以前こんなことがありました。

> [AWS Lambda](https://aws.amazon.com/jp/lambda/)にHTTP経由でアクセスするためには [Amazon Cloudfront](https://aws.amazon.com/jp/cloudfront/) での署名が必要であるが、GETリクエストにはちゃんと署名するのに対し、POSTには署名せず。
> そこでCloudfrontの公式ドキュメントを全て読み返してみると[このページ](https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-lambda.html)に「POSTメソッドを使用する場合、ヘッダにペイロードハッシュ値を含める必要がある」という表記を見つける。(ここまで数日間)

これ以降、検索でもAIでも情報が得られなかった場合、公式ドキュメントを隅々まで読むようにしています。

# まとめ

以上が、私が個人開発で学んだコツです。
しかし正直自分もうまくいっていません。
機能を増やしすぎるのは挫折の原因になると分かっていながらついつい増やしてしまったり、身の丈に合わないサービスを取り入れようとして心が折れかけたりということはよくあります。

でも、この記事が誰かの参考になればいいなと思います。

ここまでお付き合いいただき、本当にありがとうございました！

# 明日の記事

あと5日でクリスマスですね。ちなみに自分は予定ありません...

[↓ はじめてのアドベントカレンダー Advent Calendar 2024 ↓](https://qiita.com/advent-calendar/2024/first-time)
|シリーズ|著者(敬称略)|タイトル|
|:-:|:-:|:-:|
|01|@yochan__|-|
|02|@takurot|Linuxログ解析をAIで効率化するツールを作ってみた|
|03|@kenken38|【最新版】Word2Vec用コンテナのDockerfile|
|04|@gawara-t|こう読めば頭が良くなる「正しい読書法」の提案|
|05|@calcMCalcm|OPENCVでONNXを利用できるように<br>ONNX RUNTIMEをビルドする|
|06|@Cheesecake2960|Node.jsとは？|
|07|@a_d_j_u_s_t|-|
|08|@CodeLeaf|【TailwindCSS】定数ファイルへのクラス名切り出しが<br>失敗する理由と対処法💡|
|09|@nishifeoda|初心者向け！毎日の天気予報をLINEに通知し、<br>Googleスプレッドシートに記録するアプリを<br>作成しよう|
|10|@Ribbit-3|家のパソコンを外でも使いたい！！！|
|12|@yuyanz|AVDでhostsファイル試してみた|

私はよく技術書やSF小説を読むので「こう読めば頭が良くなる『正しい読書法』の提案」が気になります。
あと、以前似たようなことをやったことがある(というか現在も運用中)なので「初心者向け！毎日の天気予報をLINEに通知し、Googleスプレッドシートに記録するアプリを作成しよう」がどんな構成なのかも興味がありますね。

それでは！