【抽象的な基本設計から実装に落とし込むための教育テキスト】 - takayuki321/test_01 GitHub Wiki
【抽象的な基本設計から実装に落とし込むための教育テキスト】
■ 目的
抽象的な要求や基本設計書を受け取った際に、「何をすればいいのかわからない」と戸惑わないために、
どのように読み取り、考え、実装につなげるかの思考と手順を身につける。
■ 前提として必要な姿勢
- 設計書は「完全な指示書」ではなく、「意図と方針が書かれた概要」である
- 抽象的な記述を具体的な処理やデータ構造に変換するのがエンジニアの役割
- 「わからないから進めない」ではなく、「わからない点を整理し、仮説を持って相談する」姿勢が必要
■ 基本的な進め方（5ステップ）
- 設計書を読む（最初に全体をざっくり把握）
- 機能の目的は何か（誰のため、何のための処理か）
- 入力と出力は何か（データの流れをつかむ）
- 関連システムや制約はあるか（外部連携やルール）
- キーワードを拾う
- 設計書の中で、あいまい・抽象的な表現を抜き出す 例：「データを整形して出力」「不正なデータを除外」「ログに記録」など
- それぞれが「何を指しているのか」「どうすれば実現できるか」を考える
- 実装イメージを描く
- 拾ったキーワードに対して処理フロー・テーブル構造・画面UIなどを仮決めする
例：
- 「不正なデータ」→ NULLや型不一致のデータ？
- 「整形して出力」→ 特定フォーマット（CSV？JSON？）
- 手を動かす前に、作業内容を箇条書きで整理
- 自分なりに「この処理はこう進める予定」と書き出す
- 不明点や判断に迷う部分は「想定」として記述し、相談時に使う
《例》
・入力ファイルを一時テーブルに格納
・文字コードや項目数をチェック
・マスタ存在チェック（共通SQLを利用予定）
・正常データのみを本テーブルへINSERT
・不整合データはログ出力し、別テーブルに退避
- レビュー・相談に臨む
- 上記の整理をベースに、以下のように相談する
《例》
「基本設計書では“データ整形して帳票出力”とありましたが、以下の想定で進めようとしています。
① 日付フォーマットを統一（yyyy/mm/dd）
② 金額はカンマ区切り、0埋めなし
③ 帳票はExcel形式、テンプレートは過去案件のものを流用予定
方向性が合っているか確認させてください。」
■ よくある抽象表現と具体化のヒント
- 「データを整形」→ フォーマット統一？不要項目除外？型変換？
- 「不正データの除外」→ NULL？マスタ不整合？範囲外？
- 「ログに出力」→ ファイル？DB？エラーコード？内容は何？
- 「帳票に出す」→ フォーマットは？レイアウトは？出力タイミングは？
■ NGな進め方
・「設計書があいまいなので何もできません」と止まる
・不明点を整理せず「どうすればいいですか？」と丸投げで聞く
・自分の理解が正しいか確認せずに手を動かしてしまう
■ 推奨の進め方まとめ（チェックリスト形式）
□ 設計の目的と入出力が把握できている
□ 抽象的な表現を抜き出し、自分の言葉に置き換えた
□ 処理フローやテーブル構成の仮案を持っている
□ わからないことは整理し、「想定」として仮決めしている
□ 相談時は「自分なりの理解＋質問」で会話している
■ 最後に
「考えた上で相談する」人と、「考えずに聞く」人では、周囲の信頼度も成長スピードも大きく異なります。
抽象的な設計を扱う力は、上級エンジニアになるための第一歩です。