はじめに
ファシリテートGの「まつ」です。
これまでシステム開発や基幹システムの刷新といった多くのITプロジェクトの現場を経験させていただきました。その多くは発注者側のPMOとしてプロジェクトマネジメントの支援をさせていただくことが多かったです。
そんな中で開発主体である所謂ベンダー側のメンバーとのコミュニケーションで苦労した際に感じたことについて今回は記載したいと思います。
現場で発生したこと
冒頭でコミュニケーションに苦労をしたと書かせていただきましたが、具体的な内容としてはWBSの作成や管理に関する認識がステークホルダーと揃っていなかったことで、管理や確認に時間を要してしまう問題が発生してしまったことでした。
WBS自体はITに限らず、プロジェクトの現場では一般的に利用されるツールのひとつだと思いますので、比較的利用された経験のある方が多いのではないでしょうか。
PMBOKガイドによれば、WBSは、”Work Breakdown Structure”の略で、元々は米国の国防総省が考案したツールです。個々の要素を「成果物」で表現するのが基本とされており、
作業及び作業における成果物を管理しなければならないのですが、日本では”Work”を「作業」と単に直訳してしまっていることから、単に作業をスケジュール化したものとなりがちな印象があります。
今回開発を依頼させていただいた開発ベンダーにWBSを作成いただいたのですが、内容を確認すると、作業の項目は概ね合っていそうではあるものの、各作業に紐づく成果物や後続作業などの関連が読み取れないようなものでした。
（今思えばこの違和感に気づいた時点で再作成を依頼していたら状況は変わったかもしれませんが・・・）
WBSを作成いただいた当時の状況としては、次工程が既に開始されている状況（本来はあってはならないですが）かつ、開発ベンダーの作業も諸々逼迫していたこと、発注側のお客様からも特段指摘がなかったことなどから、今のWBSでもそれぞれの作業とスケジュールを管理すること自体になにも問題はないと考え、そのまま利用することになりました。
しかし、工程が進むにつれて管理する立場として徐々に問題が出てきました。
どのような問題が生じたかと言いますと次のようなものでした。
①作業そのものの目的や意味が不明確
②作業同士の関係性、順序性が不明確
③クリティカルパスが不明確
正直、作業遅延や課題もなく全てが順調であれば、作業管理ベースのWBSでも大きな問題にはならなかったのかもしれませんが、ひとつでも何か問題が発生してしまうと、作業だけのWBSでは管理コストが増大するということを身をもって経験することとなりました。
以下はほんの一例ではありますが、
①作業そのものの目的や意味が不明確
⇒今回の工程では不要な作業もタスクに含まれてしまっていたことが後から判明
②作業同士の関係性、順序性が不明確
⇒遅延タスクが発生した際に、影響範囲やリカバリのためのタスクの組替えを行って問題ないのか判断がつきにくい
③クリティカルパスが不明確
⇒作業スケジュール上の真の期限の判断が難しく、リスケの正当性を判断できない
進捗確認会議の場では、タスク遅延の原因や影響範囲、対処方法やリスケの妥当性の確認に時間が割かれ、大幅に会議時間を超過してしまうことが多々ありました。それによってさらに作業時間が限られてしまうといった悪循環が発生していました。
原因と改善策
原因は、発注者、ベンダーの双方でWBS作成前に管理レベルの認識が揃っていなかったことではないかと個人的には感じました。
当たり前のように活用されているツールだからこそ、「知っているいるだろ」、「理解しているだろう」とせず、記載の粒度やルールなどステークホルダーやプロジェクトの状況に合わせて、きちんと定義をしたり認識合わせを事前にしておく必要があると感じました。
そのためにも普段からのステークホルダーとのコミュニケーションもそうですが、お客様やプロジェクトの慣習やお作法的なところまでしっかり理解して、根回しといったことも行っていくことで改善ができるのではないかと考えました。
最後に
後から色々指摘をしても、手戻りで無駄な工数が発生してしまったり、そもそも指摘された側としては心象もよくないでしょうから、お互いに気持ちよく業務を遂行できる環境を整備するためにも、事前の調整をしっかり実施しようと思います。
今回の自身の経験と反省を活かして、何事も早め早めの対応を心掛けようと改めて感じました。
Opmerkingen