shutterstock 403713811

プロジェクトマネジメントのポイント

GCode-image2022/04/01

プロジェクトマネージャーの役割

開発プロジェクトを進めるのために、プロジェクトマネージャー(PM)が管理を行います。

開発は複数名で行われるので、タスクを担当者にアサインし、それをスケジュール内で完了させるようにプロジェクトマネジメントする必要があります。

開発だけでなく、内部や外部の関係者との調整を行うこともあります。

無事にリリースまで取り仕切る役割を担うのがPMなのです。

PMにはリーダーシップが求められると同時に、状況によって正しい決断ができる判断力が必要になります。

リリースまでにPMがすること

要件、仕様をもとに、見積もりを行いスケジュールを立てることから始まります。

1. 大まかなスケジュールを出す

大まかな見積もりでの工数を開発者の人数で割り、おおよそのスケジュールを立てます。他の開発案件とスケジュールが重ならないように調整を行います。

2. タスクを細分化する

開発タスクを細分化し、かかる工数をそれぞれ出します。

作業を環境構築、フロント、バックの開発と大まかに担当者にアサインをします。

3. 詳細スケジュールに落とす

タスクの全ての作業を同時に進行することはできないので担当者は割り当てられたタスクを順にこなすようにガントチャートに登録をします(バックログなど管理ツールを使います)。

4. 進捗をモニタリングする

開発に入り、立てたスケジュール通りに進んでいるかリリースターゲットに向けて進捗管理をします。

プロジェクトマネジメントのポイント

事前に決めること

1. スコープ

スコープとは開発範囲のことです。限られた時間、予算でプロジェクトを進める場合には、スコープを最初で決めておく必要があります。

発注の前までに見積に入っていないものは追加工数となってしまうので、契約前で見落としがないか発注者・受注者の両方で注意をしましょう。


2. 質問表

クライアントの要件を元に開発を行います。

どのような仕様にするかはクライアントに必ず確認をします。

開発期間前、開発期間中にクライアントと緊急のコミュニケーションが出てくる場面が多くなります。

質問には2日以内に回答をもらう等のルールを決めておきましょう。

コミュケーションや管理ツール

開発で使われるコミュニケーションツールについて紹介をします。

Redmine/Backlog

・プロジェクト管理を行うサービスです。

Googleスプレッドシート

プロジェクトマネジメントのポイント | 株式会社GCode

・画面設計はほぼエクセルファイルで作られます。ファイルがリアルタイム更新できるようにGoogleドライブで共有フォルダを作りクライアントと共有をします。

 お客様とのコミュニケーションの重要性

ゴールはどこか、お客様が重視するポイントの理解も大事なことです。

お客様のリクエストで何であるかをPMは正しく把握しなければなりません。

開発の途中で想定と異なるということがなってしまい、実装のやり直しにならないように関係者とコミュニケーションをとりましょう。

こちらの記事も読まれています

SIer×オフショアの“最小変更管理”—CRルール1枚でスコープと検収を守る|GCode

GCode-image2026/01/05

揉める前に決める。SIer×オフショアの「最小変更管理」—CRルール1枚でスコープと検収を守る|GCode

SIerがオフショアで揉めやすい論点(スコープ/検収/変更/責任境界)を整理し、1枚のCR(変更管理)ルールで最小化する方法を解説。公開サンプルとしてCRルールの見出しを提示し、詳細チェックリスト(DL/同梱ZIP)と面談での当てはめ支援も提供します。

詳細へ GCode-image
SIerが2週間の“試験導入”を通すための最小セキュリティ合意|GCode

GCode-image2026/01/05

監査にしない。SIerが2週間の“試験導入”を通すための最小セキュリティ合意|GCode

SIerがオフショアを試験導入する際に、監査レベルの負荷をかけずに必要最小限のセキュリティ合意をまとめました。必須/推奨チェック(NDA・権限・データ・ログ保持)と、1枚で使える最小合意書テンプレをDLで提供します。

詳細へ GCode-image
SIerがオフショア追加で品質を落とさない方法|GCode

GCode-image2026/01/05

SIerがオフショア追加で会議を増やさず、手戻りを止める|GCode

SIerがオフショアを追加するときに品質と手戻りを抑える「最小QAゲート10」を公開。証跡(テスト・レビュー)と引き継ぎ(リリースノート)に絞り、バグトリアージの重大度・担当・SLA・意思決定線までテンプレ化。

詳細へ GCode-image
#3 会議を増やさず小さく安全に:オフショアを2週間で検証する進め方(SIer向け)|GCode

GCode-image2025/12/26

会議を増やさず、小さく安全に:オフショアを10日で検証する進め方(中小SIer向け)|GCode

会議を増やさず、最小スコープで安全にオフショアを試す「2週間トライアル」の手順。窓口一本化・最小QAゲート・1枚週次レポート。

詳細へ GCode-image
単価で選ばない:オフショアベンダーを15分で見抜く質問10(中小SIer向け)|GCode

GCode-image2025/12/26

単価で選ばない:オフショアベンダーを15分で見抜く質問10(中小SIer向け)|GCode

単価で選ぶ前に、15分でオフショアベンダー“運用適合”を見抜く。中小SIer向けに質問10+レッドフラグ+詳細スコアを1枚に整理。窓口/DoD/変更管理で曖昧ベンダを早期除外できます。

詳細へ GCode-image
オフショア不安5つを“最小対策”に:中小SIer向けチェックリスト|GCode

GCode-image2025/12/26

オフショア不安5つを“最小対策”に:会議を増やさない、中小SIerのための運用設計|GCode

週次会議が終わった直後、チャットに「これも追加で」「確認だけお願いします」が流れてくる。
決める人が曖昧なまま、気づけば“SIer側で吸収”が積み上がる——そんな瞬間、ありませんか。
オフショアの不安は、気合やマイクロ管理で消えるものではありません。
必要なのは、**会議を増やさずに効きやすい“最小の運用セット”**です。
この記事は、よくある不安(管理・品質・セキュリティ・連携・進捗)を、**最小セット(3つの型)** に落として整理します。
増やすべきは会議ではなく、**情報と意思決定の“形”** です。

詳細へ GCode-image
GCode-image-start

開発の 検討に 役立つ

ブログ