Smart UI について、だらだらと

OOP

昨年のエントリー、 DDDについて、だらだらと からのびのびになってしまいました、 Smart UI アンチパターンについて。

Smart UI アンチパターンは コの業界で非常に目にするパターンで、また、素人が素人のままで仕事が出来てしまう パターンなのですが、その是非を論じる前に、まずはどういうものかを整理したいところです。

一言で言えば、「Smart UI、アンタ良い者なん？悪者なん？」


* * *


DDD の Smart UI “Anti-Pattern” を読んでいると、これは本当にアンチパターンなのかとも思えてきます。

Advantages

  • Productivity is high and immediate for simple applications.

シンプルなアプリを作る上では生産性は超高いし、出来るのも早いよ！

  • Less capable developers can work this way with litte traning.

底辺エンジニアでもちょっとのトレーニングで仕事ができちゃう！

  • Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changeing the product to fit their requests.

要件分析が全然ダメダメでも、プロトタイプをリリースし、そいつを足がかりにユーザのワガママ要望に添うよう、チャッチャと製品を整えて完成させる・・なあんて必勝法が使えるのは Smart UI の強み！

  • Applications are decoupled from each over, so that delivery schedules of small modules can be planned relatively accurately. Expending the system with additional, simple behavior can be easy.

アプリケーションが画面毎にぶった切りになってるから、小さなモジュール単位の出荷計画がわりと正しくできちゃう。システムの拡張も、簡単な振る舞いの追加程度なら あっという間。

  • Relational databases work well and provide integration at the deta level.

リレーショナルデータベースは、画面毎にぶつ切りになったアプリを、データレベルで統合するのにとても上手く働く。

  • 4GL tools work well.

4GLツールも上手い具合。

  • When applicatins are handed off, maintenance programmers will be able to quickly redo portions they can't figure out, becase the effects of the changes should be localized to each particular UI.

アプリケーションをリリースした後のこと。メンテナンスプログラマは、奴らが理解できない部分(解決出来なかった部分)があったって、そこだけちょちょいと作り直せちゃいます。だって変更の影響は、ぶった切りされた画面毎に局所化されてるんだもん。

（以上、適当訳）

こうみると「Smart UI」という出来たプロダクトのアーキテクチャの話というよりは、開発プロセスもひっくるめて「画面駆動デザイン」「画面駆動開発」と言ってしまいたいですね。Smart UI には、

  • 形になるのが早い
  • スキルはいらない
  • 要件分析もいらない
  • 画面毎にアプリがぶつ切りなので、
    • 影響は局所化されてて作業依存なし。並列作業可
    • 分割リリース可
    • 画面単位の工数を足せばいいだけなので、見積りが楽ちん
  • アプリケーション全体の統合は RDBMS にお任せ
  • 保守も引き継ぎもテキトーでも何とかなっちゃう

という特徴があります。

われわれプログラマは酷い目にあった経験上 Smart UI を忌み嫌いますが、そんな色眼鏡をハズして特徴だけをシンプルにみると、なかなかイケてるんじゃない？と思ってしまう。スキルに依存しないし、一応のモジュール化もされているので、分割されているメリットは享受できます。「見積りが容易で」「機械的に設計ができて」「誰にでも開発できる」という特徴は、工業化 とも言い換えられるかも。


なんと言っても Smart UI は、ウォーターフォール と開発組織の階層化が進んだ日本的なシステム開発によくマッチします。

「素人は抽象化が難しい」は まつもと さんの言葉ですが、だからドメインモデル分析には確かな技術力（プログラミングの力）が必要です。開発者（プログラマ）の技術力うんぬんの前に、要件分析フェーズが開発者から分断された状況では、見積りや開発に要件分析が必要とされない Smart UI パターンは、非常に心強い味方です。真面目な話、現実問題としてコレしか手がないかもしれない。

そして、実際に開発をするシーンでも、技術力のある開発者を必要としないため、管理者サイドとしては人員の調達が用意で、しかも教育費用が押さえられます。OJT と言う名の事実上の無教育がまかり通るのも、Smart UI という優れた開発パターンのおかげかも。


スーツ的視点では Smart UI は「これでもか！」ってくらい嬉しい特徴のてんこ盛り。しばしば「酷い開発者の巣窟ゆえの現象」として語られる Smart UI ですが、ひょっとしてコの業界は、愚かさ故に水の流れるように Smart UI にたどり着いたのではなく、自らの約束の地として能動的に Smart UI を選んだのかもしれない、、、なぁんて、思っちゃいます。


* * *


とはいえ、われわれプログラマが一見あま〜い Smart UI の「アドバンテージ」を聞いて、反射的にゾワゾワゾワっと身の毛がよだってしまうのは、これがデスマーチを呼び、数多の開発者を鬱病に葬り去ってきた元凶であると知っているからです。正直トラウマ。Smart UIな開発に乗って酷い目にあったプログラマのリストで、歴史の図書館は一杯です。

DDD では Smart UI を Layered Architecture と対になる「アンチパターン」と位置づけているわけで、

Disadvantage

  • Integration of applications is difficult except through the database.

データベースを介さないアプリケーションの統合は、ちょっち難しい。

  • There is no reuse of behavior and no abstraction of the business problem.Business rules have to be duplicated in each operation to which they apply.

振る舞いの再利用もできないし、ビジネス問題の抽象化されてない。ビジネスルールもそれを使っているオペレーション毎に重複してやがる。

  • Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options.

ラピッドプロトタイピングやイテレーションは自然と限界を迎える。だって、抽象化不足がリファクタリングの選択肢を制限しちゃうから。

  • Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.

複雑さがすぐにあなたを覆い尽くす。だから、新たなシンプルアプリケーションを追加するしか拡張への道はない。ようするに、リッチな振る舞いを素直に作る方法はないのだ。（訳、間違ってるかも）

まぁ、一言で言えば、「出来たプログラムはクソ」ということ。


ソフトウェア工学は 一言で言えば「人類と複雑さとの戦いの記録」*1。Smart UI は その強敵「複雑さ」と武器を持たずに体一つでガチンコ対決するようなもので、よく「竹槍でB29と戦う」と喩えられるのもさもありなん、といった感じ。

まぁ、そこを不満に思うのはわたしが戦闘員側（イーッ）だからで、スーツ的には「戦いは数だよ、兄貴」は正しいものの見方かも*2。ところが「全てが上手くいく話」なんてそうそう無いもの。このようなプログラムは「技術的負債」が貯まりまくりな状態で、初期開発は安く上がっても、拡張や保守にやたらとコストがかかります*3。これはスーツとしても美味しくない。

そこをセールストークでつつかれると...。


* * *


ASP.NET が世にデビューしたての頃、わたしは ASP →ASP.NET移行支援のお仕事をしていました。

そこは ASP を使って、Smart UI の極みのような開発をしていましたが、当然マンパワーで押し切るための超残業、収めたプログラムのトラブル多発でその対応での超残業という悲惨な現場でした。

コレでは（コスト的に）いけないということで、ASP.NET の移行の伴って 3層レイヤー構造を導入しようということになりました――エラい人が 日経や Microsoft のセールストーク にそそのかされて、そう思っちゃった（加えてもれなく「OOPは再利用(ry」なトークのおまけ付き）。

で、移行のための諸々をする基盤開発チームとして、外部からお呼ばれした次第です。

主なお仕事は、ASP.NET で「これまでやっていたことが出来るのか調べる」「どのようにつくればいいか標準化する」「標準のフレームワークを準備する」なのですが、難儀だったのが 要件であった 3層レイヤ構造化です。

だって、いままで Smart UI で開発してきて「関数禁止令」にも疑問を感じないで仕事をしてきた開発者軍団ですよ。ツルの一声でそんなことを言われても出来るわけない。「WebUI層とBiz層とData層に分けろ」というけれど、ドメインを分析するとか、プログラムを設計するとか、いままでやったことが全くないから、どうやればいいか想像すらつきません。・・そんなこんなが200余名。

当然 飛び出す話が「誰でも手順に従えば 3層レイヤー設計ができるような、マニュアルを作れ」。けれど、ちょっとまって。マニュアル化できるくらいなら、それってプログラムを作るプログラムを作っちゃえます。 Smart UI のノリだと自然に思えるカモだけど、それが出来たら論文書いちゃうよー。

そんなこんなで「ムリ」と回答したのですが、結果現場に蔓延したのは、各画面での分割を、WebUI層、Biz層、Data層まで貫いた、層状ならぬ賽の目状アーキテクチャーでした...orz*4。だ、誰か、タスケテ。


* * *


結局わたしたちは、まずは 一つの開発チームに絞って、実際の業務チームに参加して OOP導入 することにしました。千里の道も一歩からです。

でも、これまでの開発スタイルより、すごい工数かかるんですよね。ASP→ASP.NET の移行については、保守フェーズでの工数削減の他に、buzzってたOOPのウリ文句で 初期開発フェーズでの工数削減なんかも詠われてたので、エラい人にとって工数がふくらむのは詐欺です。あと「教育っていったって、なんでこんなに時間掛かるの？」という疑問も持ってしまう(これまで Smart UI だったから)。

もともと「設計をしない」Smart UI より ちゃんと設計をする開発が早く作れるわけがないし、「ならば、開発者どもすべてに今すぐ英知を与えてみせろ」も出来るわけがありません。

要件分析にも教育にもお金が掛からないことがSmart UI の旨みなのですから、その旨みを捨てることになると導入時点で認識していなかった、というのがそもそもの敗因です。

彼らも馬鹿ではないから、メリットのないことにはストップがかかります。結局 ASP→ASP.NET 移行計画は白紙に戻り、外部に「移行するよ！」と宣伝してしまった手前、とりあえず拡張子を .asp から .aspx に変更する、ということで 落ち着いたのでした。（すごいオチです）


* * *


以上、Smart UI をやめようとしても、誰も得をしなかった、と言う昔話。

依頼内容からして、もともと失敗する話だったと思います。それでも、今から思えば「Smart UI を止めるのを止めよう」という判断が出来なかったのは、わたし（たち）の失敗だと思う。当時 Smart UI というものが何かを正しく認識できていなくて、Smart UI を Smart UI と認識していない故に 中途半端に Smart UI から抜け出そうとしてかえって悲惨なことになる。そんなアリガチな惨事だったのだと 今は思ってます。


というわけで、いくら Smart UI に欠点があるからといって、責難は成事に非ず。Smart UI にはメリットも多いのですから、ちゃんとそこも含めて理解しなければ、と思います。

いっそ 胸を張って「Smart UI です！」って言えればいいのかな。日経あたりが上手いbuzzwordつくらないかな？「これからは Smart UI で、ソフトウェア開発を工業化」みたいな感じで。そうすれば Smart UI のメリット的なことを目指す企業は迷走しなくてすみますし、会社を選ぶときも うまく企業がタグづけされたりして、選びやすくなると思ったり。（妄想）


わたしはもちろん「そんな企業は選ばない」を選択するぜっ！・・・て、持ち上げといて、最後の最後で落としてゴメン。

おすすめ

Smart UI については こちらのエントリが秀逸です。

なんていうか、格好いいなぁ。

追記

まさか まつもとさんにつぶやかれるとは思っていなかった。超ビックリです。

「素人に抽象化は難しい」ってのに完璧に同意するけど、私自身の発言だっけ？

Yukihiro Matsumoto on Twitter: "http://d.hatena.ne.jp/minekoa/20100116/1263657955 「素人に抽象化は難しい」ってのに完璧に同意するけど、私自身の発言だっけ？"

うわっ、記憶違い!? と焦って捜す。そうそう、まつもとさんが言っていたのは

ここから「初心者向け言語が避けていること」言い替えれば 「初心者が苦手なこと」が何であるかだいたいわかる。 彼らは「抽象化」が苦手なのだ。

Matzにっき(2008-02-04)

ですね。「初心者」と「素人」、「苦手」と「難しい」じゃニュアンスが全然ちがう。記憶だけで書くのはいけません..orz すみません。

*1:ギーク的には「はてしない物語」は『虚無』よりも『複雑さ』と戦ってほしかったです。こっちのほうが強敵で、文字通り開発が never ending になります...orz

*2:逆にギークに語らせると、ニュータイプ（＝ハッカー）部隊的な話になります。ドズルとキシリアですね

*3:開発中に負債が返済不能になるとデスマーチ発動です。「トラップカード『技術的負債』発動！プロジェクトを『デスマーチ』状態にっ！」

*4:当時わたしはこれをネガティブなものとしてしか受け止めていなかったのですが、こちらを読むと、賽の目アーキテクチャを起点にリファクタリングを成功させてる。てことは、ただわたしの力不足だったんだなぁ、とちょっち落ち込みます..orz