【個人開発】親の会社で実際に使われるシステムを作った話｜要件定義からリリースまでの全記録

なぜ親の会社向けに作ったのか

最初から「親の会社向けに作ろう」と決めていたわけではありません。

個人開発のアイデアを探していた時に、親から「今の日報管理が不便で困っている」という話を聞いたことがきっかけでした。

エンジニアとして「これは自分が解決できる問題だ」と思いました。同時に、「実際に使ってもらえる可能性が高い」という点が、モチベーションとして非常に大きかったです。

実際に使われることの価値

技術的なアウトプットとしてのシステム開発と、実際に使われるシステムの開発は、全く異なる経験です。

技術的なアウトプット（ポートフォリオ）:

• 「作る」ことが目的
• フィードバックが得にくい
• 使いやすさへの意識が薄くなりがち

実際に使われるシステム:

• 「使ってもらう」ことが目的
• リアルなフィードバックが得られる
• UX（ユーザー体験）への意識が自然と高まる

この違いが、エンジニアとしての成長に大きな差を生みます。

---

プロジェクト1：日報管理システム

要件定義

最初にやったのは、「現在どんな問題があるか」のヒアリングです。

接客業8年で培った傾聴力を活かして、親が実際にどんな課題を抱えているかを丁寧に聞き取りました。

ヒアリングで出てきた課題:

• 日報をExcelで管理しているが、ファイルが増えて探しにくい
• 過去の日報を振り返る時に、日付検索ができない
• 複数人の日報をまとめて見る方法がない
• スマートフォンからも確認したい

これらの課題から、必要な機能を整理しました。

機能要件:

機能	優先度	概要
日報作成	高	テキスト入力で日報を記録
日報一覧	高	日付順での一覧表示
日付検索	高	日付範囲で絞り込み
複数ユーザー対応	中	作成者別での表示
レスポンシブ対応	高	スマートフォンでも使える

技術選定

フロントエンド：Next.js + TypeScript

個人開発でNext.jsを学ぶという目標もあったため、採用しました。TypeScriptで型安全な開発ができること、App RouterでAPIも同一リポジトリで管理できることが決め手です。

スタイリング：Tailwind CSS

ユーティリティクラスで素早くUIを構築できるTailwind CSSを採用。デザインのセンスに自信がない分、Tailwindのデフォルトスタイルを活用することで、それなりに見えるUIを作れます。

データ管理：

シンプルなシステムのため、最初はJSON形式でのデータ管理から始めました。実際に使ってもらいながら、必要に応じてデータベースへの移行を検討する方針です。

設計で意識したこと

1. シンプルさを最優先にする

ITに詳しくない親が使うシステムです。余計な機能は入れない、操作ステップを最小限にする、ということを徹底しました。

機能を絞ることは、エンジニアとして難しい判断です。「あの機能も便利そう」「この機能もあった方が良い」と思ってしまいがちですが、それがシステムを複雑にします。

2. エラーが起きてもわかりやすく伝える

「エラーが起きた」だけでは、ITに詳しくない人には何をすれば良いかわかりません。エラーメッセージを「もう一度入力してください」「管理者に連絡してください」のように、次のアクションが明確な言葉にしました。

3. モバイルファーストで設計する

親はスマートフォンをメインで使います。デスクトップのUIを後からスマートフォン対応するのではなく、最初からモバイルでの使い勝手を優先して設計しました。

実装で苦労したこと

日付の扱い

JavaScriptの日付処理は、Javaと比べると独特の癖があります。タイムゾーンの問題、表示フォーマットの変換など、細かい部分で予期せぬバグが発生しました。

結果としてdayjsライブラリを導入して解決しましたが、「日付は必ずライブラリを使う」という学びを得ました。

Server ComponentsとClient Componentsの使い分け

Next.jsのApp Routerでは、コンポーネントをサーバーサイドとクライアントサイドで使い分ける必要があります。最初はどちらで書けばいいかの判断が難しく、試行錯誤しました。

原則として覚えたこと:

• データ取得はServer Component
• ユーザー操作（クリック・入力など）が必要な部分はClient Component（'use client'を冒頭に記載）

---

プロジェクト2：給付金計算Webアプリ

開発の動機：社会保障制度の情報格差を解消したい

このアプリの開発動機は、日報管理システムとは異なります。

「日本の将来を明るくしたい」「社会的弱者を支援するシステムを作りたい」という私のビジョンから生まれました。

社会保障制度は複雑で、自分が受け取れる給付金を正確に把握している人は多くありません。「知らなかったから申請しなかった」という情報格差が、受けられるはずの支援を受けられない状況を生んでいます。

親の会社がこの分野に関わっていることもあり、実際に使ってもらえる形で作ることができました。

要件定義

解決したい課題:

• 給付金の計算が複雑で、自分で計算できない
• 制度の内容がわかりにくい
• 申請できるものを見落としてしまう

機能要件:

機能	優先度	概要
条件入力フォーム	高	収入・家族構成などの入力
給付金計算	高	入力内容から給付額を算出
結果表示	高	受給できる給付金の一覧表示
制度説明	中	各給付金の概要説明

設計で意識したこと

計算ロジックとUIの分離

給付金の計算ロジックは複雑で、かつ変更が発生しやすいです。UIとロジックを分離することで、制度改正があった時にロジック部分だけを修正できるように設計しました。

これはJavaのバックエンド開発で学んだ「単一責任の原則」の応用です。

ステップ形式のUI

一度に多くの情報を入力させるフォームは、ユーザーが途中で挫折しやすいです。「家族構成」「収入情報」「居住地」など、カテゴリごとにステップを分けることで、入力のハードルを下げました。

---

リリース後に学んだこと

実際に使ってもらい始めると、設計段階では気づかなかった課題が次々と出てきました。

「当然わかるだろう」は通用しない

エンジニアとして当然だと思っていた操作が、使う人にとっては直感的でない場合があります。

例えば「保存ボタンを押してから移動する」という操作を省略して、自動保存にした方がよかったことがわかりました。ユーザーからの「保存できてるの？」という質問が出たことで、明確なフィードバックの重要性を学びました。

フィードバックは宝物

「こうしたら使いやすい」「この部分がわかりにくい」というリアルなフィードバックは、どんな技術書よりも価値があります。

接客業の経験から「ユーザーの声を丁寧に聞く」習慣があったことが、フィードバックの収集と改善サイクルの回転に役立ちました。

「システムがあってよかった」という言葉の重み

改善を重ねた後、「このシステムがあってよかった」という言葉をもらえました。

技術的な達成感とは異なる、「人の役に立てた」という喜びを初めてリアルに感じた瞬間でした。これがエンジニアとしての私のモチベーションの源泉です。

---

個人開発を「ポートフォリオ」として活かす

実際に使われているシステムを作ったことは、転職活動や副業営業で非常に強力な武器になります。

ポートフォリオとしての差別化ポイント

「チュートリアルで作ったTodoアプリ」と「実際に使われている日報管理システム」では、採用担当者への訴求力が全く異なります。

面接で話せること：

• 要件定義のプロセス: ユーザーのヒアリングから機能を絞り込んだ判断
• 設計の考え方: シンプルさ・モバイルファースト・ロジックとUIの分離
• リリース後の改善サイクル: フィードバックを受けて改善した経験
• 実際の効果: どんな課題がどう解決されたか

これらは技術力だけでなく、上流工程の素養や「ユーザーのために作る」という姿勢を示せます。

---

まとめ

「実際に使ってもらえるシステムを作る」という経験は、エンジニアとしての成長を大きく加速させます。

個人開発で学んだポイントまとめ

• ヒアリングで「本当の課題」を掴むことがシステム開発の出発点
• シンプルさを優先する機能の取捨選択が重要
• リリース後のフィードバックが最大の学習材料
• 実際に使われる経験がエンジニアとしての視点を変える

最後に

「システムを使ってくれている人が笑顔になり、このシステムがあってよかったと言ってもらえること」

これが個人開発を続けるモチベーションです。技術を学ぶことと、人の役に立つことを同時に実現できる個人開発は、エンジニアにとって最高の学習手段だと思っています。

---

この記事が参考になった方は、ぜひ他のITエンジニア関連の記事もご覧ください！