« 部門と従業員のデータモデリング | トップページ

2019.06.04

骨格→筋肉→皮膚の順序で仕様を決めよう

■何を先に決めるべきか

 動物の動きをリアルに再現するロボットを作ることになったとしよう。その動物は顧客がイメージしている想像上の生き物なのだが、顧客は忙しくて一度だけしか打ち合わせできないとしよう。また納期の関係から、打ち合わせ結果にもとづいてさっそく製作を始めなければいけないとしよう。

 顧客と打ち合わせるべきテーマとして、その一風変わった動物(内骨格動物とする)の「骨格」と「筋肉のつき方」と「皮膚の形状」のどれが優先されるべきだろう。言うまでもなく「骨格」である。なぜなら骨格さえ決まれば基本的な体形や動作様式が決まるので、筋肉のつき方は製作者側で補完可能だからだ。皮膚の形状についてはもっと気楽に考えていい。後から皮膚の形状を微調整することが難しくないからだ。

 このように、よほど単純な製作課題でない限り「全体の仕様決定に関する適切な順序」がある。その順序に従わないと、奇妙なシロモノが出来上がったり、何度も作り替えるうちに納期に間に合わなくなったりする。全体仕様を同時に構想すればよいと思われるかもしれないが、複雑な課題でそれをやれるのは一部の天才だけだ。

 この主張に対して、「実際には骨格→筋肉→皮膚→骨格→筋肉→皮膚→…とぐるぐる繰り返されるので、何を起点にするかは事実上問題にならない」という反論があるかもしれない。しかしこれは「ドラマーの叩くフレーズはベードラとスネアがぐるぐる繰り返されるだけなので、どちらが先かは事実上問題にならない」と言い張るようなものだ。

 ドラマーにとって1小節の繰り返しパターンが何から始まるかは決定的に重要で、サイクリックに繰り返すからといって音の順序がどうでもいいということにはならない。別の例で喩えるなら、ボクサーが連打する際には「肩→腕→手首→拳」の順序で力が加えられ、高速に繰り返される。力の起点は常に肩(を含めた体幹)であるが、それを繰り返したからといって「どこが起点になるかは事実上問題にならない」とはいえない。

■業務システムの骨格は何か

 業務システムにおいても「骨格、筋肉、皮膚」に相当する構成要素があるし、「骨格→筋肉→皮膚」を1セットとする「小節感」や「力の伝わり方のまとまり」に相当する「仕様決めの順序」がある。すなわち、骨格は「DB構造」、筋肉は「業務体制」、皮膚は「UI(パネルや帳票のデザイン)」である。なぜDB構造を骨格とみなせるのか。システムの基本的な動作様式を規定する、言い換えれば、他の要素のあり方に対して比較的に強い制約を与えるゆえだ。また、後になって変更するにはコストがかかりすぎるゆえでもある。

 しかし、全身骨格だけでは動かないので筋肉が要る。業務システムに動きを与えるのはユーザの業務体制だ。しかしDB構造にもとづいてユーザの役割や仕事の連係様式が決まったとしても、彼らにコマンドプロンプト上でSQLを叩いてデータ操作させるのは気の毒だ。ゆえにDBと業務を遂行するユーザとの間に、気の利いたUIを入出力してくれるアプリを置かねばならない。それらの仕様が「皮膚の形状」である。なお、DB構造と業務体制が決まれば、それらの板挟みになっている「あるべきUI」は限定的なパターンに収まる。

 この説明にはそれなりの納得感があるとは思うが、現実の仕様策定の過程はほぼ逆転している。UIのデザイン(皮膚の形状)と業務フロー(筋肉のつき方)を先行してまとめ、後でDB構造(骨格)のつじつまを合わせるやり方が優勢だ。しかもふつうはこの1回のサイクルで出来上がった仕様にもとづいて実物を作ろうとする(ウォーターフォール方式)ので、どんなに残業してがんばってもうまくいかない。なぜなら、「DB構造→業務体制→UI」の1サイクルでいきなり素晴らしい仕様を生み出せるほど、我々は優秀ではないからだ。したがって、各サイクル毎に動作するシステム(プロトタイプ)を高速に生み出せるような開発体制が欠かせない。実際の動きを確認しない限り、仕様など絵に描いた餅でしかないからだ。

 なお最近では、腕、頭、脚のようにパーツ毎にプロトタイピングするやり方(アジャイル方式)が注目されているが、これも期待し過ぎるべきではない。なぜなら、業務システムの特徴のひとつが「複雑なDB構造を伴う」という点であり、パーツ毎に仕様を決めるやり方ではDB構造の広域な整合性が保証されないからだ。

 UIや業務体制の検討を先行させるやり方でのとくに見逃せない問題が、刷新されるべき「使いにくく保守しにくい現行システムの仕様」が温存されやすい点だ。開始時点で参照できるUIや業務体制は、現行のシステム仕様に準拠して出来上がっているものだからだ。DB構造だろうが業務体制だろうがUIだろうが、現行仕様を起点にして設計すれば、生み出されるものは限りなく「新築そっくりさん」に近くなる。

 当初から「新築そっくりさん」を意図したプロジェクトであればそれでもかまわないと思われるかもしれないが、そもそも現行踏襲にこだわる開発方針には問題が多い。現行のUIや業務体制が再現されて喜ぶのは古参ユーザだけだからだ。何度刷新しても旧システムの仕様が温存されるとしたら、ユーザの新陳代謝(若返り)が起こりにくい。事業環境の変化に追随しつつも、「誰にでも使える形」に進化してゆくことで、特定ユーザによる業務独占やワンオペの弊害を防げるし、ユーザの少数精鋭化も図れる。あまり話題にされることはないが、多くの日本企業では古参ユーザが、システムが発展・変化してゆくための障害になっている。

■「あるべき骨格」の手がかりはどこにある?

 そこらへんを踏まえ、システム仕様を刷新したいと本気で望むのであれば、「システムの骨格」であるDB構造全体の刷新から始めなければならない。ただし、あるべきDB構造を構想するための手がかりは「現行システムの仕様」の中ではなく、「顧客の思い」の中に不定形に存在する。ゆえにデータモデルは、顧客のカジュアルな語りにもとづいて構想されなければならない。その過程で現行仕様を部分的に参照する必要もあるだろうが、現行仕様が「発想の起点」になることはない(なるべきではない)。そのような過程は初心者には魔法のように見えるかもしれないが、DB設計を堅実に学んで実践を重ねるうちにやれるようになる。

 ではなぜそのやり方が主流になっていないのだろう。根本的な原因は、業務システム開発を専業とする企業自身が、システム設計を「マニュアルにしたがって誰でもやれる簡単なお仕事」と侮っている点にあるのではないか。マニュアルにしたがってやれるのであれば特別な訓練は要らないので、いろいろと都合が良くもある。じっさい彼らの開発標準には、現行のUIから項目名を丹念に拾い上げ、あるべきテーブル構造に再編成するためのもっともらしい手順が示されている。しかしそれは「ゴチャゴチャと建て増しされた温泉旅館の仕様を緻密に調べ、要素に分解してExcelあたりで整理することで、今風のリゾートホテルのデザインが見えてくる」と主張するようなもので、よほどの天才でない限りやれることではない。

 われわれのような凡人が実践できそうにないにも関わらず、なぜそのやり方が主流なのか。「まずUIを見て、それからDBの対象部分を理解する」という新人時代のナイーブな仕様の理解様式が、システムの設計手順として無批判に敷衍されてしまっているためではないか。出来合いの仕様を理解する過程と、仕様を創造する過程とは異なっていて当たり前で、後者の場面に前者の思考様式を適用してうまくいくはずがない。必然的にプロジェクトの創造性が希薄になってゆく。つまり、現行のUIと現行のDB構造が踏襲され、いつもの新築そっくりさんが生み出される。

 まとめよう。複雑な製作物の設計において「どの要素の仕様から決めるか」は決定的な問題だ。業務システムはそのような製作物のひとつで、あるべきシステムの仕様は「あるべきDB構造」を起点として生み出されなければいけない。ただしそれは、現行のUIや業務体制をどんなに緻密に分析しても見えてこない。手がかりは「あるべきシステムに関する顧客の思い」の中にある。対話によってそれを聞き出して図面化する創造的過程、それがDB設計である。


【「モデリングライブ@大阪」のお知らせ】
会場で開発課題を募って多数決で決め、顧客(課題提案者)の語りにもとづいてDB構造を30分でモデル化し、90分でシステムを実装してデモする。UIを知らなくてもDB設計が可能であること、また、まともな骨格(DB構造)さえ決まればシステムの実装は拍子抜けするほど簡単であること――これらの事実を示すための衝撃的イベントが、いよいよ大阪で開催されます。業務システム開発に携わる技術者だけでなく、現行システムの刷新を画策している企業関係者の方々もお見逃しなく。

日時:2019/07/06(土)
場所:大阪京橋オプステージ4F会議室
特別講演:中山嘉之氏「真っ当なデータモデルとデータHUB」
参加費:無料(定員40名)
詳細と申込みはこちら

|

« 部門と従業員のデータモデリング | トップページ

コメント

「モデリングライブ@大阪」について質問です。
参加する場合ですが、服装のNGとかはあるでしょうか。
例えば、Tシャツ、ジーパン、ハーフパンツはダメなど。

投稿: veerwest | 2019.06.28 15:52

カジュアルスタイルでけっこうです。私は発表者のひとりなのでジャケットは着ますが、下はジーンズです。楽しみですね。

投稿: わたなべ | 2019.06.28 19:53

コメントを書く



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




« 部門と従業員のデータモデリング | トップページ