「現場の実態が見えない」…
50人の壁、100人の壁。企業にはさまざまな壁がありますが、IT企業の場合、とりわけ100人の壁の重圧が大きいようです。
あるシステム開発ベンチャーの経営者は「会社の規模が50人、80人のときは順調だったんだけど、100人を超えると急に赤字プロジェクトが発生するようになった。以前と同じようにプロジェクト管理をしているのに、なんでかなぁ。おかげで会社の人員は100人から一向に増えない…」。こんなため息をもらしていました。
みなさんの会社でも、こんなことってありませんか?
こんな悩みに対して、年間、200件以上のプロジェクトを進めている、別のあるシステム開発会社の経営者は、「ウチの赤字プロジェクトはゼロ。週に2回、2名の担当者が各部署から膨大なデータを収集して、それをエクセルで管理しているから」。こんなふうに胸を張っていました。
プロジェクト管理にコストをかけることで、赤字プロジェクトの発生を抑制しているワケですが、計算してみると、なかなかの金額。担当者ひとりあたり週に2回、つまり月に8日、プロジェクト管理のためのデータ収集と整理に張りついているので、その延べ日数は年間96日間になる計算。担当者はふたりなので、トータルで年間約200日間かけていることになります。要するに、専任の社員をひとり、雇用するくらいの人件費をかけている、ということになります。
赤字プロジェクトが発生するのを指をくわえて見ているのは論外。でも防ごうとしたら大きなコストがかかる、というのも頭が痛い問題ですよね。
そこで、統合型プロジェクト管理ツール、OBPM(SI Object Browser PM)を提供、プロジェクト管理の手法にくわしい株式会社システムインテグレータの三浦さんに取材しました、三浦さんは同社Object Browser事業部のマネージャーを務め、システム開発企業など、さまざまな企業のプロジェクト管理事例を詳しく知っています。三浦さんによれば、「赤字プロジェクトの発生を防ぐコツは、情報を一元管理し、経営者が知りたい情報をすぐに出せるようにすることです」とのこと。
しかし、「現場の実態が見えない」「現場から報告はあがってくるけれど、事実かどうか、確かめようがない」。こんな感想をもっている経営者は意外と多いと三浦さんは話します。最大のネックは、無料ツールやエクセルで“属人的な管理”をしているため。そもそもデータを一元化しようにもできないんだそうです。
先手先手で施策を打つ
でも、これって、現場におまかせで、一元化する仕組みをつくらない経営層に問題があるのでは?
三浦さんによれば、「これまで、プロジェクト管理に特化したツールがなかったことも、問題の一因です。また、仕組み化しようとすると、それまで慣れていた無料ツールやエクセルなどから未知の新しい方法へ移行する必要があり、現場がイヤがることも予想されます。それも経営者が二の足を踏んでいた理由のひとつだと思います」とのこと。
ひとくちに「プロジェクトの一元管理」と言っても、さまざまなボトルネックがあるんですね。でも、それらは解決できないの?
三浦さんによれば、「当社が提供しているOBPMは、エクセルや無料ツールのデータをそのまま取り込むことができるほか、特定のキーワードでデータをソートすることができます。たとえば、ある部署のプロジェクトだけを見る、契約金額別に見る、コスト超過率が悪いものだけを見る、担当者別にチェックするなど、経営者が見たいデータをすぐに把握することができます」とのこと。
これなら、赤字プロジェクトの発生につながる予兆を早期に経営者が発見することで、先手先手で施策を打つことができそう。でも、実際の運用は難しいのでは?
「では今度、OBPMのユーザー会を取材してみたらどうですか。さまざまな具体的なケーススタディを聞くことができますよ」
そんな三浦さんの誘いに乗って、OBPMユーザー会を取材しました。そのなかから、「うまくいくプロジェクトを増やすためには!?」と銘打ったテーブルディスカッションの模様を抜粋、再構成したレポートをお届けします。
「ゲーム感覚」を取り入れた人材育成
富士フイルムソフトウエア株式会社
ソフトウェア技術本部 基盤技術グループ 主任研究員
◆PHOTO:INOUZ Times
私のテーブルでは、うまくいくプロジェクトを増やすためのポイントは3点に集約されました。
まず、計画の段階からどのようにウォッチしてコントロールしていくのかというマネジメント。次に組織全体のプロジェクトマネジメントの能力と品質を向上し、個々のプロジェクトが円滑に実施されるよう支援することを目的に設置される専門部署であるPMOなどの組織、それと人材育成の考え方です。
プロジェクトのマネジメントとPMOには大きな関連性があるとの点で、みなさんの意見が一致しました。OBPMで何か引っかかるところができてきたら、リスクマネジメント会議やプロジェクト計画会といった会議体で第三者も含めて見積もりの妥当性などを検討することが大切になってくる、ということです。
人材育成については、加点主義で考えている方が多かったようです。たとえば当社では、プロジェクトを成功させたプロジェクトマネージャーにポイントを付与し、ブロンズやプロマネゴールドといったランク付けをし、人事考課と連動させています。
人事考課は非常にデリケートな話になってしまいますが、ある種、こうしたゲーム性をもたせるのは有効かもしれません。あと何ポイント足りないから、このプロジェクトを成功させなければいけない、といった前向きなモチベーションを引き出すのに効果を発揮しています。
また、外資系の場合、成功した場合は現金が出るという話も出ました。ストレートな方法で抵抗感を覚える人がいるかもしれませんが、うまくいっているのなら、それはそれでいい方法かもしれませんね。
誰かが「見ている」状況をつくる
株式会社ワイ・ディ・シー
情報活用基盤事業本部 事業管理グループ グループ長
◆PHOTO:INOUZ Times
プロジェクトを成功に導くポイントは、いかにリスク管理するのかという点につきますが、私のテーブルではその方法について熱心に意見がかわされました。
たとえばアテにしていた優秀なエンジニアがアサインできなかった場合。そうなると、ある程度、実力が劣るエンジニアをプロジェクトにつけなければいけません。その場合、当社では、これ以上その人にまかせていると危険というポイントに日付をつけてリスクを見極め、マネジメントしています。
OBPMには日付を入れる欄があります。そこに、「これ以上は危険」という日付をあらかじめ記入し、その日付が迫ってきたり、あるいは過ぎてしまった場合、支援するエンジニアをつける。こうしたことをやっています。
このリスクの見極め時期を過ぎた場合、担当エンジニアを責めることはしません。そのまま行けそうなのか、あるいは支援を厚くしなければいけないのか。エンジニアと話し合い、具体的なプロジェクトマネジメントを行うんです。OBPMの機能をうまく使うことで、リスク管理の面でも効果を発揮してくれるのではないか。そう思っています。
また、OBPMをきちんと使いこなすには、誰かが見ている状態をつくるのがポイント、という話も出ました。たとえば、なにか記入しても誰もなにも反応してくれないでは、そのうち使わなくなります。記入があったら直属の上司が反応する。こうした状態をつくっていくことがプロジェクトを成功させるポイントではないかと思います。
プロジェクトが成功した「その先」の明確化
株式会社システムインテグレータ スペシャリスト
◆PHOTO:INOUZ Times
プロジェクトがうまくいった後に発生する評価のあり方について議論が盛り上がりました。「よかったね」「悪かったね」といった評価だけ聞かされても、それで終わってしまい、うまくいくプロジェクトを増やすことにはつながらないからです。
(そのプロジェクトを担当している現場から)フィードバックに基づいてデータを収集し、評価するという流れですが、フィードバックしてもらうからには何かしらその現場に対してメリットを返さなければ現場は正しいデータをインプットしないんじゃないか。極端に考えると、そんな懸念もあります。
評価を行うにあたり、確度や精度の高い当初計画を立てることの重要性は理解しています。最終結果が計画どおりでも当初計画がいい加減なものであれば、適切な評価はできませんから。
一方で、私自身、プロジェクトリーターをやっていて経験的に思うのですが、たとえば粗利率10%とか30%などの達成基準を目標として立てて、それをクリアしたら成功と定義したところで達成基準をクリアして当たり前という考え方があります。ですから、プロジェクトが成功し、評価されたその先に、うまくいくプロジェクトを増やすカギがあるのではないかなと。
会社のために頑張ろうという人もいれば、報酬など個人的なメリットのために頑張る人もいるわけです。ですから、プロジェクトが成功したその先はどうなるのか、明確な評価基準があってもいいのかな。そんなことを感じました。
「兆候」を発見して掘り下げる
株式会社システムインテグレータ リーダー
◆PHOTO:INOUZ Times
プロジェクト成功の定義について、いろんな意見が出ました。
システムを無事に納品することだけではなく、その後の保守で障害が出て工数が膨らんでいけば、結局、利益に影響するので、それは成功とはいえないんじゃないかと。
ですから、現実的にはなかなか難しいですけど、納品プロジェクトと保守プロジェクトをトータルで評価することが大切なのではないか。そんな意見がありました。プロジェクトがうまくいっているのかどうかを判断する基準は、工数の予実管理だけではなく、やはり品質の問題が重要な要因だと思います。
契約の関係についても生々しいお話がありました。営業が仕事をとるためにつくった見積もりと、開発側が算出した見積もりでは乖離が生じる場合があります。そうしたとき、どちらの数字を基本にするのか。会社として合意形成しているのかどうかが、うまくいくプロジェクトを増やすためには見逃せない点なのかなと思います。
管理実行のところでは、進捗報告をする時に必ず固定の7項目を毎回報告することにしているという事例がありました。その7項目の内容に何か変化があったら、よく変わったのか、悪く変わったのか問わず、変更があったということに着目して、そこを掘り下げていくという方法です。
また、課題管理をしていた場合は、課題の更新がしばらくされていないなど、放置されているような兆候を見つけるのが大事だというお話も参考になりました。
脱「現場まかせ」がカギ~取材を終えて
どうでしたか? みなさんの会社でも実践できそうな事例があったのではないでしょうか。
ユーザー会の終了後、三浦さんに赤字プロジェクトの発生を防ぐポイントを改めて質問しました。
「いちばんのポイントは“社長から見られている”という状況をつくることです。そのうえで、経営層は負荷状況や赤字プロジェクト発生の予兆を把握し、必要な手を早期に打つ。誰も赤字プロジェクトをつくりたくて仕事をしているワケではありません。可視化され、一元化されたデータで現場と経営層がプロジェクト管理をともに進めることが、赤字発生のなによりの抑止力になると思います」
なるほど。となると「わからないから」「見えないから」という理由で現場まかせにしていることが、赤字プロジェクトを発生させる大きな原因。こんなことも言えそうです。