7月11日夜,銀座で筆者のビジネスユニット(NTTデータの事業単位)主催のパーティを開いた。会社で5月の創立記念日に業績表彰を受賞したので,お祝いとふだんお世話になっているパートナー企業の方への御礼をするためだ。来賓として6月にNTTデータ代表取締役常務からNTT代表取締役副社長(CTO,CIO)になられた宇治則孝さんにご参加いただいた。宇治さんには7年間にわたってお世話になり,トップセールスや難しい問題への対応で幾度も助けていただいた。パーティの冒頭で宇治さんへの御礼とお祝いを申し上げた。

写真●業績表彰パーティの記念写真
写真●業績表彰パーティの記念写真
前列中央がNTT代表取締役副社長の宇治則孝さん,その右隣が筆者。
[画像のクリックで拡大表示]
 このようなパーティは今回が2004年,2006年に続いて3回目だった。2004年には約100人,昨年と今年は約60人の方を招待した。表彰には賞金がついているのだが,それを一晩ですべてパーティに使ってしまうのだ。思い出のために記念品を作ろう,などという発想はまったくない。招待するお客様の数は賞の大きさに比例する。

 パーティのクライマックスはパートナー各社の若手によるスピーチだ。どの人も上手なのに感心する。閉口するのは,皆,判で押したように私に叱られた思い出話をすることだ。まあ,日ごろお世話になっている方に感謝するのが目的の会なので,スピーチも思いのたけを吐き出して,すっきりしてもらえば本望だ。 

 さて,今回はしっかりと業績を上げるために重要な線表の使い方について述べたい。自分で線表を書けること,部下の線表をチェックし,的確に指示できることは開発においても営業においても大事なことだ。

A3一枚の線表で進ちょく会議

 筆者のユニットでは毎週月曜日の9時半から,プロジェクトリーダーと営業責任者で進ちょく会議をするのを習慣にしている。開発中のプロジェクトや進行中の新規販売案件の進ちょくや問題点について,状況把握と対応策の相談および指示をするためだ。資料はA3一枚の線表のみ。時間は30分からせいぜい1時間程度だ。線表の上半分には開発・運用・保守フェーズにあるプロジェクトの線表が並び,下半分には新規販売案件プロジェクトが並んでいる。

 横の時間軸は過ぎ去った4カ月間と,これからの6カ月間を対象としており,これからの3カ月は詳しく記入できるように幅を広く取っている。共有フォルダに置いてあるこの線表を各プロジェクトのリーダーが毎週,メンテナンスする。

 筆者はこの線表によって,動いているプロジェクトのすべてが俯瞰できる。そして,これを使ってプロジェクトマネジメントするかぎり,開発プロジェクトにおいては大きなトラブルを発生させないし,営業案件においては単純な対応の遅れやミスを起こさせない,という自信を持っている。線表を使ったプロマネをしていて面白いのは,プロジェクトリーダーや営業マンの実力,個性,やる気がその線表から見えてくることだ。

 同じ線表でも,開発線表と営業の線表ではその書き方やポイントがまったく違う。以下,それぞれの要点を述べる。

チェックのタイミングが大切な開発線表

 開発は,やることも納期も決まっている。開発のプロジェクト管理では品質,納期,コストを遵守することが重要なのだが,とりわけ品質を重視すべきだ。品質の悪さが納期遅れやコスト増の原因になるからだ。品質を守るとは言い換えると大きなトラブルを起こさないこと,そのためにはトラブルの素になるリスクを回避することだ。

 開発線表を作成したり,チェックする場合の心得を三つあげる。

●チェックのタイミングとポイントを明確に
●過去が詳細な線表に意味はない
●「問題ありません」は問題の始まり

 トラブルのリスクを回避するためにはチェックすべきタイミングとポイントをはずさないことが大切だ。いつもいつも神経質に細かなチェックをする必要はない。当たり前だが,やったことを詳しく書いた線表など意味がない。だが,現実にはやったことの記述が多くて,これからどうするかが少ない人は多いものだ。「問題ありません」という報告を鵜呑みにしてはいけない。そこから問題が始まることが多い。例によって,最近あった事例をデフォルメして仮想事例として紹介しよう。本社移転に伴う大規模LANの構築プロジェクトの例だ。

 移転の半年前から設計が始まったそのプロジェクトは,毎週毎週,「問題ありません」という報告を受けていた。問題ない,には二通りのケースがある。本当に問題がない場合と,問題はあるがチェックしていない,あるいはチェックが甘いために気づいてない場合だ。チェックをきちんとしているかどうかは,その人の引いた線表を見ればだいたい分かる。ちゃんとしている人は移転前のお客様への移行判定資料(=試験結果を説明し,お客様に移行の承認をもらうための資料)の説明日時,それに先立つプロジェクトとしてのレビュー等のポイントが線表に明記されている。

 この事例では,移転工事の日時はあるが,移行判定やレビューの日時が書かれていなかった。移転工事が始まる2週間前の進ちょく会議,ここで筆者がチェックを入れた。このタイミングを外すと間に合わなくなる。移行判定,それに先立つレビューの日時を決めること,レビューはプロジェクトのメンバーだけでやらずプロジェクト外の有識者を加えること,を指示した。移転工事実施の体制図とタイムチャートがあるか,と聞くとお粗末なのが出てきた。万一の場合に備えたエスカレーション体制までを含む体制図とタイムチャートを移行判定時にお客様に提示するよう指示した。

 その後このプロジェクトは,レビューにおいてコアスイッチの設定の改善点など2,3の問題が抽出され,本番環境の試験で軽微な不具合が見つかったが,移行判定は承認いただき移転工事も無事に完了した。このプロジェクトを担当したリーダーの特徴は,線表管理は甘いが,追い込み仕事と現場での頑張りが立派なことだ。 

「意志」が必要な営業の線表

 開発がやることも納期(スケジュール)も決まっているのに対し,営業の線表ははっきりしていない。それはそうだ。営業の線表とは自分の意志を書くものだからだ。「この案件は何月に受注する」という目標を自分で設定するところから線表を考える。
 その心得を三つだけ挙げよう。

●ゴールを明確にする
●「やれること,やれるスケジュール」でなく,
 「やるべきこと,やるべきスケジュール」を書く
●優先順位をつける

 ゴールの設定は受注時期だけでは不十分だ。新規提案活動は,アプローチ(初期折衝)→プラニング(提案・折衝)→クロージング(受注獲得のための詰め)というプロセスをたどる。それぞれのフェーズで何をするか,何時までにそのフェーズを完了するかを明確にしないと,今すべきことが具体化できない。

 凡庸な営業マンは「やれることとやれるスケジュール」で線表を引く。こんな人に限って,お客様から見積もりなどを頼まれると,見積もりが終わってからアポイントを取る。お客様が何時までに見積もりが必要かはっきりさせ,アポイントを取ってから見積もるべきだ。筆者の場合は1週間後でいいと言われたら,3日で持っていく。

 お客様から依頼されたり,上司から指示されたことしか線表に書かない人もいる。そんな意志のない,受動的な営業マンに受注など出来るはずがない。新規受注はすさまじいエネルギーが必要だ。ゴールするために何をすべきか必死に考え抜き,「やるべきこと、やるべきスケジュール」で線表を引かねばならない。

 営業という仕事には際限がない。ターゲット顧客を増やせば仕事はいくらでも増やすことが出来る。しかし,一人の営業マンが持っている時間には限りがあるし,職場にいる人材にも限りがある。そこで,案件ややるべきことに優先順位を付けることが不可欠になる。優先順位を上手につけて,大事な案件を確実に受注できる営業マンはまれだ。案件の重要性より,自分がやりやすいかどうかで優先順位をつける人もいる。そんな人はプロジェクトマネージャーが優先順位を付けて指示すべきだ。しかも,ごく単純にすることが肝要だ。「BよりもAを優先しなさい」などというのではダメなのだ。筆者は「Bについては何もしなくていい。この1週間はAに集中すること」と単純に指示する。こうすると言い訳が出来ないのだ。「AもあるけどBもしなくちゃいけないので間に合いませんでした」などとは言えなくなる。

下剋上パワーで行こう

 銀座のパーティにはStartForce社のCEO,JinKohさんにも来てもらった。日本の大手ベンダーがたくさん来ていたのだが,Jinさんのプロフィールを紹介して「Jinさんの例に限らず,今,ITの世界は下剋上時代です。若いからとか,小さいから,といった理由で軽んじていると後悔することになりますよ。私のビジネスユニットも下剋上すべく頑張ります」と刺激しておいた。