「住宅購入支援アプリ」を開発 ～コア機能～ No.2

はじめに

私は2025年7月よりアプレンティスシップ生10期として、日々エンジニアになることを目指して独学を頑張っています。
今回は一通りカリキュラム内容を終えたうえで、初めてオリジナルプロダクトを開発したので、取り組んだ内容についてお話いたします。

目次

開発アプリ「OneHouse.」のご紹介
目的に沿ったデザイン設計が大切
環境構築
本番環境で明らかになったデータベースの不一致
API(非同期通信と認証から理解するVue×Laravel連携)
テストについて
インフラ構築の苦労
GitHub Actionsでの自動化
テストユーザーへのインタビュー
今後追加したい機能
この3か月で学んだこと

開発アプリ「OneHouse.」のご紹介

今回、住宅購入支援アプリとして「OneHouse.」というアプリを開発いたしました。

本アプリは、独学で学びながら、何度も書き直しや作り直しを行い完成させました。
粗削りな部分もあるかと思いますが、温かい目で見ていただけると嬉しいです。

アプリURL:https://onehouse.click/

GutHubリポジトリURL：https://github.com/yuzuha-s/OneHouse

目的に沿ったデザイン設計が大切

フロントエンドはデザインができてからも実は何度も修正を重ねました。
例えば、「戻るボタンが無い」「この配置を変えたい」などのあとから必要だと気付いた要素が、コードに実装する段階で次々と出てきました。

見た目だけを重視して要素を配置していたことにより、本来の目的やユーザーの動線を十分に理解できていなかったことに気づかされました。

また一元管理アプリとして、どのページからでもすべてのページに遷移できる設計を優先した結果、スマートフォン向けデザインの検討を後回しにしてしまい、想定以上に多くの時間を費やすことになりました。完成度にこだわるほど作業時間だけが過ぎていき、最終的には「これで十分だろう」と判断せざるを得ず、ユーザー視点を十分に保てなかった点は大きな反省点です。

環境構築

4週間でコア機能を作るために、まずは予定を30分単位のタスクに細かく分けるところからスタートしました。

Notionを活用したタスクの洗い出しにより、初期の環境構築は計画通り完了しました。
各機能の実装を4〜7日で完遂させるため、時間の使い道には常にこだわりました。
現場の状況に合わせてタスクの追加やスケジュールの前後調整を随時行い、メインとなるコア機能の開発に絞って順序を再編し、効率的に進めました。
そのおかげか、途中でエラーが出ることもなく、順調にセットアップを完了できました。
さらに、実際の開発現場を意識し、チームでタスクを分担する工程も想定して、タスクの見える化を心がけました。

本番環境で明らかになったデータベースの不一致

新規登録時にチェックリストの項目が自動で作成されるように設計していましたが、本番環境で複数のアカウントを登録した際、他のアカウントで追加されたデータまで複製されてしまう事象が発生しました。
これは、チェックリスト用のテーブルをコピーして初期化する設計にしていたため、共通のテーブルにデータが蓄積され、それが新規ユーザーにも引き継がれてしまっていたことが原因でした。

この設計の問題に気づかず、結果として意図しないデータ共有が起きていたことに、思わず冷や汗をかきました。。。
幸い、今回は個人情報を含む内容ではありませんでしたが、今後はより一層、設計段階でのデータの扱いに注意を払う必要があると痛感しました。

そのため、初期状態で用意されるチェック項目を管理するテーブルと、ユーザーごとに追加・管理されるタスクを格納するテーブルを分離して再設計し直しました。

API(非同期通信と認証から理解するVue×Laravel連携)

JSとLaravelの役割を理解する

計算ロジックでは、入力された数値（面積や建ぺい率など）をサーバーに送り、計算結果を返す内部APIのような形で処理を実装しています。
画面全体をリロードせず結果を反映させるために、非同期通信（AjaxやFetch API）を利用する構成を想定しました。

そのため、

JavaScript：画面表示や入力処理、非同期通信
Laravel：データ処理や計算ロジック、保存処理

という役割分担を意識して分断しました。

Vueでログイン認証がうまくいかなかった

Vue.js と Laravel を連携したログイン機能を実装しましたが、認証自体は成功しているもののログイン状態が保持されず、保存処理が行えない問題が発生しました。
Laravel Sanctum やCookie設定を確認しましたが原因は特定できず、今回は認証方法を変更することにしました。
また、Vueファイルにロジック・認証・チャート処理をまとめて書いていたため、役割ごとにファイルを分割しました。
Vueに値を渡してチャートを表示するところまで実装しましたが、API経由で取得するのかBlade側から渡すのかで混乱したため、確認しながら進めました。
また各ファイルの役割を意識してチャート描画処理を整理し、不要な保存処理を削除しました。
それぞれのつながりを理解しながら手探りで実装を進め、形にできたことに大きな達成感を感じています。

※処理の流れ

Blade　初期値
 ↓
Vue
 ↓ fetch　API通信
Laravel　(認証)
 ↓
Vue 表示
 ↓
Chart　描写

テストについて

今回計算誤りや描画ミスを防ぐためにテストコードを導入しました。
計算ロジックを独立させたことで、複雑な数値処理も効率的にテスト可能だということも学びました。

JavaScript

• 建物面積の算出

バックエンド側

• ログイン認証
• 新規登録・ログイン・ログアウト
• 土地情報（LandLog）の表示・登録・削除

静的解析

• PHP CodeSniffer
• PHPStan
• ES Lint
• Vitest

インフラ構築の苦労

AWS EC2での本番デプロイは、設定が複雑でかなり難航しました。
実体験をもとに、初心者がつまずきやすい落とし穴と、事前に準備すべきチェック項目をまとめた別記事を作成してますので、お時間あればこちらも参考にしてください。

GitHub Actionsでの自動化

絶対に自動化は成し遂げようと決めていました。
理由としては、CI/CDの仕組みは必ずと言っていいほど現場で導入されているだろう、と考えていたからです。
具体的には、コードの実装 → テスト → リリース反映までの一連の流れを自動化しました。
この仕組みにより、手動作業の削減（工数削減）と、バグの早期発見が可能な開発体制を構築し、実務レベルの開発体験を個人でも再現することができたと思っています。

テストユーザーへのインタビュー

今回実際に、3名の方にアプリを操作してインタビューを行いました。
利用デバイスはスマートフォン2名、タブレット1名です。
それぞれ一戸建ての購入を検討したことがある、または現在している方となっております。

スマホでの利用が多く、アプリ操作やボタンの挙動を変更

まず、入力欄のフォントサイズが16px未満だと、モバイル端末（特にiOS）で自動的に拡大表示されてしまい、入力後に画面を手動で戻す手間がありました。
さらに、iPhoneでは input や textarea のフォントが意図しないスタイル（デフォルトの書体）で表示されるため、すべての入力要素に対して明示的にフォントを指定する対応を行いました。

また、日常的に見慣れているスマホのサイズ感と異なると、それぞれの要素が大きすぎてしまい、操作時に少し戸惑いを感じたため、要素と文字のバランスを確認しながら調整を行いました。

また、トグルで状態を切り替えられるようにしていましたが、開閉の状態が分かりにくい設計になっていました。
トグルボタンは５つあるため、アイコンだけではなく、どのチェックリストを閉じたか一目で判断できるよう、項目名を追加しました。

PC・パソコン用

スマホ用

操作に迷わないように説明書やアプリのドキュメントが欲しい

分かりやすく作ったつもりでしたが、「このアプリで何ができるのか」という視点では伝わりづらいというフィードバックもありました。そこで、ランディングページと、ログイン後の操作を案内する説明書を新たに作成し、アプリの目的や使い方が明確に伝わるように再作成しました。
変更前はすべてHTMLで実装していましたが、デザインの自由度を高めるためにFigmaで作成し、SVGとして書き出したものを埋め込む方式に変更しました。

変更前
ログイン前・ログイン後は同じページを使用

変更後
ログイン前：そのまま使用
ログイン後：アプリ操作の説明を追加

また、チェックリスト一覧が分かるページを作成した

変更後

※初期データ一覧確認ページ

今後追加したい機能

• 住宅メーカー記録長に各メーカーからもらう図面図や見積もり書の画像を保存する
• 新築一戸建ての情報サイト
  (※今回はソフトウェア開発が主な課題であったため、情報サイトのようなWeb制作は対象外としたため)
• 検討が進んだユーザー向けに、より詳細な比較機能や記録機能など、さらに使いやすくするための工夫

まとめ

初めての個人開発は、想像の何倍も大変で、それ以上に楽しいものでした。
「動けばいい」という段階から、DBの整合性、テストの網羅性、スマホでの使い心地、そしてCI/CDによる効率化まで。一つ一つの技術がどう繋がっているのか、点と点が線になった実装期間でした。

至らない点もまだ多いですが、自分で課題を見つけ、調べて、解決し、形にするというプロセスを最後までやり遂げられたことは、大きな自信になりました。
「OneHouse.」をさらにブラッシュアップしつつ、これからも新しい技術に貪欲に挑戦し、より良いサービスを作れるエンジニアへと成長していきたいと思います。