スタロジカンファレンス

by tanabe on July 24, 2007

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

職務上の必要性はともかく、個人としての興味に任せて行動すると「色々な意味で 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でやっていただける仕組みを提供するということです。