入門記12：Buriを使う為に必要なマインド(version 0.1.1)。

いきなりですが、「Buriは敷居が高い理由はすぐそこにある」でFAですよね？

今回は、ぶり祭りで羽生さんがおっしゃられていた「状態という観点による正規化」についてです。

Buriは業務システムをターゲットにしたライブラリです。

そして、業務システムの業務とは、お客様であるユーザの日々の仕事です。

日々の仕事は、そのほとんどが小さな目的・目標の連鎖と言えます。僕らの仕事で言えば、プログラムを書くのはテストをする為、テストをするのはテスト済のプログラムをシステムに組み込むため、テスト済のプログラムをシステムに組み込むのはシステムに新しい機能を加える為、等というように、小さな目的が積み重なって最終的に「お客様であるユーザの日々の仕事のお役に立つシステムを完成させる」というゴールを目指します。

この小さな目的を達成する事を、ここでは仮に「ミッション」と表現します。

このミッションの連続によってさらに大きなミッションを達成しようとするのが、たいていの仕事の根本です。「プログラム1つ作るだけ、されどそのプログラムがなければシステムは完成しない」という事ですね。

ここで、業務システムを見てみると、このミッションの達成はシステムによって完全に自動化したりする訳ですが、それだけではないミッションもあります。「判断する」といったもので、これは仕事と人間の接点です。この接点ではシステムで勝手にアレコレしてはダメで、人間（多くの場合、僕らのお客様）の意思を入れていただいて、その次のミッションに進むかどうかを決めていただかなくてなりません。

非常に分かり易い例で言えば、会社に交通費を請求する際に請求書を書きますが、これを完全に自動化してしまうと請求額にあり得ない金額を入れてもそのまま支払手続きをしてしまいます。しかし、心無い人間もたまにはいるので、その請求額が妥当かどうかきちんと見て判断しないとならない、というルールができます。そしてそのルールに則って、請求書は受領されるのか、差し戻されるのかが決まります。

この一連の流れには、「請求書を書く」、「請求書を受け付ける」、「請求書を受領する」、「請求書を突き返す」、「受領した請求書の支払をする」というミッションがあります。

ここで僕は、Buriが相手にしようとしている「状態」とはつまりここで書いたミッションではないか、と。

上記のミッションをアクティビティに、流れをトランジションに置き換えるとまるまるBuriで使うフローの下地になると思います。

こんな感じに。
（差し戻しの後は・・・どうなるんでしょうね。JPEdだとトランジションの繋ぎ方がなんかアレらしい。。。

そして、冒頭に出た「正規化」という点です。

正規化＝NormalizationでNormal＝正しいと訳されるところを、その著書で「普通にするって訳せば良いじゃん」とおっしゃられる羽生さんが、言う「状態という観点による正規化」です。では、「普通にする」ってどんなこと？となる訳ですが、これが非常に難しい。「普通って何？」は過去数世紀に渡って中二病を発症した若者が分かってくれない大人に反発しながら苦悶してきたにも関わらず解明されていないものです。

なのでもう少し軽く考えると、「普通にする」というのは「当たり前にすること」であり、前述の例で言えば「請求書を書く」ことと「請求書を受け付ける」ことはイコールではありません、という事です。イコールではないので、2つのアクティビティとして表現されます。同様に、「請求書を受領する」と「請求書を突き返す」もイコールではありませんので2つのアクティビティです。しかし、この一連の流れの中でさらに細かく分割できるものはないので、5つのアクティビティより増やす事もありません。（もちろん、ミッションが増えれば当然増えますが）

例にしてしまえば「当たり前のことだよなぁ」という感じのことですよね。

ハイ！「当たり前」になりました、やりましたね！

前回の「入門記８：Buriを使う為に必要なマインド(version 0.1.0)」に付け加える形で、以上のイメージがあるとまたぐっとBuriに近づけるのではないかと思っています。（突っ込みがなければ＞＜