ぶり脳について

[itengineer]

今井＠「こっそり「名前＠何か」を定着させようとしている」です。

アングラな感じを醸し出す為には、キモさを演出するのが一番だと思うのですが、
Buriの場合その「ぶり脳」がキモさの代表格になるのではないか、と思いました。

一言で言って「ぶり脳」とは？

というような、どうでも良いディスカッションを織り交ぜて肩の力を抜きつつ、
Buriを知りたがっている方々にちょっとしたヒントとキモさをアピールしてみてはどうか？
という、癒し系ディスカッションです。

[makotan]

まこたん＠世界で最初にぶり脳を獲得した人です

業務（システム）の流れが自然と正規化した状態で見える脳みそじゃないかな～

獲得までに何段階かあるような気がするけどね

[はぶあきひろ]

羽生＠ぶり脳獲得まで2年かかった人です。

定食屋とかで伝票を見て脳内で速攻でERDが浮かぶのがERD脳。

んで、「あ、今この伝票は受注済みの状態だな」とか思ってて
料理が出たら「入金待ちの状態に移動したな」とか思うのが、ぶり脳（ｗ

そこにあるものに対して「これはxxという状態だ」と状態名をつけたくなる
というやばい症状ですね。

[makotan]

まこたん＠いつぶり脳を獲得したか未だ不明な人です

> そこにあるものに対して「これはxxという状態だ」と状態名をつけたくなる
> というやばい症状ですね。

それは本当のやばい状態を知らないからだ・・・
「XX済みになったら次にYYやって～」
みたいにXX済みってのを何も考えずに使える様になるとコンプリート

[はぶあきひろ]

羽生＠実はまだぶり脳じゃないらしい人です。

> 「XX済みになったら次にYYやって～」
> みたいにXX済みってのを何も考えずに使える様になるとコンプリート

一周回ってプロセス脳になりました、と？（ｗ

[itengineer]

今井＠「ぶり脳を見失った状態」です。

羽生さんがぶり脳じゃない、と？＞＜
え！？プロセス脳！？
（いわゆる順次処理的な奴？？

ERD脳は、「楽々ERDレッスン」を読ませて頂いて、
　　管理したい、残しておきたい情報という観点で物事を見ていく事と、
　　それを所謂「ビジネス上の正規化」でまとめていきましょう。
という理解をしていて、
ぶり脳は、
　　情報は生まれてから死ぬまで色んな出来事があるんだよ
　　その「出来事」の瞬間をとらえたものが「状態」
という理解をしていたのですが、まこたんのを読むと
微妙に違うような。。。


っていうか、全然一言じゃない＞＜

[はぶあきひろ]

羽生＠吞んだ翌日はぼーっとする人です。

すんませんです(^^;　社内のノリで書いたら
混乱を招いてしまってますね(^^;;

プロセス脳ってのは忘れてください。
多分これは、私とまこたんの間でしか通じないと思う（ｗ
まぁ、CRUDなんですけどね。

ぶり脳云々ということでいうと、逆に言えばどういうのが
「ぶり脳じゃない」ということになるか、という風に考えてみると
いいんじゃないかと。

例えば、ERD脳になってない例としては項目の横持ちとかありますね。
同様にぶり脳になっていないと、ついついフラグとかIF文を考えてしまうと。

まぁそんなことを書いてるうちに来客なので、また今度（ｗ

[はぶあきひろ]

羽生＠何で文字化けしたのかわからない人です。

化けないかどうかをまずは確認(^^;

On 11月28日, 午前10:03, はぶあきひろ <akihiro.h...@gmail.com> wrote:
> ̤ դϤܩ` äȤ ˤǤ
>
> ޤ Ǥ (^^; ڤΥΥ Ǖ
> Ҥ Ф Ƥ ޤäƤޤ (^^;;
>
> ץ × äƤΤ Ƥ
> ֤ ϡ ˽ Ȥޤ g Ǥ ͨ ʤ ˼
> ޤ CRUD ʤ Ǥ ɤ͡
>
> ֤ × ơ Ȥ ȤǤ ȡ Ԥ Фɤ Τ
> ֤ × ʤ Ȥ Ȥˤʤ뤫 Ȥ L ˿ Ƥߤ
> 󤸤 ʤ ȡ
>
> С ERD× ˤʤäƤʤ Ȥ Ƥ Ŀ κ ֤ Ȥ ޤ ͡
> ͬ ˤ֤ × ˤʤäƤ ʤ ȡ Ĥ Ĥ ե饰 Ȥ IF Ĥ򿼤 Ƥ ޤ ȡ
>
> ޤ ʤ Ȥ Ƥ뤦 ͤʤΤǡ ޤ ȣ
>
> On 11 27 , 11:46, itengineer <itengineer1...@gmail.com> wrote:
>
> > 񾮣 ֤ × Ҋʧ ä ״ B Ǥ
>
> > 󤬤֤ × ʤ ȣ
> > ץ ×
> > 혴΄I Ĥ ū
>
> > ERD× ϡ S ERD å 󡹤 i ޤ 픤 ơ
> > Ф Ƥ Ȥ Q ¤ Ҋ Ƥ ¤ȡ
> > ^ ӥ ͥ Ϥ Ҏ ǤޤȤ Ƥ ޤ 礦
> > Ȥ 򤷤Ƥ ơ
> > ֤ × ϡ
> > ޤ Ƥ ̤ޤ ɫ ʳ ¤
> > Ρ ¡ ˲ g Ȥ館 Τ ״ B
> > Ȥ 򤷤Ƥ ΤǤ ޤ Τ i
> > ΢ ` 褦 ʡ
>
> > äƤ ȫȻһ Ԥ ʤ
>
> > On 11 27 , 5:07, Ϥ֤ Ҥ <akihiro.h...@gmail.com> wrote:
>
> > > g Ϥޤ ֤ × ʤ 餷 ˤǤ
>
> > > > XX g ߤˤʤä Τ YY äơ
> > > > ߤ XX g ߤäƤΤ Τ⿼ ʹ 똔 ˤʤ ȥ ץ `
>
> > > һ ܻؤäƥץ × ˤʤ ޤ ȣ

[はぶあきひろ]

羽生＠Chromeに対する信頼感がまたひとつ減った人です。

文字化けしないようなので改めて。

プロセス脳は忘れてください。
まこたんとのいつもの会話のノリで書いたら
逆に混乱させてしまったようで（ｗ

ぶり脳じゃない状態というのを考えてみるといいのかもしれないです。
典型はフラグ＋IF文で考えるというものですが、それが箱と矢印で
考えるようになるかどうか、がぶり脳になってるかどうかの入り口かな、と。

[makotan]

まこたん＠（新説）実はぶり脳なんてものはない！です

DIの前と後とか、RDBの前と後とか、バージョン管理システムの前と後とか、バグ管理の前と後とか、
インターネットの前と後とか、ケータイ電話の前と後とか
そんな感じで普及しちゃえば当たり前でその前はどうやってたのかが思い出せないものって結構あって
ぶりってそんな中の一つなんじゃないかなぁ～と咳をしてて思った。

＃いっぱい書きたいものが、咳と一緒に飛び出て無くなってるけどまぁいいや（ｗ

[itengineer]

今井＠「ChromeだけはGoogleのサービスで文字化けを出しちゃいけないと思います」です。

そういえばオブジェクト脳、オブ脳なんて言葉がありましたね。
というと、「ぶり脳」の説明と効果の表現の仕方に気をつけないと、
どういう扱われ方をするかちょっと怖いですｗ

ともあれ、羽生さんの
　　　「フラグ＋IF文」を「箱と矢印」で表現できる＝第一段階
というのは凄く分かり易い目安になります！

[はぶあきひろ]

羽生＠業務とエンティティは別だと断じる人です。

個人的にですが、ぶりを使うというのは
DB設計の延長だと感じるんです。

だからぶり脳というか、ぶり的発想をするには
何はともあれERDレッスンの内容が理解できていないと
難しいのだと思います。

非正規形の業務を状態という観点で正規化する。
なるほどと感じます。では「何を」状態という観点で
正規化するのかというと、実は正確には「業務フローの
中で変化していくデータ」なんですね。

ERDレッスンにて「業務の観点からの正規化」という話を
書いています。例えば「契約」というのが関連エンティティと
して浮かび上がるという例を書いています。

で、契約とはERDレッスン的に考えると、イベント系でもあります。
契約にまつわるイベントを考えると、当然契約エンティティに
ヒモ付く状態遷移というのが考えられるわけです。

では契約の状態遷移を描いたときに、それぞれのトランジション
つまり矢印を遂行するのはいつなのかというと、これはマジカ！を
書けばわかりますが、全然バラバラのタイミングで行われる業務に
マッピングされるのですね。

マジカ！が個別のアクティビティでバラバラに書いていって
「結果として」プロセスのフローになるのと同じなのですけど
マジカ！の話は取りあえず割愛。

で、そのバラバラのタイミングの業務から契約エンティティに対する
状態の操作を抜き出してぶり上でまとめると、所謂ステートマシンと
同様の形になる。

ここで改めて契約エンティティの構造を見ると、フラグだ何だという
ような余計なものは存在せずに、純粋に契約についての項目だけが
列挙できるようになる。

これが結果として、ぶりを使えばDB設計のコストが非常に軽くなるという
実益につながるわけですね。かつ仕様変更に対しても柔軟に対応できる。

ぶりにはステートマシン系のルールエンジンとしての側面ももちろん
ある（遷移のアルゴリズムを一手に引き受けるのですから）わけで、
プログラミングという単位で考える人にとっては、そういう見方を
したくなるのでしょうけど、システム全体を考える視点からすると
ぶりの効能というのはやはりシステム内超グローバル変数としての
DBというものの扱いをシンプルかつ安定的にするものだと感じるのです。

ぶり慣れしてくると、ERDの持つ重さみたいなものから解放されるのが
実感できます。それは逆に言うとERDレッスンの内容を心底理解してないと
実感できないのかもしれません。

とりあえず、アルゴリズムで考えるのではなく集合で考えられることは
不可欠で、その上で集合の中のインスタンス単位で状態を考えられることで
集合自体をよりシンプルに捉えられることに、ぶりの価値はあるのだと
感じています。

[はぶあきひろ]

羽生＠今日は大阪に移動する人です。

ERDレッスンの話を書いたので、ちょっと補足すると
あの本の中で状態遷移に関することを少しだけ書いています。
実はそれがステートパターンを使ったものです。
状態ごとにサブタイプに分けるという形になっています。

で、あれは、アルゴリズムとデータ構造の分離を是とする
RDBMSの考え方としては正当なんですけど、ではインスタンスの
出し入れをいつ・どうするのかということは、やっぱり見えない。
アルゴリズムが分離されているのだから当然なんですけど。

おまけにあの書き方で、状態遷移のある全部のエンティティに対して
サブタイプ書いていくと、まぁそりゃ大変で、エンティティ数が増える
というのはCRUDが増大するわけで開発コストも増えるし、状態についての
仕様変更があると、分割統治がされている分だけ影響度は下がるんですけど
手間がかかるのは間違いない。

その辺がぶりの投入で一気に楽になるというのが、大きな効能です。

んで、この辺は以下の記事を見ると実感すると思います。
http://itpro.nikkeibp.co.jp/article/COLUMN/20081119/319585/
これの図２は、正にぶりに任せたい内容をまとめて記述したものです。

でもこの図を書いても、これを元に更に仕様書を書き下ろして実装しないと
いけないというのが、ぶりだと遷移図を書くことで見た目にわかりやすい
上に、そのまま動作しますと。だから設計工程の工数も激減するわけです。
転記の回数が減るから。この辺は簿記と会計ソフトの関係に近い。
業務改善ってのは以下略。システム開発という業務以下略。

[itengineer]

今井＠「buri-jaを作って本当に良かった！と断じる人」です。

読んでてゾクゾクしました！

きっと【ぶりの何が知りたいの？】で何度か出てくる気がしますが、
「ぶりだと遷移図を書くことで見た目にわかりやすい上に、そのまま動作しますと。」
この一文がぶりのメリットを分かり易く表現してる点だと思います。

先日「台帳転がし系」という単語をTwitterで見かけましたが、
ERDレッスンを踏まえたテーブルがまずありきで、そのテーブルのデータの移り変わりを考えて
ようやくぶり脳の入口かな、と。
＃手前味噌ながら先日の僕の記事（入門記10(http://d.hatena.ne.jp/itengineer/20081127)）
＃がその具体例の1つかな、と思っています。

○○ステータスとか××区分というカラムに伴う制御は、2種類以上あるともう非常に管理が煩雑で、
それを制御するプログラムはどんどん脆弱になっていきますし、
そんなコードをテストしないで済むならしないで済ませたいですからね。

そうなると、「何が」状態遷移していくのか、区分けされていくのか、みたいな事を考えていかないといけなくて、
その「何が」を見極めるのは、羽生さんのおっしゃるようなERDをちゃんと作れないと、と。

成果物を実装に流用できるという点は、仕様書やコードにする際の「変換」のコストより、
「実装のイメージをお客様にそのまま確認して頂ける」という点の方がメリットとして大きいと
思っていたりします。
＃流用できるといえばT字形で有名な佐藤正美氏も「T字で書かれたER図は実装に流用できる」
＃と言っていて決して「実装手法」とは言っていなかったようなぼんやりした記憶が蘇る表現です。

マジカ！とXPDLの組み合わせを、オブジェクト指向のユースケースとシーケンス図のように
捉えると、今までのイメージのままぶり脳に近づけるかも、とたった今思いついた事を蛇足的に書いておきますｗ

[itengineer]

今井＠「裏紙は世界最強のモデリングツール」です。


微妙に怪しげな事をあえて書いてみます。

「状態」を一番てっとり早く説明するには照会画面をイメージする、
というのはどうでしょう？
案件一覧照会という画面があったら、「商談中はどれ？」とか「納品済はどれ？」とか
そういった条件をみんな入力できるように作りますよね。
それがすなわち状態です！

なんて説明すると伝わりやすいかな、と思いました。

> ...
>
> もっと読む >>

[makotan]

まこたん＠「ERDをちゃんと書くのはずいぶん前から普通のことだと思ってた」です

ERDをちゃんと作れないとぶりは使えないって言うのはその通りだと思います。
少なくともERDレッスンの内容を理解できないとぶりの理解は無理なのかも・・・

まぁ個人的にはIF撲滅から始めたのは事実だけどそれなりにERDを書くのはその前からやってたし
ぶりが出来てERDが更に楽になってこれなら羽生さん出番なくてちゃんと出来るやん！って思ったのも事実
それ以上にプログラムが楽になった～ってのが大きくて普通はERDが難しいなんて忘れかけてる事実なんだよね～(^^;

On 11月29日, 午後2:02, itengineer <itengineer1...@gmail.com> wrote:

> ...
>
> もっと読む >>

[itengineer]

今井＠「ERDが難しいのはちゃんとできてるかどうかの検証だと思う」です。

ERDをちゃんと書くにはお客様の業務をちゃんと知っていないとできない訳で。
となれば、ちゃんとしたERDが書ける＝ぶりも使える、というのはある意味その通りかも知れません。

「ERDを書くのがさらに楽になる」というのも確かにそうかも知れません。

削除フラグとか削除フラグとか削除フラグとか要らなくなりますから、
ERDが「実装されたプログラムから利用される」という制約から解放されますね。

実装都合の列が減ればその分、コードが楽になるのはコードの為の列が減るのだから当たり前、
というのは微妙に目から鱗です。


個人的にERDレッスンの内容は、ともすれば数学的にうんたらとか、
RDBMSの特性がどうとか、そういった方向に向かいがちなテーブルレイアウトというものを、
あくまで「実用的に用いる為には」というアプローチで書かれた本だと思っていて、
内容がDBに関する技術書なのか業務システム本なのか、ちょっぴり悩んだりするところなのですがｗ
この本に書かれている視点を知らないと、そもそもぶり脳を獲得するのは難しいのかも知れないですね。

これはぶりの技術がどうとか、業務システムとはそもそも、という以前に、
考えた人、作った人がほぼ同じなので凄く当たり前のことだろ、って事でFAでしょうか？ｗ

> ...
>
> もっと読む >>

[はぶあきひろ]

羽生＠大阪にいる人です。

> これはぶりの技術がどうとか、業務システムとはそもそも、という以前に、
> 考えた人、作った人がほぼ同じなので凄く当たり前のことだろ、って事でFAでしょうか？ｗ

ん？　ぶりは、まこたんがゼロから考えてひとりで全部実装したもので、
ERDレッスンの著者は全くのノータッチですよ（ｗ

[はぶあきひろ]

羽生＠補足しなければと思った人です。

よく誤解されてるのでちょっと整理しておくと

・ERDレッスンの著者イコール、マジカ！の作者。
・ぶりの作者はまこたん
・ぶりは、ERDレッスンやマジカ！とは無関係に誕生
・但し両人ともDIxAOPには影響を受けている
・そのふたりが、たまたま同じ会社にいた

ってことです。いやマジで。

よく「業務の観点から羽生がぶりの構想を考えて、それを天才まこたんが実装した」
みたいな感じで捉えられたりすることあるけど、それは全然違います。
同様に、マジカ！はぶりの前身であるハマチの後に出来てるけど、それとも
無関係に必要に迫られて、私と某メンバーがひらめいたものです。

ただまぁ、ふたりとも同じ会社になる前から「システムかくあるべし」の
話はいっぱいしてて、共通の価値観が醸成されていたってのはあります。
一時期はほんとにしょっちゅうふたりで吞んでたし（ｗ

だから、ぶり誕生秘話みたいなものがあるとして、そこに私は出てこないです。
誕生後の、仕事での活用などの展開には密接に関わってますけど(^^;

なので、ぶりを作ったという手柄はまこたんのものです。
ただ、まこたんがあまりにも口下手というか素っ気なさ過ぎるので、
私がスポークスマン代行をやるときがあるだけです(^^;;

[makotan]

まこたん＠ぶり誕生秘話をリアルに書くと色々違反しそうなのでリアルには書けないです

簡単に誕生秘話を箇条書きにすると・・・
・まこたんの趣味はソフトウェア開発の生産性向上を考えること
・ERDレッスンとか「システムかくあるべし」みたいな内容を羽生さんと話してた
・とある案件でフラグがいっぱい出てきた・・・うざかった
・その後の案件で業務フローを手書きした・・・うざかった
・S2（DIｘAOP）が出てきてS2Daoをみた
・S2JSFのαをみててそれも良かった
・時間もあるし、探してもロクなのないし作ろうと思った＜これがぶりのまえのハマチ
・使ってみると足りないことが判ったのと、他に色々あって作り直した＜これがいまのぶり
・結果、ぶりには大満足。でも理解されずに苦労することに・・・

その後はオプソ化してるので、まぁ色々と・・・って感じ

[今井高史]

今井＠「これから同窓会に片道二時間かけて行く」です。

すみません、事実誤認というか落とす為に無理やり混同させました＞＜

というか、ERDとぶり脳が非常に密接なので、本気でお二人で練り上げてきたのだと思ってましたw

08/11/29 に makotan<mak...@gmail.com> さんは書きました:

[makotan]

まこたん＠これぶり脳のスレッドだよね・・・です

羽生さんとしてはぶりを理解するのにERDから行った方が楽なのでそう言う説明が多いんじゃないかなぁと思います
まこたんがぶりを作るときはERDとか業務システムとはとか考えずに「IF嫌い」から来てるので・・・
で、スポークスマンとかプレゼン担当コミッタがどんな風に話しても大きく間違えてなければ
原則OKってことを言ってるので、そんな風に見えるのかも
＃まぁIF嫌いから話してぶりのことが判る人は実際少ないだろうしね～

On 11月29日, 午後4:48, "今井高史" <itengineer1...@gmail.com> wrote:
> 今井＠「これから同窓会に片道二時間かけて行く」です。
>
> すみません、事実誤認というか落とす為に無理やり混同させました＞＜
>
> というか、ERDとぶり脳が非常に密接なので、本気でお二人で練り上げてきたのだと思ってましたw
>

> 08/11/29 に makotan<mako...@gmail.com> さんは書きました:

[makotan]

まこたん＠話を戻す努力をしてみるテストです

第一段階以降を考えてみた・・・
第二段階：「箱と矢印」で業務システムが表現できることを理解する
第三段階：「箱と矢印」以外の表現が回りくどくて嫌になる
第四段階：「箱と矢印」の表現が自然に出来るようになって、それ以外の表現が思いつかなくなる
第五段階：日常生活に「箱と矢印」の表現が入り込んでくる

On 11月28日, 午後9:59, itengineer <itengineer1...@gmail.com> wrote:

[itengineer]

今井＠「第一段階って何だっけ？」です。

という訳で、ぶり脳獲得までのステップを纏めると。。。

第一段階：ERDレッスンを理解する or まっとうなERDを書けるようになる

第二段階：「箱と矢印」で業務システムが表現できることを理解する
第三段階：「箱と矢印」以外の表現が回りくどくて嫌になる
第四段階：「箱と矢印」の表現が自然に出来るようになって、それ以外の表現が思いつかなくなる
第五段階：日常生活に「箱と矢印」の表現が入り込んでくる

ということでよろしいでしょうか？
（またWikiにページを作りましょう

たしかに第五段階は「症状」と表現する他ないｗｗｗ

[itengineer]

今井＠「初心に返る」です。

このスレッドはそもそも肩の力を抜かなくては！
という訳で、「ぶり脳」を以下のように分けて考えてみました。

■Buriウィルス
　（中二病に似てBuriを使ってみたり、Buriについて知りたくなったりします）
■Buri脳
　（Buriを仕事で使えてしまいます）
■Buri病
　（Buriの持つ考え方でしか物事を考えられなくなります）


僕はまだBuriウィルスに感染した程度だと思っています。

On 11月27日, 午前2:43, itengineer <itengineer1...@gmail.com> wrote:

[itengineer]

今井＠「年内の全ての土日を狙われている＞＜」です。


「「箱と矢印」で業務システムが表現できることを理解する 」

イメージできたとして、それを「これってこういうことだよね」と確認するのがとても難しいと思いますた。


僕は「台帳転がし系」というキーワードでイメージしてますが、これは「台帳」が状態遷移していくのがいわゆる「線」、その中で何かしらの意思をもってそ
の状態を着目したいポイントが「箱」、これを日常に持ち込むのが「ぶり脳」ではないかと思っています。

で、「台帳」にあたるのが羽生さんのおっしゃった経営資源としてのリソースの「一側面」を抽出したモノ、と。


あぁ、「ぶり脳」と「ぶり病」は入れ替えた方が良いかも知れない。。。

[はぶあきひろ]

羽生＠明日は飲む人です。

とりあえず「台帳」ではなくて「伝票」ですね(^^)
伝票を転がす。

そういう意味では、伝票転がしの手作業の業務を
イメージすれば大体合います。

[itengineer]

今井＠「飲みたい＞＜」です。

「台帳転がし系」ではなく「伝票転がし系」でしたか＞＜

転がされるモノが○×伝票と言う事で、Buriで実装されるフローの適切な粒度がなんとなくイメージできるような気がしますね！

[itengineer]

今井＠「いろいろ並走」です。

ふと思いつきでぶり脳について思い出したように。
（正確には忘れつつあったので今一度呼び起こす、です＞＜


まとめっぽくなってしまうのですが、ぶり脳へ至る道のなかにDOAは不可欠だなーと思うようになりました。
「ぶりで状態を管理する」→「何の状態を管理する？」と考えたとき、
エンティティというかリソースというか、そういった存在はやはり非常に大きな足がかりになります。

具体的な存在であろうとなかろうと、XX済みという状態が置けるということはリソースかイベントか、
もっと分かり易く（かつ、誤解を恐れず）書いてしまうとDBにテーブルが置けるわけで。

業務システムのIF文は、このテーブルのレコードが今どんな状態だから○○して良い・悪いを
判断したりする為のモノが多いように思ったりもするので、やはり「エンティティありき」なのでは？

と思ったのでございます。