「こんな会社でPMなんてやってられない」とPM支援で参画した際に思うことがあります。システム開発を進める場合、プライマリーで請け負った開発ベンダーの社員がプロジェクトマネージャーを担うことになりますが、会社のルールに従いつつプロジェクトを推進することに、とても苦労している状況を目にします。
ジョブ型採用やプロジェクト型ワークスタイルなど新しい働き方が進んでいますが、日本企業の旧態依然な組織構造はいまだ健在です。効果的なルールであれば良いのですが、常識化した悪習慣を疑うことなく、非効率で極端に言うと無意味なルールに従いつつプロジェクトマネージャーを全うすることは、とても大変です。
オフィスをお洒落にフリーアドレスにしたり、リモートワークを積極的に導入したりしたところで企業文化が変わっていなければ、見かけ倒しです。今から就職する人や転職を考えている人は、オフィスの見た目、トレンドを意識した採用、素敵なワークスタイルに騙されてはいけません。このようなことも会社の魅力のひとつではあるものの、旧態依然な企業文化のままだと入ってから苦労することは間違いありません。
かんたんイラスト（記事を読む時間のない人へ）
旧態依然な組織の問題点
PM支援でシステム開発プロジェクトに参画すると、プロジェクトマネージャーが忙しくて、プロジェクトを切り盛りできていないことが良くあります。以前は、単に個人のスキルや経験の問題と思っていましたが、多くの開発ベンダーで同様なため、組織の問題もあると思っています。
① プロジェクトに関係ない会議が多い
プロジェクトマネージャーのカレンダーが、会議でびっしり埋まっていることに驚きます。１～２週間、一緒の時間を過ごすと、その理由が見えてきます。プロジェクトの進捗会議やレビュー会も当然ありますが、課内会議、部内会議、職制会議、勉強会、研修、面談、社員会、座談会といったプロジェクトに直接関係のない会議が多いのです。
100%稼働でクライアントに費用を請求しているにもかかわらず、社内の会議でこんなにも稼働が割かれていて詐欺にならないのか心配になります。古き良き時代であれば、その分は残業しますと言えましたが、昨今の働き改革の中では、そう言うこともできず、実態としても、プロジェクト作業の割合は確実に100%を下回っています。
昔は、クライアント先に常駐して作業することが多く、席にいないと、すぐに「なんでいないの？」とクライアントから確認が入り、「社内都合です」と言うと、「その分費用から引いて請求してね」と冗談か本気か分からないことを言われたりしました。今は自社開発やリモートワークが多く、厳しい目で見られませんが、だからと言ってプロジェクトに100%稼働を割けない状況は良くありません。
② 組織の上長への報告
プロジェクトマネージャーは、本来、開発側のプロジェクト責任者とクライアントへ状況を報告すれば良いはずですが、所属部署の上司が実質的にプロジェクトに関わっていない場合でも、上司への報告も慣例として行われています。
プロジェクト型の働き方をしていても、実態は、階層組織型の会社ルールに従いつつ、プロジェクトを推進してしまっているのです。
③ 階層的に行われる報告に付き合わされる
さらに、会社が大きいほど組織も階層化されているため、直属の上司だけでなく、さらに上の方まで、例えば、係長から課長、課長から部長、部長から担当役員など何度も報告が行われることがあります。特に、大規模プロジェクトや問題を抱えているプロジェクトでは、上層部も状況が気になるため報告の回数が増えやすいです。
階層的な報告で、部長報告には課長が、役員報告には部長がというように報告者が移り変わっていけば良いのですが、最も状況を把握しているプロジェクトマネージャーが報告者として全ての会議に呼ばれることがあり、これは、とてつもなく悪習慣です。すべての報告をプロジェクトマネージャーが実施していたら、当然、時間は削られていきます。
④ 社内向けの報告資料の作成
恐ろしく酷い場合、社内報告のために、わざわざ資料を作成しています。毎週、クライアントへ進捗報告をしているはずなので、社内でもその資料をそのまま使えば良いものを、社内テンプレに合わせるために作成しなおしたり、役員向けに新たに作ったりなど、はっきり言って社内向けの資料作成は無駄です。
旧態依然な企業文化がPMを潰す
年功序列は、いまだに日本の会社によく見られます。
特に大企業では、課長と部長の間に次長や担当部長を挟んだり、責任が曖昧な中で階層が増える傾向がいまだにあり、目的がわからないままに上司への報告が行われていることがあります。報告を受ける上司も、指摘することに意義を感じて、無用で余計なフィードバックを与え、プロジェクトに無駄な作業を増やすことがあります。日本の会社では、組織の上司部下の関係性が強いため、フィードバックを無視することも出来ず、プロジェクトマネージャーとしては苦しい立場だと思います。
このような組織の問題を抱えたプロジェクトマネージャーは、本来の業務であるプロジェクトの指揮が疎かになり、進捗遅延や品質低下を招いてしまう可能性が高いです。プロジェクトの状況が悪くなればなるほど、報告の数も質も求められるため、ますますプロジェクトマネージャーの負荷が高まっていきます。上からの厳しい言葉も増えて、精神的にも疲弊してしまい、結果としてプロジェクトは炎上状態に陥ってしまうのです。
炎上状態になったら、助っ人が次々に送り込まれ、プロジェクトマネージャーは、その立場とともにプライドも崩れ落ちてしまうのです。
これでは、良いPMは育ちませんし、PMを目指そうとする人も増えません。
身を削ってPMを助けることをせずに、フィードバックだけを与える上司は困りものです。
組織の問題から逃れる方法
プロジェクトマネージャーは、プロジェクト推進に時間もエネルギーも注きたいです。組織の問題から逃れ、少しでも重荷を軽くする方法はあるにはありますが、一社員の立場で全てを対処するのは、なかなか難しいのも現実です。
・上司への報告を一度にまとめる
上司から報告を求められたら、この報告をどこまで上げていくつもりか確認しましょう。出来れば、この先の上司への報告会には参加しない約束をとるか、それが困難な場合は、先の上司も含めて一度で済ませるよう調整を図りましょう。これを言うのは、一社員にとってはなかなか難しいことかもしれませんが、プロジェクト管理に注力したい旨の事情を説明すれば、中には分かってくれる上司もいます。
・報告書で見通しを示す
毎週、クライアントへ報告している進捗報告書で、今の状況だけを伝えている場合は、改善の余地があります。プロジェクトを間近で見ているクライアント担当者や話す機会の多い直属の上司であれば、今の状況を報告すれば何等か察しが付いて指摘を出せますが、遠目に関与している人にはよくわからないのも当然です。そのために、詳細を知りたがり、階層的な報告にプロジェクトマネージャーが呼ばれてしまうのです。
本来、報告とは、見通しを示すものです。
報告書では、今の状況から見て、この先、計画通りに進められるかの見通しを示すことが重要です。特にマネジメントが知りたいことは見通しで、むしろそれだけ知れたら良いと思っている人もいます。なので、毎週クライアント向けに作成する報告書にこの見通しを入れておくのです。そうすることで、資料の汎用性が高まり、階層的な報告に毎回呼ばれることを減らせますし、社内向けに報告資料を作り直す必要もなくなります。
・会議時間に上限を設ける
呼ばれたから会議に参加する人は多いです。会議に参加する意味を確認したり自問して、必要性がないのであれば参加しないことも考えるべきですが、立場によっては断るのは難しいでしょう。
そんな時は、会議に参加する時間に上限を設定しまうアイデアがあります。本質的には会議を棚卸したうえで必要性を一つ一つ確認して会議の精査と優先度付けを行うことが大切ですが、それで改善されない場合には、逆ノルマのように一月の会議時間に上限を設けてしまうのです。強制的にキャップを設けることで、会議時間を減らせるだけでなく、会議の必要性自体を再評価するきっかけにもなります。効率化を叫びつつも自身の負荷が高まることを危惧しているような管理職には聞き入れてもらえないアイデアですが、相談するだけなら怒られることはありません。運よく採用された際には、階層的な報告会の出席依頼が来ても、「今月上限越えちゃったので欠席します！」と言ってしまいましょう。
このアイデアは、大規模なプロジェクトであれば、プロジェクトマネージャーがチームリーダーに対して設定することも有効です。PMが忙しいプロジェクトは、たいていチームリーダーも忙しくしています。
まとめ
本質的には、こんな小手先のテクニックではなくて、企業文化を見直すことを最優先で考えて欲しいものです。IT業界は、他の業界と比較して働き方改革が進んでいるように思われますが、実態はかなり停滞していると感じています。多くの会社で旧態依然の組織構造が残っていて、特にここに挙げた社内会議と報告の階層化は、プロジェクト推進を阻害する要因でもあります。一社員が会社のルールにメスを入れて改革していくことは難しいですが、せめて「報告書で見通しを示す」など自分だけで出来ることはして、可能な限り本来のプロジェクト業務に集中して欲しいです。
昇進して部下にプロジェクトマネージャーを持つ立場になった際は、無用な会社ルールを見直して、旧態依然な企業文化からの脱却をして欲しいと願います。
効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！
