設計と実装の狭間で

・現状
・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。

ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず実行環境も多様に増えました。結果として、そもそも設計自体やっている場合ですか？という流れすら感じます。

良く言えば、「動くことが正義。」悪く言えば、「俺、好き勝手食べる（開発する）人、きみ、後始末（運用・メンテ）する人。」状態。自分の携わるHadoopなんてのは、最たる例で、設計もヘッタクレもありません。おそらくHiveでもPigでも素のMRでもいいのですが、象関連でのBI系のSIは、設計ドキュメントが整備されない状態で、そのまま残るものが散見されるようになるでしょう。使い捨てが原則ですね。そもそも分析の手法もいくらでも変わるし、実装自体もよりよいものに変えていくのが筋なので、書いては捨てろ、の流れになってしまいます。

そんなので動くのか？という意見もあるとは思いますが、実は動かすだけであれば特に問題はありません。手法としては、一定のパターンに当てはめて、あとは試行錯誤を繰り返すことで動かすことはいくらでも可能です。後付けで「これは一種のデザインパターンです〜ノウハウです〜」と居直りを唄うのは簡単ですが、今後のメンテは厳しいでしょう。挙げ句は「こんな過渡期のものが5年も保つとは思っていなかったよね」という歴史の繰り返しになると思います。

別段、Hadoopのようなマニアックなものを持ち出さなくても、さらにSIでの設計資料の無意味さ度合いは、従来よりもさらに悪化しています。コンプライアンスやホウレンソウ大好き組織の内部レビューの頻度アップは、世の中のアジャイラーの必死の抵抗をあざ笑うかのように、資料のための資料のための資料のための資料をエクセルで作るという、いつの間に皆さんエッシャーのだまし絵のプロになったのですか？と見間違うフラクタルなドキュメントの組織化に拍車がかかっています。

アジャイルチックな（厳密にはアジャイルでもなんでもないのですが）実装優先と形式優先の大規模SIの流れの中で、設計がこれほど文字通り「形骸化」している時代は過去なかったと思います。

さらに流行の関数型言語にしても、設計技術はほぼ完全に欠落しています。筋金入りのLisperな関数型な人間に聞くと「設計？　いや、要らないですよ。だって必要なものに言語自体を寄せていくから」なるほど。でもそれあなた以外メンテできないじゃん。「？？　また別の人が作れば？」なるほど。論理的にはまったく不整合がないですね。完璧だ。反論の余地なしです。設計？イラネ。これが今の関数型の潮流でしょう。

（しかし、残念ながら現在のエンタープライズマーケットの市場は大規模SIです。大人数の従来のプロジェクトは、完全に設計して->実装のフェーズド・アプローチですね。実装しながら設計するという形ではない。設計技法がない関数型は分が悪いです。おそらく設計はオブジェクト指向で、実装は関数型で、という折衷案的な解決策を取るしかないでしょう。そんな状態で関数型言語が大規模SIに投入されるということはありません。真剣に関数型言語の普及に取り組むのであれば、設計技法を本当に考える必要があると思います。）

・そもそも論
・・・知り合いの古い大工の頭領は昔、こんなことを言っていました。
「材木から建材を切り出す前に、何をどうするか全部考える。全て頭に描ききれないと絶対に（家は）できない」

すなわち、「設計する」ということは「紙に書く」ということではありません。こんな当たり前のことがアジャイル屋さん・SI屋さんでは忘れて居る人が多い。「何をどうするのか、最後まで考える」ということです。広い意味では全体のゲームプラン、狭い意味では個々のコードは一体何をするのかを明確化するということです。手法は様々でしょう。WFであろうとアジャイルであろうと本来は同じのはずです。

そもそも論からいうと、設計はコストがかかります。したがって、コストに見合うだけのリターンが当然要求されます。設計と実装の乖離が酷くなれば、設計という作業は、そのコストに見合うリターンを回収することが困難になります。「ためにする設計」は設計自体のメンテナンスをする必要に迫られ、結果、不要なコストが増大します。本来的には設計をする前提としては、設計することにより実装・テストのコストが下がるということが必要とされるのですが。

・・・残念ながら、そういった方向には行きませんでした。特にいわゆる上流コンサルや設計屋はむしろ実装との乖離を埋めるどころか、逆にギャップを上げる方向に進んでしまいました。「お客様の業務を理解しやすく、整理する」というコンサルの方向に上流系と言われるセグメントが進んだのは周知の通りです。

ちょっと待ってくれ。違うでしょう。設計はシステムを構築するためにあります。業務系のコンサルをしたいのであれば、もっと違う方法を用いるべきです。いわゆる論理モデルと実装モデルの乖離を否定するどころか、むしろ積極的に肯定し、あたかも当然の如く振る舞った上流系コンサルは反省すべきだと思います。概念モデリング？多いに結構、それで実装・テストに与えるにメリットは逓増したのですか？残念ながら結果が芳しくないのは、そろそろ明確になりつつあります。（勿論、全体像を明確にすることやWhatを掘り下げることは重要です。ですがHowを置き去りにしたアウトプットはやはり役には立ちません。役に立たないアウトプットはそれ自体が不要コストの発生源になってしまいます。）

結果的に、いわゆる上流系の設計が完全に宙に浮いて、最近ではむしろその必要性すら顧みられなくなりつつあります。もともとのアジャイルの源流は、XPとはじめとしたUML礼賛派の末裔に端を発します。結果として、設計それ自体の否定につながる流れになってしまっています。ビジネスドメインまで完全に記述仕切ってやるぜの勢いで記法・方法論・ビジネスだけが野放図に拡大し、結果として、実装と直接「言葉」が通じなくなった「設計」は、まさにバベルの塔状態です。

SI自体の限界が見え始めている現状は、ユーザー企業による内製化が本格的に試行錯誤されるという時代を呼び寄せるでしょう。その時に重要になる絶対的なクライテリアは「設計のコストを回収できる仕組み」です。本質的に業務系のシステムの設計はユーザー以上に勝る存在はありません。特に、異常業務系正常処理については、現場経験に勝るユーザーさん以上に設計できるSEはいません。そして、その設計がもっとも工数がかかる、ということはSIの常識でしょう。ユーザー企業主体の開発は、どうしても実装・品質というフェーズの終わりでのアウトプットに難が出ます。その欠点を出発点である設計でのアウトプットでどう補うか？で全体の優劣が決まる気がします。

ちゃんと設計を行うことでトータルのコストが下がるはず、ということに反対するユーザーさん、SEは少数派でしょう。しかし残念ながら設計をちゃんと出来るユーザーさん、SEもやはり少数派なままです。なぜか？設計により下がるはずのコストが下がらない、これが現状だからです。設計のメリットがあるのか？冷静に考えるとそんなことすら自問する羽目になってしまう。これが現状です。「これどうやって実装すんだ？意味わかんね〜〜〜無い方がヨクネ？」

少なくともある種の進歩史観がIT業界にあることは事実でしょう。果たしてそうなのでしょうか？少なくとも「設計」というものの考え方については、そうではないように見えます。設計のコストをどう回収するのか？それは、少なくとも大規模な構築をSIとしてしっかり行うのであれば、まさに取り組むべき課題だと思います。

別に設計したものをそのまま自動化で実装・テスト作成まで一発で走れ、とか短絡的なことを言うつもりはありません。なんか設計を実装につなげるというと、なぜかいつもそーゆー一方的な発想になってしまうのがアレですが。そうではなくて、もう一度設計と実装の間をどう埋めるのか？各自が自分の考えをもって整理してもよい時期になっている気がします。

この設計は一体なんのために必要なのか？実装をするためにはどういった設計が必要なのか？会社がとか、プロジェクトがとか、そーゆー表層的な話ではなく、自身のエンジニアリングとして、どう考えるのか？そんな話です。設計は量の問題ではないです。質の問題です。

まぁ、そんなことを思う程度な設計過疎なプロジェクトが大杉ですよ。いや、まじで。