LASSIC Media らしくメディア
ビルディングブロック型開発とは？取組状況と使い方を解説
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- ビルディングブロック型開発は、既存のサービスや部品を組み合わせて、短期間でシステムを作る開発手法です。
- IPAの調査に答えた362社のうち、この手法に取り組んでいるのは153社、42.3％でした。
- 予定より遅れている開発では、追加する人数を決める前に、既存の部品に置き換えられる作業を探しておくと進めやすくなります。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
開発が予定より遅れていて、人を増やしたいのに候補者が見つからない。見つかっても、実際に加わってもらうまでに時間がかかる——。開発の体制を考える現場では、こうした悩みが起こりがちです。そこで検討したいのが、作る量そのものを減らす方法です。ビルディングブロック型開発とは、SaaS（インターネット経由で使うソフト）、OSS（ソースコードが公開されたソフト）、パッケージソフト、API（システム同士をつなぐ仕組み）、共通モジュール（社内で使い回すプログラム）などの既存の部品を組み合わせて、短期間で柔軟にシステムを作る開発手法です。*1
部品に置き換えられる作業があれば、その分を作る工数は要らなくなります。ただし万能ではなく、置き換えられる部品があるか、部品をつなぐ仕組みが社内に整っているかによって、使える場面は変わります。本記事では、開発の体制を考える担当者に向けて、手法の中身、IPA（情報処理推進機構）の調査に見る企業の取組状況、部品をつなぐ技術の導入状況、そして予定より遅れている開発での進め方を整理します。
目次
ビルディングブロック型開発とは
組み合わせる部品は、外部から取り入れるものと社内で用意するものに分けると整理しやすくなります。SaaSやOSS、パッケージソフトは外部の事業者や開発者が作ったもので、共通モジュールは自社で使い回すために整えたプログラムです。APIは、こうした部品と自社のシステムをつなぐ役目を持ちます。
気をつけたいのは、既存のサービスを使っていることと、この手法に取り組んでいることは同じではない点です。たとえば社内の経費精算に外部のサービスを使っていても、それだけで部品を組み合わせてシステムを作ったことにはなりません。分かれ目は、最初から部品の組み合わせを前提にシステムを設計するかどうかにあります。
IPAの調査は、この手法への取組状況を1つだけ選ぶ形で尋ねています。選択肢は「積極的に取り組んでいる」「一部で部分的に取り組んでいる」「検討している」「特に取り組んでいない」「わからない」の5つです。*1 どのシステムに使ったかや、手法を使って開発期間がどれだけ短くなったかは尋ねていません。
なぜ作る量を減らすのか
開発が遅れたときの立て直し方は、大きく3つあります。人を増やす、作る量を減らす、期限を延ばす、の3つです。このうち作る量を減らすには、残りの作業のうち、どれを既存の部品に置き換えられるかを先に調べておく必要があります。
人を増やす方法では、候補者を探し、加わってもらい、仕事の進め方を伝えるまでに時間がかかることがあります。期限を延ばす方法では、発注元や利用部門との調整が要ります。作る量を減らす方法は、置き換えられる部品が見つかれば、その分の作業そのものが要らなくなる点が違います。3つのどれか1つに決める必要はなく、作る量を減らしたうえで、残る作業に人を増やすこともできます。
企業の取組状況
IPAの「2025年度ソフトウェア動向調査」は、国内のソフトウェアを取り巻く動向を調べるために、前年度から続けて実施されている調査です。公開は2025年11月25日、最終更新は2026年5月13日で、2026年2月9日時点で362件の回答を得ています。*2 ここで見る3つの設問はいずれも回答する企業を絞る条件がなく、362社全体が答えています。*1 以下の件数と割合は、IPAが公開している回答データ（CSV形式のファイル）を数えて計算したものです。*3
取組状況で最も多い回答は「特に取り組んでいない」で、143社、39.5％でした。次いで「一部のシステムやプロジェクトで部分的に取り組んでいる」が105社（29.0％）、「積極的に取り組んでおり、複数のシステムで実践している」が48社（13.3％）です。*3 後の2つを合わせると、取り組んでいる企業は153社、42.3％になります。
「現在、導入や適用を検討している」は28社（7.7％）、「わからない」は38社（10.5％）でした。*3 取り組んでいない143社とわからない38社を合わせると181社で、362社のちょうど半分に当たります。半数の企業は、この手法に取り組んでいないか、取組状況を把握していないことになります。
部品をつなぐ技術の導入状況
部品を組み合わせるには、部品どうしをつなぐ仕組みと、部品を動かすクラウドなどの環境が要ります。同じ調査は、7つの技術について「導入している」「試行している」「検討中」「導入していない」「わからない」から1つを選ぶ形で導入状況を尋ねています。
導入と試行を合わせて数えると、最も多いのはAPI連携・マイクロサービス（システムを小さな単位に分けて作る方式）で、147社、40.6％でした。内訳は導入が101社（27.9％）、試行が46社（12.7％）です。次いでクラウドネイティブ（クラウドで動かす前提の設計）が130社（35.9％）で、導入88社（24.3％）と試行42社（11.6％）を合わせた数です。*3 残る5つの技術は18.0％以下でした。
導入していない企業と、わからないと答えた企業も見ておきます。「導入していない」はAPI連携・マイクロサービスで107社（29.6％）、クラウドネイティブで121社（33.4％）でした。「わからない」はそれぞれ60社（16.6％）と73社（20.2％）です。*3 自社でこの2つが使われているかを答えられない企業が、2割前後あることになります。つなぐ仕組みの有無が分からなければ、どの作業を部品に置き換えられるかの見積もりも立てにくくなります。
システムを小さな単位に分ける移行の進め方は「マイクロサービス移行の分割・外注費用と委託先の選び方」で、全社のシステムの全体設計を整える話は「エンタープライズアーキテクチャ(EA)整備を外注で進める」で扱っています。
速さはどこまで重視されているか
同じ調査は、ソフトウェアが事業に与える影響のうち最も重要なものを、11の選択肢から1つ選ぶ形でも尋ねています。最も多かったのは「業務プロセスの効率化や高度化」で136社（37.6％）、次いで「ビジネス競争力の維持向上」が85社（23.5％）、「経営戦略立案や経営判断の支援」が40社（11.0％）、「付加価値と顧客満足度の向上」が36社（9.9％）でした。*3
「市場変化に対する迅速な適応力の向上」を選んだのは25社、6.9％です。*3 1つだけ選ぶ設問なので、6.9％は速さを最も重視する企業の割合で、速さを重視しない企業の割合ではありません。ビルディングブロック型開発を社内で提案するときは、期間の短縮だけでなく、業務の効率化や競争力と結びつけて説明すると、判断する側の関心に沿いやすくなります。
どう進めるのか
予定より遅れている開発で作る量を減らすときは、4つの順に進めます。1つ目は、まだ作っていない画面や帳票（請求書などの出力書類）、ほかのシステムとのデータのやり取りを書き出すことです。2つ目は、書き出したもののうち、既存のサービスや公開されているソフトウェア、社内で共通化したプログラムに置き換えられるものを探すことです。
3つ目は、API連携の仕組みとクラウドの環境が社内で動いているかを確かめることです。4つ目に、置き換えた後に残る作業だけを対象に、必要な人数を見積もります。最初に人数を決めてしまうと、置き換えで減る作業の分が見積もりに入りません。
部品を探す作業と残りの開発を同時に進めたいときは、部品の調査を担う人に期間を決めて加わってもらい、社員は残る作業の開発に集中する形も取れます。立て直しの数か月だけ加わってもらうなら、フリーランスを含む業務委託が使いやすい方法です。工程ごとに社内に残す作業と委託する作業の分け方は「工程別の内製化｜設計開発テストだけ委託が34.4％」で扱っています。
つまずきやすい点
一つ目は、既存のサービスを使っていることを、この手法に取り組んでいることと取り違えることです。二つ目は、つなぐ仕組みの状況を確かめないまま部品を選ぶことです。API連携の導入状況を「わからない」と答えた企業が16.6％あったように、社内の状況が見えないまま進めると、部品を選んでもシステムにつなげないおそれがあります。
三つ目は、調査の数字を自社の見込みに当てはめてしまうことです。3つの設問は別々に尋ねたもので、たとえばAPI連携を導入している企業ほどこの手法に取り組んでいるかどうかは、今回の集計では見ていません。数字は業界の分布として参考にとどめ、自社でどの作業を置き換えられるかは、実際の作業を書き出して確かめます。
まとめ：作る量を減らす前に確かめたい3つの点
ビルディングブロック型開発を予定より遅れている開発の立て直しに使ううえで、確かめておきたい点は3つに整理できます。第一に、既存のサービスを使っていることと、部品の組み合わせを前提に設計することを分けて考えること。第二に、部品をつなぐAPI連携の仕組みが自社で動いているかを確かめること。第三に、人数を決める前に、残りの作業のうち部品に置き換えられるものを探すことです。この3点を踏まえておけば、「人を増やしたのに遅れが縮まらない」という事態を避けやすくなります。作る量の見直しや開発の体制づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
ビルディングブロック型開発とマイクロサービスは同じものですか
同じものではありません。マイクロサービスはシステムを小さな単位に分けて作る方式で、ビルディングブロック型開発は既存の部品を組み合わせて作る手法です。IPAの調査でも、2つは別の設問で尋ねられています。小さな単位に分けておくと、その一部を既存の部品に置き換えやすくなるという関係にあります。
社内で作ったプログラムも部品になりますか
なります。調査の定義には、外部のサービスやソフトだけでなく共通モジュールも含まれています。*1 複数のシステムで同じ処理を作っているなら、それを共通のプログラムとして整えておくと、次の開発で使い回せます。
置き換えられる部品を探すのは、誰が担当するとよいですか
既存のシステムの中身を知っている社員と、部品にする候補のサービスやソフトに詳しい人の両方が関わると進めやすくなります。社内に後者がいなければ、調査の期間だけ外部の専門人材に加わってもらう方法もあります。
IPAの調査には、どのくらいの企業が答えていますか
2026年2月9日時点で362件の回答を得ています。*2 同じ調査でも回答企業の種別で対象を絞った設問は247社が答えており、本文で見た3つの設問とは分母が違います。*1
開発の体制を相談したいとき
既存の部品に置き換えられる作業の整理と、残る作業に必要な人数の見積もりからご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「2025年度ソフトウェア動向調査 設問一覧」（https://www.ipa.go.jp/digital/software-survey/software-engineering/j5u9nn000000hkhs-att/software2025-c-questions.xlsx）。ビルディングブロック型開発の定義（Q8-1の注記）、Q3-1・Q8-1・Q13-1の回答条件と選択肢の確認として（2026年9月確認）
- *2 参考：IPA「2025年度ソフトウェア動向調査」（https://www.ipa.go.jp/digital/software-survey/software-engineering/software2025.html）。調査の目的・公開日・最終更新日・回答件数（2026年2月9日時点で362件）の確認として（2026年9月確認）
- *3 参考：IPA「2025年度ソフトウェア動向調査 調査結果（選択肢項目文字列）」（https://www.ipa.go.jp/digital/software-survey/software-engineering/j5u9nn000000hkhs-att/software2025-result-data-str.csv）。Q3-1・Q8-1・Q13-1の回答を数えて件数と割合を計算した元データとして（母数362社）（2026年9月確認）
