はじめに
「マイページを新規で作ってください」
もしも現場で、こんなざっくりした指示が飛んできたら？ 細かい仕様書はない。設計書もない。自分で考えて、動くしかない。
本記事では「マイページ新規実装」を例に、「具体的にどう動くか？」をまとめます。
目的は「自分の思考と行動を言語化して、再現性を持たせること」
下記はあくまで「ほんの一例」に過ぎません。ですが記事にすることで自分の振り返りと、同じような状況にいる人の参考になれば光栄です。
具体例
- ユーザーのマイページ新規実装（プロフィール表示・編集機能）
- 使用技術：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記載内容
- 変更の概要や理由、設計意図
- テスト項目と結果
- 確認してほしいポイント
- ※レビュー指摘は即対応
今後の改善点：
今回は個人の判断で行った影響調査や設計判断を、今後は**「なぜその設計にしたのか」を他者に説明できるレベルで言語化し、さらに保守性・拡張性**を意識したコードを書けるよう精進していきます。
まとめ
この記事は「マイページ新規実装」タスクを「どう分解し、どう進めるか」のまとめです。
もしも現場で、雑な指示がきたら？ 指示役も他の人も忙しい。そんなときは自分で考えて、動く力が求められます。
チーム貢献の活動の一環として、今後も「再現性のある動き方」を言語化し、次のタスクにも活かしていきます。
この記事が、同じような状況にいる人の参考になれば嬉しいです。