サービス業務はプロジェクト管理不要ってホント!?(Vol.64)

 2019.11.11  株式会社システムインテグレータ

プロジェクトリーダーの皆様、日々のプロジェクト管理お疲れ様です。
「プロジェクト」という言葉を切り出すと、その性質には様々なものがありますが、IT業界でいうとそれは一般的に開発プロジェクトがイメージされる場合が多いです。

開発プロジェクトには要件定義~設計~製造~テストというフェーズがあり、それぞれの局面において様々な課題や障害が発生したり、納期を守るためにスケジュール・要員調整をしたりと、当然のようにプロジェクト管理が必要、と思われています。

その反面、準委任契約などのサービス業務についてはどうでしょう?
「成果物や納期も特に無いし、プロジェクト管理なんて必要ないでしょ」と思われる方もいるかもしれません。

このブログでは、主にプロジェクトリーダー(またはプロジェクトマネージャー)や、会社全体のプロジェクト管理ルールを検討されている担当者の方々に向けて、サービス業務が本当にプロジェクト管理不要なのかどうか、という点について考察していきたいと思います。
※弊社プロジェクト管理ツール「SI Object Browser PM (以下OBPM)」の機能を通して、サービス業務においてプロジェクト管理可能な要素を解説しつつ、考察していきます。

サービス業務にだって課題は発生する!

一般的な開発プロジェクトにおける課題は以下のようなものが例として挙げられます。

  • ○○画面のレイアウトが決まらない。
  • △△バッチの実行時間は何時にするか。
  • □□処理の性能が遅すぎる。 等

一方、サービス業務における課題とはどのようなものがあるでしょう?
世の中には様々なサービスが存在します。例えば、OBPMをお客様先に導入する際にも、マスタ設定や運用ルール作成を支援する「導入支援サービス」と呼ばれるメニューがあります。この「導入支援サービス」におけるよくある課題としては、

  • プロジェクトの登録単位をどうするか。
  • 初期稼働から品質管理メニューを利用するか。
  • 勤怠データを勤怠管理システムから取り込むか。

といったような課題があります。

「これらは全てお客様の課題だから、我々が管理する必要はない。」
果たしてそうでしょうか?それが例えお客様の課題であったとしても、サービスを提供する側として、ユーザーの課題も把握していないような企業に発注をしたいとは到底思えません。
よって、それが誰の課題であったとしてもプロジェクト全体でみた時の一つの課題として管理すべき、管理とまではいかなくとも把握はしておくべき、と私は感じます。

ただし、サービス業務という特性上、サービスを提供する側とすれば、自分たちの力だけではどうにもならない課題があるというのも事実です。 その場合は期限だけでも管理をする(いつまでに課題が解決しないと、後続のスケジュールに影響が出ます、といったような)ことで、サービスの品質向上につながるのではないでしょうか。

1

上記はOBPMの【課題登録】画面です。

赤枠で囲んでいる対応期限欄に課題解決期限、それがお客様の課題であれば、対応希望者欄にお客様アカウント(ライセンス消化なしで作れます)を指定します。
これにより、お客様がボールをもつ課題はいつまでに解決しなければならないのか、という情報を管理できます。

「開発プロジェクトはスケジュールやコストまで管理するけど、サービス業務についてはOBPMにプロジェクトを立てた上、課題のみを管理する」
これだけでも充分にサービス品質向上に寄与でき、プロジェクト管理する価値が生まれるのでは、と思います。

成果物がないからこそ、進捗報告による見える化を!

一般的な開発プロジェクトはモノが対価となるため、成果物や納期といった要素が存在します。また、設計書やソース、テスト仕様書といった明確なOUTPUTが存在するため、進捗具合や品質が視覚的に捉えやすいといった特徴があります。
一方、サービス業務には成果物や納期、明確なOUTPUTが存在せず、目に見えない要素が多いように感じます。

開発では当たり前のように進捗報告を行う習慣がありますが、サービス業務にはそういった習慣(進捗報告)が根付いていないケースが多い、と感じるのは私だけでしょうか?
目に見えない要素が多いからこそ、気づいたら大炎上!といったケースをたまに見かける気がします。危険察知のためにも実はサービス業務の進捗報告こそ、おざなりにすべきではないのかもしれません。

2

上記はOBPMの【進捗報告登録】画面です。

サービス業務の場合、ガントチャート等から集約される画面右側の定量報告エリアは、データの入力度合いによってはあまり参考にならない場合もあるため、重要なのは赤枠で囲んだ定性報告エリアになります。報告者にはフリーで記載させるのではなく、上記画面のイメージの通りに予めカテゴリを定義して記載してもらうことで、報告レベルの統一化や、確認者の読みやすさUPにつながっていきます。カテゴリの定義は開発プロジェクトと同じものを使うのではなく、サービス業務に特化したカテゴリが作れれば、なお効果が上がると予想できます。

マイルストーン機能を活用し、サービス品質の向上を!

サービス業務をプロジェクト化し、状況を見える化する手段として上述の【進捗報告登録】をご紹介しましたが、OBPMには他にも【マイルストーン(品質基準設定)】という機能があり、この機能を用いる事により、サービス期間中に予めチェックポイントを設けることが可能です。

例えば、サービス開始時、お客様とのキックオフ開催前にチェックポイントを設け、第3者(PMO、品管など)に参加してもらい社内でチェック会を実施することにより、サービス品質の向上につなげることができます。

3

上記がOBPMのマイルストーンに紐づく【品質基準設定】画面です。

チェックリストは予め標準化したものをプロジェクトに展開できるため、サービス業務に特化したチェック項目を用意しておくことで、容易に効果的なチェックが可能となります。
前述のキックオフ開催前のチェックであれば、キックオフ用資料作成時のポイントをチェックリストの項目として用意しておけば、サービス品質向上はもちろん、新米PLへのひとつの指針としても非常に有益なチェックリストとなるはずです。

・・・で、結局サービス業務ってプロジェクト管理必要なの?

ここまでOBPMの機能を通して、サービス業務においてプロジェクト管理可能な要素を解説してきました。どれか一つでも「管理すべき!」と思っていただいた方は、サービス業務に関しても是非プロジェクト管理していくべきかと私は思います。
また、どれも「管理不要!」と思った方でも、少し発想の転換をしていただきたいと思います。
たしかに、サービス業務のプロジェクト単体で見た時は管理不要なものもあるかもしれません。

しかし、私が伝えたいのは「単体」ではなく、「全体」で考えていただきたいということ。
自社内でいまどういう契約(プロジェクト)が動いていて、誰がどれだけの時間、その契約に従事しているのか、これだけでも情報を登録しておけば、社員の要員負荷管理もできますし、会社全体の管理レベルの向上につながるのでは、と考えます。

見えにくい部分をできるだけ減らし、業務の状況をどんどん可視化していきましょう。

recruit

ranking

第10回OBPMユーザー会 講演資料 「プロジェクト計画力はWBSとプロジェクト憲章にあり!」

RELATED POST関連記事


RECENT POST「プロジェクトは現場で起きているんだ!」の最新記事


この記事が気に入ったらいいねしよう!
プロジェクト管理ツール比較ガイド:全7製品を10項目で徹底調査
ブログ購読のお申込み

RANKING人気資料ランキング

RECENT POST 最新記事

RANKING人気記事ランキング