LASSIC Media らしくメディア
開発ツールの利用実態｜設計の理由が残らないときの対処
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- IPAの調査では、変更履歴を記録する構成管理ツールは79.6％の案件で使われ、設計支援ツールは14.0％にとどまります。
- コードの変更履歴は道具に残りやすい一方、設計の意図は前任者から聞き取るしかない案件が多くなります。
- 引き継ぎでは、道具に残る情報と人にしかない情報を分け、人にしかない情報は期限を決めて前任者に文書にしてもらいます。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
担当者が抜けたあと、コードは見つかっても、なぜその設計にしたのかが分からない。前任者に聞こうにも、もう別の案件に移っている——。開発の引き継ぎでは、こうした困りごとが起こりがちです。開発ツールの利用とは、プログラムの変更管理やテスト、設計図づくりといった専用の道具を開発の作業に取り入れ、作業の記録をその道具に残していくことを指します。
どの道具がどれくらい使われているかが分かれば、引き継ぎのときに何を道具から探し、何を人に聞くかの見当がつきます。ただし万能ではなく、道具を入れていても、必要な情報がそこに残っているとは言い切れません。本記事では、開発プロジェクトを引き継ぐ実務担当者に向けて、開発ツールの種類、利用の状況、引き継ぐ範囲の決め方、そして外部に頼むときに確認したい点を整理します。
目次
開発ツールとは
IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」は、開発プロジェクトで使われる道具を7つに分け、それぞれ使っているかどうかを集計しています。*1 7つは、構成管理ツール、プロジェクト管理ツール、デバッグ／テストツール、設計支援ツール、ドキュメント作成ツール、コードジェネレータ、CASEツールです。
構成管理ツールは、プログラムのファイルを誰がいつどう変えたかを記録する道具です。プロジェクト管理ツールは、作業の割り当てや進み具合を記録します。デバッグ／テストツールは、プログラムの誤りを見つけたり、テストを自動で実行したりするのに使います。この3つは、プログラムを作る作業と日々の進め方を支える道具です。
残りの4つは、設計や文書づくりに近い道具です。設計支援ツールは画面や処理の設計図を描く作業を、ドキュメント作成ツールは仕様書などの文書づくりを助けます。コードジェネレータは、設計の情報からプログラムを自動で作ります。CASEツール（設計工程を支援する道具）は、要件定義や設計など開発の前半の作業を支える道具です。
どれくらい使われているのか
この資料は、IPAにデータを提供した企業の開発プロジェクトを集計したもので、分析の対象は2016年度から2021年度です。表紙には、5,546件のプロジェクトのデータを分析したと記されています。*1 開発ツールの利用状況は、このうちツールごとに回答のあった案件で集計されています。
いちばん多く使われているのは構成管理ツールで、回答のあった858件のうち683件、79.6％が「有り」でした。次いでプロジェクト管理ツールが617件で69.5％、デバッグ／テストツールが293件で40.3％です。*1
反対に、設計支援ツールは96件で14.0％、ドキュメント作成ツールは92件で13.9％、コードジェネレータは92件で13.8％でした。CASEツールは11件で1.6％にとどまります。*1 使っている案件が5割を超えるのは構成管理とプロジェクト管理の2つだけで、2割に届かないのは設計や文書づくりに近い4つです。
| ツール | 有り | 無し | 未回答 |
|---|---|---|---|
| 構成管理ツール | 683件（79.6％） | 175件（20.4％） | 621件 |
| プロジェクト管理ツール | 617件（69.5％） | 271件（30.5％） | 591件 |
| デバッグ／テストツール | 293件（40.3％） | 434件（59.7％） | 752件 |
| 設計支援ツール | 96件（14.0％） | 589件（86.0％） | 794件 |
| ドキュメント作成ツール | 92件（13.9％） | 568件（86.1％） | 819件 |
| コードジェネレータ | 92件（13.8％） | 576件（86.2％） | 811件 |
| CASEツール | 11件（1.6％） | 661件（98.4％） | 807件 |
構成管理ツールとドキュメント作成ツールでは、使っている割合を比べると79.6％と13.9％で、差を計算すると65.7ポイントになります。資料は前回の2014年度から2019年度の集計と比べても、使われ方に全体としてあまり差がないとしています。*1
回答のない案件の多さ
この集計では、ツールごとに回答のあった件数が660件から888件まで違います。未回答は591件から819件あり、有無の件数と未回答の件数を足すと、どのツールも1,479件になります。*1 未回答の割合を件数から計算すると、40.0％から55.4％です。
つまり、資料のデータでは、ツールごとに4割から5割の案件で、そのツールを使っていたかどうかが記録されていません。未回答がいちばん多いのはドキュメント作成ツールの819件、いちばん少ないのはプロジェクト管理ツールの591件でした。
なぜ設計の引き継ぎで困るのか
引き継ぎで最初にするのは、前任者が残したものを探すことです。探す対象は、プログラムのコード、変更の履歴、作業の記録、設計書、仕様についての取り決めなどです。このうち道具に残っているものは、引き継いだ人が自分で調べられます。道具に残っていないものは、前任者や周りの人に聞くしかありません。
構成管理ツールとプロジェクト管理ツールは7割から8割の案件で使われているので、コードの変更履歴と作業の記録は、道具から追える場合が多くなります。一方で、設計支援ツールやドキュメント作成ツールを使っている案件は2割に届きません。なぜその設計にしたのか、仕様のどこをどう決めたのかといった情報は、担当者の記憶や個人のメモにしか残っていないことが多いと考えられます。
そのため、担当者が入れ替わるたびに、設計についてだけは人から聞き取って文書に起こし直すことになります。聞き取る対象を決めずに始めると、前任者に何度も時間をもらうことになり、その人が別の案件で忙しければ引き継ぎの作業が止まってしまいます。
引き継ぐ範囲をどう決めるのか
引き継ぎの作業は、次の4つの手順で進めると整理しやすくなります。
- 引き継ぐ情報を、道具に残っているものと、人にしか残っていないものの2つに分けて書き出す
- コードと変更履歴は構成管理ツールから調べ、設計と仕様は前任者から聞き取ると決める
- 人から聞き取る情報を、対象の機能と期限を決めて文書にする
- できあがった文書を受け取り、口頭の説明だけで終わらせない
1つ目の手順で2つに分けるのは、道具に残る情報と残らない情報では探し方が違うためです。同じ一覧に2列で書き出しておくと、どの情報を誰に聞けばよいかが見えてきます。2つ目の手順について言えば、構成管理ツールがあれば、コードをいつ誰が変えたかはそこからたどれます。
3つ目の手順では、聞き取る対象を絞ります。たとえば「受注の画面と、その裏で動く在庫を確保する処理について、来月末までに設計の考え方を文書にまとめる」のように、機能名と期限を決めておくと、前任者にかかる負担も見通せます。4つ目の手順で文書にしてもらうのは、口頭の説明だけでは、次に担当者が替わったときに同じ聞き取りを一からやり直すことになるためです。
つまずきやすい点
一つ目は、道具が入っていれば情報も残っていると考えてしまうことです。この資料が尋ねているのは道具を使っているかどうかで、どう使っているかまでは集計していません。構成管理ツールがあっても、変更の理由が書かれていなければ、設計の意図は結局人に聞くことになります。
二つ目は、どの道具を使っていたかを確かめずに作業を始めることです。引き継ぎの初日に、前任者にどの道具を何に使っていたかを尋ねて一覧にしておくと、その後の探し方を決めやすくなります。
三つ目は、聞き取りを期限を決めずに続けてしまうことです。前任者はたいてい次の仕事を抱えています。対象の機能と期限を決め、文書として受け取るところまでを1つの作業として扱うと、途中で止まりにくくなります。
外部に委託するときに確認しておきたい点
聞き取りと文書づくりは、引き継ぎの時期に一時的に作業が増える部分です。対象の機能と期限を決め、文書で受け取る形にしておけば、フリーランスを含む業務委託の専門人材にも任せやすくなります。委託する前に、どの機能の設計を、いつまでに、どんな形式の文書にまとめてもらうかを書き出しておきましょう。
一方で、1つ目と2つ目の手順、つまり引き継ぐ情報の仕分けと探し方を決める作業は、社内で行います。何を引き継ぐかは、そのシステムを今後どう使うかによって変わるためです。仕様書の引き継ぎの進め方は「レガシーシステムの仕様書を引き継ぐ手順」で、開発に外部の人材が加わる割合は「外部委託工数比率とは」で扱っています。
まとめ：開発ツールの利用で確かめておきたい3つの点
開発ツールの利用状況を踏まえて引き継ぎを進めるうえで、確かめておきたい点は3つに整理できます。第一に、引き継ぐ情報を、道具に残っているものと人にしか残っていないものに分けること。第二に、前任者がどの道具を何に使っていたかを最初に確かめること。第三に、人から聞き取る情報は、機能と期限を決めて文書で受け取ることです。この3点を踏まえておけば、「コードはあるのに、なぜこう作ったのかを誰も説明できない」という事態を避けやすくなります。設計の聞き取りや文書づくりを誰が担うかに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
開発ツールの使われ方は、以前から変わっていないのですか
大きくは変わっていません。資料は2014年度から2019年度の集計と比べて、プロジェクト管理ツールがわずかに増え、デバッグ／テストツールはわずかに減り、ほかのツールは横ばいとしています。*1
構成管理ツールを使っていれば、引き継ぎの文書は要りませんか
要ります。構成管理ツールに残るのは、主にコードの変更の記録です。なぜその変更をしたのか、設計でどんな判断をしたのかは、変更の説明欄に書かれていなければ残らないため、別に文書にしておくのがおすすめです。
引き継ぎの文書は、誰が書くのがよいですか
前任者が書くのがいちばん確実ですが、次の仕事で時間が取れないことも多くあります。その場合は、引き継ぐ側や委託先が聞き取って下書きを作り、前任者に確認してもらう分担にすると、前任者の負担を抑えられます。
この資料の数値は、自社の開発にそのまま当てはまりますか
そのままは当てはまりません。IPAにデータを提供した企業のプロジェクトを集めたもので、業界全体を代表するように選ばれたものではないためです。*1 自社でどの道具を使っているかを数え、資料の割合と比べる目安として使うとよいでしょう。
開発の引き継ぎを相談したいとき
聞き取りと文書づくりを任せる機能と期限の整理からご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：IPA「ソフトウェア開発分析データ集2022」。独立行政法人情報処理推進機構 社会基盤センター発行。分析対象（2016年度から2021年度）と、1.3.6 ツールの利用（表1-3-6の件数、図1-3-6の比率、2014年度から2019年度との比較）を参照。図と表は資料の数値をもとに作成（2026年9月確認）
- *2 参考：IPA「ソフトウェア開発分析データ集2022」本編（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。1.3.6 ツールの利用（有無の件数・未回答、集計対象データ名）を読んだ資料本体（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。年度ごとに公開されている資料の一覧（2026年9月確認）
- *4 参考：IPA「ソフトウェア開発関連調査」（https://www.ipa.go.jp/digital/software-survey/index.html）。IPAが公開している開発関連の調査の一覧（2026年9月確認）
