「As-is先行」か「To-be先行」か

前回、ＤＯＡとＯＯＡとの対立の話を書いたが、ＤＯＡとて一枚岩ではなく、いろいろな考え方をする人たちがいる。だから、筆者も参加している「ＤＯＡ＋コンソーシアム」の集まりは、椿正明博士や佐藤正美氏といった歴々の方法論者や、商売上競合しそうな営業担当者同士が呉越同舟で語り合うという、奇跡のような企画である。参加者の考え方の違いは想像以上で、「どうも偶然にも、我々は全員『ＤＯＡ＋コンソーシアム』という集まりに名を連ねているらしい。一致点が見つかってよかったなあ」なんて冗談が出るほどだ。それほどに違いを楽しめるというのも、本質的な部分が共通している余裕ゆえなのだろう。

ＤＯＡの中でも議論になりやすいのが、「現状分析と基本設計のどっちを先にやるべきか」という問題だ。その前後関係が分析・設計手法の前提をまったく変えてしまうからだ。まあ、けっきょくは「個別の案件毎に特性が違うから、どっちが正しいとはいえない」なんて面白みのない結論にたどり着いてしまうのだが、論者のシステム観がよくわかって面白いネタだ。

じつは最近まで、現状分析は基本設計に先行してなされるのが当たり前と思われていた。企業システムに限らず何かを改善するためには、とりあえずその現状を理解しなければ何も始まらない。そのように考えれば、現状分析を先行させるのがごくまっとうなやり方で、議論の余地なんてなさそうにも思える。

ところがどうもそうとは限らないのが、システム開発の一筋縄でいかないところだ。筆者自身は「現状分析は基本設計の『後』で実施すべし」の側に立つ（少数派である）が、これを敢然と主張するようになったのは、あるプロジェクトの顛末を身近で見たことがきっかけだった。それは「構造化分析設計手法（SA/SD, Structured Analysis/ Structured Design）」の方法論にもとづいて実施されていた大規模プロジェクトだった。

◆構造化分析設計手法の問題

ＳＡ／ＳＤは、「熊とワルツを」等の著作で有名なトム・デマルコらによって提唱され、８０年代から９０年代初頭にかけて流行した開発手法である。大きな特徴は「現状(As-is)を詳細に調べて抽象化すれば、あるべき姿(To-be)が導き出される」という信念にもとづいている点だ。まず、(1)現在の物理構造を調べ上げ、そこから(2)現在の論理構造を抽出する。次に(3)現在の論理構造から「あるべき論理構造」を洞察する。さらに(4)「あるべき論理構造」から「あるべき物理構造」を導く、というやり方をとる。

具体的には、(1)～(4)のそれぞれの段階でＤＦＤ(Data Flow Diagram)を作成する。それらの成果物は順に「現物理フロー」、「現論理フロー」、「新論理フロー」、「新物理フロー」と呼ばれる。これらの成果物は厳密に層別化（レベリング）されていて、最上位の図面は「コンテキストダイアグラム」と呼ばれ、最下位の図面（プログラムに相当するプロセスの内部を表す）は「ミニスペック」と呼ばれる。これらのドキュメントが完成したなら、「新物理フロー」の「ミニスペック」にもとづいて詳細設計がなされ、実装され、システムは完成する。

(2)現論理フロー　→　(3)新論理フロー
　　↑　　　　　　　　　　　↓
(1)現物理フロー　　　(4)新物理フロー

このやり方をとるのであれば当然なのだが、実際に作成した図面を見せてもらったとき、なによりもその「量」に圧倒された。各レベルのフローにプロセスが平均４つ並んでいるとして、レベル０から４まで階層化するとしたら合計３４１(=1+4+16+64+256)枚の図面が描かれることになる。しかも、これらを「現物理フロー」、「現論理フロー」、「新論理フロー」、「新物理フロー」の４セットぶん作らねばならない。「ＤＦＤはもう見たくない」とうんざりしていた友人の顔を思い出す。

図面の枚数が多くても、それが良い結果を生み出すのであればかまわない。機械的な作業の積み重ねで困難な課題を解決できるとしたら、それこそ方法論の真骨頂だ。しかし、ＳＡ／ＳＤはそうではなかった。決定的な問題は、上述した「現状(As-is)を詳細に調べて抽象化すれば、あるべき姿(To-be)が導き出される」の信念に合理的な根拠がなかった点だ。要するに「現論理」から「新論理」を導き出すなど、どう考えても無理なのである。もしそれが可能だとしたら、現行システムは改修の必要のないほどに洗練されているはずだ。なんという矛盾だろう。

ＳＡ／ＳＤは一時代を画したといっていいほど流行したが、ものすごく手間がかかるわりに成功事例が少ないことから急速に廃れた。（余談だが、ＳＡ／ＳＤは日本ではなぜか「ＤＯＡ」の呼び名で実施されたため、ＤＯＡと聞くと「ああ、あのＤＦＤを山ほど書くやり方ね」と応える人が今でもいて困る。ＳＡ／ＳＤはＤＯＡとは関係ない。それどころかデータ中心とは正反対のプロセス中心型のアプローチだ）

◆現行システムは「企業の強み」と「市場の制約」の鉱脈

筆者はそれまでも、不毛と思えるくらいに現状分析に時間をかけるやり方に疑問を感じていたので、ＳＡ／ＳＤのやり方を身近で見た経験は強烈だった。それで、あっという間に「現状分析不要」の過激派に走ってしまったのだが、ほどなくそれも間違いであることに気づいた。

現行システム（コンピュータを使っているとは限らない）には、その企業を存続させている「強み」や、企業努力では変更できない業界や市場での「制約」といったものが克明に記録されている。たとえば、営業担当者が納品時に顧客の意見をきめ細かく聞き取って上司に報告する過程があって、これが顧客の信頼を生んでいるのかもしれない。また、無意味なほどに複雑なキックバックの計算手順が組み込まれているが、これを前時代的と切り捨てることもできない業界の慣行があるのかもしれない。そして、これらはユーザにとってことさら「強み」とか「制約」とは意識されていない可能性も高い。

意識されていないことが多いとはいえ、それらの要素を基本設計に盛り込み損なうとひどいことになる。強みを発揮できなくなって業績が悪化したり、制約を反映していないためにシステムとして使い物にならなかったりするからだ。

◆現状分析はきっちりやるべし（ただし基本設計の「後」で）

では、現行システムのあり方からそれらの宝石を採掘するにはどうしたらいいのだろう。「企業の強みはどこだー、市場の制約はどこだー」となまはげのように探し回ればいいのだろうか。それは無理だ。ユーザ自身がそれをそれとして意識していないだけでなく、「比較対象（コントロール）」がないからだ。

たとえば、「あなたの個性は何ですか」と訊かれて、「他人との比較」なしで答えるのは不可能だ。「個性」が字義上「他人との比較」を含意しているからだ。そして、比較されるべき「他人」はマイケル・ジャクソンのような個性派であってはいけない。「一般的に人はこのような傾向を持つものだ」みたいな平均的な人物像を想定して、それとの違いがようやく「個性」とみなされる。

「企業の強み」や「市場の制約」はその企業システムの「個性」のようなものだから、これをあぶりだすためにも、「この業種の企業システムは一般的にこのような傾向を持つものだ」といった理想化されたシステム像が必要だ。以前にも書いたように、業種別のシステム設計の型紙集みたいなものが流通しているわけではないので、理想化されたシステム像なんてものは用意できないように思える。しかし、「現状分析に先行して実施された基本設計の成果物」を、上質の比較対象として利用できるのである。

家の改築に喩えれば、設計士が描いた新しい家の図面と、現在の家の見取り図とを比較して、はじめて「神棚」を置くスペースがないことに気づくようなものだ。その施主にとって、神棚に毎朝お参りすることが、家の個性とさえ意識されていないほどに当たり前の慣行ならば、設計士との打ち合わせの際に「神棚のスペースをよろしく」とはことさら言わないかもしれない。設計士としても、神棚にこだわる家族がいることが想像を絶しているなら、施主との打ち合わせの際に「神棚はどうしましょう」とはことさら言わないかもしれない。そのようなお互いの常識の差にもとづくすれ違いを是正するには、新しい家の図面と現在の家の見取り図を比較するのが効果的だ。

基本設計、現状分析、の順序の意義をじゅうぶん理解してほしい。基本設計においては、現行システムに変に引きずられずに伸び伸びと「To-be」を組み立てる。続く現状分析においては、「To-be」を「強みや制約が考慮されたTo-be」に洗練させる。この順序でやれば、もっとも少ない工数で効果的な新システムの仕様を生み出せる。つまり、現行システムは新システムをデザインするための「発想の源」ではなく、新システムの「フィージビリティ（実現可能性）」を確保するためのダシとして「いいように利用される」ということだ。

反対に、現状分析の後で基本設計を実施すると、現行システムの仕様が新システムをデザインするための「発想の源」となり、代わり映えのしないシステムが生み出されやすい。問題はこれにとどまらない。新システムの仕様を発想できないのは、現行システムの仕様がじゅうぶんに理解できないゆえに違いない――スキルの足りない技術者はそのように判断して現状分析に耽溺する。住宅を全面改修するために現状の畳の目の数を虫眼鏡を使って数えるような、丹念かつ不毛な作業を延々と続ける。結果的に、完成が遅れる。

付言すれば、基本設計の後で現状分析を実施するやり方にも問題がないわけではない。ユーザのカジュアルな発言だけにもとづいて「それならこんな感じでどうでしょう」とその場でTo-be案を描き広げるためには、さすがに適性や経験が求められる点だ。とはいえ、これも致命的な問題ではない。企業システムの設計者も「建築家」や「ミュージシャン」と同様、適性も地道な訓練も必要なフツーの専門職のひとつであるというだけの話だ。誰もが手軽になれる職業があるとしたらそれは「専門職」ではない。「この弾き方で、１０日後にはあなたもプロミュージシャン」なんて広告を信じるマヌケはいない。