システム構築プロジェクトを推進していく上で、各種管理表は重要である。課題管理表、リスク管理表、障害管理表、要求管理表などいくつもの種類がある。開発者とユーザーの両者で確認するものであり、多くの場合、管理表の書式は開発者が普段使っているものを利用する。もちろん、ユーザー側が「当社ではこの書式を使用してほしい」という場合もあるが、そうしたケースはあまり多くない。

 開発者が普段使っている管理表には共通点がある。項目数が多く、それを表になんとか押し込もうとするので、各項目の列幅が狭くなる。その狭い列に多くの情報を記載しようとするため、字がとても小さくなる。つまり、パッと見、とても読みにくい表なのである。その読みにくい表を頑張って読んでみると、項目の並び順がイマイチ良くなかったりする。本誌でこれまで数々の連載をされている小浜耕己さんの言葉をお借りすると「表内別居」(項目同士が関連するので、本来隣り合うべきなのに離れていること)の状態だったりする。

 このような管理表を作成する開発者の能力が低いかといえば、そうではない。むしろ、エンジニア気質にあふれるからこそ読みにくい管理表になってしまう面がある。エンジニアは緻密だから、管理上必要と思われる項目はなるべく漏らさず入れたいと考える。エンジニアは創意工夫をするので、先人が作成した管理表に新たに項目を追加したり項目名称を変更したりする。エンジニアは細かい資料の読解に長けているので、小さな字がぎっしり詰まった表であっても苦にしない。関連項目が離れていても頭の中でリンクするので理解に困らない。

 こうした“ビジー”な管理表はユーザーにとっては苦痛だ。ユーザーにもいろいろな人がいるので一概には言えないことは承知しているが、多くのユーザーは小さな字が書きこまれたビジーな管理表を読むのが苦手であると断言できよう。

 ユーザーが読む資料である以上、読み手に配慮しなければならない。どうすればいいか。管理表の字を単純に大きくすればいいわけではない。ここで考えるべきは、ユーザー視点から見た「管理上必要な項目」は、開発者のそれと同じではないということだ。数学の集合でいえば、ユーザーにとって重要な管理項目は開発者のそれの部分集合、すなわち一部の項目だけなのである。言い方を変えると、開発者が提示する管理表の中に、多くの「興味のない管理項目」があるということだ。

 ユーザーが興味のあるのは、極論すると「何が問題で」「いまどちらにボールがあり」「いつまでに解決するのか」の3項目である。ただ、さすがに現実のプロジェクト管理を行う上ではこの3項目だけでは心もとない。そこで管理表の書式を最初に提示する際に、ユーザーと開発者の間で何を目的とし、どれを管理項目としていくかについてきちんとコミュニケーションを図るとよいだろう。

 管理を進めていく上で適宜、双方合意の上で管理項目の追加・削除を行い、そのプロジェクトに適した管理表ができればプロジェクトの成功に大きく寄与することになろう。

永井 昭弘(ながい あきひろ)
イントリーグ代表取締役社長兼CEO、NPO法人全国異業種グループネットワークフォーラム(INF)副理事長。日本IBMの金融担当SEを経て、ベンチャー系ITコンサルのイントリーグに参画、96年社長に就任。多数のIT案件のコーディネーションおよびコンサルティング、RFP作成支援などを手掛ける。著書に「RFP&提案書完全マニュアル」「事例で学ぶRFP作成術 実践マニュアル」(共に日経BP社)など