« データモデリングの達人技を盗め、温泉で | トップページ | 「わかりやすさへのこだわり」があるか »

2017.09.28

システム設計と創造性

 これまでさまざまな開発プロジェクトを脇から見てきたのだが、ありがちなパターンとして「分析・設計工程に想定以上の時間がかかってしまって、実装工程の時間が短縮される」というのがある。ほとんどのプロジェクトがこのパターンに陥ると言えるほどに頻発している。

 べつに担当者がサボっているわけではない。遅くまで残業してがんばっていたりするのだが、出来上がる成果物はひどく心もとない。では何を熱心にやっているかというと、関係者へのヒアリングと、旧システムの仕様分析である。それの何が問題かというと、「創造的要素」が希薄な点だ。「分析ばかりに夢中になって、設計がほとんどなされていない」と言い換えてもいい。

 これに関して私が以前から疑問だったのは、「問題モデル(分析モデル)」と「解決モデル(設計モデル)」とが連続しているような言い方だ。問題モデルを誠実にまとめれば、そこから解決モデルを導出できる――これは信念ではあっても真理ではない。両者の間には絶望的なギャップがある。

 その勘違いを助長したのが、いわゆる「ボトムアップ開発技法」だった。まず「AsIs(現状)」を調査・分析して、それにユーザの不満や経営者の要望を加味して「ToBe(あるべき姿)」を生み出す、という考え方で、90年代にシステム開発プロセスの基本スタイルとして定着した。

 そのやり方にはいろいろな弊害があったが、最大の問題は、設計者に「創造性」を求めなかった点だった。手順に従って地道にやれば効果的なToBeが生み出されるように思えるものだから、システム設計が「タテのものをヨコにするだけの簡単なお仕事」とみなされてしまった。じっさい、「最新の建築資材を使った竪穴式住居」のようなシステムがそこらじゅうで生み出された。せいぜい、ユーザの個別の不満に反応した「雨どい付竪穴式住居」を生み出す程度で設計者は満足してしまった。

 「ボトムアップ開発技法」を含めた「開発方法論」は、複雑かつ困難な設計過程を機械的手順に還元するためにあると考えられがちだが、それほど単純なものではない。機械的手順を部分的には示すにせよ、「ここから先は専門職として求められる職業適性の問題」という絶対領域を明らかにするという大事な役割がある。

 ミュージシャンとして飯を食ってゆくためには「人並みでない音楽的感性」が要る。リズム感や音程感覚が鈍ければプロとしてやっていくのは難しい。同様に、システム開発者として飯を食ってゆくためにも、ある種の「人並みでない職業適性」が要る。それを明確にしないまま、誰にでもやれそうな手順として見せかけようとする「開発方法論」を信用してはいけない。適性に欠けた要員がプロジェクトに闖入(ちんにゅう)することを許すからだ。これは非常に困る。あなたがスタジオミュージシャンの現場で収録に関わろうとすればまわりがどんなに困るかを想像してみてほしい。

 システム設計者に求められる「人並みでない職業適性」がどういうものかはさておいて、音楽活動や建築設計に求められる程度の「創造性」が求められることは明白なのである。じっさい、問題モデルに対応する解決モデルを生み出すには、両者のギャップを越えるための「創造的飛躍」が要る。「施主から聞き出した要望」から「施主が満足できる建築物のデザイン」を論理的に導き出すことが不可能であることを考えれば当然のことだ。

 しかし「創造的飛躍」ではわかりにくい。具体的にどうすればよいかというと、まずは「システムが扱う現実の全体をぼやーっと理解する」ことを目指せばよい。ただし、無駄に時間をとられるだけなので、細かいところまで理解する必要も資料化する必要もない。続いて、その現実を効果的に管理するためのDB構造をぼやーっとイメージして、手早くモデル化する。「ぼやーっとイメージする」なんて聞くと簡単そうだが、その過程で専門知識や経験が参照されるだけでなく、「前頭前野」が活発に働くことになる。創造の源と言われる中枢だ。

 もちろん、それで終わりではない。なにしろ、理解された現実と構想されたモデルとの間に論理的なつながりはないので、そのモデルが的確かどうかわからない。それゆえに、モデルにもとづいてシステムのプロトタイプを作らねばならない(*1)。旧システム上のデータをプロトタイプに流し込んで動かしてみるためだ。その動きやデータの見え方について、「現実」に精通しているユーザが納得すれば、基礎となったモデルの的確さを予想できる。変なアイデアも出てきて何度も却下されるだろうが、変なアイデアが出てくるくらいでないと「創造的飛躍」が起こっているとはいえない。

 「ボトムアップ」でも「トップダウン」でもない、分析的理解と創造が交錯する「仮説検証の高速リピート」でしか、効果的なシステム仕様は手に入らない。これが、この仕事に30年関わってたどりついた私なりの結論である。「コツコツと地道にやれば物事はうまくいく」といった信念は、ことシステム設計に関してたいして役に立たないどころか弊害さえもたらす。設計者には「創造する覚悟」が求められる。

 そして私は切ない気分で思うのだが、前頭前野を駆使する活動に普段から慣れ親しんでいないと、この仕事は務まらないような気がする。「分析的知性」だけでなく、余計(?)な「創造的知性」まで求められる。下手に手を出せば、担当者の創造性の欠如が露わにされた形で「雨どい付竪穴式住居」が生み出される。かくのごとくシステム設計は、責任重大かつものすごく恥ずかしい仕事だ。


*1.これが可能なのは、データベース構造が決まれば、それを処理するUI構成がほぼ決まるからだ。ただしその逆は成り立たない。いくらUI構成を緻密にまとめても、対応するデータベース構造は収束しない。多くのプロジェクトがUI構成をまとめることを優先させて失敗するのはそのためだ。DOA(データ指向アプローチ)が見い出した重要な原則である。

|

« データモデリングの達人技を盗め、温泉で | トップページ | 「わかりやすさへのこだわり」があるか »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: システム設計と創造性:

« データモデリングの達人技を盗め、温泉で | トップページ | 「わかりやすさへのこだわり」があるか »