自社ビルを建てることになって、あなたは責任者として打ち合わせに参加した。そこで建築業者がこのように提案してきたらどうだろう。「より満足していただくために、御社のビジネスを分析させてください。ビルのデザインには御社のビジネスが反映されるものだからです」わからないではないが、なんとなく違和感がないだろうか。
自社ビル建設ではなく、業務システムの開発・刷新だとしたらどうか。「業務システムのデザインには御社のビジネスが反映されるものです」と言われたら、まあそれはそうだと思える。少なくとも自社ビルよりも施主のビジネスが色濃く反映されそうだ。しかしだからといって、仕様策定がビジネス分析から始まるとしたらやはり違和感がある。大袈裟すぎるというか、まあ意味がないとは言わないが、顧客も業者もどれだけ暇人なのかとつっこみたくなる。
自社ビルや注文住宅の建設でも、業務システムの開発・刷新でも、プロの業者と素人の施主とが了解し合えるインタフェースは「作られるもののイメージ」である。それさえ明確にすればよいだけの話で、そのためにビジネスだの経営姿勢だの組織体制だの人生観だの信条や趣味だのをこまごまと分析する必要が果たしてあるのか。
ここでの問題は、じつは業者側のスキルレベルにある。
まともな建築士であれば、予算や居住人数等のざっくりした条件にしたがって、ビルや住宅のさまざまなデザイン候補を提示するものだ。施主はそれらのどれかを選ぶか、複数の候補の特徴を組み合わせたデザインを要請すればよい。施主の思いや社会的立場を詳しく分析しないと設計できない、などと言ってくる建築士はなんだか頼りない。
業務システム開発でも同じことだ。本来であれば、顧客の断片的な要望にもとづいて、業者はさまざまなアイデアを提示すべきである。顧客はそれらを手がかりにして、システムのイメージを具体化していけばいい。事前に求められる要望は、最初は素人なりの観念的な箇条書きでじゅうぶん。業者からのフィードバックによって詳細なものに方向づけされていくからだ。ビジネスや組織のあり方や現行システムを事前に分析しないと設計できない、などと言ってくる業者はなんだか頼りない。
じっさいのところ多くのシステムベンダーは、ビジネス分析を含む「超上流工程」にご執心で、ビジネス戦略コンサルと区別出来ないほどだ。その原因として、彼らが生み出すシステム仕様についての不全感を覚えているからではないか。「われわれのプロジェクトがなかなかうまくいかないのは、顧客のビジネスについての理解が不足しているからだ。上流工程だけでは十分ではない。超上流工程に関わるべきなのだ」――そのように考えている節がある。
噴飯ものだ。彼らに不足しているものは、顧客に関するより詳しい情報などではない。顧客の曖昧かつ漠然とした語りを手掛かりにして、いくつもの具体的かつ工学的なアイデアを瞬時に生み出して返すためのスキルや知見や想像力である。アイデアが次々にフィードバックされることで、顧客はようやく自分たちが欲しかったものを回顧的に「要件定義」できる。専門家からの適切なフィードバックがなければ、システム仕様は現状と変わり映えのしない「ピカピカの竪穴式住居」に陥るしかない。
ただし、顧客に対してフィードバックされるアイデアは彼らにとって扱いやすいものでなければならない。キングファイルで綴じられた膨大なドキュメントなんかではぜんぜんダメ。ベンダーは「情報システムというものは複雑なので、これらを理解してもらわないと、開発されるものの仕様を確認したとはいえませんよ」と説明するかもしれない。しかしそれは、建築案件の施主にボルトの位置や鉄筋の本数を図面上で検収してもらうような独善でしかない。プロとして責任を持つべき専門的配慮までを素人の検収にまかせているようであれば、独善どころか職業倫理に反している。
では、業務システムに関してフィードバックされるアイデアはどのような形式であるべきか。「論理データモデルとこれを基礎とするプロトタイプ・システム」が最強だと私は考えているが、ここでは詳しく述べない。
少なくとも、アジャイル手法の信奉者が大好きなデジタル紙芝居のようなしろものでは、高度専門性に裏打ちされた適切なフィードバックとはみなせない。なぜなら、システムのふるまいを支える「広域データベース構造の考案」という最重要かつ最難関の課題をスキップできてしまうからだ。ようするにデジタル紙芝居は「構造計算されていない高層ビルの美麗なイラスト」のようなもので、そんなビルに誰も住みたいと思わないし、そもそも施工中に倒壊するだろう。
いずれにせよ、建築士やシステム開発者を含めたクリエイト系の高度専門職は、顧客と分かり合うために「字面のやりとり」を延々と繰り返すのではなく、高度専門性に裏打ちされた「生み出すべきモノ」の具体的かつ多彩な選択肢を、ごく初期段階から提示しなければならない。
映画音楽の作曲家は監督のカジュアルな語りにもとづいて、ピアノやDAWを駆使しながら楽曲の断片を次々に提示する。そのために「登場人物分析」だの「脚本分析」だのを手間暇かけてやるほど暇人ではない。そして彼らは具体的な楽曲をインタフェースとして、映画監督と音楽家という異なる専門家同士でわかり合えることを知っている。売れっ子の映画音楽家は言うだろう。「なぜこの曲にしたかって？ いろいろ提示したら監督がなんや知らんけどこれがいいと言ったからさ。どんなシーンにあてるかって？それは知らないな。監督に訊いてくれ」
我々は顧客とは異なる専門分野の住民である。我々にはシステム開発のプロとして「顧客と分かり合うための狭隘なインタフェース」を高速かつ大量にフィードバックする責任がある。システム仕様に顧客のビジネスが反映されるのはそういったやりとりの「結果」であって、そのために事前にビジネス分析が必要ということにはならない。言い換えれば、ビジネスや組織といった顧客自身に関するこまごまとした分析が必要と思えるようなら、高度専門職としてのスキル不足を自覚すべきだ。
そういうわけで、ビジネス分析を含めた「超上流工程」をやりたがるシステムベンダーには気をつけたほうがいい。無能であるか、大袈裟な要件定義書の作成で余分に稼ごうとしているかのどちらかだ。
