自走から共走へ ── PM経験で気づいた、本当の“自走力”とは

はじめに

「開発経験を積むための開発経験が無い！を解決する方法」を読んでから、「自走力」という言葉についてずっと考えている。
今回の記事では、自分の経験（サークル → 就活 → PM）を通して見えてきた「自走力」の正体を整理し、最後に“今の自分に不足しているもの”について言語化してみる。

なぜ「自走力」について考えるのか

リンク先の記事では、

自走する能力と人を頼る能力のバランス

が重要と述べられている。
この表現を読んだとき、これまでモヤモヤしていた「自走力」という言葉が、自分の中でようやく立体的な輪郭を持って理解できた。

これまで私は、以下のような立場を経験してきた

• サークル運営者
• 就活生
• PM

これらの立場で見えていた「自走力」は、それぞれ全く違う姿をしているように見えていたからだ。

視点によって形を変える「自走力」

それぞれの立場で自分が捉えていた「自走力」について振り返ってみたい。

1. サークル運営者の視点：独力突破力

サークルを立ち上げた当初、私にとっての自走とは「何がなんでも動くものを作ること」だった。
自分含めて初心者ばかりで、自分が止まればチーム全体が止まる。
だからこそ、エラーが出ても、仕様が複雑でも、誰にも頼らず泥臭く兎に角解決し切る力。
「独力で壁を突破する力」こそが自走力だと信じていた。

2. 就活生の視点：手のかからない人材

就職活動において、私は「自走力」を一つの武器としてアピールした。そこで企業に伝えたかったニュアンスは、「私は教育コストがかかりません」という宣言だったように思う。

「いちいち聞かなくても自分で調べて進められます」
「手がかからない人材です」

サークル内の環境もあり、「どうにかすること」の経験から、それが出来ると思い込んでいたし、それこそが求められるものであると思い込んでいた。
いわば「独立稼働できる能力」として自走力を定義していたように思う。

3. PMの視点

そして今年、PMとしてチームの開発進捗やサービスの方針を管理する立場になった。
ここで初めて、過去自分が為していた「自走力」の定義に違和感を抱くことになる。
PMの視点から見たとき、本当に欲しい人材は「独力で突破する人」でも「全く手がかからない人」でもなかったからだ。

PMになって知った「沈黙」の恐怖

PMとしてプロジェクトの進捗を管理する中で、最も恐ろしいのはメンバーの「沈黙」だった。

PMが最も恐れるのは「進捗が見えない時間」である。

• 詰まっているのか
• うまくいっているのか
• 何に困っているのか

これらが PM から見えなくなると、タスクはブラックボックス化し、プロジェクトの不確実性が跳ね上がる。

お願いしたタスクを抱え込み、次のスプリントミーティングまで音沙汰がない。ミーティングの時間に「実は実装方法に行き詰まっていて、できていません」とはじめて報告が来る。これがPMにとって最大のリスクだ。
過去の私が「自走力」だと思っていた「誰にも頼らず自分で解決しようとする姿勢」は、チーム開発の視点で見ると「進捗のブラックボックス化」というリスクになり得ると気づいたのだ。

逆に、PMとして信頼できるメンバーは、「頼るタイミング」が絶妙だ。
まずは自分で動き出しつつも、一定時間詰まったら、「ここまで分かったが、ここから先の方針で迷っている」とすぐに共有してくれる。　「今少しミーティングできますか？」と連絡が来る。
順調だとしても、進捗が定期的にテキストで閲覧可能な状態に共有される。

この経験を経て、冒頭の記事にある 「自走する能力と人を頼る能力のバランス」 という言葉が、強烈な納得感を持って腹落ちした。 真の「自走力」とは、一人で走ることではない。
「チームの成果を最大化するために、他者の力を借りながらでも、止まらずに前に進み続ける力」 のことだったのだ。

自分に足らざるもの：PMの視点を持ち、プレイヤーとして振る舞えるか

「自走力」の正体は掴めた。しかし、「理解している」ことと「実行できる」ことは別だ。 来春から私は、PMではなく一人のエンジニア（プレイヤー）として働くことになる。その時、今の気づきを実践できるだろうか。
自分に足らざるものを考えたとき、最大の敵は 「技術的なプライド」と「申し訳なさ」 だと思う。

PMとしては「早く聞いてほしい」と思っているのに、いざ自分が実装者になると「こんな初歩的なことを聞いたら技術力を疑われるのではないか」「忙しい先輩の手を止めるのは申し訳ない」という感情が湧き上がってくる。
その結果、記事で戒められている「開発経験が無い人の悪いパターン」である、抱え込みに陥る未来が容易に想像できてしまう。

私に今足りないのは、技術力そのもの以上に、「頼る技術」 だ。

自分の「わからなさ」を言語化する技術

「何ができていて、何ができていないか」を区別することを必ず行う。
そもそも、何がネックなのかを把握する手法を多く持つ。
その上で解決案を自分なりに考えた上で提示するところまでできれば最高だと思う。

これは、こにふぁーさんの「"提案"のレベルを上げる」に大きく影響を受けている。

弱さを見せるマインドセット

「全部自分でできる」という鎧を脱ぎ、「チームのために、今の自分には助けが必要だ」と早期にアラートを上げられる勇気。
まだまだ経験も技術もないことをしっかり認めた上で、謙虚になる必要がある。

最後に

PM経験を通じて、私は「自走」のゴールが「個人のスキルアップ」ではなく「プロダクトの成功」にあることを学んだ。
この視点を忘れずに、「適切に悩み、適切に人を頼り、最短距離でゴールに向かう」。

そして今では、こう思うようになった。

むしろ「共走」こそが、チーム全員の“自走”なのではないか。

今回の記事では自分自身の反省にフォーカスしたが、
メンバー全員が風通しよく現状を共有できるような仕組みづくりも、今後の大きな課題だ。

来年の書き初めは、きっここう書こう。