プログラミング
内部設計をもとにプログラム言語を用いてプログラム(モジュール)の作成を行います。
内部設計とプログラミングの間にプログラム設計を書く場合もあります。
プログラミング工程では「コーディング規約」に沿ってプログラムを作成します。
コーディング規約とは、ソースコードを書くにあたって、共通の決まりごとをまとめたドキュメントです。
関数や変数の名前の付け方、コメントの書き方、エラーハンドリングのパターン、セキュリティ対策、パフォーマンス最適化などのお作法が規定されています。
なお、ソースコード(source code)とはプログラミング言語の言語仕様にそって書かれたテキストのことです。
開発環境の構築
Python、Java、TypeScript、Go、Rustなど、どの言語でプログラムを書く前にも開発環境を構築します。
2026年現在、効率的なシステム開発には統一された開発環境の整備が必須です。
「開発環境」とは、開発をするためのさまざまな機能を実現するためのソフトウェアを集めた環境です。
コンテナ化されたDocker環境やクラウドベースの開発プラットフォーム（GitHub Codespaces、AWS Cloud9など）が主流となり、開発チーム全体で統一された環境を維持することが容易になりました。
これにより、ローカル環境の差異によるトラブルを減らし、チーム全体で同じ環境で開発することが可能です。
たとえばPythonでのバックエンド開発、TypeScriptでのフロントエンド開発、またはGoでのマイクロサービス開発を行う場合、以下のツールが必要になります。
| ソフトウエア・ツール | 目的 |
|---|---|
| テキストエディタ / IDE | ソースコードを書くためのツール。Visual Studio Code（VSCode）、JetBrains IDEs（PyCharm、IntelliJ IDEA、GoLand）、GitHub Codespacesなどが標準的。 |
| ビルドツール / パッケージマネージャー | ソースコードをコンパイルまたはトランスパイルし、実行可能モジュール・パッケージを作成する。npm、pip、Maven、Gradle、Cargo、Goコマンドなど。 |
| デバッガ / 開発者ツール | バグを特定・修正するツール。IDE統合デバッガ、ブラウザ開発者ツール、リモートデバッグ機能、ログ解析ツールなど。 |
| コード解析・品質管理ツール | 静的解析・フォーマッティング・テストカバレッジ測定・セキュリティスキャン。ESLint、Pylint、SonarQube、Trivy、pre-commit hooksなど。 |
| コンテナ化・オーケストレーション | Docker、Kubernetes、Docker Composeなど。開発環境と本番環境の統一、スケーラビリティ確保に必須。 |
これらのツールに加え、ソースコードのバージョン管理（Git）、継続的インテグレーション・継続的デプロイメント（CI/CDパイプライン）、基盤管理を専門とするDevOpsチームが、モダンなシステム開発では標準的な構成です。
GitHub Actions、GitLab CI、Jenkins、CircleCIなどのCI/CDサービスを活用することで、自動テスト、自動ビルド、自動デプロイメントを実現し、開発効率が飛躍的に向上します。
統合開発環境（IDE：Integrated Development Environment）としては、Visual Studio Code、JetBrains製品ファミリー、GitHub Codespacesなどが広く採用されており、拡張機能により言語別の開発効率化が可能です。
なお、大規模なシステム開発の場合は開発環境を提供・管理するための専用チーム（DevOpsチーム）があることがほとんどです。
そのようなシステム開発ではプロジェクトで指定された開発標準（コンテナイメージ、ビルド構成、デプロイメント方法、ネットワーク設定、セキュリティポリシーなど）に則ってプログラミングを行うことになります。
コードレビューと品質管理
プログラミングが終了したら、コードレビューを実施します。
コードレビューとは、完成したソースコードを別の人（またはチーム）がチェックする作業のことです。
コーディング規約に沿っているか、文法の誤りはないか、設計書と異なるコードがないか、セキュリティ上の問題がないか、パフォーマンスの最適化余地がないか、テストカバレッジは十分か、などを確認します。
2026年の現代では、GitHubなどのバージョン管理サービスを通じたプルリクエスト（PR）ベースのコードレビューが業界標準です。
レビュアーはプルリクエストにコメントを付け、マージ前に必要な修正を指摘します。
また、自動化ツール（linter、フォーマッター、静的解析ツール、SAST、依存性チェック）をCI/CDパイプラインに統合することで、基本的な品質チェック、セキュリティ脆弱性検査、依存ライブラリの問題検出を自動化し、レビュアーが論理的な問題やビジネスロジックに集中できる環境を整えるのが一般的な実践です。
実際の現場では時間的制約からコードレビューを簡略化することもありますが、自動化ツールと人的レビューの組み合わせは、後工程での不具合修正コストを大幅に削減し、トータルの開発工数を考えるとほぼ必ず実施しておくべきです。
特にコーディングの経験が浅い担当者に対しては、有識者が丁寧にレビューして、アーキテクチャの問題や潜在的なバグを早期に指摘することで、単体テスト以降の工程で取り除ける不具合を事前に除去しておくことをおすすめします。
■次の記事
単体テスト
ITエンジニアのキャリアアップを検討しているなら
PR
