プロジェクトってなにをするの?


システムエンジニアのプロジェクトとは?
SEにおけるプロジェクトは、新規システムの開発やハードウェアの老朽化による移行などの目的に向けて発足されるものです。
例えば、「新たに自社の人材管理システムを導入する」という目的が決まった際にプロジェクトは発足され、目的達成に向けての活動が開始されます。
まずプロジェクトでは目的達成に向けて、「計画」を行います。
スケジュールや、プロジェクトに参画してもらうメンバー、コスト、スコープ(例:管理対象は自社だけか、グループ会社も含むか?)などなどを計画していきます。
その後、計画に沿って、システムの開発を進め、導入していくことをプロジェクトと呼びます。
詳細は、SEとして仕事を続けていくといずれPMをやることもあると思いますので、そのときにPMBOK(ピンボック)を確認しましょう。
PMBOKはプロジェクト管理に関する知見が整理された手引書のようなものです。
SEになって1~3年目レベルでは、いきなりPMBOKやプロジェクト管理の細かい内容を聞いても頭がこんがらがってしまうだけですのでね。
例えば、「新たに自社の人材管理システムを導入する」という目的が決まった際にプロジェクトは発足され、目的達成に向けての活動が開始されます。
まずプロジェクトでは目的達成に向けて、「計画」を行います。
スケジュールや、プロジェクトに参画してもらうメンバー、コスト、スコープ(例:管理対象は自社だけか、グループ会社も含むか?)などなどを計画していきます。
その後、計画に沿って、システムの開発を進め、導入していくことをプロジェクトと呼びます。
詳細は、SEとして仕事を続けていくといずれPMをやることもあると思いますので、そのときにPMBOK(ピンボック)を確認しましょう。
PMBOKはプロジェクト管理に関する知見が整理された手引書のようなものです。
SEになって1~3年目レベルでは、いきなりPMBOKやプロジェクト管理の細かい内容を聞いても頭がこんがらがってしまうだけですのでね。
プロジェクトのチーム構成
SEになるとプロジェクトにアサインされることになります。
プロジェクトは基本的に複数人で進めていくことになりますので、プロジェクトチームとして活動してくことになります。
プロジェクトチームでは、大まかに役割が決まっています。
プロジェクトの規模により、設置されない役割もあります。 中規模~大規模のプロジェクトと小規模なプロジェクトのチーム構成例を紹介します。
また、各役割の詳細を見ていきましょう。
プロジェクトにおける責任者という役割でもあり、チームのPLやTL、メンバーを管理し、うまくプロジェクトが進むようにマネージメントするのが仕事です。
「うまくプロジェクトが進むように」というふわっとした内容の通り、仕事内容も多岐にわたります。
各メンバーのタスク進捗を確認してスケジュールが遅延していないか、課題が起きていないか、トラブルが起きている場合は解消のための指示、顧客との折衝交渉、プロジェクト活動にかかるお金の管理、メンバーの士気管理などなど・・・。
プロジェクトがうまく進むようになんでもやるのがPMです。
もちろん、これを全て一人でこなすのは困難なので、うまくPLやTLにタスクを委譲して代わりにやってもらうというマネージメントもOKです。
続けざまに起こる問題に対して、試行錯誤しつつ柔軟に対応するという困難な役割です。
PMは業務が大量にあるため、プロジェクトの規模によっては全ての管理をやり切るのが現実的に困難な場合も多いです。
そんな時に、PMの管理業務を補佐する役割がPLとなります。
PMが対外的にもプロジェクトの責任者となりますので、顧客との折衝交渉などはPMが行い、その他のチーム内の管理部分をPLに任せる場合が多いです。
PLは、PMと比べると管理内容や範囲を小さく設定することで、より細かく管理を行う役割となる傾向にあります。
ただし、プロジェクトの規模が小さくPMだけで管理が行いきれる規模の場合は、PLは立てないケースもあります。
プロジェクトチームという大きな塊の中から、データベースチームやネットワークチーム、開発チームなど専門性に応じて更に小さなチームを作ることがあります。
そのチームはプロジェクトにおいて、自身の得意とする技術領域の範囲を担当するスペシャリストとなります。
そんなスペシャリスト集団を管理するのが、チームリーダーという役割になります。
よくPLとどう違うのかと比較されますが、PLはPMの補佐として複数あるチーム全体を管理します。
TLは各チーム内の管理を行うということで、PLとは管理範囲が異なる点に注意が必要です。
これまでのPM、PL、TLは、管理をメインとして行う役割でした。
この管理者からタスクを振り分けられ、実際に遂行するのがメンバーの役割となります。
ですので、設計や開発作業などの実際に手を動かす作業は主にメンバーで行います。
タスクの遂行において、課題が発生した際にはすぐに管理者へエスカレーションし、指示を仰ぎます。
プロジェクトは基本的に複数人で進めていくことになりますので、プロジェクトチームとして活動してくことになります。
プロジェクトチームでは、大まかに役割が決まっています。
- PM(プロジェクトマネージャー)
- PL(プロジェクトリーダー)
- TL(チームリーダー)
- メンバー
プロジェクトの規模により、設置されない役割もあります。 中規模~大規模のプロジェクトと小規模なプロジェクトのチーム構成例を紹介します。
■中規模~大規模

■小規模

■極小規模

PM(プロジェクトマネージャー)
PMはプロジェクトにおける取りまとめ役として、全体を管理する役割です。プロジェクトにおける責任者という役割でもあり、チームのPLやTL、メンバーを管理し、うまくプロジェクトが進むようにマネージメントするのが仕事です。
「うまくプロジェクトが進むように」というふわっとした内容の通り、仕事内容も多岐にわたります。
各メンバーのタスク進捗を確認してスケジュールが遅延していないか、課題が起きていないか、トラブルが起きている場合は解消のための指示、顧客との折衝交渉、プロジェクト活動にかかるお金の管理、メンバーの士気管理などなど・・・。
プロジェクトがうまく進むようになんでもやるのがPMです。
もちろん、これを全て一人でこなすのは困難なので、うまくPLやTLにタスクを委譲して代わりにやってもらうというマネージメントもOKです。
続けざまに起こる問題に対して、試行錯誤しつつ柔軟に対応するという困難な役割です。
PL(プロジェクトリーダー)
PLは、PMの補佐役として立てる役割となります。PMは業務が大量にあるため、プロジェクトの規模によっては全ての管理をやり切るのが現実的に困難な場合も多いです。
そんな時に、PMの管理業務を補佐する役割がPLとなります。
PMが対外的にもプロジェクトの責任者となりますので、顧客との折衝交渉などはPMが行い、その他のチーム内の管理部分をPLに任せる場合が多いです。
PLは、PMと比べると管理内容や範囲を小さく設定することで、より細かく管理を行う役割となる傾向にあります。
ただし、プロジェクトの規模が小さくPMだけで管理が行いきれる規模の場合は、PLは立てないケースもあります。
TL(チームリーダー)
TLは、プロジェクトチーム内で更に専門性に応じて細分化したチームの管理を行う役割です。プロジェクトチームという大きな塊の中から、データベースチームやネットワークチーム、開発チームなど専門性に応じて更に小さなチームを作ることがあります。
そのチームはプロジェクトにおいて、自身の得意とする技術領域の範囲を担当するスペシャリストとなります。
そんなスペシャリスト集団を管理するのが、チームリーダーという役割になります。
よくPLとどう違うのかと比較されますが、PLはPMの補佐として複数あるチーム全体を管理します。
TLは各チーム内の管理を行うということで、PLとは管理範囲が異なる点に注意が必要です。
メンバー
上役からの指示に従って、実際にプロジェクトのタスクを遂行するのがメンバーの役割です。これまでのPM、PL、TLは、管理をメインとして行う役割でした。
この管理者からタスクを振り分けられ、実際に遂行するのがメンバーの役割となります。
ですので、設計や開発作業などの実際に手を動かす作業は主にメンバーで行います。
タスクの遂行において、課題が発生した際にはすぐに管理者へエスカレーションし、指示を仰ぎます。
開発手法
システム開発では手法が何個かあります。
主に使われるものが2つありますので、紹介します。
その他の方法はほとんど使われることはないので、紹介する2つを知っておけばだいたいは大丈夫です。
その名前は、水が滝のように一方向に流れることに由来しています。
一般的なウォーターフォール開発の段階は以下のようになっています。
ウォーターフォール開発は前段階の工程が完了してから次の工程に進むことで、安定した品質でシステム開発が可能となります。
要件定義で顧客の要望を洗い出し、基本設計で概要を決め、詳細設計でより詳細な設計に落とし込みます。
製造に至るまでに、段階を追って詳細化していくことで、後の段階になってから顧客の要望と大きく異なるということを防いでいるのです。
ウォーターフォール開発におけるメリット/デメリットを紹介します。
ウォーターフォール開発は1歩ずつ着実に進めていくイメージになります。
前工程で決めたことを土台に次の工程を進めていく関係で、顧客から要望に変更が発生すると前の工程からやり直すことになるため、柔軟な変更には対応できないというデメリットがあります。
とはいえ、大規模な案件ではウォーターフォールで着実に進むような方法が好まれるため、金融業界や公共系の案件ではよく採用されます。
ウォーターフォール型の直線的な進め方と対照的に、アジャイルは変化に対応しながら進化する開発手法です。
反復的な開発サイクルという特徴を持ち、システム全体を一気に作るのではなく、短期間(2~4週間)で構築可能な範囲を作ってはリリースすることを繰り返します。
例えば、最初の4週間は「ログイン機能」を作りリリース、次の4週間では「マイページ機能」を作りリリース・・・・ということを繰り返し、徐々にシステムの機能をリッチにしていくという考えです。
アジャイル開発におけるメリット/デメリットを紹介します。
短期間で機能を開発しリリースまで行う必要があるため、忙しない開発手法になります。
リリースするということは動いているものを顧客が見ることができるということになります。
例えば、最初の「ログイン機能」を作った後、顧客が実際に使ってみて、使ってみた感想をフィードバックしてもらうことができます。
また、次の開発機能をこのタイミングで変えることも可能で、例えば「マイページ機能」よりも「メールアドレス変更機能」の方が欲しいという要望であれば、次の4週間で「メールアドレス変更機能」を作ることも可能で、顧客の意見を迅速に反映できる点で顧客満足度が上がりやすい開発手法です。
ただし、顧客は常にそのシステムに何が最も必要かを検討し、優先度を判断し続けてもらう必要があります。
「次に何の機能を入れればわからない」という状況になったり、「あれもこれも重要で優先度が付けられない」となってしまうと次の反復開発に混乱を生じてしまいます。
関係者全員が積極的に参加し、そのシステムをよくするためにを常に考え続ける必要があるという意味で、効果的ですが難しい開発手法とも言えます。
主に使われるものが2つありますので、紹介します。
その他の方法はほとんど使われることはないので、紹介する2つを知っておけばだいたいは大丈夫です。
①ウォーターフォール開発
ウォーターフォール開発とは、ソフトウェア開発の伝統的な手法で、プロジェクトを連続した段階(フェーズ)に分けて各段階が完了した後に次の段階に進む直線的なアプローチです。その名前は、水が滝のように一方向に流れることに由来しています。

一般的なウォーターフォール開発の段階は以下のようになっています。
要件定義:システムに必要な機能や制約を特定し文書化
基本設計:アーキテクチャ設計
詳細設計:各機能の詳細設計(パラメータ設計)
製造:設計に基づいた開発作業
テスト:機能の正常性確認、バグの発見と修正
リリース:システムの導入
基本設計:アーキテクチャ設計
詳細設計:各機能の詳細設計(パラメータ設計)
製造:設計に基づいた開発作業
テスト:機能の正常性確認、バグの発見と修正
リリース:システムの導入
要件定義で顧客の要望を洗い出し、基本設計で概要を決め、詳細設計でより詳細な設計に落とし込みます。
製造に至るまでに、段階を追って詳細化していくことで、後の段階になってから顧客の要望と大きく異なるということを防いでいるのです。
ウォーターフォール開発におけるメリット/デメリットを紹介します。
メリット
- 明確な計画と進捗管理が可能
- 各段階で詳細な文書が作成される
- 大規模プロジェクトでの管理がしやすい
- 要件が安定している場合に効果的
デメリット
- 柔軟性が低く、要件変更への対応が難しい
- 最終段階までユーザーからのフィードバックが得られない
- リスクが後半に集中する傾向がある
- 開発全体が長期化しやすい
前工程で決めたことを土台に次の工程を進めていく関係で、顧客から要望に変更が発生すると前の工程からやり直すことになるため、柔軟な変更には対応できないというデメリットがあります。
とはいえ、大規模な案件ではウォーターフォールで着実に進むような方法が好まれるため、金融業界や公共系の案件ではよく採用されます。
②アジャイル開発
アジャイル開発は、ソフトウェア開発の柔軟で反復的なアプローチで、2001年に「アジャイルソフトウェア開発宣言」によって体系化されました。ウォーターフォール型の直線的な進め方と対照的に、アジャイルは変化に対応しながら進化する開発手法です。

反復的な開発サイクルという特徴を持ち、システム全体を一気に作るのではなく、短期間(2~4週間)で構築可能な範囲を作ってはリリースすることを繰り返します。
例えば、最初の4週間は「ログイン機能」を作りリリース、次の4週間では「マイページ機能」を作りリリース・・・・ということを繰り返し、徐々にシステムの機能をリッチにしていくという考えです。
アジャイル開発におけるメリット/デメリットを紹介します。
メリット
- 変化する要件に柔軟に対応できる
- 早期かつ頻繁にフィードバックを得られる
- リスクの早期発見と対応が可能
- 顧客満足度の向上
デメリット
- 範囲や終了日の予測が難しい場合がある
- 大規模プロジェクトでの調整が複雑になりうる
- ドキュメント作成がウォーターフォールより少ない傾向がある
- 全ての関係者の積極的な参加が必要
短期間で機能を開発しリリースまで行う必要があるため、忙しない開発手法になります。
リリースするということは動いているものを顧客が見ることができるということになります。
例えば、最初の「ログイン機能」を作った後、顧客が実際に使ってみて、使ってみた感想をフィードバックしてもらうことができます。
また、次の開発機能をこのタイミングで変えることも可能で、例えば「マイページ機能」よりも「メールアドレス変更機能」の方が欲しいという要望であれば、次の4週間で「メールアドレス変更機能」を作ることも可能で、顧客の意見を迅速に反映できる点で顧客満足度が上がりやすい開発手法です。
ただし、顧客は常にそのシステムに何が最も必要かを検討し、優先度を判断し続けてもらう必要があります。
「次に何の機能を入れればわからない」という状況になったり、「あれもこれも重要で優先度が付けられない」となってしまうと次の反復開発に混乱を生じてしまいます。
関係者全員が積極的に参加し、そのシステムをよくするためにを常に考え続ける必要があるという意味で、効果的ですが難しい開発手法とも言えます。
プロジェクト管理でよく聞くワード
プロジェクトに参画するとよく聞くワードをまとめました。
初めて参加すると他の人が何を言っているのかわからないというところから始まってしまいます。
なんとなくでもよいので、先に言葉の意味を見ておくと付いていきやすくなります。
初めて参加すると他の人が何を言っているのかわからないというところから始まってしまいます。
なんとなくでもよいので、先に言葉の意味を見ておくと付いていきやすくなります。
PMO (Project Management Office):
プロジェクト管理を支援・監督する専門組織や部門。
複数のプロジェクトの標準化、品質管理、リスク管理などを行い、プロジェクト全体の成功率を高める役割を担います。
大規模な組織では常設のPMOを設置していることが多いです。
複数のプロジェクトの標準化、品質管理、リスク管理などを行い、プロジェクト全体の成功率を高める役割を担います。
大規模な組織では常設のPMOを設置していることが多いです。
例: 「この案件はPMOの指示で週次報告の形式が変更になりました」「リスク管理はPMOが一元的に行います」
WBS (Work Breakdown Structure):
プロジェクト全体の作業を階層的に細分化して構造化した図表。
作業を管理可能な単位に分解することで、スケジュール作成や進捗管理、担当割り当てを効率的に行えます。
階層の最下位レベルはワークパッケージと呼ばれ、実際に工数見積もりや担当者割り当ての対象となります。
作業を管理可能な単位に分解することで、スケジュール作成や進捗管理、担当割り当てを効率的に行えます。
階層の最下位レベルはワークパッケージと呼ばれ、実際に工数見積もりや担当者割り当ての対象となります。
例: 「WBSを更新して、テスト工程の細分化をもう少し詳細にしてください」「WBSのLevel 3まで作成したので確認をお願いします」
ガントチャート:
横軸に時間、縦軸にタスクを配置した棒グラフ形式のプロジェクトスケジュール表。
各タスクの開始日、終了日、進捗状況を視覚的に把握できます。
タスク間の依存関係(前後関係)も矢印で表現することが可能です。
Microsoft ProjectやJiraなどのツールで作成・管理されることが多いです。
各タスクの開始日、終了日、進捗状況を視覚的に把握できます。
タスク間の依存関係(前後関係)も矢印で表現することが可能です。
Microsoft ProjectやJiraなどのツールで作成・管理されることが多いです。
例: 「ガントチャートを見ると、来週がタスクの集中期間になっていますね」「ガントチャートを更新して、遅延の影響範囲を確認しましょう」
マイルストーン:
プロジェクト内の重要な節目や中間目標を示す指標。
進捗確認や計画の見直しのタイミングとなります。
典型的なマイルストーンには、要件確定、設計完了、コーディング完了、テスト完了などがあります。
期間や工数を持たず、達成すべき状態を表します。
進捗確認や計画の見直しのタイミングとなります。
典型的なマイルストーンには、要件確定、設計完了、コーディング完了、テスト完了などがあります。
期間や工数を持たず、達成すべき状態を表します。
例: 「次のマイルストーンは基本設計書の承認です」「マイルストーンの遅延が発生したため、全体スケジュールの見直しが必要です」
ステークホルダー:
プロジェクトに関わる、または影響を受ける全ての関係者。
クライアント、エンドユーザー、プロジェクトチームメンバー、経営層、パートナー企業など多岐にわたります。
ステークホルダーの期待や要求は時に相反することもあり、それらのバランスを取りながらプロジェクトを進める必要があります。
クライアント、エンドユーザー、プロジェクトチームメンバー、経営層、パートナー企業など多岐にわたります。
ステークホルダーの期待や要求は時に相反することもあり、それらのバランスを取りながらプロジェクトを進める必要があります。
例: 「主要ステークホルダーを集めた会議を開催します」「このステークホルダーは予算決定権を持っているので、しっかり説明する必要があります」
キックオフ:
プロジェクト開始時に行われる初回の公式会議。
プロジェクトの目的・目標、スコープ、スケジュール、体制、役割分担などを関係者全員で確認し、プロジェクトへの理解と参加意識を高めます。
プロジェクトの目的・目標、スコープ、スケジュール、体制、役割分担などを関係者全員で確認し、プロジェクトへの理解と参加意識を高めます。
例: 「来週月曜日にキックオフミーティングを開催します」「キックオフでは特に役割分担について明確にしておきましょう」
PoC (Proof of Concept):
新しい技術や方式が実際に機能するかを確認するための小規模な実証実験。
本格的な開発の前に技術的な実現可能性やリスクを評価するために行います。
PoCの結果を踏まえて本開発の計画を立てたり、採用技術を決定したりします。
実験的な性質を持つため、本番環境での実装とは異なる場合があります。
本格的な開発の前に技術的な実現可能性やリスクを評価するために行います。
PoCの結果を踏まえて本開発の計画を立てたり、採用技術を決定したりします。
実験的な性質を持つため、本番環境での実装とは異なる場合があります。
例: 「新しいフレームワークのPoCを2週間かけて実施します」「PoCの結果、パフォーマンス面での課題が見つかりました」
スコープ:
プロジェクトで実施する作業の範囲や境界。「何を含み、何を含まないか」を明確にします。
スコープ変更(追加機能要求など)はプロジェクトの予算・期間・品質に大きな影響を与えるため、スコープ管理は重要なプロジェクト管理業務の一つです。
スコープクリープ(範囲の無秩序な拡大)に注意が必要です。
スコープ変更(追加機能要求など)はプロジェクトの予算・期間・品質に大きな影響を与えるため、スコープ管理は重要なプロジェクト管理業務の一つです。
スコープクリープ(範囲の無秩序な拡大)に注意が必要です。
例: 「この機能はスコープ外なので、別プロジェクトで対応します」「スコープの変更があるため、変更管理プロセスに従って承認を取ります」
QCD:
品質(Quality)、コスト(Cost)、納期(Delivery)の3要素。
プロジェクト管理における重要な評価指標であり、これらのバランスを取ることがプロジェクト成功の鍵となります。
三角形の関係にあり、一つを改善すると他が悪化する傾向があります(例:品質を上げるとコストが増加する)。
状況によってどの要素を優先するかの判断が求められます。
プロジェクト管理における重要な評価指標であり、これらのバランスを取ることがプロジェクト成功の鍵となります。
三角形の関係にあり、一つを改善すると他が悪化する傾向があります(例:品質を上げるとコストが増加する)。
状況によってどの要素を優先するかの判断が求められます。
例: 「このプロジェクトはQCDの中で特に品質を重視します」「QCDのバランスを考慮して、機能の優先順位付けを行いましょう」
まとめ
プロジェクトについて説明を行いました。
これからSEを目指す人も、SEになったばかりの人もいずれプロジェクトに参画することになります。
プロジェクトというものがどういうものか理解しておくと、これからの仕事の内容をイメージすることにも役立ちます。
また、参画してすぐの時は覚えることも多いので、先にイメージや言葉だけでも覚えておくとスタートダッシュが切りやすいです。
是非なんども見て、覚えてみてくださいね。
最後まで読んでいただきありがとうございました。
これからSEを目指す人も、SEになったばかりの人もいずれプロジェクトに参画することになります。
プロジェクトというものがどういうものか理解しておくと、これからの仕事の内容をイメージすることにも役立ちます。
また、参画してすぐの時は覚えることも多いので、先にイメージや言葉だけでも覚えておくとスタートダッシュが切りやすいです。
是非なんども見て、覚えてみてくださいね。
最後まで読んでいただきありがとうございました。