橋本将功のレビュー一覧
-
-
-
Posted by ブクログ
ネタバレ面白いタイトルで少し話題になっていたので。プロジェクトが壊れるのか人が壊れるのかは不明だけど、受け手、送り手の気質もあるにせよそうならないように努めることは重要であり、破綻プロジェクトも多数あるみたいなので参考にしたい。指示の方法やレビュー時に気を付けることに加えて、コミュニケーションや透明性の欠如、組織・環境など参考になる。リーダーにおすすめ。
#メモ
・知らず知らずのうちに言動や意思決定によるストレスを与えることがある
・過度なプレッシャーやサポート不足、明確な目標や役割の不在などが、メンバーのモチベーション低下やメンタルヘルス不調を引き起こさせる
#アンチパターン抜粋
- タスクの丸投げや曖昧な指示 (これは加減が難しい。具体的過ぎても考える余白を与えられないので適度な指示が重要と思う)
- 長時間労働や非現実的な締切 (体力、精神的に)
- マイクロマネジメント（過剰な管理。ある程度放任してもいい）
- 不公平な評価や過剰な責任の押し付け (でも大企業になると公平性のある評価は難しい...)
- ミスへの過剰な罰 (これはあまりないけど、そういえば部活のときにあったなあと思う)
- コミュニケーション不足や感情的なやり取り (これは問題ないけどテレワークとかで会う機会も減っているのでリモートワークの孤独感やサポート不足に対する工夫は必要)
- 組織文化とのミスマッチ (厳しい！) -
Posted by ブクログ
内容はタイトルのまま。人が病む原因となりうる要素を50個並べた本。50個もあるため、一つ一つの記述は短く、対策も表面的に思える。だからこそサクッと読めて良い、という面もあるが。
真面目に対策しようと思ったら、一つの要素で本が一冊書けるようなテーマばかりなので、本書を読んで何かすぐに個別対策ができるというようなものではない。「悪いのは分かるのが、簡単に対策できるなら、とっくにやってるわ！」になりがち。
逆に、本書の良さは網羅的に書き出して整理したところで、インデックスとして価値がある。一応、ITプロジェクトという文脈で書かれているけど、それ以外の業務でも通用する話ばかりなので、ITじゃない人が読んでもいいと思う。 -
-
Posted by ブクログ
ネタバレプロジェクトマネジメントに関連するメタ認知のテクニックについて述べた書籍。
題名から受けるイメージとは異なり、マインドセットなどに関する内容となっている。
プロジェクトマネジメントに関しては、前作の「基本が全部わかる本」がよくまとまっているので、そちらがオススメ。
本書はプロジェクトマネージャ向けの内容で、基本から一歩進んで視座を上げた「メタ認知」を知ることができたのは良かった。
【ポイント】
・メタ認知とは、「自分や関わる相手が何をしっているか、何をやっているかを客観的に理解していること」に関する能力
・組織の発展には、各人材が持つスキルの平均点を上げる観点での仕組み（ドキュメンテーションや実践の場を設けることなど）が必要
・非定期でインフォーマルな報告・相談ラインを持つ。危なそうな気配を感じたら、気軽にすばやくあげられるとよい -
-
-
-
Posted by ブクログ
プロジェクトマネジメントとは何か、その中でプロジェクトマネージャーの役割について、教科書のようにまとまっており、自分自身経験はないが概要は学べたと思う。本書のような流れでプロジェクトが進行し、課題をクリアしていきながら完了に至るのかということを想像できた。
1. プロジェクトとはなにか 基本的な知識と考え方をおさえよう
・プロジェクト：いまある状態からあるべき状態にするために行う、スタートからゴールまで続く複数の業務（本書の定義）
・プロジェクトの目的：プロジェクトが向かうべき最終的な到達点
・プロジェクトの目標：そのプロジェクトで達成すべき基準
・プロジェクトの目標はQCDによって定義することができる。例えば、業務システムの開発（Q：要件定義で必須と合意した機能要件と非機能要件を実装する、C：初期費用の費用は1.5億円を想定する、D：リリースは2023年の8月末を想定する）
2. 交渉 適切なパートナーシップを築こう
・事前資料（言語化）→打合せ（非言語でカバー）→議事録（言語化）の順がおすすめ
3. タスクマネジメント チームでパスワークをしよう
4. プロジェクト計画 目標や進め方を決めよう
・プロジェクトの方針の意思決定はQCDの基準を基に行う
・開発手法の選択（ウォーターフォール、アジャイル（スクラム））
5. 見積り 必要な費用とスケジュールを構造しよう
・概算見積りと詳細見積りを使い分ける
・概算見積り：発注者への提案や社内プロジェクトでの企画時点、プロジェクト計画、要件定義の段階
・詳細見積り：要件定義や設計で不確実性をかなり潰した状態で提示（正式な見積り）
6. 契約 不利な条件を回避しよう
・請負契約（成果物に対価）と準委任契約（労働に対価）
7. 要件定義 やるべきことを決めよう
・プロジェクトで実現すべきこと（要件）を決める（定義する）
・①「要求（実現したいこと）」と「要件（実現すべきこと）」を切り分ける
・②決めるべきことをスケジュールの観点で見極める
・③ビジネス要件（Why）を固める。Why：なぜそれをやるのか？
・④「実現すること」（What）の軸足と概要を描く
・⑤合意された事柄を資料化する（できるだけ図で表現。スライド作成ツールは使用しない）
・⑥法律など社会のルールを踏まえる
・⑦要件変更や追加要件のハンドリングをする
8. デザイン 顧客が本当に必要だったものを目指そう
・UI：目に見える画面のビジュアルや操作性などのデザイン
・UX：顧客体験などのデザイン
9. 設計 専門家に渡すバトンをつくろう
・①技術スタック（プログラミング言語やOS、ミドルウェア、フレームワークなど）を選定する
・②開発の「作法（ソースコード管理、コード規約、開発環境、デプロイ方法など）」を整える
・③設計書に求められる精度を確認する
・④設計書を作成する（基本設計から着手）
・⑤設計書をレビューする
10. テスト 事業リスクを最小限におさえよう
11. リリース 石橋を叩いて渡ろう
12. 保守改善 事業の成功につなげよう -
Posted by ブクログ
◯本書を読む目的
・仕事で小さなプロジェクトを回す必要が出てきたため
・今後マネジメントフェーズになった時の予習
◯感想
まずはリスクの観点で全体を俯瞰し、アクティブに調整を行うプロジェクトマネジメントとタスク進捗管理や予算管理に終始するプロジェクト管理を混同しないことが重要。
プロジェクトは不確実性が伴うものなので、計画段階からスケジュールや予算にバッファーを持たせるべき。
本書のプロジェクトの定義やQCDに関する交渉を有するという観点で考えると、ソリューション営業もプロジェクトの一部だと感じた。
そう考えると自分も普段大なり小なりプロジェクトマネジメントを実行している身ということになるため、より成功率を上げることを意識したい。 -
-
-
-