「自分でやるよ」――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。
よくある場面
「これって、どうやるの?」
私がまだエンジニアだった頃、専門スキルを持たない上司に作業を教える機会がありました。
プロジェクトの実質的な進行は私が握っており、上司に一部の作業をお願いして、私がその結果を解析するというフローを組んでいました。
「あぁ、それはこうやってですね……」
「なるほど、ありがとう」
しかし、しばらくしてまた声がかかります。
「たびたびごめん、これって次はどうやるんだっけ?」
「…………(あーもう、説明するより)自分でやります」
相手のスキル不足や理解の遅さに直面した時、つい自分が手を動かして巻き取ってしまう。 これは「自分でやった方が早い病」と呼ばれる、ビジネスの現場で最も頻発する悪手です。
しかし、これが悪手だと頭では分かっていても、私たちは土壇場になると必ずこのトラップを踏み抜いてしまいます。
なぜ起きるのか ― バグの構造
なぜ、優秀な人ほど「自分でやった方が早い」の誘惑に勝てないのでしょうか?
それは単なる忍耐力の問題ではありません。
PM(設計者)としての「納期設定のバグ」と「権限移譲の解像度の低さ」が引き起こしている構造的なエラーです。
日常の風景に例えてみましょう。 出かける直前、玄関で子どもが「靴紐」を結ぶのに手間取っている場面を想像してください。
時計を見ると、出発時間はもう目の前。あなたは焦り、こう言います。 「もう時間がないから、お母さん(お父さん)がやる!」
これが「自分でやった方が早い病」の正体です。
本当の納期(出発時間やクライアントへの提出期限)と、タスクの締め切りを【同じ時間】に設定しているから、システムに余裕がなくなり、最も処理速度の速い「自分での実行」という強制終了コマンドを選ばざるを得なくなるのです。
これを繰り返すとどうなるか。
子どもはいつまでも靴紐を結べるようにならず、あなたは5年後も毎朝、玄関で子どもの靴紐を結ばされるハメになります。
先ほどの私と上司の関係も全く同じで、私が巻き取った瞬間に、上司の学習プロセスは停止し、私は「上司の分の処理も永遠に負担し続ける」という技術的負債を抱え込みました。
他人に処理を委ね、組織全体のスペックを拡張する(スケールアウトする)ためには、「気長に見守る」といった精神論は通用しません。 アーキテクトとして、物理的に「自分で巻き取れないシステム」を設計する必要があります。
(※「納期を前倒しする」という字面だけなら、AIでも出力できます。しかし、なぜその前倒しが必要で、どこまで権限を渡せばシステムが安全に稼働するのか。その「アーキテクトの視点」を以下の設計からインストールしてください)
解決策(How)はnoteで公開中
ここから先の具体的な解決策・コマンドは、noteの記事「アーキテクトの過去問」として公開しています。
このテーマを深めるおすすめの本
『HIGH OUTPUT MANAGEMENT』(アンドリュー・S・グローブ)
マネージャーの仕事を「チームの成果」で捉え直す、任せ方と育て方の古典。
※本記事は、noteで公開した「「自分でやるよ」は組織を殺す。部下の靴紐を“片足だけ”結ばせるマネジメントのシステム設計」の無料部分をブログ向けに再構成したものです。


コメント