ITシステム構築での失敗を避ける:製造業とのアプローチの違い

2024/07/02

企業の経営者や事業責任者にとって、ITシステムの再構築は非常に重要な課題です。しかし、そのプロセスを製造業や建築建設業のように捉えると、プロジェクトは失敗に終わる可能性があります。製造業の成功体験をベースに、ITシステム構築にアプローチする企業が多いですが、これが問題を引き起こす要因となり得るのです。本稿では、ITシステム構築と製造業アプローチの違いに焦点を当て、成功するための戦略を探ります。

1.はじめに

コンサルタントの立場で企業の方々とお話ししていると、システム構築が思うように進まず、不満の声が上がるケースに度々直面します。
特に製造業や建築建設業の関係者からは、システムベンダに対する強い不満が聞こえてきます。

製造業であれば、製造仕様に従って詳細な手順を経てプロダクトが完成するのが常識です。
建築や建設業でも、図面に詳細に記された部品や建付けに基づき、お客様が納得の上でその通りに仕上がるのが自然な期待です。しかし、同じ期待を持ってシステム開発に臨むと、しばしばその常識が通じず、結果として「非常識だ」と憤られることが少なくありません。 このような不満の背景には、システム開発と製造業・建設業との本質的な違いが潜んでいます。

そこで本稿では、システム開発の特異性と、製造業や建設業とのアプローチの違いについて考察し、その違いを理解することで、システム構築の成功につなげるためのポイントを探っていきます。

2.ITシステム構築と製造業の違い

まず、製造業の視点からITシステム構築を捉える際の誤解を解くことが重要です。製造業は「安くて高品質な製品を大量生産する」という目標を持ち、そのためのプロセスが確立されています。例えば、日本の自動車産業は、トヨタ生産方式などの効率的な生産手法を採用し、品質を確保しつつコストを削減することに成功しています。この成功モデルは、他の産業にも影響を与え、特に効率性が求められる場面では大きな成果を上げてきました。

一方で、ITシステム構築は、その性質上、製造業の大量生産アプローチとは相容れない部分が多々あります。ITシステム構築は、単なる製品を作る行為ではありません。それは「業務プロセスをシステム化する」という極めて複雑な作業です。たとえば、業務には「この状況ではこうする」といった暗黙知や経験則が多く含まれています。しかし、これらを明文化し、プログラムとして実装することは容易ではありません。

製造業では、製品の設計が一度確定すれば、その後の製造プロセスは一定の品質とコストで大量に生産できます。工場のラインが稼働し始めると、同じ製品が次々と生産されるため、コスト効率が高くなるのです。このような製造業の特性は、ITシステム構築には当てはまりません。その詳細を以下より考察していきます。

  • プロセスの性質の違い

ITシステム構築の本質は、「人が行うプロセスの定義」にあります。システムを通じて業務を自動化・効率化するには、業務に内在する動作や意思決定を、プログラムとして明示的に記述しなければなりません。この過程では、「暗黙知」や「属人性」といった、言葉で定義しづらい要素が大きな影響を及ぼします。

一方、製造業は、製品の工程化や可視化が前提となっています。例えば、自動車の製造プロセスでは、設計図に基づいてすべての部品と手順が明確に定義されます。作業の標準化が行われ、どの工程でも一定の品質を確保できる仕組みが整備されています。

この違いにより、ITシステム構築は、製造業のような線形で確定的なプロセスでは対応できない場面が多くあります。ITシステムは、目に見えない情報やプロセスを扱うため、柔軟な対応と進行中の定義の見直しが求められるのです。

  • 属人性の課題

ITシステム構築には、作業を担うプログラマ個人の能力や経験が大きく関わります。プログラムを書くという行為自体がクリエイティブな要素を含み、その結果はプログラマのスキルによって左右されます。同じ仕様書に基づいても、熟練したプログラマと新人のプログラマでは、コードの品質や保守性、効率性に大きな差が生じます。

これに対して、製造業では製造ラインの標準化が進んでおり、作業者の個々のスキル差を吸収する仕組みが確立されています。たとえば、自動車の部品組み立てでは、手順や道具が統一されているため、熟練者でも新人でも、最終製品の品質は基本的に一定です。

  • 工程管理と分業化を前提とした製造業のアプローチとのギャップ

製造業では、製品の設計から製造、出荷まで、すべての工程が明確に定義され、管理されています。各工程は分業化され、特定の役割や手順が明確に割り当てられるため、効率的かつ均一な品質を実現できます。例えば、自動車製造では、設計図が製造プロセスを決定し、すべての部品が精密に組み立てられることで完成品ができあがります。

この「工程管理と分業化」に基づくアプローチは、製造業において長年成果を上げてきたモデルです。しかし、これをそのままITシステム構築に当てはめると、思わぬ問題が発生します。

  • ITシステム構築における「プロセスの流動性」とのギャップ

ITシステム構築では、製造業のようにあらかじめすべての仕様やプロセスを固定化することが困難です。その理由の一つに、ITシステムは「未知の要件」や「曖昧な仕様」を含むことが多い点があります。プロジェクトの進行中に初めて顕在化するニーズや課題が頻繁に発生するため、プロセスが流動的になる傾向があります。

また、システム構築はソフトウェアという非物理的な対象を扱うため、製造業のように「完成品として明確に定義された状態」に到達するまでのプロセスが明瞭ではありません。この違いが、製造業のアプローチをそのまま適用する際の大きなギャップを生みます。

3. ITシステム構築を「設計業」として捉える視点

ITシステム構築では、各プロジェクトが個別のニーズや要件に応じて設計されます。プログラミングは、単なる製造工程ではなく設計そのものであり、製造業が目指す均質なプロダクトの大量生産とは本質的に異なります。ITシステムは用途やユーザーに応じてカスタマイズが必要であり、そのため標準化されたプロセスではなく、柔軟で創造的な設計が求められるのです。

  • 設計とは何か: ITシステム構築におけるプロセスの定義

ITシステム構築における「設計」とは、単なる図面や計画を作成する行為にとどまりません。それは、人間が行う業務プロセスを定義し、システムに落とし込む行為そのものです。業務に内在する手順や判断基準を抽出し、それをコンピュータが実行可能な形に変換することが「設計」としてのプログラミングの核心です。

例えば、業務の「この場合はこうする」という暗黙知を明文化し、具体的な手順として整理することが求められます。これは、製造業で行う「製造工程」の計画とは異なり、常に変更や調整が必要となる動的な行為です。

  • プログラムを書く行為は「設計」そのもの

プログラミングとは、仕事のプロセスを手続きとして記述する行為であり、同時にアルゴリズムを作成する行為です。プログラムに書かれるコードは、人間の思考を反映し、業務の流れを具体的に表現します。

ここで重要なのは、プログラミングが単なる「コーディング」ではなく、「設計」であるということです。プログラムの品質は、設計の良し悪しによって左右されます。例えば、顧客の要件を正確に理解し、それを効率的かつ柔軟な形でコードに落とし込む能力が求められるのです。

製造業では、製品の設計図に基づき、均質な製品を大量に生産することが目的です。しかし、ITシステム構築では、各プロジェクトが異なる要件やニーズに応じて設計されます。この違いは、以下のように説明できます:

  • 製造業: 設計が終われば、製造工程は繰り返し可能な均質なプロセスとして実行されます。

  • ITシステム構築: プログラムを書く行為そのものが設計であり、各工程がプロジェクト特有の仕様に依存します。

つまり、製造が「規格化されたプロダクトの生産」を目指すのに対し、ITシステム構築は「個々の仕様に基づく設計」を行うプロセスであると言えます。

4. まとめ

ITシステム構築は、全ての工程が「設計」と言える特性を持ちます。プログラミングは設計そのものであり、システムの成功は設計の質に大きく依存します。経営者や事業責任者は、ITシステム構築を製造プロセスではなく、設計業として捉える視点を持つべきです。

製造業の成功事例を参考にしながらも、ITシステム構築に特化した柔軟なアプローチを取り入れることが、競争力を高める重要なステップとなるでしょう。

この記事を書いた人について

谷尾 薫
谷尾 薫
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア(全省庁統一資格Aランク)代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。