ソフトウェア技術者は工務店か

1991年にリリースされたCMM(能力成熟度モデル)では,ソフトウェア開発のスタートは「要件管理」からでした.ところが,2000年にリリースされたCMMI(能力成熟度モデル統合)では「要件開発」というプロセスが,しかも,エンジニアリングプロセス領域のひとつとして定義されました.
これまで「要求獲得」や「要件定義」という言葉に慣れ親しんだ耳には,要件を開発するという言葉が,若干の違和感を伴って聞こえたのではないでしょうか(「要件は開発するものなの?」,「しかも.私たち開発者が??」).CMMIがリリスースされてからすでに15年以上が経っていますが,要件を開発するというプロセスを,その意図を組み入れ,製品の品質に実際に寄与するように組織やプロジェクトに実装している組織は,まだ多くはないのではないでしょうか.
この要件開発プロセス,最近では,「超上流」と呼ばれたりする場合もあります.ところで,ソフトウェア開発の上流とはどこまでさかのぼることになるのでしょうか.最近では,ソフトウェア開発の周辺でも,「User experience」,「デザイン思考」などの用語が飛び交っています.これまでソフトウェア開発が問題として扱っていなかった領域の考えかたも取り込まなくてはいけないのでしょうか.要件開発に関係する技術を整理する前に,どこからが,もしくはどこまでがソフトウェア技術者の仕事なのかを,家のリフォームを例に眺望してみたいと思います.
実は,仕事の範囲を考えるということは,その仕事の責任と権限に対する権利と義務,つまりソフトウェア技術者の職能とは何かを考えることでもあります.堅い話はとりあえず横に置いて,まずは,リフォームを計画中のA子さんのリフォームのやり取りを覗いてみることにしましょう.

A子さん宅は築20年,新婚のときにご両親から譲り受けました.もともとはご両親が建てた家でしたので,いろいろと不具合があるのか,A子さんはリフォームを計画しているようです.
A子さん宅は築20年,リフォームを計画しているようです.

A子さん:「ここに壁を新しく作ってもらいたいの」

この依頼は誰宛のものでしょうか.
登場したのは地元で信頼の厚い「お任せ工務店」さんです.
ところで,お任せ工務店さんは,A子さんからの依頼を受けてどのように応えるでしょうか.

お任せ工務店:「どこに壁を建てたいのですか」,「壁の素材はどうしますか?」,「壁紙はどれにしますか,それとも,モルタル塗りにしましょうか」

壁を建ててと言われても,どのような壁をどこに立てれば良いか指定がなければ建てられませんね.お任せ工務店さんは,依頼を受けて壁を建てるのが仕事なので具体的な仕様が欲しいようです.

「壁を建てたい」という顧客からの要求は,家の内部仕様に直接かかわるものです.このように,顧客が内部仕様に対する直接的な要求を出して,それを構築側が受ける.構築側は,作るために必要な仕様をもれなく聞き出さなければならないという関係は,システム開発の現場でもよく見られますね.

実装をしなければならないお任せ工務店さんは,顧客から漏れなく内部仕様を聞き出さなければなりません.
ところで,お任せ工務店さんは,具体的な仕様を聞き出していくうちに,どのような疑問を持つでしょうか.

お任せ工務店:「ところで,壁を建てるとこちらの部屋がふさがれてしまいますが,扉を新しくつける必要はありませんか」

新設する壁に関する仕様だけではなく,壁をたてることによって,家の機能も変更を受けるようです.
さらに.お任せ工務店さんは,次のような疑問を持ちました.

お任せ工務店:「ところで,何故,ここに壁を立てるのですか?」

すると,A子さんはこう答えました.

A子さん:「2階の寝室を区切って,独立した2つの部屋として使いたいの」

A子さんは,夫婦それぞれの寝室が欲しいのでしょうか?

この話を聞いたお任せ工務店さんは,壁を建て立てたいというのは,夫婦それぞれの寝室を作るためだということがやっとわかりました.そうなってくると,ただ壁を立てれば良いというものではありません.それぞれの部屋に対して,寝室としての機能を考えていかなければなりません.
お任せ工務店さんは,夫婦それぞれの寝室を作らなければならいないという若干の不安を持ちつつ,別の人を連れてきました.建築士の斎藤さんです.
2階の現在の寝室から夫婦それぞれの寝室を作るにはどうするのが良いのか,寝室としての機能や,家の構造上どのように区切ると良いのか,いきなり壁を建てるのではなく,図面を引く必要が出てきたのです.

建築士斎藤さん:(う〜ん,この8畳間からどうやって2つの寝室を作るといいかな..)

A子さんの「2階の寝室を区切って,独立した2つの部屋として使いたいの」という要求は,「ここに壁をたてる」という内部仕様に対する要求ではなく,家の機能に対する要求です.この要求に応えるためには,設計が必要です.
さて,設計を任された斎藤さんですが,現状の家の図面を手に入れたあと,構造などを考慮しながら寝室を2つ作るプランを練っています.
ところで,斎藤さんはA子さんは設計を進めながら思いました.

建築士斎藤さん:元の寝室はちょうど半分に分ければいいのかなぁ.それにしてもちょっと狭くなるなぁ.入り口はどちら側につけようか.ところで,それぞれの寝室からは音が漏れない方が良いのかなぁ.なんだか心配になってきたぞ…

心配になると仕事が進まなくなる斎藤さん.そこで,思い切ってA子さんに聞いてみました.

建築士斎藤さん:「ご夫婦それぞれの寝室の入り口ですが,できるだけ離した方が良いですか?」

するとA子さんは,2階の寝室を2つに分けたい理由を説明してくれました.

A子さん:「あら.寝室ではなくて,子供達がそれぞれの部屋が欲しいと言っているの」

ああ,そういうことだったのですね.なぜかホッとした斎藤さん.寝室を2つ作るなんて,お任せ工務店さんも早とちりだなぁと気を取り直してA子さん宅の図面を眺めてみると..

建築士斎藤さん:おや?子供達それぞれの部屋というのなら,あまり使われていない1階の客間も利用できそうだけど,そもそも,どんな部屋が欲しいのか,どんな部屋が喜ばれるのか,もっと掘り下げて聞いた方がいいかもしれないなぁ…

そこで,斎藤さんは,同僚の営業部の山田さんに,子供部屋のリフォームプランで最近お客さんに喜ばれているアイディアがどのようなものか相談しました.

ところで,これまで,A子さんから語られていた要求の主体は「家」でした.ここに来てはじめて,利用する「人」が主体に切り替わったことに気がつきましたか.
このように,A子さんの「子供達がそれぞれの部屋が欲しいと言っているの」という要求は,顧客が主体の要求です.それに対して斎藤さんが提案するのは,家が主体の要件です.斎藤さんの仕事は,顧客主体の要求を家が主体の要件へと定義し直すことです.

斎藤さんは顧客が主体の要件を解釈して,家(システム)が主体の要件を定義して顧客に提案します.

1階の客間は普段あまり利用されていないようです.このアイディアは,2階の夫婦の寝室を分けてしまうよりも良いかもしれません.しかし,1階の客間は6畳とさらに狭いですし,そもそも和室なので,床の張り替えなどコストもかかりそうです.
良い提案だと思ったのですが,またしてもちょっと心配になった斎藤さん,部屋の広さも気になるので,聞いてみました.

建築士斎藤さん「ところで,お子さん方は何歳ですか?」
A子さん「8歳と5歳の女の子です」

建築士斎藤さん:え? 8歳と5歳で独立した部屋が欲しいのかな?

そもそも部屋を区切る必要があるのか,根本的なところで疑問に思った斎藤さん,今度は同僚のプランナーの吉田さんと森下さんに相談しました.

建築士斎藤さん「A子さん宅のリフォームで,8歳と5歳のお嬢さんたちの独立した部屋を作りたいと言われているのですが,そんなに小さなお子さんなのに部屋を区切って喜ばれるのですかね」
吉田さん「まずは,その8歳と5歳のお嬢さん自身が,何を望んでいるのかを聞いたほうがいいわよ」

そうですね,実際の顧客は8歳と5歳のお嬢さんたちです.彼女らが何を望んでいるかを聞いたほうが良いかもしれません.吉田さんは,お嬢さんたちの1日の生活の視点から彼女らが何をなぜ望んでいるのかを理解すると良いとアドバイスをくれました.
その結果,「別々の部屋が欲しい」という要求は8歳のお姉さんからの要求だということ.そして,8歳のお子さんは読書が大好きで,学校の図書館から借りてきた本を帰宅してから読もうと楽しみにしているのだが,お姉さんの帰りを待ち構えている妹にいつも邪魔されて本が読めないということ.妹とも遊びたいが,1時間程度で良いので,妹に邪魔されずに本を読みたいというのが望んでいることだということがわかりました.

お姉さんは,1時間程度で良いので,妹に邪魔されずに本を読みたいだけだったのです.

ああ,それだったら..
結局,2階には壁を立てずに(もちろん,夫婦の寝室を2つに分けずに)問題は解決したようです.

ソフトウェア工学の歴史がはじまってから(つまり,ソフトウェアを作るということに関しての共通的な法則性が意識されて以来),多くのソフトウェアプロジェクトは,顧客の”要求通りに”「壁」を建てて失敗してきました.
2009年にStandish Groupから出されたCHAOS Report(定期的にソフトウェア開発プロジェクトに関する統計を取り分析している米国の大学を中心とした研究組織)では,ソフトウェア開発プロジェクトの68%が失敗に終わっているという結果が出ていました.この68%と言う数値は,大まかに言って,ソフトウェア工学の歴史がはじまった70年代から変わっていません.上流工程では,重要な部分の何かがかけちがったままなのかもしれません.その視点の一つが,もしかすると,職能,つまり,優秀な工務店であることを目的として意識していることかもしれません.
一方で,昨今よく耳にする「デザイン思考」は,デザイナーの活動を経験的に捉えたもので,工学としては,現象論的な段階であると言えます.ソフトウェア工学での上流工程をさらに一歩進め,その本質をつかむには,上流工程自体を実体論的に理解すること,つまり,上流工程の活動(生産的活動として捉えた場合のソフトウェ開発の上流工程)のモデル化がまずは必要だと考えています.ヒントは「脳と現実世界」のあたりかも..