こんにちは、MARCUS（マーカス）です。
プロマネ初心者で何から手を付けようか悩んでいる人
『プロマネを任されたけど、何をすればよいかわからない。』
『とりあえず立上げ～計画で、何をすればよいか知りたい。』
そんな悩みを解決します。
この記事の内容
①プロジェクトマネジメントの全体の流れ、プロセス群について
②立ち上げプロセス群と知識エリアについて
③計画プロセス群と知識エリアについて
今までチームメンバーとしてプロジェクトに参加していても、いざ、プロマネを自分でやるとなると何からはじめて良いかわからないものです。
そこで今回は、プロジェクト初期の立ち上げ～実行前の計画プロセスについて紹介します。
記事を読み終えれば、プロジェクトの立ち上げ～計画までの流れがわかるようになりますよ。
PMPでキャリア10年以上のわたしが、説明します
▼PMBOKガイドは、プロジェクトマネージメントの手引書です！
プロマネなら誰でも一冊は持っていると思います。むしろ、これがなくては始まりません。
値段は少し高いですが、プロマネをしていればほぼ一生モノになります。
持ってない人は、一冊は購入しておきましょう。損はしませんよ。
結論から言いますと、プロジェクトの立ち上げ～計画プロセスの流れは、
1．プロジェクトの目的・目標・条件・作業範囲を決めて、組織の承認を得る。
2．スケジュールを作成する。
3．コスト（予算）を見積する。
4．リスクを事前に予想し、対応策を考える。
それでは、具体的に記事で説明します。
目次
プロジェクトマネジメントのプロセス5群
まずは、プロジェクト・プロセスの全体流れを知りましょう。
全体がわからないと、詳細を説明しても迷子になってしまいますからね。
プロジェクトは、開始～終わりまで【合計5つのプロセス群】があります。
ポイント
①立上げプロセス群／プロジェクトの開始を、組織に宣言するプロセス
②計画プロセス群／目的を達成のために、作業可能な計画を立案・維持するプロセス
③実行プロセス群／計画を実行するために、人や資源を使いこなすプロセス
④監視コントロール群／目標達成のために、プロジェクトを監視管理するプロセス
⑤終結プロセス群／プロジェクトを公式に受入れ、終了に向かわせるプロセス
各プロセス群には10の知識エリアがあり、それぞれプロジェクトの内容や進捗に合わせてアウトプットとなる成果物を作成していくことになります。
PMBOKの知識エリアは、必ずしもすべてを行う必要がないです。
なぜなら、プロマネ就任時にすでにプロジェクト憲章があるような場合もあります。
プロジェクトの状況に応じて、PMBOKを「うまく利用する」くらいの感じでOKです。
どんな成果物がプロジェクトに必要になるかを見極めることから始めましょう。
進め方としては立上げプロセス群では、統合マネジメントの知識エリアで「プロジェクト憲章を作成」して、ステークホルダーマネージメントで「ステークホルダーの特定」をするといった感じです。
今回は、プロジェクト実行が始まる前の【立上げ～計画プロセス群】についてです。
【立上げプロセス～計画プロセス】を、家族旅行で例えるとこんな感じ。
お父さんが「家族旅行に行く！」と言い出したけど、まだ予定は何も決まってない状況。そこで、あなたが旅行の予定を立てることになった。『家族旅行に行こう』と決めてから、『自宅で旅行の予定をたてる』までの流れが、プロジェクトでいう立上げ～計画プロセスということになります。
それでは、立上げプロセス群から見ていきましょう。
『良い計画』でプロジェクトは6～7割は成功です！
何事も計画が大切ですね
▼PMBOKは、文章だらけで「とっつきにくい！」というあなた！
プロジェクトマネージメントの基礎について、マンガでわかりやすく学習できます。
PMBOKを読む前に、マンガで基礎をわかっていけば文章理解もスムーズになりますよ。
プロジェクトの開始を承認してもらおう【立ち上げプロセス群】
立上げプロセス群のアウトプット（知識エリア）
1．プロジェクト憲章作成（統合マネージメント）
2．ステークホルダー特定（ステークホルダーマネージメント）
結論から言うと、「プロジェクトの開始を正式に承認してもらう」のが立ち上げプロセスです。
プロジェクトの目的、おおよその予算や日程、プロマネの権限範囲などを決定することが主な目的です。
それでは、具体的に説明します。
プロジェクト憲章（Project charter）を作ろう
プロジェクト憲章は、プロジェクト全体の方向性を決める重要な書類です。
なぜなら、誰にも承認されていないプロジェクトを開始したとしても意味がありません。
作業を始める前に、オーナーや上司にプロジェクトの開始を承認してもらう必要があります。
そのため、プロジェクト憲章の書き方としては、
1．プロジェクトの目的、内容（どうしてプロジェクトをするのか？）
2．成功基準、要求事項（成功判断の基準は？期待される成果は？）
3．前提条件、制約条件（すでにわかっている制約、期待する前提）
4．おおまかな予算とスケジュール
5．プロジェクトマネージャーの責任権限（どこまで権限があるのか？）
をセットで書く必要があります。
上記の注意点としては、プロジェクトマネージャーの責任権限を明確にすることです。
例えば、予算をどこまで使えるのか、人を追加する権限があるのかなどを決めておきます。
そうすることで、判断を早く行うことができ、作業をスムースに進めることができます。
あまりに権限のないプロマネだと、作業の中断が頻繁になりますので注意しましょう。
✓必要な情報は、事前に打合せで入手する
プロジェクト憲章作成に必要な情報は、オーナーや上司から早い段階で入手しましょう。
そうしないと、目的や方向性が「的はずれ」な資料になりかねません。
そのため、オーナーや上司から以下の情報を入手します。（インプット）
①プロジェクト作業範囲記述書（作業範囲の詳細を記載）
②ビジネスケース（プロジェクトが発足された要因情報）
から、プロジェクトの背景や目的を理解します。
まずは作業を始める前に、プロジェクト憲章で方向性や目的を明確にしましょう。
「プロジェクト憲章の作成」を、家族旅行で例えると！
家族旅行の予定を立てる前に、どの地方に行きたいのか？そこで何をしたいか？使っていい金額は？何日いくか？いつ行けるか？私はどこまで決めていいのか？（宿の予約は自分の判断でしていいのか、お父さんの確認がいるのか）などを決めるということです。
全体の方向性が決まらないと、詳細の検討はできないですよね
あとで無駄な作業がないように、はじめが肝心です！
ステークホルダー（関係者）を特定しよう
ステークホルダーの反応や期待をコントロールすることも、重要になってきます。
なぜなら、プロジェクトの成功は「ステークホルダーの満足度」によって決まるからです。
ステークホルダーとは、プロジェクトに関わる利害関係者のことです。
（客先の関係者、社内のチーム、外注予定先、競合会社など）
以下のような情報をリスト化し、ステークホルダーを特定します。
①会社名・役職・名前
②連絡先（電話やメール）
③関与度【どのくらいプロジェクトに関心があるか】
④影響度【どのくらい発言がプロジェクトに影響するか】
⑤プロジェクトへの立場【支持・不支持】
上記の注意点としては、プロジェクトへの「関与度」と「影響度」を特定することです。
報告書提出先や定期打合せ参加者などの、コミュニケーション方法を決める情報になります。
例えば、「関与度・影響力大」には、常に報告をして「確実に対応」するようにします。
「関与度小、影響力大」には、たまに情報を共有し「満足度を保持」するという具合です。
ステークホルダーをリスト化して、関係者の反応を意識しながら作業を進めましょう。
すべてのステークホルダーが、始めからわからなくても大丈夫。
プロセスが進むうちに、新しくわかってから追加すればOKです。
プロジェクトの成功確率を上げるには、役に立つリストですよ。
「ステークホルダーの特定」を家族旅行で例えると！
お父さん：なにも言わない（関与度小）けど、旅行をいくかを決定する（権限大）
お母さん：相談にのってくれる（関与度大）けど、独断では決められない（権限小）
おばあちゃん：自分は行かない（関心度小）けど、お父さんを説得できる（権力大）
この場合の、ステークホルダーエンゲージメントは、、、
①お父さんの期待に答えた、旅行の予定を計画する。
②おばあちゃんには、お土産作戦で旅行への関心を持ってもらう。
③おばあちゃんに、必ず旅行に行くようにお父さんを説得してもらう。
という作戦ですね。
詳細を計画していこう【計画プロセス群】
計画プロセス群の知識エリア
1．統合マネージメント（各プロセスの成果物を取りまとめる）
2．スコープ・マネージメント（作業範囲や必要な成果物を決める）
3．スケジュール・マネージメント（スケジュールを決める）
4．コスト・マネージメント（予算を見積もりする）
5．品質マネージメント（プロジェクトやプロダクトの品質評価について計画する）
6．資源マネージメント（必要な資源について計画する）
7．コミュニケーション・マネージメント（ステークホルダーとの意思疎通を計画する）
8．リスク・マネージメント（想定リスクを洗い出し、優先順位をつけて対策する）
9．調達マネージメント（外部からの調達品の計画をする）
10．ステークホルダー・マネージメント（ステークホルダーの期待値管理を計画する）
立上げプロセスでプロジェクトの開始が、正式に承認されました。
これからいよいよ本格的に、作業に入っていくことになります。
計画プロセス群のなかでも、スコープ・スケジュール・コストを優先的に計画します。
なぜなら、プロジェクト状況の評価基準となる「ベースライン」になるからです。
ポイント
プロジェクト・ベースライン
①スコープ・ベースライン
②スケジュール・ベースライン
③コスト・ベースライン
例えば、作業範囲や必要な成果物（スコープ）の目標が決まれば、おのずと品質目標や資源、調達といった他の知識エリアも計画することになり、スコープ・ベースラインが他の計画の基準になることがわかります。
ただし、ここで注意が必要なのは、ベースライン作成と同時に「リスク・マネージメント」についても行う必要があるということです。
プロジェクト・ベースラインが崩れると、他の知識エリアも影響を受けるためです。
そこで、今回は【ベースライン作成＋リスクマネージメント】を中心にご説明します。
ではまず、スコープ・マネージメントからお話します。
作業の範囲を決めよう【スコープ・マネージメント】
スコープ・マネージメントは、作業範囲やその内容、条件について文書化します。
一言でいうと、「何をする」と「何をしない」を文書で明確にするということです。
スコープ・マネージメントの成果物（アウトプット）は、
1．要求事項収集：ステークホルダーのニーズを文書化する
（内容、要求、目標、制約条件、前提条件などを収集する）
2．スコープ定義：必要な成果物とそのために必要になる作業を決める
（プロジェクトスコープ記述書で詳細内容を規定する）
3．WBS作成：ワーク・ブレイクダウン・ストラクチャーを作成する
（作業内容を細分化する。他の知識エリアで使用する）
ステークホルダーから出るニーズを、”コントロール”することが重要になります。
なぜなら、「これもほしい」「あれもやりたい」とプロジェクトの目的達成のためには、優先度の低いニーズが多く出てくるためです。
そこで、プロジェクトの目的達成に必要なことを基準として、それぞれのニーズに優先順位をつけてまとめるようにします。
例えば、こんな感じです。
| MUST （必須：優先度高） | プロジェクトの目的達成には、必ず必要なタスク すぐに優先して実行しなければいけない |
| Hi-Want （優先度中） | 目的達成にはあまり必要ないが、機能面や使い勝手がよくなるタスク 極力、プロジェクト内で行うよう努力する。 |
| Want （優先度低い） | 目的達成には必要ないタスク 顧客満足度を上げるために、予算や日程に余裕があれば行う |
一方的に要求を断ると、ステークホルダーの機嫌がわるくなりかねません。
優先順位をつけて、話をすることでこれを解消できます。
断る前にスケジュールやコストを意識しながら、ニーズをコントロールしてください。
✓ プロジェクトスコープ記述書とWBS
スコープ・マネージメントで以下の2つの文書は確実に作りたいです。
理由としては、
- プロジェクトスコープ記述書が、実行するすべての作業の基準となる。
- WBSがこのあとの「スケジュール作成」と「コスト見積もり」のベースとなる
- 2つの文書をあわせて、スコープ・ベースラインになる
からです。
特にWBSですと、作業内容が細分化されていれば、
- 各作業に必要な日数を算出すれば「スケジュール」になる
- 各作業単位でかかるコストを見積もりすれば「予算」がわかる
というふうに、次の知識エリアで必要になる成果物になります。
3つの各ベースラインは、お互いに影響しあいます。
まずは、スコープ・ベースラインをしっかりと文書化しましょう。
スコープ・マネージメントを家族旅行に例えると！
1．家族にどこに行きたいか聞く（要求事項収集）
2．家族会議で行き先のOKをもらう（スコープ定義）
3．旅行に向けて、必要なことを書き出します（WBS作成）
ここまでで、スケジュールを作成する準備が出来ました。
続いて、スケジュール・マネージメントに進んでいきましょう。
スケジュールを決めよう【スケジュール・マネージメント】
スケジュール・マネージメントの成果物（アウトプット）
1．アクティビティ定義
2．アクティビティ順序設定
3．アクティビティ資源見積
4．アクティビティ所要時間見積
5．スケジュール作成
スケジュール・マネージメントでは読んで字の如く、スケジュールを作成します。
スケジュール作成まで、アクテビティ定義→順序設定→資源見積→所要時間見積と5つのステップがありますが、それぞれは連続して行われる作業でわかりやすいと思います。
「アクティビティ」というのは、プロジェクトで実行する作業の最小単位を言います。
計画や管理精度を上げるために、作業単位をなるべく小さくするということです。
その①：アクティビティ定義
アクティビティ定義では、「スケジュール表の縦軸」にあたる項目を定義します。
このとき、アクティビティはWBSで定義した「ワークパッケージ」でOKです。
WBSで分解した作業の単位をワークパッケージと言います。
PMBOKでは、ワークパッケージをさらに分解したものをアクティビティとしています。
しかし、実際には「ワークパッケージ＝アクティビティ」とすることが多いです。
なぜかというと、作業単位を小さく分解しすぎると管理しきれなくなるからです。
ワークパッケージの最小単位は、8／80ルールが一般的です。
8時間以上（1日以上）、80時間（2週間以下）になる作業単位です。
例えば、作業時間が”1時間”で、1日の作業数が”200”では、とても管理できません。
出来るだけ作業を細分化した方が、管理精度は上がるかもしれません。
しかし、負荷が大きすぎて管理出来なくては本末転倒でしょう。
そこで、ワークパッケージをそのまま、アクティビティを定義しましょう。
（WBSができていれば、特に作業はいらないということです）
その②：アクティビティ順序設定
ここでも読んでそのまま、「アクティビティを作業する順序」を決めることです。
例えば、「【作業A】が終了後【作業B】を開始」といった具合に作業順を決めます。
順序のパターンとしては、
- 終了ー開始（FS） Aを終了すると、Bを開始できる
- 開始ー開始（SS） Aを開始すると、Bも開始できる
- 開始ー終了（SF） Aを開始すると、Bを終了できる
- 終了ー終了（FF） Aを終了すると、Bも終了できる
スケジュールの線を引く時に、必要な情報です。
順序を決める前に、作業手順の制約をしっかり意識しましょう。
その③：アクティビティ資源見積
アクティビティを作業するのに、必要な資源を見積もりします。
人、機器、資材等の量と時期を明確にします。
外部から調達する資源がある場合は、「量と時期」をしっかり見積もりましょう。
なぜなら、外部調達資源は、スケジュールのボトルネックになることがあります。
例えば、購入機器の発注が漏れ納期が遅れたため、全体の進捗が止まるなどです。
ですので、外部調達の資源は、余裕を持ったスケジュールで手配しましょう。
その④：アクティビティ所要時間見積
それぞれのアクティビティ完了に必要な時間（日数）を見積もります。
ただし、アクティビティ毎に「予備時間」を設定してはいけません。
最短で終わるギリギリの時間を、設定するようにしてください。
「学生症候群」や「パーキンソンの法則」という人間心理によって、プロジェクトが遅れるためです。
学生症候群：時間（期限）ギリギリまで始めない人間心理
パーキンソンの法則：仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
例えば、最短7日＋予備3日の作業時間を設定すると、終了日は必ず10日目になります。
予備日は常にすべて使い果たされ、最終的にプロジェクトの完成は遅れます。
個々のアクティビティの所要時間は「最短」で見積もり、予備時間はプロジェクト全体で一番最後に一括して確保しましょう。
その⑤：スケジュール作成
あとは、その①～その④の情報をあわせて、スケジュールを作成するだけです。
縦軸にアクティビティ、横軸に時間です。一般的にはガントチャートが使われます。
このスケジュールが、「スケジュール・ベースライン」になります。
コスト見積もりをするのに、ベースとなる情報です。
それでは次に、コストの見積もりに進みましょう。
スケジュール・マネージメントを、家族旅行で例えると！
1．家族旅行で行く場所やイベントを書き出します
2．次に、行く場所やイベントの順番を決めます
3．旅行中に必要なもの（資源）、日付を決めます
4．旅行先での滞在時間や移動時間を見積します
5．それらをまとめてスケジュールを作ります
過ぎた時間は、取り戻すことが出来ません。
スケジュールの管理が、もっとも気を使いますね。
▼スケジュールの関して、関連記事でも書いています。こちらもどうぞ。
プロジェクトの遅れる理由を知っていますか？３つの理由を現役プロマネが解説します
コスト見積しよう【コスト・マネージメント】
コスト・マネージメントの成果物（アウトプット）
1．コスト見積
2．予算設定
コスト・マネージメントでは、プロジェクトを成功させるために必要な予算を設定します。
アクティビティ毎に「コスト見積」をして、それを合計すると「予算設定」です。
その①：コスト見積
スケジュール表を使用して、アクティビティ毎にコストを見積もりします。
コスト見積で、1番大切なのは「コストの発生時期を時系列」で計算しておくことです。
なぜなら、プロジェクト初期で予算を使いすぎると終盤で予算がなくなることがあります。
それを防止するために、プロマネは時系列で予算状況を管理していくことになるからです。
例えば、縦軸にコスト額、横軸にスケジュールの折れ線グラフを用意します。
このS字カーブで、計画と実績のコストの差を比較することで予算管理が容易にできます。
ですので、コスト見積では必ず「時系列でコスト」を把握しておくことが大切です。
その②：予算設定
予算設定では、見積もりしたコストを積算して「プロジェクト予算」を設定します。
予算と、コスト見積もりのSカーブをあわせて「コスト・ベースライン」です。
コスト・マネージメントを家族旅行で例えると！
1．旅行中に必要になる費用と日にちを各項目で見積します
2．かかる費用を積算して、旅行の予算を確認します
※旅行中かかる費用を日当たりでわかるようにしておきましょう
翌日の予算を節約するなどで全体の予算を管理することが出来ます
以上で、プロジェクト管理の基準となる3つのベースラインができました。
ここから各ベースラインに、予備（コンティンジェンシー）を用意する作業になります。
理由としては、プロジェクトには”必ず”トラブルや突発的な変更があるからです。
そういったときに、予備時間や予備費がないと都度オーナーの承認を得て追加予算やスケジュール変更の手続きが必要になり、プロジェクト完成までのボトルネックになっていきます。
そこで、スコープ・スケジュール・コストに影響を及ぼす「リスク」について事前に対処策を計画することが重要になってきます。
決められた時間・予算のなかで、目的を達成する。
『プロマネの腕の見せどころ』です！
トラブルを予想しよう【リスク・マネージメント】
リスク・マネージメントの成果物（アウトプット）
1．リスク特定
2．定性的リスク分析
3．定量的リスク分析
4．リスク対応計画
結論ですが、できるだけリスクを洗い出し、優先順位をつけて対策案を考える。
それが、リスク・マネージメントです。
プロジェクトでは、「トラブルや突発的な変更」はつきものです。
事前にトラブルを予想、対策しておけば影響を最小限にすることができます。
その①：リスク特定
可能性のあるリスクを、ブレーンストーミングで洗い出します。
有識者を始め、なるべく多くの人数で洗い出しを行いましょう。
リスクを「リスク登録簿」としてまとめます。
リスク登録簿の内容としては、以下のような内容になります。
- リスク分類、項目
- リスクの内容、発生する条件（リスクが発生してしまう条件）
- リスクの発生可能性（可能性小→中→大）
- リスクのプロジェクトへの影響度（影響小→中→大）
- リスクの優先度（優先低い→中→高い）
- 対応方針、対応内容（いつ、どのような対応をするか）
- 担当者名、期限、状況（対応完了した場合には完了とする）
その②③：定性的リスク分析、定量的リスク分析
どちらもリストアップしたリスク項目の『優先度』を評価するための分析作業です。
発生可能性や影響度（被害）が数値で表せる場合は「定量的分析」、定性的な基準を元に『小中大』等で表すときには「定性的分析」になります。
発生可能性、影響度についてそれぞれ定量的分析か定性的分析で【重み付け】をします。
発生の可能性が高く、発生した場合の影響度が大きいものが「優先度が高いリスク」です。
その④：リスク対応計画
リスク対応計画では、優先度の高いリスクからどのような対応をしていくか決めます。
優先度の高いリスクから発生する前に、要因を排除したり低減できるような対応が必要です。
優先度が低いリスクについては、問題がおきたら事後対処とするのも対応策の一つです。
例えば、優先度の低いリスクは発生可能性が低く、発生しても影響が小さいリスクです。
これらすべてのリスクに事前対処していると、資源を消費し、時間もコストもかかります。
そこで発生してから事後対処するということで、資源を節約することができます。
優先度が高いリスクでも、保険や外注契約で外部に責任を転嫁することもできます。
リスクの対応計画によって、コストや日数が必要な予備として計画され、それらをスケジュールやコスト・マネージメントにフィードバックして計画へ折り込むましょう。
リスク・マネージメントを家族旅行で例えると！
①電車が遅れて目的地への到着が遅れるかもしれないので、時間に余裕を見る
②財布を無くす可能性があるので、現金を数人で分けて持つ
③テーマパークで濡れるからもしれないので、着替えを余計にもつ
などのことです。
トラブルリスクの予想は、経験がいります。
専門家の意見や過去の似たプロジェクトを参考にすると、リスクの洗い出しが出来ますよ！どんなトラブルが起こっても「想定内！」って対処するプロマネって、かっこいいですね。
▼『プロジェクトは始まる前にすべてが決まる』
プロマネが、自分自身でキャリアを守るためのリスク管理本です。
なかなかの良書です。おすすめです。
まとめ プロジェクトの立上げと計画プロセス群について
ポイント
【立上げプロセス群】
1．プロジェクト憲章を作成しよう
2．ステークホルダーを特定しよう
【計画プロセス群】
3．作業範囲を明確にしよう（スコープ・マネージメント）
4．スケジュールを作成しよう（スケジュール・マネージメント）
5．予算を設定しよう（コスト・マネージメント）
6．トラブルを予想して対応しよう（リスク・マネージメント）
ここまでくれば、プロジェクト目標達成のための内容・時間・お金が決まりました。
これから調達実行、チーム編成といった『実行プロセス群』に進んでいきます。
必要に応じて品質や資源、コミュニケーション方法等の計画書も作成すると、よりプロジェクト全体を網羅した計画書になってくると思います。
プロジェクトの計画書は、一度作れば完成ではありません。
作業全体を通して、随時見直しを繰り返し行うことが大切です。
プロジェクトではトラブルや変更はつきものですし、計画内容がチームの実態に合わずに足を引っ張るようなこともあるからです。
計画実行後も、いつも見直してブラッシュアップしましょう。
ポイント
ここまでの内容をまとめた資料が『プロジェクトマネージメント計画書』です。
文書のテンプレートは、各会社や組織にあるものを使うことをお勧めします。
関係者が馴染みのある資料であれば、打合せ時間の短縮にもなります。
繰り返しになりますが、プロジェクトマネージメントはあくまでも手法です。これが、正解！というものはありません。プロジェクトに応じて、PMBOKを臨機応変に活用しましょう。
それでは、みなさんの参考になればうれしいです😄
▼こちらの関連記事もどうぞ
-
-
プロジェクトの遅れる理由を知っていますか？３つの理由を現役プロマネが解説します
こんにちは、建設系現役プロマネのMARCUSです 『良く出来た計画と十分な資源があっても、プロジェクトが遅れる理由は何なのか？』 『始めは順調なのに、プロジェクトが進むとだんだん遅れてくるのはなぜなの ...
続きを見る
-
-
【PM必見！】プロジェクトマネージャーに必要なスキル・資格とは？
こんにちは、MARCUSです。 プロジェクトマネージャーを目指しているけど、必要なスキルや役に立つ資格は？ そんな疑問について、わかりやすく説明します。 建設業界（いわゆる工事業界）でプロマネ歴10年 ...
続きを見る
-
-
【知りたい】プロジェクトマネージャーの年収、給料、年収アップ法
こんにちは、マレーシア（海外）で建設プロマネをしているMARCUSです プロジェクトマネージャーになろうとしている人も、すでにプロジェクトマネージャーの人も、他の人の給料・年収が気になりますよね～ そ ...
続きを見る