PR

 「岩城さんじゃないですか」。

 試験会場で突然声をかけられて振り向くと,そこには青木が立っていた。彼は私の担当するプロジェクトの利用者側のリーダーで,システム開発プロジェクトを通じて私と常日頃議論を戦わせている間柄だった。彼は年次で言えば私の3期後輩にあたり,システム開発の経験も私の方が長いため,彼にはことあるごとに,「システム開発はこうあるべき」と講釈をたれていたのである。

 「何だ,青木もプロマネ受けるのか?」。

 「はい。岩城さんの言っていることをもっとよく理解しなきゃいけないなと思って・・・」。

 彼は真面目で純粋。私の小言も素直に受け入れて,システム開発の利用者リーダーとしてメキメキ実力を上げてきていた。とはいえ,彼は利用者の代表としてシステム要件を出してくる立場。私は開発の現場でプロジェクトを仕切る立場。仕事の中身やプロジェクトマネジメントの経験からいっても,私が彼に負けるわけがない。

 プロマネ試験は情報処理技術者試験の中でも高度試験区分であり,決して簡単に合格できるものではないが,ここは格好良く合格して,青木に対しても面目を保つ必要がある。ただ,突然のライバル出現に,私の心は少なからず動揺し,プレッシャーを感じていた。

 「それじゃあ,頑張りましょう!」。どこか不敵な笑みを浮かべつつ,爽やかにそう言って青木は去っていった。「不合格になるわけにはいかない」。私は,自分にそう言い聞かせながら,試験に臨んだ。

不合格のショック

 試験の出来はというと,自分ではまずまずの感触。試験前の数カ月は,本業の開発プロジェクトがシステムテストのさなかで,多忙を極めていたこともあり,試験勉強に十分な時間をかけたとはいえない状況であった。それにもかかわらず,午後I,午後IIともに出せる力は十分に出せた,という満足感とともに試験を終えることができた。

 これまで自分が担当したプロジェクトでは大きな失敗は無く,直面する困難な状況も周囲の協力を得て何とか切り抜けてくることができた。今思えば,「自分のプロジェクトマネジメント能力は,実務経験を通じて既に試験合格に十分なレベルにある」と,ある意味なめてかかっていたのかもしれない。そして,2カ月後,私は大いなる屈辱を味わうこととなったのである。

 「何?不合格?」。

 パソコンの画面に映し出される合格者の受験番号一覧に,私の受験番号を見つけることはできなかった。しばらく放心状態でいると,ふっと青木の不敵な笑みを思い出した。私は脳裏に浮かんだ「あり得ない結末」をすぐさまかき消した。「まさか,俺が不合格であいつが合格できることはないだろう」。

 次の日,会社で仕事をしていると,青木の上司から電話がかかってきた。

 「青木がプロジェクトマネージャという試験に合格したようなのだが,それってすごいことなのか?」。

 青木の上司は,情報処理技術者試験の知識に乏しいらしく,彼の合格がどれほどすごいことなのか,私に確認しようと電話をかけてきたのだった。私は一瞬言葉を失ったが,辛うじて平静を装いながら言った。「・・・ええ。プロマネは高度試験区分ですし,たいしたものですよ」。

行き当たりばったりで切り抜けてきたツケ

 プロマネ試験に不合格となったことで,自分のマネジメント能力を否定されたという思いが高まり,ましてやカウンターパートナーである青木があっさり合格したことでショックは倍増した。自信を喪失しかけていた私は,何とか事態を打開しようと,自らのマネジメントスタイルを一から見直そうと決心した。

 そして,自分のマネジメントスタイルを分析するうち,私は一つのヒントを得ることができた。それは,私のマネジメントは行き当たりばったり型だった,ということだ。これまで担当したプロジェクトの多くが,成り行きで結果的にうまくいっていたことが,逆に試験の結果に災いしたのである。

 私は,「プロジェクトはチームワークが第一で,チームメンバーのコミュニケーションが良好であれば,プロジェクトは必ず成功する」というポリシーを持っていた。数値目標を管理して着実にプロジェクトを進ちょくさせることより,チームメンバーのモチベーションを高めたり,人間関係の調整を行うことがマネージャの最も重要な役割だと信じていた。

 確かに,PMBOKの9つの知識体系にも「コミュニケーションマネジメント」が定義されている。しかし,これは9つの中の1つであって,それがすべててではない,ということを,私は正しく認識できていなかったようだ。調達や品質やリスクに対するコントロールが十分にできないままでは,「計画通り」のプロジェクト遂行はできない。振り返ってみれば,私の上司や周囲の協力者がカバーしてくれていたおかげで,どうにか私のプロジェクトマネジメントは破綻せずにいられたのである。

 では,青木はどうだったのか。システム開発のユーザー側の代表としての彼の立ち居振る舞いを思い起こしてみると,確かに彼は私よりはるかに論理的だった。数字や進ちょく管理にこだわりがあった。プロジェクトの進ちょくに遅れが生じているときも,私が根拠に乏しい「大丈夫です」という回答をすると,「何日遅れているのか?どのようにキャッチアップするのか?」をきちんと確認してきた。それに対する私の説明は精神論に偏り,「頑張ります」を繰り返すことが多かった。

プロセス重視型へのマネジメントスタイル変革

 こうして得られたヒントから,私が導き出した方向性は,「プロセス重視型への変革」である。リスクの詳細な分析,進ちょく率の厳しいチェック,徹底した変更管理。これらはこれまで担当したプロジェクトで実施してこなかったわけではないが,マネジメントの優先順位を低くとらえていた。世の中に存在する管理手法に関する知識も乏しかったため,非常に稚拙な管理しか行っていなかったといえる。

 そのことに気付いてから,不思議とこれまで取っつきにくかった参考書に書かれている管理技法も,スムーズに頭に入ってくるようになった。プロジェクトマネージャの管理対象である「スケジュール」「品質」「組織要員」「調達」「変更」「リスク」をバランス良くコントロールすることが大切だ,ということに気付くことができたおかげで,私のプロジェクトマネジメントのスタイルは一気に変革し始めたのである。

 実務では,勉強したことを実践してみて「何だか岩城のマネジメントが変わってきたなぁ。不安感がなくなってきたよ」と上司に言われたときには,ちょっぴり嬉しかったものだ。

再挑戦

 不合格の翌年の試験は,試験日と大規模システムのカットオーバーが重なってしまい,泣く泣く受験を断念することとなり,再チャレンジは2年後の2006年となった。受験勉強もプロジェクトをマネジメントするように,マスタースケジュールやタスク管理表を作成して計画的に取り組んだ。

 前回準備が不十分だった論文も,準備に時間をかけて自分のマネジメントスタイルを変革した事実を表現するようにした。そして何より,ライバルに負けた悔しさをバネに,絶対の気迫で受験に臨み,念願の合格を勝ち取ることができた。

 青木とは今でもパートナーとして,ともにプロジェクトの成功を目指して切磋琢磨しあっている。そういえば,最近,彼とのプロジェクトマネジメントについての語らいが大変盛り上がるようになってきたのは,気のせいではないだろう。

試験概要:プロジェクトマネージャ試験
経済産業省の情報処理技術者試験の1区分。情報システム開発プロジェクトを成功させるための責任者(マネージャ)としての技術力を認定する試験。試験科目は,午前(選択式),午後I(記述式),午後II(小論文)の3部構成。合格率は8~10%程度。

岩城 一成(いわき かずなり)
大手金融会社の情報システム開発・運用会社に勤務。企業内システムの開発・運用業務に10年間従事。プロジェクトマネージャ歴は5年。これまで,新商品開発やグループ企業のシステム統合プロジェクトを担当し,現在は次期基幹システムの開発に携わっている。