困っているときほど、当たり前を当たり前に

休日なのでということもないですが、自分で思っているほど周りの人はそれほど重要に思っていないという経験をした昔話を。

以前、プロジェクトマネージャをしていたプロジェクトがありました。進捗会議や個別の検討テーマを詰めていく会議は週に１回を基本として、必要都度連続日で開くなどコミュニケーションの場は出来上がっていました。

開発局面に入ると主にデリバリーチームのこちらからの開発の進捗報告と試験工程の準備が主なテーマになります。開発の進捗が計画どおり、若しくは、前倒しなら何も気を揉んだり胃を痛めたりすることはないのですが、このプロジェクトも御多分に洩れず遅延が出始めます。

開発拠点では、日々、進捗ミーティングを朝一に開いていたのでわたし自身が一番よくわかっていました。プロジェクトはプロジェクト最適化、つまり、できるメンバに仕事をアサインしたり高いレベルのスキルを持っているメンバに特定のタスクを集中させる過ちを犯しがちですが、このプロジェクトではそれをやっていました。

何が起きたかというと、個別最適化を図ったが故、その最適化を図ったメンバが遅延し始めるとプロジェクトが遅延してしまったのでした。

今思えば、当たり前なんですけどね。プロジェクトのコア技術なのであれば二重、できれば三重のリソースを当てておいてその技術を起因として起きるリスクは回避しなければならないんですよね。

進捗が遅延したら報告しなければなりません。進捗の遅れは日々実感を伴っていくし、進捗会議で嘘を言ってあとで間に合いませんなんて、プロジェクトマネージメントのプロフェッショナルとして信義の面からも言えません。

自分自身がここまでというデッドラインをプロジェクトマネージャは持っているものです。ほんと、ギリギリまで待つ人もいれば随分と早いところに閾値を持っているプロマネもいます。過去に回避した経験値からそういう閾値を育てるんですよね。

こういうときほど、基本に返って当たり前の行動を取った自分に呆れるというか関心をするというか。

使い古された手を引っ張り出したり、それの実現性を何度も裏を取ったりしてリカバリプランを立てます。開発局面と単体試験局面を一緒の工程にして見た目のdue dateを変更します。そして、遅延しているメンバの仕事を棚卸してリカバリプランの実現性を確認します。

さて、あとはどのタイミングで事実を報告するか、です。

悪い知らせほど早くと言うのは対処の時間を確保するためにです。えぇ、わかっています。ですからリカバリプランを持って次の進捗会議で正直に今ある状況を共有することにしました。

それを言うまで、どれだけドキドキしていたか。でも、そういうときこそ平静を装って、普段通りに、さらっと言われた方が聞いた方も冷静にことを信義できるものです。こういった相手の立場ならどう思うかも、リカバリプランを考えたときに大事な検証項目なんですよ。自分がメンバから同じようなことを言われたらどういうか、何を基準に判断するか。同じなんですよねぇ…。

それまでのプロジェクトの進捗がデリバリーチームとしては遅延がなかったことが信頼を獲得していたのでしょう。工程の変更と単体試験で終わるんだよね、という軽い確認でおわったのでした。

いやー、ホッとしました。リカバリプランを持って行ったのも（当たり前ですか）任せておいても良いと判断されたのでしょう。これが信頼もなく、見通しもないならお客さまがこちらに踏み込んできても何も言えないんですよねぇ。

これも一つの当たり前を当たり前にやることの大切さを身に沁みて体験した出来事でした。ドラマティックな出来事やプロジェクトXのようなことではない、普通に何回でも起きるような出来事の方がわたしにとっては価値のある学びなのです。