ITパスポート試験｜開発技術の基礎知識とソフトウェア開発モデル　IT Passport Exam | Development Technology: Fundamentals and Software Development Models

ITパスポート試験の出題分野の中でも、「開発技術」は毎回必ずと言っていいほど多くの問題が出てきます。「システム開発って何となく難しそう…」と感じている方でも、一つひとつの工程の意味を整理していけば、意外とスッキリ理解できます。本記事では、開発の流れを順番に追いながら、試験に出る重要ポイントをしっかり押さえていきましょう。

Development technology is one of the most heavily tested areas in the IT Passport exam. If the topic feels intimidating at first, don’t worry — once you work through each stage of the development process in order, the pieces fall into place more naturally than you might expect. This article walks through the development flow step by step, covering every key point you need for the exam.

システムとソフトウェアの違いから始まり、開発プロセスの全体像・システム要件定義・システム設計・プログラミング・テスト・開発モデル（ウォーターフォール・アジャイル）・DevOps・ソフトウェアの見積り手法まで、試験頻出テーマを網羅的に解説します。

This article covers all the frequently tested topics in a comprehensive way: the difference between systems and software, the overall development process, system requirements definition, system design, programming, testing, development models (waterfall and agile), DevOps, and software cost estimation methods.

システムとソフトウェアの違い / The Difference Between Systems and Software

「システム」と「ソフトウェア」は混同されやすい用語ですが、ITパスポート試験ではこの2つを明確に使い分けています。システムとは、ハードウェアとソフトウェアを組み合わせた全体のことを指します。ソフトウェアはあくまでシステムを構成する要素の一つにすぎません。身近な例で考えてみましょう。銀行のATMを思い浮かべてください。ATMを動かすためには、端末本体や通信回線などの「ハードウェア」と、残高照会や振込処理を行う「ソフトウェア」の両方が必要です。この2つが揃って初めて、私たちが利用できる「システム」が成り立ちます。

“System” and “software” are terms that are easy to confuse, but the IT Passport exam uses them with clear distinction. A system refers to the overall combination of hardware and software working together. Software is simply one component that makes up a system. Think of a bank ATM as a familiar example. To run an ATM, you need both hardware — such as the terminal itself and communication lines — and software that handles tasks like balance inquiries and fund transfers. Only when both are in place does the “system” that customers can actually use come to life.

システム開発とは / What Is System Development?

システム開発とは、業務上の目的を達成するために必要なハードウェアを手配し、その目的に合ったソフトウェアを設計・構築する一連の活動のことです。手作業で行っていた業務をシステムに置き換えれば、処理速度の向上やミスの削減など、大幅な業務改善が期待できます。ただし、優れたシステムを作るためには、IT技術の知識だけでは足りません。その業務に関わる経営・法律・会計などの幅広い知識がなければ、技術的には正しく動くシステムができたとしても、現場の課題を本当の意味では解決できないからです。試験では「システム要件定義」「ソフトウェア保守」「システムテスト」「システム方式設計」の4つの用語が特によく出題されます。

System development is the entire set of activities involved in arranging the hardware needed to achieve a business objective and designing and building software tailored to that objective. Replacing manual tasks with a system can bring significant improvements — faster processing, fewer errors, and more. However, IT expertise alone is not enough to build a truly effective system. Without broad knowledge of business management, law, and accounting, even a technically sound system may fail to solve real workplace challenges. The exam places particular emphasis on four terms: system requirements definition, software maintenance, system testing, and system architecture design.

ソフトウェアライフサイクルプロセス（SLCP）/ Software Life Cycle Process (SLCP)

システム開発は、一連の決まったプロセスに沿って進められます。この流れ全体をソフトウェアライフサイクルプロセス（SLCP）といいます。SLCPは主に「企画」「要件定義」「開発」「運用」「保守」という5段階のプロセスで構成されています。本記事では、試験での出題頻度が特に高い「開発」「運用」「保守」の3つのプロセスを中心に解説します。

System development proceeds through a fixed series of defined processes. This overall flow is called the Software Life Cycle Process (SLCP). The SLCP is structured around five main stages: planning, requirements definition, development, operation, and maintenance. This article focuses on the three stages most frequently tested: development, operation, and maintenance.

システム要件定義 / System Requirements Definition

開発プロセスのスタート地点となる工程がシステム要件定義です。これから構築するシステムが満たすべき条件（システム要件）を洗い出して確定させる工程のことで、「作るべきシステムの姿を発注者と開発者が合意するためのプロセス」ともいえます。この段階できちんと要件を文書化して双方で確認しておくことで、後から「そんなことは頼んでいない」というトラブルを未然に防ぐことができます。

The starting point of the development process is system requirements definition. This is the process of identifying and finalizing the conditions (system requirements) that the system being built must meet — in other words, it is the process by which the client and the development team reach a shared agreement on what the system should look like. Thoroughly documenting and confirming the requirements at this stage prevents disputes later, such as “we never asked for that.”

機能要件と非機能要件 / Functional and Non-Functional Requirements

システム要件は機能要件と非機能要件の2種類に分類されます。機能要件とは、ユーザーとのヒアリングを通じて明確になる、システムが果たすべき具体的な機能のことです。例えば「スーパーのレジシステムで商品のバーコードを読み取り、合計金額を自動的に計算すること」のような機能がこれにあたります。一方、非機能要件とは、ユーザーへのヒアリングでは自然には出てこないものの、システムが備えるべき性能や品質に関する条件のことです。「1件の照会処理を3秒以内に完了すること」「年間の稼働率を99.9%以上に保つこと」などがその代表例です。機能要件はユーザー自身が意識しているのに対し、非機能要件はユーザーが意識していないことが多いという点が大きな違いです。

System requirements are classified into two types: functional requirements and non-functional requirements. Functional requirements are the specific functions the system must perform, identified through interviews with users — for example, “the supermarket checkout system must scan product barcodes and automatically calculate the total.” Non-functional requirements, by contrast, are conditions related to the system’s performance and quality that users typically do not bring up on their own during interviews — typical examples include “each inquiry must complete within 3 seconds” and “the system must maintain an annual uptime of 99.9% or higher.” The key difference is that functional requirements are things users are consciously aware of, while non-functional requirements are often not on the user’s radar at all.

6つの品質特性 / Six Quality Characteristics

ソフトウェアの品質を客観的に評価するための基準として、6つの品質特性が定められています。なお、国際規格上は現在8特性に更新されていますが、ITパスポート試験では6特性で出題されます。機能性とは、目的に対して必要な機能がどれだけ実装されているかの度合いです。信頼性とは、障害が発生せず機能が継続して正しく動き続けられるかの度合いです。使用性とは、利用者にとってわかりやすく、快適に操作できるかの度合いです。効率性とは、処理速度や資源消費の観点で、目的に対して無駄なく動作するかの度合いです。保守性とは、不具合の修正や機能の改善にかかる手間の少なさの度合いです。移植性とは、別のOS環境やハードウェア環境に移した場合でも問題なく動作できるかの度合いです。

There are six quality characteristics defined as objective criteria for evaluating software quality. Functionality is the degree to which all the functions required for the intended purpose have been implemented. Reliability is the degree to which the software continues to operate correctly without failures. Usability is the degree to which the software is easy for users to understand and operate comfortably. Efficiency is the degree to which the software operates without waste in terms of processing speed and resource consumption relative to its purpose. Maintainability is the degree to which fixing defects and improving features requires minimal effort. Portability is the degree to which the software can operate without problems after being moved to a different OS or hardware environment.

システム設計 / System Design

システム要件定義によって「作るべきシステムの姿」が決まったら、次はシステム設計の工程に進みます。システム設計とは、確定した要件をもとに、実際にシステムを構築するための設計図を具体的に作り上げていく工程です。システム設計はさらに4つの工程に細分されます。なお、利用者の目に触れる部分の設計を外部設計、利用者から見えない内部の仕組みの設計を内部設計と呼ぶこともあります。

Once system requirements definition has determined what the system should look like, the process moves to system design — the stage of concretely drawing up the blueprints for actually building the system based on the confirmed requirements. System design is further subdivided into four sub-processes. Design of the parts that users see and interact with is called external design, while design of the internal mechanisms invisible to users is called internal design.

システム設計の4工程 / The Four System Design Sub-Processes

システム設計は次の4つの工程で構成されます。①システム方式設計とは、システム要件として確定した各項目を「ハードウェアで実現するか」「ソフトウェアで実現するか」「人が手作業で行うか」という3つの区分に整理・割り当てる工程です。この工程を経ることで、システムに「何が」必要になるのかを関係者全員が共有できるようになります。②ソフトウェア要件定義とは、①でソフトウェアの担当と決まった要件を、より詳細に具体化していく工程です。画面や帳票などのインタフェース要件と、扱うデータの種類やデータベースに関するデータ要件の2つが主な検討対象です。③ソフトウェア方式設計とは、②で定めたソフトウェア要件をプログラムとして実装できる「プログラム単体の単位」にまで細かく分割していく工程です。④ソフトウェア詳細設計とは、③でプログラム単位に分割された要件を、さらに実際にコードを書ける最小単位にまで落とし込む工程です。この工程では処理の流れを具体的に検討し、その内容をフローチャート（流れ図）として整理します。

System design consists of four sub-processes. ① System architecture design organizes and assigns each confirmed system requirement to one of three categories: “realized by hardware,” “realized by software,” or “performed manually by people.” Completing this step lets all stakeholders share a clear picture of “what” the system will need. ② Software requirements definition takes the requirements assigned to software in step ① and develops them in much greater detail. The two main areas examined are interface requirements — such as screens and forms — and data requirements — covering the types of data involved and database specifications. ③ Software architecture design breaks down the software requirements defined in step ② into individual program units small enough to be implemented as discrete programs. ④ Software detailed design takes the program-unit requirements from step ③ and breaks them down further into the smallest units that can actually be coded. In this step, the processing logic is worked out in detail and organized as a flowchart.

重要ポイント / Key Point

「システム方式設計」と「ソフトウェア方式設計」は名前が非常によく似ていますが、まったく別の工程です。「システム」という単語がついている用語はシステム全体に関するプロセス、「ソフトウェア」という単語がついている用語はソフトウェアだけに関するプロセスです。混同しないよう注意しましょう。

“System architecture design” and “software architecture design” have very similar names but are completely separate processes. Terms that include “system” relate to the system as a whole; terms that include “software” relate to the software component only. Take care not to confuse them.

プログラミング / Programming

システム設計が完了したら、いよいよプログラミングの工程に入ります。プログラミングとは、コンピュータに実行させたい処理の手順を、プログラム言語のルールに従って記述する工程のことです。この工程を担当する人を「プログラマ」といいます。また、フローチャートをもとにして実際のコードを書き起こす作業を、特に「コーディング」と呼びます。試験では「プログラミングはどの工程の後に行われるか」が問われることがあります。正解は「ソフトウェア詳細設計の後」です。

Once system design is complete, the process enters the programming stage. Programming is the process of writing down the sequence of operations to be executed by the computer, following the rules of a programming language. The person responsible for this work is called a “programmer.” The specific act of translating a flowchart into actual code is called coding. The exam may ask which process comes just before programming — the answer is that programming follows software detailed design.

プログラムから機械語へ / From Program to Machine Language

コンピュータが直接理解できるのは、0と1だけで表現された機械語のみです。しかし、人間が機械語を直接書くことは現実的ではありません。そこで現在のプログラミングでは、「まず人間にとって読み書きしやすいプログラム言語でコードを作成し、それを専用のソフトウェアで機械語へ自動変換してコンピュータに渡す」という流れをとります。この変換処理のことをコンパイル、変換を実行するソフトウェアのことをコンパイラといいます。また、変換前の人間が書いたコードのことをソースコードと呼びます。

The only language a computer can directly understand is machine language — represented entirely using 0s and 1s. Writing machine language directly is not a realistic option for humans, however. Modern programming therefore follows this workflow: code is first written in a programming language that humans can read and write easily, and then automatically converted into machine language by dedicated software before being passed to the computer. This conversion process is called compiling, and the software that carries it out is called a compiler. The human-written code before conversion is called source code.

テストとソフトウェア受入れ / Testing and Software Acceptance

プログラミングが完了したら、作成したプログラムやシステム全体が意図どおりに動くかを確かめるテストを実施します。テストとは、システムが設計仕様を満たした動作をしているかどうかを検証する工程です。不具合が残ったまま本番稼働に入ると、業務上の損害が生じるリスクがあります。事前にテストを重ねることで、その可能性を最小限に抑えます。試験では「システムテスト」「結合テスト」「ブラックボックステスト」「ホワイトボックステスト」「ソフトウェア受入れ」の5つの用語が特によく問われます。

Once programming is complete, testing is carried out to confirm that the programs and the overall system behave as intended. Testing is the process of verifying that the system operates in a way that meets the design specifications. Going live with defects still in place risks causing damage to business operations. Thorough testing beforehand minimizes that risk. Five terms appear particularly frequently on the exam: system testing, integration testing, black-box testing, white-box testing, and software acceptance.

テストの種類（V字モデル） / Types of Testing (V-Model)

テストには4つの種類があり、開発の各工程と対応する形でV字を描く構造になっています。この対応関係を図にしたものをV字モデルといいます。テストは最も小さな単位から順に実施され、最終的な運用テストで検証対象が業務全体の要件にまで広がります。単体テストとは、個々のプログラムが単体として正しく動作するかを確かめるテストです。通常はホワイトボックステストの手法が用いられ、開発者が担当します。結合テストとは、単体テストを通過したプログラム同士を連携させたときに、データの受け渡しや連携動作が正しく行われるかを確かめるテストです。プログラム同士の「つなぎ目（インタフェース）」に問題がないかを検証します。主にブラックボックステストの手法で実施されることが多いです。システムテストとは、応答時間や稼働時間を含むシステム要件が、設計仕様どおりに達成されているかを確かめるテストです。開発者が担当します。運用テストとは、本番と同等の環境でシステムを動かし、業務要件を完全に満たしているかをユーザー自身が確認するテストです。

There are four types of tests, structured so that they correspond to development stages and form a V-shape — a diagram of this correspondence is called the V-model. Testing proceeds from the smallest units outward, with the final operation test covering the full scope of business requirements. Unit testing confirms that each individual program works correctly on its own. White-box testing methods are normally used, and it is conducted by the development team. Integration testing confirms that programs which have passed unit testing work correctly together — specifically, that data is passed correctly and that the connections (interfaces) between programs function without issue. Black-box testing methods are mainly used. System testing confirms that system requirements — including response time and uptime — are being met as specified. It is conducted by the development team. Operation testing has users themselves verify that the system fully satisfies business requirements by running it in an environment equivalent to the live production setup.

ホワイトボックステストとブラックボックステスト / White-Box Testing and Black-Box Testing

ホワイトボックステストとは、プログラムの内部的な処理構造を把握したうえで、すべての実行経路が正しく動作するかを検証するテスト手法です。「箱の中身を透かして見ながら確認する」イメージで、プログラム内部のロジックを隅々まで追いかけます。内部構造への深い理解が求められるため、プログラマなどの開発者が担当します。一方、ブラックボックステストとは、プログラム内部の仕組みを一切考慮せず、入力に対して期待どおりの出力が得られるかだけを確認するテスト手法です。「箱の中はまったく見ない」というスタンスで、仕様書に書かれた動作と実際の動作が一致しているかを確かめます。内部構造の知識がなくても実施できるため、開発者だけでなく発注者（エンドユーザー）も参加して行います。

White-box testing is a method that verifies whether all execution paths within a program operate correctly by examining the program’s internal processing structure. Think of it as checking while looking straight through the box — the internal logic of the program is traced in detail. Because a deep understanding of the internal structure is required, it is carried out by developers such as programmers. Black-box testing, by contrast, ignores the internal workings of the program entirely and simply checks whether a given input produces the expected output. The stance is “don’t look inside the box at all” — the goal is to confirm that the actual behavior matches what is written in the specifications. Because no knowledge of the internal structure is needed, it is conducted not only by developers but also by the client (end users).

ソフトウェア受入れ / Software Acceptance

テストが完了したら、いよいよ開発プロセスの最終工程であるソフトウェア受入れです。ソフトウェア受入れではソフトウェア導入とソフトウェア受入れ支援の2つが行われます。ソフトウェア導入とは、完成したソフトウェアを発注者の本番環境にセットアップする工程です。続くソフトウェア受入れテストは、発注者がシステムを正式に引き受けるにあたって、契約で取り決めた仕様どおりに仕上がっているかを確認するテストです。このテストを主体的に行うのは発注者側です。受入れテストで問題がなければ、正式な納品・引き渡しとなります。

When testing is complete, the development process reaches its final stage: software acceptance. Two activities take place here: software installation and software acceptance support. Software installation is the process of setting up the completed software in the client’s live production environment. The subsequent software acceptance test is conducted by the client to confirm that the system has been completed in accordance with the specifications agreed in the contract. The client is the primary party carrying out this test. If the acceptance test raises no issues, the system is formally delivered and handed over.

運用プロセスと保守プロセス / Operation Process and Maintenance Process

開発プロセスが終わり発注者がシステムを受け入れると、次は運用プロセスと保守プロセスへと移行します。システム開発は「納品して終わり」ではありません。利用者が長期にわたって安心してシステムを使い続けられるよう、継続的なサポートが欠かせません。運用プロセスとは、完成したシステムを実際の業務環境で稼働させる工程です。利用者マニュアルを活用した継続的な教育・支援もこのプロセスに含まれます。保守プロセスとは、稼働後に発見された不具合の修正や、新たな業務ニーズに対応するための機能追加を行う工程です。試験ではこのプロセスを「ソフトウェア保守」という用語で出題します。重要なのは、テスト環境や導入前の準備段階ではなく、実際に稼働している本番環境に対して作業を行う工程であるという点です。

Once the development process is complete and the client has accepted the system, the process transitions to the operation process and the maintenance process. System development does not end at delivery — continuous support is essential to allow users to keep using the system safely over the long term. The operation process is the stage of running the completed system in the actual business environment, including ongoing user education and support using the user manual. The maintenance process is the stage of fixing defects discovered after go-live and adding new functions to address evolving business needs. The exam refers to this using the term software maintenance. The key point is that this is work performed on the live production environment that is already in operation — not a test environment or a pre-launch preparation stage.

ソフトウェアの開発モデル / Software Development Models

ソフトウェア開発の進め方や手順をパターンとして整理・体系化したものをソフトウェア開発モデルといいます。開発会社や案件によって進め方はさまざまですが、試験では「ウォーターフォールモデル」と「アジャイル開発」の2つが最も頻繁に出題されます。

A software development model is a systematized pattern that organizes the approach and procedures for developing software. While development companies and projects vary in their approaches, the exam most frequently tests two models: the waterfall model and agile development.

ウォーターフォールモデル / Waterfall Model

ウォーターフォールモデルとは、要件定義・設計・プログラミング・テストという各工程を、前の工程が完全に終わってから次に進むという一方通行の流れで進めていく開発手法です。水が高いところから低いところへと一方向に流れる「滝（ウォーターフォール）」の様子に見立てて、この名前がつけられました。最大のメリットはスケジュールや工程の全体計画が立てやすいことです。各工程の区切りが明確で順番に進むため、いつ何が完了するかを予測しやすく、全体のスケジュール管理がしやすいという特徴があります。一方、デメリットは後から変更や修正が必要になったときの対応コストが非常に大きい点です。滝が上流に逆流しないのと同様に、一度完了した工程に戻ることを前提としていないため、仕様変更や不具合が後から発覚した場合には、該当の工程まで全面的にやり直す必要が生じます。

The waterfall model is a development approach in which the stages of requirements definition, design, programming, and testing are each completed fully before moving on to the next — a strictly one-directional flow. The name evokes the image of water flowing in one direction from high to low, like a “waterfall.” Its greatest advantage is that it is easy to draw up an overall schedule and project plan. Because each stage has a clear boundary and the project proceeds in order, it is straightforward to predict when each stage will finish and to manage the overall timeline. The main disadvantage, however, is that the cost of making changes or corrections after the fact is very high. Just as a waterfall cannot flow back upstream, the model does not assume returning to a completed stage — so if a specification change or defect is discovered late in the process, everything from that stage onward must be redone.

アジャイル開発 / Agile Development

アジャイル開発とは、短いサイクルで開発とリリースを何度も繰り返しながら、ビジネス環境の変化やユーザーニーズの変化に素早く対応していく開発手法です。「Agile（アジャイル）」は英語で「機敏な・素早い」という意味を持ちます。アジャイル開発が必要とされる背景には、市場や顧客ニーズの変化スピードが急速に速まっていることがあります。ウォーターフォールモデルのように「すべての工程が完了して初めて製品が完成する」という手法では、開発が完了したときには市場のニーズが変わってしまっているリスクがあります。アジャイル開発ではまず動く製品を素早く市場に出し、実際のユーザーの反応から学びながら内容を改善してリリースを重ねるサイクルを回します。ウォーターフォールモデルとの違いを整理すると、「事前の計画の緻密さ」「得意なプロジェクト規模」「仕様変更への対応力」の3点が主な比較ポイントです。

Agile development is an approach that repeats short cycles of development and release, responding quickly to changes in the business environment and user needs. “Agile” means quick and nimble in English. The need for agile development arose from the dramatically accelerating pace of change in markets and customer needs. Methods like the waterfall model — where a product is only complete after all stages are finished — risk delivering something the market no longer needs by the time development is done. Agile development instead gets a working product to market as quickly as possible, then runs repeated cycles of learning from real user feedback and releasing an improved version. The three main comparison points between agile development and the waterfall model are: the degree of detailed upfront planning, the project scale each handles best, and how well each copes with mid-project specification changes.

DevOps

DevOpsとは、開発チーム（Development）と運用チーム（Operations）が壁を作らずに緊密に連携し、自動化ツールなどを積極的に活用することで、新機能の投入やシステム更新を素早く継続的に実現しようとする取り組みです。開発チームは「より良いシステムを速く届けること」を目指し、運用チームは「動いているシステムを安定させること」を目指します。この2つの目標は方向性が異なるため、従来は対立が生じやすい関係でした。DevOpsは、この対立をツールや組織文化の工夫によって乗り越え、最終的にユーザーへ届ける価値を高めることを目指します。なお、DevOpsには「必ずこうしなければならない」という厳格な定義はなく、開発と運用が協力して改善を進める文化・実践の総称として理解するのが適切です。

DevOps is a set of practices in which development teams (Development) and operations teams (Operations) break down silos and work in close collaboration, actively using automation tools and similar means to deliver new features and system updates quickly and continuously. Development teams aim to deliver better systems faster, while operations teams aim to keep running systems stable — goals that have traditionally pointed in different directions, making these teams prone to conflict. DevOps seeks to overcome that conflict through tools and organizational culture, ultimately with the goal of delivering greater value to users. Note that DevOps has no rigid definition of “this is exactly how it must be done” — it is best understood as an umbrella term for the culture and practices through which development and operations work together toward continuous improvement.

XP（エクストリームプログラミング）の3つのプラクティス / Three XP (eXtreme Programming) Practices

XP（eXtreme Programming）はアジャイル開発の代表的な手法の一つで、複数のプラクティス（実践項目）が定義されています。このうち試験に出題される3つのプラクティスを紹介します。テスト駆動開発（Test Driven Development）とは、プログラムを書く前に先にテストを作成し、そのテストに合格するようにプログラムを実装していく開発手法です。通常の手順とは逆の順序をとることで、プログラムの目的が最初から明確になり、不具合の少ない状態で開発を進められます。ペアプログラミングとは、プログラマが2名1組で1台のコンピュータを共有し、一方がコードを書き、もう一方がリアルタイムで内容を確認・指摘しながら開発を進める手法です。リファクタリング（Refactoring）とは、ソフトウェアが外部に対して提供する動作や機能を一切変えないまま、内部のコード構造を整理・改善することです。ユーザーから見た動作は変わらないのに、コードの読みやすさや保守性が向上するという特徴があります。

XP (eXtreme Programming) is one of the leading approaches within agile development, defined by a set of practices. Here are the three practices that appear on the exam. Test-Driven Development (TDD) creates the test first — before writing the program — and then implements the program so that it passes that test. By reversing the normal order, the purpose of the program is clear from the start, and development proceeds with fewer defects. Pair programming has two programmers sharing one computer: one writes the code while the other reviews the content in real time and provides immediate feedback. Refactoring means reorganizing and improving the internal code structure without changing anything about the behavior or functions the software provides to users. The behavior seen from the outside remains unchanged, but the code becomes easier to read and maintain.

ソフトウェアの見積り / Software Cost Estimation

システム開発には費用がかかります。その費用はどのように算出されるのでしょうか。試験では開発費を見積もる方法として「積み上げ法」「ファンクションポイント法」「類推見積法」の3つがよく出題されます。それぞれの名前と特徴をしっかり区別できるようにしておきましょう。

System development involves cost — but how is that cost calculated? The exam frequently tests three estimation methods: the bottom-up method, the function point method, and the analogical estimation method (analogy-based estimation). Make sure you can clearly distinguish the name and characteristics of each.

積み上げ法とは、プロジェクトを構成する個々の作業をすべて洗い出し、各作業にかかる人員・時間（工数）を一つひとつ積み上げて合算する見積り方法です。細かく分解して積み上げていくため精度が高い一方、全作業の洗い出しに多くの時間と手間がかかります。ファンクションポイント法とは、開発対象のシステムが持つ機能の数と複雑さを定量的に計測し、その値に係数を掛けることで開発規模とコストを算出する方法です。「機能（ファンクション）」に「点数（ポイント）」をつけて計量することが名前の由来で、ISOにも規格化されている最も普及した見積り手法です。客観的な説明がしやすい一方、評価者によって結果にばらつきが出ることがあります。類推見積法とは、過去に完了した類似プロジェクトの実績データをもとに、今回の開発コストをざっくりと算出する方法です。比較的短時間で見積りが出せますが、参照できる類似事例がない場合には適用できません。

The bottom-up method identifies every individual task that makes up the project, estimates the people and time (workload) required for each task one by one, and sums them all up. Because it breaks work down in fine detail, it is highly accurate — but identifying every task takes considerable time and effort. The function point method quantitatively measures the number and complexity of functions in the system being developed, then multiplies that figure by a coefficient to calculate the development scale and cost. The name comes from assigning “points” to “functions” — it is standardized by ISO and is the most widely used estimation method. While it lends itself to objective explanation, results can vary depending on who does the evaluation. The analogical estimation method uses performance data from similar projects completed in the past to produce a rough estimate of the current development cost. It yields estimates relatively quickly, but cannot be applied when there are no comparable past cases to reference.

まとめ / Summary

ITパスポート試験における開発技術の重要ポイントをまとめます。

Here is a summary of the key points on development technology for the IT Passport exam.

1. システムとソフトウェアの違い　システム＝ハードウェア＋ソフトウェア。ソフトウェアはシステムの構成要素の一つ。試験ではこの2つを明確に使い分ける
   System vs. software — System = hardware + software. Software is one component of a system. The exam uses these two terms with clear distinction
2. SLCP（ソフトウェアライフサイクルプロセス）　企画→要件定義→開発→運用→保守の5段階。試験では開発・運用・保守の3段階が重点
   SLCP (Software Life Cycle Process) — Five stages: planning → requirements definition → development → operation → maintenance. The exam focuses on the three stages of development, operation, and maintenance
3. システム設計の4工程　①システム方式設計（ハード・ソフト・手作業への割り振り）→②ソフトウェア要件定義→③ソフトウェア方式設計（プログラム単位に分割）→④ソフトウェア詳細設計（コーディング単位に分割）。「システム」と「ソフトウェア」の使い分けに注意
   Four system design sub-processes — ① System architecture design (assigning to hardware/software/manual) → ② Software requirements definition → ③ Software architecture design (dividing to program units) → ④ Software detailed design (dividing to coding units). Pay attention to the distinction between “system” and “software” in the names
4. テストの4種類（V字モデル）　単体テスト（個別プログラム・ホワイトボックス・開発者）→結合テスト（プログラム間インタフェース・ブラックボックス・開発者）→システムテスト（システム要件・開発者）→運用テスト（業務要件・ユーザー）
   Four test types (V-model) — Unit testing (individual programs, white-box, developer) → Integration testing (interfaces between programs, black-box, developer) → System testing (system requirements, developer) → Operation testing (business requirements, user)
5. ウォーターフォールvs.アジャイル　ウォーターフォール＝一方通行の順次進行（計画立案が容易・修正コストが大きい・大規模向き）。アジャイル＝短サイクルの開発とリリースの繰り返し（計画変更が前提・仕様変更に強い・小規模向き）
   Waterfall vs. agile — Waterfall = strict one-directional sequential flow (easy to plan, high revision cost, suited to large projects). Agile = repeated short development and release cycles (plan changes expected, flexible to specification changes, suited to small projects)
6. DevOps　開発チームと運用チームが壁を越えて協力し、自動化ツール等を活用して機能投入・更新を継続的・迅速に実現する取り組み。アジャイル開発やウォーターフォールモデルとは別の概念
   DevOps — A set of practices in which development and operations teams collaborate across traditional boundaries, using automation tools to deliver and update features continuously and rapidly. It is a distinct concept from agile development and the waterfall model
7. 見積り3手法　積み上げ法（作業ごとに工数を積算・精度高・時間がかかる）・ファンクションポイント法（機能の数と複雑さを計量・最も普及）・類推見積法（過去の類似事例を参照・迅速・事例なしでは使用不可）
   Three estimation methods — Bottom-up (accumulating workload per task, high accuracy, time-consuming); function point method (measuring function count and complexity, most widely used); analogical estimation (referencing past similar projects, quick, not usable without comparable cases)

練習問題　開発技術の理解を確認しよう / Practice Questions: Test Your Understanding

ここまでの内容を試験形式で確認しましょう。解答と解説は各問題の直下に記載しています。

Let’s test what you’ve learned with some exam-style practice questions. The answer and explanation for each question appear directly below it.

本練習問題3問は、令和6年度 ITパスポート試験 公開過去問題（開発技術分野）より引用しています（問題1＝問47、問題2＝問49、問題3＝問7）。

All three practice questions are taken from the IT Passport Examination — Official Past Questions, Reiwa 6 (2024), Development Technology Domain (Question 1 = Item 47, Question 2 = Item 49, Question 3 = Item 7).

問題1 / Question 1

ソフトウェアの開発におけるDevOpsに関する記述として、最も適切なものはどれか。

Which of the following is the most accurate description of DevOps in software development?

1. 開発側が重要な機能のプロトタイプを作成し、顧客とともにその性能を実測して妥当性を評価する。
   The development team creates a prototype of key features and, together with the customer, measures its performance and evaluates its suitability.
2. 開発側では、開発の各工程でその工程の完了を判断した上で次工程に進み、総合テストで利用者が参加して操作性の確認を実施した後に運用側に引き渡す。
   On the development side, each stage is completed before moving to the next, and after the final integration test — in which users participate to confirm operability — the system is handed over to the operations side.
3. 開発側と運用側が密接に連携し、自動化ツールなどを活用して機能の導入や更新などを迅速に進める。
   The development side and the operations side work in close collaboration, using automation tools and similar means to introduce and update features rapidly.
4. システム開発において、機能の拡張を図るために、固定された短期間のサイクルを繰り返しながらプログラムを順次追加する。
   In system development, programs are added incrementally through repeated fixed short-term cycles in order to expand functionality.

解答：3 / Answer: 3

DevOpsとは、開発チームと運用チームが壁を作らず密接に連携し、自動化ツール等を活用しながら機能の導入や更新を迅速に継続的に進める取り組みです。選択肢3がこの定義に正確に対応しています。選択肢1はプロトタイプ開発の説明で、顧客とともに試作品の性能を検証する手法を指します。選択肢2は各工程を順番に進めるウォーターフォールモデルの説明です。選択肢4は「固定された短いサイクルを繰り返す」という点からアジャイル開発（スクラムなど）の説明にあたります。

DevOps is the practice of development and operations teams collaborating closely across traditional boundaries, using automation tools and similar means to deliver and update features rapidly and continuously. Option 3 accurately matches this definition. Option 1 describes prototype development — a method of validating a prototype’s performance together with the customer. Option 2 describes the waterfall model, in which each stage is completed in sequence before moving to the next. Option 4 — with its reference to “repeated fixed short-term cycles” — describes agile development (such as Scrum).

問題2 / Question 2

ソフトウェア開発プロジェクトにおける、コストの見積り手法には、積み上げ法、ファンクションポイント法、類推見積法などがある。見積りで使用した手法とその特徴に関する記述a〜cの適切な組合せはどれか。

Software development projects use several cost estimation methods, including the bottom-up method, the function point method, and the analogical estimation method. Which combination correctly matches estimation methods a–c with their descriptions below?

a　プロジェクトに必要な個々の作業を洗い出し、その作業ごとの工数を見積もって集計する。
Identify every individual task required for the project, estimate the workload for each task, and total them.

b　プロジェクトの初期段階で使用する手法で、過去の事例を活用してコストを見積もる。
A method used in the early stages of a project that estimates cost by drawing on past case studies.

c　データ入出力や機能に着目して、ソフトウェア規模を見積もり、係数を乗ずるなどしてコストを見積もる。
Focuses on data inputs/outputs and functions to measure software scale, then applies coefficients to estimate cost.

	積み上げ法 Bottom-up	ファンクションポイント法 Function point	類推見積法 Analogical
ア	a	c	b
イ	b	a	c
ウ	c	a	b
エ	c	b	a

解答：ア / Answer: ア

3つの見積り手法の内容を確認します。aの「個々の作業を洗い出し工数を積み上げて合算する」は積み上げ法の特徴です。bの「プロジェクト初期段階で過去の事例を参照してコストを算出する」は類推見積法の特徴です。cの「データ入出力や機能の規模を計量して係数を掛けコストを算出する」はファンクションポイント法の特徴です。したがって、積み上げ法＝a・ファンクションポイント法＝c・類推見積法＝bとなる「ア」が正解です。

Let’s confirm each method against the descriptions. Description a — “identify every task and accumulate workload estimates, then total them” — matches the bottom-up method. Description b — “used in the early project stages, drawing on past case studies to calculate cost” — matches the analogical estimation method. Description c — “measures the scale of data inputs/outputs and functions, then multiplies by a coefficient to calculate cost” — matches the function point method. Therefore, the correct combination — bottom-up = a, function point = c, analogical = b — is option ア.

問題3 / Question 3

システム開発の上流工程において、業務プロセスのモデリングを行う目的として、最も適切なものはどれか。

In the upstream processes of system development, which of the following is the most appropriate purpose of modeling business processes?

1. 業務プロセスで取り扱う大量のデータを、統計的手法やAI手法などを用いて分析し、データ間の相関関係や隠れたパターンや傾向などを見いだすため
   To analyze large volumes of data handled in business processes using statistical methods and AI techniques, and to discover correlations, hidden patterns, and trends within that data
2. 業務プロセスを可視化することによって、適切なシステム設計のベースとなる情報を整備し、関係者間で解釈を共有できるようにするため
   To visualize business processes so that the information needed as a basis for appropriate system design is organized, and so that a shared understanding can be established among all stakeholders
3. 各部門の従業員がもつ業務に関する知識・経験やノウハウを社内全体で共有し、創造的なアイディアを生み出すため
   To share the knowledge, experience, and know-how that employees in each department have about their work across the entire organization, and to generate creative ideas
4. プロジェクトに必要な要員を集結し、チームとして組織化して、プロジェクトの目的の達成に向けて一致団結させるため
   To bring together the personnel needed for the project, organize them as a team, and unite them toward achieving the project’s goals

解答：2 / Answer: 2

システム開発の上流工程（要件定義）では、DFD（データフロー図）などの図法を活用して業務の流れを可視化し、発注者と開発者がシステムの設計に必要な情報を共有します。選択肢2の「業務プロセスを可視化することによって、適切なシステム設計のベースとなる情報を整備し、関係者間で解釈を共有できるようにするため」がこの目的に正確に対応しています。選択肢1は大量データから規則性を発見するデータマイニングの目的です。選択肢3は組織内の知識や経験を蓄積・活用するナレッジマネジメントの目的です。選択肢4はプロジェクト開始時にチームの目標意識を統一するキックオフミーティングの目的です。

In the upstream process of system development (requirements definition), techniques such as DFDs (Data Flow Diagrams) are used to visualize business workflows, allowing the client and development team to share the information needed for system design. Option 2 — “to visualize business processes so that the information needed as a basis for appropriate system design is organized, and so that a shared understanding can be established among all stakeholders” — accurately matches this purpose. Option 1 describes the purpose of data mining — discovering patterns and regularities from large volumes of data. Option 3 describes the purpose of knowledge management — accumulating and leveraging the knowledge and experience within an organization. Option 4 describes the purpose of a kickoff meeting — unifying the team’s sense of purpose and goals at the start of a project.