PMプロの知恵コーナー
先号　　　次号

ゼネラルなプロ (133) (Nコム)

向後　忠明　[プロフィール]　：11月号
　先月号まではプロジェクト組織の構築とプロジェクトのその枠組みについて話をしてきました。すなわち、プロジェクト計画書作成の前段階の話をしました。
　本プロジェクトはN社の社内システムの開発であり、顧客でありユーザでもある財務部担当部長がプロジェクトマネジャであり、財務部としての本プロジェクトにかかわる経営会議での要件を詳細に関係者に示す必要がある。そのため、統括管理者としてのプロジェクトマネジャはプロジェクトチーム関係者にその経緯について述べ、同時にプロジェクト遂行に関する自分の意思を明確にする必要があります。
　以下がプロジェクト発足の経緯と実行に関する内容を列記したものであり、これに従い書類に纏め全プロジェクトスタッフに周知する必要があります。

  1. ①プロジェクト背景(経営層の思い、プロジェクト化までの経緯、不確定要件への対応等)
  2. ②プロジェクトの特徴とプロジェクト遂行方針、プロジェクト目標
  3. ③プロジェクト組織の設定とその構成の説明及びスタッフとその役割分担と配員
  4. ④スコープ(仕事の範囲)の設定と分担の設定、各分担範囲での要求品質の設定とその統制と維持に関する方法
  5. ⑤スケジュール目標とコスト目標の設定とその統制、維持に関する方法
  6. ⑥問題例外事項に対する意思決定などプロジェクトの総合的な管理と遂行手順
  7. ⑦プロジェクトコーディネーション手順(図書類の識別、やり取りの規定)

　ここに示す内容がプロジェクト計画書に記述するものであることをPMアドバイザーとしてプロジェクトマネジャ及びキーパーソンに説明しました。
　ところが、プロジェクトスタッフから、いろいろな質問が出てきました。
　例えば、PMBOK®にはプロジェクト開始に当たってはプロジェクト憲章を作成すると記載されているが、「プロジェクト計画書に示す内容とどのような違いがあるのでしょうか？」といった質問でした。Nコムの社員はプロジェクト計画と憲章の違いが分かっていなかったようです。これは説明するまでもなくプロジェクト計画書であり、このようにやるといった宣言書です。
　今度は、プロジェクト目標に示される品質についても質問がありました。ユーザの立場としては、品質指標の範囲はISO 9001に定義されている製品合否判定基準を含む妥当性確認までであり、システム完成後の品質保証への要求までを計画書に示す必要がある旨を説明しました。
　一方のコスト、スケジュールのマネジメントではPMBOK®には各種手法を示しているが、あまり複雑な方法を採用すると慣れていない人はかえって余計な労力を使うことになるので単純な方法で行うように説明しました。
　例えば、スケジュールはお互いのシステムの関連の分かるバーチャートネットワークを使うように、そしてコストはスケジュールに合わせた消費コストをバーチャートにリンクさせコントロールする程度で良い旨を説明しました。
　PMBOK®を学んできた社員は学んできた手法に固守しがちですが、やはり実際のプロジェクトを経験していない人は物事を四角四面に考え、応用が利かず書物に示す理想の方法に走ってしまう傾向にあるようです。
　私は、PMBOK®はかなり良くできたプロジェクト知識体系であると思っています。
　しかし、資格試験に合格して「これで私はプロマネとしてプロジェクトをマネジメントできる」と思うのは時期尚早です。
　実際にプロジェクトを多く経験した人はPMBOK®に書かれている内容のどの部分を対象のプロジェクトに適用したら良いか判断できるが、資格試験に合格したからと言って実際のプロジェクトに習熟するには時間がかかります。このためには指導者の下での一定期間のOn-The-Job Trainingが必要と感じました。

　なお、実際の技術面における問題についてはエンジニアリングマネジャ(Nコムウエア)及びNコムの技術部門の双方がそれぞれの担当部分を管理していたので技術仕様の作成は安心してお願いすることができました。
　しかし、完全に任せきりにするには心配もあり、当初のこのプロジェクトの成り立ちと基本的要件についてはプロジェクトマネジャとPMアドバイザーが先導する形で関係部門や技術陣とつかず離れず議論を重ねました。
　すなわち、プロジェクト背景についてステアリングコミティーにてアーキテクチャーの構成つくりとスキームモデルによる構想計画など本プロジェクトのあり方を議論しながら、本プロジェクトの構想や要件をまとめ、同時にプロジェクト組織やプロジェクト計画の微調整なども行いました。
　このようにして財務部の要件の確認が行われ、その内容が技術陣にも徐々に理解されるようになり、彼らも単独で基本仕様書の作成に入ることができるようになりました。

　このように、最初の立ち上げはうまく進められたが、仕事が進むに従い、システム運用面や各社分担システム間のインターフェースにかかわる課題や追加要求や変更が発生してきました。
　そこで、今度は旧システム(更改前の財務管理システム)のオペレーションを行っている持ち株会社のオペレーション部門(Nオペレーション部門)の協力を求め、その担当者を本プロジェクトチームメンバーに加えました。
　そして、Nコム、Nコムウエア、そしてNオペレーション部門を加えた三社による定期的な課題会議を毎週行うことになりました。ここにはプロジェクトマネジャやPMアドバイザーも入りその場で問題や新たな変更を関係者間の話し合いにより処理し、問題を後に残さないようにしながら、仕様の確定をしていきました。
　IT開発プロジェクトはユーザ、オペレーションそして技術開発部隊が共に仕事を進めることが非常に重要であることはPMアドバイザーのこれまでの経験からよくわかっていたのでこの課題会議を重要視していました。
　何故ならIT開発は要求される仕様が不確定な場合が多いのでその仕様確定が重要であり、これを確実にしないと後の工程に大きな影響を及ぼすことになります。
　特にユーザやシステムをオペレーションする人たちとの綿密な要件の詰めを行わないことで大きな問題となるケースが多いようです。
　例えば、ある海外の中央銀行システムで当初の条件設定の時の交渉時で曖昧な妥協をして顧客との綿密な協議もせずに契約を締結したためその後のユーザおよびオペレーション部門からの追加要求に追従できず大きな失敗をしたことがあります。
　これは自信過剰からくる顧客との綿密な仕様検討や条件設定での協議をしないで一括契約で仕事を進めてしまったことで、最終仕様設定に多くの時間とコストを要してしまったことが原因でした。
　プラント建設やビル建設のプロジェクトの場合はIT 関連プロジェクトとくらべ、顧客要求がしっかりしていてその顧客要求(RFP：Request For Proposal　の略)に対してコンプライアンステーブル(Compliance Table)というものをプロポーザル提出時に提出し、交渉時に要件の確定を行い契約します。よって、契約後は受注側の責任でプロジェクト計画に従ってその目標を達成のためプロジェクトコントロールをしていきます。
　もちろん、プラント建設等々も課題・変更管理の必要性はありますが、どちらかというとプロジェクトマネジメントはスケジュールやコストへの影響に重きを置いています。それに対して、IT 開発は仕様や条件変化に重きを置くことが重要と自分は考えていました。
　IT 開発でアジャイル方式というものがあるが、顧客要求の変化に対応するために顧客との共創を基本としたものであり、仕様の確定を顧客と密接に話し合いながら変更を最小とするように共同でシステムを開発する方法と考えています。
　今回のような社内システム更改プロジェクトのような場合でユーザが顧客でありかつプロジェクトマネジャが顧客の立場であることから実行及び結果責任の両方を持つことになり、この課題管理にかかわる会議はこのプロジェクトにとっても大切でした。そのため、PMアドバイザーとしては常にプロジェクトマネジャの脇にいて、適切に意思決定できるように援助していきました。本プロジェクトへの関与のほとんどの部分がこの課題管理会議への出席が主なもので最も時間を要した期間でもありました。
　実際、この詳細仕様設定の短い期間での技術陣の作業は厳しいものであったことから関係各部門のワークロードは最高となり、みんな夜遅くまで仕事をしていました。そのような中、財務部長は「皆さんご苦労様」と言って担当者を励ます意味で作業している人たちに果物やお菓子を配り、作業現場の雰囲気を盛り上げるようにしていました。
　このような光景を自分は何度も見ましたが、やはりトップマネジメントの行動は働いている人達に影響を与えるPM行動特性の一つであることに気が付きました。
　これも一種のコミュニケーションクライメートの醸成につながり、このようなことからこのプロジェクトは成功すると感じていました。
　結果としては、仕様確定も大きな問題もなく、スムーズにプログラム製造作業に入ることができました。
　なお、本プロジェクトの完成に際しては富山県のある場所にあるホストコンピュータでの運用開始にも立ち会い、何の問題もなくシステム運用が開始され、その結果、予定期間より早く完成することもでき財務部長も喜んでいました。

　なお、次月号ではプロジェクト進行中において、多くのプロジェクトで失敗の原因となる仕様変更や問題発生時での仕様変更とシステム品質への影響、そしてそれを防止する課題・変更管理への対応について話をしたいと思います。
ページトップに戻る