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

ゼネラルなプロ (81) (実践編 - 38)

向後　忠明　[プロフィール]　：7月号
　縄のれんでの話の続きで翌日、約束していた財務部の友達(Mさん)の部屋に出かけて行き、いろいろ彼が困っている話を聞きました。
　彼の話では「今、わが社の経理は2半期決算であるが、これを4半期決算にすること、そしてグローバル会計もできる体制にしなければならない」ということでした。
　このため何から手を付けてよいのかわからないので、筆者の意見を聞きたいとのことでした。
　Mさんは企業情報システムとして多くの企業でも導入されているERP(Enterprise Resources Planning)といったシステムパッケージを採用して自社のシステムを専門システム会社に開発を任せようと考えていました。
　しかし、話を聞くと自社(NC社)のシステムは事業部ごとに各種システム開発会社やハードメーカに頼ったものとなっているので、ERP パッケージを導入して業者に一式で任せるのも心配とのことでした。
　また、これまで各事業部でシステムを開発した業者との関係や開発に関する考え方も違い、その調整も大変になると考えていたようです。
　話をよく聞くと、N社のシステム開発グループ会社(C社)がNC社の既存経理システム導入時に開発をしているとのことであった。これらの事情を考えると、自社での開発の方がERPパッケージ会社に開発を任せるよりリスクも低減でき、そして関係ステークホルダー間の調整も少なくて済むように感じました。
　このことを考えると、筆者は自社でこの既存システムを開発することも可能なような気がしました。
　このことで、NC社内にプロジェクトチームを編成し、主体的に動けば、各事業部との技術上の話も社内に限られ、自由な意見交換もでき、インターフェースの問題、その他技術上の調整もやりやすくなると感じました。
　このような話の結果、Mさんは既存システムを社内及びN社グループが中心となって本プロジェクトを進めることにしました。
　その日の話はここで終わりましたが、「財務部だけで各事業部を含めたステークホルダー調整や全体マネジメントが必要となるが大丈夫かな！」と思いながら部屋を出ていきました。

　一方、前月号でも述べたようにS事業部での仕事も部長連中のプライドの高さと筆者に対する上から目線に嫌気を指していました。
　またこの時期になってある団体から声がかかってきて、そちらの仕事も忙しくなってきました。
　その団体とは経済産業省が設立した情報処理推進機構(IPA)であり、プロジェクトマネジメント委員会でのIT 技術者のスキル標準を作るということでした。
　この仕事は筆者が所属しているプロジェクトマネジメント協会(PMAJ)からの紹介でした。
　IPAのスタッフがわざわざNC社まで訪ねてき、筆者にIPAの役割やIT業界の在り方などを説明してくれました。
　その後、筆者に「ぜひプロジェクトマネジメントのスキル標準を作る委員に就任してもらいたい」と要請してきました。
　筆者もこれからのプロジェクトマネジメントのIT業界への振興も必要と考えていたことや、S事業部の仕事もあまり面白くなかったこともあり「喜んで参加させていただきます」と快諾しました。
　その他、PMAJ から P2Mの普及のための活動も求められ、会社以外の活動が忙しくなってきました。
　そのような時に、Mさんから電話が入り、「申し訳ないが、例の会計システムについて相談があるので財務部に来てほしい」とのことでした。この時思ったのが、システム開発を自社でやった場合「誰がそれをやるのか？」とのことでした。
　Mさんの部屋に行ったら案の定、「このプロジェクトのまとめ役としてプロジェクトマネジャになってほしい」との依頼でした。
　しかし、現在抱えている仕事のことを考えるとすぐには受け入れられない状態でした。
　また、筆者はすでにS事業部に対しても事業部内のプロジェクトのマネジャはやらない旨を伝えているので財務部においても同様であることをMさんに伝えました。
　しかし、Mさんの依頼も無視できないとの思いから、アドバイザーということでならということで納得してもらいました。

　最初はアドバイザー的に財務部に時々顔を出し、社内の経理システムと付随するグローバル会計システムの概要を知るためMさんと一緒に数社のコンサルタントを呼んで技術的な問題点やどのくらいの期間、そしてコストがかかるかなどの情報収集に努めました。
　この間にも財務部の中にこのプロジェクトをまとめる人、すなわちプロジェクトマネジャを決めなければならないことを勧めました。
　一方のS事業部は、彼らもこのプロジェクトの重要性を分かっていたので、筆者が全面的に財務部にてプロジェクトマネジャのアドバイザーとして補佐することに何も言いませんでした。
　その後、財務部もプロジェクトマネジャを自部門から出すことで決めてくれました。プロジェクトマネジャに指名されたAさんは全くプロジェクトマネジメントを知らないということで筆者にいろいろ「何で私が・・・」と悩み事を言ってきました。
　そこで筆者は、「Aさんは財務や経理について十分な知識を持っています。筆者がプロジェクトマネジメント的アドバイスでサポートするので一緒にやれば問題ありません」と勇気づけたりしました。このようにしてこのプロジェクトは財務部中心で進められることになり、そのプロジェクト名称を「次期経理システム開発プロジェクト」と命名し、スタートすることになりました。

　プロジェクトを始めるにあたってまずやらなければならい事は、このプロジェクトが全社の各種システムと広範な関係があり、N本社とのインターフェースもあることから、プロジェクト全体の枠組みを設定する必要があることでした。
　そこでこのプロジェクトは財務部、経営企画部、そして各事業部合同のステアリングコミティーを創設し、その下にプロジェクトマネジャが全プロジェクトを統制・管理するタスクフォースを結成することにしました。そしてプロジェクトマネジャのもとにスタッフを財務部や関連部門から選出し、体制を整えました。
　なお、この時、技術インターフェース調整や技術全般を見る人材が財務部にいなかったので既存経理システムを開発した会社(当社の経理システム導入時の開発会社：C社)から人を出してもらいエンジニアリングマネジャの職務についてもらうことにしました。
　IT業界ではエンジニアリングマネジャという職種は無かったが、筆者のいたエンジニアリング会社と同じように技術中心のプロジェクトマネジャの補佐ということで次のような役割を与えました。
① プロジェクトコントロール(スケジュールおよび技術品質)、インターフェース調整
② C社内の調整(C社を主に経理システムの技術全般開発責任とした)
③ 当社財務部及び各事業部のインターフェース調整とその責任
④ 技術レビュー会議の適宜招集と技術的議事進行
⑤ 各種テスト及び以降に関する計画、調整、執行
⑥ PMへの報告
　このような役割は一般的にプロジェクトマネジャの役割であるが、今回指名されたプロジェクトマネジャは財務部、すなわちユーザ側の立場であるのでこのエンジニアリングマネジャは実質的な本プロジェクトのプロジェクトマネジャとなります。
　なお、筆者のPJアドバイザーの役割はプロジェクトマネジャとしての財務部の業務プロセスの考えとエンジニアリングマネジャの技術上の考えに問題が発生した場合での調整役です。また全体課題会議における相談役でもありました。
　このように、このプロジェクトのキーパーソンを決めてから、ステアリングコミティーと共に各事業部の既存システムに関する調査を行い、各事業部の要望などをまとめプロジェクト全体の枠組みを決めていきました。
　すなわち、
① プロジェクトWBS(Work Breakdown Structure)の作成
② プロジェクト遂行ガイドラインの設定(PJ遂行方針、コントロール基本方針、コーディネーション手順)
③ マスタースケジュール
④ 総合実行予算(最大予算の検討)
　このプロジェクトは特に、極力N社グループ内だけで進めることのできるような体制で基本的な枠組みを作ることで進めました。もちろん、システム開発には運営上の問題もいろいろ出てくることもあり、運用を専門とする同じくN 社グループの運用部門の人達も入れて以下の役割をしてもらうことにしました。
① 設計への運用上の問題の調整や管理
② 要求仕様に基づく設計書レビュー
③ 移行計画書の調整、管理
④ 運用試験実施計画書の調整管理
⑤ 運用マニュアルの作成
⑥ ヘルプデスクの設置・運用業務の支援
　等々システム運用に係る各種の業務の協力をしてもらうこととしました。
　いずれにしても、このプロジェクトはかなり大掛かりなものとなり、予算も数十億円におよぶシステム開発であり、期間も1.5年程度で仕上げることでプロジェクトの枠組みを設定しました。
　NC社総がかりのプロジェクトとなってしまいました。
　こうなると筆者が所属していたS事業部も全体の一部の事業部として介在することになります。
　S事業部はNC社の中でも最も大きな事業部であり、プロジェクト業務を主に実行しているところなので独自の大きな会計システムを運用しています。
　そのためこの事業部の会計システムもこの次期経理システム開発プロジェクトの管理のもとで開発をしてもらうことにしました。
　そうなると当然S事業部は本プロジェクトチームの管理のもとで仕事をすることになるので、筆者も関係することになります。合同会議などの場では財務部の立場でS事業部の人達にいろいろ質問したりその結果の意見調整をしたりしました。
　何となく不思議な成り行きとなりましたが、このプロジェクトを利用して、これまでS事業部の担当部長には無視されてきたプロジェクトマネジメントアドバイザーとしてS事業部の人達に教えることになりました。
　このように、まずはタスクフォースチームを立ち上げ、詳細なプロジェクト計画書を作成し、S事業部とその関係ベンダー、C社のシステム部門、その他の各事業部のシステム担当部門を置いたプロジェクト体制を作り、実行に入りました。

　続きは次月号とします。
ページトップに戻る