プロジェクトチームのマインドとルールを方向づけるには：ユーザーサイド・プロジェクト推進ガイド（12）（1/2 ページ）

システム開発の経験に乏しいメンバーからなるプロジェクトチームは、最初の“オリエンテーション”が大切だ。前回に引き続いて、オリエンテーションで話すべき内容について考察する。

[山村秀樹，＠IT]

業務部門に積極的に顔を出すことを伝える

　業務部門をプロジェクトから遠ざけるプロジェクトチームは、全力を尽くして努力したとしても、失敗する可能性が大いにあります。出来上がったシステムは「使えないシステム」となっている可能性があるのです。

　業務部門出身のプロジェクトメンバーが自身の出身職場に対して問題意識を持っていることはよくあります。このようなメンバーは実に頼もしい半面、その問題意識が独善的な場合があります。

　1つの業務部門を見ても、その中には管理職・ライン・スタッフ・事務などいろいろな役割があります。こうした人々がそれぞれ要望する機能の中には、相いれないものもあります。そのメンバーが考える“改善すべき”問題点とは、出身職場にいたときの立場での見方であって、実は別の立場から見ると十分に合理的で“改善する必要がない”場合もあるのです。そこに気付かず、一方的に問題視して業務プロセスを変更し、システム化してしまうと、後から「使えないシステム」と評価されることになります。

　よくコンサルタントや企画部門が主導して決めた業務プロセスや機能要求仕様で作られたシステムが、現場で「使えないシステム」となっているといったことが話題になります。しかし、別に企画部門ではなくても、現場自身が主導して仕様を決めたにもかかわらず「使えないシステム」ができてしまうことがあるのです。ひどいときにはその職場の上級管理職が、反対意見を具申した部下に対し「バカ野郎、これでやれ」と強引に押し通して、結局、誰も使わないシステムができてしまうことすらあります。

要求を現場で見つける努力

　これを防ぐために「業務部門をプロジェクトに巻き込み続け、要所要所で合意を取りながらプロジェクトを進めよ」とされます（本連載でも主張してきました）が、これは最低限のことです。実際には、さらに業務部門の隠れた問題や意見を探り出す努力が必要です。

　プロジェクトの機能要求仕様を検討する会議には、各業務部門の代表者に出席してもらいますが、会議で出てくることがすべてではありません。会議やインタビューでは、聞くべき事柄にもその回答にも必ずモレがあります。電話や電子メールでのやりとりでも同じです。

　そこでプロジェクトメンバーには、現場に頻繁に顔を出して、万遍なく意見を聞き出す努力をするように伝えます。現場に行って初めて明らかになる事柄もよくあります。時間はかかりますが、プロジェクトメンバーが現場に顔を出すことによって得られる情報は、残業代をケチって削減できるコストよりもはるかに価値があります。足は第2の心臓といわれているそうです。現場を歩き回ることは、気分転換にもなりますし、頭に血が回って脳の働きが良くなるといった効用もあるかもしれません。

　加えて、業務部門の人々に質の高い機能要求仕様の作成の重要性をきちんと理解してもらうことも大切です。というのは「システムの修正は簡単だ」と思われていることがあるのです。そのため、機能要求を「必要になったら、そのときに伝えよう」と簡単に考えていることがあります。メンバーには、現場と接触する際には「システムの修正は簡単ではないこと」「そのため精度の高い仕様が必要なこと」を折に触れて現場に伝えるように説明します。

　ついでながら、バカ野郎といわれて仕様に入れられなかった意見も大切な情報です。これは将来修正が予想されるプロセスですから、変更に強いシステムを作る工夫の1つとして、あらかじめ設計にそうした可能性を織り込んでおくのも知恵というものです。

情報を共有することを説く

　情報を共有するということは、作業に透明性を持ち込むということです。これはメンバーが何をしているのかをほかのメンバーにも分かるようにし、またメンバーが作業を囲い込んでしまうことを防ぎます。

　チーム内の良好なコミュニケーションは、努力なしに維持できるものではありません。機能要求仕様を詳細に詰める段階では、ベンダから問い合わせが殺到してきます。そのボリュームはすさまじく、回答期日に余裕もありません。各メンバーはこれらの問い合わせに応じるための作業で手がいっぱいになり、ほかのメンバーの作業にまで気が回りません。

　ミーティング（レビュー）を設けて、メンバーが検討中の仕様を報告し合っても、本当の状況、詳細な内容はなかなか分からないことが多いものです。そもそも、作業のボリュームに比してミーティングの時間はあまりにも短く、メンバーは抽象的な報告しかできません。短い時間で要領よく的確に報告したとしても（いや、要領が良いからこそ）、ディティールやニュアンスまでを正確に伝達・理解できることは少ないでしょう。

　各メンバーが機能要求仕様に生じた変更を電子メールで連絡し合う方法もあります。たいてい、業務部門や関係者とやりとりしている内容を、そのままほかのメンバーにCcで送信するものです。

　このやり方は、送信側にとっては楽なのですが、実際のところ受信側のメンバーはまず、そのメールを読みません。そのままメールボックスにためたままにしておき、必要になったときに検索するか、直接その担当者に問い合わせます。受信者側・送信者側、どちらにしてもメールボックスを検索し直すことになるのですが、要求仕様のようにバージョンやステータス（状態）が大切な情報を電子メールでやりとりすることはかなり危険です。検索キーワードが違っていて目的の情報を抽出できなかったり、見つけたと思った情報が古いものであったりします。

　本来は少なくともリーダーが注意して、各メンバーの作業内容を管理しなければならないのですが、リーダーにもリーダーの作業なり都合なりがあって、時間がなかなか取れません。時間ができたとしてもメンバーと時間が合わず、満足に話し合えるというわけにはいきません。

　また時には、仕事のやり方を知らないのか、自分の存在価値をつり上げようと考えてのことか、あるいは周りの人間には理解不能だと考えているのか、自分の作業を囲い込んでほかのメンバーに対して秘匿するメンバーもいます。All for One, One for All の意識がないのです。

　このような状況では、機能要求仕様に全体的な不整合や矛盾が発生します。複数の業務部門が関係し合う業務プロセスには、ただでさえ重複・衝突・矛盾することが多いのに、調査や検討を担当するメンバーが業務部門ごとに違い、お互いの業務プロセスが分からなければ、不備が生ずることは当然のことです。

　ソフトウェアの準備ができたのに、ハードウェア担当者への連絡ミスでハードの準備ができていないなんてことも起こり得ます。要求仕様でも、チェック不足、あるいはメンバーの能力やプロジェクトに対する温度差により、要求事項の多いところと少ないところ、内容が詳細なところと粗雑なところなど、ムラが出ることも問題です。

成果物は集中・一元管理する

　そこで成果物などをメンバー同士が相互に見て、プロジェクト全体の仕事の質や進み具合が見て分かるよう、情報──つまり、調査検討用の資料や成果物などはあらかじめ決めておいた場所に蓄積するようにします。リーダーとメンバーは、報告／指示という作業に時間を費やすのではなく、プロジェクトの作業そのものを自ら見に行くのです。これは管理コストを軽減する効果があります。

　もちろん、資料や成果物を共有するためには、それなりのルールを整備しておくことも必要です。例えば「フォーマットを決めておく」「日付をちゃんと入れる」「改訂個所は分かるようにしておく」「変更があれば変更のあったことを口頭やメールで連絡する」などです。

　なお、共有する情報とは、資料・成果物だけではありません。チームのルールもそうですし、リーダーの指示も含みます。