パターンと生きたプロセス：ソフトウェア開発をちゃんと考える（6）

» 2006年07月12日 12時00分 公開
[山田正樹，メタボリックス]

前回「自然言語としてのパターン」ではアレグザンダーのパターン本の中から「時を超えた建設の道」を読んだ。続く「パタン・ランゲージ」は、「時を超えた建設の道」を具体的に建物のパターン・ランゲージに応用したパターン集で、ソフトウェアには直接関係しないので、今回は触れない（が、これはこれで大変面白い。自分で自宅なりオフィスなりを造るようなことがあれば、といろいろ考えさせられる）。今回読むのは「パタンランゲージによる住宅の建設」である。本書はシリーズのほかの巻に比べると、よりプロセスに重点が置かれている。

　本書は1975年から、メキシコ・メキシカリ市でバハ・カリフォルニア州政府のプロジェクトとして、30戸の住宅の設計施工を行ったときの記録である。そこでは次の7つの原則が用いられた。それぞれの後ろにその原則の意味をわれわれの言葉で簡単にいい換えてまとめてある。

  • アーキテクト・ビルダー
    「設計をする人と実際にモノを作る人が別々であってはいけない」
  • ビルダーズ・ヤード
    「モノを作る人は実際にモノが使われる現場でモノ作りをすべきだ」
  • 共有地の共同設計
    「システムの共通／共有部分は実際にそれらを使う人たちが設計に関わる」
  • 個々の住宅のレイアウト
    「個々の機能（アプリケーション）は実際にそれを使う人が設計に関わる」
  • 一歩一歩の施工
    「個々の機能（アプリケーション）は市販部品の組み合わせではなく、1つ1つを作り込んでいく」
  • コスト・コントロール
    「コストはプロセスの進ちょくに従って常に見積もりと比較し、修正していく」
  • プロセスの人間的なリズム

1.人は毎日、一定の時間、一緒に働く

2.各機能のユーザーは、少なくとも何らかの具体的な作業に携わる

3.毎日、何かが明確に達成されるようにする

4.大きな作業の中では、みんながお互いに助け合う

5.作業が1つ終わるごとに、祝杯を挙げる

　これを見てeXtreme ProgrammingのプラクティスやScrumのパターン言語を思い起こす人もいるだろう。たぶんそのとおり、この7つの原則はアジャイル・プロセスのプラクティスにも大きな影響を与えている。

　ただし、これは建築のプロジェクトであって、ソフトウェアのプロジェクトではない。特にこれは住宅の建設であって、このプロジェクトの場合には住む人々自身が設計施工の過程に直接的にかかわったものである。そんなソフトウェアから遠く離れた（と思える）モノ作りの、それも30年前の一事例の原則を、いまのわれわれの仕事に当てはめていいものだろうか？ そんなことに意味はあるのだろうか？

　例えば、いまあなたが中規模の会社の基幹システム新規開発を始めるところだとしよう。まぁ十中八九、こういう光景が繰り広げられるのではないかと思う。

　実際にシステムを使うユーザーは、最初はしつこくインタビューされるけれど、その後はシステム移行のトレーニングが始まるまで放っておかれる。その間、開発チームが話をするのはよくてユーザー企業のシステム部門担当者か、下手をすれば間に入っているSIerだけ。システムはアーキテクトがばりばりに設計してくれ、PMP資格を持ったプロジェクト・マネージャがばりばりに見積もりとプロジェクト計画を立ててくれる。その設計を見積もりどおり、計画どおりに実装するのは、このユーザー企業のことなどほとんど知らない、下請けか派遣プログラマか、もしかしたら中国やインドの誰か。重要なのは、設計どおりに実装し、計画どおりに進ちょくさせること。

　出来上がったモノを日々使うことになるユーザーは、毎日生き生きと仕事をすることができるだろうか？ いままでの経験からいって、それはかなり怪しいと思う。ここでいっているのは表面的なユーザービリティのことだけではない。もっと深い何か、でもユーザーには誰でも分かっている何かのことだ。

　これは基幹システムであって、住宅じゃないから仕方がないというかもしれない。しかし住宅だってこんな造られ方をすることが当たり前というわけではないのだ。アレグザンダーはいう。

「今日あるような狭い建築の見方に固執してしまい、新しい生産プロセスが今こそ生み出されるべきでありその可能性があるということも理解せずにいるのかもしれません」（p.12）

「現在私たちが使っている生産システムでは、物事をじっくりと適正なものにすることが難しいようなコントロール形式ができあがっているのです。というのは、ほとんど例外なく決定は誤ったところ、つまりそれが影響を与える直接具体的な場所とは離れたレベルでなされるからです」（p.37）

　実はシステム開発でも「ユーザー参加」というキーワードは語られてきている。本書とほぼ同時期（1970年代）から北欧を中心として協調型設計（Cooperative Design）、その後北米にわたり参加型設計（Participatory Design）、ユーザー中心型設計（User-Centered Design）などが提唱されている。JAD（Joint Application Development）という開発手法もある。JADは後にRAD（Rapid Application Development）やアジャイル・プロセスの1つである適応型ソフトウェア開発などへとつながっていく。

　まず、ユーザー企業の情報システム部門の人たちに前面から退いてもらうことは可能だろうか？ ユーザーの思いを最初にゆがめるのはまず彼らだから。ユーザーに毎日一定時間、システム開発に参加してもらうことはできるだろうか？ ユーザーにシステムのことなんか分かりっこないという心配はあまりしなくてもいいような気がする。

　彼らは既存システムに足りないところを Excelやら、Webやら、人の頭やらを使って（われわれよりずっと）賢く解決しているコトがよくあるのだから。練り込まれたデータベース・スキーマやガントチャートなしで開発を始めることができるだろうか？ なおかつ予算の範囲内で、本当のユーザーが使えるもの、これから10年、20年と使い続けられるものができるだろうか？ 別にシステムを一度に全部作り直す必要はないのかもしれない。まずある部署の1つの機能を実現してみるのに、それほど大それたプロジェクトや億単位の資金はなくてもいいだろう。

　最後にアレグザンダーがこのメキシコでのプロジェクトで取った興味深いやり方を1つ紹介しておこう。普通、建物を建てるのには建築基準法にのっとった認可を得る必要がある。もちろん認可を得るためには図面の作成などに多くの時間とコストが必要で、なおかつエンド・ユーザー（つまりその家に住む人）ではなく専門家が必要になる。一度認可を得たら、その設計を現場で変更するわけにはいかない。それらの過程で多くのユーザーの思いがうやむやになっていく。しかしアレグザンダーは図面を1枚も描かなかった。彼は自治体と交渉して、認可を個々の建物の設計に対してではなく、建築の「プロセス」に対して得られるようにしたのである。つまり（最低限の条件を除けば）結果としてどんな建物ができようが、それが前もって提出した、きちんとした作業手順に従って建設されてさえいればいいのである。

　これはわれわれにとっても非常に参考になるのではないだろうか。ソフトウェア開発では｢何を作るか」を基準にしたスコープ・ベースの開発契約が大きな問題を起こしている。アジャイル・プロセスでは時間枠を基準にした契約を推奨するけれども、それは発注者／受注者間の信頼関係に依存したものになりがちで、なかなか社会的に受け入れられていない。しかし、ユーザー参加とプロセスを基準にした契約は双方にとって利益のある契約形態になる可能性があると思われる。

「ソフトウェア開発をちゃんと考える」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ