満足せる豚。眠たげなポチ。

• 複雑なUIの一例で、コンボボックスの選択をいじると別のコンボボックスの選択内容が変わるとか、別の入力の入力可否が変わるとかを一画面でやっているものなんかがあると思う。これって結局内在するルールやフロー制御をプレゼンテーション層で扱ってしまっているだけなんだよね。そこを画面を割って buri や ebi 使うとすれば、UI レベルで本当に複雑さが必要なアプリってたしかにそうそう無い。（自分の担当業務アプリを考えたりして。）
• 一方で、「一画面で入力させたい」という要求は良くも悪くも強くあって、たとえば消費者向けの Web のページで契約成立まで20ページとかあったらそりゃ嫌がられるよなとかは理解できる。じゃ、Ajax のような非同期な作りにすれば入力単位としては１ページに見えるけど実装上は適切な単位に区切ってしまうとかできそう。どうせ一回に入力すべきなのは一箇所だけなのだし。「ページ遷移うざい」というだけの問題なら解決できそう。
• まさにこれを地道に徹底したわけだ。と妙に納得。

  手作業で開発すると500人月はかかる。それとは対照的に、同じシステムの仕様を決定するだけなら 5, 6 週程度で済むだろう。そして、その仕様がそのまま動作するシステムとなるのなら、開発期間を劇的に短縮するのに成功することとなる。〜 What Not How P7.(適当訳)

とか。

追記： What Not How に関してはこの辺とか。

What Not How: The Business Rules Approach to Application Development

posted with amazlet on 07.07.24

C. J. Date
Addison-Wesley Pub (Sd) (2000/04/12)
売り上げランキング: 94569

amazlet.com で詳細を見る

先日、スタロジカンファレンスに行ってきた。

職務上の必要性はともかく、個人としての興味に任せて行動すると「色々な意味で salesforce.com が一番の競合では？」とか質問したかった。（が自重した。開催者側の意思としてそういう主旨の場ではないと思ったので。）

脱実装、目指せコンサルという世間が共通して目指している勝ちパターンというのがあって、発表はそれに逆張りした結果だと考えているので、はてブコメの極端な賛否両論にはニンマリしているに違いないと勝手に予想。

個人的には、フレームワークがないとシステム構築ができない時代の次は、提供されたインフラ（含一定のフレームワーク）の上だけでプログラミングをする時代*1だと思ってるので beaf に加えて保守運用サービスを開始するという予定、さらにそのコアを成立させるための前提としてマジカ！（そして、見積前の最終成果物となる伝票が地味にノウハウの塊だと思う。）を突っ込んでいるというスタロジ発表はひたすら面白く衝撃的だった。

あと、帰ってきて各所の記事を読みながら8万円はその覚悟を買うべきで数字を一人歩きさせる段階じゃないよね、と思った。

最後に正直に書いてしまうと同行した同僚は平松さんのセッション(BuriやEbiなどでコードを自動生成、条件分岐撲滅、というテクニカルな話。技術屋さんには一番おいしさが明確だった)以外はつまらなかったらしい。たしかにマジカ！に Goya に ERD レッスンに、などなどの予備知識がないと自信家のトンデモなのか、本当の開発の革命なのかは理解できないかも。少なくともぼくは後者だと期待している。

*1 Rails がフルスタックである意味とか、InstantRails が輪をかけてフルスタックである意味とか、言語としての Java は分かるけどフレームワーク方面は分からないっていう人はやれることが非常に限定されるとか。

感想などで興味深かったものをメモ。

• スタロジカンファレンスを傍観して〜ABDのこととか
• As Is から To Be
  

  マジカはアクティビティをまず書き出して、その間の流れるモノをあぶりだす過程になる。

  To Beを考える時はまずマジカで書き出したアクティビティはおいといて、あぶりだされらモノに注目して、逆にそこから最適なアクティビティをあぶりだすって作業ってことだと、理解。

  モノは必要だからそこにあるわけで、まずはそれを与件として置いて、いじるべきはそのモノにまつわる冗長なアクティビティだということなのですね。

• スタカン
  

  8万円と云う値段はもう彼岸の出来事のようで、こりゃかなわんと云う所なので自分の中でさておいてしまい、それより例外的に値段があがる部分として「複雑なUI・帳票」としか書いてないのがひっかかった。

  複雑なロジックじゃないんだ。

• 要件の複雑性に対応するために
  

  あと昨日も言いましたけど要件定義はマジカ！だけじゃないです。現状をマジカ！で洗い出す⇒そこからKBMを抽出⇒新業務設計⇒新業務をマジカ！に落とす⇒伝票設計する。ここまでやって、さらにUI設計をやります。その上で見積。んで、これらの工程をDIYでやっていただける仕組みを提供するということです。

別に特定の何かを指しているわけではないけれど、「もう迷わない！」的な宣言をブログで出しちゃうのを見るとむしろ不安をあおられる。

迷って悩んでした上で決断をするから尊いのであって、迷わない人なんて心配で信用できないなぁ。