自分係数を失ったエンジニアはどこに心理的安全を求めれば良いのか

以前のエントリでは別の切り口で書いたプロジェクトのことを最近、気になっていることからの連想で思い出すようになったのです。気になっていることはどこにプロジェクトのslack、つまり余裕しろを持たせるのが最適なのだろうということです。

今の世の中の流れ、流通にしろコストにしろ何にでも余裕を削りに削って無駄を排除することをよしとしてなんでも余裕しろを無くしてしまいます。確かに無駄であるならそういう対応もいいのでしょうが、一方で心理的安全などの働く側の目に見えないけれど、なくてはならないクラッシャブルゾーンは一体どう確保しすれば良いのでしょうか。

アジャイル開発のスクラムやカンバンを知って、プロジェクトのシステム開発手法の一部に採用することでプロジェクトチームの可視化されない課題を認識させることをしたり、見積もりをチーム全員で行うことで見積もりの曖昧性や見積もり時に考慮が漏れないように全員の視点でウォークスルーすることでアウトプットの品質を確保しやすくなるという面において効果のあるツールだと実践するチームからも好意的に受け止められています。

ところで、従来の作業見積もりでは、作業を担当する各人に見積もりをさせたり、リーダが一方的に見積もりをしたり、最悪なのはスケジュールに合わせて作業日数を指定されたりとそれが見積もりなのか疑わしいやり方もあったのではないかと思うのです。世の中の現場ではまだそうした見積もり紛いの見積もりが横行しているような感じではあります。

紛いものは捨てて、チームで見積もりをする際には、中間層のエンジニアの技術レベルより少し下げたところのエンジニアが担当することを前提として見積もることをルールと決めて見積もってもらいます。これはハイレベルなエンジニアは自分がやることを無意識に想定して自分の技術レベルで見積もりしてしまうからです。若手も同じように自分がやることを前提に見積もりますがこちらのケースはハイレベルのエンジニアとは真逆に工数に自分係数を掛けまくります。

なので中間層より少し下にしておくことでブレ幅をコントロールするわけですがこのようなルールをおくことでなぜ工数が少なくて良いのか、それとも多くが必要であるかの暗黙の前提や制約条件を洗い出すことに繋がる効果があります。

こうしたやり方はプランニングポーカーを使っているのですが、これをやりすぎると時間で見積もっていることや前提を整理して行くので仕様がはっきりすることに対して見積もり精度が上がるため個人が見積もっていたときに好きに積んでいた自分係数が掛けられなくなります。一方、見積もりはチームで行ってコンセンサスの上で決めているので見積もった時間内でできなければ自分の実力がないことになってしまうと感じる遠位ニアにはそこそこのプレッシャーになりかねないということです。

ではどこで余裕しろを持ったらいいのか。

正解はないのでしょうし、それぞれのチームで合意しておくのが模範解答なのでしょう。チームで合意するのも調整、調和型のプロジェクトマネジメントやマネージャのスタイルとしては決して新しいものではなく、古典の部類のタイプです。

そこで冒頭のプロジェクトでやったことを思い出すのです。優秀なエンジニアに仕事を集中させてプロジェクト最適化をやりすぎたら進捗にまずいくらい影響が出てしまう直前まで行ってしまったので、タスクを取り上げ、中間層のエンジニアたちと見積もりし直しと振り直しを決め、タスクの納期は正味の工数に絞りつつもプロジェクトのバッファを用意しておくやり方で切り抜けた後に知ったのはTOCのやり方だったのですけれど。

こうしたタスクの工数の見積もりの精緻化は個人の自分係数をとらせないというやらせ方なのでこれが続くと息が詰まりどこかで線が切れてしまうのではないかという心配もあるのです。一息入れるくらいのブレークならいいですが心理的プレッシャーは人により閾値が違うので一概に言えないし、気づきにくいものです。

自分係数をとらせないのはスピードを上げてリリースするためでもあるけれど、そうしたことが続くと余裕を無くし、チームで設定するスピードに合わせなければならないために優先順位が入れ替わり切羽詰まると品質悪化に繋がるケースも出てきます。

そうしたことの対策をバランス感覚でという無責任な一言で片付けたくはないと思うのですが。

結局、笑ってやるしかないということなのでしょうか。