オブジェクト倶楽部２００８夏イベント参加報告

更新日：

10:00～10:30 オープニング アイスブレイクセッション 開会の挨拶

  • 配布物の紹介
  • KPT in 2008夏イベント 携帯URLの紹介
    • http://www.yattom.jp/kpt/
    • 講演中、いまのよかった！と思ったらその瞬間に「拍手！」をクリック。
    • 講演中、よくないな、こうしたらいいのにな、と思ったら「残念！」をクリック。
  • 身体の体操
    1. 左手で△、右手で□。
    2. 左手で□、右手で△。
  • 各セッションの説明
  • テーマの説明
    1. 今回はワークショップがメインなので、是非身体を動かしてください。
    2. エコがキーワードです。エコバックも配っています。
  • エンジニアマインドというフリーペーパーを配っているとの宣伝

10:30～11:40 主賓講演 『システム思考と概念モデリング』

概念モデリングの背景には、システム思考があると思います。

システム思考とは、対象を全体として見て、
その構成要素を識別し、構成要素の相互作用によって
全体の振る舞いが創発されるとする「対象の見方」です。

実は、そこには、観察者と対象を構成要素とする、
さらに外側にある上位システムが仮定されています
（世阿弥の「離見の見」）。

こうした、多階層システム観とその非連続性、
そこにある揺さぶりの極知としての
モデルのコペルニクス的転回、学習の論理階について議論します。

今日お話したいこと

  • モデラの姿勢
    • モデルを考え、モデルで考える
    • モデルを通して学ぶ
    • 真の学び

システムとはなにか

システム主義

  • 1940～50年代
    • ものの見方
      • ベルタランフィ：一般システム論
      • ウィナー：サイバネティクス
      • ポアンカレ：カオス
      • ベイトソン：学習階層
      • プリゴジン：散逸構造
      • ナドラー：ワークデザイン
  • 1970年代～
    • 理論から思考へ
      • ワインバーグ：一般システム思考（1970）
      • チェックランド：SSM（1980）
      • センゲ：因果ループ（1990）

全体論

  • システム
    • 分解・還元主義に対するアンチ
    • 複雑性をどう扱うか
    • 対象をシステムとして見る態度
      • 全体があり、構成要素がある
      • 創発：全体の振る舞い＞総和（個々の振る舞い）
      • 自己組織化
      • 階層：システムはより大きなシステムの一部
    • アプダクション
      • 観測者、操作者
      • 入力、ブラックボックス、出力
      • 概念モデル、ダイナミズム

意味論

  • システムの階層性
    • サルの行動を原始の振る舞いで説明（モデル化）できるか
    • モデルは階層内の概念とそのメタでしか書けない
      • 意味は階層内の文脈に依存し、階層を超えられない
      • 観測者は誰？

階層間の翻訳

  • 階層間をつなぐ
    • 意味の翻訳
    • 時間単位の変換
  • 情報システムの階層

モデリングの位置づけ

用・美・強

  • 建築学に学ぶ
    • Vitruvius（ローマ時代の建築家）
      • 三つの価値観のトレードオフを調停する
        1. Utilitas（用）
        2. Venustas（美）
        3. Firmitas（強）

本当は家を建てたいのか

  • Zachmanフレームワーク
    • 断片化した企業情報システムを体系的な分散化に
建築メタファ ISドキュメント データの記述 プロセスの記述 ネットワークの記述
バブルチャート スコープと目標 重要なエンティティの一覧 実現されるプロセスの一覧 営業拠点の一覧
建築家の製図（施主の表現） ビジネスモデル ER図 機能フロー図 ロジスティックネットワーク
建築家の計画（建築家の表現） 情報システムのモデル データモデル DFD 分散システムアーキテクチャ
ゼネコンの計画（施工者の表現） 技術のモデル データ設計 構造チャート システムアーキテクチャ
サプコン指示計画（文脈外の表現） 詳細記述 データベーススキーマ プログラム ネットワークアーキテクチャ
機械語での記述
建物 製品（情報システム） データ 機能 通信

使ってなんぼ

  • 情報システムサイクル
    • 原要求と要求
      • 施主
      • 設計者
      • 施工者

思いの違い

  • それぞれの思い＝システム
    • 交差するプロセス
    • アーキテクトの役割

設計

  • 「原要求」から「要求」への変換（設計）
    • 設計者が行うプロフェッショナルな仕事。
    • 設計者の価値観、「美」の感性。
    • 都市環境、町並み、インフラ構想
    • 夢をかたちに
  • 「要求」に書かれるべきもの
    • 概念モデル
      • 型モデル、仕事の流れ、提供する機能
      • 要求記述テンプレートの業務設計部分

仕事の設計

  • 仕事とは
    • 「行わなければならないこと」を「体や頭を使って」行うこと

  • 仕事の対象と仕事のシステム
    • 「もの」－ものづくり（システム）
    • 「人」－サービス（システム）
    • 「情報」－情報システム

  • 行わなければならないこと
    • 対象の「はじめの状態」を「終わりの状態」に変える
      • input -> output
    • 考察の範囲：Universe of Discourse（UoD）

    • システムロード

もの・こと分析

  • もの・こと図
    • はじめの「もの」を終わりの「もの」に変換する
      1. 終わりの「もの」を決める
      2. はじめの「もの」を決める
      3. 残りのものを決める
      4. 基本変換を明確化する
      5. 手段のものを決める

かなめ

  • 要の「もの」、要の「こと」
    • 真に得たいもの、それに適うもの
    • 目的でない余計な不可を除去した結果
    • 終わりの「もの」の品質：品質要件

  • 要の変化
    • 必要最小限の対象の変化
      • 良品条件：すべてが解明されているわけではない

  • 要の手段
    • ワークヘッド：対象に接触して働く「もの」

仕事の流れ

  • 基本変換を業務フローとして記述する
    • 手順を具体化する
    • オブジェクトフローを追記
    • 手順を手段にあわせて調整する
    • 行為者を決める

仕事があっての機能

  • 手段のものを機能として記述する
    • その機能を情報システムに割り当てたものをユースケースという
  • 機能のテストとしてのシナリオ
    • ユースケースのインスタンス
    • 仕事のシミュレーション（ウォークスルー）

学びとモデル

現代版「学び」理論の系譜

  • 「Engestrom」と「Lave and Wenger」の2つが大事

学習とコミュニケーションの論理階

天啓の瞬間

  • ダブルバインドな状況
    • 相互に否定しあう2つのメッセージまたは命令
      1. Bateson（1972）
        • この棒が現実にここにあると言うなら、これでおまえを打つ。
        • この棒が現実にここにないと言うなら、これでおまえを打つ。
        • 何も言わなければ、これでおまえを打つ。
      2. Engestrom（1987）
        • ハックベリー・フィンの冒険（Twain, 1950）
          • 始めは逃亡奴隷Jimとの逃避行：無目的な反応
          • 奴隷制が廃止された地域に近づくと、内的矛盾が顕在化
          • Jimを助ける（新モラルは正しいが、トラブルに巻き込まれる）か
          • 密告する（旧モラルでは正しいが、Jimを裏切る）か
    • 新しい世界観の獲得
      • 一瞬の意味の転換：新しい道具、新しい活動
        • 獲得を促すスプリングボード

内部矛盾をあえて抱える

  • 「モジュール化」と「摺り合わせ」
    • 「冷たい」技術 vs 「熱い」技術
    • すべてを「冷たく」したくない
      • ダブルバインドを残しておく
      • 内部矛盾が見つかる状態
      • 熱くしすぎないコントロール
      • コミュニケーションコストが小さい？

児玉的コペ転の事例(1)

  • ギャンブルの胴元
  • オペレーションに過去の予定は要らない
    • 過去は実績のみ
    • 未来は予定のみ...って当たり前だけど
    • 予実較差は階が異なる（マネジメント）

児玉的コペ転の事例(2)

  • 関連型の有効性
  • REA（McCarthy, 1982）

児玉的コペ転の事例(3)

  • Individualはindividualでない

まとめ

  • 学び続けるために
    • 思考の見える化としてのモデル
    • 学ぶことをモデル化してみた
    • 学習の道具としての世界観
    • あえて内部矛盾を創造に変える

11:40～13:00 昼飯・休憩

13:00～14:10 『業務パッケージ導入での業務モデル活用事例』

業務パッケージ導入において顧客満足の向上と作業の効率化が課題になっています。
この解決方法のひとつとして、業務パッケージで実現できる標準業務モデルを
あらかじめ作成し、顧客と現業を確認しつつ差分を洗い出し、導入後の業務を
イメージする方法に取り組んでいます。
取り組みを始めたばかりですが、同様な取り組みをしているプロジェクト、
これから取り組みを考えているプロジェクトに参考になればと思います。

14:10～14:20 休憩

14:20～14:50 『マネージャーが感じるAgileは結構ネガティブ。どう説明する？』

マネージャーといってもAgileに興味を持っている人だけじゃなし、
記事斜め読みで先入観を持っている人にAgile本そのまま言っても無理です。
その説得方法を先入観ありありのマネージャーが語ります。

Agiler vs Manager

  • 熊谷恒治
    • チェンジビジョン勤務
    • TRICHORDオーナー

雑誌の目次をさらっと読む程度しかしてないマネージャーは

  • いつも菓子食べてるの
  • ペアでなんかやるみたい
  • 価値価値言ってる
  • 定時帰り なんか楽しげサークル？

もう1つの障害

アジャイル開発では、細かく分ける

  • チェンジビジョンでは、Todo一覧を作っている。
Todo Doing DONE

アジャイル開発に対する批判

  • あのチーム好き放題だな。

  • 朝会に何の意味があるの？と問いかけを、マネージャーがチームにしてみた。

  • ちゃんとやってないじゃん！

  • 調子に乗ってはいけない。

まとめ

  • 正しいことってうまく伝えづらいねぇ
  • 聞きかじった知識に追い打ちをかけないで
  • そもそも論は避けないと
  • 視点を変えただけで捉え方がグラッと～
  • 惰性はだめ
  • まあ、やらせてみようか！って人は、その前から信頼度が高い？

Q&A

  • [Q]経営層にペアプロの良さを伝えたい
    • [A]うまくごまかせるなら、先にやってしまう。
    • [A]レビューをしているんですよ、と言う。
    • [A]教育をしてるんですよ、と言う。
  • [Q]ペアプロの成果をアピールするには？
    • [A]具体的な数値で出すのは難しい。
    • [A]うまくいってるな、ということを感じさせてみる。
    • [A]がんばってんな、と思わせてみる。

14:50～15:10 休憩

15:10～16:50 『ビジネスパターンによるモデル駆動設計 そして開発プロジェクトについて想うこと』

昨年監訳を担当し、日経BPソフトプレス社から発刊された「ビジネスパターンによるモデル駆動設計」には、
様々なところから反響が寄せられました。
上流から実装に至るまでをカバーする一連のパターンが紹介されているからだと思います。
この講演では、これらパターンの中から構造パターンを中心に、その概要を説明します。
また、要件からパターンを通じて一連の設計を行う過程について考え、
本書のパターンがそのどこに位置するのかを考えます。
そして、パターンを活用した開発プロジェクトのあるべき姿においても
お話できればと思います。

概要

  1. REAとビジネスパターンの概要
  2. 質問コーナー
  3. 構造パターンと振る舞いパターン
  4. REAと開発プロジェクト
  5. 簡単なREAモデリング演習

REA

  • 会計のためのデータモデルとして、ミシガン州立大学のWilliam E.McCarthyによって1982年に提案された
  • ビジネスプロセスによって現実世界の意味づけを行い、その意味に基づいて経済的な取引やそれに付随するデータの関連を、モデル化することでデータ間のトレーサビリティーを提供する
    • なぜそのような取引が起きたのか
    • その取引の結果はどうなるのか
  • 米国の大学の企業情報システムの講座で教えられている
  • すでに4冊の書籍が刊行
  • 本年8月に日本で刊行された「ビジネスパターンによるモデル駆動設計（依田が監修を担当）には、REAに基づく各種パターンと、それらを利用してアプリケーションを開発する手法が、具体的に紹介されている。
  • Eコマース標準作成の基盤を提供している。
    • ebXML
    • UN/CEFACT（貿易簡易化と電子ビジネスのための国連センター）
    • Open-edi（ISO/IEC 15944-4）
      • オントロジーフレームワーク：Open-edi business transaction ontology（OeBTO）

著書Pavel Hruby氏の主張について依田のまとめ

  1. 企業が関係する資源の計画と管理に関する情報システムは、経済イベントの対称性に基づいてモデル化すると、高品質なシステムが開発できる。
  2. そのようにモデル化されたアプリケーションは、パターンを利用して高速に開発し効率的に保守することができる（REAパターン）。
  3. そのようにモデル化され開発されたアプリケーションは、会計システムの情報を包含し（財務諸表が出せる）、なおかつトレーサビリティーが高く理解の容易な情報を提供するものとなる。
  4. 中小企業もカスタマイズが容易で、安価な独自のERPシステムを持つことができる。
  • 「ビジネスパターンによるモデル駆動設計」は、1、2、について書かれた本です。
  • 本日のお話も、1、2を中心にして行います。
  • 3、4については、"Elevator Pitch, REA TECHNOLOGY"などを参考にしてください。

パターンを書き出すには

REA交換プロセスパターン

  • 増加経済イベント

  • 減少経済イベント

  • 経済エージェント

  • 経済リソース

REA変換プロセスパターン

  • 変換とは

  • 減少経済イベント

  • 経済リソース

バリューチェーン・パターン

  • REA交換プロセスパターンと、REA変換プロセスパターンを統合
    • 交換プロセス
    • 変換プロセス
  • 外にいるものを、INとOUTで繋いでいく

コミットメントパターン

  • 増加コミットメント
  • 減少コミットメント
  • 経済エージェント
  • 経済リソース

REAモデルの例(1)

  • 販売注文
  • 増加コミットメント（支払明細）
    • 寿司を注文する
  • 増加イベント（現金の受領）
  • エージェント（顧客）
  • リソース（現金）
  • 減少コミットメント（販売明細）
  • 減少イベント（販売）
  • エージェント（寿司屋）
  • リソース（寿司）

REAパターンを利用するメリット

  1. モデルがわかりやすくなる
  2. モデルが作りやすくなる
  3. モデルを立体的に評価できるようになる

REA交換プロセスパターンのためのドメインルール

  • あらゆる増加経済イベントは、交換の双対性にしたがって、1つの減少経済イベントに関連しなければならない。逆もまた同様である。
  • あらゆる増加経済イベントは、流入流出関係により、1つの経済リソースに関連しなければならない。
  • あらゆる減少経済イベントは、流入流出関係により、1つの経済リソースに関連しなければならない。
  • あらゆる経済イベントは、供給関係によって1つの経済エージェントに、また受領関係によって1つの経済エージェントに関連しなければならない。実行時には、これら二つのエージェントが異なる経済的利益を持つ異なるエンティティを表さなければならない。

構造パターンを利用したモデリングの勘所

  • モデリングの目的を意識する
  • 構造にするか制約にするか
  • リソースかリソースタイプか
  • 賃貸と融資
  • 価値の流れ（廃棄処理）
  • サービス化
  • 大規模なモデルへの対応

モデリングの目的を意識する

  • REAモデリングの目的は、、、
    • 何が起きたのか？
    • なぜそれが起きたのか？
    • 何が将来起きるのか？
    • なぜそれが起きるのか？
      • 以上を知ること
  • 上の4つを知ることが自分にとって必要不可欠であると感じ、そのためにはどのような情報が提供されればよいのかを頭に描いてモデリングすればよい
  • 経営者の気持ちになれば理解しやすい。
    • 「いったいこの金は何に使ったんだ！」
    • 要するにERPS（Enterprise Resource Planning System）を作る気持ち？

制約のマトリクス表現

Resource I-Event（増加イベント） D-Event（減少イベント） Agent
現金・にぎり寿司 寿司屋・顧客
流入・流出 現金の受領 販売 需要・供給

リソースか、リソースタイプか

賃貸と融資

  • 賃貸では同じ不動産を返さなければならない。
  • 融資は、小切手で借りて現金で返しても良い。
  • 不動産は、借りたものを返さなければならない。
  • 融資と不動産の区別はつくが、借りたお金と現金の区別はつかない。
  • 不動産は分割して返せないが、金は返せる。

Q&A

  • [Q]為替だとどうなりますか？
    • [A]原著に出てきていたかもしれない。

構造パターンと振る舞いパターンを、2次元で進めていく

構造パターンと振る舞いパターンは直交している（識別パターンの場合）

振る舞いパターン
構造パターン ここがプロジェクト！
  • プロジェクト
    • グループ
      • 識別子セットアップ
    • REAエンティティ
      • 識別子

識別アスペクト

  • アプリケーションモデルの上位に、クラスが定義されていることが重要。
    • つまり、モデルに対して積極的だということ。

REAとプロジェクト

  1. 準備段階
  2. 研究会などで自社版ビジネスパターンを作ってみる
  3. 振る舞いからプロジェクト版の作成
  4. 本格展開による量産効果を狙う
  5. 方向付け（Inception）・推敲（Elaboration）・構築（Construction）・移行（Migration）
    • いきなりここから始まっていないか？それは儲からない。

ビジネスパターンへの私の取り組みの歴史

  1. 10年ほど前に、CBOP（ビジネスオブジェクト推進協議会）のBFOP（Business Function Object patterns）開発に参加。
  2. UMLのパラメトリック・コラボレーションによる1次元的な組み立て構造。
  • REAの場合
    • 構造パターンと振る舞いによる2次元的組み立て構造。
    • 基盤部分を交換の双対性が支える

開発プロセスにもたらす効果

  • 従来からの要求分析や上流設計の手法は、業務プロセス主導型である。
  • そのため、ユーザの関心はキープできるものの、システム設計に有用な情報を提供できない。
  • REAは、あらかじめ、構造パターンと、振る舞いパターンが用意され、構造モデルはバリューチェーンモデルと直結している。
  • 従って、バリューチェーンモデルが描ければ、構造モデルを作成し、振る舞いパターンの合成などにより、一定のシステム開発作業に直接進むことができる。
  • バリューチェーンモデルは、仮想化、サイバー化、Web2.0化する社会におけるビジネス構造を骨太に描き出すツールであり、ユーザの関心も得やすい。
    • 物流モデルとは違う。
  • バリューチェーンモデルは、リソースとプロセス（業務）の関係を表している。
  • 従って、バリューチェーンモデルだけで、企業のリソース計画管理に関する要件を相当程度表し得ると言えるのではないか。
  • 以上の考察から、REAはREP（Enterprise Resource Planning）的システムの要件定義と設計開発手法として大きな可能性を持っていると思われる。

要求開発、要求分析との関係

  • 要求開発のようなトップダウンアプローチも欠かすことはできない。
  • REAのようなビジネスの普遍性に基づくアプローチと、どのように合流させれば良いか。
  • REAバリューチェーンモデルは、REAが構造パターンとして提唱する部分

演習

  • [お題]図の中の四角の中を埋める。
  1. 最近行った取引をモデル化してください。
    • 個人でひとつ
    • ビジネスでひとつ
    • プライバシーや機密にはふれない範囲で。。。

参考情報

16:50～17:10 休憩

17:10～17:30 アジャイル開発体験 XPブートキャンプ 2008 成果発表

開発セッションの趣旨は、XPの1日体験の場を作り、
楽しくXPを学ぼう♪というものです。
参加者4人＋永和コーチ1人が1チームになって、
簡単なアプリケーションを作ります。
その場には、TDDやペアプログラミングのほか、
計画ゲーム、スタンドアップミーティング、ふりかえり等を
盛り込む予定です。
さぁ、いっしょに過ごしませんか？
究極のプログラミングの楽しいひと時を。
言語はRuby、またはJava。
当日は4人1組のチームを組んで開発します。

  • 感想
    • 開発環境が個人個人ばらばらだったので、やりづらい時もあった。
    • Rubyをあまりやっていない人が多く、コーチの方にかなりお世話になった。
    • ペアプロは楽しかった。
    • 早い段階でいろいろなものが見える化できた。
    • ツールを上手く使わないと、なかなか早くならない。
    • 見積もりが難しく、当初予定が全部終わらなかった。
    • また次もやりたいと思った。
    • チーム開発は楽しい。
    • リズムが重要。
    • TDDの戦略に慣れていない。
    • ドライバーとしての役割。
    • チーム全体がニコニコしながら楽しくやれた。
    • Emacsが多かった。

17:30～18:30 ライトニングトークス

DSL実装技術

  • 言語間の距離と目的
  • 二つの言語の距離を近づける
    • 言語間のインピーダンスを近づける
    • 開発のしやすさが向上する
  • 目的
    • プログラマ以外がプログラムの挙動を変更する
      • システムの動作を柔軟に変えていける
    • 柔軟性を上げて開発効率を向上させる
    • 部分的に高速な言語を利用して速度を稼ぐ
    • 完全に違うパラダイムの言語を使う
      • ベース言語のみでは記述しにくい箇所を補助する

OSDのススメ

  • 開発スタイルの紹介
  • OSD（俺専用 ソフトウェア 開発）
  • 得られる価値は
    • 要求を100%満たす
    • 普段にはない気づき
    • モチベーションを少々
  • たとえば
    • テキスト処理を自動化
    • 画像サイズを一括変換
    • スクリーンショットを自動で保存
  • フィードバック神速
  • オンサイト顧客の究極形

福井市で蝶が羽ばたくと、新宿御苑で竜巻が起こる

  • チャットでじゃんけん
  • 遠隔ふりかえり
  • 遠隔Inbox
    • tracを利用
  • TRICHORD 遠隔かんばん
  • 遠隔JUDE
  • おしまい

謎のIT系同人フリーペーパー現る！？















高橋メソッドを営業のプレゼンで実践してみた

  • crossnoteという製品を作っている
  • 高橋メソッド
    • わかりやすい
    • 頭に入りやすい
    • セールスに使えそう
  • お客様相手にこんなプレゼンしていいのか
  • やった結果
    • 非常にいい
    • あくび率
      • 導入前：27％
      • 導入後：0％
  • セールスに導入する際の工夫
    1. 文字と絵の大きさで強調の工夫が出来る
    2. モザイクを使う
    3. 重要なことは小さく書く
    4. 漫画を使い、言いたいことを言わせましょう
  • まとめ
    • 高橋メソッドは、セールス・プレゼンにも有効

Road to major(?) -- IBM/RationalがAgile Agileいってたよ

  • IBM/RationalはAgileに本気らしい
  • [Q]33/338 これは何でしょう？
    • [A]Agileを題材にしているセッション数 / 全セッション数
  • http://www.ibm.com/rational/agile
  • Jazz - Rational Team Concert
    • Jazzのセッションのようにコラボレートしていく

人生を10倍楽しくする 早起きHACKS！

  • [Q1]自分は夜型だと思う人
  • [Q2]早起きしたいけどできない人
  • 誰でもみのもんたのように朝3時に起きれます
  • 寝る時間によって起きる時間を動的に変える
    • 睡眠時間
  • 毎日レム睡眠の時に起きればよい
  • 起きる時間を固定ではなく、睡眠時間を固定
  • 寝る前に、目覚ましを6時間後にセット
  • 起きた後、日記を書く
  • うたた寝指向
  • 家族を巻き込むな

あなたは本物の新人でしたか？

  • 新人4人が発表。
  1. 生態その1
    • 人生経験が並じゃない
      • 29歳、26歳
      • 年下の先輩までいた
      • 結婚している同期までいた
      • 子持ちの同期もいた
      • 内定後に留年
      • しかも多留
  2. 生態その2
    • 財形貯蓄フル活用
  3. 生態その3
    • 記憶容量ゼロ
  4. 生態その4
    • 国際色豊か
  5. 生態その5
    • 飲み会命
  6. 生態その6
    • 時間厳守
  7. 生態その7
    • 恐ろしい適応能力
  8. 生態その8
    • 先見の目がある

日本コーチ協会東京チャプター

  • コーチを必要とする人々の変化
    1. 正しい答えの無い時代
    2. 自分探しの必要性
    3. キャリアへの考え方
    4. 自立が急速に求められる環境への変化
    5. スピードへの対応
    6. 自分の価値を高める
    7. マネジメント
  • コーチとは
    • コーチング・サポーターなる概念。
  • 何を話すのか
    1. やってみたいこと
    2. 変えたいこと
    3. 好きなこと
    4. 答えを出したいこと
  • 話すとどうなるのか
    1. どんなに小さな事でも、声に出すと想像以上に効果がある

世界を変えるのは他の誰かではない。自分自身だ。


渡辺メソッド

18:30～18:40 終了挨拶


-Blog

Copyright© fullvirtue.com プロダクトオーナー支援スペシャリストのBlog , 2025 All Rights Reserved.