はじめに
メリークリスマス！ 
Ateam LifeDesign Advent Calendar 2025 25日目は @tsutorm がお送りします。
もう4年前になりますが 「"工数が足らない" からの脱却」という記事を書きました。
じわじわとロングランでいいねを頂きまして、皆さんの工数を取り巻く苦労を感じます。
今回は工数シリーズ第二弾として「ソフトウェア開発を『生産ライン』で語る違和感」と題した内容をお送りします。
※この記事は私自身の言葉や考え方を反映していますが、一部GPTやClaudeの出力を含んでいます。
1. 開発プロセス=生産ライン、工数=原材料として語ることの違和感
「工数が足りないからできない」「この機能は工数を積めば実装できる」「開発ラインが足らない」
こういう会話が皆さんの周りで発生することはないでしょうか。
私自身もこういう表現を使うこともありますし、ビジネスサイドとこういったコミュニケーションをとることもあります。
しかし一方でこのようなキーワードに私は常日頃、違和感を感じています。
これは、企画・設計・実装・テストを一連の工程として捉えて、ソフトウェア開発を製造業の生産ラインとしてみなす事を暗黙的に共有して成立している概念に見えるからです。
生産ラインはわかりやすい概念です。原料を投入して一連のプロセスを経て製品が出力されます。
分かりやすく、管理しやすく、説明しやすい。
ですから、おそらく多くの現場でこういった表現が使われていると思います。（使ってなかったらすみません...）
しかしこの比喩ではソフトウェア開発の特性が十分に説明されておらず、その結果開発とビジネスの間での相互理解を妨げるという問題もあるのでは。と感じています。
今回はこの違和感の正体と、比喩のスコープのズレについての一見解を述べていこうと思います。
2. 生産ラインメタファーの限界
生産ラインのメタファーは、ビジネスサイドにとって非常に魅力的な概念です。工程が明確で、進捗が測れて、工数とコストを結び付けやすいです。
特に「工数」という概念は原価管理や予算管理と相性も良くて、形がなく捉えどころのないソフトウェア開発プロセスを同じ枠組みで扱えるのではないか。という期待からこのような概念が自然と生まれたんではないでしょうか。
しかし、製造業の生産ラインは基本的に「同一の成果物を大量生産し、成果物は在庫として保管・販売できる」ことを前提としています。この場合、産出された製品は一定の価値で販売できることが前提として成立していて、投下資源と産出量=価値は比較的比例します。
一方、Webサービスやアプリケーションといったソフトウェア成果物の性質は根本的に異なります。
成果物は基本的に1点物であり、また複製コストは限りなくゼロに近いです。ソフトウェアを買い切りやライセンスの形態で販売することもありますが、Webサービスやアプリケーションはそれらを継続的に利用して得られる便益=利用価値に対して対価が発生します。
この違いを無視してしまうと「工数を積めば価値が増える」という誤解が生じてしまいます。
私個人としてはこの部分に強烈な違和感を覚えるところです。
3. より適切なメタファー
それではソフトウェア開発プロセスはどのような活動と類似しているのでしょうか。私が思うより適切なメタファーとして2つ提示したいと思います。
候補1. 研究開発（R&D）
ソフトウェア開発という部分から、プロセスとして類似性が高いのは研究開発活動だと思います。
プロセスの類似性としては1は以下のように整理できると考えます。
| R&D | ソフトウェア開発 |
|---|---|
| 企画・構想 | 要件定義 |
| 基礎研究 | 技術検証・PoC |
| 開発 | 設計・実装 |
| 実用化 | リリース |
| 評価・改善 | 運用・フィードバック反映 |
これらのプロセスとソフトウェア開発プロセスの類似性は高いと考えます。また、成果や活動の性質としても次のような類似点があると考えます。
- 成果が事前に完全には予測できない
- 試行錯誤そのものが価値を生む
- 人と時間をどれだけ投入しても必ず成功する保証はない
候補2. 建築、不動産運営
ビジネスモデルの観点では、建築や不動産運営も比喩として有効と感じます。
| 建築・不動産 | ソフトウェア |
|---|---|
| 建築ディベロッパー | 受託開発会社 |
| 賃貸マンション経営 | SaaS事業 |
| 施工不良・手抜き工事 | 技術的負債 |
| 経年劣化 | ライブラリの陳腐化、セキュリティ脆弱性 |
| 修繕・リフォーム | リファクタリング |
共通する特徴をピックアップします
-
初期設計の長期影響：
- 建物の基礎や構造は後から変えられません。ソフトウェアですのである程度柔軟な変更ができますが、採用言語やアーキテクチャなどは同様の性質があり、初期の設計判断が5年後、10年後の運用コストを大きく左右することがあります
-
見えない品質の重要性：
- 配管や断熱材は外から見えませんが、住み心地を決定的に左右します。ソフトウェアのコード品質やテストカバレッジも、ユーザーからは見えませんが長期的な安定性を支えています
-
維持管理コストの存在：
- 建物は建てて終わりではなく、経年劣化による修繕が必要です。ソフトウェアはそれ自体が経年劣化しませんがライブラリの陳腐化やセキュリティ脆弱性の発見などで保守・運用に継続的なコストがかかります
4. 生産プロセスのメタファーが有効な領域
ここで重要なポイントがあります。生産プロセスのメタファーが完全にミスマッチであるということではない。ということです。
生産プロセスのメタファーが活きる部分というのは開発プロセスそのものではなく、ソフトウェアが入力を受け取り出力を行うまでの一連の処理に対応しています。
Webサービスを例にとりましょう。
ブラウザからリクエストを受け取ったら、アプリケーションは内部で入力とデータを加工しHTMLやJSONを生成しレスポンスとして返却します。場合によってはキャッシュに生成物を保持することによって同一の要求には即座に応答を返すでしょう。
これはリクエスト処理を製造工程、キャッシュを在庫、レスポンスを出荷と捉えられるのではないでしょうか。
製造プロセスで登場する概念（スループット、レイテンシ、ボトルネック、スケール）との整合もつきます。
製造業における生産ラインのメタファーで表すべきはソフトウェアの動作そのものにあるではないでしょうか。
5. ソフトウェア開発～運用を二層構造として整理する
ここまでを整理すると、ソフトウェア開発は二層構造として捉えられます。
創るフェーズ: 開発プロセスは研究開発・建築/資産形成を比喩として使う
動かすフェーズ: リクエスト/レスポンス処理を製造プロセス。各機能を生産ラインを比喩として使う。
本来後者の比喩を前者に適用してしまったことが違和感の正体だったのではないでしょうか。
6. まとめ: 比喩を正しく使い分ける
比喩は理解を助ける一方で、思考の枠組みを固定してしまいます。
ソフトウェア開発を生産ラインだけで語ってしまうと、設計や構造、長期価値が見えづらくなります。
一方で、生産ラインの比喩を正しい場所で使えば、運用や性能改善において強力な武器になるのではないかと考えます。
ややこしい比喩など使わずに本質で語ればいいのでは。というご意見もあるかと思いますが、
私は、わかりづらいソフトウェア開発の理解を助けるために比喩は重要な要素だと考えています。
今回とりあげた2つの比喩もソフトウェア開発の本質と異なる部分があると思います。万能な比喩は存在しないと思います。
比喩のスコープを正しく認識し、使い分けることが重要 なのではないでしょうか。
この記事がビジネスとエンジニアの間に立つ方々の手助けとなれば幸いです。