金融プロジェクトの現場で起きていた静かな麻痺
ああ、私は人の痛みよりスケジュールを優先していた。
金融系の大型プロジェクト。
Javaのフレームワークを適用し、標準化し、品質を担保する。
遅延は許されない。レビューは連日続く。
現場は常に緊張していた。
「来週5人来るから机を用意してほしい」
「パソコンもお願いします」
「いなくなった人のPCはどうしますか？」
ほぼ毎日、この類の話をしていた。
1週間しかいない人もいた。
「新しい責任者です」と紹介された人が、翌週には来なくなったこともある。
重鎮エンジニアは次のプロジェクトへ引き抜かれた。
人の移動は“イベント”ではなく“前提”だった。
Javaフレームワーク適用の裏で失われた対話
その中で、私は後輩にきつく当たった。
品質を守るため。
納期を守るため。
その言葉に、私は疑いを持たなかった。
彼は次第に休みがちになり、やがて別プロジェクトへ移った。
だが私は、それを大きな出来事だとは思わなかった。
多くの担当者の移動と同じように処理した。
感覚が麻痺していたのか。
それとも冷徹だったのか。
プロジェクトは回っている。
成果は出ている。
それで十分だと、どこかで思っていた。
後輩の異動を“通常運転”と処理した私の構造
しかし後に、その後輩が鬱になったと聞いた。自分からも連絡が取れなくなった。
私は一人で食事に行くようになった。
それでも、仕事のことを考えていた。
スケジュール通りに終わらせること。
そこに集中していた。
それが“普通”だと思っていた。
ここで問いが生まれる。
私たちは、成果を守るために何を犠牲にしているのか？
人の入れ替わりを構造として処理することで、何を見落としているのか？
成果と関係、どちらを守る経営か ～ 構造の再定義～
表面の問題
人の入れ替わりが激しい。コミュニケーションが難しい。
本質的ボトルネック
人を「役割の単位」でしか見ていないこと。
関係を“交換可能な資源”として扱う組織慣性。
再定義
プロジェクトとはタスク遂行の場ではない。
“関係を設計する場”である。
移り変わる人の中で、変えてはならないもの
抽象化すれば、これは経営判断の問題だ。短期成果を最適化すると、関係コストは後回しになる。
だが関係は、後払いできない資産だ。
あのとき、私はスケジュールを守った。
だが関係を守らなかった。
もう少し言葉を選んでいたら。
もう少し対話を設計していたら。
1回でも食事に誘っていたら。
何かは変わったのだろうか。
過去は戻らない。
だが、目の前の関係は今この瞬間にも壊れ得る。
経営とは何か。
成果を出すことか。
それとも、成果を出し続けられる関係をつくることか。
人は移り変わる。
しかし、関係への態度は選び直せる。
次に誰かがプロジェクトを去るとき、
それを単なる人事異動と捉えるのか。
それとも、関係設計の結果と見るのか。
私は後者を選びたい。
目の前の関係を、成果と同じ解像度で設計する。
移り変わる人の中で、変えてはならないものを守る。
私ならできる！明日から踏み出す
コメント
コメントを投稿