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

ゼネラルなプロ (82) (実践編 - 39)

向後　忠明　[プロフィール]　：8月号
　タスクフォースチームの立ち上げをS事業部とその関係ベンダー、そしてC社のシステム部門やその他の各事業部のシステム担当部門等からなるプロジェクト体制を作り、実行に入りました。
　このプロジェクトの特徴はユーザである財務部門が中心となって、システム開発の全工程を実行するといったものでした。
　これまでのシステム開発は顧客のプロジェクト使命に示される要件に従って請負企業が契約をおこないシステム開発をするといった形をとるのが一般的でした。
　しかし、システム開発の案件では顧客要件が明確でないこともあり、その場合のプロジェクトの多くが失敗していることをよく聞きました。そのため要件の設定にこのシステムを使用する財務部が中心となって行うべきと考えました。
　そのため、このプロジェクトではプロジェクト要件を創発する財務部が中心となって、進めることにしました。
　もちろん、漠然とした既存システムの更改と言ったプロジェクト使命を可能にするには既存のシステムの技術的な要件も基本仕様に示す必要があります。このことは財務部だけでは無理であり既存の経理システムを開発したC社のシステム部門の技術者をプロジェクト体制の中に入れる必要がありました。
　このようなことで、プロジェクト体制の中心は財務部員が運用面の仕様の固めとプロジェクトチームのマネジメントを担うという立場で動けるようにしました。
　財務部員に対するプロジェクトマネジメント手法についての教育は、PMアドバイザーが付かず離れず一緒に仕事をしながら教えていくことにしました。

　そして、プロジェクトマネジャ及び財務部の人達、PMアドバイザーそしてC社からのエンジニアリングマネジャが中心となって、プロジェクトの基本となる下記の仕事をまとめていきました。

① 社内システムとしての構想作りのためのプロジェクト体制作り
② 既存システムの調査や社内の各事業部のシステム運用面での問題点の発掘に関するヒアリング
③ それに基づくプロジェクトの枠組み作りとWBSの構築、マスタースケジュールの作成、
そしてコミュニケーション手順の作成
④ プロジェクト実行のための体制作りとプロジェクト実行計画書の作成

　当初は、全くシステム開発案件に経験のない財務部の人達がこのようなことができるか不安であったがプロジェクトマネジャをはじめ皆さんは謙虚に「わからないところはわからない」と素直に筆者に質問してきていました。
　もちろん、重要な実行計画書の作成や技術的条件設定などにはプロジェクトマネジャとエンジニアリングマネジャ、そして筆者が重点的に介入してその作業を進めました。

　その後の作業は引き続きシステム要件に従って、設定された仕事の範囲に従い各事業部は詳細設計に入りました。詳細設計はすでに決まった基本仕様に基づき作成されました。
　この辺になると財務部スタッフは中身に入れないので主に進捗度合いのマネジメントになります。
　この段階では財務部員はあまり出しゃばらず、技術スタッフと密なコミュニケーションをとりながら良い協調関係で仕事を進めていました。
　実行中に問題が発生した場合は定期的な会議(課題会議)を財務、C社のシステム部門、そしてシステム運用部門の関係者が集まりそれぞれの立場で忌憚のない意見を出し合って解決していきました。

　詳細設計が始まるとプログラム製造に入ることになりますが、この場合は自社及び関連事業部そしてC社の所掌部分はそれぞれの業者にお願いすることになります。
　その引合い作業は統一した仕様にて発注する必要があるので、その条件の構成を関係各部門が集まって調整を行います。
　この作業については引合書及びその技術要件に従い、財務部のプロジェクトマネジャやエンジニアイングマネジャそして筆者が集まって最終的な業者の決定をしました。
　プログラム製造が始まるとこれまで以上の人が動き始めることになります。
　この作業は詳細設計に示される要件を厳密に、一語一句、一点の間違いもなく作業を進めるといった、いわゆる機械のピン一本、ねじ一本の取り落としの無い精度の高い作業が要求されます。
　そのためかなり神経を使う仕事でそれも夜遅くまで仕事をすることもあり、マネジメント側も相当気を使う期間です。
　もし上流側で間違った仕様でこの工程に仕事がそのまま流れてきて、やり直しになれば当然期間もコストも大幅に遅れたり増加したりします。
　システム開発においては顧客の要件定義が曖昧な場合、その要件の吟味を正確にしておかないと結局は多くの問題を発生させることになります。そのため、この様なことの無いように心がけ、前にも述べたような事情で要件の設定には関係各部門や関係者からのヒアリングを慎重に行い、時間をかけて検討したのです。しかしそれでも開発の途中段階で要件設定時でも気が付かなかったことで要求の拡大やコストがらみの要求の絞りこみなどいろいろ発生してきます。
　以下にその参考例を示します。

参考例

　また、プログラム製造後のシステムテストにおいては分担して行われた各サブシステムの結合試験があります。ここでの問題を防ぐためには基本設計や詳細設計にて十分詰めておく必要があります。
　このようにシステム開発では上流での作業の良し悪しがこのプログラム製造や各種テスト段階で明らかになってしまいます。
　そのため、関連各組織との密なコミュニケーションによって、プロジェクトの初期の段階で各サブシステムとのインターフェース間の齟齬が無いような手立てをとっておく必要があります。
　このように顧客要件が徹底されても、システム開発プロジェクトでは多くの仕様変更が発生することを、大きなシステム開発をやることでいろいろと学びました。

　もう一つシステム開発業務で重要なことは詳細設計やプログラム製造そして各種テストでは皆さん夜遅くまで毎日真剣に仕事をしているためのミスも発生します。
　プロジェクトマネジメントにおいて「コミュニケーションクライメートの醸成」という言葉があります。
　これは「一緒には働く人達の意識を高める良い職場の雰囲気作り」という意味であり、モチベーション向上に効果のある方法です。
　特にプログラム製造段階は多くの派遣の人もいることや、また、かなり神経を使う段階でもありプログラマーやSEも気分的にイライラしている時期です。
　この時にはハッパをかけるより、トップに立つ人間は配下の人達に気を遣うということが大事なことです。
　例えば、このプロジェクトの場合はプロジェクトスポンサーである財務部長が頻繁に担当の所にきていろいろと差し入れをしたりしていました。このような環境でのトップに立つ者の行動としては素晴らしいと思いました。
　このようなことが担当者のモチベーションにも大きな影響を与えることになります。

　このように、多くの人間が毎日現場で作業をするのを見て、筆者自身、仕事の中身の詳細はわかりませんでしたが、25年前のトルコ中央銀行決済システム開発プロジェクトのことを思いだしました。この当時筆者は、全く、システム開発の経験もなく、何をどのようにしたらよいかもわかりませんでした。またアドバイスをしてくれる人もいませんでした。その時のことを考えると、筆者のアドバイザーとしての役回りは経験のない集団の指導に少しは役に立ったような気がします。
　ところで、このプロジェクトでトルコプロジェクトでは全く経験したことの無い技術上のことで驚かされるものがありました。今、システム開発に従事している人から言わせれば当たり前のようなことですが、それはプログラム開発において絶対的に必要なデバック作業といった工程での仕事です。
　何が驚かされたかというと、デバック(プログラムの不備を見つける試験)はトルコプロジェクトの頃はデバックマシンなどなく人手で行っていたように記憶しています。
　システム開発で最も労力と神経を使うのがこの作業であり、この作業を機械でやっているのを見てびっくりしました。
　25年という月日はやはり長いものと感じました。技術は日進月歩であり、それだけに毎日の勉強による自己啓発が重要と考えました。
　その後はこのプロジェクトも順調に進み、スケジュールの遅れもなく予定通りに完了し、運用されることになりました。
　プロジェクトが完了した時は財務部長とも手を握ってシステムの完成を祝いました。
　このプロジェクトの成功はすでに前にも述べたようにシステム要件の設定に多くの時間をかけ、システム開発に必要な人材を各所からゼロベースで集め体制を作り、実行においては良い職場の雰囲気の中で業務が行われるように配慮したことに起因していると思いました。

　今月はここまで
ページトップに戻る