研修期間にソフトウェア開発の入門書を読み直してみた
はじめに
こんにちは、クラスメソッドオペレーションズ株式会社26新卒の伊藤です！
4月に入社したものの、まだ本格的な業務は始まっておらず研修期間中です。「せっかくの時間があるうちに基礎を固めておきたい」と思い、学生時代に一度読んだソフトウェア開発の入門書を読み直してみました。
今回読み直した本はこちらです。
「ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版」
飯村 結香子・大森 久美子・西原 琢夫（著）、川添 雄彦（監修）
ウォータフォール型・アジャイル型の両方をバランスよく解説してくれている入門書で、ゼロから読めるので、IT企業への就職が決まった学生さんにもおすすめできます。
学生のときは「資格の勉強になりそう」という動機で読んでいたのですが、今回はIT企業に入った身として読んでみると、理解の解像度がけっこう変わった気がします。
この記事は、同じ26卒の新入社員の方や、これからIT企業を目指す27卒の学生さんに向けて「業務が始まる前にこういう全体像を知っておくと役立ちそう」という気持ちで書いています。ガチガチの技術解説というよりは、ざっくり全体像をつかむための読み物として読んでもらえると嬉しいです。
第1章：ソフトウェア開発ってそもそも何？
「早く・安く・正確に・誰でも」が目標
ソフトウェア開発の世界にはソフトウェアエンジニアリングという考え方があります。
もともとソフトウェアが大規模になるにつれて、品質や生産性がどんどん落ちていく「ソフトウェア危機」というものが起きたそうです（1960年代の話です）。その危機を乗り越えるために「プログラム開発を工学として体系化しよう」という動きが生まれました。
目標はシンプルで、早く・安く・正確に・誰でも作れるようにすること。
学生のときは「なるほどね」と流していたのですが、IT企業に入る身になって「納期・コスト・品質のバランス」という話がリアルに感じられるようになりました。
開発モデルは3種類が代表的
開発の進め方には大きく3種類あります。
ウォータフォール型
要件定義 → 設計 → 製造 → テスト → 運用、と順番通りに進む方法です。計画的に進められる反面、途中で要件が変わると最初まで戻る必要があって大変です。開発途中で顧客の求めることが変わってしまう現象を「ムービングターゲット」と呼ぶのですが、これへの対応が苦手なのが弱点です。
スパイラル型
ウォータフォールの良いところを活かしつつ、各段階で「実際に動くもの（プロトタイプ）」を作りながら確認を挟んで進める方法です。こまめに確認できるので問題を早めに発見しやすいのが特徴です。
アジャイル型
短いサイクルで開発・確認を繰り返す方法です。「変化する要求を受け入れる」というスタンスで、ビジネス環境が速く変わる今の時代に合っていると言われています。後の章でもしっかり触れます。
第2章：開発の「共通ルール」って意外と大事
用語と表記を統一する理由
複数人で開発するとき、ドキュメントの書き方がバラバラだと読み解くのに余計な時間がかかります。「コンピュータ」か「コンピューター」か、句読点は「、。」か「,.」か……こういった細かいルールも、チーム内でそろっていないと意思疎通の妨げになります。
学生のときは「そこまで気にする？」と思っていたのですが、読んでいるうちに「文書の読みやすさも品質のひとつ」という考え方に素直に納得できました。
図を使って「伝える」
開発ではさまざまな図が使われます。代表的なものだと以下のようなものがあります。
- UML（クラス図・シーケンス図・ユースケース図など）：オブジェクト指向に基づいたモデリング記法
- フローチャート：処理の流れを図で表したもの
- DFD（Data Flow Diagram）：データの流れを表したもの
- 状態遷移図：イベントによって内部状態がどう変化するかを表したもの
基本情報や応用情報の勉強をしていると、これらの図は一度は見たことがあるはずです。試験で見るのと実際の設計書で使われているのでは目的が違いますが、読み書きできると絶対に役立つので、この機会に読み方だけでも押さえておくといいと思います。
第3章：要求定義と要件定義、何が違うの？
「顧客の要求」と「システムの要件」は別物
学生時代に読んだとき、正直ここが一番ピンとこなかったです。
シンプルに整理するとこうなります。
- 要求定義：顧客が「こんなことをしたい」と言ったことを整理する段階（多少の矛盾や重複があっても許容される）
- 要件定義：その要求をもとに「システムとして何を実現するか」をきっちり決める段階（矛盾・重複・不足はNG）
区別するコツとして「顧客の〇〇」「システムの〇〇」と頭につけて考える方法があります。「顧客の要件」はおかしい、「顧客の要求」が正しい、というイメージです。
要件定義は後の全工程のバイブルになるので、ここがズレると最終的にできあがるものもズレる、というのはなるほどと思いました。
機能要求と非機能要求
要求はさらに2種類に分かれます。
- 機能要求：「〇〇を検索できる」「〇〇を登録できる」など、システムの機能そのもの
- 非機能要求：「検索は0.5秒以内に完了する」「障害が起きても1時間以内に復旧する」など、機能以外の条件
非機能要求は後回しになりがちですが、システムの使いやすさや信頼性に直結する大事な部分です。応用情報の試験でも出てくる概念なので、馴染みのある方も多いと思います。
第4章：設計は「外部」と「内部」の2段階
外部設計：ユーザ目線で「何を作るか」を決める
外部設計では、システムを外から見たときの振る舞いを定義します。画面のレイアウト、データの構造、外部システムとのやり取りなどがここで決まります。
データ設計でよく使われる図としてER図とCRUD図があります。
- ER図：データの「もの（エンティティ）」と、そのものどうしの関係（リレーションシップ）を表した図
- CRUD図：あるエンティティに対して、生成（Create）・参照（Refer）・更新（Update）・削除（Delete）のどの操作が行われるかをまとめた表
どちらも基本情報・応用情報の勉強で見た記憶があると思うので、「あのときの知識ってここで使われるのか」と繋がる部分です。
内部設計：プログラマ目線で「どう作るか」を決める
内部設計では、実際にプログラムが書けるレベルまで詳細を落とし込みます。
印象に残ったのは、内部設計書を作る目的のひとつが「プログラマのスキルによらず品質を均一にする」ことだという点です。誰が作っても同じ品質になるように設計書で仕様を固めておく、という発想は、これから開発現場に入る前の自分にとって新鮮な視点でした。
第5章：製造とテストの流れ
コーディング規約はチームのルール集
プログラムを書くときは、チームで決めたコーディング規約に従います。変数名のつけ方、コメントの書き方、処理の記述ルールなど、細かいルールが定められています。
たとえばこんな感じです。
⭕️ inputRecordCounter（英語で意味がわかる名前）
❌ nyuuryokuRekodokaunta（ローマ字読み）
⭕️ dataCount = 0; /* データ数カウントを初期化する */（なぜそうしているかがわかる）
❌ dataCount = 0; /* dataCountを0にセットする */（何をしているかの説明になっている）
「後から自分や他の人が読んだときに理解できるか」を常に意識する、というのは研修期間中からでも意識できることだと思います。
テストにはいくつかの種類がある
テストは大きく以下の流れで進みます。
- 単体テスト：プログラムの最小単位ごとにテストする。内部構造を見ながらテストデータを作る「ホワイトボックステスト」が主に使われる
- 結合テスト：プログラム同士を組み合わせてテストする。入力と出力だけを確認する「ブラックボックステスト」が主に使われる
- 総合テスト：本番に近い環境でシステム全体をテストする
また、単体テストでは他のプログラムとの依存関係を切り離すために「ドライバ」（呼び出し元の仮プログラム）や「スタブ」（呼び出し先の仮プログラム）という仮のプログラムを使います。基本情報でも出てくる概念なので、知っている方は「あれか！」となるはずです。
第6章・第7章：アジャイル開発はチームスポーツ
アジャイルは「小さく作って、早く確認する」
アジャイル開発（特にスクラム）では、短いサイクル（スプリント）を繰り返しながら開発します。
大まかな流れはこんな感じです。
- やりたいことを整理してリスト化（プロダクトバックログ）
- 今回作るものを決めて計画（スプリント計画）
- 設計・製造・テストを実施（スプリント）
- 毎日状況を共有（デイリースクラム）
- 作ったものを確認（スプリントレビュー）
- チームとして振り返り（ふりかえり）
ウォータフォール型との一番大きな違いは、「実現範囲を最初に固定しない」点です。ウォータフォールでは最初に決めた範囲通りに作ることを目指しますが、アジャイルでは変化する要求を受け入れながら優先度の高いものから順番に作っていきます。
「ふりかえり（KPT）」という考え方が印象的だった
Keep（続けること）・Problem（うまくいかなかったこと）・Try（次に挑戦すること）の3つでスプリントを振り返る方法を「KPT」と言います。
このなかで特に刺さったのが「問題点を "ひと"のせいにせず、"こと"として反省する」というスタンスです。誰かを責めるのではなく、何が起きたかに焦点を当てる。開発に限らず仕事全般に使える考え方だなと思いました。
見積もりに使う「プランニングポーカー」も面白い
フィボナッチ数列（1, 2, 3, 5, 8, 13…）が書かれたカードを全員が同時に出して、ストーリの開発量を見積もる手法です。数字が一致しない場合は理由を話し合って合意するまで繰り返します。認識のズレを可視化できるのが面白いなと思いました。
第8章：プロジェクトマネジメントって何をする仕事？
開発を「プロジェクト」としてとらえる
ここで出てくるのが PMBOK（Project Management Body of Knowledge） という考え方です。プロジェクトマネジメントの知識体系をまとめたもので、世界的に広く使われている標準です。応用情報でも登場する概念なので、見聞きしたことがある方も多いと思います。
まず「プロジェクトとは何か」という話から始まります。プロジェクトの特徴は大きく2つです。
- 独自性：毎回まったく同じことを繰り返すのではなく、何か新しいもの・独自のものを作り出す
- 有期性：始まりと終わりが決まっている（ずっと続く定常業務とは違う）
この2つが揃っているものがプロジェクトです。毎日の運用・保守作業などのルーティーンワークとは区別されます。「期限があって、新しいものを作る」というのがプロジェクトのイメージですね。
PMBOKの構成：プロセス・知識エリア・プロセス群
PMBOKはプロジェクトマネジメントの活動をプロセス（作業の単位）として整理しています。そのプロセスを2つの軸で分類しているのが特徴です。
- 知識エリア：「何を管理するか」の分類（スコープ・コスト・スケジュール・品質・リスクなど）
- プロセス群：「いつやるか」の分類（立ち上げ→計画→実行→監視・コントロール→終結）
この2軸で全プロセスをマッピングしたものが「プロセスマップ」です。
また、PMBOKをそのままプロジェクトに当てはめるのではなく、プロジェクトの性質に合わせて必要なプロセスを取捨選択することをテーラリングと言います。「PMBOKに書いてあることを全部やらないといけない」わけではなく、状況に合わせて使い方を調整するという考え方です。
「予測型」か「適応型」か
プロジェクトのライフサイクルには大きく2種類あります。
- 予測型：最初に計画を立て、それに沿って進めるスタイル。ウォータフォール型の開発と相性が良い
- 適応型：変化に柔軟に対応しながら進めるスタイル。アジャイル型の開発と相性が良い
どちらが正解というわけではなく、プロジェクトの不確実性の高さによって選ぶのが大事だというのがポイントです。「どのくらい要件が変わりそうか」「どのくらい未知の要素があるか」によって、どちらのスタイルが向いているかが変わります。
第1章で学んだウォータフォール型・アジャイル型という開発モデルの話が、ここでプロジェクト全体の視点と繋がってくる感じがして、読んでいて「なるほど、そういう構造か」と整理されました。
第9章：セキュリティは後付けじゃダメ
2種類のセキュリティ
セキュリティには2つの視点があります。
- プロダクトのセキュリティ：開発するシステム自体を守る視点
- 開発プロセスのセキュリティ：設計書や仕様書など、開発中に作られるドキュメントを守る視点
後者は盲点になりやすいですが、設計書には業務ノウハウや内部構造の情報が詰まっているため、漏れると攻撃のヒントを与えてしまいます。個人のUSBメモリを業務PCに挿してはいけないというルールも、こういった観点から来ているんだなと納得しました。
また「セキュリティと利便性はトレードオフ」という話もあります。セキュリティを高めるほど使いやすさが下がることがあるため、どこまでやるかの判断が必要です。
そして一番大事なポイントとして「セキュリティは設計の段階から考える」こと。後から追加しようとすると設計を大幅に見直す必要が出てくるケースがあります。これは覚えておきたいと思いました。
読み直してみて感じたこと
全体を通じて感じたのは「開発は結局コミュニケーションだ」ということです。
要件定義での顧客との合意形成、設計書でのチームへの情報共有、ふりかえりでのチーム内の対話……どの工程にも「正確に伝える」「認識を合わせる」というテーマが通底しています。
学生のときは「技術を学べばなんとかなる」という意識で読んでいたのですが、改めて読んでみると「誰と、どう動くか」の部分が開発のいたるところに出てきていることに気づきました。業務が始まる前にこの視点を持てたのは、読み直した価値があったなと感じています。
まだ実際に手を動かした経験はないので、今後業務を通じて「ああ、あのときの内容はこういうことだったのか」と繋がる瞬間が来ることを楽しみにしています。同じ境遇の方がいればぜひ意見交換しましょう！
まとめ
| 章 | 内容のひとことまとめ |
|---|---|
| 第1章 | 開発手法（ウォータフォール・スパイラル・アジャイル）の全体像 |
| 第2章 | 表記統一・図の使い方など開発の共通ルール |
| 第3章 | 要求定義と要件定義の違い、機能・非機能要求 |
| 第4章 | 外部設計（何を作るか）と内部設計（どう作るか） |
| 第5章 | コーディング規約と単体・結合・総合テスト |
| 第6章 | アジャイル開発の概要とウォータフォールとの違い |
| 第7章 | スクラムの具体的な流れ（バックログ・スプリント・ふりかえり） |
| 第8章 | PMBOKの構成、予測型・適応型のライフサイクル |
| 第9章 | プロダクトと開発プロセス、2つのセキュリティ視点 |
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました。
