先日の情シスオフ会でスタロジの羽生さんが「ブリスタ」を惜しげもなく公開して、そのすごさにびっくりしたとwkzkさんのブログに記事が出ていて、その中にこんな記述があった。
そうそう、それはmark-wadaさんのいう対面式で開発を行うというあのお話と一緒だなぁと。mark-wadaさん強敵ですよ、これは。正確にはmark-wadaさんだけにいうことじゃないんだけど、ま、そこまでは書かない(^^;
それで、こりゃ一言おうかと思ったのだが、具体的に分からなかったのでやめておいた。いつか羽生さんに聞こうかなと思っていたら、羽生さんが、そのあとブログで「ギョイゾー！の裏側」というタイトルで記事を書いていた。びっくりした。ここまで書いていいのかということとここまでやっているんだという驚きである。
読んですぐに分かった。分かったといっても、ぼくは中味のことはまったくといっていいほど理解できないと思うが、そうではなく「ブリスタ」のコンセプトと設計内容、機能のことである。
羽生さんがぼくの強敵だとはぜんぜん思わない、というより羽生さんの方がはるかに先に行っているし、実践でがんがんやっているのには正直言って脱帽です。
しかしながら、wkzkさんも言っているように、ぼくが考えていることとまったくと言っていいほど一緒なんです。羽生さんに一緒にするなと言われるかもしれないが、図々しくそう書かせてもらっています。
もはや、システム開発は製造工程が律速でも何でもなく、要求定義（要件定義じゃないですよ）が大きなウエートを占めています。要求定義がきちんとできたら、その成果物が一貫で実装まで行ってしまうというのがめざすところです。
このことに関して羽生さんのエントリーではこう書かれています。
このようにスタロジは、基本的にはお客様とフェイスするチームと仕組み作りチームに分かれています。そして相対的にですが圧倒的に時間がかかっているのがお客様との打ち合わせです。この打ち合わせの時間も、ブリスタのおかげで恐らくは一般的なプロトタイピングなどと比較すると随分と短い時間でやれていると思いますが、結局はお客様の「うん、こういう業務でいいんだよ」という確信にたどり着くまでの時間次第ということになっています。業務上の確信という点ではマジカ！を使ったりもしていますが、何にせよ意志決定ということがテーマなわけですから越えるべきテーマは色々とあります。
この意思決定をしやすくする仕組みというのが重要で、自分たちの業務を分かりやすく整理してやる必要がある。それも含めて課題として、
今のところ、お客様と打ち合わせをして作るものを固めるところの時間短縮が課題です。またそれと連動する形で、打ち合わせ通りになっているかを検証する時間の短縮も課題です。開発については手書きの業務ルールを出来るだけ打ち合わせ段階の資料からそのまま落とせるようにするということを考えていますが、これはあと2年ほどはかかるかと思います。
と言っています。これらの課題をどう解決していくのか。難しいのは、いいツールを作ったらできるのかという問題でもなく、その気にさせるファシリテーションみたいなことが要求されるのだろう。
それと、業務ルールというのは、必ずしもいつもきっちり決まったものがあるわけではないので、なんとなくあるものから徐々に固まってルールに昇格するようなところがあるので、ある種の成長あるいは進化プロセスとして組み入れることが要るのではないでしょうか。
ここはぼくも一生懸命考えているのですが、羽生さん、2年なんて言ってないでもっと早く作らないと、ぼくが作っちゃうよ。（笑）
羽生さん、もうこれはヤバイですよ。これはイノベーションです。イノベーションというのは、優れたことをすることではありません、方向を変えることを言います。これは情報システムの作り方の方向を明らかに変えることです。（ぼくはBPMベースで同じことを主張しています）
それと、「スタロジはいわゆるウォーターフォール型というスタイルで仕事をしています」と言われますが、行き着くところは違うんじゃないかと思う。だって、仕組み作りチームは、案件ごとに動く必要がなくなるわけで、お客様とフェイスするチームだけで開発が終わってしまうのではないかと思うのです。これもすごい。
いずれにしろ、スタロジの仕事に敬意を表さざるをえません。と同時にうらやましくてしょうがありません。羽生さん、いいですよね仲間がいてああじゃないこうじゃないと議論しながらやっているのでしょうね。ぼくも入りたいな。
ぼくは基本的にひとりなので、しかもコード書けないし、システム設計もできないし、けっこうつらいものがあります。でもがんばります。