はじめに

「マイページを新規で作ってください」

もしも現場で、こんなざっくりした指示が飛んできたら？　細かい仕様書はない。設計書もない。自分で考えて、動くしかない。

本記事では「マイページ新規実装」を例に、「具体的にどう動くか？」をまとめます。
目的は「自分の思考と行動を言語化して、再現性を持たせること」
下記はあくまで「ほんの一例」に過ぎません。ですが記事にすることで自分の振り返りと、同じような状況にいる人の参考になれば光栄です。

具体例

ユーザーのマイページ新規実装（プロフィール表示・編集機能）
使用技術：Ruby on Rails, PostgreSQL

タスクの進め方（7ステップ）

1. 仕様確認

【重要】「何をすればミッションクリアか？」の明確化
まず「何ができればゴールか」を明確にします。

確認項目

マイページに表示する情報は？（ユーザー名、メールアドレス、登録日など）
どの画面から遷移する？（ヘッダーのアイコンクリック）
編集できる項目は？（ユーザー名、プロフィール文）
データがない場合の表示は？（未設定の場合は「未設定」と表示）
権限によって表示内容は変わる？

ポイント
上記を、タスクを振った人に確認。
「聞かなくてもわかるでしょ」って空気があっても、聞く。
認識齟齬は事故の元。ここでズレると、あとで全部やり直しになる。
認識ズレが一番のスケジュール遅延要因。

2. 変更箇所の把握

どこをどう変更するか洗い出します。
この段階で、変更箇所を洗い出しておくと、影響調査が楽。
まずは領域に分けて考え、つぎに粒度を細かく。

新規ファイル？既存ファイル修正？
バックエンド：Controller追加？Model修正？
フロントエンド：HTML/CSS/JSどこまで触る？
DB：新規テーブル？既存テーブルにカラム追加？
SQL：新規？既存流用？

バックエンド

UsersControllerにshow、edit、updateアクションを追加
Userモデルにバリデーション追加（プロフィール文は500文字以内）

フロントエンド

views/users/show.html.erb（表示画面）
views/users/edit.html.erb（編集画面）
CSS（マイページ用のスタイル）

DB

既存のusersテーブルにprofileカラム追加（text型）

ルーティング

config/routes.rbにresources :users, only: [:show, :edit, :update]追加

3. 処理の流れを設計する

紙に簡単なフローチャートを書きます。
目的は「実装の流れを頭に入れること」

ヘッダーのアイコンクリック
  ↓
UsersController#show
  ↓
Userモデルからデータ取得
  ↓
show.html.erbでデータ表示
  ↓
「編集」ボタンクリック
  ↓
UsersController#edit
  ↓
edit.html.erbで編集フォーム表示
  ↓
更新ボタンクリック
  ↓
UsersController#update
  ↓
バリデーション → 成功ならマイページへリダイレクト

目的は実装の流れを把握すること。
コードを書く前に全体像を掴むことで、実装中に迷わなくなります。

4. 影響調査

既存機能への影響を確認します。

確認項目

usersテーブルにカラム追加 → 既存のユーザー登録機能に影響ないか？
CSSのクラス名 → 他ページと重複していないか？
ルーティング → 既存のルートと競合していないか？
共通関数、他機能で使われてない？
Model修正で、他画面に影響出ない？

結果

profileカラムはnull許可にして、既存ユーザーに影響なし
CSS は.mypage-プレフィックスをつけて名前空間を分離
ルーティングは問題なし

ポイント
ここをサボると、デグレ（既存機能の不具合）になる。
「この関数、他でも使ってるな…」と思ったら、別関数に切り出す判断も必要。
共通処理や既存コードを触る場合、影響範囲の調査は必須。
実務では「デグレ（既存機能の不具合）」が最も避けるべき事故。

5. 実装（開発）

設計に沿ってコードを書きます。

ポイント

コントローラーはシンプルに（ビジネスロジックはモデルへ）
ビューは部分テンプレートで共通化（_form.html.erb）
エラーメッセージは日本語化（i18n）

6. テスト

Excelでテストケースを洗い出します。

テスト項目（一部）

正常系：プロフィール編集が正しく保存されるか
異常系：500文字を超える入力でエラーメッセージが表示されるか
異常系：他人のマイページを編集しようとした場合、エラーになるか
デグレ確認：ユーザー登録機能が正常に動作するか

ポイント
テストケースを事前に書くことで、「何を確認すべきか」が明確になります。
実務では品質担保が重要で、テストの網羅性が「信頼」に。

7. PRでレビューを受ける

GitHubでPRを作成し、メンバーにレビューを依頼します。
レビューで指摘をもらい、OKならマージ。

PR記載内容

変更の概要や理由、設計意図
テスト項目と結果
確認してほしいポイント
※レビュー指摘は即対応

今後の改善点：
今回は個人の判断で行った影響調査や設計判断を、今後は**「なぜその設計にしたのか」を他者に説明できるレベルで言語化し、さらに保守性・拡張性**を意識したコードを書けるよう精進していきます。

まとめ

この記事は「マイページ新規実装」タスクを「どう分解し、どう進めるか」のまとめです。
もしも現場で、雑な指示がきたら？　指示役も他の人も忙しい。そんなときは自分で考えて、動く力が求められます。

チーム貢献の活動の一環として、今後も「再現性のある動き方」を言語化し、次のタスクにも活かしていきます。
この記事が、同じような状況にいる人の参考になれば嬉しいです。