はじめに
エンジニアとして働き始めてはや1か月が経過。
技術力云々以前の問題として、現場のことを知るためにも 「ずっと受けたかったソフトウェアエンジニアの新人研修第3版」 を読んでみました。
少し古い情報になってしまうか心配でしたが、先日上司から実際の開発のながれについて、話を伺った際 「あれ？本を読んでいたおかげですんなりこの用語がわかるぞ」 となったので、読んでみるのはありかと思います。
では早速、要約・まとめ・私の意見も添えていきたいと思います
対象者
- どんな内容なのかを知りたい人
- 実務経験0年の人
なぜこの本を読もうと思ったのか
- 開発手法、なにそれ？の状態だったから
- 現場にはやくなれるため
- 事前学習。理解度向上の為
- 開発ってどんな流れ？を知るため
- 指導者があまりにも忙しそう。自分で動かないと！と思ったから
読み方
- かかった日数：2日
- 読書スタイル：通勤時間
- じっくりよまない、大枠でつかむ感じ
第1部：ソフトウェア開発基礎知識
第1章：ソフトウェア開発とは
ソフトウェア開発は、単にプログラムを書く作業ではなく、全体としてのシステムをどう設計し、どう進めていくかが重要である事がわかりました。
「早い・安い・正確に」というエンジニアリングの3本柱について、「（某牛丼チェーン風に）」は笑ったｗ
柔軟に変化に対応できる開発スタイルが今の時代に合っている理由がわかりました。つまりアジャイル開発が現代社会では主流となっているという事。構造化された設計の考え方や、分析と設計を分けて考えるアプローチも理にかなっており、複雑なものを扱う上での整理法として非常に参考になりました
開発プロセス（要求定義・要件定義 → 設計 → 製造 → テスト）がきちんと段階を踏んで整理されていることは、プロジェクトの成功に直結する大事な視点だと感じました
第2章：基本的なルール
開発現場では「作業標準」が重要で、これは単にマニュアルというよりも、再現性のある高品質な作業を実現するためのルールであると理解しました。
標準化によって、誰が作業しても一定以上の品質を担保できるのは、チーム開発において重要なポイントであると理解しました。
また、設計書などを作る際の用語の統一や、プロダクトごとのルールも、エンジニアリングの一部だと認識し、「プログラムを書く」だけじゃなく、「情報を正確に伝える」ことも重要な開発の仕事である！と強く感じました。
第2部：ウォータフォール型開発モデルでの開発
第3章：開発プロセスと要求定義・要件定義（要約＆感想）
この章では「そもそも何を作るのか？」を明確にする要求定義・要件定義の重要性が語られていました。特に印象的だったのは、「要求」は顧客の願望そのもの、「要件」はそれを現実的に落とし込んだ設計方針という関係。ここが曖昧だと後々のトラブルになるのは容易に想像できました。
さらに、**機能要求（システムが行う処理）と非機能要求（応答速度や復旧能力など）**の違いも明確で、どちらも開発成功には不可欠。技術面だけでなく、顧客の信頼を得るための提案力や文書力も問われる工程だと感じました。
要件定義書の作成では、曖昧な表現を避けて、役割分担や実現しない内容まで明示するという点が不思議に感じました。開発前の段階で、丁寧に向き合うことが以外と多いことに驚きました。
第4章：設計（要約＆感想）
この章では、システム開発における**「設計」工程の全体像**が紹介されていました。大きく分けて「外部設計」と「内部設計」があり、それぞれに目的と作業内容が明確に異なります。
● 外部設計
システム全体の構成やユーザーとのやりとり（画面や帳票など）を決める工程で、まだコードは書きません。業務フローを可視化しながら、どういう機能が必要か、どんな画面・データがあるかを決めていく流れです。
ここでユーザー視点を意識することが、のちの仕様変更を減らす鍵だと感じました。
● 内部設計
より技術的な内容で、処理ロジックやデータ構造、プログラムの部品化を具体化していきます。再利用しやすい「部品化」を意識することで、品質や効率が上がる一方で、独立させる設計の手間もあるので大変そうだと思いました。
5章：製造とテスト
この章では、「実際にシステムを作る」製造工程と、作ったものをしっかり確認するテスト工程について。
内部設計をもとにコードを書くだけでなく、「ソースコードレビュー」「単体テスト」など、「書く」の先にある工程を知ることができました。
単体テスト・結合テスト・総合テスト・受け入れテストと、テスト工程が何段階もあることに驚きました。特に、
- ホワイトボックステスト（内部構造を見る）
-
ブラックボックステスト（外部から挙動を見る）
という視点の違いが興味深かったです。
バグが出たときは、ただ直すのではなく「なぜ起きたのか」を分析し、次に活かすプロセスも含めて品質保証なんだと感じました。
6章：アジャイル型開発モデル
ウォーターフォール型開発では、要件や設計を最初に決めきるため、途中の変更やズレに対応しにくいという課題があります。
一方アジャイル開発は、短期間での開発（スプリント）を繰り返しながら、常に改善し続けるスタイル。設計・実装・テストを小さな単位で進めるため、変化に強く、現場の声を反映しやすいのが特徴です。
スクラムでは、PO（プロダクトオーナー）、SM（スクラムマスター）、開発チームの三者が役割分担しながらも、自律的に動くチームとして開発を進めていきます。情報共有や信頼関係が非常に重要だと感じました。
7章：スプリントでの活動
アジャイル開発では、スプリントという短期間の開発サイクルをチームで回していきます。その準備として、まずプロダクトバックログを作成。これは「ユーザーが実際にどう使うか（ユーザーストーリ）」をもとに、優先度順に整理された要件リストです。実際に作るべき機能を可視化するのはどの仕事においても大切なんだと実感しました。
次にスプリント計画で、要件をタスクレベルに落とし込んで「スプリントバックログ」を作成。ここで実装範囲が明確になります。
スプリント中は、デイリースクラムで進捗や課題を共有し、必要に応じてペアプロやモブプロで開発。バーンダウンチャートやテスト駆動開発で効率と品質を保ちます。
スプリント後にはスプリントレビューで成果を確認。「どこまでできたら完了か？」を明確にしておく「Doneの定義」がとても重要なんだと知りました。
最後にレトロスペクティブ（振り返り）。KPTという手法で、よかったこと・課題・次に試すことを整理します。個人的にも、反省と改善の繰り返しはチームの成熟に欠かせないと感じています。
第4部：プロジェクトマネジメント
第8章：プロジェクトマネジメント
開発を成功に導くために欠かせないのがプロジェクトマネジメント（PM）。その基本となる考え方が「PMBOK（ピンボック）」。これは、プロジェクトを効率よく進めるための体系的なガイドになります。
プロジェクトとは、日々の業務（ルーティンワーク）とは異なり、独自性と有期性が特徴です。
PMBOKは10の「知識エリア」で構成されており、たとえば以下のような領域がありました
- 統合・スコープ・スケジュール・コスト・品質
- リスク・資源・調達・コミュニケーション・ステークホルダー
また、プロジェクトの時間軸について、PMBOKでは５つあり「立ち上げ➡監視・コントロール（実行⇔計画）➡終結」で構成されています。状況に合わせた変更が必要である事が理解できました。
最後に、プロジェクトの特性に応じて、手法を柔軟に調整（＝テーラリング）するのも重要な考え方で、要件が明確なら予測型（ウォータフォール）、変化に対応したいなら**適応型（アジャイル）**を選ぶ、という考えかたを知ることができました。
第9章：セキュリティ
システム開発において、セキュリティは「後から考えるもの」ではなく、最初から意識すべき設計思想だと感じました。
セキュリティは技術的に難しそうな印象もありますが、本章を通じて「信頼されるシステムを作るための基本的責任」だということを学びました。
特に、普段何気なく使っているサービスの裏では、こうした仕組みや配慮があるからこそ安心できていることを再認識。今後自分が開発に関わる際も、機能だけでなく安心も一緒に提供できるよう意識していきたいです。
さいごに
この技術書を読むことで、開発の流れを大まかにですが知ることができました。
加えて、一つの開発方法だけでなく、他の開発方法も知ることで、柔軟に対応できるようになるのではないかと思いました。
執筆段階では研修中の身であり、設計含む「上流工程」は「？？」の状態でしたが、複雑で大変そうだけどこれがお客様・多くの人に役立つサービス作りの開発につながる本質的な部分であると感じました。
引き続き、他の技術書も読み、アウトプットを心掛けていきたいと思います