振り返り・技術記事

　当初は「ペットの健康管理アプリ」という広いテーマで考え始めましたが、調査を進める中で、飼い主の困りごとは「記録が続かない」「異変時に受診判断が難しい」「予約・連絡が分断される」の3点に集中していることが分かりました。そこで機能を増やすより、日常記録→症状チェック→予約→通知の導線を一つの流れとして設計する方針に切り替えました。

　ペルソナは「平日は忙しく、短時間で判断したい30代の犬オーナー」を中心に設定し、情報設計では1画面で次の行動が分かることを重視しました。特に、記録詳細から予約へ遷移できる導線や、通知一覧で必要情報を確認できる構成は、初期段階で定義したユーザー課題に直結しており、後半の実装判断の基準になりました。

　デザインでは、医療系サービスとしての信頼感と、毎日触れるアプリとしての親しみやすさの両立を目標にしました。色は寒色を基調にしつつ、重要操作には暖色系アクセントを使うルールを先に決めたことで、画面追加時にも判断がぶれにくくなりました。

　ワイヤーフレーム段階では、要素を詰め込みすぎて情報密度が高くなり、テスト時に「どこを押せばよいか迷う」という指摘が出ました。そのため、Figma上で優先度の低い情報を段階表示に整理し、主要ボタンの位置を統一しました。結果として、初見ユーザーでも主要導線（記録・予約・通知）を短時間で把握できるUIに改善できました。

　フロントエンド実装では、テンプレート分割と共通スタイルの管理が想定以上に重要でした。初期は画面ごとに個別調整を繰り返したため、スマホ表示でレイアウト崩れが発生しやすく、修正の影響範囲も大きくなりました。途中から共通コンポーネントとブレークポイントを整理し、ナビゲーションやフォーム部品を揃えたことで、後半の改修速度と安定性が上がりました。

　また、JavaScriptでは「小さな体験改善」の積み重ねが効果的でした。通知リンクの自動整形、メニュー開閉、フォームの補助表示など、派手ではない改善が継続利用時のストレスを下げることを実感しました。

　バックエンドでは、機能追加よりも「権限」「状態遷移」「例外時のふるまい」を先に固めることの重要性を学びました。特に予約機能では、申請・承認・却下・キャンセルのルールを曖昧なまま進めると、後で仕様整合が難しくなるため、ロールごとの操作可能範囲を明文化してから実装する方が結果的に効率的でした。

　Spring Boot + MyBatis 構成では、SQLが明示的な分、意図したデータ取得・更新を追いやすい反面、ドキュメントとの同期を怠るとズレが発生しやすい課題もありました。今回、仕様書・サイトマップ・DB設計書を実装準拠で継続的に更新したことで、保守性と引き継ぎやすさが大きく向上しました。

　32日間を通して最も大きな学びは、開発は「作ること」だけでなく「揃えること」が品質を決めるという点でした。要件、実装、ドキュメント、テスト観点が一致している状態を維持することで、機能の信頼性だけでなく、修正の速さやチーム内共有のしやすさも向上しました。

　また、AI活用は実装補助として有効でしたが、最終的な責任は仕様判断と検証にあることを強く実感しました。今後は、初期設計でのルール定義、変更時の影響分析、ドキュメント同期をさらに習慣化し、機能追加と品質維持を両立できる開発力を高めていきます。

LINE Developers WebhookからユーザーIDを取得する

　LINE Messaging API で個別ユーザーに通知を送るには、ユーザーID（例: Uxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx）が必要です。LINE公式ドキュメント「ユーザーIDを取得する」の「WebhookからユーザーIDを取得する」では、友だち追加やメッセージ送信時にボットサーバーへ送信されるWebhookにユーザーIDが含まれることが示されています。

　実装上は、Webhookイベントの events[].source.userId を読み取り、アプリ側のユーザーテーブルへ保存します。これにより、後続のPush通知や対象ユーザー特定に利用できます。

{
  "events": [
    {
      "type": "follow",
      "source": {
        "type": "user",
        "userId": "Uxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      }
    }
  ]
}

　注意点として、ドキュメントでは「プロフィール情報の取得に同意していない場合はWebhookにユーザーIDが含まれない場合がある」とされています。受信処理では userId の存在チェックを入れ、未取得時はログ出力と再連携導線を用意するのが安全です。

出典: LINE Developers - ユーザーIDを取得する

　学習テーマは「バックエンド設計」と「AI活用開発」の2つに絞り、3か月で理解を深めて実務で使える状態を目指します。

　目標は、バックエンド設計では認可・トランザクション・例外設計を根拠を持って実装できること、AI活用開発ではAPI連携・プロンプト設計・評価改善を一連で実行できることです。

　学習計画は、1か月目に基礎理解、2か月目に既存機能への実装適用、3か月目にテストと評価指標を使った品質定着の順で進めます。週次では「インプット（週3回×30分）」「実装（週2回×60分）」「振り返り（週1回×30分）」を固定し、継続を重視します。

　成果物として、毎月1本の技術メモまたは記事を作成し、3か月で「バックエンド改善1件」と「AI連携機能1件」を実装します。達成基準は、設計判断を説明できること、実装とドキュメントに差分がないこと、AI機能の改善結果を事例または数値で示せることです。