おまけ資料の「プロジェクト憲章サンプル」「WBSサンプル」は、後日HIDEブログにかきまーす！
20220206 10時PMからスペースで実施したプロジェクトマネジメントに関する議論をまとめたもの
https://twitter.com/fishing_kiyogon/status/1489566422443642881
おまけとして、プロジェクト憲章やWBSのサンプルも記載し、すぐに自分のプロジェクトに利用できるようにする。
shunさん、仮想Nishiさん、さきさん、井上さん、くろみさん、きくえさん、無限に昼寝していたいさん、ゆきうさぎさん、広高さん、おけいさん、loserさん、ありりさん、きよごん
コメントしてくれた方々：仮想Nishiさん、shunさん、くろみさん、きくえさん
| コメント |
|---|
| プロダクトを作り終えるまでの全部の工事現場監督者 |
| なにかみんなでやるってのがあって、 |
| ゴールがあるので、ゴールまで道を間違えないで完走できるようにうまく進めるモノ（人じゃなくてモノ） |
| ＋品質、コストを考慮する。 |
| （規模、業界でちがうけど） |
| 目的/ゴールに向けて、納期/アウトプットを定義し、それに向けて、ステークホルダーを調整していく。（調達とかしつつ） |
| 目標と終息を意識し、プロジェクトメンバーががちゃんと動けているかを確認する活動。 |
目的を決めて、どのチームがどんな役割を持つかメンバーが何をするかを決めて、
プロジェクトメンバー全員でゴールに向かって走り続ける活動！
PMは与えられたものをやるのではなく、自分で主体的に決めて、最後までやり続ける活動です！
コメントしてくれた方々：仮想Nishiさん、shunさん、くろみさん、きくえさん、井上さん
| コメント |
|---|
| 全体を見て、組織横断的に、過不足ないように、調整を行う。 |
| プロジェクトに関わってる人、チームメンバー以外にも、どんなステークホルダーがいるかを意識して、これをやるためには誰が必要で、誰に確認するべきで、ちゃんと全部を把握すること。 |
| 指示したり、タスクするだけでなく、タスクを行う人/まかせる人に、なんのためにやって、あなたはどこまでやってほしいをちゃんと伝える。（きっとこれでわかるだろう、ではなく） |
| メンバーで参加することが多いけど、WBSだったり、マイルストーンあるので、それにそっているか、クリティカルなボトムネックになってないか、。 インフラの場合は、回線がちゃんと引けているかを気にする。拾えるところを拾う。特に外注（半導体不足）が遅れる可能性があるので、顧客先への説明をちゃんと行ったり、意識を合わせる。 |
| 人数増えてきたら、ちゃんと理解できているか/理解度が人によってちがうので、きちんと質問できる雰囲気作りが大事。 |
| 年齢層バラバラなチームだと、若い人が質問しづらくなる。経験浅いと言いづらい雰囲気が。出せるパフォーマンスが出せなくなる。 |
| プロジェクトマネジメントでやっているポジションを考えると |
| プロジェクトのゴールを定めること。これによって予算、リソースがでて、WBS/クリティカルパスが定めれる。 |
| 決裁権を持った上で判断できる。 |
| （リソースの確保、機能追加削除、ゴールを定める/変更できる） |
| プロジェクト憲章を作って、プロジェクトの合意形成を行う。（社外のプロジェクトメンバーを含めて） |
とにかく横断的に全体を見る。
PMの仕事は、経営者を動かすことも含めて、全部です。
プロジェクトの最初に行うことは、
キックオフMTGにプロジェクト全メンバーを参加してもらい、
プロジェクトの目的（どんな社会貢献、どんな会社メリット、どんなユーザメリット）やゴール（期限、定量効果）を明文化した上で、
ここ目指すので合ってるよね？って合意形成すること。
プロジェクト進行する上で重要なのは、
・担当者がタスクの目的/内容をちゃんと理解できているのかを意識する。
（質問しやすい場やコミュニケーションチャネルを作る）
・特に外注するタスク（脆弱性診断や回線敷設、金融庁確認など）は、スケジュール調整が難しいのでバッファを含めて最初にスケジューリングしましょう。
| 言葉 | ざっくり | 備考 |
|---|---|---|
| WBS | タスクを細分化したもので、タスクと先行関係、担当者、期限を記載するもの。 | Excel/PPT/MicrosoftProject/backlogなどのツールが利用される。 |
| 重要なのはどのツールを利用するか、ではなく、 | ||
| 「どのように運用するか」が重要。 | ||
| 誰がどういうタイミングで更新するか、定例ではどのように利用するか、など。 | ||
| ↓にサンプルを置いておきます。 | ||
| クリティカルパス | 一言でいえば、遅れると目標のスケジュールが遅延するタスク。 | |
| 逆に言えばクリティカルパスでないタスクは遅延してもスケジュールが遅延しないので余裕があるタスクとも言える。 | ー | |
| プロジェクト憲章（Project Charter） | プロジェクトの5w2hをプロジェクトメンバーで共有するために利用するもの。 | |
| キックオフMTGで利用する＆変更があった都度プロジェクトメンバーに共有する。 | ↓にサンプルを置いておきます。 |
コメントしてくれた方々：shunさん、くろみさん、井上さん、ゆきうさぎさん、仮想Nishiさん、広高さん、おけいさん、さきさん、かず、Loserさん、ありりさん
| カテゴリ | 困ったこと | 解決案 |
|---|---|---|
| タスク/進捗管理 | 進捗率80%とか100%ってなってるけど、蓋開けたらなんもない。 | ・近い人がちゃんと確認すること。 |
| ・そして、早めににぬけさせる | ||
| タスク/進捗管理 | WBS（やること全部書きだしてるスケジュールのようなもの）を中途の年上の人が作ることにあって、3行（設計、構築、運用）しかなくって、PMから降ろされた。 | 社内で過去に実施したWBSのサンプルを渡してあげるのがよい。 |
| タスク/進捗管理 | 粒度/観点が人によって異なる。下手な人だとプロジェクトがあれることが多い。 | 過去に実施したWBSをもとに勉強会をやってもらうとよさそう。 |
| タスク/進捗管理 | WBSで難しいポイント。PMはいろんなPMがいる。クリティカルパスにつながるところを引く、エンジニアの進捗ベース（開発、テストなど細かいところ） チームメンバーによって誰がどこまでやるんだ？ | |
| →個人の見解にならないものを作らないといけないけど、それはPMの仕事じゃないじゃん。 | ||
| PMの求められる内容によって、粒度が異なるのは、日本だと仕方ない。 | ||
| 日本以外だともっと細かくすべき。 | ||
| 日本人は察する能力があるが、日本人以外だとそれが難しいよね。 | 人によって理解できる粒度が異なるのは仕方ないので、 | |
| 人に合わせて明文化すること。 | ||
| タスク/進捗管理 | 誰に何を伝えたいか、がすごい大切。 | |
| PMに伝えたい粒度、開発に伝えたい粒度によって、WBSは異なる。 | ||
| 経営者、開発へ伝える粒度が異なるので、意識する。 | 経営報告用の進捗の資料と、 | |
| 開発用のWBSは別に用意したほうがいいね。 | ||
| タスク/進捗管理 | アップ日という言葉の定義が人によって違う。 | |
| クライアントが確認するのか、社内で確認するのか？ | クライアントの作業についてもWBSに追加する。 | |
| （WBSには、社内だけでなくプロジェクト関与者全員の情報をいれましょう） | ||
| 組織 | 会社によってプロジェクトや開発を知らない人が偉い人のケースもあり、 | |
| その場合はどうすりゃいいんじゃ（メテオバーン開発） |
もう偉い人が、鶴の一声で ころっと変わる。3回位経験ある。朝令暮改 | この場合は、36計逃げるに如かず
おすすめは、その会社を将来買収できるような企業に転職して、買収してやりましょう。 | | タスク/進捗管理 | サービスインまえに、脆弱性診断を行わないとリリースができないと気づいた。
| ・WBSを作った段階で関係者にレビューをし、OKをもらう。 ・そこになかったタスクに気づいた場合は、改めて、関係者と調整して、リスケすることで合意をとるべき。 | | タスク/進捗管理 | タスク整理ができてない＆チーム内の認識合わせができてない、結果各タスクで、手戻りなどが発生する。 | コミュニケーション方法をちゃんと定義しましょう（定例、チャットのチャネル） 個別の会話で終わってしまうのが一番よくないので、 個別で会話した場合は、みんなのチャネルにあらためて明文化して伝える。 ※人事系の話以外は、DMは使わないようにしようね。 | | 変更管理 | 嫌いなPM：クライアントから機能追加の相談を受けたときに、その場でいい返事をして、メンバーが大変になることを引き起こす。
スケジュール/予算について戦えよ、その機能ほんとに必要なの？ PMは、プロダクト/サービスに対する判断をちゃんとすべき。戦った結果をメンバーにちゃんと説明する。
PMが受けて、plyaingもしようとして、燃えちゃう。 | プロジェクトオーナーと、プロジェクトマネージャの力関係を、 対等でなければ、プロジェクトマネジメントはうまくいかないよっていう、 文化を醸成していくしかないなあ・・・。
特に日本の大きな会社ほど、プロジェクトオーナー側の力が強く（知識がなく） プロジェクトの失敗が多いような気もするので、 経営者がシステム開発に知見があるかどうかをチェックしましょう。 （エンジニアは、営業の強い商社や証券会社は行かないほうが幸せになれます。） | | コミュニケーション | 確定事項だけをメンバーに使えると歪がおきやすい。
| こういう理由でこうなったんだよ、って説明をメンバーにちゃんと伝えよう。（勝手に決めやがってって思われないようにする） 人数の大小に関わらず大切。 | | 変更管理 | 「この機能やれれば入れてよ」っていう曖昧なやつ。 | その場は受けてもいいけど、メンバーには伝えないで、 「できませんでした！」でよい。次のフェーズで提案し直す。
もし赤が出ずにできるなら、信用度を得るためにやってもよい。 | | 営業 | 新たな依頼がきたときに、どのように話すか。
| なんでやるのか？ という理由を明確にしてほしい。 何が問題で、その要望を出してるの？スケジュールと予算を教えてください。
理由があれば、工夫する余地が生まれる。 | | 組織 | 引き継いだ案件が3億円の損害で、始末書かいた （年をまたいだらバグって、注文できなくなった。すごいトラブル。） | 始末書書くのは担当者ではなく、お金に責任をもっている偉い人に書いてもらいましょう。 | | 人外 | 10人月なら、1ヶ月10人いれれば終わるでしょ？ | なるべく近寄らないようにしてください この手の輩を説得するのに時間を費やすにはあなたの人生は短すぎます。 | | 営業 | ディレクタ（営業みたい）な人がとってきた。3000万円。（事後報告） がんばったじゃん！
1億くらいかかるプロジェクトだったｗｗｗｗ | 一般的には、500万円以上の案件は、IT部門がチェックする、みたいなプロセスを作るのがいいですね。 | | 組織 | やばいやつが上にいた。 | ・さらに上の人を仲間に引き入れる。 ・または、いい感じにおだてあげて気持ちよくさせて仕事を任せてもらう。 | | 教育 | 部下の育成が大事だ！
部下ってのが外注・・・。 育てると営業で引き抜かれる。
育てると損・・・・
抱合せで新人いれられて、成長したら、単価交渉・・・・無理なら、いなくなる、みたいな営業される。 | SESを育てるってこと自体がおかしい。
解決策がない感じ。
そういう営業を信用しないってことが解決策になる。
一度そういう経験をしたら、その会社名を公開してください。 | | リソース管理 | 好きじゃないPM
リソースがないのに、ガールズバーの子をプロジェクトメンバーにいれる。 夜10時になるとガールズバーに出勤していく。 | モチベーション効果が得られるから問題ない？
→一定期間のびるけどそのあとくずれるんだって。オタサーの姫によるコミュニケーション破壊！ | | リソース管理 | １）ちいさい会社で社長が愛人を秘書にして。仕事ができなくて。でも優しくしろっていわれて、キレてみんなやめる。
２）中国のIT企業で、チアリーダを部署にいれた。かわいい美人な子をいれて、応援とかお茶とか。効率上がりましたって記事があった。 | 要はバランス | | プロジェクトマネジメント | PMって、役割であって、役職ではない。 開発であれば、ビジネスロジック決める人、開発するひと、QA(テスト）する人だけど、 PMは、最悪開発してもよい。役割がない役割をもつ。誰かがやってないことをやるっていう立場で働けると炎上しにくいのではないか。
方向性だけ決めればいい、管理だけすればいい、って考えているPMもいるが、 その場合、メンバーは、PMが決められないから、自分たちで決めればいい。
plyaingしたら燃えちゃうってのは、PMだけど開発するよになるとしても、 一時領域だけやる、って意識が必要。 マネジメントしすぎなくても、しすぎても問題。 | PMはゴールまでもっていければよいので、 自分がプロジェクトマネジメントに専念してもよいし、 開発を担っても問題はない。
プロジェクト開始時点で一人しかできないことをなるべく少なくしておくとリスク回避につながるかも。 | | ドキュメンテーション | ドキュメント時間かけすぎ問題。 とりあえずやったふうに見せる人が多い。 | ドキュメントについて ・目次を書いてレビューを受ける ・1項目作ってレビューを受ける
とにかく少ない段階でレビューをして、その人のレベルを見極めて、 指摘しましょう。 | | コミュニケーション | 共通言語がない | 開発といってもテストといっても人によって意味が違う。 そのためプロジェクトメンバーが増えるたびに、利用している言葉についてきちんと明文化する。 | | コミュニケーション | ドキュメント作っても見ない人がいる。 | 説明会するとか。。かなあ。。 | | コミュニケーション | 冷たいチーム。気づいてもいわない（俺のタスクじゃないし） めんどうだし、自分のタスク増やしたくないし。 | | | コミュニケーション | （若い人ほど）問題があってもいわない。
| 怒られそうなことほどいってほしい。 | | プロジェクトマネジメント | PMのしごとって、こうしとけば成功とか失敗といがいに言えない。 asis/tobeをつなぐ仕事を全部つなぎなおして、自分がやるか・他社を巻き込んで進めていく。
バックオフィスの業務設計と同じように、自分のプロジェクトのTobeまでの道筋をつくらないと、タスクが洗い出せない。
| プロジェクトとはもともと、組織を横断して行う仕事です。 部門を超えて、その会社の責任者としてできる限りの情報を横断的に収集して、 タスクの洗い出しと、役割分担を決めていく必要があります。 | | プロジェクトマネジメント | PMにたてなくても、うごける。 ジョーカーみたいなやくわり
勝手に動くようなルール化/システム化をしてる。 細かく決めれば動きづらくなる。いい塩梅で、人の能力をみながらワークフローにしたりルール化したりしてる。 都度都度権限を与えることで、プロジェクト自体がまわってる。 | ←このような感じになるためには、↑のように、すべての情報を理解してないとできないかもなあ。 | | 教育 | 入社してPM未経験 自分の中で矛盾なのが、若手に多いけど 細かくタスクをわたすと、タスクを消化することがゴール担ってしまう 長期的にみると、相手を当事者にさせる。
| PM未経験者の場合は、きちんとPMできる人がサポートして軌道修正してあげることが重要だね。
目の前のタスク消化に夢中になるかもしれないけど、最終的な目的を意識して、 そこに本当につながってるタスクなのかなあ、という観点で指摘してあげるとよいかも。 |
おまけ資料
こちらは、後日、HIDEブログにまとめますのでお待ち下さい〜