マツダ×日鉄の共創から学ぶ──価格勝負を超える「設計一体化」のシステム開発論
仕様を縛ると、技術も発想も閉じ込めてしまう。
2025-10-27

マツダと日本製鉄が、車体開発の初期段階から連携する「共創型開発」を始めました。価格で競わせる従来の調達構造を見直し、設計思想を共有することで、コスト削減と品質向上の両立を図るものです。
この考え方は、自動車業界だけでなく、システム開発の世界にも深く通じます。見積り比較に頼った価格競争は一見合理的に見えて、実は全体の非効率を生む構造です。本コラムでは、見積り競争がなぜ限界を迎えているのか、そして“共創型フルスクラッチ開発”がどのようにその課題を解決するのかを解説します。
>>フルスクラッチ(オーダーメイド)のシステム開発について詳細はこちら
目次
【記事要約】マツダ、日鉄と共同で車体開発 関税負担を背景にサプライチェーンを再構築
マツダは日本製鉄と自動車車体の共同開発を開始する。日鉄が設計初期から参画し、車両全体の軽量化・コスト削減を図る。従来の部品単位の競争入札を見直し、素材メーカーの技術提案を生かす「共創型」体制へ転換。米国の関税引き上げで業績が悪化する中、マツダはコスト構造の抜本改革を急ぐ。初の対象は25年末発売予定の新型「CX-5」で、日鉄の次世代鋼材により1割軽量化を実現。自動車メーカーと素材メーカーの上下関係を超えた対等な連携の先例となる。
出典:日本経済新聞「〈ビジネスTODAY〉マツダ、日鉄と車体開発米関税打撃、コスト削減 車メーカー優位の力学変化」2025年10月24日付朝刊
ポイントをひとことで
見積り競争による価格中心の発注構造は、一見合理的に見えて実は開発力を削ぐ仕組みです。仕様を先に固定してしまえば、開発会社は「安く作る」ことしかできず、「より良くする」ための提案を封じられます。結果として、表面上のコストは下がっても、再設計や改修が増え、全体コストは上昇します。真に効率的な開発とは、発注者とシステム開発会社が構想段階から課題を共有し、共に設計を考えること。そこにこそ、品質とコストを両立する“共創型開発”の本質があります。
価格だけで選ぶ構造が、なぜ非効率を生むのか
システム開発の発注現場では、複数のシステム開発会社に同じ仕様書を配布し、最も安い見積りを提示した会社を選定するという流れが一般的です。
一見、コストを抑える合理的な方法のように思えます。しかし、ここに大きな落とし穴があります。
まず、仕様を固定した状態で見積を取ると、システム開発会社は「決められたことを最も安く実装する方法」を考えるしかありません。そこに創意や技術的な最適化の余地はなく、各社は“言われた通りに安く作る”方向に走ります。
その結果、発注者は「安く見える見積り」を手に入れられても、長期的には以下のような非効率を抱えます。
- システム全体の整合性が取れず、後工程で修正が増える
- 業務フローや運用を十分に理解しないまま実装が進む
- システム開発会社が本来持つ技術提案や改善力が生かされない
つまり、見積り競争で“安さ”を追求するほど、全体としてのコストはむしろ上がる構造になっているのです。
固定化された仕様が「提案力」を奪う
マツダと日本製鉄の事例では、まさにこの構造の逆を行っています。
これまでマツダは、設計後に部品ごとの素材を複数のメーカーに競わせる方式を取っていましたが、結果的に素材メーカーの技術力を十分に引き出せず、全体コストも高止まりしていました。
この構図は、システム開発でも同様です。
仕様が完全に固まった状態で見積り依頼が出されると、システム開発会社は「与えられた前提の中で安くする」しか選択肢がありません。
本来であれば、
「この要件なら別の設計手法の方が効率的です」
「このデータ構造なら将来的な拡張に備えてこう設計すべきです」
といった提案ができるはずなのに、仕様が固定されているため提案の余地がない。
つまり、発注側の“管理しやすさ”を優先した結果、システム開発会社の技術知見や創造力が封じられているのです。
「安い見積り」の裏で生まれるコスト構造
システム開発の現場でよく起きるのが、「当初の見積りより高くなった」「想定外の追加費用が発生した」という問題です。しかし、その原因の多くは“見積りが安かったから”ではなく、“見積りの出し方が誤っていたから”にあります。
仕様が確定した段階で単純な工数計算を行うと、一見明確な数字が出ますが、実際には仕様変更・運用要件・他システムとの整合など、プロジェクト進行中に発生する変数を十分に織り込めていません。
結果として、開発中に要件変更や再設計が発生し、工数が膨らみ、コストも増大する。
つまり、「最初に安く見せたコスト」が後から膨らむ構造になっているのです。
これはマツダが「見積価格の安さで選んでいた結果、むだなコストを見落としていた」と語った状況とまったく同じです。
“共創型フルスクラッチ開発”がもたらす構造改革
では、どうすればこの構造から抜け出せるのでしょうか。
鍵は、発注者とシステム開発会社が「設計段階から共に考える」関係に変わることです。
“共創型フルスクラッチ開発”とは、仕様書が固まってから発注するのではなく、構想や業務課題の段階からシステム開発会社と対話を重ね、最適なシステム像を共に描くアプローチです。
これにより、以下のような効果が生まれます。
- 発注側の業務課題と技術側の制約を相互に理解できる
- 目的に即した要件設計が可能となり、仕様変更リスクが減る
- 技術的な最適化や自動化の提案が設計段階から行える
たとえば、「顧客管理」と「在庫管理」を別システムとして発注する場合、それぞれの業務要件だけを見れば最適化できますが、データ連携や運用の整合性は後回しになります。
一方で、共創型の設計では、“顧客データが在庫回転にどう影響するか”という構造全体を俯瞰して設計できるため、後工程の無駄を大幅に減らせます。
“対等な関係性”が生む技術進化のスパイラル
共創の本質は、「立場のフラット化」にあります。
マツダと日鉄の取り組みは、自動車メーカーと素材メーカーという“主従関係”の構図を壊し、対等な立場で価値を共に生み出す関係へ転換した点に意義があります。
同様に、発注者とシステム開発会社の関係も、“指示と実行”から“対話と設計”へと変える必要があります。要件を指示する側と、従う側という構造では、創造性も責任も分断されます。
しかし、課題を共有し、リスクをともに背負い、成果を共に評価する関係に変われば、システム開発会社の技術力は自然と引き上げられます。
さらにこの関係は、単発のシステム開発に留まらず、長期的な進化を生む基盤にもなります。
共創によって設計思想を共有していれば、新しい業務要件が生じた際にも、再構築ではなく“進化”として対応できる。つまり、対等な関係性が、継続的な技術成長のスパイラルを生むのです。
“共創”が最終的にコストを下げる理由
価格交渉による削減と、共創による削減は、性質がまったく異なります。
価格交渉は「単価を下げる」発想であり、共創は「仕組みを変えて無駄をなくす」発想です。
共創型の設計を実践すれば、
- 再設計や追加開発の発生を抑える
- 業務側と技術側の認識齟齬を減らす
- 運用や保守まで見据えた構造を設計できる
結果として、初期費用だけでなく、運用・保守・拡張を含めた“総コスト”が確実に下がります。
これは、マツダと日鉄が「共創によってムリ・ムダ・ムラを削減した」構造と同じです。
まとめ
価格で競わせる発注構造は、一見合理的に見えて、技術力の発揮を阻み、長期的なコストを増やす結果を招きます。仕様を固定したうえで見積りを取るのではなく、構想段階からシステム開発会社と共に考える。この「共創型フルスクラッチ開発」こそが、真の意味でコストを抑え、品質とスピードを両立する唯一の方法です。
見積りを比較する前に、まず「共に設計する」という発想に立ち戻ること。
それが、これからのシステム開発に求められる新しいスタンダードです。
フレシット株式会社では、この「共創型フルスクラッチ開発」の思想を実践しています。私たちは、要件が固まった後に作るのではなく、構想段階からお客様と課題を整理し、業務フローやサービス設計、将来の拡張性までを見据えた全体設計を行います。システム開発会社としての立場を超え、事業の一部を共に設計する“パートナー”として伴走することで、コスト・品質・スピードのすべてを最適化します。安さではなく、本質的な価値を生む開発をお考えの方は、ぜひフレシットにご相談ください。
>>フルスクラッチ(オーダーメイド)のシステム開発について詳細はこちら
著者プロフィール
フレシット株式会社 代表取締役 増田順一
柔軟な発想でシステム開発を通して、お客さまのビジネスを大きく前進させていくパートナー。さまざまな業界・業種・企業規模のお客さまの業務システムからWEBサービスまで、多岐にわたるシステムの開発を手がける。一からのシステム開発だけでは無く、炎上案件や引継ぎ案件の経験も豊富。システム開発の最後の砦、殿(しんがり)。システム開発の敗戦処理のエキスパート。

公式Xアカウントはこちら