プロジェクト管理

堀江貴文｢だから団塊ジュニアは出世ができない｣未来予測は不可能だが､たった1つわかること | リーダーシップ・教養・資格・スキル | 東洋経済オンライン 2024.9
- 西成：渋滞というのは、組織でも個人でも同じで、適切な仕事の量があって、ある臨界を超えると急に仕事が渋滞し始めます。詰め込まず、余裕を持ったほうが生産性が高くなることがさまざまな企業で示されています。この臨界は企業によって異なりますが、最大できる仕事量の約7割ぐらいがいい、ということがわかっています。そして未来を予測して、今後どれだけの仕事量になるか予測していくことも重要です。
フロー効率と経験資源の葛藤 - yigarashiのブログ 2024.8
「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 #マネジメント - Qiita 2021
- リソース効率とフロー効率の違い。見えやすいリソース効率ばかり追求するとフロー効率は落ちる場合がある。

なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita 2021.11
- 多数のソフトウェアプロジェクトの統計的な性質を調べたJUASの調査によると、ソフトウェアプロジェクトの工期と工数の関係は工数の三乗根に2.7をかけた数字に比例する
- 人数規模を拡大するにつれて、コミュニケーションコストの方が人数を追加するメリットよりも大きくなってしまうため、プロジェクトの拡大には上限がある
- ソフトウェアプロジェクトではスケールメリットが必要になれば、如何にコミュニケーションコストの低い組織とプロダクトを実現するかが重要になります。これはマイクロサービスアーキテクチャやDevOps、そして組織マネジメントがなぜ必要なのかを示唆

どうやら本当のデスマーチを教える時が来たようですね 2020.12

ベンダーよ、シェルパの屍を越えていけ～　細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」 (1/2) 2014.2.22

歴史から考えるアーキテクチャとマネジメント 2012.10.21

ソフトウェア開発プロジェクトをとりまく６つの誤解～プログラミングを経験しないとわからないこと 2012.8.8
- 既にあるソフトウェアを流用した方が速く作れる
- ソフトウェアはハードと違って後から容易に直せる
- 誰が作っても中身は同じ品質になる
- 共通部品から先に作ることが出来る
- 人を増やせば一度に沢山の機能が作れる
- 正確な見積もりを出すことが出来る

伝えなければ伝わらないという当たり前の話 2012.8.9

ソフトウェア開発プロジェクトを蝕む10の典型的な過ち 2012.6.13
- 「人数を増やせばよい」という誤解
- 間違った指標を採用する
- 現実離れしたスケジュールを組む
- 時間の見積もりが大雑把すぎる
- 作業を計算に入れ忘れる
- コミュニケーション不足
- ビジネス上の優先順位を無視する
- 手続きによる壁を作る
- 「すぐに本格的な作業を始められる」という神話
- マルチタスク

システムはどこまで内製化できるか 2011.10.30

Web2.0時代のソフトウェア開発手法

プロジェクトマネジメントで起こりやすい7つの問題と解決方法
- 曖昧な要件 -> マイルストーン設定
- クライアントの返答待ち -> Yes/Noで答える質問
- 遅延 -> 現実的な時間を割り当てたスケジュールをクライアントに伝える
- プロジェクトごとに異なる管理
- クライアントができたものに満足しない -> クライアントの動機を根本から理解
- プロジェクトのプライオリティが低い ->決定権のあるクライアントとコンタクト
- 問題解決に時間がかかる -> テストの時間を多くとる（※それができたら苦労はない

プロジェクトはなぜ成功するのか 2010.12.14
- プロジェクトの成功は何で決まるのか、一言で言えと問われれば「プロジェクトの成否はメンバーで決まる」と答える。これが土台にある。しかし、それだけでは不十分で、プロジェクト管理の在り方で同じメンバーでも結果は大きく違ってくる。ポイントは以下の三つだ。
```
  1. 対症的プロジェクト管理でなく、予防的プロジェクト管理をすること
  2. 設計品質だけでなく、作業品質の向上を図ること
  3. プロジェクト全員が共通の目標を持つこと
```

プロジェクト・アンチ・パターンの集大成「アドレナリンジャンキー」 2009.12.21
- 「アドレナリン・ジャンキー」とは、モーレツ社員（死語）、もしくはモーレツ社員で構成された組織のこと。すべての仕事は最優先で、全ての送信メールは、【！緊急！】で始まる。作業の順番は重要性ではなく、切迫度によって決められる。したがって、長期的な見通しは存在せず、全ての仕事は、ある日突然、「緊急」になるまで放置される。

プロジェクトの失敗はスタート時点にあり。キックオフ前に、ミッションマップを作ろう 2009.12.4
- １．あなたの会社（プロジェクト）のミッションは何か？
- ２．あなたの会社（プロジェクト）の顧客は誰か？
- ３．あなたの会社（プロジェクト）が提供する価値は何か？
- ４．あなたの会社（プロジェクト）にとっての成果とは何か？
- ５．あなたの会社（プロジェクト）の計画は何か？

トラブル対応に必要な“余裕”をどう作る？ 2009.11.17
- ルーチン作業を自動化するツールを作り、蓄積する

プロジェクト成功のために
- ソフトウェアは、多数のチームやプロジェクト、硬く結束した作業グループで開発するので、ハイテクビジネスではなく人間関係ビジネスに携わっているといえる。
- プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な対人関係の結果である。
- 仕事の人間的な側面より、技術面に注意を多く払う理由は、重要だからではなく、単に解決しやすいから

『プロジェクトファシリテーション』書評

プロジェクト管理サーバーとは 2009.4.11

正解を知っていても、あえて黙っている方がよい状況を知る 2009.1.30
- 正解を知っていても総合的に見て黙っていた方がよいことに加えて、あと2つ重要なことがある。「正解を知らない人たちはダメだ」という愚痴を言わないことと、結果が出てから後出しじゃんけんのように「正解はこうだったんだ」と言わないことだ。

議論を恐れてはならない 2008.8.21
プロジェクトを開始前の準備 2008.8.21
- スコープを決める
- ソリューションを最適化
- 開発規模見積もり
- 要員と体制の検討
- 提案段階でフェーズが重ならないスケジュール
- リスクを識別・定量化

旧来の手法では最先端の製品は開発できない 2008.4.24
- 昔風の開発のやり方で最新の高度で複雑な製品を開発しようとすると，個人に限界を超える負担を強いる場合が出てきます。その結果，個人に対して非常に過酷な影響が出る。しかも度々です。私も健康を害したことがあります。こうした環境は，どこの企業でも開発の最前線を歩いている人たちに共通かもしれません。僕は開発の責任者をしている期間がすごく長かったので，その恐ろしいほどのムダを身に染みて知っています。結局，（発展性が乏しかったり，汎用性が低かったりする）弱い技術を一生懸命育てようとすることになってしまい，手間がかかるだけで何の意味もありません。そういうことを何度も繰り返しやることに対して，本当にムダだなあ，と強く思っているんです。

システム開発から属人性を排除しようとして失敗する 2008.4.2

アプリとインフラの担当者はなぜ分かり合えない? 2008.3.5
- （1）お互いがインフラ（アプリ）のことを知らない
  - アプリ・チームが作成した設計書をインフラ・チーム側で精査して各種パラメータを検討するとか，性能が出ないと思われるアプリについて単体テスト段階からインフラ・チームと検討する，といった協力体制があれば問題は未然に防げます。PMOはそのような協力体制を「仕組み」として作り込んでしまうことが必要なのです。メンバーの自主性だけに任せておくと，いつまでも同じような問題が繰り返し起こります。
- （2）プロジェクトの成功よりも自分の組織の成功を最優先に考える
  - プロジェクトが1つの方向を向くようにナビゲートしなければなりません。上位組織に呼びかけるなどの対応は不可欠ですが，あくまでも『プロジェクトの成功が最も重要なゴールである』とプロジェクト全体に示す必要があります。その意味において，「プロジェクトとして成功したかどうか」を人事評価項目に含めるのも1つの手だと思います。
- （3）「相手が決めてくれないと自分の作業が進まない」という理屈が横行する
  - 「担当者同士の課題」から「プロジェクトの課題」へとエスカレーションできる仕組みを作る

プロジェクト管理は「簡単なことを、確実に」 2008.3.3
- 成果を明確にする、作業分解、作業フロー、スケジュールの作成

ITの地殻変動はどこで起きているか？>SeasarとRuby,PF 2008.3.2

わたしの７つのふりかえり 2007.10.2
- ■01　定期的に、ふりかえる
- ■02　わたしたち v.s. 問題
  - 相手の向こう側に「問題」があるので、相手を口撃してしまうのが、ホワイトボードに書き出すことで
```
ホワイトボード（問題）　　←←←←←　「わたし　and　あなた」
```
    になる
- ■03　「問題」を持って、歩き回る
- ■04　人を集める
- ■05　よい質問
  - * いま取り組んでいるのは、どんな問題なのかな
  - * その問題が解決するとはつまり、○○ということになればOKなんだよね
  - * 「○○になった」のは、どうやったら分かる?
  - * それはいつ分かる?
  - * それは誰が分かる?
  - * あるいは、わたしが分かるためにはどうすればいい?
- ■06　お菓子は、重要なのかもしれない
  - 一緒にモノを食べてると、敵じゃないという気になれる。
- ■07　Getting out of the Box

案件成功のための10の鉄則 2007.7.30
- 鉄則1：プロジェクト／案件内容の把握を確実に
- 鉄則2：チームビルディングを楽しもう
- 鉄則3：利害関係者間でコミット、自分の負担を軽減
- 鉄則4：スケジュール作成で作業計画を明確化
- 鉄則5：メンバー作業のトレースは最低1日1回
- 鉄則6：上司への報告はスムーズに
- 鉄則7：工数把握でワーニングをキャッチ
- 鉄則8：問題点のフロー化
- 鉄則9：締めも肝心
- 鉄則10：見直しは絶対しましょう

masuidrive的プロジェクトの方針 2007.7.11

プロジェクトを成功させる魔法の言葉
- もし、問題があるとすれば、それは何ですか?
- あと何日?
- 目的は何ですか?　成果物は何ですか?　成功基準は何ですか?

Google、はてな、Appleに学ぶ失敗しないプロジェクトの３ヒント 2007.3.8
- 死守すべき締め切りを作らない
- メンバーのやる気に依存しない
- 変化することを前提とする

モチベーションを高めるには達成すればよい 2006.11.29

プロジェクトキックオフオリエンテーションで話すこと 2006.6.20
- 機能要求仕様はユーザー側が主体となってまとめるべきものであり、ベンダへの丸投げはプロジェクトの失敗につながること
- システム仕様の作成とは要求事項を羅列することではなく、取捨選択、検討して絞り込むことであること

プロジェクトを管理しないという発想

↑

PMBOK†

PMBOKについて. プロジェクトマネージャーの教典ともいえる、PMBOKについてご紹介したいと思いま… | by Masanori Ichiishi | nextbeat-engineering | Sep, 2023 | Medium 2023.9

The Complete Project Management Body of Knowledge in One Video (PMBOK 7th Edition) - YouTube 2022

「PMBOK対応童話でわかるプロジェクトマネジメント第2版」を読みました - 虎の穴開発室ブログ 2023.4

【PMP試験対策】　プロジェクトマネジメント・フレームワーク

↑

サブトピック†

一般†

PMBOK†

関連Webサイト・参考資料†

最新の50件