共創でつくる、が意味するもの ― 発注者と受注者をやめると開発はどう変わるか

当社は「共創でつくる」という言葉をよく使います。ビジョンは「共創があたりまえの社会へ。」です。ただ、この言葉が開発の現場で何を意味するのかは、外から見ると分かりにくいと思います。大企業の共創プログラムのような対話の場でもなく、費用と知的財産を分け合う共同開発でもありません。

一言でいえば、発注する側と請け負う側という関係をやめることです。当社ではこれを共創型開発（共創開発）と呼んでいます。お客様と当社が毎週同じ場で動くものを見て、優先順位と仕様をその場で一緒に決めながら、動くソフトウェアを出し続ける進め方です。関係をやめると、決め方、責任の持ち方、そしてお客様にお願いすることが変わります。

この記事では、その変化を具体的に書きます。良い面だけでなく、お客様にお願いする負担と、向いていない場合も書きます。創業の経緯は なぜwesionaryTEAMを創業したのか にあるので、ここでは進め方の違いに絞ります。

受託開発で起きがちなこと

受託開発 の進め方は、要件を定義し、見積と契約を交わし、開発会社がつくり、納品する、というものです。要件が固まっていて変わらないなら、これは合理的な進め方です。

問題は、要件が最初から固まっていることが少ない点にあります。使ってみて分かることが必ず残ります。しかし受託の形では、開発中の中身は発注側から見えにくく、ずれは納品間際になってから「思っていたのと違う」という形で現れます。

これは当社だけの実感ではありません。日本情報システム・ユーザー協会（JUAS）の2025年度調査では、工期が予定どおりにいかなかった要因として、次の三つが前年に続いて上位に並びました。

同じ調査で、品質・予算・工期の悪化に影響した工程として「要件定義」を挙げた企業は57.4〜69.0%にのぼります。500人月以上の大きな開発では、工期が予定どおりにいかなかった割合が47.8%でした。要件は最初に固めたつもりでも動く、というのが業界全体の実態です。

経済産業省のDXレポートも、要件を明確にしないまま開発会社に任せきりにする進め方について、でき上がったシステムが意図したものと異なり、テスト工程で大きな手戻りが起きて費用超過と納期遅延につながり、責任の押し付け合いにもなりやすいと指摘しています。そのうえで、要件を確定するのは利用する企業の側であるべきだと述べています。

そして変更は、交渉になります。追加費用と納期の話になり、どちらの責任かという話になります。これは、どちらかが悪いのではなく、発注と受注という関係がそうさせています。固定の金額で請け負う側には、追加や変更を抑えたい動機が生まれるからです。国のアジャイル開発版モデル契約も、請負契約にはその動機が生じうると明記したうえで、準委任契約（成果物ではなく作業そのものに対価を払う契約）を前提にしています。

共創では、どこが変わるのか

変わるのは三つです。

• 意思決定の場を分けない。お客様と当社が毎週同じ場で、動くものを見て、その場で決めます。発注側が決めて受注側が実行する、という分業にしません。
• 優先順位を一緒に決める。全部を最初に決めるのではなく、次に何をつくるかを都度選びます。要らないと分かった機能は、つくりません。
• 途中で変える前提で進める。変更は想定内であって、交渉ではありません。小さくつくり、触って、直すことを繰り返します。

毎週の定例で扱うのは、次の三つです。先週出したものを触って確かめること、優先順位の入れ替えと範囲の取捨、次の週に出すものを決めること。決めたことはその場で記録し、お客様も同じ画面で見られる プロジェクト管理の仕組み に残します。後から「言った、言わない」にならないためです。

責任の線も引いておきます。何をつくるか、どの順番でつくるかを決めるのはお客様です。決めたものが動く品質で出てくることに責任を持つのは当社です。国のモデル契約でも、つくるものの優先順位を決める責任者（プロダクトオーナー）は発注側が選び、その職務を開発会社に委ねるべきでないとされています。当社の「その場で決められる人に出ていただく」は、この考え方をそのまま実務に置いたものです。

当社はこの進め方を「内製型共創」と呼んでいます。デザイン思考で課題を捉え、リーンスタートアップの考え方で小さく検証し、アジャイル開発で繰り返す。お客様の内製チームの一員のように動く、という意味です。

お客様にお願いすること

共創は、お客様の負担を減らす進め方ではありません。むしろ、関わる時間は受託より増えます。お願いすることは三つです。

時間

週に一度の定例に出ていただきます。動くものを見て、決める場です。加えて、その週に当社から出た確認事項には、次の定例を待たずに答えていただきます。定例の間で返事が止まると、その週の開発が止まるからです。

判断

その場で決められる人に出ていただきます。持ち帰って稟議にかけると、繰り返しの速さが失われます。承認の仕組みがある会社でも、定例の場で決めてよい範囲を決裁者とあらかじめ合意しておけば進められます。

当事者としての関与

実際に使う人に触ってもらいます。発注の窓口担当者だけでは、使う人の迷いは分かりません。定例の一部を、使う人が触る時間にあてます。

この三つが用意できない場合、共創の形はうまく働きません。その場合は、受託の形で進めるほうが合っています。

決める人が出られなくなったら

うまくいかなかった例を抽象化すると、多くは「決める人が定例に出られなくなった」ことから始まります。判断が持ち帰りになり、繰り返しが止まり、結果として受託と同じ待ち時間が生まれます。

そうなると分かった時点で、当社は受託の形に切り替えることを提案します。残りの範囲を固め、見積と契約を交わし直して、納品に向けて進めます。無理に共創の形は続けません。切り替えの基準は、範囲が固まったかどうかではなく、決める人が毎週その場にいられるかどうかです。

うまくいかないケースと、向き不向き

共創が向いているのは、新規事業や業務の作り直しのように、何をつくるべきかをまだ探している段階です。使う人の声で変えたい、決める人が毎週出られる、将来は自社で育てたい、という条件がそろうと、最も力を発揮します。

向いていないのは、要件が固まっていて変えない場合、決める人が参加できず窓口担当者だけで進める場合、期限と範囲が固定で変える余地がない場合、途中の関与を望まず丸ごと任せたい場合です。こうした案件は、受託の形でお引き受けします。

言葉の線引きもしておきます。当社の共創は、費用や知的財産を分け合う共同開発ではありません。アイデアを出し合うワークショップでもありません。動くソフトウェアを毎週出し、それを一緒に見て決め続けることです。

サービスとしての形

共創の進め方は、当社のサービスに共通しています。新規事業を最小の形で検証する PoC・MVP開発、既存の事業で製品を育てるプロダクト共創、そしてお客様のチームが自走できる状態をつくる 内製化支援 です。つくるものが決まっている案件は、システム開発 として受託の形で進めます。どれを選ぶかは、サービス一覧 を見比べたうえで、最初の相談で一緒に判断します。

内製化支援は、共創の延長にあります。毎週同じ場で決める習慣が、そのままお客様の内製チームの進め方になるからです。IPA（情報処理推進機構）のDX動向2025によると、アジャイルの原則を全面的に取り入れている日本企業はどの部門でも1割以下です。進め方を一緒に身につけるところから始める理由がここにあります。内製化すべきか、外注すべきか の判断基準は別の記事にまとめています。

よくあるご質問

共創型開発のデメリットは何ですか？

三つあります。お客様の関わる時間が受託より増えること、費用の総額が最初に確定しないこと、決める人が定例に出られなくなると進みが止まることです。この三つを引き受けられるかどうかが、向き不向きの分かれ目です。

共創だと、費用や範囲が決まらないのではありませんか？

上限は期間と体制で決まり、範囲は優先順位の結果として決まります。期間と体制を先に決め、その中で何をつくるかを毎週一緒に選ぶ形です。範囲を固定しない進め方なので、契約は請負ではなく 準委任契約 の形が合います。事業の立ち上げやAI導入では、導入までの費用をいただかず、公開後の成果に応じていただく形をとることもあります。費用のかたちは最初の相談でご提案します。

稟議が必要な会社でも共創型でできますか？

できます。条件は、定例に決裁権のある人が出られることです。定例の場で決めてよい範囲を先に決裁者と合意しておけば、毎回の稟議は要りません。それが難しい場合は、受託の形をご提案します。

社内にエンジニアがいなくても共創できますか？

できます。必要なのはエンジニアではなく、決められる人と、実際に使う人です。技術は当社が担い、お客様には判断と現場の知識をお願いします。

受託開発は引き受けていないのですか？

引き受けています。要件が固まっているもの、変える余地がないものは、受託の形が合います。どちらが合うかは、最初の相談で一緒に判断します。

まとめ

共創でつくるとは、発注と受注の関係をやめ、決める場を分けないことです。優先順位を一緒に決め、途中で変える前提で小さくつくり直す。その代わり、お客様には時間と判断と当事者としての関与をお願いします。

向いている場合と向いていない場合があります。どちらが合うかを一緒に判断するところから始めたい方は、無料見積相談 で担当PMにご相談ください。共創と受託のどちらの形でも、範囲と費用の目安をその場でお伝えします。進め方について先に相談したい方は お問い合わせ からどうぞ。実際の案件は 開発事例 にまとめています。

関連する記事とページ

• 受託開発とは何か ― 契約の形と、発注前に決めておくこと
• 準委任契約とは ― システム開発での使いどころと、請負契約との違い
• ラボ型開発とは ― 向いている案件と、請負・準委任との違い
• システム開発は内製化すべきか、外注すべきか
• PoC・MVP開発 ― 新規事業を最小の形で検証する
• MVP開発会社の選び方 ― 検証の設計ができる会社を見分ける5つの基準
• 無料見積相談 ― 担当PMに範囲と費用の目安を相談

出典

• 一般社団法人日本情報システム・ユーザー協会「企業IT動向調査報告書2026（2025年度調査）」2026年4月
• 経済産業省「DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～」2018年9月7日
• 独立行政法人情報処理推進機構・経済産業省「情報システム・モデル取引・契約書（アジャイル開発版）アジャイル開発外部委託モデル契約（解説付き）」2020年3月31日（2025年4月改訂）
• 独立行政法人情報処理推進機構「DX動向2025」2025年6月26日