仕事の幅を広げたい。でも何でも拾う人になる前に
「これ誰か拾える？」で、つい手が上がりそうになる
「ここで手を挙げた方が、役割を広げている感じがするのかな…」
朝会が終わりかけた時、ホワイトボードの端に残った未整理のタスクを見ながら、誰かが言う。
これ、誰か拾えますか？
こういう一言で、手が止まることはない？ 実装はちゃんとやっている。もう少し仕事の幅も広げたい。単価や評価につなげるには、実装以外のことも持てた方がいい気がしている。
だからこそ、その場で「自分やります」と言いそうになる。言った方が前向きに見えるし、頼られる人にも見える。何より、沈黙が少し気まずい。誰も拾わない空気の中で、自分だけ何も言わないのは、なんとなく冷たい人に見える気がする😅
でも、その気まずさで拾った仕事は、あとから重くなる。
最初は小さな調整のつもりだったのに、会議メモ、仕様確認、関係者への連絡、次回の議題づくりまで流れてくる。水曜の夕方には、自分の実装タスクが後ろに押されている。なのに、周りから見ると「いろいろ助けてくれている人」で止まりやすい。
ここが、役割拡張のいちばん苦しいところだと思う。広げたい気持ちはある。でも、広げ方を間違えると、評価ではなく疲労が増える。
Stack Overflow の 2025 Developer Survey では、AIツールやAIエージェントで開発作業の生産性が上がったと答える開発者がいる一方、AIエージェントによってチームの協働が改善したと答えた人は少数にとどまっている。個人の作業速度が上がっても、チームの止まりが勝手になくなるわけではない、ということだ。
だから役割を広げるなら、仕事をたくさん拾うより先に見たいことがある。自分が持つことで、どの止まりが減るのか。 ここが見えないまま手を挙げると、便利な人にはなれる。でも、価値としては伝わりにくい。
手を挙げる前の気まずさを、まず疑っていい
「自分が拾わないと冷たく見えるかも」と感じる場面は、かなり多い。特に、役割を広げたいと思っている時ほど、その気持ちは強くなる。ここで黙ると、成長機会を逃しているように見えるからだ。
でも、手を挙げることと、役割を広げることは同じではない。手を挙げるのは入口でしかない。大事なのは、何をどこまで持ち、何を持たないのかを言えることだ。
たとえば、未整理のタスクを見た時に、全部を持つのではなくこう返す。
いったん仕様の未決だけ拾います。連絡先の調整は担当者を分けたいです。
これでも十分、前に進めている。むしろ、境界をつけているぶん、長く続きやすい。
忙しくなるほど、価値は見えにくくなる
役割を広げようとして疲れる人ほど、「拾った仕事の量」は増えている。ところが、「何を前に進めたか」は言いにくい。ここがつらい。
資料を作った。会議を入れた。確認を回した。チャットも拾った。たしかに全部やっている。けれど、その並びだけだと、相手からは「いろいろやってくれた」以上に見えにくい。
役割拡張で見せたいのは、仕事量ではなく変化だ。認識ズレが減った。判断待ちが短くなった。手戻りが減った。次回の会議で決めることが見えた。忙しさではなく、止まっていたものがどう動いたかを言葉にする。 ここまで言えると、広げた役割が価値に変わりやすい。
幅を広げる前に、現場の「止まり方」を見る
仕事の幅を広げたい時、いきなり「PMっぽいことをやる」「上流を持つ」と考えると大きすぎる。言葉が大きいと、何から始めればいいのか分からなくなる。
もう少し小さく見ていい。現場は、いつも大きな理由だけで止まるわけではない。むしろ、次のような小さな詰まりで止まる。
- 誰が決めるか分からない
- 何をもって完了とするか曖昧
- 仕様の前提が人によって違う
- 連絡先はあるのに、確認順が決まっていない
- やることは見えているのに、優先順位が決まっていない
Google re:Work のチーム効果性の整理では、効果的なチームに関わる要素として、心理的安全性、信頼性、構造と明確さ、意味、影響が挙げられている。ここでいう構造と明確さは、役割や期待、進め方が見えている状態に近い。
現場のエンジニアが役割を広げる時も、ここから始めると無理が少ない。いきなり全部を仕切るのではなく、今の仕事の近くにある曖昧さを1つだけ見える形にする。 それだけでも、チームはかなり動きやすくなる。
認識ズレを減らす
1つ目は、認識ズレを減らすことだ。これは実装者がかなり見つけやすい。
たとえば、チケットには「CSV出力」と書いてある。でも、営業側は「顧客ごとに集計したい」と思っている。運用側は「担当者ごとに出せないと困る」と言っている。エンジニアから見ると、同じCSVでもかなり違う。
ここで黙って実装すると、あとで戻る。だから、「今回のCSVは、顧客別なのか、担当者別なのか、まずここだけ合わせたいです」と出す。これだけで、未決事項が会話の場に出る。
これは大きなPM業務ではない。実装前に、ズレそうな言葉を1つ翻訳しているだけだ。でも、その1つが手戻りを減らす。
判断待ちを減らす
2つ目は、判断待ちを減らすことだ。
現場でよくあるのは、「確認しています」のまま止まる状態だ。誰に確認しているのか。いつ返るのか。返ってこない場合はどうするのか。ここが見えないまま、実装者だけが待つことになる。
役割を広げるなら、ここで全部を急かす必要はない。まずは判断の形にする。
この2案で実装の前提が変わります。今日中にA/Bだけ決められれば、明日は実装に入れます。
これなら、相手は何を決めればいいか分かる。自分も、ただ待っている状態から抜けられる。判断を奪うのではなく、判断しやすい形にして渡す。ここに価値がある。
手戻りを減らす
3つ目は、手戻りを減らすことだ。
PMI の Pulse of the Profession 2025 は、プロジェクト専門職にとって事業理解が重要で、スコープ・予算・スケジュールを超えて価値を出すことが求められると整理している。これをエンジニアの現場に置き換えるなら、単に作るだけでなく、「何が戻りそうか」を先に見られることが価値になる。
たとえば、画面を作る前に「レビューで見たいのは文言なのか、操作導線なのか、権限なのか」を分ける。全部を完璧にするのではなく、戻る可能性が高い場所を先に見せる。
ここで大事なのは、未来を全部当てることではない。戻りそうな場所を、戻っても傷が浅いタイミングで出すこと。 これができると、実装の外側に少し役割が広がっている。
「私がやります」ではなく、持つ範囲を言葉にする
役割を広げたい時に、いちばん言いにくいのは「ここまでは持つけど、ここから先は別で決めたいです」だと思う。手を挙げたあとに境界を出すと、やる気がないように見えそうで怖い。
でも、境界がないまま拾う方が危ない。全部を自分で抱えると、最初は感謝されても、あとで自分の本来タスクが詰まる。疲れてくると返信が遅れる。すると、せっかく前向きに拾った仕事まで雑に見えてしまう。
IPA の「DX動向2025-AI時代のデジタル人材育成」では、日本企業でDXを推進する人材不足が大きいことが示されている。人材が足りない現場では、できる人に仕事が集まりやすい。だからこそ、全部を善意で拾うのではなく、役割として続けられる形にする必要がある。
役割拡張は、自己犠牲の量で測らなくていい。むしろ、続けられる範囲に切る方が誠実だ。
まず、拾う仕事を1つに絞る
朝会で「これ誰か拾える？」と言われたら、全部を持つ前に、1つだけ選ぶ。
- 未決事項を3つに分ける
- 次回会議の判断材料だけ作る
- 仕様のズレそうな言葉だけ確認する
- 関係者ごとの確認先だけ整理する
- 完了条件だけチケットに追記する
このくらいでいい。小さく見えるかもしれない。でも、現場が止まりやすい場所に効いているなら、それは役割拡張の入口だ。
逆に、「調整全般やります」「必要なことは全部拾います」と言うと、持ち場が消える。相手も何を期待していいか分からない。自分も、どこまでやれば終わりなのか分からない。
だから、まずはこう言う。
今回は、未決事項の整理だけ拾います。決定と各担当への依頼は、いったん○○さんから出してもらえると助かります。
少し勇気はいる。でも、これなら手を挙げつつ、抱え込みを防げる。
ここで相手が欲しいのは、たぶん「全部やってくれる人」だけではない。止まっているものを、次に進められる形へ変えてくれる人だ。だから、言い方も強く断る必要はない。
ここを整理すると、次の判断がしやすくなると思うので拾います。 ただ、最終決定は担当者から出してもらえると、後の認識ズレが減りそうです。
このくらいの温度でいい。相手を突き放すのではなく、判断の持ち主を元の場所に戻す。自分の役割は、そこへ進みやすい道を作ることだ。これなら、手伝いながらも境界を残せる。
価値に変えるなら、減ったものを残す
役割を広げたあとに、何も記録しないと評価につながりにくい。だから、やったことではなく、減ったものを残す。
週報や振り返りに、こんな3行を入れるだけでいい。
- CSV出力の対象を顧客別に揃え、実装前の認識ズレを減らした
- A/B案の違いを整理し、当日中に判断できる状態にした
- 初回レビューで確認する範囲を絞り、作り込み後の手戻りを避けた
ここまで書けると、「いろいろやりました」ではなくなる。仕事量ではなく、現場の変化が見える。
単価や役割の話に持っていく時も、この形が効く。詳しくは、実装だけだと単価が頭打ち。PM視点が効いてくる理由 や 週報を作業報告で終わらせない。価値が伝わる書き方 にもつながる。
明日やるなら、朝会後の3行からでいい
役割拡張という言葉は大きい。でも、明日やることはかなり小さくできる。
朝会やチャットで、宙に浮いた仕事を見つけたら、すぐ「自分やります」と言う前に、メモを3行だけ作る。
止まっていること: 仕様の対象が顧客別か担当者別か揃っていない
自分が拾うこと: 2案の違いと実装影響をチケットに書く
自分が拾わないこと: 最終決定と関係者への依頼これだけで、手の上げ方が変わる。自分がやることも、相手に決めてもらうことも見える。何より、「全部やらないと成長できない」という気持ちが少しほどける。
役割を広げる時に必要なのは、誰よりも多く抱えることではない。現場の止まりを1つ減らし、その範囲を言葉にすること。 そこからなら、実装の延長で始められる。
もし、すでに仕事を拾いすぎてしんどくなっているなら、人に任せると申し訳ない。結局、自分で全部やってしまう も近い話だ。役割を広げることと、全部を背負うことは別のものとして見直していい。
仕事の幅は、いきなり大きく広げなくていい。明日は、宙に浮いたタスクを全部拾うのではなく、止まりを1つだけ減らす。その1つが、便利屋ではなく、前に進める人として見られる入口になる✨
