プロジェクト型の働き方や、幅広いIT技術の浸透により、ますます重要性が高まっているプロジェクトマネジメント。
しかし、学ぼうと思っても範囲が広すぎてどこから手を付けていけばよいのかもわからず、それならいっそ全部やってしまえと思ったのが、この記事の始まりです。
そう思ってAmazonで『プロジェクトマネジメント』と検索してみると1000以上の候補が出てきます。
これではさすがにいくらお金と時間があっても足りません。
そこでKindle Unlimitedに限定して『プロジェクトマネジメント』で出てきた本を全て読むというのが私がやったことです。
その中でいくらかでも学びがあるのではないかと思った60冊を今回ご紹介します。
ちなみにKindle Unlimited登録まだの方は初月無料なのでまだの方は以下から登録できます。
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
また６０冊は多すぎるという方は「迷ったらこれを読め｜厳選7冊」へ飛んでください！
ご紹介するプロジェクトマネジメント本60冊は無料で読める
「プロジェクトマネジメント」で検索した８５冊を厳選して60冊とした
まずは以下をご覧ください。以下が私が作成した読書メモです。
上記の読書メモを元にこの記事ではプロジェクトマネジメントを学ぶのに役立つKindle Unlimited本60冊を紹介しています。
なぜプロジェクトマネジメントは学ぶのが難しいのか
本章ではプロジェクトマネジメントの学習の難しさについてご説明していきます。
具体的には以下の3項目でご説明します。
- PMBOKは膨大な知識体系
- 顧客との交渉やメンバーマネジメントなどの本では学べない知識
- 財務やマーケティングなどのビジネス知識も必要
PMBOKは膨大な知識体系
そもそもプロジェクトマネジメントは膨大な知識体系です。
有名なものにPMBOKがありますが、
PMBOKは10種類の知識エリア×5種類のプロジェクトライフサイクル×3つの実行パートの合計150分類からなる膨大な知識体系です。
知識エリア、プロジェクトライフサイクル、実行パートは図にすると以下のようになります。
全てを完ぺきに勉強しようとすると一朝一夕ではいかないのが難しさの理由の1つ目です。
顧客との交渉やメンバーマネジメントなどの経験から学ぶ知識がある
理由の2つ目は経験から学ぶ知識があることです。
PMBOK意外にも実際のプロジェクトでは、顧客との交渉やメンバーマネジメントなど、経験から来る知見が数多くあります。
これらをもし学ぶとするとPMBOKとは別に経験者の本を読んだり、お話を聞いたりするのが有効です。
財務やマーケティングなどのビジネス知識も必要
またプロジェクトを最適なゴールに導くための財務やマーケティングなどのビジネス知識も必要です。
プロジェクトの前提となる市場の状況や業界構造の理解、さらに業務に関する知識も求められる場合があります。
さらに企業の経営に対してこのプロジェクトがどういう効果を発揮するかという視点では、財務などの知識も必要となります。
こうした統合的な知識を学んで初めてプロジェクトマネジメントについて理解することができます。
プロジェクトマネジメントに関しては以下の記事でまとめています。
上記がプロジェクトマネジメントを学ぶのが難しい理由です。
それでは次項でプロジェクトマネジメントの本の分類について説明していきます。
カテゴリ分類は12種類
本記事でご紹介する書籍の分類は以下の12種類です。
| 本の分類名 | 分類の説明 |
|---|---|
| プロジェクト計画（7冊） | プロジェクトの前半戦の計画段階に必要な知識に関する書籍。PMBOK関連本などが多い。 |
| 要件定義（9冊） | プロジェクト計画の中でも特に難易度が高く、書籍も多いので切り出した。一般的な要件定義の流れの説明のほかに、交渉のようなソフトスキルに関する説明も多い。 |
| 顧客対応（3冊） | 交渉や顧客のマネジメント、顧客との会議の進め方や承認を得るまでの流れなど、実際のプロジェクトでは悩む方も多いところ。特にエンジニア出身だと最初は苦労する方も多い。 |
| メンバーマネジメント（12冊） | 複数のプロジェクトメンバーに対する接し方や、タスクの割り振り方、進捗管理の方法などに関する書籍が多い。内容に最も幅があったのがメンバーマネジメントの本。 |
| プロジェクト実行管理（8冊） | プロジェクト計画が出来たら、あとはそれを実行管理していくことになります。その際の管理の方法や、リスクの予見・対応に関する話が多いです。 |
| 契約（1冊） | プロジェクトの開始前に締結する開発契約に関する本の紹介です。とっつきにくいですがやると必ず将来に生きます。 |
| タスク管理（4冊） | プロジェクトマネジメント以外でも今や広く行われているタスク管理。書籍も多いので独立した分類とさせていただきました。どちらかと言えば他のPM本よりは読みやすい本が多い印象。 |
| 仕事術（5冊） | タスク管理とも近いですが、もう少し広く、抽象的な仕事の効率化に関する書籍をまとめました。PM学習以外でも役立つ本は多いです。 |
| ビジネス知識（5冊） | プロジェクトマネジメントを行う際に必要となる周辺ビジネス知識をまとめました。これらはいずれ学ぶことになるものも多いでしょうし一度目を通してみてもよいかもしれません。 |
| 考え方（2冊） | プロジェクトマネージャーの考え方や心構えが分かる本たちの分類です。 |
| 読み物（4冊） | プロジェクトマネジメントに関連する物語や読み物です。疲れた時の息抜きなんかに良いかもしれません。 |
図にすると以下のようになります。
それぞれの本の紹介は評価・読書メモ・説明で構成
最後に各本の紹介は以下の構成で進めていきます。
| その本の評価 | おすすめ度と読みやすさを5段階で評価しています。 |
| 読書メモ | 私が実際に読んでいた時のメモを書いています。 |
| 説明 | 読書メモを踏まえて説明を加えています。 |
それではいきましょう。
【プロジェクト計画】プロジェクト計画の作り方が分かる本6冊
- 目指せPMP PMBOK第5版対応: 最速でPMPに合格するための解説書
- 意外と知らない・誰も教えてくれない PMのぷちテクニック〜スマホに入れておきたい10の裏技〜episode1
- システム開発現場のプロジェクトマネジメント教科書2016年電子書籍版
- 図解超入門 3分でわかるITパスポート試験対策教科書 プロジェクト・リーダーを目指すITエンジニアの極意のすべて
- IT戦略論 図解 IT戦略マネジメント＆ITシステム設計入門：グローバル競争優位のIT戦略アプローチ
- 「戦略実行力」強化の公式: マネジメント体系に学ぶやりきる組織の仕組み
- アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす
→この章を読み飛ばす（次の章：【要件定義】要件定義に迷いがなくなるために読む本9冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
目指せPMP PMBOK
評価
- 読みやすさ：☆☆☆☆☆
- おすすめ度：★★★★★
読書メモ
- プロジェクトライフサイクル｜プロジェクトは5つのサイクルで構成されている
- 立ち上げ
- 計画
- 実行
- 監視コントロール
- 終結
- プロジェクトマネジメントには８種のマネジメントが存在する
- 統合マネジメント
- スコープマネジメント
- タイムマネジメント
- コストマネジメント
- 品質マネジメント
- 人的資源マネジメント
- コミュニケーションマネジメント
- リスクマネジメント
- 調達マネジメント
- ステークホルダーマネジメント
- プロジェクト憲章はビジネス上の目標設定
- プロジェクトマネジメント計画はプロジェクトの管理計画
- プロジェクト計画はプロジェクトで何をするかの実行計画
本書の説明
計画書の書き方はこの本に集約されています。
プロジェクトマネジメントの知識体系PMBOK関連の本で一番整理されていました。実業務ではここまで詳しく作成する場合ばかりではありませんが、知っているのと知らないのとでは大違い。必ず押さえておきたい知識です。
意外と知らない・誰も教えてくれない PMのぷちテクニック
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- パートナー向けの業務仕様説明会やQA解決会を開く
- 提携フォーマットと報告ルールを作成する
- 要件の優先順位を明確にする
- 成果物をタスクの順で定義する（作業WBS＆成果物WBS）
- タスクは5W1Hで定義する
- 要件を定義することではなく要件を理解することをゴールにする
- プロジェクトの前提条件、制約条件、想定リスクのすり合わせを行う
- 部署間の力関係の把握とネゴ相手の選定、事前情報収集を行う
説明
ポイントは作業WBSと成果物WBSがあることです。タスクのとらえ方を分かりやすく解説してくれています。そのほかにも一般的なPMの知識としては出てこないが、業務上行うことを説明してくれています（業務仕様説明会やQA、部署間の力関係と交渉など）。計画分野の本にしては読みやすいです。
ポチップ
システム開発現場のプロジェクトマネジメント教科書
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- プロジェクトマネジメントプロセス｜立ち上げ、計画、実行、監視コントロール、終結
- プロセス資産のフォーマットが必要ではないか
- プロジェクトマネジメント計画書とは管理・監視の計画
- プロジェクト計画はスケジュール、費用、人的資源の計画のこと
- システム開発におけるWBSは製品＞機能＞時系列＞成果物と分割していくとやりやすい
- PERT図でCCPを明らかにする
- リーダーシップ｜PM理論、SL理論
- リスクの予測には根拠や事実を捕まえることが大切
説明
WBSを製品＞機能＞時系列＞成果物と落とし込むのはぜひ覚えてほしい点。
一般のツールを使うと親子課題やカテゴリの分類は出来るが、その分割の仕方やグルーピングに関してはあまり知られていないのではないでしょうか。
そして感覚で作成したWBSはプロジェクトが進むにつれてどこかでロジックが破綻してしまい、結局ツールを使いこなせないという話もよく聞きます。必ずしも上記の方法が当てはまるとは限りませんが、分割やグルーピングの指標を知っておくことでMECEなWBS作成の一助になるでしょう。ひいては各メンバーが自身のタスクをしっかりと把握して迷わず進めてくれるようになるでしょう。
プロジェクト・リーダーを目指すITエンジニアの極意のすべて
評価
- 読みやすさ：★☆☆☆☆
- おすすめ度：★★★★☆
読書メモ
- ビジネスプロセスの思考
- コンピュータの機能｜入力、記憶、演算、制御、出力
- 製造分野のIT化｜POP（バーコード管理）⇒CAD（図面のデータ化）⇒CAM（加工制御）⇒CAE（シミュレーション）⇒CIM（生産システム）⇒FA（工場全体の自動化）⇒FMS（多品種少量生産）⇒PDM（部門横断管理システム）
- 流通分野のIT｜POS（販売管理）⇒EOS（発注管理）⇒決済（クレジット、プリペイド、デビット、ポイント）
- IT投資評価を行う
- 基本計画｜システム化計画、プロジェクト実行計画、要求定義
説明
顧客とプロジェクトを行ったことがある人ならわかると思いますが、顧客との議論や合意獲得にはビジネスプロセスの考え方が必ず必要です。プロジェクトマネージャーの仕事はビジネスプロセスからシステムプロセスに変換することです。つまりPMの仕事は、ビジネスの目標を達成するために、システムなどの成果物を、期限内に作成するプロジェクトをゴールまで導くことです。そしてこの本が伝えているのはまさにビジネス⇒システムについての話です。
ポチップ
グローバル競争優位のIT戦略アプローチ
評価
- 読みやすさ：☆☆☆☆☆
- おすすめ度：★★★☆☆
読書メモ
- 市場のニーズ、クライアント企業のニーズ、世の中の潮流、コアコンピタンス、目標と狙い、実行策、実績分析・評価
- システムの開発規模を表す項目｜画面、帳票、端末、プログラム、ステップ数、開発工数
- ERPは定型業務が対象
- 外部環境評価軸｜事業環境変化対応レベル、競争優位対応レベル、利害関係者参加レベル
- 内部環境評価軸｜ビジネスモデル創造レベル、再構築レベル、業務改革レベル、経営資源変化対応レベル、組織変化対応レベル、企業文化・風土対応レベル、オペレーションプロセス影響レベル
- 技術評価軸｜システムれ系レベル、既存システム影響レベル、技術難易度、技術革新、要求スキルノウハウレベル、業界標準化レベル
- 顧客視点評価軸｜要件規模レベル（コスト）、必要要因規模レベル（コスト・納期）、予算規模レベル（コスト）、要求ソリューションレベル（品質）
- IT活用｜品質、コスト、インターフェース、スピード
- ITプロジェクト推進のC5R5M｜
- Customer&Relationship management｜顧客との関係性構築
- Collaboration management｜協働作業の仕組化
- Communication Management｜情報コントロールの仕組み
- Competition management｜競合との差別化
- Cost management｜IT投資のROI
- Risk management｜リスク対応
- Request management｜顧客の情報ニーズ
- Resource management｜経営資源のIT投資
- Redesign management, ｜ビジネスモデルやバリューチェーンの再構築
- Regal management｜法や特許、知的財産などの管理
- クリアにすべき必須項目｜推進上の課題、狙い、開発要員、運用要員、ハードウェア、ソフトウェア、仕組み、投資額・効果、体制、納期・期間
- 提案時は短期・中期・長期の軸で用意する
- PDPC法｜対策を図解する手法
- 企業活動のモデル化｜縦軸（コスト、リソース、コーポレートカルチャー、リスク）、横軸（ナレッジ、CRM、プロセス、バリューチェーン）
説明
ビジネス視点からＩＴシステムとは何かを話している本。特にIＴプロジェクト推進のC5R5Mは知っておくべき項目群。
ポチップ
「戦略実行力」強化の公式
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★★☆☆☆
読書メモ
- リーダーシップとは戦略を示す責任
- マネジメントとは実行責任
- 実行マネジメントは成果物を目指すプロジェクト、成果物から価値創出を目指すプログラム、それらを構成する施策群を管理するポートフォリオ
- ガバナンスの活動は監督、制御、統合、判断
- 監督は仕組みづくり
- 制御は仕組みを動かす
- 統合とは施策間の共通目標への統合
- 判断は意思決定の推進
説明
成果物と価値、施策の違いについて知りたければこの本を読みましょう。プロジェクトマネジメントのより上位概念のプログラムやポートフォリオについて学べます。プロジェクトって結局何？と思ったら答えてくれる本です。
ポチップ
アジャイルCCPM
評価
- 読みやすさ：★☆☆☆☆
- おすすめ度：★☆☆☆☆
読書メモ
- ODSCからバックワードでタスクを設定する
- タスクは名刺＋動詞で定義する
- タスクのリソース割り当てはスキル（計画フェーズ）⇒人（実行フェーズ）の順で割り当てる
- 合流バッファということは休みとなってもよいのでは
説明
昔からの開発手法であるウォーターフォール型に対して、近年よく使われるのがアジャイル型と呼ばれるものです。
また、プロジェクトマネジメントの考え方の一つでCCPM（Critical Chain Path Management：クリティカルチェーンパスマネジメント）というものがあります。CCPMとは最大の工数がかかるタスクの経路がプロジェクト全体の進捗を決めるという考え方です。その最大経路を短縮し、遅延なく進めることを重要視します。
そしてこの本はアジャイルの柔軟な開発手法にCCPMを取り入れた新手法が説明されています。色々な手法に興味がある人にはおすすめですが、プロジェクトマネジメントを学んでいるタイミングよりはもう少し後のフェーズで読むべき本の印象です。
ポチップ
【要件定義】要件定義に迷いがなくなるために読む本9冊
- 最短で達成する 全体最適のプロジェクトマネジメント
- 要件定義トラブルの予防と対策１３６: 要件定義フェーズでよくある問題の予防と事後対応策がわかる！
- プロジェクトを成功に導く 要求定義: プロジェクトマネジメント・ビジネスアナリスト
- プロセスデザインアプローチ 誰も教えてくれない「プロジェクトマネジメント」
- 要件定義のヒアリングリスト４２７: 要件定義フェーズで、今、何を確認すべきかが、具体的にわかる！
- 予定通り進まないプロジェクトの進め方
- 失敗事例から学ぶプロジェクトマネジメント
- 要件定義実践のポイント: 曖昧さと不確実性を仕様化する！
- 逆算思考: NUCBビジネススクールの「ケースライティング」で会得した最強の思考法
→この章を読み飛ばす（次の章：【顧客対応】顧客の対応に困らなくなるために読みたい本3冊に飛ぶ）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
全体最適のプロジェクトマネジメント
評価
- 読みやすさ：★★★★☆
- おすすめ度：★★★★★
読書メモ
- 順番を決めてシングルタスクで上から処理していく
- 人間バッファはダメ
- 抵抗は6ステップで緩和していく（抵抗の6段階：問題と認識していない、解決方法に合意していない、解決方法の効果に疑問、ネガティブな問題発生を示唆している、実現可能性が低いと感じている、未知との遭遇）
- 経営の視点でどういう評価項目で優先順位をつけるか
- 記号で優先順位を検討する
- 許認可待ちの時間を減らす
- プロジェクトの目標はODSCで定義する（目的、成果物、成功基準）
- 定性基準には「…と言う」「…と言わせる」を活用する
- 人は成功する過程で成長を実感したときに興奮する
- 3つの質問でWBSを作る（その前にやることはなんですか？本当にそれだけですか？○○したら××できるんですね？）
- バッファなしタスクの工数は「邪魔が入らず一つの作業に集中してトラブルなく終えた場合の工数」
- バッファはぎりぎりタスク工数の半分
- 大企業でも工程表は10個程度
- 進捗は残り日数で換算する
- 問題を検知するには「問題があるとしたら何ですか？」と聞く
- 相手に考えさせるには「何か助けられることはないですか？」
- 遅延が発生した場合には「何を待っていましたか？」
説明
この本でぜひ把握してほしいのは抵抗を6ステップで緩和していく方法と、定性的な品質基準の立て方です。どちらもほかの本には書いていない内容でありながら、実際にはよく使うものなのでぜひご確認ください。
要件定義トラブルの予防と対策１３６
評価
- 読みやすさ：★☆☆☆☆
- おすすめ度：★★★★★
読書メモ
- そもそも要件を聞き出すのは間違い。顧客と作り上げる作業
- 要件定義の遅延は３０人日に当たる場合もある
- 言語外の情報を想像することが最重要
- 知的労働は急ぐことができないと理解する
- 本人のコミットのない残業は無意味
- PMは予防に全力を尽くす
- 見積時点で前提条件をはっきりさせておかなければならない
- 前提条件｜開発条件、導入条件、検収条件、運用条件、保守条件
- 仕様とは｜基本アーキテクチャ、ハードウェア使用 技術 、技術、パッケージ （カスタマイズ量）、情報、 プロダクト、マイルストン、外部システムとの連携、機能数、画面数、帳票数、テーブル数、データ量、トランザクション量など
- 機能の重要度順、タスクの独立性、担当者、コミュニケーション
- 不可能なことに関しては根気強く顧客に説明し続けることがPMの仕事
- 統率されていない仕様変更は無条件に禁止する
- あればよい機能は不要
- 現状で明確化されている業務のみをシステム化すること
- 業務のシステム化はコンピュータの得手不得手と照らし合わせて判断すること
- 新しいことや情報活用をするためのシステムは要件が膨張しやすい
- 要件が膨張しにくいシステムは省力化、効率化、標準化が目的
- 現行のビジネス価値と将来のビジネス価値を切り分ける
- 費用対効果と開発リスクを検討する
- ステークホルダー（経営、開発、ユーザー、保守）の視点を分けて考える
- 変更管理プロセスの明確化（個別カスタマイズ）と説明を必ず行う
- 顧客への確認する際は何を検証してほしいかを明確にしなければならない
- リーダーはサポート役に回るべき
- メンバーのドキュメント作業は極力減らすべき（タイミングを意識して指示すべき）
- 待ち時間のほうが多いメンバーがいないようにしなければならない
- 追加の変更要求の取り扱いをあいまいなままにしておくと際限なく発生する
- 追加要求変更の対応前に作業一覧を顧客に見せる
- 結局、どんなシステムが必要かではなく、ユーザーに何をさせたいのか、何をさせたくないのかを明確にすべし
- 追加に関してはメンバーの了承を得るように働きかけること
- 事実は客観的であり価値は主観的
説明
まず要件定義の原則です。顧客と作り上げるものであることを強く認識しておきましょう。
ベンダーから一方的に提案するものでもなければ、クライアントから押し付けられるものでもありません。
要求ヒアリングなどの活動を通して、クライアントとベンダー双方の観点から要件を浮き彫りにしていく作業こそが要件定義です。ほかにはタスクの独立性に関しても押さえておきましょう。
ポチップ
プロジェクトを成功に導く 要求定義
評価
- 読みやすさ：☆☆☆☆☆
- おすすめ度：★★★★☆
読書メモ
- ドキュメント｜プロジェクト憲章、ビジョンとスコープレポート、ビジネスケース、要求作業計画、ビジネス要求文書、ベンダー要求文書（RFx）、ビジネス契約文書
- 要求分析とは作業分析とユーザー分析が必要（１次ユーザーと２次ユーザーがいる）
- 影響力と影響度で分析する
- ビジネス要求文書の構成｜更新ログ、用語解説、対象者、ビジネス要求文書の決定と商人プロセス、スコープ・目的・ベネフィット概要、背景・経緯・以前のプロジェクトの情報、アプローチ、規制上の要求、ビジネスレベル要求、ユーザープロファイルと権限委譲、ステークホルダー要求、機能要求、非機能要求、前提条件・依存条件・制約条件、リスクと管理プロセス、システム・解決策の選択肢、変更管理プロセス、付録、承認セクション
説明
要件定義の前フェーズの要求の収集～分析に関する本です。要求分析は作業分析とユーザー分析があります。１次ユーザーと２次ユーザーがいるのでそれぞれに対して影響を分析する必要もあります。
ポチップ
プロセスデザインアプローチ
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★★★★☆
読書メモ
- プロジェクトの進め方（プロセス）で成否が決まる
- プロジェクトごとにルート設計が必要
- プロセスフローダイアグラムで共通認識を確立する
- CMM/CMMI（能力成熟度モデル）
- エンジニアリングとプロジェクトマネジメントが連携していなければならない
- ベンダーはクライアントの要求の言語化を行う
- ソフトウェアエンジニアの生産性は数十倍ある
- 経営層のコミットメントがなければ必ず失敗する
- 構想段階ではコミュニケーションを惜しまない
- プロジェクトには目的がある
- 戦略ープロジェクトープロセスの一貫性を維持する
- エスカレーションは何より早急に対処する
- 常にプロジェクトの状態を説明できるようにしておく
- プロジェクトの要求を咀嚼しゴールまでどうやってたどり着くかを考える
- クライアント側のPMは業務部門の人にすべき
- PM同士の関係性が最重要
- 営業をうまく使う
- 問題が多ければコミュニケーションプロセスの見直しを行う
- ゴールにどうやってたどり着くかを説明でき料にする
- 共通認識が持てなければ失敗する
- わかるところまで計画して分かった段階で詳細に計画するを繰り返す
- 顧客ロードマップ｜目的は何か⇒誰に聞くか⇒何を聞くのか⇒誰が聞くか⇒顧客に聞く⇒情報を整理する⇒スコープに組み込む
- 6Rフレームワーク｜状況⇒問題意識⇒要求⇒意図・裏付け・仮説、今回のスコープ、期待する成果
- WBSでは子の要素を足すと親の要素に等しくなる
- 上位目的、スコープ、成果で考える
- プロジェクトライフサイクル｜要求定義、要求分析、基本設計、詳細設計、実装、システムテスト、受入テスト、運用保守
- 目的が曖昧であればシステム化構想フェーズを設ける
- 必ず各フェーズごと完結するようにする
- 完了基準を設ける
- 課題が顕在化した問題であり、リスクが潜在的な問題
- 計画の目的は実効性の検証、ネクストアクションへの迷いを無くす、コミュニケーション基盤を作る
- WBSには成果物WBSと作業WBSが存在する
- プロセスは実行可能なタスクの集合
- タスクの関連性の検証にはプロセスフローダイアグラムを用いる
- PFDの構成要素｜インプット、アウトプット、成果物、プロセス
- 積み上げではなく逆算
- FASTダイアグラム
- PDFはインプットとアウトプットのないプロセスは存在しない
- PDFはプロセス同士、成果物同士がつながることはない
- 無形の成果物に着目する
- 進捗を％で判断せずに必要に応じてコントロールする
- バッファはまとめる
- 改善は現行プロセスを知ることから始める
本書の説明
名前の通りプロセスの設計に関する内容の本です。プロジェクトの手順やメンバー、顧客にどう動いてもらえばよいか悩んでいる方におススメです。
ぜひともご記憶いただきたい2つのポイントがあります。
1つ目は問題が多発している場合はコミュニケーションプロセスの見直しを行うこと。
2つ目は顧客に対する対応のロードマップです。
顧客ロードマップ｜目的は何か⇒誰に聞くか⇒何を聞くのか⇒誰が聞くか⇒顧客に聞く⇒情報を整理する⇒スコープに組み込む。
問題が発生している場合は事前の情報が拾えてない場合が多いです。そのためのコミュニケーションプロセスの改善です。また顧客へのヒアリング前にここまで準備をしていくと、必要な情報を相手の負担を少なく集めることができます。
ポチップ
要件定義のヒアリングリスト４２７
評価
- 読みやすさ：★☆☆☆☆
- おすすめ度：★★★★☆
読書メモ
- まず必要な要求はすべて文字にする
- 何を知らないかも大切な情報
- 初めての業界の場合は95%を捨てるくらいの気持ちでとにかく情報量を集める
- ヒアリング準備作業｜前回ヒアリングの見直し・復習⇒質問リストの作成⇒質問リストのレビュー⇒説明次項・説得次項の検討⇒ヒアリングシナリオの作成⇒参加メンバーへの通知
- ヒアリング作業｜目的の説明⇒前回内容の確認⇒自発的な要求のヒアリング⇒顧客への質問⇒要求の整理⇒要求の分類
- 要求の性能などの漏れがないかを確認する
- 要求同士の関連から前提条件や制約条件がないかを確認する
- レビューは個人ごとにテーマを絞って行う
- レビュー内容を元に開発の可否を判断していく
- その後新たな要求を考案する作業を行う
- 要求のテストが可能なことを確認する
- 顧客に過去のSIerとのトラブルを聞いておく
- システム開発について顧客に理解してもらう必要がある
- 顧客への説明で伝わらない場合には言い換えをしてみる
- 顧客は当たり前すぎる要求を忘れている
- 要求仕様書はシステムは何をするか、設計書はシステムをどのように作るか
- 設計は要求と紐づいている（通し番号での管理など）
- ヒアリング会議、個別インタビュー、業務観察のスケジューリングを行う
- 顧客サイドに対しても課題認識が8割？
- 開発依頼理由を確認しておくようにしましょう
- プロジェクト参加者とヒアリング難易度を聞いておく
- 問題とそれによるコストを明確にする
- システムの使用期間イメージはどれくらいか
- QCDのバランスを確認しておく
- システム導入前後の変化について対象を絞って確認していく
- 繰り返し作業やスピードについても確認する
- 事業の目的⇒システムの目的⇒機能の目的
- 機能の利用シーン、ユーザーを確認する
- 機能の条件（前提や関連）を確認する
- 非機能要求には機能の品質属性の他に運用や保守・拡張に関する要求やセキュリティに関する要求がありる
- UIは非機能要件に属する
- 最初にどの機能を実装するかは非常に大きな問題である
- 設計チームに引き渡す前に全要求を見直す
- 要求の一貫性が最重要
- 要求の重要度と優先度の違いを明確にする
本書の説明
要件定義を行うためのルールや行動を明確にしてくれている本です。
ここでは特に2点ご紹介します。
1つ目は初めての業界の場合は95％を捨てるくらいの気持ちでとにかく情報を集めることです。要求ヒアリングの際は業界や組織に対する情報が圧倒的に不足しております。まずはとにかく情報を集める、情報に触れられる場所に行きます。
2つ目は要求同士の関連性を考慮することです。この原則を理解していないと仕様変更時に安請け合いした変更が実はシステムに大きな影響を与えたりします。メモだけでもかなりの量になっている本書ですが、要件定義に関しては網羅されているのでお勧めです。
ポチップ
予定通り進まないプロジェクトの進め方
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- ルーティンワークが減っている
- 要望、要求、要件、仕様、設計のどれに位置するかを把握せよ
- 依頼側は要望、要求、要件を行う
- 何を順守しようとしているかと現状、課題の確認
- パッケージの導入にはフィット&ギャップ分析を行う
- プ譜｜勝利条件、廟算八要素、中間目的、施策、事象
- 要素｜メンバー、予算、納期、クオリティ、ビジネスモデル、環境、競合、外的
- シナリオにして共有化力を高める
説明
要件定義の中でも手順を整理して説明しているのがこの本です。「要望、要求、要件、仕様、設計のどれに位置するかを把握せよ」など具体的な言葉とセットで説明してくれています。
失敗事例から学ぶプロジェクトマネジメント
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- 機能を分割し優先順位付けを行う
- 要望の受け入れ度合いを決めておく
- 顧客側に担当者を置いていない（常時体制が必要）
- 設計規約を作る
- 監視・管理は徹底するところまでが仕事
- プロパーと外部の割合を保つ
- メンバー間や下請け間でのコミュニケーション活性化も必要
- プロジェクト憲章を作成する（全容、スコープ、課題、制約条件、仮説、WBSなどの合意）
説明
機能要件の定義はされていると思いますが、その中で優先順位が明確な場合ばかりではないと思います。
この本では機能の優先順位を明らかにしたうえで柔軟にプロジェクトを進めていくことが書かれています。そのほかにも失敗を防ぐ方法が書かれているので確認としてさらっと読んでみてもよいでしょう。
要件定義実践のポイント
評価
- 読みやすさ：☆☆☆☆☆
- おすすめ度：★★★★☆
読書メモ
- 問いの定義が大切
- 問いの解は変わり続けるがそれでも変わらない問いが大切
- 要求の質を上げることが要件定義やマネジメントの質が決まる
- 顧客の要求が常に変化し続けることを前提とした顧客対応プランを練る
- 顧客の言葉ではなく真意や背景を読み取る
- 顧客同士に解釈のずれを確認する
- 選択肢を狭める質問を避ける
- 例外は仮説シーンでヒアリングする
- リスク管理のリソース配分を考える
- リスクの一例は導入フェーズでの現場からの追加
- 顧客経営層はシステム開発の投資に対する説明責任がある
- 顧客の過去の失敗を教えてもらう
- 避けたいことを顧客からヒアリングする
- 回答期限の設定とそのリスクの検討を行う
- 結局エンドユーザーが大切（接点、要望、協力）
- インフォーマルな体制図の把握に工数を使うこと
- 要求チェックプロセスを顧客内部で構築してもらう
- ヒアリング対象者に意見がある程度システムに実装されることを伝える
- 交渉すべき人と納得してもらう人がいる
- 顧客のゴールと自社のゴールを設定すること
- メンバーにリスクのヒアリングをしてマネジメントが判断する
- 目的⇒スコープ⇒QCD
- スコープの変更を前提とした準備や推進体制を整えること
- 顧客の無謀な追加要求にはスケジュールと工数と品質で突き返す
- 元の要求からの変更率を測定する
- 要求同士の矛盾がないかを確認する
- 厳しいPJTでは機能の段階的リリースを検討する
- リソース投下でカバーできる限界を知っておくこと
- 機能の重要度によって割り振りが変わってくる
- 品質の中で顧客の重要視しているものを把握しておくこと
- 品質基準を明確にしてグルーピングしておくこと
- 大規模プロジェクトではドキュメンテーションが40%を閉めることも
- ビジネス要件｜機能要件、ユーザ インターフェース要件
- システム要件｜基本アーキテクチャ要件、ハードウェア要件
- 性能や運用の条件
- 明確な要求は分解する
本書の説明
現実には出てくる無茶な要求に対する交渉など、顧客との関わり方から要件定義をする方法が記載されている本です。
ビジネス要件とシステム要件の違いは把握しておきましょう。また「明確な要求は分割する」と書かれています。一般的には明確な言葉に落とし込んだ方が良い印象がありますが、実際には適切に分割しておかなければ開発フェーズで問題が発生します。
「ケースライティング」で会得した最強の思考法
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★☆☆☆☆
読書メモ
- ゴールまでの逆算でタスクを分割する
- それらのタスクを分割して個別に具体化する
- 具体化したタスクを積み上げて最終成果物までの道筋を明らかにする
説明
この本で覚えておいていただきたいのが「具体化したタスクを積み上げて最終成果物までの道筋を明らかにする」です。WBSの大原則でありながらなかなか実行するのは難しくもあります。今一度改めて記憶しておきましょう。
ポチップ
【顧客対応】顧客の対応に困らなくなるために読みたい本3冊
- プロジェクトマネジャー１年目の教科書: 「昇進したら無能になった」とならないための、エンジニアのための顧客対応の指南書
- ビジネス大学30分 プロジェクトマネジメント
- プロジェクトマネジメント〜軍事学からのアプローチ〜
→この章を読み飛ばす（次の章：【メンバーマネジメント】メンバーマネジメントに悩んでいる人に読んで欲しい本12冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
プロジェクトマネジャー１年目の教科書
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★★
読書メモ
- システムは効率化から効果へ
- マニュアルマネジメントの限界
- 顧客上司に通すときにマネージャーがどう判断するかを聞く
- 顧客の参加度を上げる
- 絶対に飲んではいけないときは2時間黙る
- 上層部へは経営と紐づけて話す
- 粗探しには相手にそのアクションに対する意図やアクションを逆質問する
- 上司を連れてくるなどの対策で攻め込ませない
- 忙しくてもトップが決済の場合もあるので注意
- 顧客の説得にはベンダじゃないと気づかなかったという話にする
- 顧客へは同じ話を繰り返し冷静に行う
- 顧客に動いてもらうために怒るなどすべての手を尽くす
- 顧客の聞いたと理解したは違う
- プロジェクト計画書は指針であり、電車道ではない
- ワンマンには気づいてもらう
- あるべきと現実を整理する
- 顧客の意思決定構造を上下左右含め整理する
- 必要かもしれない情報はすべて共有する
- 営業との役割分担
- やらないことを定義する。機能の基準を明確にする（達成数値など）
- 突っ込みが多い顧客にはあえてポイントを用意する
- 顧客のプレゼン判断基準を知っておく
- 提案を却下されたら見た目を変えて再提案する
- 顧客との争点を明らかにする
- 顧客の要望には出来ない理由とその影響範囲や対応策をセット
- 交渉前に社内で基準を3つ決めておく
- 顧客の心配は原因究明をしっかりと行う
- 顧客へのアピールはしっかりと行う
- 担当が承諾しない場合、上司に納得できるサポートをする
- ステークホルダー個人の目的は突っ込まず対応策を相談する
- ベンダが要件の取捨選択基準を破らない
- 全体像を理解するためにはとにかく質問する
- 最初の打ち手は必ず失敗する
説明
SEやプログラマー出身だと経験しない顧客対応にプロジェクトマネージャーになったら苦労するポイントを解説してくれている本です。特にポイントとしては顧客へは繰り返し同じ説明を何度もすることや顧客に動いてもらうことは難しいので全ての手を尽くす点です。技術力がある人ほど陥りやすい点を解説してくれているのでエンジニア出身でマネジメントサイドに進みたい人にはおススメの1冊です。
ポチップ
ビジネス大学30分 プロジェクトマネジメント
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★★★★☆
読書メモ
- プロジェクトマネジメントはプロセスマネジメントと顧客接点マネジメントと組織マネジメントに分割される
- プロセスマネジメントはプロジェクト遂行のテクニック
- 顧客接点マネジメントはステークホルダーとのかかわり方
- 組織マネジメントは社内のマネジメント
- プロジェクトリーダーは予見に基づいてプロジェクトを滞りなく進行させる役目の人間
- プロジェクトマネージャーは顧客との納期や追加費用の調整や社内の調整＆リソースの調達など
- プロジェクトスタート時点ですでに成功・失敗は決まっている
- ソフトウェア開発の一般的な工程｜契約⇒要件定義⇒設計⇒製造⇒テスト
- 本書の工程｜契約準備⇒契約⇒上流工程⇒下流工程
- 顧客の要望を調整してもらうしかデスマーチを解決する方法はない
- 契約段階での確認事項｜成果物、開発範囲、役割分担、スケジュールの融通性、開発方法の制限・制約、保守・運用
- プロジェクトは顧客との共同作業であり顧客の能力には相当な注意が必要
- 上流は準委任、下流は請負の方がリスクが少ない
- 契約は要件準委任、詳細設計～ソフトウェアテスト請負、テスト準委任、保守準委任とすべし
- 実施計画書は契約前に作成する
- 実施計画書項目｜目的、成果物、受注範囲、制約・前提条件、マスタースケジュール、体制・役割、推進ルール、承認・変更ルール、変更履歴
- 顧客・ベンダー双方がルールに従うことが重要
- PMに課題を簡単に報告できるような体制にする
- なれ合いが身を亡ぼすこともあるので必ず変更ルールは決めておく
- 発注目的と発注動機を理解する｜費用削減、付加価値の追加、発注するしかない義務型
- 外部委託の理由はノウハウやマンパワーの不足かコストメリット
- 業界追従のパッケージの提案かオリジナルの開発か
- 役割分担の例｜お披露目は顧客がやるが資料やデモの準備は受注側などの状況を防ぐ
- 必ずステアリングコミッティの体制を整えておく
- ヒアリングのために必要なら常駐も検討せよ
- 定例は多忙な参加者のスケジュールを事前に抑える意味で必要
- 議事録の徹底化と顔合わせ
- 議事録は結論とその理由、その他の未決定事項を記載する
- メンバーの仮アサインや人材リソース調達の権限をPMに持たせる
- とにかく有言であれ（不実行でも構わない）
- プロジェクトの課題を会社として解決していかなければなくなることはない
- ホーソン実験は自己重要感
- プロジェクト目標とストレッチ目標を設定する
- 失敗プロジェクトへの配慮を欠かさない
説明
プロジェクトの流れに合わせて顧客と握っておくべき情報を記載しております。特に顧客との打ち合わせに関する情報はこの本で学ぶのがおすすめです。ステアリングコミッティと定例会に関するルール決めについてなどほかの本では触れていない情報も多かったです。
プロジェクトマネジメント〜軍事学からのアプローチ〜
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★★★☆☆
読書メモ
- 背水の陣とは背後の不安を取り除くこと
- プロジェクトは予算が最優先（上が決めるから）
- 直接確認する（1次情報）
- キックオフでは調査、前提条件、想定、成功イメージを語る
- 階級が混在するMTGは回避する
- 戦線を拡大しすぎない（チェックを厳しくしすぎない）
- 仕様変更はコミュニケーションに時間を使う
- バグはテストを繰り返すしかないが無くならない
- ハードルを提示したうえで前向きな発言をする
説明
プロジェクトマネジメントを軍事学から考えている本です。抑えてほしいポイントとしては、仕様変更の際にコミュニケーションに時間を使うという点です。現場でもよくあるシーンでありながらよく問題発生するのが仕様変更なので覚えておきましょう。
【メンバーマネジメント】メンバーマネジメントに悩んでいる人に読んで欲しい本12冊
- ３分間コーチ ひとりでも部下のいる人のための世界一シンプルなマネジメント術
- 草食系部下を戦力化する！マネジメントの極意【新装版】: 部下から慕われるリーダーになる51のステップ。
- 大工の棟梁に学ぶプロジェクトマネジメント
- マジビジプロ 図解とマンガでわかる リーダーになったら最初に読む プロジェクトを成功させる技術！
- ポンコツ上司が頼られ上司になったリーダー術: 組織を殺さずに活かす「チームワーク構築」【リーダシップ】【組織論】
- 1日15分で人生が変わる！人生プロジェクト管理術
- 管理者のための人材特性とマネジメント手法
- プロジェクトマネジメント技術 ビジネス･コンサルティング技術シリーズ
- ゼロから成功を引き寄せるMVPマネージメント
- プロジェクトマネジメントなう＼(^O^)／: 20年間無敗のマネジメントノウハウ
- チームはマネジメントで変わる！
- 実践パーソナルプロジェクトマネジメント
→この章を読み飛ばす（次の章：【プロジェクト実行管理】プロジェクトを実際に動かしていく時に読みたい本8冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
３分間コーチ
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★★
読書メモ
- 三分間コーチとは1回3分で部下にコーチとして話す方法
- ポイントは部下について考える時間と部下と話す時間をとること
- マネジメントの役割はスケジュール管理とタイムマネジメント、実施戦略の立案、リスクマネジメント、判断、部下育成
- 業務に沿ってどうだった？と聞いてみよう
- 部下から相談に来させてはいけない
- 部下のプロフィールを改めて作る
- 部下との日記をつけておく
- 調子が良い曜日に集中する（1週間で1日集中する日を作ってみる）
- 全部化に対するトピックを考えておく
- スタートダッシュやハードルを下げることが可能
- 業務の後押しのコミュニケーションを躊躇しない
- 上司に自分のことについて知ってほしい
- タスク50%のタイミングで進捗を聞く（相手をモチベートさせるような質問）
- 事前の目標をたがいに確認することで自発性を高める
- 部下がコミュニケーションを求めているとき｜タスクやPJTの開始、途中、終了の時
- 部下1人での不測の事態対応力を鍛えるためには決して答えを教えず、リソースやスキルをあげる
- どんな状態であれ区切りを設ける
- 区切ったら事実を整理する
- ブレストのサポートも上司の役目を果たすチャンス
- アイディア⇒行動に移すアイディアの順で考える
- 事前に3分間コーチについて同意をとっておく
- ○○に迷ったら声をかけてと伝えておく
- 続きは明日、今日は話せてよかったで十分
- マネージャーの仕事は声掛けがほとんど
- 上司の仕事は部下に仕事をさせることではなく、自ら進んで仕事をやろうという気にさせること
- 的確に要望する
- 少し先の未来を示す
- 繰り返しイメージする
- 問いを共有する
- 正しい問いは不安のような無駄な問いが追い出せる
- 個人のWIIFMにたどり着くまで深堀する
- 解決をせずにともに向き合う
- 不満の徹底ヒアリングと解消⇒その後相手に対する期待を伝えていく
- 楽しさと面白さがないと人は成長しない
本書の説明
非常に実践的なメンバーマネジメント手法でありながらシンプルなので、計画や管理に組み込むとよいかと思い、早めに紹介させていただきました。
内容は、各メンバーに対して細かく3分程度の雑談込みの会話をしましょうと説明している本です。
これは私自身、メンバーとして経験して有効だと感じている方法であり、実践するようにしています。
また、ほかの本でも触れていますが、この本でもマネージャーの仕事は声掛けがほとんどと話されています。いろんな手をうっているのにプロジェクトの進みが悪いと感じる方はこちらを試してみたらいかがでしょうか。
ポチップ
草食系部下を戦力化する！マネジメントの極意
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★★
読書メモ
- 自分がやりたい仕事を部下に任せる
- ライバルの動きを”気づかせる”環境を作る
- 進め方ではなく考えることに時間を使えるようにする
- 部下の人生に対する面談を行う
- 変更理由を必ず伝える
- 成功体験ではなく成功原因を伝える
- 仕事の一部を完全に任せて自身の片腕を複数作る
- とりあえずやれは0点
- 行動をほめる、見ておく、指摘する
- 大枠のスケジュール感を伝えたうえで期限を部下に決めさせる
- ○○してみようよと伝える
- 中途半端でもストップさせるのも上司の仕事
- 部下の欠点は上司の欠点
- 部下の質問には即答しない
- 上司から部下への報連相を徹底する
- 部下とのコミュニケーションの工夫の余地はいくらでもある
説明
草食系と呼ばれる人たちに自然とやる気を出してもらうにはどうすればよいかを書いた本です。最もマネジメントとして刺さったのは上司から部下へのホウレンソウです。部下に報告を強制しながら上司からの情報は伝えていない場合が多すぎます。まず自分の行動を変えたうえで部下の行動を変革させていきましょう。
ポチップ
大工の棟梁に学ぶプロジェクトマネジメント
評価
- 読みやすさ：★★★★☆
- おすすめ度：★★★★★
読書メモ
- 評価するのはやり方ではなく結果
- 部下が大丈夫と言ったらまずは信じる
- やるべきことを示すとは完成イメージの共有とタスクの明確化
- 指示通りに動かないときは自身の伝え方を見直す
- 相手の能力ややる気を考えない
- 必ずプロジェクト中に一度はあれる
- 現場があれたら仲良くなるチャンス
- 文句が多いやつには教えてくれてありがとう
- 意見を言わない人には話を投げかけて思っていることを話させる
- やがてチームのためにとなる
- どうしても相性が合わない場合は笑顔で送り出す
- 上に立つ者の我慢は話を聞くこと
- 雑談や休憩で情報交換をさせる
- 知っていれば未然に防げることも多い
- お金だけはきっちりNOという
- 気づきを行動に変えてうまくいくという経験をさせる
- 口下手かどうかではなく必要なことが伝わっているかを考える
- いうことを聞かせるためには実力を見せることも必要
- 習うより慣れろで笑顔で任せる
- 確認するという工程を入れておく
- 順調なら疑え
- 結果と経緯をメモする
- ミスは誰でも起こすので正直に言いやすい場所を作る
- クレーマーにはとっとと謝ってしまう
- 頭は止めない
- 変なことやってると感じた場合は意図や理由をしっかり聞く
- 拮抗する案はどっちを選んだっていい
- 決めてほしいと頼まれたらすぐに決めて後にフォロー
- 仲良くなければ良い仕事はできない
- 指示出して遠くから見守る
- 失敗したら反省してもらう＋他の人にも教えてやってくれという
- 今の自分の仕事が全体に対して何の意味を持つのかを知っているとモチベートされる
本書の説明
大工の棟梁の部下との接し方からメンバーマネジメントを学べる本です。
理論というより実例がメインなので、メンバーと接するときの引き出しを増やしたい方にはおすすめです。
私自身が最も学びになったのはメンバーが失敗したときの接し方です。失敗した時にただ叱ってもやる気を失ってしまうし、叱らなくてもなめられたり、だらけてしまうのでどうしたらよいのか悩んでいました。
この本では失敗したら反省してもらう＋他の人にも教えてやってくれということで失敗を無駄なものにしないが、失敗したことに関しては反省させているという例が紹介されていました。
リーダーになったら最初に読む プロジェクトを成功させる技術！
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- プロジェクト型が増えたのは効率化と対応力のため
- PJTのステップは企む・談る・やる・視る・振り返る
- 課題ログをリストアップ
- QFDの家で設計する
- 情報のレポートラインを上下以外も設計する
- パフォーマンス・資源・時間の3要素の比率を決める
- チームビルディングの4ステップ：成立期・動乱期・安定期・遂行期
- 状況対応型リーダーシップ（教示的⇒説得的⇒参加的⇒委任的）
- 教示的：チームビジョン＋具体的タスク
- 説得的：ヒアリング＋回答
- 参加的：問題をチームで解決
- 権限のコントロール
- コーエン&ブラッドフォードの影響力モデル
- プロセスフローダイアグラムとWBS
- 問題解決は親和図で行う
- Keep, Problem, Tryでプロジェクトを振り返る
本書の説明
メンバーに動いてもらうための考え方やフレームワークなどがメインで記載されています。
例えば、QFDの家はメンバーに品質基準を説明するのに分かりやすいです。リーダーシップやチームビルディングの4段階を把握しておくと雰囲気に流されず冷静に対応できます。
ポチップ
ポンコツ上司が頼られ上司になったリーダー術
＜評価＞
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- テレワークでスピード重視することが可能
- ピラミッドの上に座って指示を出すのがボス、ピラミッドを自ら引っ張るのがリーダー（リーダーを目指そう）
- リーダーの能動的なコミュニケーションが組織の稼働率を決める
- 部下に聞いているようではだめ。自ら指示を出す
- チームビルディングでは人間関係とルールの両輪が備わっていることが大切
- 先生によって出来ない子か目立つ子がいじめられるのが決まる
- 休憩を指示するのもリーダーの役目
- シングルタスク化出来るように区切ってく
- リーダーはしんがりを務めよ
本書の説明
リーダーの役割と行動について書いてある本です。
この本で一番大事だと感じたのは「リーダーの能動的なコミュニケーションが組織の稼働率を決める」です。
私はこれを身をもって体験しました。ほっとくとメンバーは勝手に落ち込んでいくし、気づいたら炎上確定な問題が発生しているし、かと思ったら指示がなかったからと何もしていない人がいたりします。率いるポジションの人は肝に銘じてほしいのがどんなに気まずくても自らコミュニケーションを図ることです。
ポチップ
1日15分で人生が変わる！人生プロジェクト管理術
評価
- 読みやすさ：★★★★☆
- おすすめ度：★★★☆☆
読書メモ
- 感情が動いたシーンをヒアリングする
- 目標を立てる
- 感情と整合性が取れているかを確認する
- 実現ステップを考える
- 行動計画を立てる
説明
メンバーのモチベーションアップを図りたいならおすすめの本。太字部分にある通り、メンバーの感情と指示や役割との整合性が取ることでパフォーマンスが上がり、積極的に動いてくれるようになります。
ポチップ
管理者のための人材特性とマネジメント手法
評価
- 読みやすさ：☆☆☆☆☆
- おすすめ度：★★★☆☆
読書メモ
- 組織には戦略志向型と成果志向型が存在する
- 成果志向型ではマイクロマネジメントでやる気を重視し数値で判断する（結果、離職率が増える）
- 戦略志向型はキャリアステップを考える（途中での離脱者はいるがそれでも費用対効果が高い）※ただし現代のスピード感にあっていない戦略志向型組織が多い印象
- 成果志向型が多い日本では中高年雇用が進まない
説明
組織論の本です。戦略志向型と成果志向型の組織について説明されています。成果を出したら昇進の成果志向型と戦略的なキャリアステップで考える戦略志向がある中で、筆者はどちらかと言えば戦略志向型に立っています。読んだ感想としては、戦略志向型の方がよいことは納得感があるが、現代のスピード感に合わせるためにもう一工夫必要ではないかと思いました。
プロジェクトマネジメント技術
評価
- 読みやすさ：★☆☆☆☆
- おすすめ度：★★☆☆☆
読書メモ
- 担当者がワークプランを立てさせる
- オフタイム/オンタイム全てでコミュニケーションを増やす
- プロジェクトの序盤はとにかく課題を出して階層化、絞り込みをしていく
- 次に課題に対して解決策の仮説検証
- 最後に提言をまとめる
- 初回打合せ（2週間程度）のタイミングで認識・知識のすり合わせを事細かに行う
- 担当を小分けにして個人の責任を明確にする＆会議では他パートへの貢献を重視する
- 新しい業界を調査するときは業界構造、流通ルート、営業要員一人当たりの売上高などを既知の業界と比較しながら確認すると速い
- 関連パート同士のコミュニケーションを毎日させる
説明
複数人がかかわるプロジェクトで一番怖いのが共有がうまくなされていなかった時の認識ずれです。手戻りは発生するし、修正の仕方でももめます。それらを解消するために関連パート同士で直接話す機会を作りましょう。
ゼロから成功を引き寄せるMVPマネージメント
評価
- 読みやすさ：★☆☆☆☆
- おすすめ度：★★☆☆☆
読書メモ
- M（使命）、V（理想）、P（情熱）をもってコミュニケーションし、戦略を立て、責任を明確にしながら進む
- 求められていることの視点を持つ
- ニーズ・強み・情熱の交わり領域で力を発揮する
- SWOT分析をしてNSPの重複部分を見つけ出す
- ハイプカーブ｜業界内での盛上り⇒衰退⇒市場への浸透
- Mは自身の使命感を持てることが何かを問い続けること
- P⇒V⇒Mの順で考えるが、説明はMVPの順
- 99%の努力と１％のひらめきは技術系（努力）にとっての営業（ひらめき）
- セグメンテーションとカオスのバランスが大事
説明
MVPマネジメントに関する本です。一般的にはビジョン（理念や理想とも）に共感できるかで語られることが多いですが、共感したうえで行動指針となるミッションがなければ行動できません。逆に言うとミッションが明確なら個別業務の指示は抽象的でも、ミッションと照らし合わせて行動できるようになると説明されています。
20年間無敗のマネジメントノウハウ
評価
- 読みやすさ：★★★★☆
- おすすめ度：★☆☆☆☆
読書メモ
- 各人の特長を生かすアサインが大切
- 全てのメンバーが納得できるようになるまで役割を見直す
- 頭の良さ・柔軟性重視
- 良い人を集めて最も苦しんでいる人を基準にする
- 優秀な人にはどーんと任せて長い目で見る
- 発生順を優先順位付けに考慮しない
- 問題発生時は暫定対処⇒問題の根源の掘り下げ
- 定例は昼にすべし
- やってみせ 言って聞かせて させてみて ほめてやらねば人は動かじ
- 話し合い、耳を傾け、承認し、任せてやらねば、人は育たず
- やっている、姿を感謝で見守って、信頼せねば、人は実らず
- 炎上案件の火消しは1対1でヒアリングを行う
- メンバーが休みたい場合はノータイムでOKする
説明
定例会を朝からやるのではなく、昼過ぎにやると効率が良いという点は使える情報。
ポチップ
チームはマネジメントで変わる！
評価
- 読みやすさ：★★★★☆
- おすすめ度：★★☆☆☆
読書メモ
- まずはありがとうとごめんなさいを徹底する
- 4つのタイプ｜能動的（すごい）、受け身（ありがとう）、感情（新しい、面白い）、考える（確かに、正しい）
- 会議の3種類｜問題発見、対策、実行支援
- マネジメント｜長期⇄短期の軸を変える
- 視野を広げる｜社長と世間の違い
- してはいけないことと良い例を挙げる
- タスクの4象限｜メンバーの可or不可×リーダーの可or不可
- 松下幸之助は体験発表会を行っていた
説明
気軽に読めてマネジメントに関して再発見がある本です。特に4つのタイプでメンバーの対応を変えたり、会議の種類が3種類という話は分かりやすいです。さらっと読めるので移動時間などに読んでみると発見があるかもしれません。
実践パーソナルプロジェクトマネジメント
評価
- 読みやすさ：★★★★☆
- おすすめ度：★★★☆☆
読書メモ
- ミッションはあなたの役割（誰に何をする人なのか）
- 個人でMVVからPMまで構造化する
- 自身の生涯の目的を問う
- 3年間の過ごし方を問う
- 半年の寿命で何をするか
- 翌日のタスクを6つ出して優先順位を決める。翌日その通りにやる
- 予定したことを予定した通りに進める
- タスクの粒度は1週間の配分時間で決める
- 終わったこともTODOに記載する（すぐできることはすぐにやる）
- タスク管理は予実の時間を入力する
- 予定は割当時間と考える
- タスクの割り振りは何時間分の成果を作り出す必要があるかで考える
- EVMを使いこなす（予定時間と作業量の時間換算と実時間）
- やる気を出す要因を探してやる気をなくす要因を減らせ
- とりあえず適当に手をつける（スイスチーズ法）
- 1つのタスクは15分に切ってみる
- 欲求論｜マズローの欲求5段階節
- マクレガーのXY理論
- アルダファのERGモデル
- マクレランドの欲求説
- パブロフの犬
- ハーズバーグの2要因説
- ブルームの期待説
- ワイナーの達成動機帰属理論
- 目的達成にはロジックと意思と踏み込み
説明
マネジメントに使えそうな心理学の理論が紹介されている本です。マズローの欲求5段階節、マクレガーのXY理論、アルダファのERGモデル、マクレランドの欲求説、パブロフの犬、ハーズバーグの2要因説、ブルームの期待説、ワイナーの達成動機帰属理論・・・ともしご存じのない説があったらググるかこの本で確認しておきましょう。
【プロジェクト実行管理】プロジェクトを実際に動かしていく時に読みたい本8冊
- ゲームプランナーのチーム運営例: ～ゲーム性以前の問題を発生させないために～ ゲームプランナーの参考例シリーズ
- リーダーになる前に知っておきたかったこと
- トラブルシューティングから学ぶプロジェクトマネジメントの基本
- 試行錯誤のプロジェクトマネジメント: 方法論をマスターしたら、守り、破り、離れろ！
- ITプロジェクトの無駄を排除する ロスコストマネジメント実践ノウハウ
- 現場改善はなぜ上手くいかないか: 進退きわまった時にすべきこと
- 1時間で読める初心者のためのプロジェクトマネジメント
- 本気のプロマネ３: リスクマネジメントを理解する
→この章を読み飛ばす（次の章：【契約】プロジェクトの契約に関する本1冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
ゲームプランナーのチーム運営例
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★★
読書メモ
- アナウンスで事足りるレベルは報告・連絡
- 認識のすり合わせを行わなければならないことを共有という
- 共有は互いに口に出して説明してお互いの認識のずれを確認する作業を指す
- ビジョンの共有など必要なステップは自身でやろうとせずにチームの運営方法に組み込む必要がある
- ビジョンの共有に正解はなく、それを確立する方法こそがチーム運営方法を決めること
- 実装内容の取りまとめ（PMが行う）
- 実装内容のすり合わせ（PMとPL）
- 実装内容の全体共有（PLがメールと口頭で）
- その後はPMとPLで進捗会議と遅延のリカバリ策を検討していく
- 納品の数日前に全体のチェックを行う
- 納品物チェックは全員で行う
- マイルストーンとしてのゴールがあるだけでそこまでの道筋は千差万別
- 明確にバグだしの時間を決めておく
- 基本的に自分ですべてを進めるのはできないという前提を置く
- チームの運営方法についての提案は許容される
- ゴールを中心メンバーで共有しそれをスタッフと共有することを徹底する
- 自身が必要だと思った打合せはどんな形であれ必ず実行する
- チームで動く場合には先読みして先手を打つ考え方にしなければならない
- チーム発足までに決め事が必要
- 仕事上のやり取りは連絡か報告か相談か依頼しかない
- くどい共有というかすり合わせは必ず行うべし
説明
ゲーム業界の開発を例にプロジェクトマネジメントを説明している本です。まず、報告、連絡、共有の違いについての説明が分かりやすいです。アナウンスで事足りるレベルは報告・連絡であり、認識のすり合わせを行わなければならないことを共有というと説明されていました。ほかにもPMとPLの仕事分担やバグだしの時間を作るなど、実践的なノウハウが多い本です。
ポチップ
リーダーになる前に知っておきたかったこと
評価
- 読みやすさ：★★★★☆
- おすすめ度：★★★★☆
読書メモ
- 伝えた内容は忘れられる前提で動かす
- 自分の都合が良いように文章を理解する
- 0→1フェーズでは課題設定の共有をとにかく徹底する
- 共通認識を持てるすべてを使って共有する
- 1→10では新旧メンバーの対立の解消に全力を注ぐ
- 成長が止まったと感じたら出来ることを非常にうまくやることに力を注ぐ
- 誰もが心中で感じていることを言葉にして前を向かせる
- filetype:pdfで情報収集する
- 考えて言葉にするを繰り返すことで思考は前に進む
- まず動け（プロトを作れ）。アマチュアは考えていろ、プロは動く
本書の説明
リーダーとしての心構えが書いてある本です。読みやすい本ですが、覚えておくべきことがいくつもありました。例：0→1フェーズではリーダーの仕事は課題の共有である。1→10ではメンバーの対立解消に時間を使う。・・・など。
トラブルシューティングから学ぶプロジェクトマネジメントの基本
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★★★★☆
読書メモ
- トラブルはステークホルダーとの認識の齟齬によって発生する
- スコープの解像度が全て
- プロジェクト前のアウトラインの作成には延べ10時間程度の打合せが必要
- アウトラインではシステムの目的、必須要件、ラフ構成図、機能一覧、求められる品質概要を定めておく
- プロジェクトを始めた理由は何か
- コスト見積に関してエンジニアが黙っていた
- 対応可能な納期の説明が出来ないため間に合わない納期のままであった
- リスクに関する説明がなかった
- ネガティブ報告の受け入れ態勢がなかった
- わから ない こと を 聞く
- リスク が ある こと を 議論 に する
- 正直 に 話す、 伝える
- 機能や品質に加えてドキュメントや社内手続きに関しても確認しておく
- 納期が守れそうにないときは、理由と対応策を最速で伝える
説明
プロジェクトのトラブルの事例と原因、対応策について説明されている本です。この本で最も大切だと思ったのは、失敗の原因として「ネガティブ報告の受け入れ場所がなかった」ことです。メンバーからネガティブ要素を上司に伝えるのは容易なことではないので、どういうルールで伝えればよいかを明確にしておかなければ上司に報告されることはありません。また、マネジメントより現場の方が先にネガティブ要素に気づくので、もし、報告が上がっていれば予防できた事例も数多く存在します。
試行錯誤のプロジェクトマネジメント
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★☆☆
読書メモ
- おしゃべりは情報交換の場
- マネジメントは仮説検証のプロセスが大切であり先が見えていないことを自覚することから始める
- 詳細な設計は正確な設計だが詳細な計画は不確実性も内包したものでなければならない
- オーバープランに注意して計画する
- 教科書手法とプロジェクト独自の事象では独自を優先する
- プロジェクトの「誰のために」「何を提供するか」の徹底共有が大切
- 前提条件と制約条件の共有も必ず行う
- メンバーの行動の一貫性を保つために行動指針・行動の限界を決めておく
- 方向転換せざるおえないときの意思決定方法の検討
- マネージャーの仕事はチームの理解から始める
- 問題発生時には必ず理解やヒアリングから始める
- 権限と義務と責任｜誰が誰に対してどのような成果物を提出する義務があるのか、誰にその責任があるのかを明確にする（必ず個別（分散させない））
- リフレッシュルームもよい
- 情報共有のルールや意識付けは必須
- 権限譲渡はアウトラインの作成と現場の判断
- 顧客と開発者の間で直接コミュニケーションをとる機会を設ける
- 野次は中心に立たせる
- 問題の関係性を明らかにして原因究明を行う
説明
プロジェクトを進めていくうえでのメンバーとの接し方や組織ルールの作り方、さらに障壁となるようなオーナーやステークホルダーの対応方法など、プロジェクトが止まりがちなポイントに対しての対処方法が書いてある本です。この本でもプロジェクトの目的の共有の大切さについては強く説かれています。また、「メンバーの行動指針・行動限界を決める」や「問題発生時にはヒアリングから始める」など当たり前だが実践がなかなかできていないことについても説明されています。
ポチップ
ロスコストマネジメント実践ノウハウ
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★★☆☆☆
読書メモ
- コストの原因例（製造業）｜出荷後の不具合、設計ミスによる手戻り、製造不良廃棄品、未使用廃棄品、梱包ミスの破損、工事等無償サービス、過剰在庫の場所代、安値売却
- ロスコストの原因は事故などの直接的原因とそのきっかけの間接的原因に分けられる
- VTA分析｜縦軸に時間、横軸にステークホルダーとして原因分析する
- 原因や要員、リスクの依存関係、連鎖を分析していく
- ロスコストモデルを作成～修正する
- 失敗シナリオを作る
説明
無駄な費用や工数を削減するためのマネジメント手法が書かれています。ポイントは失敗シナリオを作ることです。シナリオとして共有されていると組織の資産となり、今後の失敗を防ぐことにつながります。
現場改善はなぜ上手くいかないか
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★☆☆☆☆
読書メモ
- 現場改善は見える化から始める
- KPIは努力した人が評価される仕組み
- KPI設計の目的は単純な効率化以外の競争力を持つこと
- 定例会が予定通りに開閉され、ネクストアクションが具体化されていること
- 定例会では数値情報以外の共有を行う
- 会議やPMのやることは原因究明、方法決定、リスクヘッジ、状況の整理
- 課題形成作業①課題の洗い出しと優先順位付け
- 課題形成作業②原因確認
- 課題形成作業③解決方法の洗い出しと選択
- 課題形成作業④選択した解決方法のリスク検討
- 課題の見える化｜スコープ⇒方針と実行計画⇒現行業務と問題点⇒問題分析と課題の定義
- PJTの要件定義｜制約条件と訂正・定量要件の洗い出しを行う
- PJTの仮説検証｜問題点ステートメント⇒スケジュール表の作成⇒効果測定・評価指標の作成⇒リスク管理
- PJTの最初にメンバーにプレゼンを行う
- プレゼンの場面と聞き手の行動を定義する
- PDCAがうまくいかない場合はCとAがない
- 改善を急ぎすぎるとメンバーのやる気がそがれる
- 計画書は必ずサマリーをつける
- まずは落ち着いて自社の業務プロセスを見える化すること、顧客に対しては要件をベンチマークすることです。
- 見える化のキモは定性情報を定量情報に変えていくこと
- 変更管理には変更要望書の作成も効果的
- PDCAも見えるかもすでにやったことの振り返りから始めよ
説明
現場改善に関する本です。現場改善の最初のステップであり、非常に重要なのに、ほとんどの事例で出来ていないのが「見える化」です。この本でも繰り返し説明されていますが、見える化ができていないとその後のステップは意味を成しません。
1時間で読める初心者のためのプロジェクトマネジメント
評価
- 読みやすさ：★★★☆☆
- おすすめ度：☆☆☆☆☆
読書メモ
- 期日があるのがプロジェクト
- ゴールはSpecific（明確性）、Measurable（測定可能）、Assignable（割当設定）、Realistic（実現可能性）、Time-related（期限）に立てる
- 求められる品質の可視化
- マニュアル・ガイダンスの作成
- 研修の開催
- 進捗管理の方法の設定（エクセルと口頭）
- トラブルの早期発見と対策のイメージを持っておく
説明
プロジェクトマネジメントを広く説明している本です。進捗管理を口頭とテキストの2種類で行うのがポイントです。
本気のプロマネ３: リスクマネジメントを理解する
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★☆☆☆☆
読書メモ
- リスクとリスクファクターを把握する
- リスクファクターの対策を立てる
- リスクファクターは静的、動的、外的がある
- 静的リスクファクターにはルール化、マニュアル化
- 動的リスクファクターと外的リスクファクターには常時監視を行う
- 特に常時監視はファクターが起きそうかどうかを拾い上げる仕掛けが必要
- 常時監視では閾値・限界地の設定が必要
- 『タスク完了』が人によって違う
- 変更要求には規格を理由に断る
- リスクマネジメントでは残タスク管理、残コスト管理、メンバーの健康管理が必要
- 実現可能な計画か実現不可能で痛手が少ない計画を立てる
説明
リスクマネジメントに関する本です。リスクを静的なものと動的なものに分類し、マニュアル化とモニタリングで予防する仕組みが紹介されています。
【契約】プロジェクトの契約に関する本1冊
- ディベートで学ぶシステム開発委託契約
→この章を読み飛ばす（次の章：【タスク管理】タスク管理を知ってマネジメント脳を鍛えたい人に読んで欲しい本4冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
ディベートで学ぶシステム開発委託契約
評価
- 読みやすさ：☆☆☆☆☆
- おすすめ度：★★★★★
読書メモ
- 開発契約の種類｜多段階契約、請負、準委任、再委託、検収、契約不適合責任、著作権、損害賠償
- 契約の優先順位｜民商法の強行規定＞契約書の条項＞民商法の任意規定
- システム開発委託の優先順位｜商法＞民法
- 経産省のモデル契約｜https://www.meti.go.jp/policy/it_policy/softseibi/index.html#p02_01
- 一般的にはシステム開発契約では、多段階契約と再見積もりで行う（要件定義作成支援業務、外部設計書作成支援業務、ソフトウェア開発業務、ソフトウェア運用準備・移行支援業務）
- 準委任は善管注意義務のみで報酬が支払われる
- 責任分界点がどこにあるか
- 民法636条注文者の供した材料の性質による契約不適合
- 民法536条2項の債権者の責めに帰すべき事由
- 善管注意義務とは専門家の注意義務であり派遣などとは質が異なる
- 支払い条件は報酬の確定と報酬の支払い時期の2点を決める
- 下請法では検収基準ではなく受領基準から60日での支払いとなる？
- 請負契約は双務契約であり、報酬請求権は契約の締結時に発生する
- 要求の変更は双方の合意がないと契約上有効とはならない
- 情報システムとは業務遂行上必要な情報の仕組であり、ソフトウェアはプログラム群のこと
- 契約内の責任を債務不履行責任
- 契約内容に適合していないと一年以内に知った場合にその項目に対してのみ責任が発生することを契約不適合責任と呼ぶ
- 営業秘密として保護されるためには秘密として管理されていること（秘密管理性）、有用な情報であること（有用性）、公然と知られていないこと（非公知性）の3つが必要
- 秘密保持に関する争点は安全管理措置・方式である
本書の説明
最もハードルが高いが、最も必要なノウハウと言ってもよい契約に関する本です。
取っ掛かりはおっくうになるかと思いますが、必ず読むべき本です。開発契約の各項目ごとにベンダーとクライアントの議論の様子が記載されています。
そもそも契約とは業務でよく問題になる点を事前に取り決めることなので、この本を読むだけでも、プロジェクトでのもめるポイントを把握することができます。
【タスク管理】タスク管理を知ってマネジメント脳を鍛えたい人に読んで欲しい本4冊
- マンガでわかる! 幼稚園児でもできた!! タスク管理超入門
- 爆速仕事術: 定時退社を可能にする５つの思考法
- 知的生産性を高める20のルール
- ダイエットは経営だ: 正しい経営者はダイエット専門職
→この章を読み飛ばす（次の章：【仕事術】仕事の効率化して、あなた自身とチームを加速させたい人が読む本5冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
幼稚園児でもできた!! タスク管理超入門
評価
- 読みやすさ：★★★★★
- おすすめ度：★★★★★
読書メモ
GTDタスク管理術
- 毎日少しでも良いのでタスク全ての洗い出しのみを行う
- いらないものを削る
- アクション出来ない場合は細分化する
- すぐできることを今終わらせる
- 他の人にお願いできることを依頼するor自分ではやらない
- ここで初めてスケジュールを切る
- タスク管理ツール（Nozbe、Toodledo、TaskChute）
- 全TODOを踏まえて当日のタスクを作成する
- IfThenでタスクを考える
- それが無理なら時間で区切る
- ８～１０は実行しやすくする目的
- 習慣を変える場合は環境を変えて週間までの行動を長くめんどくさくする
- タスクの見積（終わりと始まり）と実績を記録する（記録ツール：TaskChute, iライフログ、toggl）
- タスクが膨れ上がったら捨てる
- バッファを設定する
- 振り返りをタスクに組み込む
- 効率化図るためのTIPSを記録する
- 記録を元に効率化のための改善を行うor提案する
- 時間の使い方を区分して自身の将来にとって有益な時間を増やす
5歳の著者の娘さんの実録を元にした本。
本書の説明
プロジェクトマネジメントの入口として最適な本。
GTD（Getting Things Better）と呼ばれるタスク管理法を著者の家族の例で説明してくれています。身近なことなので想像しやすいですし、プロジェクトマネジメントのエッセンスは詰まっている本です。
またプロジェクトマネジメントの中でもタスク管理は入り口としてイメージしやすいです。その中でもGTDは現在のIT業界の主流となっている考え方なので押さえておきましょう。学習初期に読むのがおすすめ。
ポチップ
爆速仕事術
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- あなたの仕事を早くしても支持が悪きゃ変わらない
- 力の入れ方・抜き方を考えるべし
- 部下の中での上司の重要性が高いことをアピールする（報告する）
- 事実・解釈・打ち手を報告する
- 説得に会社の価値観を使え
- 文章の推敲は音読
- 求められることを続ける
- 自分の自信があって明確に指示できる仕事は他人に振る
- 本気で業務の9割を捨てる覚悟をする
- 予定は半分くらいが空白がちょうどよい
- 納品物、契約・交渉、受発注以外の仕事を捨てる
- 派閥の安全地帯に陣取り根回しをする
- 対立したときは共通敵を作って解決する
- 簡単なDaily目標とざっくりとした長期目標を立てる
説明
マネジメントとして仕事の効率を上げる、プロジェクトの進捗効率を上げるためのノウハウが書いてある本です。
特にポイントだと感じたのは以下の2点です。
１．自分の自信があって明確に指示できる仕事は他人に振る、
２．本気で業務の9割を捨てる覚悟をするです。
１．は他人にタスクを振る基準です。たとえ自分でやった方が早かったとしても他人に明確に指示できる仕事はほかの人にお願いしましょう。そして自身でタスクを抱えるのをやめましょう。
２．は仕事の効率化を考えるうえでの最重要ポイントです。1つの仕事を何秒早く終わらせるかではなく、無駄な仕事をとにかくやらない。そのためには本気で9割の仕事を捨てる覚悟が大事だったりします。
知的生産性を高める20のルール
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★☆☆
読書メモ
- 期待値調整は超上流の戦略で決まる（HOW＜WHAT＜WHY）
- 3つにグルーピングする
- フレームワークを100個覚える（BSC等）
- 問いを間違ってはならない
- 簡単な構造で議論を図示する
- メモもPREPで行う
- リスクマトリックス（移転・保有・回避・軽減）での対応方針の策定を行う
- ノックアウトファクターだけは必ず取り除く
- コミュニケーション力＝相手のカレンシーを見抜く能力が高い（コーエン&ブラッドフォードのカレンシー分類）
- イブニングタイムの休息方法もプロであれ
- PJTでは常に先を示し続ける
- 相手の思考回路に合わせた連続性を持ったコミュニケーションを行う
- 常に全体視点で考える・全体視点に立ち戻る
- トータルパフォーマンス（＝作業適正化×感情的成果）で考える
説明
現代の仕事でつかえるTipsが詰まっている本です。いくつか例をご紹介すると「３つにグルーピングする」「フレームワーク100個覚える」などやって損はないことが書いてあるので、興味を持ったものから取り組んでみるとよいかもしれません。また、トータルパフォーマンスの考え方はマネジメントとして押さえておきたいところです。
ダイエットは経営だ
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★☆☆☆
読書メモ
- 3年継続する可能性が8割程度だと思えることをやる
- ゴールを決定するために現状分析が大切
- 正しいことの引きは弱い
- ダイエットのファッション化
- 経営者はビジネスの研究が必須
- 0or100にしないで0～100にする
- クリアできる目標とする
- 菓子パン1個＝140分のウォーキングのように他の危険度の指標として見える化する
- ノンストロークを恐れてマイナスストロークを欲していないか
説明
個人の継続のためのノウハウ本です。自身の成長のためにも、メンバーへのタスク割り振りなどには役立ちます。
特に覚えてほしいのは「３年間８割の確率で継続できそうな目標を立てること」です。つい高い目標を立ててしまいがちですが、３年くらい継続できそうな目標にするとよいでしょう。さらに、私の感覚では３年８割目標を３カ月くらい続けると、その目標を少し高く設定してもまた３年８割に感じてくるようになります。
【仕事術】仕事の効率化して、あなた自身とチームを加速させたい人が読む本5冊
- なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
- 超時短思考: あなたの時間が増える成功メソッド
- なかなか自分で決められない人のための「決める」技術
- 本気でゴールを達成したい人とチームのためのOKR
- 問題はタコつぼでなくタコだった！？
→この章を読み飛ばす（次の章：【ビジネス知識】プロジェクトマネジメントの周辺ビジネス知識を学べる本5冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
なぜ、あなたの仕事は終わらないのか
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★★
読書メモ
- オブジェクト指向とは何らかの対象を先に選択したうえで動作を指定すること（日本語と同じ）
- わざとバッファを作ることで効率が上がる
- 時間の使い方次第で能力を超えられる
- 上司は業務の都合上で期限を決める
- Windows95は発売当初3500個のバグがあった
- 全ての仕事は必ずやり直しになる
- 問題を分解して独立させる
- ビルゲイツは説明専門家を2名雇っていた
- プレゼンは質疑応答のみ
- ペーパーウェア戦略（まだ完成していないものを発表して競合のやる気をそぐ）
- スケジュールの割り出しのための時間を2日間もらう
- その2日間でほぼ完成までもっていき残りの期間で完成度を高める
- ロケットスタートで徹夜する
- 2日で8割仕上げても10日目まで提出しない
- 効率の低下を感じたら何度も寝る
- とにかく締め切りを作る
- 集中が分断された3時間と分断されない1時間は同程度
- 複数の業務をシングルタスクで進める場合は前回の業務進捗を思い出す作業まで想像して終える
- あなたの役割は規則を守ることではなく仕事を終えること
- 何かきっかけがあるまでは勉強はしない
- ハンマーの使い方ではなく釘の打ち方を調べろ
- 今の仕事で興味がある部分の共通点を見つけ出せ
説明
Windows95をチーフアーキテクチャーとして設計した中島聡さんの本です。
中島さんのエンジニアとしての仕事の効率化に関する話とビル・ゲイツの効率化に関する話が出てくるので、読んでいて楽しめる1冊です。特に「ウィンドウズ95は発売当初3500個のバグがあった」ことと「学ぶのではなく調べる」は印象的です。ローチファーストはIT業界でよく語られますがそれにしても3500個はすごいですね・・・。
また中島さんは今まで一度も学んだことはないといいます。タスクや課題があって、それを調べることしかしなかったといいます。何となく学ぶよりも、調べざる負えない状況を作ったほうが成長は早いですよね。
超時短思考
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- 作業は必ず全体像の理解から
- 15分ごとに分割する
- 企画は言われた瞬間に8割仕上げておく
- 会社で電話や会話を無くす時間を作る
- テンプレートにする（作業手順と内容、フォーマットを決める）
- 仕事を止めない、溜めない、抱えない
- 引き継ぐ前から出来る仕事は先にやっておく
- マニュアルは自分たちの仕事を文章化するためにやる
- マニュアルは作業手順とその根拠を示す
- 整理整頓は捨てる・すぐに取り出せること
- 探す作業は効率化しやすい箇所
- 10秒考えて分からない場合は聞く、調べる、現地に行くようにする
- デジタルツールには最大限の投資をすべき
- 常にGiveするとふとした時に返ってくる
説明
仕事の効率に関する本です。この本では「企画は言われた瞬間に8割仕上げる」を実践するようにしています。明らかに仕事の効率が上がったのでおすすめです。
なかなか自分で決められない人のための「決める」技術
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★★★☆☆
読書メモ
- 仕事は自ら決めて動く、作業はすでに決められている。二つ合わせて業務。
- 経営層やマネジメント層が決める回数を増やす必要がある
- 何かを決めるとは捨てる何かを明確にすること
- 決断の際には以下のメリデメに着目｜感情、経済、時間、労力、健康、将来、家族、お客様
- 決めるときは誰がなぜ何を誰に誰のために誰といつからいつまでどのようにいくらでいくつどこでを意識する
- 本能・感情・理性のどれで決断をしているか
- 直観は経験値で考える
- ウォンツ・キャン・マストで考える
- 気づく⇒きめる⇒やる⇒続けるで成功する
- マネジメントはQCD
- 習慣とセットでハードルを下げて続ける
説明
プロジェクトマネージャーの仕事は決断の連続です。限られたリソースを使って、期限内にゴールまでたどり着くためには多くの決断が強いられます。そして問題が複雑になっていくと、感覚だけでは決断できなくなってきます。そんなときのために読んでおいてほしいのがこちらの本です。それこそいくつかは感覚的に頭の中でやっていたという人もいるかもしれませんが、もし、まだ試していない考え方があれば実践してみてはいかがでしょうか。
本気でゴールを達成したい人とチームのためのOKR
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★☆☆
読書メモ
- OKR（objectives and key results）
- 企業活動＜＜情熱、やる気、目的意識
- 目的を持てばわくわくして普段以上の力を発揮する
- 課題の先にワクワクを設定する
- 自分の目的が組織の目的に近づいていく場合もある
- 組織とは複数の人が協力して共通の目的を達成しようとする状態のこと
- 相乗効果でプロレスラーに女性が勝つこともある
- コンフォートゾーンやパニックゾーンではなくストレッチゾーン
- 部下に現状を把握させる振り返り
- 何を考えるかを定義するのがマネージャーの仕事
- 組織の透明性が役割や方向性の理解につながる
- 多様性のある組織においても共通の目的と規律は共通させる
- 挑戦を評価する仕組みを作る
- 目標は徹底的に細分化する、何度も修正する
- １アポロ計画の成功は明確な目標を宣言したこと
- ミッションは組織の存在理由、ビジョンは目指すべき状態、バリューは行動や価値の基準
- MVVの下に戦略が来る
- 目的を達成するための重要な指標を設定する
- OKRの運用はタスクの障壁の排除に気を配れ
- 1on1は事前に話す内容を伝えておけばあり
- OKRの振り返りはKPTを活用する
- 改善は取り除く、減らす、増やす、付け加えるでまとめる
- 組織のコミュニケーションの仕組みは共通言語と頻度
- 成果と原因について議論すること
- OKRの目標は強い言葉など面白さ重視する
説明
KPIなどの指標を使うための効果的な考え方OKR（Objectives and Key Results ”目標と主要な結果”）について説明されている本です。インテルの元CEOが提唱した考え方で、GoogleやFacebookなども導入しています。OKRの具体的な実践方法は本体にお任せするとして、ポイントとして押さえておいていただきたいのは、「コンフォートゾーン、パニックゾーンではなくストレッチゾーン」です。各メンバーにタスクをあてるときにその人にとってのストレッチゾーンを考えましょう。つまり常日頃から各メンバーを理解するアクションをとっておくことが必要です。
問題はタコつぼでなくタコだった！？
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★☆☆☆☆
読書メモ
- 個人の夢や目標が会社にどんな影響を与えられるかを定義すると腑に落ちる
- とにかく一点突破
- ミクロの強固な一点突破がマクロを変える
説明
縦割りで硬直化した組織を変革するために何をすべきかを説明している本です。ポイントはまずミクロな一点を突破することです。
【ビジネス知識】プロジェクトマネジメントの周辺ビジネス知識を学べる本5冊
- ビジネスフレームワーク３００: 4時間で俯瞰する300のフレームワーク
- 言葉ダイエット メール、企画書、就職活動が変わる最強の文章術
- Valuesist(バリューシスト) 働き方改革時代に社員のやりがいと生産性を高めるバリュー経営法 (impress QuickBooks)
- 鬼速PDCA
- 経営戦略論 図解 バランス・スコアカード実践７ステップ構築PMプロジェクト・マネジメント（実践編）: ３分で簡単にわかる経営戦略論シリーズ 戦略シリーズⅡ
→この章を読み飛ばす（次の章：【考え方】プロジェクトマネージャーの考え方を学べる本2冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
ビジネスフレームワーク303
評価
- 読みやすさ：★☆☆☆☆
- おすすめ度：★★★★★
読書メモ
フレームワークのカテゴリ｜
- 全社戦略
- 事業戦略
- 戦略実行・組織変革
- 業務分析・業務改革
- データ
- 問題解決
- 意思決定・比較判断
- 議論の整理・収集
- 提案・報告・説明
- プロジェクト推進
- チームビルディング
- マーケティング
- アイディア出し
- 主要な法則
説明
ビジネスフレームワークが300個紹介されている本です。この本がすごいのは一つのフレームワークでもパターン分けされていたり、SWOT分析でもクロスSWOT分析までの流れも含めてフレームワーク化している点です。繰り返し使えます。
言葉ダイエット メール、企画書、就職活動が変わる最強の文章術
評価
- 読みやすさ：★★★★☆
- おすすめ度：★★★☆☆
読書メモ
- 文章が長いとわかりにくい
- 1996年～2006年で情報量が560倍
- 一文一意で書く
- 修飾語を具体的なものに置き換える
- 同じ言葉は言いかえる
- 前文と同様で明らかであれば主語を省くのもよい
- 遠回しな敬語表現はやめる。潔い表現をする。
- アイディアやコンセプトなどはどちらかにして統一
- こそあど言葉を無くす
- 面白さには発見が必要。
- 主観的発見は無意識で感じてた内容を言葉にした発見
- 客観的発見は知られていない事実を伝えること
- 一般的な内容をどんどん言い換えて具体化する
- まずは大雑把に3幕構成で仕上げる
説明
文章術に関する本です。チームで動く場合、文章で情報を伝えることがたくさん出てくると思います。決して重たい本ではないので、もし今まで一度もこうした本を読んだことがなければ、一度目を通してみてはいかがでしょうか。
Valuesist(バリューシスト)
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★☆☆
読書メモ
- ビジョンだけでは加速している現代に対応しきれない
- バリュー＝行動指針を明確にして目標を探しながら走り続ける組織にすべし
- 日頃の業務にMVVを入れ込んだ形にすべし
- バリューとは会社の存在意義とそのための行動指針
- 行動指針と評価基準が連動していれば就職時のミスマッチが減る
説明
MVVマネジメントの本です。Mission、Vision、Valueのうち、特にValue（行動指針）が大切だと論じている本となります。プロジェクトに置き換えると目標（Vision）が明確だとしても、そこにたどり着くための前提や制約、行動基準などが不明確だと各メンバーがどう動いてよいかわからなくなります。チームを率いていくうえで理解はしておきたい考え方です。
ポチップ
鬼速PDCA
評価
- 読みやすさ：★★☆☆☆
- おすすめ度：★★☆☆☆
読書メモ
- PDCAは課題解決の手法の一つである
- ボトルネックは検証プロセスではなく計画時点での基準の甘さ
- 物事がうまくいっているときにも原因がある
- PDCAの階層を作る
- 重要指標に絞ってPDCAサイクルを回す
- 理路整然とした戦略では対応しきれないのでPDCA使うべし
- 計画がPDCAの5割を占める
- PDCAが失敗する原因は過慎重か過雑
- なぜそれを目指すのかを常に自問する
- 上位PDCAはいわゆるOKR
- 他にできるとしたら？さらに3つは？と問う
- 仮に本物の経営者だとしたらと問う
- 5段階の深堀をする
- 最初の階層だけはMECEにする
- プロセスごとに分割して改善する
- 完結型のタスクは数、継続型のタスクはラップタイム
- TODOの基準はスケジュールに書き込めるか
- 他人の感情には常に気を配れ
- アイスボックスを有効活用せよ
- 捨てる、入れ替える、圧縮するの順でタイムマネジメントする
- 検証可能な範囲で出来るだけ早く
- 気づきがC
- サイクルが1週したら次のサイクルのための情報収集も行う
- PDCAサイクルには最低限の仮説設定と期間と行動が必要
- 振り返りでは必ず良かった点にも目を向ける
- 週単位でサイクルを回していくが、中間での振り返りやシェアを挟むのもよい
説明
PDCAサイクルについて説明している本です。ポイントとしてはPDCAサイクルには最低限の仮説設定と期間と行動が必要であること、Cは気づきと認識することです。
バランス・スコアカード実践７ステップ構築PMプロジェクト・マネジメント（実践編）
評価
- 読みやすさ：★☆☆☆☆
- おすすめ度：★★☆☆☆
読書メモ
- ビジョン、最終目標KGI、問題点分析、課題設定、アクション･プラン、KPIを整理し て、キーワードを抽出
- SWOT 分析 （KGI、強み、弱み、機会、脅威）
- 戦略マップ（財務、顧客、業務、学習と成長）
- バランス･スコアカード解法（4つ視点における戦略目標、）｜重要成功要因、重要評価指標、ターゲット
- アクション･プランを明確にしましょう！ （財務、顧客、業務、学習と成長）
- 経営ビジョン、ビジネスモデル、経営方針、事業戦略、KGI設定、導入準備の推進体制の整備、利害関係者調整、競合他社調査・分析、4つの視点＋α、SWOT分析、KPI設定、予算計画、プロジェクトリスク抽出、アクションプラン作成、KPI選定、トップ承認
説明
プロジェクトのさらに上位に位置する経営の観点について学べる本です。特にバランススコアカードを使った方法について説明されています。経営に関する項目や指標について説明されていますが、特に６．の経営ビジョン・・・の部分は一度理解しておくとよいでしょう。
ポチップ
【考え方】プロジェクトマネージャーの考え方を学べる本2冊
- プロジェクトマネジャー２年目の虎の巻: 「昇進したら無能になった」とならないための、エンジニアのためのプロジェクト管理の指南書
- プロアクティブ仕事術 コンサルタントが３年目までに身につける仕事をデザインする方
→この章を読み飛ばす（次の章：【読み物】プロジェクトマネジメントに関する物語を読んで息抜き出来る本4冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
プロジェクトマネジャー２年目の虎の巻
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★☆☆☆☆
読書メモ
- 新規事業や変化が速い現代におけるPJTでは安易なコスト試算は危険
- 人間系のコミュニティタスクとシステム系のモノづくりタスク
- 新規ではマイルストーンではなくプラスとマイナスの目標を作る
- 順次ではなく累積でいつか跳ねるような行動を選択する
- まずは動くことを最優先とする
- フレームワークを使う場合は粒度を意識する
- ヒアリングは直接複数回を基本とする
- プレーヤーは正確にマネージャーは曖昧に
- 問題に早期に気付くためにはスケジュールと対策の量と内容を確認する
- PMの仕事はコミュニケーションやタスクのやり取りのハードルを下げる
- PMはフレームワークに乗っていない人間的な課題を解決する
- メンバーの言い訳は情報源
- 現場が人員追加の判断を行うべし
- PMレイヤーの情報共有は全体視点を持ってもらうため
- アウトプットで評価すると自発的になる
説明
開発以外も含めた広い意味でのプロジェクトマネジメントに関して浅く広く書いてある本です。順次ではなく累積という考え方は今後覚えておいて損はないでしょう。
ポチップ
プロアクティブ仕事術
評価
- 読みやすさ：★★★☆☆
- おすすめ度：☆☆☆☆☆
読書メモ
- プロアクティブとは計画的な行動を起こすこと（段取りや先読み、走りながら行動とは違う）
- プロアクティブな仕事スキル｜スコーピング、手順展開、割付、見える化、リスク対応、コミュニケーションプラン、スキル計画
- 仕事の報告対象とその理由（何に使うか）を明確にすべし
- 仕事を早く進めるためにはECRS（なくす、一つにする・同時に行う、順番を変える、単純にする）
- ルーティーン業務はWBSを元に手順書にする
- 仕事の主導権に関わるor自分が成長できる仕事以外は他人に振る
- そのために事前に仕事をお願いする人と工数を計画しておくリソースプランを立てる
- リスクを予測して消極的な計画を立てるのではなくありとあらゆる不足を想定しながらその対応策を立てることが大切
- スキルを段階的にどの順番で学ぶかの計画が大切
説明
個人のスキルがものをいうコンサルタントの仕事に対する考え方の本です。「仕事の報告対象とその理由（何に使うか）を明確にすべし」は覚えておいてよいでしょう。
ポチップ
【読み物】プロジェクトマネジメントに関する物語を読んで息抜き出来る本4冊
- クリスマスプロジェクト: 子どもたちの笑顔のためにクリスマスプレゼントにプロジェクトマネジメントを活用しよう
- ザ・コーチ
- ザ・コーチ2 ― 神様からのギフト
- ザ・コーチ3
→この章を読み飛ばす（次の章：迷ったらこれを読め｜厳選7冊）
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
クリスマスプロジェクト
評価
- 読みやすさ：☆☆☆☆☆
- おすすめ度：★★★★★
読書メモ
- プロジェクトの期待値を高める
- プロジェクト終了と思ったところから顧客満足度の勝負が始まる
- 複数人がかかわると不公平性が出てくるので難しい
- プロジェクトメンバーのねぎらいを行う
説明
プロジェクト終了と思ったところから顧客満足度の勝負が始まることだけは強く覚えておきましょう。
ポチップ
ザ・コーチ（１～３）
評価
- 読みやすさ：★★★☆☆
- おすすめ度：★★★★☆
読書メモ
- 喜ばせたい人、喜ぶ顔を見せたい人、幸せになってほしい人と仕事の意義を問う
- 許せない人と理由とその人に感謝してみる
- プロジェクトが成功したときに誰がどこでどんな会話をして喜んでいるか
- ブレーキを外せば自然と前に進めるようになる
- 自身の目標を見直す
- 仕事をするうえで大切にしていることは何か
- 自身の目標を達成するために知識・能力・道具が必要
- 目標、目的、夢、ゴール、ビジョンを明確に理解する
- 目標について話すときは目的を強調せよ
- ドリームリスト100を作る
- ゴールを手にした瞬間のイメージを描く
- ゴールや目的を設定し行動することでのベネフィットは何か
- ゴール達成に必要な知識を具体化する
- 目標は自分が主語
- 目標に向けて何をやったか、効果的に進むためにどうすればよいかを問う
- 真の幸せや豊かさを達成するための時間を見積もってそれを配分していく
- 今日の計画が終わる前に今日を始めない
説明
メンバーや自身の目標設定に悩んだらヒントがあるかも。
迷ったらこれを読め｜厳選7冊
「正直60冊なんて多すぎる・・・」と思った方は以下の7冊を読めば最低限プロジェクトマネジメントのことを理解できます。
- マンガでわかる! 幼稚園児でもできた!! タスク管理超入門
- 大工の棟梁に学ぶプロジェクトマネジメント
- ３分間コーチ ひとりでも部下のいる人のための世界一シンプルなマネジメント術
- 要件定義実践のポイント: 曖昧さと不確実性を仕様化する！
- 要件定義のヒアリングリスト４２７: 要件定義フェーズで、今、何を確認すべきかが、具体的にわかる！
- 目指せPMP PMBOK第5版対応: 最速でPMPに合格するための解説書
- ディベートで学ぶシステム開発委託契約
1から順に簡単⇒難しい、範囲が狭い⇒広いとなっています。
以下にそれぞれの本をなぜこの順で読むとどんないいことがあるかを記載しました。
↓↓↓↓↓↓↓Kindle Unlimitedの登録はこちらから↓↓↓↓↓↓↓↓
マンガでわかる! 幼稚園児でもできた!! タスク管理超入門
＜1番目に読むことを推薦する理由＞
- 内容が簡単で読みやすい
- PM経験がなくても理解できる事例で書かれている
- タスク管理はプロジェクトマネジメントを理解する入口に最適
内容が簡単で読みやすい
この本は全182ページで中身も専門用語が少なく、読みやすいです。
入門書としてちょうどいい分量でしょう。
PM経験がなくても理解できる事例で書かれている
そして幼稚園児のお子さんとの家族の話を題材にしたタスク管理の本なので、身近で想像しやすく、あなた自身も実践しやすいものとなっています。
タスク管理はプロジェクトマネジメントを理解する入口に最適
そしてタスク管理は、プロジェクトマネジメントのステップの中でも初期から最後まで続く重要なステップです。
最初にタスク管理の入門を把握しておくことで、この後の専門的な計画やマネジメントの本を理解する助けになります。
ポチップ
大工の棟梁に学ぶプロジェクトマネジメント
＜2番目にこの本を読むことを推薦する理由＞
- 以後の学習でマネジメントについても試行錯誤できるようになるため
- この本は専門知識がなくても理解できる話がたくさん書かれているから
以後の学習でマネジメントについても試行錯誤できるようになるため
この本はカテゴリでいくと、メンバーマネジメントの本です。
そしてメンバーマネジメントを要件定義やプロジェクト計画よりも先に読んでおくと、その後の読書でメンバーに対する接し方や指示の仕方も同時に学ぶことができます。
メンバーマネジメントはそれこそ正解が複数あるので、「あなたならどうするか」をたくさん考えた人が強いです。
そこでメンバーマネジメントの色々な手法を把握した上で、要件定義の方法やプロジェクト計画の立て方・進め方を学ぶと「私ならこの時チャットで指示出すかな」とか「この時は会議開いてみんなに伝えたほうがいいかな」など考えられるので、模擬練習になります。
この本は専門知識がなくても理解できる話がたくさん書かれているから
その中でもこの本は経験談ベースで専門知識がなくても理解できる話がたくさん書かれているので先に読むのがおすすめです。
本の内容は複数の大工の棟梁さんから部下の育成や指導に関してのインタビューをするものです。
それこそこんなブログまで見に来てくださっている方は普段から勉強家だと思います。
マネジメントについても学んでる場合があるかもしれません。
ただ今回の相手が大工の棟梁さんなので、一般的なマネジメント手法に当てはまらないけど確かにいいと思えるものがいくつもありました。
一読の価値ありです。この本も199ページと薄い本なのでサクッと読めます。
３分間コーチ ひとりでも部下のいる人のための世界一シンプルなマネジメント術
＜3番目にこの本を読むことをすすめる理由＞
- 簡単に実行出来る方法でありながら、実践すると効果が出やすいマネジメント手法であるから
- 特にテレワークでメンバーの気持ちが離れていきやすい中で有効な手法であるから
簡単に実行出来る方法でありながら、実践すると効果が出やすいマネジメント手法であるから
この3分間コーチはリーダーが各メンバーと1対1で定期的に3分間会話をすることでメンバーの様子やタスクの進捗、リスクを事前に予防できるというものです。
私がこの方法を進めるのは実体験で効果が出ていると感じたからです。
定例などの会議ではなく、調子どう？と気軽に話す場所があると自分の懸念点や作業進捗がよくない点を上司に共有できるので安心して仕事に取り組めます。
そしてやることは3分間、各メンバーと会話するだけ・・・やらない手はないので選ばせていただきました。
特にテレワークでメンバーの気持ちが離れていきやすい中で有効な手法であるから
この方法だとテレワークでも簡単に実践できます。
コロナでのテレワーク移行が進んでいる会社も多いと思いますが、普段通りに行うとチーム内の距離感が広がり、メンバーの気持ちが離れていきやすいのがテレワークでしょう。
その時にもこの方法は有効です。
要件定義のヒアリングリスト４２７: 要件定義フェーズで、今、何を確認すべきかが、具体的にわかる！
＜4番目にこの本を読むすすめる理由＞
- 要件定義はプロジェクト計画の最初のステップだから
- 新人マネージャーが最も悩む要件定義について分かりやすく説明している本だから
- 要件定義の中でもヒアリングは最初に行うステップだから
要件定義はプロジェクト計画の最初のステップだから
いざプロジェクトが始まるとまず行うのが要件定義です。
このプロジェクトでは何をゴールにしていつまでにどんな方法で進めるのかを決めていきます。
そして決めた要件を元に計画に落とし込んでいくことになります。
計画の前に学んでおくべきなのでこの位置とさせていただきました。
新人マネージャーが最も悩む要件定義について分かりやすく説明している本だから
また要件定義だけ切り出して書籍を紹介したのは、新人マネージャーが最も苦労するのが要件定義だからです。
前述のように要件定義でプロジェクトの大枠を決定するのですが、慣れない状況でわずかな情報から全体像の定義をするのは至難の業です。
経験者でも難しさを感じている人が多いようなので切り出して重点的に紹介することとしました。
要件定義の中でもヒアリングは最初に行うステップだから
最後にこの本は要件定義の中でもヒアリングに重きを置いている本です。
そして要求のヒアリングは要件定義工程の中でも最初に行うので、学習順としては先としました。
ポチップ
要件定義実践のポイント: 曖昧さと不確実性を仕様化する
＜5番目にこの本を読むことをすすめる理由＞
- 要件定義フェーズの顧客との交渉に関して書いてある本だから
- 要求を要件として定義するまでの現場のリアルなステップを記載しているから
要件定義フェーズの顧客との交渉に関して書いてある本だから
要件を決めていく中で必ずお客さんとの交渉が発生します。
そして交渉は大変です（特にエンジニア出身だと特に苦手意識があるといいます）。
その時に役立つのがこの本です。要件の決め方から顧客にどうやって承諾をもらうかなども説明されています。
現場での経験を見越したときに必須の知識です。
要求を要件として定義するまでの現場のリアルなステップを記載しているから
もう一つのこの本の特徴が、要件定義の作業手順の説明ではなく、要件定義フェーズを完了するために必要なことが書かれています。
この本を読めば要件定義フェーズの流れを把握できます。流れというのは、要求ヒアリング⇒要求整理⇒機能要件・・・などではなく、
要求を聞く前にまず自分たちのチームでデスクトップ調査をして仮説出しをする。その次に現場とマネジメント、両方にヒアリングをする。などアクションを流れを理解できるということ。
目指せPMP PMBOK第5版対応: 最速でPMPに合格する
＜6番目にこの本を読むことをすすめる理由＞
- プロジェクトマネジメントを学ぼうと思うならPMBOKを理解するのは最低ライン
- PMBOKを学ぶならこの本が最もわかりやすかったから
プロジェクトマネジメントを学ぼうと思うならPMBOKを理解するのは最低ライン
この本はPMBOKと呼ばれるプロジェクトマネジメントの知識体系に関する資格PMPを取得するための対策本です。
そしてプロジェクトマネジメントを学ぶ際にPMBOKを学ばない手はありません。
網羅的ですし、体系だったプロジェクトマネジメントの知識が手に入ります。
現場レベルでは使わないなど多少はあるかもしれませんが、最低限押さえておくべき内容です。
PMBOKを学ぶならこの本が最もわかりやすかったから
そうは言ってもPMBOKは膨大な知識が必要となります。
今まで紹介してきた本はその中の一分野にすぎません。
いきなりPMBOKを学ぶのはハードルが高いのでこの順としました。
また、PMBOKの本は複数ありますが、その中で最もわかりやすいのがこの本でした。
先ほども説明したようにPMBOKは幅広い分野をカバーしているので、理論立てて書かれていない本を読んでしまうと余計に混乱する場合があります。
ディベートで学ぶシステム開発委託契約
＜7番目にこの本を読むべき理由＞
- 契約を知ることは顧客との間の争点を知ることになるから
- 最後にした理由はプロジェクトマネジメントのことをある程度把握していないと全く理解できないから
契約を知ることは顧客との間の争点を知ることになるから
最後に厳選させていただいたのは開発契約に関する書籍です。
契約はとっつきにくい印象があったり、困ったら法務の人に任せればいいやと考えている人がいるかもしれませんが、プロジェクトマネージャーを目指すのであれば必ず学ぶべき知識です。
なぜ契約で事前に決めごとをするかというと、その部分はあとでもめる可能性が高いからです。
逆に言うと、契約のことを分かっていれば顧客とどういったところでもめるのかを理解することができます。
さらにこの本は様々な契約書の文言に対して、顧客とベンダーの議論形式で進んでいきます。
つまり、顧客との契約交渉や争点に対する対応策を学ぶことができます。
最後にした理由はプロジェクトマネジメントのことをある程度把握していないと全く理解できないから
最後にした理由は、初心者が読んでもまったく意味が分からないからです。私自身がそうでした。後回しにして、ある程度プロジェクトマネジメントを学んでから読んでみると使える知識がたくさん詰まっていました。
まとめ
今回はプロジェクトマネジメントに関する書籍をご紹介しました。
こちらで学んで実際にPMになりたいという興味を持ってくれた方には以下の記事もおすすめです。
