今春，富士通官公庁ソリューション事業本部のプロジェクト・マネジャーである斎藤崇之氏は，「これから1週間で，新規入札案件についてのプレゼン資料をまとめるように」との指示を上司から受けた。

　プロマネ歴5年の斎藤氏は，入社してから開発現場一筋。システム提案といった営業活動にはほとんど携わったことがなく，提案用のプレゼン資料作りは初めてと言ってよい。「どうしたら，伝えたいことがうまく図示できるのかが分からず，悩んでいた」（斎藤氏）。

資料作り未経験者が提出一番乗り
　だが斎藤氏は，なんとか1週間後にプレゼン資料を省庁に提出することができた。「提出に行ったら，省庁の担当者が『えっ，もうできたんですか』と驚いていた」（斎藤氏）。入札していた他ベンダーで提出済みのところはなく，その後1～2週間かかっていたという。

　資料のクオリティも決して低くなかった。省庁の担当者からは「分かりやすい」と評価された。一度も資料を作ったことがなく，図の作成に自信がなかった斎藤氏が，なぜ1週間で資料をまとめられたのか。

　実は斎藤氏は，「1週間で作るように」と指示されるや否や，同じ事業本部内にある標準化部門のソリューション開発センターソリューション技術部に，プレゼン資料作成について相談した。すると即座に，プレゼン資料の作成ノウハウ集が斎藤氏の元に送られてきた。

　受け取ったノウハウ集は，PowerPointのファイルだった。訴えかけたい内容ごとに，典型的な図解のパターンがまとめられたものだ。「提案内容をうまく表現できる図解パターンを選び，そこに文章やキーワードを加えるだけで，資料の1枚1枚を仕上げられた」（斎藤氏）。提案内容は固まっていたので，資料はすぐでき上がったという。

図解スキルは組織全体に求められる
　ソリューション技術部が作ったプレゼン資料のノウハウ集はその後，斎藤氏が所属する公共システム開発部門に公開された。今年8月には，他の開発部門にも公開された。ただし，社外には公開していない。

　ノウハウ集を作成したソリューション技術部の平賀典生氏は「プレゼン資料の内容を組織的に高い水準に引き上げる必要性が高くなった。そこで，図解を含めたプレゼン資料の作成ノウハウをまとめることにした」と作成理由を話す。最近のコンペでは，「提案内容の出来はもちろん，その内容をきっちり理解してもらえるかどうかで受注が大きく左右される」（平賀氏）という。

　実際，社内でノウハウ集が公開された8月以降，効果が着実に出始めている。斎藤氏の案件は残念ながら受注できなかったものの，8月から9月にかけて，富士通はシステム開発案件を続けて受注できた。いずれの案件のプレゼン資料も，ノウハウ集を基にまとめられた。「自分がまとめたノウハウ集が，受注に貢献していると評価されており，非常にうれしい」と，平賀氏は顔をほころばせる。

【追記】斎藤氏の案件は10月に再度入札が行われ，最終的に富士通が受注した。（2005年11月14日）

　プレゼン資料における図解ノウハウの共有は，富士通だけでなく，野村総合研究所などでも進められている。図解のスキルは，ITエンジニア個人だけでなく，組織に求められるスキルへと位置づけを変えつつある。

「IT業界の人が書く図は分かりづらい」
　図解の威力を一層高めるには，組織的に図解のノウハウを共有するとともに，一人ひとりのITエンジニアがスキルを高めることが欠かせない。その第一歩は，「相手にわかりやすく伝えよう」という意識を持つことである。

　極めて当たり前のことに聞こえるかも知れないが，図解に関する著書が多い宮城大学事業構想学部の久恒啓一教授は，「システム業界の人には分かりやすい図を書こうという姿勢が欠けている」と指摘する。例えばプレゼンの際に，システムの専門家同士では理解できても専門外の人には通じない，内容が細かすぎて全体を把握しづらい，といった図を作るITエンジニアが少なくないという。

　ITエンジニアが「これでよし」と思っていても，顧客が満足しない「図解の落とし穴」がある。それを2つ紹介しよう。図を書く以前の心構えに問題があることがお分かりいただけるはずだ。

的外れな図を見せられてあきれる顧客
　ITエンジニア向けの研修を手がけるITキャリア研究所の高橋浩一代表取締役はかつて，ユーザー企業でシステム開発プロジェクトを担当していた。そのとき，開発委託先のITエンジニアの対応にあきれたことがある。

　高橋氏はITエンジニアに「業務の流れを図にして見せてほしい」と頼んだ。システム構築の対象となっている業務を，ITエンジニアがきちんと理解しているか心配になり，確認したかったからだ。

　ところがITエンジニアが高橋氏に提出してきたのは，システム・フロー図。業務の流れとは縁遠い，システムの内部的な処理の流れをまとめたものだった。相手が何を求めているのかを理解しないこのITエンジニアに対して，高橋氏が不信感を抱いたことは言うまでもない。

「業務改善策がITキーワード」もご法度
　ITエンジニアが陥りがちなもう一つの落とし穴は，SCMやCRMといったIT略語の乱発である。ビジネスマン向けに図解研修の講師を十数年務めているメディアハウスA&Sの飯田英明取締役は，こうしたIT略語を散りばめたプレゼンの図をよく目にするという。「顧客の業務上の課題を示し，その解決策としていきなりIT略語を持ち出す提案が少なくない」と嘆く。

　一見，立派で見栄えの良い図だろうが，よくよく眺めてみると，顧客の業務課題の解決に直結していないことが多々ある。顧客のことを真剣に考えていないことの表れと言えるだろう。おまけにこうした提案内容は，コンペになったときに他社と似通ってしまう可能性が高い。「どのITベンダーの担当者も安易に書きがちな図」(飯田氏)だからだ。

　図解の原則は相手の立場に立つことである。日経ITプロフェッショナル11月号の特集記事を担当して，その当たり前の事実を再確認させられた。特集記事では，システム開発の現場における図解の具体的な活用事例やコツも多く紹介している。ぜひ参考にしていただきたい。