> For the complete documentation index, see [llms.txt](https://yutakatay.gitbook.io/katapedia/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yutakatay.gitbook.io/katapedia/doc/purojekutomanjimento.md). # プロジェクトマネージメント ## プロジェクトマネージメント プロジェクトマネージメントとは、組織の目的を実現するために、現状を評価、分析し、ゴール達成に向けて組織をリードすること マネージャーのアウトプット ＝ 自分の組織のアウトプット ＋ 自分の影響力が及ぶ隣接諸組織のアウトプット ## プロジェクトを成功させるもの ### 今 * シンプルさ * フィードバック * コミュニケーション * 勇気 * 尊重 ### 昔 * 管理 * 監視 * 制御 * 支配 * 評価 ## 管理とは * マネジメント（management） * コントロール（control） * アドミニストレーション（administration） ### 役職 * コミッター * コントリビューター * テスター * リリースマネージャ * ディレクター * スクラムマスター #### 各役割 * PM 決裁権限がある管理職、と見ておこう。 PMは大きなプロジェクトの、あるいは複数のプロジェクトの管理を行う役割を持っている。プロジェクトの予算管理、高いレベルの顧客との交渉を行う。 決済権を持ち、見積書提出、契約処理、請求処理、予算管理と部内での上司への報告なども行う。マネジメントすることが役割なので設計書を書いたりプログラミングを行うことはほとんど無いはず。 * PL 決裁権限はないもののそれに近い判断を行える立場とも言える。 PMの下についてプロジェクトの管理、メンバー管理を行う。予算管理を行い顧客との交渉なども幅広く行う。PLはSEと兼任している場合が多く、仕様書、設計書の作成にも携わる。場合によっては自分でプログラミングを行うケースもある。 ### プロジェクトが長引く理由 **余分な機能を詰め込む** 特に、ソフトウェア開発の現場ではこのような事が日常茶飯事となっています。これは、望む機能を実装する為に単純に「追加コードを作れば良い」といった考えに走ってしまうからです。 実際は、既に予定されている機能の組み合わせで実現出来る可能性も考慮する必要があります。 **作業完了を報告しない** 作業が完了したとしても、まだ期限に余裕がある場合は報告をせずに、時間稼ぎをして、期日になった時点で報告が行われます。 これは、早く終わった場合に次回も同様に早く終われると上司は考え、次の作業時間がかなり短く設定されるからです。 つまり、早く作業が終わったとしても、次のステップでそれが活かされる事がありません。 **作業の掛け持ち** 複数の作業を同時に行う場合、１つのステップを完了させる為に必要な期間は「平行作業を行うステップの合計」となります。 このような場合、３つのステップが終わらなければ次のステップは実行する事が出来ません。 **学生症候群** これは何かというと、皆さんも学生の頃テストが近づいてきたら必死に勉強した事はないでしょうか？ または、夏休みの最後の１週間から、必死に宿題を片付けた事はないでしょうか？ つまり、これは期間を設けている場合に、その期間の終わり間際になってようやく作業を開始する事を意味します。 会社では、月末になると「今月の売上目標がぁ！」と、いった行動に身に覚えのある方はいないでしょうか。 ### できない 1. 難易度が高い 2. 時間が足りない 3. 今実現するには機能不足 4. 他に問題が発生する 5. その機能、意味ない 6. めんどくさい ### 反発 #### 抵抗の6階層 1. 問題の存在に合意しない 2. ソリューションの方向性に合意しない 3. ソリューションが問題を解決できるとは思わない 4. ソリューションの実行でマイナスの影響が発生 5. ソリューションの実行を妨げる障害がある 6. その結果起こる未知のことへの恐怖 ### 人手不足 十分な人的リソースを確保するのが難しい情勢で、プロジェクトマネジャー（PM）が採り得る道は三つある。 1. 一つめは、小規模な体制でもプロジェクトを進めるための工夫を模索する道だ。要件の絞り込みといった地道な努力から開発手法の変革まで、様々な施策が考えられる。ただし入念な準備が必要で、手間と時間もかかる。 2. 二つめは、プロジェクトを凍結することだ。周りから批判を浴びるかもしれないし、苦労して確保した予算は水の泡となる。PMにとっては難しい判断となる。 3. 三つめは、プロジェクトを断行する道である。力技で人手を集めたり、“頑張り”という名の生産性向上策で人手不足を補う。入念な準備はいらず、難しい判断は必要ない。 ### ITマネージャーに必要な力 1. 掘り起こす力：真に実現したいことを会話などを通して明らかにしていく力 2. 突破する力：ビジネスに成果をもたらすIT企画を経営陣に理解・承認してもらう力 3. 捌（さば）く力：IT部門への要望の取捨選択や、IT部門として取り組む順番を見極める力 4. 仕切る力：企画やプロジェクトを進める際に実施する会議を仕切り、目的を達成する力 5. 付き合う力：社外の専門家や協力会社などと関係を築く力 6. 巻き込む力：様々な関係者から体制構築、情報提供、推進支援などの協力を獲得する力 7. 嗅ぎ分ける力：部下の成果物やベンダーの報告内容などからリスクを察知し、手を打つ力 8. 推し進める力：思いも寄らない事態が発生しても、企画やプロジェクトを遂行していく力 #### 場から危険を察知 開発現場が荒れている（書類が散乱している、メンバーが寝泊りしている、ゴミ箱からゴミがあふれている、など） 開発現場の会議室から怒鳴り声が聞こえてくるなど、雰囲気が殺伐としている 打ち合わせに入ってくるところから、メンバーが下を向いて自信なさげだ 説明が早口で、質問を受け付けたくないという態度を取る 進捗報告を各チームリーダーに依頼したところ、リーダーの欠席が続く 下位のメンバーに同じ質問をして、同じような回答が返ってくるか 上位クラス者に質問して、理解度を確認する #### 成果物から危険を察知 前後の脈略が合っていない 誤字脱字が多い 明らかに手抜きが感じられる スケジュールを勝手に変えてくる 課題の対応期日を毎回先送りする リスクが挙がってこない #### 人から危険を察知 話し方に自信がない（小声や早口で話す） 取り繕うような発言が多くなる（ごまかす） 話を聞いていて、前後の脈略が合っていない 余計なことを発言してボロが出る 会議に出席しなくなる #### 実行承認を得るために意識すべき三つのポイント 1. 金額の根拠を提示する 2. 決裁者の関心事を押さえる 3. 信頼できる実行体制を組む ### なぜマネージメントをやりたくないのか #### マネージャーの仕事がわからない系 * 仕事のイメージがわかない * マネージャーという職業にクリエイティビティはあるのか？ * マネージャーの仕事に意義を感じない * マネージャーの仕事が何の役に立っているか見えない * 多くのマネージャーはヘボい（ように見える） * マネージャーとしてのロールモデルがいない #### 面倒な仕事そう系 * 面倒ごとを引き受けることになるイメージ * 会社上層部との折衝が面倒 #### 楽しくなさそう系 * 給料がそんなに上がるわけでもなさそう * マネージャーやってて日々楽しそうな人そうそういないし、まあつまらない仕事なんだろう #### 開発していたい系 * 開発のほうが楽しい * 自分で作ってるという実感がなくなってしまうような気がしている * エンジニアリングって実は仕事じゃなくて趣味でやってるだけなんだけど、マネージメントは趣味にならなそう * 技術を追求できなくなる * 開発できなくなる日本企業の文化 * 自分自身がコード書いて、課題を解決していく達成感・快感を感じたい * 一番下っ端としてずっと開発してるの、責任最小化できて最高だな！ * 会議ばかりでコードが書けなくなるから * 打ち合わせばかりになる * 特定の会社に最適化されてしまいそう #### 人間との対話できない系 * 人間との対話はできないけど機械となら対話できるから * 人間との対話よりもコンピュータと対話する方が好きだから→コンピュータをマネジメントすればよいのでは * 人よりコンピューターに向かっていたい * コンピュータが人を管理すれば解決 #### その他 * 「マネージャーになる = 昇進」とは考えてないこともあって、あまり関心がない * コントロールされたくないのにコントロールしなきゃいけない風の矛盾 ### 進捗管理 #### ガントチャート ### 評価 #### プロダクトマネジメント * xxはプロダクトの本質的な課題を伝えている * xxはプロダクトの本質的な課題に対する解決策を伝えている * xxはプロダクトの優先順位、やること/やらないことを伝えている * xxはプロダクトを定量的に理解し、伝えている * xxはプロダクトを定性的に理解し、伝えている * xxはプロダクトの検証スピードを意識している * xxはプロダクトの品質向上を意識している * xxはプロダクトに対して長期的な投資を行っている * xxはプロダクトから得られたナレッジを蓄積し共有している * xxが示すプロダクトに納得感を持っている #### プロジェクトマネジメント * xxは優先事項である結果/成果物にチームが集中できるようにしている * xxは私/チームに権限や意思決定を移譲している * xxは私/チームに上層部からえた関連情報を定期的に共有している * xxはチームにリソースを十分配分している * xxはスケジュールを適切に設計、管理している * xxは必要なときに自らプロジェクトを進行している * xxが行うプロジェクトマネジメントに納得感を持っている #### ピープルマネジメント * xxは私の役割・目標を私に伝えている * xxは私の成果・能力を正しく評価している * xxは良いチーム・組織を作っている * xxは私/チームが成果をあげるための実行可能なフィードバックをしている * xxは私を1人の人間としてみて、敬意・思いやりをもって接している * xxは私と私のキャリア/成長にかかわる有意義な話し合いをしている * xxは私/チームの成功や満足度に関心や気遣いを示している * "xxは私/チームと円滑にコミュニケーションしている " * xxは私のワークライフバランスの管理を阻害していない * xxは職場を楽しく働きやすい環境にしている * 私は責任・やりがいを持って働けている * 私は私の給与に納得感を持っている * xxは私の性格や人間性を理解している * xxはオープンでフランクな態度を示している * 私はチームの一員として一体感をもって仕事をできている * チームメンバーは上下関係ではなく敬意をもって互いに接している * チームの意思決定は迅速で、さまざまな視点が検討されている * 私はxxのピープルマネジメントに納得感を持っている #### xx個人の能力 * xxは会社の状況を理解している * xxは私/チームにアドバイスできるだけの技術知識を持っている * xxは私/チームにアドバイスできるだけのデザイン知識を持っている * xxは私/チームにアドバイスできるだけのビジネス知識を持っている * xxは部署間連携を適切に行っている * xxはxxの上長と適切に連携している * xxはチームを超えた人たちを巻き込んでい仕事を進めている * xxは早い決断・大きな決断を行っている * xxは自身の能力向上を積極的に行っている * xxは採用活動を積極的に行っている * xxの考え方に違和感を持っているところはない * 私はxxを他の社員にもお勧めする ### 権限と責任 | レベル | 説明 | | --------- | ----------------------------------------------------------------------------------------------------------------------------------- | | 1 命令する | (上司が部下に) 命令する上司がすべてを決定して、部下に対してそれをするように命令するという権限のレベル。 この状態では、上司に全ての権限がある | | 2 説得する | (上司が部下に) 説得する上司が部下に対して「なぜそうするのか/どうしてやるのか」を説明し、説得します。 部下は、説明をよく理解し趣旨に合うように実施を行います | | 3 相談する | (上司が部下に) 相談する上司が行う提案を部下に対して相談します。 最終決定の前に、部下に意見を求めるという権限のレベル | | 4 合意 | (上司が部下と) 合意する上司と部下が合意をして初めて、その指示を遂行するようにします。 このレベルになる上司と部下の権限は同じレベル | | 5 助言してもらう | (上司が部下に) 助言する部下が提案を行います。 その提案に対して上司は、気になる点などを指摘します。 これは助言であって、命令ではありませんので、部下は全て聞き入れる必要はありません。 | | 6 尋ねられる | (上司が部下に) たずねる部下が決めたことを、上司が報告を求めた時だけ説明します。 報告を受けて意見を言うことはありますが決定権はメンバーにあります。 | | 7 委任してもらう | (上司が部下に) 委任する部下が上司の確認なしに実施をしてよい権限です。 上司がそのことについて尋ねた時のみ、回答します。 イレギュラーのない日常業務などは、この権限が部下に渡されていないと上司は確認作業を行わないといけなくなり、ボトルネックになるかもしれません |