スケジュール管理、してるつもりでした

Thu, 21 May 2026 00:00:00 +0900

はじめに

「スケジュール管理って何が正解？」と悩んでいませんか。

私はPMになってからのこの1年間、Jiraやスプレッドシートなど、色々なツールを試してきました。その都度「これが最適解だ」と思っていました。

でも実際は、ツールの更新に追われ、良かれと思った仕組みが逆に現場の負担を増やしていました。

振り返ると、当時は「管理している気になっていただけ」だったのかもしれません。

今日は、私がこの1年で直面したリアルな失敗と、そこからの気づきをお話しします。

1. ガントチャートから始めた、私の現場

PMに就任した当初、プロジェクトではJiraのガントチャートを使っていました。

最初は「これで全体の進捗が見える」と手応えを感じていました。

しかし、現場では日々、予期せぬズレが発生します。タスクが2日遅れると後ろも連鎖的にずれるため、毎朝の引き直し作業に追われる結果に。

ここで得た最初の気づきは、「ガントチャートは計画には強いが、日々変化する現場を追うには重すぎる」ということでした。

2. 迷走、そして現在の運用へ

Jiraのガントチャートをやめ、リストビューに切り替えました。しかし今度は「いつ終わるか」が見えなくなり、全体の節目を管理する「スプシカレンダー」を自作しました。

さらに、細かい進捗やメモが追えなかったため、独自の「スプシのタスク一覧」を作成。 PR後の細かい状態を追うために「SlackのPR一覧」も導入しました。

これらを私が確認して回ることで、PMとしての状況把握は劇的に楽になりました。

——ただし、これが「現場にとっても最適だったか」というと、話は別でした。

3. 試行錯誤から導き出した「3つの引き算」

私が状況を把握するためにツールを重ねた結果、現場のリーダー層には複数の管理工数を強いることになってしまいました。

この迷走を経て痛感したのは、管理の仕組みは足し算ではなく引き算で考えるべきだということです。

現場を回すための視点は、次の3つに絞れます。

① 残り 完了していない残タスクがどれだけあるか
② 担当 今、誰のところでボールが止まっているか
③ 期限 絶対に動かせない最終期限はいつか

本当に必要な情報は、実はこれだけでした。

PMに任命された日から使える3つの考え方

Thu, 25 Dec 2025 00:00:00 +0900

PMに任命された日から使える3つの考え方

はじめに

「来週からPMね」と言われたとき、何から考えればいいのか戸惑った経験はありませんか。

今日はタスクの進め方ではなく、
PMとしての考え方について、新米PMとしての実体験をもとにお話しします。

1. 最初は「雇われPM」だった、私の立ち位置

私は今年4月、10年以上のブランクを経て業界に復帰しました。
4月はシステム理解とテスト、5月はチームリーダー、そして6月からPMを任されました。

最初は専門用語も分からず、お客様とのやり取りもそのまま人に渡すだけの日々でした。

役に立ちたい気持ちだけが先行し、PMとして何をすべきか分からない状態でした。

2. 思い出した過去のPM

そんな時、新卒時代に見ていたPMの姿を思い出しました。

私は新卒の頃、
とある会員サイトのフロント保守改修チームに携わっていました。

そのチームでPMは、お客様から提示される改修リストをもとに、
どの改修を・どのリリースで・どの順番で対応するかを判断し、
現行仕様を確認しながら要件を固めていく役割を担っていました。

開発は、要件定義を起点に設計・実装・テスト・レビューまで
一連の流れを丁寧に回す体制で、リリースは多いときで月2回行われていました。

改修内容や工数に応じて、
まとめて出すもの、次回に回すもの、単独リリースで慎重に出すものを切り分けるなど、
リスクとスケジュールを見据えた調整が常に行われていました。

そのPMは、開発メンバー5人を抱え、日々の進捗を追いながら、
お客様の要望と現場の声の間に立ち続けていました。

今振り返るとその姿は、単なる調整役ではなく、
チームを止めずに前に進めるための意思決定者だったのだと思います。

3. 今の自分に置き換えて考えた

「あのPMは、何を大切にしていたのか」
それを今のチームに置き換えて考えた結果、3つの考え方にたどり着きました。

① 索敵

先々に何が起きそうかを意識し、今の判断が将来の手戻りにつながらないかを見ること。

すべてを覚える必要はありません。調べ方や資料の場所が分かっていれば十分です。

プロジェクトの進行だけでなく、チームの疲労感やお客様の温度感も含めて
「今、何が起きそうか」を見るようにしています。

② 翻訳

お客様の「こんな感じにしたい」という要望と、現場の「技術的に厳しい」という現実。

その間に立ち、お互いの意図が正しく伝わるようにすること。

認識のズレを減らし、手戻りなくプロジェクトを前に進め、
「ちゃんと理解してもらえた」と双方が感じられる状態を目指しています。

③ 防衛

エンジニアが最も価値を生み出す、集中できる時間を守ること。

未整理な情報や突発的な割り込みを、できるだけ直接チームに当てないように調整します。

PMが盾になることで、チームは安心して手を動かすことができ、
その力を最大限発揮できると考えています。

4. まとめ

PMに任命された日から意識したいことは、

先を見る「索敵」
橋をかける「翻訳」
集中を守る「防衛」

完璧でなくても、まずはこの3つを持つこと。

おわりに

10年以上のブランクを経て、またこの業界で皆さんと仕事ができることを嬉しく思います。
私は初めは雇われPMでしたが、半年間チームの一員として新米PMなりに意志を持って、
皆さんと並走してきました。
これからも技術的な議論を尊重し、客先調整という役割でチームを支えていきたいです。
もし、明日来週からPMと言われた場合はぜひ参考にしていただければと幸いです。

プロジェクトマネジメント on Feature Branch Tech Blog

スケジュール管理、してるつもりでした

はじめに

1. ガントチャートから始めた、私の現場

2. 迷走、そして現在の運用へ

3. 試行錯誤から導き出した「3つの引き算」

PMに任命された日から使える3つの考え方

PMに任命された日から使える3つの考え方

はじめに

1. 最初は「雇われPM」だった、私の立ち位置

2. 思い出した過去のPM

3. 今の自分に置き換えて考えた

① 索敵

② 翻訳

③ 防衛

4. まとめ

おわりに