「ユーザのための要件定義ガイド」（100ページ）第4章「ビジネス要求の獲得」では、要件定義工程においてプロジェクトメンバー間での情報共有の困難さについて言及されています。
以下に原文を紹介しつつ筆者の経験を踏まえて対応策を考えてみたいと思います。
(2)現状業務・システムを理解・共有する
【解決したい問題】
•現状業務やシステムの分析をしたが、分析した当人以外、誰も内容を把握できておらず、分析結果や全体整合の結果が正しいかどうかがプロジェク卜として判断できない
•自分が担当した部分を他の誰もわかっていない
•全体を把握している人がいない
•業務運用担当者が理解していない
現行業務やシステムを可視化するとき、分担して作業を進めることがある。そのとき可視化を担当した人しかそこの内容を理解していないという状況がまま発生する。そうなると、ドキュメント作成が手段から目的に変化してしまい、作成が終われば可視化による現状の把握もその時点で達成したという勘違いにつながる。また、業務部門でも自身の業務の全体が把握できなくなっていて作業結果の妥当性を確認できない場合もある。そうなった場合には、この機会に双方で積極的に業務の理解を進める必要がある。
勘どころ①プロジェクト全員での共通認識プロセスを実施する
プロジェクトのメンバーひとりがドキュメントを作成するだけでは不十分である。現状に対する共通認識をプロジェクト全員で形成しなければ、同じ方向性を持って問題、ニーズ、課題の分析や目的、手段の検討もできない。
そのため、作成した業務シナリオのプロジェクト全員での読み合わせやウォークスルーを通じて関係者間での認識違いを浮き彫りにするなどをして、お互いの認識を再確認することが必要である。
|
ウォークスルーとは システム開発の分野では、開発プロジェクトのメンバーが一堂に会し、仕様や構成の問題点を探したり解決策を討論したりする作業のことをウォークスルーという。 正式なレビューなどとは異なり、必要に応じて短時間開催されるインフォーマルな検討会で、プロジェクトの管理者は参加せずに作業者のみで開かれる場合が多い。特に要件定義や仕様策定、設計などの上流工程で行われることが多い。 （出典：IT用語辞典（e-Words)のサイト） |
筆者は三十数年前に大手銀行の第三次オンライン開発において外為勘定系システムの要件定義を経験しました。当時のチームメンバーは約15人でしたが各自がそれぞれの分野を専任として担当しており、要件定義も各自に任されていました。しかし、全体の整合性は歯車がかみ合うように常に保たれており、全体の流れを踏み外すメンバーはいませんでした。
対策としては、毎週月曜日の定例朝会で各自の進捗状況・問題点の発表と意見交換が行われていましたが、各自の専任分野を担当していたとは言え必ず誰かとインターフェースがあり、「お前のA業務が決まらないとこっちのB業務が決められない。いつまでに決まるんだ。早く仕様をよこせ。」とか喧々諤々のウォークスルーが行われ、定例以外でも別フロアに別れているメンバーのところに頻繁に足を運んで確認するなど（殆ど喧嘩に近い）コミュニケーションがとられていました。
また、要件定義が書きあがると必ずピアツーピアでのレビューが行われなした。
このコミュニケーションは、単に意思疎通ができたというだけでは実現出来なかったと思います。それは、各自が「外為勘定処理」についての業務知識があったことに加え、15名が何年もかけて取り組まなければならないほどの「要件定義の量」ではありましたが、全員がプロジェクトの「全体感」を把握していたからだと思います。勿論、チームリーダーの力量も特筆されるべきものでした。
では・・・なぜ、超が付くほどの大プロジェクトで上記のことが出来たのか・・・を考えてみると、それは「体系」がしっかり描かれていたことだと思います。
図１
実は、この新システムでは旧システムには無かった画期的な概念が採用されていたのですが、その概念を基本として新しい「外為勘定処理の原則」が策定され、メンバー全員がその原則に沿ってそれぞれの担当部分を一貫した考え方で検討を進め、且つ、横軸での整合性も常に保たれるようにコミュニケーションがとられていました。
もう一つ付け加えるとすると、開発早期からデータベースの設計を進めこれが共有されていたことも大きな成功の要因だったと思います。（データベースの設計については別の機会に書きたいと思います。）
図２
と、いう訳で・・・筆者の経験から言えることは、通り一遍の「システム化計画書」で「要件定義」に着手してしまうと、冒頭のガイドに指摘があった「現状業務やシステムの分析をしたが、分析した当人以外、誰も内容を把握できておらず、分析結果や全体整合の結果が正しいかどうかがプロジェク卜として判断できない」という状態に陥ってしまうと言うことです。
図２に示したように、以下のポイントが重要です。
1. 要件定義の骨格となる基準を定義する。
2. 各メンバーが担当する個別の機能について上記「基準」を共有する。
3. 個別の機能が横断的機能に対して不整合な（矛盾のある）機能を展開しないように配慮する。
その為には、このシステムが何を目的としているかを明確にしつつ、以下のポイントをメンバーで議論し自身の担当分野では何に配慮しなければいけないか、また、他の担当者と何を共有しながら進めることが必要かについて共有しておくことが重要です。
別の言い方をすると・・・
1. 各メンバーは全体としてどのような「業務の構築」及び「システム開発」をしようとしているのかを理解する。
2. 各メンバーは、自分がその中でどの部分を担当しているのかを理解する。
3. 各メンバーは、自分の担当部分と他のメンバーの担当部分がどのように関係しているかを理解する。
4. 各メンバーは、横断的機能に対して自分の担当がどのような影響を及ぼすのかを理解する。
5. その上で、各成果物はピアツーピア・レビューを行う
そうした上で、要件定義の進捗について定例的に情報交換を行い、プロジェクト全体の中で自分が今どこにいるのかを常に認識できるような環境を作っておくことが重要です。
また、そうすることでリーダーは、チーム全体の進捗状況や、各メンバーが抱えている問題や遅れなどを把握することが出来ますし、ピアツーピア・レビューにより一定の情報共有が可能です。