Kotlinの案件で声がかかっても、真っさらな新規プロジェクトが待っているとは限りません。多くの現場でまず向き合うのは、長く動いてきたJavaの資産です。全部を書き直す話ではなく、どこからどこまでを引き受けるかという線引きが最初の仕事になります。この記事では、その線引きをどう決め、どう書面に残すかを整理します。

1. 全部書き直す形では来ない

書き直しよりも、資産をそのまま動かす前提が強い

Kotlinの案件が来ると聞くと、真新しい基盤を一から組む仕事を想像しがちです。ですが、利用する側の企業の半数程度は、いまも長く使ってきたレガシーシステムを抱えています¹。すでに動いているJavaの資産が土台にあり、Kotlinはその上に少しずつ足していく形で使われます。

この前提を知らずに現場に入ると、書き直しを期待して肩透かしを受けます。実際に求められるのは、既存の挙動を壊さずに、新しく書く部分と手を付けない部分を見極める力です。真新しさよりも、資産との付き合い方のほうが評価される場面が多くなります。

打診を受けた段階で、既存のJava資産がどこまで動いているかを尋ねておくと、後の認識違いを防げます。案件情報に「新規構築」と書かれていても、内実は同居からの置き換えであることが少なくありません。

開発の進め方も一段ずつ承認を取る形が中心

開発の進め方にも同じ前提が表れます。依然としてウォーターフォール型の手法が主流です²。要件を固めてから設計し、設計を固めてから実装に移るという段階が、Kotlinの案件でも踏襲されます。

アジャイルの経験だけを頼りに臨むと、承認の手続きの多さに戸惑うかもしれません。ここで効くのは、段階ごとに何を確定させ、何を次の段階に持ち越すかを整理する姿勢です。進め方を疑うよりも、決まった段階の中で自分の担当範囲を明確にするほうが、話が早く進みます。

段階を踏む進め方は窮屈に感じられるかもしれませんが、確定した範囲が後から覆りにくいという利点もあります。同居の前提と段階的な進め方は、セットで理解しておくと打ち合わせの見通しが立ちやすくなります。

この2つの調査結果が示すのは、Kotlinの案件が「新しい技術を試す場」ではなく「既存の仕組みと折り合いをつける場」だということです。同居の前提を先に受け入れておくと、初回の打ち合わせで担当範囲を尋ねる質問も具体的になります。

図の作成：Remogu編集部。同居の範囲のイメージを整理したもので、比率を表す統計データではありません

2. 同居させる範囲をどう決めるか

境界を引く材料が現場にないことが多い

同居させる範囲を決めようにも、材料が現場に用意されていないことがあります。構成管理ツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまります³。誰がどの部品を管理しているかという記録自体が薄いということです。

この状態で置き換える範囲を決めるよう求められても、判断のしようがありません。まず自分の目で、今動いているものの単位を確認する作業から始まります。用意された地図を読むのではなく、地図を自分で描く仕事だと捉えると、次の一歩が見えてきます。

この確認作業は一人で抱え込む必要はありません。クライアントの担当者に同席してもらい、画面を見ながら一緒に洗い出すほうが、記憶違いや見落としを防げます。最初の数時間を確認作業に充てる価値は十分にあります。

確認の対象は、コードそのものだけではありません。ビルドの設定やデプロイの手順書、過去の障害対応の記録も、範囲を決める手がかりになります。散らばった情報を一度に集めるだけでも、同居の輪郭がつかめてきます。

比較で範囲の型を先に知っておく

区切り方にはいくつかの型があります。パッケージやディレクトリの境界で分ける型、画面や業務処理のまとまりで分ける型、そしてどこからどこを呼んでいるかという経路で分ける型です。同じKotlinの案件でも、依存関係の複雑さによって向いている型が変わります。次の表に、それぞれの型が何を基準にしていて、どんな場面に向いているかを整理しました。

決め方	何を基準にするか	向いている場面
モジュール単位で区切る型	パッケージやディレクトリの境界	呼び出し関係が薄く、独立して動く部分が多い場合
機能単位で区切る型	画面や業務処理のまとまり	利用者から見える変化を優先する場合
呼び出し関係で区切る型	どこからどこを呼んでいるかという経路	依存関係が複雑で、影響範囲を先に知りたい場合

どの型を選ぶかは現場の依存関係によって変わります。呼び出しの経路が込み入っている案件では、経路で区切る型のほうが後戻りが少なくなります。型を先に知っておくと、打ち合わせの場で自分から区切り方を提案しやすくなります。

型を組み合わせて使う場面もあります。まず機能単位で大まかに区切り、次に呼び出し関係で細部を調整するといった二段階の進め方です。最初から完璧な線引きを求めず、打ち合わせを重ねながら精度を上げていく姿勢が実務的です。

3. 部品の一覧が無いという前提

SBOMも運用の方針もまだ整っていない

部品の一覧に関しても、期待していい水準は高くありません。SBOM(ソフトウェア部品表)を導入している企業は1割未満です⁹。使っているライブラリや外部の部品を一覧にした資料が、そもそも存在しない案件のほうが多いということです。

方針の面でも同じ傾向があります。OSSポリシーやOSPO(オープンソースを扱う専門の組織)は未整備の状態です¹⁰。誰がどの部品を許可し、誰が更新の責任を持つかという取り決めが、文書として残っていません。

導入率の低さは、担当者の怠慢ではなく、優先順位の結果であることが多いといえます。事業の成長を優先してきた結果、管理の仕組みが後回しになっている現場だと捉えると、責める姿勢ではなく補う姿勢で臨めます。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）をもとに作成

無い前提で確認する項目を並べる

一覧が届くのを待つよりも、無い前提で自分から作るほうが早く動けます。とはいえ、一覧が有る場合と無い場合とでは、最初に確認する項目も、確認する相手も変わります。次の表に、一覧が有る場合・無い場合・古い場合のそれぞれで、最初に何を、誰に確認するかを整理しました。

一覧の状態	最初に確認する項目	確認する相手
一覧がある場合	記載されている部品の版が、今も動いているものと一致しているか	管理を担当している窓口
一覧が無い場合	設定ファイルやビルドの定義から、実際に使われている部品を洗い出すこと	直近で保守を担当していた担当者
一覧が古い場合	更新されていない期間と、その間に入った変更の量	クライアントの窓口とコードの履歴

一覧の有無で確認の起点は変わりますが、最終的にたどり着く先は同じです。今動いているものを自分の目で確かめてから、同居させる範囲を決めます。想定と違っても慌てず、確認した内容をその都度書き留めておくと、後の線引きがぶれません。

確認作業には時間がかかりますが、この工程を飛ばすと、後になって想定外の部品が見つかり、スケジュール全体が崩れる原因になります。最初にまとまった時間を確保しておくほうが、結果として効率よく進みます。

4. 外部のサービスとの境目

外部サービスは既に広く組み込まれている

同居の範囲を考えるとき、Java資産だけでなく外部のサービスとの境目も避けて通れません。外部のサービスや製品は、一部での利用を含めて6割強の企業が活用しています⁴。Kotlinで書く部分の外側に、すでに他社の仕組みが組み込まれているケースが多いということです。

活用されている外部サービスの種類は案件によってさまざまで、認証の仕組みや通知、決済に関わるものまで多岐にわたります。どのサービスがどの機能を担っているかを最初に一覧化しておくと、後の境目の確認がスムーズになります。

外部のサービスに頼っている分、安心かといえばそうではありません。外部サービスの保守や運用に不安を抱える企業は多い状態です⁵。中身が見えない部分をどこまで自分の担当に含めるかは、契約の前に詰めておく必要があります。

境目の不安をそのままにしない

境目をあいまいにしたまま作業を始めると、外部サービス側の不具合まで担当範囲に含められてしまう場面が出てきます。ここは相手の考え方を尋ねるより先に、契約の文言で担当範囲を確かめておくと、後のやり取りがはっきりします。

境目を確かめる質問は難しいものでなくて構いません。「このサービスの障害が起きたとき、復旧の連絡はどちら向けに来るか」を尋ねるだけで、担当範囲の輪郭がはっきりします。同居の作業を始める前に、この一問を通しておくと安心材料になります。

境目の確認は一度で終わるものではありません。作業が進むにつれて新しい連携が見つかることもあるため、気づいた時点でその都度、担当範囲に含まれるかを確かめる習慣をつけておきます。

外部サービスの契約や利用条件はクライアントの側が結んでいることが多く、内容を細部まで把握していない担当者もいます。分からない点があれば、その場で分かる範囲を確認し、残りは持ち帰って調べてもらう形で構いません。

5. 更新の判断は避けられない

脆弱性への対応は先送りできない

同居させたJavaの資産を放置できない理由もあります。システムの脆弱性を悪用した攻撃は、情報セキュリティ10大脅威の4位に挙げられています⁶。新しく書く部分だけを見ていても、古い部分に開いた穴は塞がりません。

対応を先延ばしにするよりも、上位に挙げられ続けているという事実そのものを優先度の合図として使うほうが、更新の判断がしやすくなります。同居の作業を始めた時点で、更新の計画も同時に持っておく必要があります。

更新の対象になりやすいのは、外部との接点になっている部分です。同居の範囲を線引きする際に、更新が必要になりそうな箇所をあらかじめ把握しておくと、後の対応が早くなります。

リスク管理の整備は道半ば

組織側の備えも一様ではありません。ITのリスク管理と業務継続計画については、全体の5〜6割程度の企業が整備しています⁷。裏を返せば、4割から5割の現場では、更新を止めたときの手順が固まっていないということです。

整備の有無によって、更新の進め方は大きく変わります。リスク管理の体制が整っている現場では、承認のフローに沿って進めれば足ります。整備が薄い現場や、手順そのものが無い現場では、確認する相手や連絡先を自分で先に特定しておきます。次の表に、現場の状態ごとに、更新前に確かめる内容と進め方を整理しました。

現場の状態	更新前に確かめる内容	進め方
リスク管理が整備されている現場	更新の承認フローと影響範囲の確認手順	手順に沿って申請し、承認を待って進めます
整備が薄い現場	誰が最終的に更新を判断するかという窓口	窓口を先に特定してから作業に入ります
手順が無い現場	更新後に問題が起きたときの連絡先	連絡先を書面で確認してから着手します

整備の水準を確かめずに更新へ進むと、承認を待つ場面で先に手を動かしてしまい、あとで差し戻される場合があります。表の内容を打ち合わせの最初の質問に使うと、無駄な手戻りを減らせます。

更新の判断を先送りにしないためには、着手前の確認だけでなく、更新後に誰へ結果を報告するかも決めておくと、体制が薄い現場でも作業の区切りがはっきりします。

図の作成：Remogu編集部。一覧の有無によって更新判断までの手順が変わることを整理したもので、日数を示す数値ではありません

6. 決める人がいない現場で起きること

責任者が定まっていない現場は珍しくない

同居の範囲や更新の判断を誰に確認すればいいのか、現場に着いてから迷うことがあります。意思決定を担う責任者を設置していない企業は、約半数に上ります⁸。誰かが決めてくれるはずだと待っていても、決める人自体がいない場合があるということです。

責任者が不在の現場では、判断が複数の担当者の間をたらい回しにされることもあります。誰に聞いても「上に確認します」で止まる状況は珍しくなく、時間だけが過ぎていく点に注意が必要です。

外部サービスの保守や運用に不安を抱える企業が多いという状態も⁵、責任者が定まっていない現場では長引きやすくなります。不安の種があっても、それを引き取って判断する立場の人が見当たらないためです。

決める人が見えないときの動き方

決める人がいないとき、自分から質問を止めてしまうと状況は動きません。担当者ごとに「ここまでは判断できる」という範囲を確かめ、判断できない部分は上位の誰に持ち込むのかを聞いておきます。待つよりも、判断できる範囲を先に把握しておくほうが、作業が止まりにくくなります。

責任の所在があいまいな現場ほど、自分の作業記録が頼りになります。何を、いつ、誰に確認して進めたかを残しておくと、後から判断が食い違ったときの拠り所になります。

記録を残す習慣は、同居の案件に限らず次の案件でも役立ちます。担当した範囲と確認した相手を積み重ねておくと、自分の実績を語るときの具体的な材料にもなります。

決める人がいない現場は不便に見えますが、見方を変えれば、自分の提案が通りやすい現場でもあります。区切り方や進め方を先に示せる担当者は、こうした現場ほど重宝されます。

7. 線引きを書面で確かめる順番

確認の順番を決めておく

同居させる範囲や更新の判断は、口頭の合意だけでは後から食い違いが生まれます。構成管理ツールを導入している企業が、利用する側で約3割、作る側で約4割にとどまる状況では³、担当範囲の記録を相手任せにできません。自分から書面に残す動きが要ります。

確かめる順番は、まず今動いているものの単位を洗い出し、次に自分が触れる範囲を線で囲み、最後にリスク管理や業務継続の体制が整っているかを確認します⁷。体制が薄い現場ほど、この最後の確認が漏れやすくなります。

書面に残す形式は複雑でなくて構いません。担当する部品の名前、触れない部分、更新の判断を仰ぐ窓口の3点を、メールや契約書の別紙に一行ずつ書き添えるだけでも、後から見返せる記録になります。

書面に残す作業を手間に感じるかもしれませんが、担当範囲が明確になっていることは、契約を続ける場面でも役立ちます。次にどこまで任せられるかを、クライアントの側も判断しやすくなるためです。

この3点を最初の打ち合わせで確認しておくと、同居の作業が進むほど生まれやすい行き違いを減らせます。次によくある疑問をまとめました。

図の作成：Remogu編集部。同居の範囲を書面に残すまでの確認順序を整理したもので、所要日数を示す数値ではありません

同居の範囲は誰が最終的に決めるのですか

多くの現場では、責任者が明確でないまま作業が始まります⁸。決める人が見当たらないときは、判断できる範囲を担当者ごとに確認し、判断できない部分は誰に持ち込むかを先に決めておくと、範囲の宙ぶらりんを防げます。決める人を探している間も、判断が要らない範囲から着手しておくと、待ち時間を無駄にせずに済みます。

部品の一覧が無い案件では何から手を付ければいいですか

SBOMを導入している企業は1割未満です⁹。一覧が無い前提に立ち、ビルドの定義や設定ファイルから、実際に使われている部品を自分で洗い出す作業を、最初の工程に組み込みます。洗い出した内容は簡単な一覧にまとめておくと、後工程の確認がしやすくなります。

外部サービスの不具合まで担当に含まれることはありますか

外部サービスの保守や運用に不安を抱える企業は多く⁵、境目があいまいなまま作業が始まる案件もあります。契約の文言で担当範囲を確かめておけば、外部サービス側の不具合まで背負う事態を避けやすくなります。境目に関するやり取りは、メールなど文字に残る形で行っておくと、後から確認するときに役立ちます。

同居させる範囲を自分の言葉で書き出せれば、その案件で担当した仕事は、次の案件でも語れる実績になります。次に目にする案件情報では、どこまでを自分の担当として引き受けられそうでしょうか。

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

出典・参考情報

＊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「情報セキュリティ10大脅威 2026」直せる穴（2026年1月・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月確認）