PJMとして学びたい、MTGの事前情報

この記事はHSP傾向があり、プロジェクトマネージャーを任された方向けの記事です。
今日はプロジェクトにおけるMTGの事前準備について説明します。
 
「今更MTGの事前準備を知る必要があるの?」
 
と思われるかもしれません。
 
しかし、プロジェクトマネージャーの仕事は、90%がコミュニケーションと呼ばれています。コミュニケーションの質がプロジェクト結果に大きく影響します。
 
 
ステークホルダーとの会話の場であるMTGこそ、プロジェクトマネージャーが最も力をいれるべき場面です。
 
 

MTGの種類と特性を理解しよう

 
MTGには目的に応じた種類があり、用途が異なります。
 

f:id:tateki_intokyo:20201123112620p:plain

 
そしてMTGを開く際には、どの目的で行われているかを参加者に理解してもら必要があります。
 
参加者に共通の認識がないと、例えばBrainStormingのつもりで開いたMTGで、Aさんは「決定された」と勘違い、勝手に仕事を進めているだけならば未だ良いですが、Aさんから部署の上長へ報告されてしまうと、部署レベルで認識の違いが広がってしまいます。
 
そこでオススメは、プロジェクトのキックオフMTGでコミュニケーションフローを明確にする事です。

f:id:tateki_intokyo:20201123112215p:plain

事前にプロジェクトメンバーおよびステークホルダーと、
「どんなコミュニケーションが行われるのか?」
「どのようなプロセスをもって決定されるのか?」
を共通認識として持つことが出来れば、
 
”気が付けば勝手に進んでいた”といった問題を防ぐことが出来ます。
 
ちなみにこれは自論ですが、コミュニケーションフローはソフトウェア開発のプロジェクトほど明確にするべきと考えています。
 
ソフトウェア開発はハードウェアの開発と比較して、実行修正が比較的容易です。
 
例えば、新しい車を製造するプロジェクトの場合、「間違って未だ決裁下りていないのに部品を購入してしまった」等のミスが大きなコスト損失になりますから、恐らくしっかりとコミュニケーションフローを決めて決裁手順を定めているでしょう。
 
対してソフトウエア開発は、「間違って一部のプログラムを書き始めてしまった」等が起きても、もちろん工数は勿体無いですが、書き直せば良いのですからイコールすぐに大きな問題になりません。
 
だからこそ、ソフトウェア開発はコミュニケーションフローが明確に定められず、結果としてコミュニケーションにコストがかかっていると感じます。
 
プロジェクトの計画段階でコミュニケーションマネジメントを具体的に決めましょう。
 
 
プロジェクトは段取り8割と言われます。
 
段取りをしっかりする為には、プロジェクトマネージャーは他メンバーを気にかける精神的,時間的な余裕が必要です。
 
その為にも、プロジェクトマネージャー自身が資料作成やデータ分析などの個人作業を受けないようにしましょう。
 
もし自分の業務の90%がコミュニケーションではない時、見直しをするべき時かもしれません。
 
本日は以上です。
読んで下さり有難うございました。

プロジェクトマネージーが意識したい4つのフェーズ

この記事はプロジェクトマネージャーを任された方向けの記事です。
今日はステークホルダーについて説明します。
 

プロジェクトは4つのフェーズに分けられる

プロジェクト実行までに最低限作るべきドキュメント

 

プロジェクトは4つのフェーズに分けられる

 

プロジェクトのフェーズは以下にまとめられます。

 

「立ち上げ」

「計画」

「実行(とコントロール)」

終結

f:id:tateki_intokyo:20201107135512p:plain

 

これらのフェーズはどの業種業態でも変わらない共通のフェーズです。よって、プロジェクトマネージャーは知識,スキル,人間性を活かして、一つ一つのフェーズをこなしていく必要があります。

 

その上で最も重要な考え方は「各フェーズの境界線はあいまいにしてはいけない」という事です。

 

各フェーズ間ではフェーズ・ゲートと呼ばれる、「ステークホルダー内での承認」作業があります。承認作業は、一人の決裁者が承認するか,複数者が承認するか、多数決か,全会一致か、過半数か独断かなどいくつかの方法がありますが、このフェーズ・ゲートを明確に設ける事で、プロジェクトが今どの状態にいるのか、ステークホルダー内で共通認識をもつ事ができるようになります。

 
プロジェクトを実行するまでに最低限作るべきドキュメント
プロジェクトを実行するまでに最低限作るべきドキュメントは以下になります
・ビジネスケース
・プロジェクト作成範囲記述書(SOW)
・プロジェクト憲章(Project Charter)
・プロジェクトマネジメント計画書
 
・ビジネスケースは、企業や組織が投資する際の合理性と適正性を示します。これはPJMではなく依頼者となるプロジェクトスポンサーや営業,企画が作るケースが多いです。同時にPJMも理解が必要です。ビジネスケースを正しく理解する事で、プロジェクトが進む間にユーザニーズやビジネスインパクトと異なる方向へ行ってしまう事を防ぎます。
・プロジェクト作成範囲記述書(SOW)は、目的,目標,作業範囲,成果物,メンバーの役割と権限を示します。これを元にしたプロジェクト憲章が作成されます。
 
ステークホルダー登録簿は、各ステークホルダーのプロジェクトに対する権限,影響度,関心の一覧になります。ステークホルダー登録簿を元にステークホルダーとのコミュニケーション方法を定めます。(権限の大きいステークホルダー:こまめに連絡し、要求に沿ったPJT要件を
作成。権限の小さなステークホルダー:定期的に連絡して情報共有する 等)
 
・プロジェクト憲章(Project Charter)は重要で根本的な方針や施策などをを示します。これはプロジェクトスポンサーとPJMが認識を合わせながら作成するケースが多くなります。
 
上記のドキュメントをプロジェクトスポンサーとPJMが読み合せて合意する事で、立ち上げフェーズが終わります。特にプロジェクト憲章(Project Charter)は重要です。プロジェクト憲章をプロジェクトスポンサーと読み合せ、承認を得る事でプロジェクトが正式な活動として認可されます。
 
そしてその後は、PJTのスコープ,スケジュール,R&Rなどをプロジェクトマネジメント計画書で記述していくことになります。
 
プロジェクトは規模が大きくなる程にPJMの力がよって大きな違いが生まれます。上記のフェーズを意識し、一つ一つのドキュメントを丁寧に作るようにしましょう。

HSPなPJMは、目的・目的を強く意識しよう


この記事はHSP傾向があり、プロジェクトマネージャーを任された方向けの記事です。
今日はプロジェクトの目的,目標について説明します。
 
結論
 

目的とは”あるべき状態”、目標とは”目的に向かう上で目指す目印”

 
プロジェクトは始める際にまず定めるべきは目的と目標です。しかし、意外にこの目的と目標が曖昧だったり、関係者の中で十分に共通認識を取れてない場合があります。
 
例えば上層部がある問題に大きな関心を寄せており、至急解決策が期待されているとします。そのような背景で立ち上がったプロジェクトは、最初の段階こそ上層部の支援を受けて一気に進みますが、その関心が薄れると着地地点を失いがちです。
 
 
そうならない為にも、まずは目的と目標をしっかり定めておく必要があります。そして目的と目標の定義は以下です。
 
・目的: あるべき状態
・目標:目的に向かう上で目指す目印
 
目的はあるべき状態を指します。よって一つしかありません。目標はそこを目指す為の目印です。よって複数あります。
 

f:id:tateki_intokyo:20201025064303p:plain

目的を定めるのは大変

”あるべき状態”を定義するのは単純な作業ではありません。個人や家庭でしたら人数も少ない為、比較的容易ですが、大勢が関わる会社では難易度が上がります。
 
そこで、目的を定める第一歩として、プロジェクトに関わる以下を明文化しましょう。この5つに応える事によって目的のアウトラインを整理できます。
 
Q1;会社,組織が欲しいものはなにか?(WHAT)
Q2;なぜそれが欲しいのか?(WHY)
Q3;いつぐらいまでに欲しいのか?(WHEN)
Q4;いくらぐらい必要なのか?(HOW MUCH)
Q5;どうやったら手に入るのか?(HOW)
 

目標は定量的かつ具体的に決める

 
目的を設定した後は目標を設定します。目標設定において意識するべきは、定量性と具体性です。
 
悪い例:他社と同価格帯の新機種スマホを作る
 
良い例:2021年12月までに、企画×課がPMとなり、自社製造ラインを利用して、他社と同価格の5万円でカメラは××画素、スクリーンの大きさは××、カラーは3種のスマホを、原価3万で作る
 
最低限の情報としてWhen(いつ),Who(誰が),Whom(誰に),What(何を),How(どのように),How much(いくら)は含まれているべきでしょう。
 
必要な情報がプロジェクトメンバーに伝わらないと、不要な作業や方向性を間違えた作業が行われ、貴重なリソースを浪費してしまいます。
 

目的,目標は臆せずステークスホルダーと話すべき

 
目的と目標はステークスホルダーに強く共有するべきです。たとえばプロジェクトに関連する知識を持っている専門家に伝えたり、社内のプロジェクトを横断的に理解している有識者に相談する事で、新しい情報を得られ、情報に応じて目的や目標の修正が可能になります。修正は早期であるほどにプロジェクトリソースの有効活用につながります。
 
また、目的と目標はプロジェクトメンバーにも何度も強く共有されるべきです。よくあるたとえ話ですが、一人のレンガ職人がレンガを造る仕事を「金を稼いでいる」と考えるか、「質の良い煉瓦を造っている」と考えるか、「世界一の塔を建てている」と考えるかは、掲げられている目標とその理解度に依存します。
 
では、”何回伝えると十分なのか?”と疑問が湧きますが、よく言われるのは平方根ルールです。
 
・プロジェクトメンバー4人体制:4の平方根で2回
・プロジェクトメンバー10人体制:10の平方根で3.15、繰り上げして4回
・プロジェクトメンバーが100人:100の平方根で10回
 
上に記載の回数伝えれば十分だという事ではありませんが、目的はなにか?具体的で定量的な目標は何か?を定め、ステークスホルダーに周知するのはまさにPJMの仕事と言えるでしょう。
 
特に、HSP傾向のあるPJMにとって目的・目標設定は一層大切な作業になります。一度プロジェクトが走り始めると、予想もしない事が発生します。ステークスホルダーが新しい要件を要求したり、プロジェクトメンバーからプロジェクトに関わる大きな問題が挙げられたりされます。
 
そんな時に繊細で他者の感情に気を遣いがちなHSPは、迷いや心理的な葛藤を抱えてしまいがちです。それでもブレずにプロジェクトを遂行していく為、立ち返る場所としての目的と目標が重要になります。
 
時に目的と目標を定める作業は時間がかかり、ステークスホルダー間の交渉が必要な苦しい作業ですが、その後のプロジェクトの円滑な運営の為、手を抜くことなく丁寧に進めましょう。
 
今回は以上です。
読んで下さりありがとうございました。

PJMが把握したいステークホルダー

この記事はプロジェクトマネージャーを任された方向けの記事です。
今日はステークホルダーについて説明します。
 
結論
    ステークホルダーは網羅的に捉えよう
    特に知るべきはプロジェクトスポンサーとPMO
 
ステークホルダーは網羅的に捉えよう
 
ステークホルダーとは「プロジェクトの任意の局面に利害関係をもつか、影響を及ぼすか、影響されるか、又は影響されると自覚する人、グループまたは組織」です。日本語では利害関係者と呼びます。
 
プロジェクトメンバーは勿論ですが、PJTの恩恵を受ける顧客、PJTに影響を及ぼす社内機関で例えば法務部やITガバナンス部、協業するビジネスパートナーなども当てはまります。そのような人たちの期待,要望を調整しながらプロジェクトを進めるのがプロジェクトマネージャーの仕事です。
 
ステークホルダーを考える上で一つ注意頂きたいのは、利害関係がありながらPJTから距離をとってくるステークホルダーです。時に一部のステークホルダーはPJTが自身の業務や責務に影響を及ぼすと知りしながら、意図的に関わりを避ける場合があります。その理由は様々ですが、自身の業務が繁忙している為関わる時間がない、想定される依頼への答えが未だ準備できていない等が挙げられます。
 
このようなステークホルダーは消極的な態度を取る為、プロジェクトマネージャーも注意が弱くなりがちですが、そんな彼らも避けきれない局面になると急に沢山の要望を出したり、これまで出てこなかった新しい指摘を入れてくる場合があります。ですので、プロジェクトマネージャーはそのような回避してくるステークホルダーの要望も、予め十分に理解して進めていくべきです。
 
特に知るべきはプロジェクトスポンサーとPMO
 
様々なステークホルダーがいる中で、特に注意するべきはプロジェクトスポンサーとPMOです。プロジェクトスポンサーはプロジェクトを正式な活動であると承認する役割です。また、プロジェクトマネージャーの権限を超える問題を解決してくれる役割でもあります。たとえば複数プロジェクト間での予算の割り振りや、人員の配置などです。
 
よって、プロジェクトスポンサーが誰かを理解し、彼らに十分な説明をする必要があります。プロジェクトスポンサーへの説明機会は限られている場合が多い為、然るべきタイミングに備えてしっかり準備する事が重要です。
    
次に注意するべきはPMOです。プロジェクトマネジメントオフィスとして、プロジェクトのガバナンスや標準化、教育や監視を行うのがPMOになります。覚えておくべき事として、彼らの職務はあくまでプロジェクトを整える事であって、プロジェクトの目的,目標達成ではありません。
 
時々プロジェクトマネージャーしていると言いつつも、会議体の調整や資料管理ばかり実施している人がいますが、それらはPMOの仕事でありプロジェクトマネージャーの仕事ではありません。PJMの仕事はあくまで目的,目標達成である事を覚えておきましょう
 
今回は以上です。ステークホルダーの知識を自身のPJTにおき替えて、参考にしていただければと思います。

プロジェクトが直面する3つの問題

この記事はプロジェクトマネージャーを任された方向けの記事です。
 
プロジェクトマネージャーの仕事は、納期までに目的,目標を達成する事です。プロジェクトは様々な問題に直面しますが、その中で常に「どうすれば達成できるか?」と考え続ける必要があります。
 
そして、プロジェクトが直面する問題は3パターンに分けられます。
 
1.立ち上げ時に未来の目的目標が想像できない
2.計画から実行へ実際に行動を移せない
3.実行時に計画と現実が違い過ぎて諦める
 
どの問題に直面するかは、プロジェクトのサイズ,組織のサイズに影響されます。
 
例えば少数の組織の場合、立ち上げ,計画にあまり時間はかかりません。
「これを試そう!」「当面はここを目標にしよう!」と定めれば、後は実行するのみになります。早ければ数時間で一つのPJTが実行へと移っていきます。
 
団体で仕事していると同じようにはいきません。立ち上げ時に目的,目標を決める際、プロジェクトサポーターと認識合わせし、様々な関係部署に説明する必要があります。
関係部署の繁忙期と重なると、計画から実行に移すまで時間がかかる場合があります。
 
一方で、団体でプロジェクトを進める良さは実行時にあります。動き出したプロジェクトを止める権限はプロジェクトサポーターにしかありません。各メンバーはそれぞれの意思に関わらず、プロジェクト内のアサインされたタスクを行います。立ち上げと計画には時間と忍耐が必要ですが、動き出す事に成功すればプロジェクトは進んでいきます。
 
少数の組織の場合、逆に実行時で問題にぶつかります。現実が計画と一致しない時、辞めるか続けるかを関係者が集まって判断するのが容易な為です。よって、途中で注視になるプロジェクトが多く発生します。
 
私自身、大きい組織でプロジェクトマネージャーをしながら、プライベートで個人事業主のように仕事をしています。大きい組織は立ち上げと計画時に沢山の時間と苦労がかかりますが、一度動き出しさえすればモニタリングするだけの期間続きます。
プライベートの仕事は立ち上げと計画はすぐに終わりますが、目標に向けて行動し続ける根気が必要です。
 

このように、組織サイズでプロジェクトが直面する問題は異なる認識するのは重要です。そして、それぞれで体験する苦労と身につくスキルは異なりますので、大きい組織でのプロジェクトと、個人事業主のようなプロジェクトの両方を経験する事をお勧めします。

 
両方を経験し、バランスよくプロジェクトマネジメントのスキルを身につけましょう。

PJMになったら知りたいPJMの基礎概念

この記事はプロジェクトマネージャーを任された方向けの記事です。
 
”プロジェクト”という言葉は抽象的なものとして便利に使われていますが、その定義は明確に定められれているという内容です。

結論

 プロジェクトとは「過去に一つでも経験したことない要素」と「開始日・終了日」
 プロジェクトマネジメントには、プロジェクトマネジメントの知識と技術が必要
 

プロジェクトとは「過去に一つでも経験したことない要素」と「開始日・終了日」

 
”プロジェクト”という言葉はとても抽象的に使われ、何かの取り組みを始める場合に「××プロジェクト」と呼ばれたりします。逆に、”このサイズの仕事はプロジェクトと呼べない、これはタスクだ”といった言葉を聞くことがあります。プロジェクトの定義はなんでしょうか?
 
プロジェクトの定義は「独自の目的・目標を設定し、それを期限までに達成させる一連の活動」です。
 
まず、「独自の目的・目標」があります。つまり、一つでも過去に経験のない要素があればPJTです。そして、「開始日と終了日」が決まっています。プロジェクトには必ず期限があります。
 
分かりやすい例として、”結婚式”が挙げられます。”結婚式”は、男女が友人,知人を招いて結婚を宣言する目的で、決められた日取りに行われます。殆どの方の場合(離婚経験がない限り、、、)、二人に結婚式の経験はなく、情報収集から始まり、予算を決め、内容を決め、実施します。
 
ちなみに、”結婚式”は最も進めやすいプロジェクトの一つです。なぜなら、目標,目的,期日を承認するプロジェクトスポンサーが本人だからです。プロジェクトスポンサーは決裁者と言い換えて頂いて構いません。
 
企業活動においては目標,目的が定まっておらず、終了日も決まっていない活動を”プロジェクト”と呼ばれている場合があります。これは、プロジェクトを指揮するプロジェクトマネージャーと、承認するプロジェクトスポンサーが別々の場合に発生します。
 
プロジェクトスポンサーも目標,目的,終了日を承認したいのですが、より上位の戦略が定まっておらず、承認基準がない為です。
 
その場合、プロジェクトマネージャーは担当プロジェクトの目的,目標,終了日を提案するだけではなく、より上位の戦略の理解が求められます。
 
もし、担当プロジェクトの目的,目標,終了日が決まっていない場合、まずは上位の戦略の情報を集めた上で、担当プロジェクトの目標.目標,終了日を仮設定し、決裁者であるプロジェクトスポンサーに提案しましょう。
 

プロジェクトマネジメントには、プロジェクトマネジメントの知識と技術が必要

 
プロジェクトマネジメントが体系的に整理されている職場は少ない印象です。正確にはプロジェクトマネジメントの研修は提供されていますが、各メンバーがそれを業務に落とし込みできているケースは少ない印象です。多くの方々が先輩たちの姿を見てプロジェクトマネジメントを学ばれているのではないでしょうか?
 
プロジェクトは「立ち上げ」「計画」「実行」「コントロール」「終結」にプロセスを分ける事ができ、それぞれのプロセスに必要な知識と技術があります。特に「計画」「実行」における知識と技術が重要です。
 
計画を正しく立てていないと、目標が低すぎたり高すぎたりなってしまったり、本来の目標,目的が達成されない実行計画になったりします。実行を正しく進めないと、計画と現実の間のギャップが大きくなりすぎ、プロジェクトが途中で終わってしまったりします。
 
そこで、どの業種,業態でも押しなべて適用できるプロジェクトマネジメントの知識,技術が重要になります。
 
また、プロジェクトの成功には、知識,技術だけではなく人間性も大切な要素になります。
 
計画から実行に移ると、プロジェクトはまるで頂上目指して道なき道を歩く登山のようです。途中で想定外も起きますし、ケガする人もいますし、様々な問題が起きます。その中でプロジェクトメンバーと共に頂上を目指す為には、引率していく人物の人間性が不可欠です。
 
例えば、役職は決して高くないありませんが、会社のビジョンを理解し、メンバーに慕われる人は、部署を異動すると途端に出世する場合があります。
 
逆に、役職は高くて営業力や資料作成など高いスキルをお持ちにもかかわらず、感情的性格の為、メンバーに距離をおかれている人は、その役職で止まってしまう場合があります(というよりも、配下メンバーが辞めてしまう為、組織がスケールしないのですが、、)。
 
人間性はプロジェクトを成功させる為には必要な要素です。そして、最も軽視されている要素かもしれません。この人間性は有名なデールカーネギーの「人を動かす」で学べると思います。
 
今回は、プロジェクトには目標,目的,終了日がある、プロジェクトマネジメントには知識,技術,人間性が必要であると書きました。PJM活動に活かしていただけますと幸いです。
 
お読みいただき、ありがとうございました。

脳科学から考える良いデザイン

PMしていると、「UIは2つのパターンがありますが、どちらが良いですか?」「この入力制限ロジックをいて入力精度を高めようと思いますが、どう思いますか?」とデザイナーから質問され、判断に迷うときがあります。
 
ABテストで判断できると好ましいですが、細かいデザイン一つ一つにテストはできません。今回はそのような状況で判断したい時の一つの指針を脳科学の観点から考えたいと思います。
 
PMをされていて、かつページデザインなどの具体的な部分を看ている方々にとって役立つ内容になっています。
 

結論

人には不快情動と快情動がある

良いデザインは不快情動を起こさない(つまり、脳にストレスを感じさせない)

 

人には不快情動と快情動がある

外的な変化に応じて身体に起きる変化を”情動”と言います。例えば、野原を歩いていて、目の為を黄色と黒色の小さな物体が飛んできたとしましょう。私たちは反射的に頭を屈めて身を縮めます。身を縮めてからその物体を注視すると、ハチだと分かりました。そして「ああ、怖かった!」という言葉が出ます。
 
この「物体が飛んできた事を認識する」⇒「身を縮める」が情動です。
 
他の例として、偶然目の前に綺麗な女性が現れた時に心臓の鼓動が速くなる事も情動です。つまり、情動は無意識下で生み出されます
    
この情動は悲しみ,恐れ,怒りなどの不快情動と喜び,愛などの快情動に分けられます。そして、私たちは快情動を得るか、不快情動を避ける為に行動します。例えば、道を歩いていると焼き鳥の匂いがした時に思わず視線を向ける行動は快情動を得る為です。奥さんが起こった時に思わず目を背けるのは不快情動を避ける行動です(笑)。
 
私たちは快情動を得るか、不快情動を避ける為に行動する。これは重要なインサイトです。
    

良いデザインは不快情動を起こさない(つまり、脳にストレスを感じさせない)

 
”不快情動を発生させない”デザインが良いデザインと言えます。箸を例にあげましょう。箸を使ってご飯を食べる時、”箸ってどう握ればいいんだろう?”とわざわざ考えません。意識を使う事もなく箸を親指と人差し指で掴み、中指を添え、テレビを見たり人と話しながら、ご飯を箸で掴みます。
 
”箸でご飯を掴む”という行為に意識を向ける事はありません。私たちは箸をまるで身体の一部のように扱え、そこに不快情動はありません(表面がツルツルした食べづらい食べ物を除き)。箸は不快情動を生み出さない為、私たちにとって良いデザインと言えます。
    
箸が手を汚さずに食事という活動を実現させるように、良いデザインは身体の一部のように人の活動をサポートし、その活動範囲を拡張させます
 

三回以上もボタンを押させるな。 スティーブ・ジョブズ

 

スティーブ・ジョブズのプロダクトへの拘りも、不快情動の同じ文脈で捉える事ができます。

    
PMとしてデザインに迷い時があります。そして思わず、「どっちでも良いかな~」と言いたくなります。定量データがないとベターなデザインを判断するは難しいです。
 
そのような時は、”脳にストレスを感じさせないデザインとは?”と問いかける事をお勧めします。そう考えると、たとえ簡素であってもユーザにストレスを感じさせないデザインの方が、ハイエンドで見栄えの良いデザインよりもベターな場合もあるでしょう。
   
今回は脳科学における情動の観点から執筆いたしました。読んで頂き、有難うございました。