顧客がモジュラーかインテグラルか、社内がモジュラーかインテグラルか、といった2軸で整理することで、以下のような分類が可能となる。

 

表1：内外によるアーキテクチャ分類表

社内(中)|顧客(外)	インテグラル	モジュラー
インテグラル	中インテグラル・外インテグラル (日本の自動車開発etc.)	中インテグラル・外モジュラー (村田製作所・インテルetc.)
モジュラー	中モジュラー・外インテグラル (DELLetc.)	中モジュラー・外モジュラー (汎用部品？)

また、オープンかクローズかでの2軸でも分類もある。

表2：オープンクローズドによるアーキテクチャ分類表

社内(中)|顧客(外)	インテグラル	モジュラー
クローズド	クローズドインテグラル (最適化専用部品)	クローズドモジュラー (社内共通商品)
オープン	- - -	オープンモジュラー (汎用部品寄せ集め)

以下では、社内/顧客軸のについての分類を基に考える。私や周辺の人が「現場」と言っていたのは何だったのか。開発の現場と異なるお客さまの「現場」とは何なのだろう。ちなみに、DevLOVEというコミュニティで去年末に「現場」をテーマにAdvent Calendarを書いてもらっていた。そこには様々な現場が詰まっている。
http://devlove.doorkeeper.jp/events/7039


私は「現場」とは「複雑性のある場所」であり、「現場力」とは「その場にある複雑性に対処する力」であると考えた。 人を取り囲む世界は、複雑なもので、複雑さと共に人は暮らしている。


 その複雑さと対峙し、うまく付き合っていくために、様々な方法をとっている。それに対峙する方法の大分類が「モジュラー(組み合わせ)」か「インテグラル(擦り合わせ)」かなのではないか。インテグラルは複雑なものに対してそれを受け入れて合わせ込む方法であり、モジュラーは複雑なものに対してそれを部品に切り出して組み合わせる方法であると思われる。「複雑なもの」それ自体が「現場」にある課題だろう。

ここ1年ほどの経験を通して、その「現場」、お客さまの「現場」の複雑さに向き合うことの大切さを知ったのだが、さて、開発の現場はどうか。
 開発の現場もまた、複雑さを抱えている。単純さはあまりない。そこに「ツールだけ入れてもダメ」「手法だけ学んでもダメ」と言われる類の言説がある。開発現場での課題は、複雑だ。ツール(道具)というモジュール(部品)を入れないとダメ。それは、インテグラル(擦り合わせ)の世界なのではないか。部品をただ組み合わせるだけではなく、どのようにしたら合わせられるかを考え、合わせ込む熟練工の世界。結局それを「現場」という言葉に包んでしまっていたのではないか。

とりあえず、この記事はこの辺で。 

タイトルは岩井俊二さんを意識したようでうまく意識できてなかった。