情報システム部門は、会社の情報システム革新の先端をいくべき部門だけれど、残念ながらその意識は技術的な問題にとどまっているようだ。

たしかに技術に関しては、新しいものを積極的に取り入れようとしている（それさえできないSEは論外だが）。しかし、情報システム部門のもう一つの大切な役割は、情報というものに対する認識を変えていくことだと思う。

最近、とってもお買い得のホームページを見つけた。SRAの青木氏のページで、「オブジェクト指向システム分析設計入門」という著書がタダで読めてしまう。このオブジェクト指向入門が異常におもしろいのだ！

ただ、仕事の上で必要に迫られたSEが読んで理解できるかどうかはあやしい。オルテガや岸田秀の引用があったりして、かなりマニアックな「入門書」である。それだけに、この「オブジェクト指向入門」は、僕のような衒学趣味の人間にはこたえられない魅力がある。

ところでその第６章に、SEの作業環境に関する記述がある。ほんとうに従来のウォーターフォール型のシステム開発を見直して、オブジェクト指向の開発を進めようと思えば、作業環境から見直さなければいけないという主旨である。

僕の働いているオフィスは、今や大規模事業所では当たり前になった一人一台のPC、８つずつ島になったデスクと、一つだけ独立した課長のデスク、申し訳程度の高さのパーティションと、典型的な日本型レイアウトになっている。これが欧米になると、個々人のデスクも独立して、パーティションも高く、視界があまり利かないようになるのだろう。

青木氏は、この日本型レイアウトと欧米型レイアウトのどちらについても批判的である。では青木氏の提案するレイアウトはどのようなものだろうか？それは、部屋の中央にドカンと会議机があり、壁に向かって作業用のデスクがぐるりと貼りついている。そして驚くべきことに、パソコンラックはキャスター付きで、自由に部屋の中を移動できるようになっている、というものだ。

実は僕の会社にも、これに近いレイアウトになっている部署がある。さすがにキャスター付きラックはないけれど、中央に会議机、周辺にデスク、というレイアウトだ。

僕自身、あるプロジェクト対応で小さなスペースをあてがわれたとき、このような配置にしようと思ったが、上長に、「やっぱり真ん中に島を作るのがいいんじゃない」と言われてあっさり納得してしまった。あのときの僕の感覚はまんざら間違いでもなかったようだ。

中央に会議机を置くのは、言うまでもなくコラボレーションを重視する観点からだろう。これはつまらにことのようだけれど、実は従来のウォーターフォール型のシステム開発体制とは本質的な差異がある。

ウォーターフォール型のシステム開発の背景には、垂直的な機能分化が進んだ組織がある。組織の中の各階層の権限がはっきりと決まっていて、トップダウンにせよ、ボトムアップにせよ、各階層でOKが出なければ、その情報は上にも下にも流れない。

このような組織は、オブジェクト指向開発のような新しいスタイルのシステム開発にとって、２つの理由で具合が悪い。一つは、今言ったように、意思決定が各階層で不連続に行われること。もう一つは、経営的に重要な決定事項と技術的に重要な決定事項が、ごっちゃにされてしまうことである。

まず一点め。意思決定が組織内の各階層で不連続に行われるとは、たとえば担当者レベルでとりあえず話をまとめないと、上長レベルの話しが始まらない、あるいはその逆など、組織階層どうしの意思疎通がいちいち段階を踏まないと行われないような状況を指す。

このような状況は、たしかにウォーターフォール型のシステム開発にはとても都合がいい。組織階層の上位にある人々がまず仕様の概要を決めて、それをブレイクダウンするとともに下位の階層へ落としていく。ここには、システム開発と組織構造のみごとな調和がある。

しかしこのように垂直的な組織で、プロトタイピング手法やスパイラル式の開発体制を作ろうと思うとほとんど不可能である。無理にプロトタイピングをやろうとすると、かなり悲惨なことになる（経験者語る）。

とにかく時間がかかるのだ。担当者レベルでプロトタイプの検証をしてもらってOKが出ても、上長の一言でふりだしにもどる。修正を加えてふたたび担当者に見せるとまた文句が出る。垂直的な組織構造の会社はあまり欲張らずに、旧態依然のウォーターフォールで進めるのがむしろリスクが少ないだろう（そのかわり完成したシステムも硬直的なものになるだろうが）

次に２点め。今述べたことと大いに関係するが、垂直的な機能分化が徹底した組織では、経営的に重要な決定事項と、技術的に重要な決定事項がごっちゃにされてしまう。

たとえばクライアント・サーバシステムを開発することを考えてみよう。メインフレームと違って、C／Sシステムにおいては開発ツールの選定がキーになる。ただ、これは技術的に重要だというだけであって、どのような経営目標のために、どのような機能を実現するかという、経営的に重要な課題とは別に論じられるべきである。

ところが垂直的な組織では、その内容に関わらず「重要なこと」はすべてトップが決める。開発ツールといってもバカにならない金額だから、技術的に重要なことまでトップが決めることになってしまうのだ。

トップが情報システムに精通しており、的確な判断を下せるならまだいいが、仮に間違った選択をしたとすれば、このような組織は後から軌道修正することも難しい。まさにシステム開発は「デス・マーチ（死の行進）」と化す。

以上２点の弊害は、システム開発にとって「環境」がいかに重要であるかを示唆してくれている。ここで「環境」と言うのは、OSの種類やサーバ機のメーカー選定のことではない。企業の組織構造やオフィスのレイアウトといった、もっと広い意味での「環境」である。

システム開発の手法を変革するとは、結局のところ、組織をフラットにし、オフィスのレイアウトを変えるというように、「環境」から手を加えるところから始まるのではないだろうか？今までどおりの垂直的な組織や、「島(平社員)＋孤島(管理者)型」オフィスに、無理やりプロトタイピング手法を接ぎ木しようったって、うまくいくわけがないのだ。