業務の可視化で、多くの関係者を巻き込め！：ユーザーサイド・プロジェクト推進ガイド（19）（2/2 ページ）

[山村秀樹，＠IT]

機能要求仕様の不備や誤りを防ぐ効果も

　機能要求仕様をプロジェクトメンバー、関係部署、ベンダなどで共有するというのは、大変重要です。

　情報の共有には、情報を“ガラス張り”にするという意味合いもあり、内容の不備や誤りをチェックする機能を期待できます。すなわちプロジェクトチームが業務の問題点や要望事項、改善策などを正確に理解し、モレなく仕様に反映しているかについて、業務部門などの関係者がチェックできるということです。逆に業務部門などの関係者から見ても、プロジェクトチームに伝え忘れていることがないかをチェックできます。

　しかし情報共有は、ネットワークやサーバなどのインフラさえあれば、自然にできるようになるというわけではありません。例えば、議事録を電子メールで垂れ流したり、Q&Aシートをファイルサーバにため込むだけだったりでは情報共有にはなりません。このような情報は、トラブルが発生したとき仕方なしに閲覧されることはあっても、まず誰も見向きさえしないでしょう。本来、トラブルとならないように前もってチェックすべきなのですが、これがなされないまま放置されてしまい、いざトラブルというときに慌てることになります。

　未整理で断片的、しかも順不同の情報は扱いにくく、情報利用者が整理しながら内容を読み取る必要があります。この負担を受け入れてまで、機能要求仕様をチェックしてくれる業務担当者は非常にマレです。そもそも機能要求仕様とは業務プロセスの一部であり、業務プロセスの分かりやすいドキュメントがなければ、共有フォルダに配置しても、機能要求仕様の共有になりません。

　業務プロセスを可視化した分かりやすいドキュメントが用意されて、初めて業務部門など関係者が折に触れ、その内容をチェックすることができるようになります。それを踏まえて、より良い解決策が生まれたり、別の課題に取り組んだりできるのです。

　業務プロセスの分かりやすいドキュメントがあれば、当然、機能要求仕様をチームで共有する場合にも便利です。レビューなどでほかのメンバーから意見や提案を求めたり、システムを全体的に見て各機能のバランスを確認したりすることが簡単になります。長期的なプロジェクトでは担当者が代わることも予想され、この場合の引き継ぎ資料としても有効です。

　関係者からの問題提起や解決案、指摘事項だけではなく、ベンダからの問い合わせとその回答なども、このドキュメント上に追記や修正を加えていきます。そうすれば、ベンダ側の認識を確認したり、ベンダ提案の理解をスムーズに行ったりすることができます。そして、これは最終的にシステム稼働後の新たな「業務の分かるドキュメント」となります。

　また、この新たな「業務の分かるドキュメント」は、プロジェクトの進ちょくを管理するためのツールや、業務担当者やシステムのメンテナンス担当者用の教育資料として利用することもできます。

文章によるドキュメントの問題点

　業務を目に見える形にするためには、文章よりも図を作成した方がよい場合が多々あります。

　文章を読んでその内容を理解するということは、読む1人1人が文字や言葉からイメージを展開することであり、各人が頭の中で可視化作業を行っているといえます。このことは、いくら読んでも理解できなかった長大な物語が、漫画になったら理解できるようになった経験を持つ人ならば、よく分かるのではないでしょうか？ 皆さんの周囲にも、まさに図を描きながら報告書などを読んでいる人がいるかもしれません。

　言葉をイメージに展開するということは、「言葉の意味を思い出す」「文章の構造に注意する」「隠れた意図がないかを探索する」「ニュアンスを推測する」など複雑な作業です。この作業は、脳の能力のかなりの部分を使うようで、かなりの集中力が必要です。そのため、本来の作業である業務の評価や検討に専念できないという問題が発生します。

　文字だらけの文書は、読む気になりにくいという問題もあります。とても面白い小説ならいざ知らず、ビジネス文書は文字を目で追うだけでも面倒なものです。字数が少なければ読む元気も出せますが、そうでないと“読む”以前に“見る”気にすらなりません。

　業務プロセスの記述ともなれば、かなりの字数になり、しかも単調な表現が連続するため、読んだとしても斜め読みになってしまい、重要な個所を読み落とす危険性が高くなります。

　また、文章は読む人によって理解や解釈に違いがあり、誤解が生じやすいことも問題です。例えば「A君とB君に相談してください」という指示があったとします。この場合、自分とA君の2人が一緒にB君に相談するのか、自分がA君とB君の2人に相談するのか、両方の解釈ができます。これが口頭や文書ではなくて、適当な図──例えば、自分と記された人のアイコンとA君と記されたアイコンが、並んで別の人のアイコンと向かい合っていて、そのキャプションが「B君に相談する」とあれば、自分とA君の2人が一緒にB君に相談するものと、解釈が一意になります。

（A君と）B君に相談する

（A君とB君）に相談する

　さらに文章では、揚げ足取りなど無駄な騒動が発生することもあります。書き手と読み手の気が合わず、無意味な反論メールの応酬やいい争いの場面を目撃することがあります。周りの人にとっても単に不快なだけでなく、事態の鎮静化のために時間がつぶされるなど迷惑なことです。

　逆に事象や概念を言葉・文章にする作業も、思ったより複雑で難しいプロセスです。何らかの発表資料やレポートを作成するときに「言葉が見つからないな」「話をうまくまとめられないな」などと困ることは結構あるでしょう。普段のコミュニケーションは意外に言葉だけで行われているわけではなく、語調や表情、態度にもよっているのです。「思うことを言葉だけで伝える」というのは意外に難しく、習練なしにはなかなかできないものなのです。

　イルカはイメージでコミュニケーションをしているという説があります。本当ならば実にうらやましい能力を備えているものです。しかし、人間がイメージでコミュニケーションを取ることは工夫なしにはできません。工夫された図が必要なのです。この工夫が適切だと「分かりやすい」と評価されることになります。

　「業務プロセスの分かりやすいドキュメント」を作成するということはまさしくこれを実現する作業です。この業務の分かるドキュメント──すなわち業務の可視化ツールとして最適なのが、業務プロセスフロー図です。次回は業務プロセスフロー図について考えます。

筆者プロフィール

山村 秀樹（やまむら ひでき）

某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、中でもシステムの開発プロセスについて興味を感じている。

Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。

「ユーザーサイド・プロジェクト推進ガイド」バックナンバー

• 業務の可視化で、多くの関係者を巻き込め！
• 工夫と規律で「システム用語辞書」を実現せよ
• 社内用語を統一する「用語辞典」作成のポイント
• 言葉の不統一がもたらす業務とシステムへの悪影響
• ドキュメントを作成しないユーザーは、失敗する
• プロジェクトメンバーがそろう前に行っておく事前準備
• システム開発プロジェクトの魅力を伝えよう
• プロジェクトチームのマインドとルールを方向づけるには
• プロジェクトキックオフ！ オリエンテーションで話すこと
• プロジェクトリーダーは十二分な準備で自信を生み出せ
• プロジェクトチームのリーダーに向く人、向かない人
• プロジェクトチームにおける“システム担当者”の役割
• プロジェクトチーム結成──業務部門との関係を考える
• プロジェクトチームに付きまとう制約を打破するために
• タイプ別プロジェクトチームの問題点
• 不良システムを作らないプロジェクトの枠組み
• スケジュールとコストは、ユーザー側が始めからつかめ
• 最初が大切──構築システムの“概要”を作る
• ユーザー企業側プロジェクトチームの使命と役割