ソフトウェア開発を製造業の設計のメタファーで捉えるか、製造のメタファーで捉えるかは経営学で永らく論争の行われてきたテーマらしい。実際のところ両面あるんだろうけれど、バグを減らすための品質管理になると、製造メタファーの方が相関が分かりやすいこともあって応用が進んでいるようだ。業態によっても違って、携帯サイト構築のように自社サービスのコーディングであれば、経営判断とコーディングを同じ人間が担当できる可能性があるけれども、受託開発など自由が利かないケースも多い。役所では最近、分離調達といって設計と施工を分ける手法が一般化しつつあるが、こちらは建設のメタファーを参考としているようにみえる。
ソースコードの一行一行は、経営判断そのものだ。
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。
ところでソフトウェア工場という発想は1980年代初頭に日本で生まれた。開発を製造メタファーで捉える場合に、仕様をどう固定するのか、また固定することで本当に良いシステムを作れるのか不思議だったのだが、歴史的経緯を知って疑問は氷解した。
もともとソフトウェア工場とは、日立・富士通が汎用機事業でIBM互換路線を取ったことに端を発していた。富士通のMシリーズはソフト・ハードともにIBM互換のものを独自開発していた。あくまで機能レベルの互換性であり、IBM汎用機から富士通汎用機への移行には移植作業を伴う。彼らはまずこの移行作業をソフトウェア工場で行ったようだ。だから仕様については、元のIBM互換機上と同じように動くという単純明快な目標があった。
いうまでもなく新規につくるソフトウェアについては製造アプローチよりも設計アプローチが有効な場合もある。つまりソフトウェア開発とは不断の問題解決プロセスであり、分裂勘違い君のいうような経営判断の集積でもあるのだろう。システムだけを見直すよりも、事業構造や業務プロセスも含めて最適化した方が、問題解決に当たって効果的な場合が多い。
自社サービスであれば全体最適を指向することはまだ容易だが、SIerとして外部から入るとなると非常に難しい。客へ向かって「システムが赫々云々だから、仕事の仕方をこう変えてください」とは言い難いからだ。システムではなく問題解決そのものを請け負い、ITをツールとして活用できればよいし、IBM筆頭にITベンダ各社はコンサルティング部門を強化している。
そういった領域では仕様決めやコーディングを設計として捉え、製造業の設計プロセスに於けるプロジェクト管理や問題解決の方法論が参考となるかも知れない。一方で量産する製品を設計するプロセスと、企業活動を情報システムで支える上での問題発見・解決プロセスとは異なるところもあるだろう。
いずれ情報システムやITサービスそのものを対象としたケーススタディや理論が増えてくるだろうが、製造業・建設業・サービス業といった既存産業のメタファーを援用する場合、何をどう適用するかで問題設定や解くためのアプローチは大きく変わりそうだ。