出席してるので、実況兼レポートです。ustreamでも流してるそうです。
とりあえず、会場つくまでに有り得ないほど迷いましたorz。でも、開始が遅れたようで遅刻になりませんでした。ラッキー。
羽生さん 第一部(14:30-16:25)
- エンドユーザ出身←4年間オペレータとして、ユーザの立場にいた
- コード書いて気持ちよくなっていたら負け
- ウォーターフォールをしっかり学んだ
- Oracleのサポートやっていた
- きちんとした設計が大事→データ中心アプローチ
- 事業計画アプリを作り、ビジネスモデルを学んだ
- 羽生さんはGeekではない
- Geekなら、羽生さんができることは出来て当たり前
- お金は自然に湧いて来ない←対価
- みんなつながっている→お客様の知り合いは身内かも→お客様が一番大事
- 社内にも、バリューチェーンはある
- PC、光熱費、人件費等が必要
- 人件費→売るのには、営業費用も必要
- お金を集めるには？←自腹(自己資本)、他人から(自己資本、他人資本(負債))、お客様の売上
- 売上≠利益(残高試算表、賃借対照表、損益計算書)
- "お金"の話は、ビジネスプロセスをモニタリングするためのメーター
- "お金"＝欲深い、ではない。"円"はリットルやメートルと一緒。
- メーターを見て、運転しているということ
- デスマの凄さ→お金が「いくらでも注ぎ込まれる」
- スーパーマーケットでは無理。公共事業なら・・・
- 勘定科目を見ると、ビジネスプロセスが見える
- 利益=売上-費用、ではなく、０-費用+お買上=利益
- 利益を増やす４つの方法
- 販売数を増やす、原価を下げる、単価を上げる、回転率を上げる
- コントロール可能なのは、原価を下げる、のみ
- 高付加価値≠高価格、高付加価値＝高利益率
- 販売個数、回数を10%改善するより、価格や原価を10%改善する方が効果が高い
- 契約は、借金を背負うような物(納品義務が生じる)
- 納金までにかかる費用は、納品確率を高めているだけ
- 30人が年収1千万になるには？←1人月100万のような計算では、不可能*1
- 1人あたり年間2500万円売り上げる*2
- 売る側の「商品」≠買う側の「期待」
- 「はい、タケコプター」≠「空を自由に飛びたいな」
- お客様の納得を得るには？→差別性、メリット、実績
- AIDMA(attention,internet,desire,memory,action)
- システム開発 VS 派遣１名
- 羽生さんが自社を「スタロジ」と呼ぶのは、名前を使いやすくしてもらうため
- プロの一押し→左脳＋右脳（論理的な説明＋熱い情熱）
- ビジネスプロセスを設計し、インプリメント(運用)する
- プログラミングと違い、生身の人間だから難しい
- 業務システム開発の問題点
羽生さん第二部(16:40-17:10)
- Buri(Business Unit Routing Integration)は"ワークステートエンジン"
- ワークフローエンジンに必要な、管理ツール、監視ツールがない
- アクティビティ(箱)、トランジション(矢印)、プロセス
- 必要な概念→状態、アクティビティ、ルーティング
- 必要な技術→S2Container、S2Dao、OGNL、XPSL
- BuriはXPDLを読み込んで実行
- WfMCによる定義。解釈が自由なので互換性は低い
- データは、アクティビティ(箱)によって状態(フラグ)が変わる
- ルーティングパターン→(XORかAND) + (JoinかSplit)
- Splitの種類→condition, otherwise, exception, default exception(Buriでは非対応)
- Activityの動作タイプ→Auto、Manual
- プロセスにおいて、扱うデータ(テーブル)は一つ
- Teedaなど+Buri+SeDao。Buriの情報は１つの管理テーブル。
- S2Container的には、Buriが一つのコンポーネント。POJOの一つ。
- JavaからBuriを利用するには？→Bao or Invoke
- BaoはBusiness(logic Access Object)。Interfaceとして定義
- Buriを使った開発手順
- 対象プロセスを決める
- DB設計＋Dao作成
- XPDLを作成し、Daoを割当
- Baoを書き、プレゼン層からBaoを利用
- Buriの利点
- プロセスを定義するのには、マジカを使うとよい
まこたん(17:10-17:50)
- Buriの名前の由来→ぶり大根*6
- Buriを作った理由→IF文が嫌い
- IF文の種類。ほんとは３つにわかれる
- 要件としてのIF
- 設計で作られるIF
- 実装で作られるIF
- DBのフラグと連携するIFが一番嫌い。DBのフラグはグローバル変数
- これを作っているのは、"設計"している人
- Buriで解決できないIF
- 区分の導出、運賃の計算、複雑な条件→これらはEbi(Excel)で管理
- Buri入門・・・は、時間がないので流し
- えび→ぶりの中のハリセンから派生
- ぶりの今後→BugFix＋クリーニング。機能拡張の予定は皆無。
ブリの内部
- 内部データアクセスモジュール、ぶりコアモジュール、エンジンAPI、Processor+Bao
- ぶりコアモジュール(XPDLを実行する)
- packageとprocessはclass、activityはメソッド
- XPDLコーダ→コンパイラ→内部表現+Object
- BuriProcessの種類
- AbstBuriExecProcess(ワカナゴエンジン)
- AbstBuriExeProcessDataAccess(ぶりのエンジンの本体)*7
- ぶりAPI → ProcessとActivityはルールベースで選択
- buri.engine.selectorの中がルール
- エンジンのdiconでどれを使うかを決める
- 自分で拡張可能
- 内部データアクセス→CUD
- 権限管理→APIだけ提供。
- Standardタイプはこれが必須
- 普通のアプリにはいらない*8
- 支援モジュール→タイマー実行とsignal
- Processor→アプリケーションから呼びやすくするための物。buriSignalはこの仲間
- Bao→aoシリーズに合わせた。XPDLから生成できるんじゃないか？
- DB構造
- ぶりのView
- BuriPathData→PathName,pkeyNum,dataType,tableName
- BuriPathDataUser
- BuriPathHistoryPath
- BuriPathHistoryUser
- DB構造がシンプルなので、状態の検索はSQLで行う
質疑応答(17:50-18:10)
- Q. ビフォアアフターが見たい。文字だけだとありがたみがちょっと。
- まこたん: ない。ビフォア書くと発狂する。
- 羽生さん: ぶりを使うと、設計の方針自体が変わってくるので、ビフォアができない
- 羽生さん: 1.0にしないのは、広まり過ぎるのを防ぐため。
- Q. 状態は、組み込みの物と同じイメージ？
- 羽生さん: ActivityをAutoにできるので、通過すると処理として扱われる。ステートチャートともフローチャートとも似てるけどちょっと違う。同列に並べるイメージ。
- Q. よくあるフローは伝票のイメージ。それでいいのか。
- まこたん: それで構わない。
- 羽生さん: デモを作ると、ぶり以外の昨日が目立ってしまう。マジカとかプロセスデザインとか他の技術の実装とか。
- まこたん: ぶり祭りで質問の時に一人だけ暇だった
- Q. フローを動いてみせれるといいのでは？
- 羽生さん: ぶり祭りでのウケはよくなかった。birds eyeは、実際に運用する人には求められてない。IF文が多くて困るのは開発者だけで、お客さんは全く興味がない。お客さんの要求に、はいはい、と答えられるツールを目指している。ぶりのベンダーとなってぶりを売るだけならこのようなデモは必要だが、本質ではないでしょう。
- 羽生さん: ぶりはOSSなので、有志がぶりのベンダーとなるのは構わない。
