第一回チキチキ 『Buriの旨さを味あわせてやる』〜やっぱぶりは寒ブリだよね〜に参加してきました。これが目当てでjava-jaに入ったようなものです。既にいろんな方がまとめエントリを書かれています。是非これらのエントリもご覧下さい。
その中で僕個人が特に響いたことを書いておきます。
Who is your customer？
誰をお客様にしたいのか見えていないのでろくなシステムにならないのだ、というご指摘。根源的で当然のことだからこそ見えなくなるこの矛盾。あなたが直接対面しているのは本当のお客様、つまり実際にこれを使って業務を行うお客様ではないことが多層構造のこの業界では多い。プライムの案件でも実際に対面するのはお客様の情報システム部であることが多い。僕が今コンサルとして入っている仕事も、クライアントは情報システム部の方だ。その裏に本当のお客様がいる。だからこそ、「誰のために、何を実現するために、このシステムがあるのか」を考える必要があるということを、叩き込んで頂きました。
アーキテクチャがダメならプロセスもダメになる
プロセスはアーキテクチャを超えることは出来ません。これはものすごくものすごくものすごく大切なことです。
プロセスというのはある一定の構造を持っています。インプット、プロセス(処理)、アウトプットです。プロセス(処理)は「ルール」と「フロー」に分けられます。ルールとは業務ルールのことです。例えばお得意様からきた受注は５％割り引くとか、家族割に入っている場合は家族間の通話料を一律１分１円にするとか、そういうものです。フローというのは一連の処理の流れです。当たり前ですが、処理というものは上から下に流れていきます。逆流することはありません。業務を順番につないでいくからフローが生まれていきます。フローの中にルールがあるから秩序が生まれていきます。秩序あるプロセスからでしか、アウトプットは生まれません。
ではこの３つの要素は何によって決められるか。設計です。アーキテクチャです。
どんな企業組織も、どんな業務システムも、設計を超えてプロセスが動き出すことはないのです。実際にアウトプットを作るのはプロセスだったとしても、そもそもどういった構造になっているのかを可視化しないことには、プロセスをどういう風に変えていけばよいのか、つまりどういう構造にしていけばよいのか、そういったことが見えなくなります。Architecture Does Really Matter.
気づきのない提案は最低
本当にそう思います。
僕はPowerpointを書くのが主な仕事です。最低の提案は「可もなく不可もない提案」です。お客様は何かを実現したくて僕のような人間に提案を求めます。そこであまりにも妥当なことを申し上げても、結局気づきが生まれません。気づきというのは、驚きです。驚きがない提案は間違いなく心に響きません。僕の仕事は｢そもそもWHATを見つけるためにはどういう考え方でいくべきか」というのを提案するのが根本的な問いです。「なにそれ、当たり前なんだけど」というのはお客様からしたら、お前に金を払う意味はないということです。
人生におけるさまざまな選択で 妥当な選択ほどつまらないものはない。妥当な選択は、後に誇れる物を何も残さない。 一つだけ決意ある選択をし、後はなるようになればよい、と思うくらいがちょうど良 いと思うのである。乱暴な考えだが、結構、なんとかなってしまうものだ。
可もなく不可もないことだけは避けて、決意ある選択をしていくのが僕のポリシーです。
SIビジネスのIT化
羽生さん自身も何度もブログでおっしゃられていますが、羽生さんのスターロジック社が目指す方向は「SIのIT化」という一貫したポリシーです。みなさん無自覚に「羽生さんスゲー」と感じているようなんですけど、羽生さんのスゴい所はSIビジネスの原価低減に基づく品質向上を徹底してやっていて、その為には今まで築いてきたやり方をズバっと変えて更なる高みへ導こうとする執念にあります。システム開発のやり方を変えることがどれほど難しいことか。その為に作るプロダクトを稼ぐお金を捻出することがどれだけ大変か。ビジネスのやり方を変えるということは、最後は人間のマインドセットを変えるということに帰結します。これがどれほど難しいか。そういったことにガチンコで向き合われていることがすごいと僕は思います。
で、SIビジネスのIT化ということを考える時にポイントになるのが、人間が「実現したい結果」をソースコードにコンパイルするというオーバーヘッドです。プログラマの業務に対する理解のレベルが品質に直結します。ビジネスプロセス全体を一気にコードに落とそうとするから、こういったオーバーヘッドが生まれます。
そこで、Buriです。
ビジネスプロセスは「アクティビティ」と「トランジション」から出来ています。そういう大きな流れをBuriで管理する。ビジネスロジックを書くのはアクティビティの範囲に影響範囲を絞っていく。業務から業務へのつなぎは全部ワークステートエンジンが管理すれば、ビジネスロジックに注力できるし、プロセスの変更はBuriのエディターで編集することでコードレスで対応していく。
業務システムが何のためにあるのか。ビジネスプロセスを実行するためです。そうであるならばビジネスプロセス自身を管理できる仕組みを作り、原価低減と品質向上を同時に実現しようというのがBuriの本当の狙いでしょう。こうやって書けばBuriのようないわゆるBPM製品の意義は見えてくるんだけど、こういう縁の下の力持ち的なものって伝わりにくいんだよね。見た目には全然うまみがわからないじゃない。Flexでバリバリ作りこんだUIとかだと「これすげー」って伝わりやすいんだけど、ビジネスプロセスって地味だし当たり前すぐる所がある。それは僕の悩みどころ。
SIビジネスの原価を下げるということは、人手の作業を可能な限り減らす、属人化されているプロセスをどんどんシステム側に寄せていくということです。決してこれは「決められたことだけをやる」とイコールではありません。ひがさんのエントリにもありましたけど、誰もが同じコードを書くことが目的ではなくて、誰もがメンテナンスを出来るコードを書くのが重要で、誰もがメンテできるためには「このコードが何をやっていて、何をどう変更するとどこに影響があるのか」を管理できていることが肝要なわけで。そういった意味でもBuriのようなワークステートエンジンの導入は意味があります。
その代わり、今までのやり方を変える事になるんだけどね。
まぁ色々書いたけど
最も重要なのはid:yuripopの絶対領域にある。今まで書いたことは全て前座に過ぎない。絶対領域で来られたら迷わず飲み会で隣の席を確保するに決まってるだろ、常考。正直狙ってましたよ。これがスーツ力です。ええ。
