プロジェクトマネージャが残業ゼロを実現するためにしたこと

on


とある日の昼下がり……。

「ちょっといいですか。」
「はい、なんでしょう。」
「3か月間すごく頑張ってもらったんだけど。」
「そうなんですよ、もう、大変ですよ。」
「でね、36協定があってね。」
「はい？」
「もう規定を通り越して延長状態であと少しでそれも超えそうなんですよ。」
「はい……。」
「なので、これからは残業ゼロでお願いしますね。」
「(ふぁ！)」
「えーこれから佳境なんですよ。」
「いえ、これ超エライ人からの指示なんで。」
「そうは言っても……いやこれから構築とか試験とか始まるんですから。」
「超エライ人からの指示なんで。」
「さいですか。」

「すみません。少しエライ人さん。」
「どうしたの。」
「残業してはいけないって指示されたんですが。」
「そうだよ、するなよ。」
「いや無理ですから。」
「じゃなくて、あとどれくらいのり代があるか教えてください。」
「ちょっと待って。nn時間だな。」
「(意外とあるじゃん！)」
「超えるなよ。頼むよ。」
「は〜い(わからんけど)。」


プロジェクトマネージャの存在価値
プロジェクトマネージャの存在価値の一つは、メンバが困ったときにいつでも(予定された不在は除いて)メンバの相談にのれることだと思っています。24時間ではないけれど、例えばデータセンターでの構築作業をする際に、ファシリテーションがらみで予定されていたものが準備されていないとか、構築中に製品トラブルになって今後の作業について判断出来ない状況になったり、そうした対外的なことで困ったりするようなでき事があったとき、メンバに判断を求めるのは酷なこととかあって、そうしたところの指示はやはりプロジェクトマネージャやSEリーダが請け負うところだと思っています。


それは、行動することによる責任の所在がメンバになることは避けさせたいという観点もあったりします。


設計フェーズが終われば、あとは開発と試験の工程になるわけで、いくら検証環境で準備をしつくしても現地の環境でやってみたら、

「あーADのアカウントを申請したのにできていないよ。」
「なにこれ？インストーラ、こんなふるまいしなかったよ。」


なんて起きちゃうわけで。逆に計画した予定どおりにことが進んだり、前倒しで作業が進行してしまうと“逆に”不安になったりするんです。まぁ、どれだけ日頃からトラぶっているかということでもなくて、プロジェクトでデリバリするシステムはそれごとに依存する環境が違うから、十分な時間を掛けてもトラブルときはトラブルんですよ。(キリッ


プロジェクトマネージャなのに残業できないとどうなるか
そんな困ったときの切り札的なプロジェクトマネージャが裁量で他応できないならどうなっちゃうのか、って話です。単純に困りましたよね。今のままのような対応では確実にのり代をあっという間に食いつぶしますもの。


プロジェクトチームの運営を変えないとプロジェクトが回らない。


これ結構インパクトありますよ。メンバのロール設計をどう見直すか。作業に仕方をどうするか。生産性の向上は、その生産にかかわるしくみを変えないと上がらない。でもモノを生産するような決まりきった仕事はほとんどなくて、割り込みをどうさばくか、的な応用の必要な業務に対応するか、ってことに改めて直面するんですね。


採用してたシステム開発手法が役に立つ
このプロジェクトも、カンバン、チケットでのTiDDを採用していたんですね。カンバンも、TiDDも使ったことはなかったメンバばかりだったけれど、数か月経ってだいぶ慣れていたんですね。


その上、タスクの定義、due dateのオーダに基づくタスクの完了日の日程調整、担当のアサイメント、レビューのしくみがルーチンワークとして成り立っていたんです。ほんと、思いますよ。日々の刷り込みって大事だ、と。


別に、カンバンやTiDDでなくてもいいんです。ウォーターフォールでもいい。兎に角、採用したシステム開発手法を不格好でも回していることがそのプロジェクトとして今の時点ではふさわしい姿として出来上がるんですから。


で、残業ゼロのためにどうしたのよ？
もう、チームのロール設計を変えた、というよりデレゲートです。それを受け止めるしくみ＝システム開発手法は定着している。それぞれのメンバの作業品質はある程度確保されている。で、あればもう権限移譲しかないです。


ただ、いきなり権限委譲してもそれを受けるメンバが、

「それはできません。」
「オーバーワークになってしまうかも。」


って思っても不思議ではないです。だって、権限移譲するということは、仕事を受けてもらうということなんですから。なので、キーパーソンのメンバに集まってもらって、

“一人一人の今の役割、今の事情、これから期待している役割”


について話しました。担当であったメンバはサブSEリーダに。サブSEリーダのメンバはSEリーダに。SEリーダのメンバはサブプロジェクトマネージャに。それぞれ一つ上のロールの一部を担うことで“プロジェクトの中での予定以上の経験で成長すること”の機会を生かそう、と。


きれいごとや作業の再分配ではなく、明日挑戦することを今日からやろうと。それも今実はできているんだけれど、それを改めて明示的にロールに加えたい、と。メンバのマインドセットをすること、これもプロジェクトマネージャの仕事なのです。