Re-Introduction to Openthology

要求開発再入門萩本　順三 MAMEZOU　 The solution beyond the solution.

要求は「開発」するもの • 「要求分析」、「要求定義」などは、要求がすでに存在しているという前提に立っている • ユーザからヒアリングした要求の実現が業務効率化に結びつくとは限らない。 – ユーザの理解の範囲内で生まれた属人的なもの – 直感的、場当たり的であることが多い • 要求は、業務を分析することによって開発される。ロジカルに導かれる必要がある。 MAMEZOU　２．要求開発方法論とは　　 The solution beyond the solution. 動機編より抜粋

なぜよいシステム開発ができないのか？ – 最悪のシナリオ業務理念を統制し、業務効率化を図るための業務とは ○○あるべきだよ。業務管理者の論理あの業務は、○○パッケージや我々のやり方がベストなん ○○フレームワークを使って開発だ。これにあわせてシステムすれば簡単だよ。業務は、それにあわせればいい壁を作ってくれよ。。システム開発者の論理業務担当者の論理 MAMEZOU　２．要求開発方法論とは　　 The solution beyond the solution. 動機編より抜粋

それは、正しいシステム要求がだせないから • うまくいきそうで駄目なシナリオ（その１） – トップ・業務管理者の考えどおりのシステムを作ったが、業務担当から大クレーム。 – 結局使われないシステムになった。業務理念を統制し、業務効率化を図るための業務とは ○○あるべきだよ。業務管理者の論理わかりました。おっしゃるとおり、あの部長、業務の事をなにも分かっていないんだよね。業務効率化案に基づいた要求を考えていきましょう。壁でも、あの人のいうこと本当にただしいのかなあ？まあ、いっか。システム開発者の論理業務担当者の論理 MAMEZOU　２．要求開発方法論とは　　 The solution beyond the solution. 動機編より抜粋

それは、正しいシステム要求がだせないから • うまくいきそうで駄目なシナリオ（その２） – 業務担当者からそれぞれ要求を聞きだした。 » 業務の標準化ができない。 » 効率化を考慮していない業務にあわせてシステムを作ってしまう。業務理念を統制し、業務効率化を図るための業務とは○○あるべきだけど、業務担当は、みんな既存システムのやり方に慣れてしまって本当に改善しようとおもっていないんだ。業務管理者の論理我々のやり方がベストなん分かりました。業務担当の方々だ。これにあわせてシステムに合わせて、システムを開発します。壁を作ってくれよ。だけど、それぞれの担当者から出てくる要望を開発するのは大変だよな。ま、いっか。システム開発者の論理業務担当者の論理 MAMEZOU　２．要求開発方法論とは　　 The solution beyond the solution. 動機編より抜粋

要求開発とは – 正しい要求の獲得と合意のための活動業務理念を統制し、業務効率化を図るための業務とは○○あるべきだ、しかし現実は △△だから、それをどう改善できるか現場と話し合ってみよう。業務管理者の論理あの業務は、○○パッケージや○○フレームワークを使って開発すればよさそうだ、し我々のやり方がベストだと思っていたけど、かし、本当に求められている業務の姿を明見方を変えれば欠点が多いね。問題分析ツ確にして３者で合意しなければ、真の要求問題の視覚化(モデル)とリーでもう少し業務のあるべき姿を考えてみなど獲得できるはずがないね。改善プロセスによる活動よう。コタツ開発された要求システム開発者の論理（システム要件）業務担当者の論理モデル MAMEZOU　 The solution beyond the solution.

要求（正確に言うと要求仕様）はどうにでも定義できる！ビジネス戦略最適解はどれだ！ＩＴによる付加価値注入現場の問題解決　　　　問題解決 MAMEZOU　 The solution beyond the solution.

要求の重要性 • 米国Standishグループの調査によれば、システムに作りこんだ機能のうち、結果として利用されているのは３６％だということです。これは言い換えると３分の２のシステムが「役に立たない」ということにもなります(Standish group study report in 2000 chaos report)。このような「大いなる無駄」を排するためには「正しい」要求にもとづくシステム開発が必要となります。要求開発は、システム企画の段階からRFP（Request For Proposal）の作成まで、一貫して「目的と手段の連鎖」を見える化していくプロセスです。これにより、ステークホルダー間の合意をとりながら、企業経営への貢献という最終的な目的を実現させるためのシステム開発を推進していきます。 MAMEZOU　 The solution beyond the solution.

開発プロセスオーバービュー広義の要求開発（要求定義）狭義の要求定義ＢＤＡ経営分析要求開発広義のシステム開発ビジョン、ミッションの確立問題点分析準備立案デザイン移行ビジネスゴール設定狭義のシステム開発ビジネスユースケースシステム開発システム化範囲の導出財務的解決やマーケ業務フロー（As-Is、To-Be) 方向付け　推敲　　　　　構築　　　　　　移行ティング的解決で終わロードマップ作成業務レベルの概念モデルる課題もあるシステムユースケースの抽出と個別プロジェクトへのブレークダウン第１　プロジェクト方向付け　推敲　　　　　構築　　　　　　移行ビジネス戦略の見える化、プロジェクトスコープとリソー業務要求の獲得スを確定しゴールとプロセスの見え第２　プロジェクトを明確化。る化、ITの基本要方向付け　推敲　　　　　構築　　　　　　移行求の獲得。狭義のプロジェクト第３　プロジェクト広義のプロジェクト 9 MAMEZOU　 The solution beyond the solution.

要求開発方法論（Openthology）構造とモデル • 戦略とサービス構造中心でモデル化 – ビジネス戦略からプロジェクト戦略へ – 業務のサービスの明確化 • 企業の意思決定層とビジネスオペレーション層の構造を確立（見える化） – 企業の意思決定層の戦略を、ビジネスオペレーション層のサービスまで具体的に落とし込むメソッドを持つ。ビジネス戦略ビジョン：ゴール構造ビジネスオペレーションサービス構造ビプロセス構造情報構造ジネオブジェクトスビジネス・プロセスビジネス要求モデル　　　　　　　　　　　　システム要求データアプリケーション・プロセス I モデル T シスアプリケーションテムフレームワーク実装アーキテクチャ MAMEZOU　 The solution beyond the solution.

Openthology構造とモデル Openthology ユースケース記述ユースケースモデル BSC戦略マップ業務フロー（アクティビティ図）ビジネスユースケースモデル　ビジネス概念モデルビジネス戦略　分析・設計モデルビジョン：ゴール構造　　　　クラス図ビジネス　DB 　　モデルビプロセス構造サービス構造情報構造ジネスオブジェクトビジネス・プロセスビジネス要求モデル　　　　　　　　　　　　システム要求データアプリケーション・プロセスモデル I T シアプリケーションステムフレームワーク実装アーキテクチャ 11 MAMEZOU　 The solution beyond the solution.

要求の基本（ビジネスからシステム開発につなげる表と裏）戦略オペレーションビジネスビジビジネス戦略オペレーションネス What 表（価値）　 How 裏（実現） What 表（価値）　裏（実現） How シス表（価値） What How裏（実現）テムシステム要求システム設計 MAMEZOU　 The solution beyond the solution.

戦略のトリアージ　課題　オペレーションビジネス戦略ビジネス戦術トリアージされた戦略ビ改善・改革が必要な業務処理ジネス製品要求　トリアージ（triage）：要求を戦略的に取捨選択する事。製もともとは医学用語で、有限のリソース（医師や医薬品品など）を最大限に活用し、各患者の病状や状況に開合わせて、より多くの傷病者の治療をするために優発先順位を決定することを指す。付録：発刊予定書籍トリアージされた　「成功する要求仕様、失敗する要求仕様」日経ＢＰ要求　アランＭデービス著、安井・萩本監訳、高嶋訳 MAMEZOU　 The solution beyond the solution.

Structure Openthology ver2.0 モデル・ストラクチャ図ビジネス戦略ビ　　戦略ビュービジネス戦略ＩＴ戦略ジネプログラム戦略スプロジェクト戦略サービス　ビュープロセス　ビュー情報　ビュービジネス要求ビジネス・プロセスオブジェクトモデル　　　　　　　　　　　　ＩＴアプリケーションシステム要求データシ・プロセスモデルステムアプリケーションフレームワーク実装アーキテクチャ MAMEZOU　 The solution beyond the solution.

Structure Openthology ver2.0 Structure & Reference 　　Business Strategy　　　　　Reference Model 　　IT Strategy Reference Model 　　ProgramStrategy ビジネス戦略 Reference Model ビ　　戦略ビュービジネス戦略ＩＴ戦略ジプログラム戦略　　Project Strategy ネプロジェクト戦略 Reference Model スサービス　ビュープロセス　ビュー情報　ビュービジネス要求　　Information オブジェクトビジネス・プロセスモデル Reference Model 　　　　　　　　　　　　Ｉアプリケーションシステム要求データＴ・プロセスモデルシスアプリケーション Openthology 本質　ビューテフレームワークム戦略実装アーキテクチャサービス　　Service Reference Model プロセス情報　　Process Reference Model MAMEZOU　 The solution beyond the solution.

モデルの役割(Ver1.0) 観点のビジネス課題ビジネス・オペレーションシステム要求システム設計流れ業務プロセスからIT要求へプロセスモデルサービスモデル・業務フロー・システムユース　ケース戦略モデルサービスモデルアーキテクチャモデル・BSC戦略・ビジネス　マップ　・ERD/DB設計　ユースケース・IT貢献度　マップ情報モデル　・アーキテクチャモデル・プロジェクト　ゴール記述書 TFP分割手法　・SOAモデル　・Thing図　・Function図　・Place図ビジネス概念からITアーキテクチャへ要求開発フェーズ準備立案デザインシフトシステム開発フェーズ８．要求開発ビジネスモデリング応用編 MAMEZOU　 The solution beyond the solution.

Structure （要求開発）戦略ビューサービスビュープロセスビュー BSRM PJSRM SRM PRM 財務顧客プロセス コタツモデル教育 BSC戦略マップ原価計算方式の見直しと経理部の豆蔵のチェック作業自動化入力の分散負荷の削減 ad アクティビティ決算早期化（経費･勤怠）早期の決算報告連結決算提出期限のの自動化手作業の自動化厳守 ud ユースケースモデル社会的適正な内部統制のﾘｽｸﾎﾟｲﾝﾄの把握ｺｽﾄ･売上信用度の向上情報開示新規事業の確立良質案件コントロール予測の正確な営業マンを発生元でのリアルタイムの把握業務増やす直接入力立上げ値上げ差別化営業の二重入力のデータ連携 プロジェクト（事業部、福数人で）ｽﾃｰﾀｽ一覧売上増提供価格営業力強化新規を増やす事務処理付加価値増信用度削減維持･向上（間違いの防止）（付加価値向上）（単価）をあげる負荷軽減案件の適切なシステムによる金額実績優先順位つけ案件情報の見落とし案件営業会議での契約期間、既存事業の稼働率を上げる案件件数をリピートを増やす提供時期の撲滅適切な営業 ToDo作業の職務経歴の情報共有売上拡大増やす生産性向上入力作業の簡素化二重入力の排除把握活動迅速な提供タイムリーな個人別スキル開始終了人数積極的採用操作性向上レスポンスアサイン状況提案情報の把握利益向上回線障害の回避（企業価値利益の（要員数）離職率をモチベーション社内情報のタイムリーな向上）維持把握減らすアップ案件情報契約管理適正な評価個人売上のの共有リアルタイムな事業の円滑プロジェクトの適切な予算収支管理表　　ゴール記述書な運営円滑な運営予実管理精度ある実績把握売上･経費プロジェクト情報適正な運用情報（経費･工数･アサイン）タイムリーで事業部、ﾁｰﾑコスト減チャンスロス事業部単位での売上予測予算と実績ののタイムリーな入力高精度な把握毎に異なる (ロスセーブ) （機会損失）予実管理同一粒度での社内振替のﾋﾞｭｰが必要対比管理厳正な評価精度ある情報共有適正な稼動予実一覧（アサイン表）･活用アサインメント（適正な勤怠の承認（スキル･思考）労務管理 概念アクティビティ図 要求リスト 要求分析ツリー ビジョン分析ツリー プロジェクト定義 ビジネスユースケース 問題分析ツリー ステークホルダー分析 ターゲット分析情報ビュー 概念クラス図　 ☆TFP分割　（Thing図、Function図、Place図） cd 論理モデル 0..* 1..* 0..* 0..1 1 0..* IT貢献度マップ 技術マップ ゴール記述書 プログラム計画　　　 ITSRM What What PSRM IRM How How MAMEZOU　 The solution beyond the solution.

Structure（要求開発からシステム開発へ）要求開発システム開発プロセスビューサービスビュープロセスビュー PRM ? s d 相互作用論理モデル:: 論理モデル:: 論理モデル:: 論理モデル:: 論理モデル:: イベントフロー ad アクティビティ業務情報開始終了 シーケンス図 概念アクティビティ図 要求リスト ud ユースケースモデル cd 設計クラス図 cd 設計クラス図情報ビュー情報ビュー システムユースケース 概念クラス図 ユースケース記述 cd 分析クラス図 設計クラス図　 ☆TFP分割（アーキテクチャ）アプリケー id コンポーネントモデル 0..* 　（Thing図、Function図、Place図）スコーション 1..* パッケージ 0..* プ 0..1 cd 論理モデルパッケージ 0..* 1..* 0..* 0..1 1 0..* パッケージアプリケー 配置図レベションエンターズレベルルプライ What What IRM How How ＥＲ図 MAMEZOU　 The solution beyond the solution.

システム開発におけるＶ字モデルシステム要件受け入れテストサブシステム要件サブシステムテストコンポーネント要件コンポーネントテストモジュール要件単体テスト MAMEZOU　３．要求開発の意義 The solution beyond the solution.

要求開発の目指す・変形Ｖ字モデル要求ビジネス要求 Verification Validation 開発評価ビジネステスト結果イメージの予測シス評価システム要件受け入れテストテム開発評価サブシステム要件サブシステムテスト評価コンポーネント要件コンポーネントテストモジュール要件単体テスト MAMEZOU　３．要求開発の意義 The solution beyond the solution.

ToBeビジネス（結果イメージ）の予測戦略の根拠 Why 戦略の根拠戦略の根拠 Why Why ビジネス戦略 What 準ビジネス戦略ビジネス戦略備 What What 立案デザイン・方式 How シ方式フ How ト方式 How 方式方式 How How MAMEZOU　 The solution beyond the solution.

ビジネス価値とビジネス方式関係価値価値価値 What What What A 方式How 方式How 方式How 要求開発（時間軸）価値価値価値 What What What B 方式How 方式How 方式How 要求開発（時間軸） MAMEZOU　 The solution beyond the solution.

ビジネス戦略のトリアージ優先順位ビジネス戦略２００７年３月新たに見つけられた戦略引き継がれる戦略１年トリアージ後選択された戦略要求を開発２００８年３月（実現）新たに見つけられた戦略引き継がれる戦略トリアージ後選択された戦略７ヶ月要求を２００８年１０月開発トリアージ後選択された戦略 MAMEZOU　 The solution beyond the solution.

これからのアーキテクトの課題ビジネス IT システムシステム現状ビジネスとITを分けて考える要求設計実装（WhatとHowの分離） What How ビジネス IT システムビジネスビジネスオペシステム NEXT ビジネスの見える化手法を確立戦略レーション要求設計実装（戦略と実現の分離） What How What How What How ビジネス IT システム見える化を目的で繋げるビジネスビジネスオペシステム NEXT 戦略レーション要求設計実装（分離したもの同士の最適なリレーション） What How What How What How NEXT Howからの突き上げによるビジネス価値増大のための見える化 MAMEZOU　 The solution beyond the solution.

要求開発プロセス（プロセスキャビネット）のイメージ Structure Phase：　　　　段階的に詳細化・具体化していく Disciplines 準備立案デザイン　シフト　 Plan 作業項目名作業項目名 Do P P P P D D D D Check C C C C Act A A A A ７．要求開発プロセス MAMEZOU　 The solution beyond the solution.

実際のプロセスキャビネット要求開発プロセスキャビネット段階初期知識の可視化と合意に基づく計画ビジネス課題に関する概観の可視化新ビジネスのデザインシステム開発への移行 Phase 準備 arrangements 立案 draft デザイン design シフト shift Decipliens ・フェーズ基本計画・フェーズ基本計画・フェーズ基本計画・フェーズ基本計画・要求開発プロジェクトのゴールの設定・モデリング戦略策定・ToBeモデルの評価方法の策定・システムToBeモデルの評価方法の策定・要求開発チーム編成計画・ビジネス要求評価方法の策定・IT基本要求の評価方法の策定・IT基本要求の評価方法の策定 Plan ・準備教育計画作成・教育計画の作成・ビジネス可視化プロトタイプ計画・システム移行計画書達成評価基準の明・ビジネス可視化プロトタイプ計画の見直し確化・システム基本構想策定計画・システム基本構想策定計画・要求開発プロセスのカスタマイズ計画・実施計画書作成・ビジネス課題の理解・概観ビジネスモデリング・ビジネスToBeモデリング・システムToBeモデリングビジネスモデル・プレビジネスモデリング(Option) ・ビジネス要求の開発・IT基本要求の開発・IT基本要求の開発 Do 要求モデル・コアメンバー教育 (Option) ・要求開発メンバー教育・動機付けセミナー(Option) 教育・教材の作成(Option) ・プロトタイプ開発・プロトタイプ開発・システム移行計画書作成システム化・承認権限者による検証・承認権限者による検証・承認権限者による検証・承認権限者による検証・メンバー責務・スキルの確認・プロジェクトミッションの評価・ビジネスToBeモデルの評価・システムToBeモデルの評価 Check ・モデリングの評価（Option）・モデリング戦略評価・IT基本要求の評価・IT基本要求の評価・ビジネス課題の評価・概観ビジネスモデリング評価・プロトタイプの評価・システム移行計画書内容の評価・教育実施評価・システム基本構想の評価・計画の見直し・改善・計画の見直し・改善・計画の見直し・改善・計画の見直し・改善・メンバー構成の見直し・構想の見直し・改善・構想の見直し・改善・すぐやるカイゼン・教育計画の再計画・すぐやるカイゼン・すぐやるカイゼン Action ・必要であればビジネス課題の理解のやり直し・メンバー構成の見直し・必要であれば、再教育を期間を検討する・すぐやるカイゼン７．要求開発プロセス MAMEZOU　 The solution beyond the solution.

要求開発のフェーズ準備 ■ビジネス戦略の把握とプロジェクト課題の見極め　・ビジネス戦略、ＩＴ戦略の見える化　・プロジェクト課題の見極めのための、ざっくりとした見える化　・必要人材のアサイン（我々で果たしてプロジェクト課題を解決できるか？：リソース）　・プロジェクトターゲット範囲の決定（どの領域をどこまでやるの？：スコープ）　・要求開発プロジェクトゴールの策定立案 ■概観の把握と可視化　・モデリング戦略（ToBe、AsIs業務モデルの把握のための順序戦略）　・プロジェクトゴールにスコープしたビジネス領域の外観を見える化（攻略点の把握）　・当初から課題とされているビジネス要求の抽出と整理（本質的見極め）デザイン ■ToBe業務の設計　・ToBe業務の設計　・ビジネス要求開発、IT基本要求の開発シフト ■システム計画　・IT基本要求の抽出　・システム移行計画書の作成７．要求開発プロセス MAMEZOU　 The solution beyond the solution.

要求の開発および獲得 • 要望 – 業務視点でだされた、ビジネスおよびシステムに対する「XXXのためにXXXしたい。」といった要望。 • 要求 – 要求開発チームで、意味不明な要望、要望の重複排除、似ている要望を整理することで要求に格上げされる。 • 要件 – 期間コストを踏まえて、どのシステム開発で取り入れるのか決定されたシステム要件。３．要求開発における要求 MAMEZOU　の開発および獲得 The solution beyond the solution.

要望-要求-要件への変化トップ・品質管理　例：　「検査業務を早く、安く、正確に！」　管理者・品質管理（業界標準等）ビジョン　　　　　　　　例：管理者「効率化を図るために、再測を止める」　　　　　　　　　　品質管理「セキュリティのために、個人特定機能が必要」方針目的対策現場　例：担当者「業務ミスを犯さないために、二重チェックを行う」個別方針要望　要求　要件　（会議体で分析）・システム化対象の選択・システム化実現方法の　選択検討と合意（会議体で検討）･リリース予定日の設定・重複を省く　業務要求　業務要件･グループ分け・重要度の管理 0…＊・業務かシステムかの判断（会議体で分析）・コンセプトの再確認　システム要求　システム要件・要求の優先度付け・運用方法の確立・目的に対する対策を分析・例外事象の洗出要求　し、参加者の納得できる・システム利用方法方法を仕上げる。・上記の標準化　機能要求　ユースケースコンポーネント３．要求開発における要求非機能要求　アーキテクチャ MAMEZOU　の開発および獲得 The solution beyond the solution.

要求の生息地 • 原住民 – 初めから企業ミッションの中に生息している、そもそも達成すべき最優先要求。 – いままでの業務の延長から見つかる要求。 – いままでのシステムの中に生息して、今後も必要となる要求。 • 未開の土地 – 業務改善により始めて姿を見せる要求。恥ずかしがりやで、まだ形がはっきりとせず、個人の意識の中に眠っているので、みんなで目に見えるように可視化しないと出てきてくれない。 • 暗黙知域 – 業務メンバーと開発メンバーの意識の中に暗黙知として眠っており、これが基で様々なトラブルを引き起こす。３．要求開発における要求 MAMEZOU　の開発および獲得 The solution beyond the solution.

ＴＦＰ分割概要（なぜＴＦＰ分割か？） • データモデル – 長所 • 物と場だけに着目する。所詮はデータ集合を静的に現すものなので、非常に解りやすく曖昧性がない。 – 短所 • 機能（業務）との関係が希薄。業務処理の概念化が異なる図 (DFD)として表現するしかない。 • オブジェクト（クラス）モデル – 長所 • 機能的なクラスを抽出するために、機能概念を含んだ自然な概念世界を表現できる。 – 欠点 • 概念の中に機能的なクラスが存在すると、機能の中に関連が隠されてしまったり、機能の入出力関係と、「もの」と「もの」との関係が混在することになり非常に曖昧になる。 MAMEZOU　 The solution beyond the solution.

Thing、Function、Placeにクラスを分類する Thing …もの（情報）として識別された単位。　 Entity(属性の集合が一般的) •イベント（事象）やトランザクション（取引）イベントトランザクション　の結果・記録も「もの」に分類イベントの記録として Thingに置くのがポイント概念（クラス） Function …機能として識別された単位　 Control(機能名がクラス) 　　通常、属性と操作がない。　 Place …場所を示す MAMEZOU　 The solution beyond the solution.

クラスを　Thing、Function、Placeの中でさらに分類する大分類小分類事例リソース系科目商品顧客店モノ Thing イベント系仕訳取引注文コト機能系取引業務注文業務概念（クラス） Function スルルール系Ａ取引Ｂ取引キソク Place 場所系会社バ MAMEZOU　 The solution beyond the solution.

Thing図の例 Thing図には Function と Place を含めてはならない。 Thing図例ピンク系統で表現。またはステレオタイプ<<Thing>>を使う cd 論理モデル cd 論理モデル +貸し方 0..1 1..* 客顧客仕訳勘定科目 +借り方 1 1..* 0..1 1..* 1 +対象科目 0..* +購入商品 1..* 1..* +月次単位商品 BS/PL 累積データ科目 - 借り方計: int 1 1 - 貸し方計: int ものとものとの関係 MAMEZOU　 The solution beyond the solution.

Function図の例 Function図には Thing を含めてよい Function図例グリーン系統で表現。またはステレオタイプ<<Function>> cd ? +貸し方仕訳 0..1 1..* 勘定科目 +借り方 0..1 1..* 支社支社月次更新累積データ BS/PL - 借り方計: int 科目 - 貸し方計: int 1 1 ものの使われ方（ものの価値証明） MAMEZOU　 The solution beyond the solution.

Place図の例 Place図には Function と Thing を含めてよい Place図例１クラス表現の場合　　　…ブルー系統で表現。またはステレオタイプ<<Place>> パッケージ表現の場合…特になし cd もの・ことを置く場の本社 +購入商品定義場により価値が出る！商品顧客 1..* 0..* <<購入される>> 店舗売上 MAMEZOU　 The solution beyond the solution.

ＴＦＰ分割手法まとめビジネス具現的概念ビジネス普遍概念（ビジネスの価値に着目）（ビジネスの本質に着目） Place図 Function図 Thing図 Thing Function Thing Place ものとものとの関係 Function ものの使われ方ものとことをおく場の定義ビジネス分析対象ＳＯＡオブジェクト汎用概念開発に移行可能な概念分散協調設計アーキテクチャ設計ＤＢ設計 MAMEZOU　 The solution beyond the solution.

Re-Introduction to Openthology

by Kent Ishizawa on May 13, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 2

Statistics

Re-Introduction to Openthology — Presentation Transcript