CakePHPを使ったシステムの案件は、新しく何かを作るというより、これまで動いてきたものを止めずに保ち続ける仕事が中心です。長く使われてきたシステムほど、いま何がどう組まれているかを示す資料は薄くなりがちで、直した後に壊れていないかを確かめる仕組みも整っていないことがあります。情報処理推進機構(IPA)の調査からは、開発の進め方や部品管理の実情がいくつも見えてきます。この記事では、案件を引き受ける前に確かめておきたい観点を、公的な調査をもとに整理します。

1. 多いのは動かし続けるための改修

新しく作るより、動かし続ける仕事が中心です

CakePHPの案件情報を見比べると、新規構築よりも改修や保守を求める内容が目立ちます。

背景にあるのは、システムを長く使い続ける事業者が多いという事情です。情報処理推進機構(IPA)の調査によれば、利用する側の企業の半数程度が、いまもレガシーシステムを抱えています¹。

つまり案件の多くは、すでにある仕組みを壊さずに直す仕事だと捉えたほうが、実情に近づきます。

開発の進め方も、これまでの延長線上にあります

新しい開発手法を前提に案件を想像すると、実際の現場との違いを感じることがあります。

開発の手法はいまもウォーターフォール型が主流です¹⁰。最初に全体を決めてから順番に進める、これまで通りの進め方が続いています。

だからこそ、案件を引き受ける前には、いま何がどう組まれているかを示す資料が残っているかを見ておきたいところです。

受ける前提を、早い段階ですり合わせておきます

改修が中心という前提は、条件を協議する場面でも役に立ちます。どこまでを直す対象にして、どこからを対象外にするのかを、最初にすり合わせておくと、後になって認識の差が生まれにくくなります。

長く動いてきたシステムほど、直す範囲を決めるための材料が、依頼する側の手元にも十分に残っていないことがあります。材料が薄いことを前提に置いておくと、進め方の相談もしやすくなります。

次の章からは、その材料にあたる部品の一覧や設計書が、実際にどこまで残っているかを見ていきます。

資料が薄いことを最初から見込んでおくのと、資料があるはずだと思い込んで進めるのとでは、途中で受ける印象がまったく違います。前提をそろえておく分だけ、後の作業は落ち着いて進められます。

依頼する側も、資料の少なさを自覚していないことがあります。引き受ける側から確認の質問を投げかけることが、双方の認識をそろえる最初の一歩になります。

図の作成：Remogu編集部。引き受ける前に見ておきたい資料を整理したもので、統計データではありません

2. 部品の一覧があるかを最初に見る

使っている部品の一覧が、確認の出発点になります

改修を引き受けるとき、最初に見ておきたいのは、使っているライブラリや部品の一覧があるかどうかです。

構成管理ツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまっています²。一覧が整っていない現場も、一定の割合で存在することになります。

一覧がなければ、まず実際にソースコードを開いて、何が使われているかを洗い出す作業から始まります。

SBOMという言葉も、実情を映しています

SBOM(使っている部品の一覧を示す文書)という言葉を、案件の説明で見かけることが増えました。

SBOMを導入している企業は、1割に届いていません³。言葉が広まる速さに、現場での整備がまだ追いついていないようです。

一覧の有無で、最初の作業量が変わります

一覧があるかどうかは、改修に着手する前の準備にそのまま影響します。ある場合とない場合とで、最初に確認する内容と進み方は次のように変わります。

確認する項目	一覧がある場合	一覧が無い場合
使っている部品の種類	すぐに把握できます	実際に動かして洗い出します
古い版のまま残っている箇所	一覧を見れば分かります	ソースを一つずつ確認します
影響範囲の見積もり	短い時間でできます	調査に時間がかかります

この差は、引き受けた直後の作業量そのものに関わってくる部分です。

一覧が無い状態で改修を頼まれることは、珍しいことではありません。むしろ、それを前提にした進め方を用意しておいたほうが、実際の案件には合います。

洗い出しにかかる時間を、最初から作業の一部として見込んでおくと、後になって予定が崩れる場面を減らせます。割合として見ると、次のようになります。

数字だけを見ると心細く感じるかもしれませんが、同じ状況にある現場が一定の割合で存在するということでもあります。一覧を整える作業自体が、案件の一部として評価される場面も増えています。

一覧を作る作業と、機能を直す作業とでは、求められる集中の種類が違います。両方を同じ調子でこなそうとすると、思った以上に疲れが残ります。

出典：情報処理推進機構(IPA)「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）を基に作成

図の作成：Remogu編集部。一覧の有無によって作業の手順がどう変わるかを整理したもので、統計データではありません

3. 方針が決まっていない領域

オープンソースの使い方に、決まった基準がないことがあります

改修の中では、外部のオープンソースを新たに組み込む場面も出てきます。

オープンソースの使用方針や、それを管理する専任の窓口(OSPO)は整っていません⁴。使ってよい範囲を、その都度判断する現場が多いことになります。

方針が無い領域ほど、引き受ける側の判断に委ねられる部分が増えます。

判断を任される場面が多いことは、悪いことばかりではありません。経験を重ねてきた側にとっては、自分の判断が反映されやすい領域だとも言えます。

判断の根拠を都度説明できるようにしておくと、依頼する側との協議もスムーズになります。基準が無い領域ほど、言葉での説明が頼りになります。

組み込むオープンソースを選ぶときは、更新の頻度や利用者の広がりも見ておきたい点です。判断の根拠を残しておけば、後から見直すときにも役立ちます。

技術情報の集め方も、担当者ごとに違います

新しい技術情報をどこから集めるかも、統一されていないことが多いです。

技術情報の収集は体系的な仕組みを持たず、個人に任されている企業が多いです⁸。前任の担当者しか知らない事情が、案件の随所に残っています。

集め方が統一されていない現場では、資料を読むだけでなく、担当者に直接たずねる場面も出てきます。誰に何を確認できるかを、早めに把握しておきたいところです。

方針の有無で、引き継ぎの手間が変わります

方針が定まっている領域とそうでない領域を、あらかじめ分けて考えておくと、途中で迷う場面を減らせます。

方針が無い領域は、担当者が変わるたびに判断の基準もそろえ直すことになりがちです。引き継ぎの負担は、この積み重ねから生まれています。

逆に言えば、方針が定まっている部分を先に見つけておくだけでも、引き受けたあとに迷う範囲を絞り込めます。表で整理すると、次のようになります。

観点	方針が定まっている場合	方針が定まっていない場合
オープンソースの利用	使ってよい範囲が明確です	その都度判断が必要になります
技術情報の収集	仕組みとして共有されます	個人の経験に頼ることになります
新しく加わる担当者への引き継ぎ	資料をもとに進められます	都度の聞き取りが必要になります

方針が無い領域を早い段階で見分けておくと、後になって困る場面を減らせます。

4. 設計の意図が残っていない

なぜこの形にしたのかが、資料に残っていません

改修を進めていると、なぜこのテーブル構成にしたのか、なぜこの処理を分けたのかが分からない場面に出会います。

部品ごとに分けて作る発想や、データの持たせ方を意識した設計に取り組む企業は、いまも少ないままです⁷。設計の意図そのものが、言葉として残っていないことになります。

意図が分からないまま手を入れると、直したつもりの箇所が、別の場所に影響することもあります。

意図を推し量る手がかりは、コードの並びや命名の癖の中にも残っています。資料が薄いときほど、コードそのものを丁寧に読む時間が必要になります。

意図を読み解く作業には、コードを読み慣れているほど短い時間で見当がつきます。積み重ねてきた経験が、こうした場面でこそ生きてきます。

読み解いた意図は、自分の頭の中に留めず、コメントや簡単なメモとして残しておきます。次に触る人が同じ時間をかけずに済むようにする、小さな引き継ぎになります。

要件と設計は、いまも文書が中心です

とはいえ、まったく資料が無いわけではありません。

要件定義と設計は、いまもドキュメントを中心に行われています⁶。口頭のやり取りよりも、書かれたものをたどれる余地は残っています。

文書をどこまで読み解けるかが、改修の進めやすさを左右します。

文書とコードを、両方の側から突き合わせます

要件定義の文書と、実際に動いているコードの中身は、必ずしも一致しているとは限りません。長い年月の間に、片方だけが更新されて、もう片方が置き去りになることもあります。

文書とコードを突き合わせて確認する作業は手間がかかりますが、意図が残っていない部分を早い段階で洗い出しておくと、その後の改修が進めやすくなります。

文書だけを信じて進めるよりも、コードで実際の動きを確かめてから進めるほうが、思わぬ手戻りは少なくなります。

5. 直した後に確かめる仕組み

直した後の確認が、自動化されていないことがあります

コードを直したあと、正しく動くかをどう確かめるかも、現場によって差があります。

DevOpsやモデルベース開発は、作る側の企業を除くと取り入れているところは少ないです⁹。自動テストの仕組みが薄い現場では、確認の作業を手作業で担うことになります。

自動化されている場合とそうでない場合とでは、1件の改修にかかる手間の感じ方も変わってきます。

自動化されていない現場では、確認の手順そのものを、担当者が自分で組み立てる場面も出てきます。手順を言葉にして残しておくと、次に同じ確認をする人の助けになります。

自動テストが揃っている案件と、そうでない案件とでは、同じ規模の改修でも、かかる時間の見立てが変わってきます。見積もりの段階でこの違いを織り込んでおきます。

確認の仕組みを少しずつ整えていくことも、改修と並行して進められる仕事の一つです。次に同じ案件に関わる人のためにもなります。

外部サービスとの連携も、確認の対象になります

改修の範囲には、外部のサービスと連携している部分が含まれることもあります。

外部のサービスについても、維持や運用に不安を抱える企業は多いです⁵。連携先の状態まで含めて確認したいという声が根強いことがうかがえます。

連携先が増えるほど、確認する対象も増えます。自社の中だけで完結する改修と比べて、確認にかかる時間は長くなりやすい部分です。

連携先の一覧を最初にまとめておくだけでも、後から慌てて調べ直す場面を減らせます。小さな一覧でも、確認の起点として役に立ちます。

確認の仕組みの有無で、安心感が変わります

確認の仕組みがあるかどうかで、改修後の安心感は大きく変わります。比較すると次のようになります。

確認の仕組み	自動化されている場合	自動化されていない場合
変更後の動作確認	自動テストで検出できます	手動で確認する範囲が広くなります
反映までの時間	短くなります	その都度の作業が発生します
外部サービスとの連携確認	定期的に検証されます	問題が起きてから気づきます

この仕組みが無い場合は、確認にかかる時間を前もって見込んでおきたいところです。

6. 外部のサービスへの不安という前提

外部への依存は、不安の種にもなります

自分たちの手の届かない外部サービスに頼る部分があると、何かあったときにすぐ対応できるのかという不安が残ります。

外部のサービスについても、維持や運用に不安を抱える企業は多いです⁵。内部で作った仕組みだけでなく、外部への依存そのものが心配の対象になっています。

この不安を前提に置くと、改修の範囲をどう区切るかという判断も変わってきます。外部に任せている部分まで手を広げるのか、内部の範囲だけにとどめるのかを、最初に決めておきたいところです。

不安そのものをなくすことは難しくても、依存している範囲を明らかにするだけで、気持ちの上での負担は軽くなります。まず何にどこまで頼っているかを言葉にしてみることから始まります。

不安を無かったことにするよりも、不安の中身を具体的に言葉にするほうが、対処のしようがはっきりします。漠然とした不安のままにしておかないことが大切です。

外部サービスの状態を確認する頻度や方法も、依頼する側とあらかじめ決めておくと、後になって責任の所在があいまいになる場面を防げます。

方針が無いまま外部に頼ると、判断が担当者任せになります

オープンソースの使用方針や、それを管理する窓口(OSPO)は整っていません⁴。方針が無いまま外部の仕組みを取り込む場面は、この案件でも起こり得ます。

方針が無いことを引き受ける側から指摘するのではなく、自分なりの判断基準を持って臨む姿勢のほうが、実際の現場では役に立ちます。

判断の基準をいくつか用意しておくと、方針が定まっていない場面でも、その都度立ち止まらずに進められます。

リモートで案件に関わる場合も、この前提は変わりません。案件の90%以上がフルリモート可能です。場所が離れていても、確認の手順さえ明確なら、外部依存への不安は小さくできます。

次の章では、こうした前提をふまえたうえで、引き受ける前に確かめておきたい順番を整理します。

7. 引き受ける前に確かめる順番

資料の有無から、順番に確かめます

ここまで見てきた内容を、引き受ける前に確かめる順番として並べ直します。順番を決めておくと、条件を協議する場面でも、何を優先して聞くかで迷わずに済みます。

まず、部品の一覧があるかどうかです。構成管理ツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまっています²。無い場合は、洗い出しの作業から始まる前提で計画を立てたいところです。

次に、設計書が残っているかどうかです。要件定義と設計は、いまもドキュメントを中心に行われています⁶。文書がどこまで追えるかを、早い段階で確かめておきます。

確認の仕組みと、外部への依存も合わせて見ます

3つ目は、直した後に確かめる仕組みがあるかどうかです。自動化の有無で、改修後の作業量は大きく変わります。

4つ目は、外部サービスへの依存がどこまであるかです。依存の範囲が分かれば、不安を抱えたまま進める部分を減らせます。

この4つは、どれか1つが揃っていれば十分というものではなく、組み合わせで確認するとより実情に近づきます。1つずつ順番に確かめていく進め方が、結局は近道になります。

この4つを引き受ける前の順番として持っておくと、CakePHPの改修案件を見るときの判断がしやすくなります。

図の作成：Remogu編集部。確認する順番を整理したもので、統計データではありません

CakePHPの案件を受ける前に、最初に何を聞けばよいですか

最初に聞いておきたいのは、使っている部品の一覧が残っているかどうかです。一覧が無い場合は、洗い出しに時間がかかる前提で条件を確認しておくと安心です。あわせて、直した後に確かめる仕組みがあるかどうかも聞いておくと、作業全体の見通しが立てやすくなります。

設計書が残っていない場合はどう進めればよいですか

設計書が薄い場合でも、要件定義の文書だけは残っていることがあります。まずはその文書を手がかりに、変更が影響する範囲を絞り込みます。文書からたどれない部分は、実際のコードを読みながら少しずつ埋めていきます。

外部サービスに依存している部分がある場合、何を確認しますか

連携している外部サービスの一覧と、その状態をどう把握しているかを確認します。依存範囲を早めに洗い出しておくと、あとで慌てずに対応できます。確認の頻度や担当をどちらが持つのかも、合わせて決めておくと安心です。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月・2026年8月確認）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」構成の把握（2025年4月・2026年8月確認）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」部品の一覧（2025年4月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」方針の空白（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」不安の所在（2025年4月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」知識の持ち方（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」確認の自動化（2025年4月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月・2026年8月確認）