PM・役割拡張
人に任せると申し訳ない。結局、自分で全部やってしまう
頼むと相手の負担になりそうで、説明するくらいなら自分でやった方が早い。そんな抱え込みを責めずに、小さく任せるところまで戻す方法を整理する。
案件、単価、契約、伝え方、仕事の広げ方、学び方の観点から記事を探せます。
タイトル・本文で探す
気になる言葉で絞り込めます。スペース区切りで複数条件も使えます。
カテゴリで絞り込む
タグで絞り込む
件数順に表示しています。
9件 / 全54件
PM・役割拡張
人に任せると申し訳ない。結局、自分で全部やってしまう
頼むと相手の負担になりそうで、説明するくらいなら自分でやった方が早い。そんな抱え込みを責めずに、小さく任せるところまで戻す方法を整理する。
AI駆動開発
AI時代ほど、レビュー観点を持つ人が強くなる理由
AIがそれらしいコードを速く出すほど、レビューは「読めるか」ではなく「入れてよいか」を見る仕事になります。意図、影響範囲、テスト、運用の観点から役割価値を整理します。
AI駆動開発
AIにコードを書かせるほど、仕様の曖昧さが表に出る理由
AIで実装が速くなるほど、未決事項や曖昧な仕様はそのままコードに出やすくなります。実装前に何を切り分けると役割価値になるのかを整理します。
単価設計
AIで速く書けるようになったのに、単価が上がらない理由
AIで実装が速くなっても、検証・説明・合意形成を見える形にしないと、価値ではなく時短だけで見られます。
PM・役割拡張
ファシリテーションはPMだけの仕事じゃない。現場で効く小さな進行整理
会議を仕切る人になる前に、論点、決める人、次の一手を小さく整えるだけで、エンジニアの役割は広がります。
PM・役割拡張
実装だけだと単価が頭打ち。PM視点が効いてくる理由
実装はちゃんとできるのに単価が伸びにくい時は、技術力の次に「現場を前に進める力」が見られています。PM視点がどこで価値になるのかを整理します。
単価設計
キャリア全体で見ると、単価設計はどう考えるべきか
その場の単価だけを追うと、あとでしんどさが出ることがあります。キャリア全体で見た単価設計の考え方を整理します。
PM・役割拡張
実装だけの人が、PM要素を少しずつ増やすには
いきなりPMになる必要はありません。実装の延長で、論点、決定者、完了条件を少しだけ前に出すところから役割は広げられます。
PM・役割拡張
仕事の幅を広げたい。でも何でも拾う人になる前に
役割を広げたい時ほど、目の前の困りごとを全部拾うと消耗しやすいです。仕事量ではなく、現場の止まりを1つ減らす広げ方を整理します。