システム開発の実装（製造）とは

実装（製造）は、設計で決めた仕様をソースコードなどの動く成果物へ変える工程です。

開発環境の準備からコーディング、レビュー、単体テストまでを含むことがありますが、工程の名称や境界はプロジェクトごとに確認する必要があります。

設計を動くプログラムに変える

実装では、詳細設計書やチケットに書かれた処理、データ、画面、外部連携を、プログラミング言語やフレームワークを使って形にします。

仕様をそのまま機械的に入力する作業ではなく、既存コードとの整合性、例外時の動作、保守しやすい構造を考えながら判断する仕事です。

前工程から受け取った情報に矛盾や不足があれば、推測で埋めずに設計担当者へ確認します。

実装後は機能単位の動作を確かめ、レビュー可能な状態へ整えます。

開発全体での位置づけは、開発エンジニアが関わる工程でも確認できます。

出典：IPA「国際規格SLCP：システム＆ソフトウェアのライフサイクル・プロセス」

製造・実装・コーディングの違い

「製造」「実装」「コーディング」は近い意味で使われますが、担当範囲が必ず同じとは限りません。

コーディングは主にソースコードを書く行為を指し、実装は設定、ビルド、レビュー対応なども含めて機能を動かす作業として使われることがあります。

製造は、ウォーターフォール型の案件で実装工程を表す呼び方として見られます。

単体テストまで製造に含める案件もあれば、別工程として管理する案件もあります。

名称ではなく、入力資料、担当作業、成果物、完了条件を確認すると認識のずれを防げます。

開発手法で進め方が変わる

ウォーターフォール型では、詳細設計の完了後に実装へ進み、機能やプログラム単位で作業と承認を管理する形が代表的です。

設計変更が生じた場合は、関連文書やテスト項目への影響も確認します。

アジャイル開発では、短い反復の中で設計、実装、テスト、レビューを繰り返します。

実装工程がなくなるわけではなく、扱う機能の範囲と確認の時期が小さく区切られます。

どちらでも、変更内容、確認結果、残っている課題をチームで共有できる状態が必要です。

出典：IPA「アジャイル開発の進め方」

実装前に準備するもの

実装前には、参照する設計と未決事項、開発環境、チームのルール、単体テストの条件をそろえます。

準備の完了基準を共有しておくと、担当者ごとの前提の違いや、実装後に環境不足が判明する事態を減らしやすくなります。

設計と未決事項を確認する

最初に、対象機能の詳細設計、画面・API・データ仕様、関連する既存処理を読みます。

設計の版、対象チケット、変更理由を結び付け、今回触る範囲と触らない範囲を明確にしてください。

入力値、境界条件、権限、エラー時の動作が曖昧なら、実装を始める前に質問します。

複数の資料で記載が異なる場合も、担当者の解釈だけで正解を決めません。

確認した決定内容をチケットや設計書へ戻し、後から根拠を追える状態にすることが、実装中の手戻りを抑える土台になります。

開発環境とルールをそろえる

開発端末、言語処理系、依存ライブラリ、データベース、テスト用データなどを準備し、既存コードをビルド・実行できるか確認します。

環境構築手順がある場合も、バージョンや設定値が現在のリポジトリと合っているかを見てください。

命名、整形、コメント、例外処理、ログ、ブランチ運用、レビュー申請のルールも共有します。

自動整形や静的解析を使うチームでは、ローカル環境とCIで同じ条件を再現できるようにします。

個人の好みではなく、チームが継続して保守できる基準へ合わせることが要点です。

単体テストの条件を決める

実装前に、機能が完成したと判断する条件と、単体テストで確かめる範囲を決めます。

正常な入力だけでなく、境界値、不正値、データがない場合、外部処理が失敗した場合なども候補です。

テストコードを作るのか、手動確認を併用するのか、証跡をどこへ残すのかもそろえてください。

設計から期待結果を判断できない場合は、実装後まで持ち越さずに確認します。

実装工程の進め方

実装は、作業を確認可能な単位へ分け、設計と規約に沿ってコードを作り、レビューの指摘を反映する流れで進めます。

変更量の多さよりも、目的と影響範囲を説明でき、別の担当者が安全に確認できる単位を選ぶことが基準です。

作業を実装単位へ分ける

機能を画面、API、データ処理、共通部品などへ分け、依存関係と実装順を整理します。

一度に大きく変更すると原因の切り分けやレビューが難しくなるため、動作を確認できる小さな単位にします。

各タスクには、対象、完了条件、関連設計、担当者、期限を結び付けてください。

共通部品を先に変える場合は、既存機能への影響も確認します。

作業の分割は担当を割り振るためだけでなく、変更の目的と確認範囲をチームで共有するために行います。

設計と規約に沿って実装する

コーディングでは、設計で定めた処理とデータの流れを守りながら、既存の構造や規約に合わせます。

入力検証、権限、例外処理、ログなど、正常時には見えにくい動作も実装対象です。

分かりにくい処理へコメントを増やす前に、名前、関数の責任、条件分岐を整理し、コード自体から意図を読み取りやすくします。

設計変更が必要になったら、コードだけを先行させず、影響範囲と判断者を確認してください。

仕様変更と実装上の工夫を分けて記録すると、レビュー時の論点が明確になります。

コードレビューで確認する

コードレビューでは、動作するかだけでなく、設計との対応、読みやすさ、例外処理、セキュリティ、テスト内容を確認します。

変更理由と影響範囲を説明し、レビュー担当者が関連仕様へたどれる状態にしてください。

指摘は単なる好みと、品質・規約・仕様に関わる問題を分けて扱います。

修正した箇所は再確認し、対応しない指摘には理由を残します。

レビューを承認作業だけにせず、チームの判断基準をそろえ、将来の変更で迷いにくくする機会として活用しましょう。

単体テストと不具合修正

単体テストでは、プログラムを構成する機能や部品が、設計どおりの入力・処理・出力になるかを確認します。

不具合が見つかった場合は、再現条件と原因を切り分け、修正後に影響範囲を含めて再確認します。

機能単位で動作を確かめる

単体テストは、関数、クラス、モジュールなど、プロジェクトで定めた単位ごとに動作を確かめる工程です。

正常系に加え、境界値、不正な入力、例外、状態変化を確認し、期待結果と実際の結果を比較します。

外部サービスやデータベースとの接続を代替する仕組みを使う場合は、代替した範囲と実環境で未確認の部分を明記してください。

単体テストを通過しても、機能同士の接続やシステム全体の動作まで確認できたとは限りません。

品質活動の広がりは、QAエンジニアの役割と将来性も参考になります。

出典：IPA「実装および単体テスト」

原因を切り分けて修正する

不具合が出たら、入力、環境、データ、対象コード、外部依存を分け、再現条件を固定します。

表示されたエラーだけを消すのではなく、期待結果との差がどこで生じたかをログやデバッガで追ってください。

原因が設計の不足や共通部品にある場合、担当範囲だけを直すと別の機能に影響するおそれがあります。

修正方針と影響範囲を共有し、関連するテストも実行します。

再発を防ぐには、今回の条件をテストへ追加し、同じ誤りを検知できる状態へ変えることが有効です。

結果と未解決事項を残す

テスト結果には、実施した環境、対象の版、入力データ、期待結果、実際の結果を記録します。

不具合を修正した場合は、原因、変更箇所、再確認した範囲を関連チケットと結び付けてください。

制約によって確認できなかった項目や、次工程で確かめる事項も隠さず残します。

証跡の形式はプロジェクトで異なりますが、後から同じ条件を再現し、判断の経緯を追えることが基準です。

実装工程の成果物と完了条件

実装工程の成果物はソースコードだけではなく、設定、単体テストの仕様・結果、レビュー記録、課題の記録などを含む場合があります。

完了は「コードを書き終えた時点」ではなく、定めた確認を終え、次工程が正しい版を利用できる状態で判断します。

コードと設定を管理する

ソースコード、設定ファイル、依存関係、ビルド手順をリポジトリで管理し、対象の版を識別できるようにします。

環境ごとに異なる値や認証情報は、コードへ直接埋め込まず、プロジェクトの管理方法に従って分離してください。

変更を登録するときは、目的が分かる説明と関連チケットを付けます。

生成物を含めるか、設定例をどこまで置くかなど、リポジトリのルールも確認が必要です。

別の担当者が同じ手順でビルド・実行できることが、引き渡し可能な状態の一つの目安になります。

テスト・レビュー記録を整える

単体テスト仕様には、確認対象、前提条件、入力、操作、期待結果を記載します。

結果には実施日だけでなく、対象の版と環境を結び付け、どのコードを確認したか分かるようにしてください。

レビュー記録には、指摘、対応内容、判断結果、未解決事項を残します。

形式はチケット、レビュー機能、文書などさまざまですが、同じ情報を複数箇所へ重複させる場合は更新元を決めます。

記録量を増やすより、次工程と保守で必要な情報へ迷わずたどれることを優先します。

次工程へ引き渡す

結合工程へ渡す前に、対象機能、版、ビルド方法、設定、単体テスト結果、既知の制約をまとめます。

関連モジュールやデータ変更がある場合は、適用順と戻し方も共有してください。

完了条件は、レビュー承認、テスト通過、重大な未解決事項がないことなど、プロジェクトの基準に照らして判断します。

すべての課題をゼロにできない場合は、影響、回避方法、対応予定を合意します。
次工程が安全に作業を始められる状態まで整えることが、実装工程の完了です。

実装品質と経験の広げ方

実装品質は、要求された機能が動くだけでなく、読みやすさ、変更しやすさ、安全性、確認可能性を含めて考えます。
案件を選ぶときも言語名だけを見ず、設計確認、レビュー、テスト、改善のどこまで担当できるかを比較してください。

読みやすく変更しやすく作る

読みやすいコードは、名前、責任範囲、依存関係が整理され、変更理由を追いやすい状態です。

複雑な処理を無理に短くせず、機能の境界に合わせて分け、重複や不要な分岐を減らします。

既存コードを直すときは、同時に大規模な整理を行うと変更目的が分かりにくくなるため、必要な修正と改善を分けて検討します。

性能や抽象化も、測定結果や予想される変更に基づいて判断してください。

チームのレビューで理解でき、テストで振る舞いを確かめられることが保守性につながります。

セキュリティを実装へ反映する

セキュリティは、実装後に点検項目として追加するだけではなく、設計とコーディングの段階から反映します。

入力値の検証、認証・権限、機密情報の扱い、ログ、依存ライブラリなど、対象システムのリスクに応じた確認が必要です。

組織のセキュアコーディング規約がある場合はそれに従い、レビューや解析ツールの結果を確認します。

警告を機械的に消すのではなく、影響と修正方法を判断してください。

安全性を個人の注意だけに頼らず、ルールとレビューで継続的に確認することが欠かせません。

出典：IPA「製品開発者向け・製品利用者向けガイド」

担当範囲を案件選びに生かす

実装経験を整理するときは、「Javaで開発した」のような言語名だけで終わらせず、対象機能、担当工程、成果物、レビュー、テストを組み合わせます。

設計の不明点を確認した経験や、不具合の原因を切り分けた経験も具体的な役割です。

案件票では、製造の有無に加え、詳細設計の修正、コードレビュー、テスト設計、自動化、リリース対応まで確認してください。

開発・実装を含む案件一覧で業務内容を見比べると、次に求められる経験を把握しやすくなります。

基礎から学び直す場合は、Webエンジニアになるための手順も参考にできます。

システム開発の実装（製造）は、設計を動くプログラムへ変え、レビューと単体テストを通じて次工程へ渡せる状態にする工程です。

名称や境界は案件によって異なるため、設計確認、コーディング、レビュー、テスト、成果物のどこまで担当するかを確認してください。

実装経験を作業内容と判断範囲に分けて整理すると、現在の強みと次に広げたい工程が見えやすくなります。