前回，Openthologyの立案フェーズではビジネスの本質レベルでの可視化を行い，プロジェクトで注力すべき攻略点を特定することを述べました。そのために，立案フェーズにおけるモデリングでは，ビジネスの構造とメカニズムを大枠のレベルで可視化します。
LFD（Lane Flow Diagram）は，ユーザー企業により考案された表記法ですが，業務の全体像を大枠で可視化できることから立案フェーズでの使用に適しており，Openthologyにプラグインされています。
LFDは，ユースケースをUMLのアクティビティ図のようにレーン上に並べた図です（図1）。LFDの記述に難しいルールはありません。設計する業務のステークホルダーごとにレーンを用意し，業務の流れの記述に徹するだけです。
 図1●LFD（Lane Flow Diagram）のサンプル [画像のクリックで拡大表示] |
具体的には，業務の流れに従って，何らかの作業や処理の存在する個所（ノードと呼んでいます）にアイコンを記入し，業務の流れを実線の矢印で結びます。説明上，データの流れを記述したほうがわかりやすい場合は，点線の矢印で補助的に記述します。
LFD上には，必要に応じてヤコブソン表記のアイコンを記述します。例えば，業務フローの中でシステムが何らかの自動処理を行う場合には，コントロール（Control）の記号を記述します。別に何の記号でもよいのですが，直感的にわかりやすいので使用しています。
ビジネスは人とシステムにより構成されます。開発対象のシステムについて，「（そのシステムは）誰に，いつ，何をする」というユースケースを明らかにし，業務部門の担当者に提示することも必要になります。そこで有効なのがシステムと外部世界との境界線である「バウンダリ（Boundary）」の記述です。具体的には，「画面」や「帳票」の出現タイミングを明記します。
さらに，業務部門の担当者に具体的な業務をイメージしてもらう目的で，画面のモックアップを作成します。モックアップはHTMLなどで作成する画面のラフスケッチであり，検討の過程で随時変更されます。
LFDとモックアップを組み合わせて提示することで，業務部門の担当者は，どのタイミングで，どんな画面で，何をするかをイメージできます。また，業務の流れの全体像を俯瞰してとらえることにより，活発な議論が可能になります。
LFDは，業務の全体像を俯瞰してとらえることを目的に考案された図です。このため，多数の分岐を伴うなど，詳細な業務フローの記述には適していません。まずは，標準的な業務フローについて大枠で検討・合意し，イレギュラーな処理や業務の詳細は別途（要求開発の場合は，デザインフェーズで）検討するといった使用方法が有効です。
業務部門の担当者と検討を始める際，そのきっかけとして提示する資料は非常に重要です。叩き台の「案」として，LFDとモックアップを作成すると，ユーザーは新しい業務の全体像や，関与する部署，自分の責務と業務の内容が大枠でイメージでき，活発な議論が可能になります。
集中検討会の開催
叩き台としてのLFDができあがると，各レーンに記載された部門の担当者を訪問し，LFDと，担当者にかかわりのある画面のモックアップを提示します。「新しい仕事のやり方」について可視性が高まることから，活発な議論が展開し，業務フローに無理はないか，画面の項目や機能に漏れがないかなどの調整が可能になります。調整の過程で，LFDとモックアップは必要に応じて修正します。こうして，あいまいだった業務要件は次第に明確に整理され，ビジネスモデルはブラッシュアップされていきます。
各部門との調整が終わり，LFDとモックアップの修正が完了した時点で，「新しい仕事のやり方」のあるべき姿の「仮説」ができたことになります。次のステップは「仮説」の検証です。この段階で関連部門のキーマンを一堂に集め，集中検討会を開催すると，効率よく合意形成ができます。
集中検討会では，LFDの業務の流れに沿って，画面機能の確認や，事前に準備した課題リストをもとに全体の場で検討・調整すべき事項について，検討を行います。関係者が揃っている場で，検討を行い，できるだけその場で結論を出すように留意します。事前に調整を行っていることもあり，全員の理解を前提に仕様を決定することができます。
詳細な検討が進んだ段階で，ビジネスの大枠に変更が発生すると，大きな手戻りにつながります。この段階で，ビジネスの大枠について合意を得ておけば，その後に発生する変更は，システムのユーザー・インタフェースに関するものなど，プロジェクトへの影響が軽微なものに集約されます。プロジェクトのリスクの最小化の観点から，検討会は非常に重要といえるでしょう。
集中検討会を終えたら，指摘事項や積み残し課題の調整結果を反映し，LFDとモックアップを確定します。これにより，業務の大枠についての設計は完了となります。
さて，冒頭で，LFDがOpenthologyにプラグインされていることを述べました。Openthologyは，要求開発に役立つ手法をプロセスセルという単位でプラグインしています。次回は，Openthologyのプラグインについて紹介します。
| （野田 伊佐夫＝要求開発アライアンス 執行委員長） |
