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

いきなりですが、「Buriは敷居が高い子」でFAですよね？

じゃあBuriが難しい事をしているかというと、構成はなんだか複雑な感じがしますが、ようはエンティティのステータスを順序通り進める、という事をしているだけっぽいです。(もちろんそれだけではないのかも知れませんが)

難しいのは使い方です。

しかも、一般のjakarta-commonsのようなライブラリを使うイメージの使い方ではなく、「自分たちが行う開発という仕事においてBuriをどう位置づけて活用するか」といった難しさです。極論を書いてしまうと、Buriを使うには、対象がまず業務システムである事に加え、プロジェクト、アーキテクチャ、データモデルもろもろをBuriの為に構成し直す必要があります。(もちろん極論だと思いますが、意外に遠くないのではないでしょうか)

しかし、ここで気をつけたいのは、では「プロジェクト、アーキテクチャ、データモデルがそれぞれきちんとしていないとBuriは使えない」というのは若干語弊があるという点です。プロジェクト、アーキテクチャ、データモデルが腐っていたらそもそもまともな開発は出来ないでしょ、というだけの事なんです。今まではそれを個人の努力で埋めたり、お客様の要望を捻じ曲げたりして、なんとか「それっぽく」見せていただけではないか、と。

Buriを活用するには、お客様の業務を理解することが必須になります。

お客様の業務とは、開発するシステムの使われ方などとは別のレイヤで言うところの業務です。お客様が日々進めているそれぞれの業務の中に、システムがどう関わっていくのか、その結果としてシステムが担うミッションは何なのか、システムがやらなければならない仕事は何なのか、といった視点でソフトウェア開発を見ないと、Buriの使いどころを見出すのは難しいです。

そしてその使いどころを見出す事が出来れば、Buriは絶大な効果をもたらしてくれるんではないかと。

僕も少し前に軽く陥りましたが、Buriの作者が言う「IF文撲滅」という言葉から、既存の開発におけるIF文をイメージしても「IF文撲滅」という単語が伝えたい本質を理解するのはきっと難しい。IF文が何の為にあるのか、そもそもIF文を生みだしている理由とはソフトウェアで管理したい情報を扱う為ではないのか、では情報の何を扱いたくてIF文を書くのか、と考えていくとBuriがちょっと分かってくるのではないかと思い、僕は日々そのへんの事について思い悩んでいる次第です。

つまり、業務システムというのは基本的に「アウトプット」しか求められていなくて、入力は基本的に出力したいから仕方なくやっているだけである、と。なので、最低限必要な入力は不可欠なのですが、それ以上の入力をしたくないというのがユーザとなるお客様の本音で、その本音にお応えしようとするとまずは入力して頂いた情報をきちんと活かす事を考える必要があります。そしてそこで入力された情報が、その目的を達成するに至るまでを考えてみますと、Buriが管理しようとする「状態」という考え方が出てきたのは、非常に必然的だったように感じられます。

従来の開発におけるIF文がこの「状態」を扱う為に存在していた、と仮定するなら、Buriの持つアプローチが一つの最適解である事がなんとなく分かってくるような気がします。

今の時点で、僕が見えているBuriというのはココマデです＞＜

個人的には、もう1つcfneoの開発を通して見てきた「品質」という切り口でBuriに期待しているポイントがあるのですが、それはまた今度にします。

ツッコミがあればよろしくお願いします＞＜