→上流工程一般
→ドキュメント作成
→開発支援ツール
サブトピック†
- なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita 2021.11
- 多数のソフトウェアプロジェクトの統計的な性質を調べたJUASの調査によると、ソフトウェアプロジェクトの工期と工数の関係は工数の三乗根に2.7をかけた数字に比例する
- 人数規模を拡大するにつれて、コミュニケーションコストの方が人数を追加するメリットよりも大きくなってしまうため、プロジェクトの拡大には上限がある
- ソフトウェアプロジェクトではスケールメリットが必要になれば、如何にコミュニケーションコストの低い組織とプロダクトを実現するかが重要になります。これはマイクロサービスアーキテクチャやDevOps、そして組織マネジメントがなぜ必要なのかを示唆
- ソフトウェア開発プロジェクトを蝕む10の典型的な過ち 2012.6.13
- 「人数を増やせばよい」という誤解
- 間違った指標を採用する
- 現実離れしたスケジュールを組む
- 時間の見積もりが大雑把すぎる
- 作業を計算に入れ忘れる
- コミュニケーション不足
- ビジネス上の優先順位を無視する
- 手続きによる壁を作る
- 「すぐに本格的な作業を始められる」という神話
- マルチタスク
- プロジェクトマネジメントで起こりやすい7つの問題と解決方法
- 曖昧な要件 -> マイルストーン設定
- クライアントの返答待ち -> Yes/Noで答える質問
- 遅延 -> 現実的な時間を割り当てたスケジュールをクライアントに伝える
- プロジェクトごとに異なる管理
- クライアントができたものに満足しない -> クライアントの動機を根本から理解
- プロジェクトのプライオリティが低い ->決定権のあるクライアントとコンタクト
- 問題解決に時間がかかる -> テストの時間を多くとる(※それができたら苦労はない
- プロジェクト・アンチ・パターンの集大成「アドレナリンジャンキー」 2009.12.21
- 「アドレナリン・ジャンキー」とは、モーレツ社員(死語)、もしくはモーレツ社員で構成された組織のこと。すべての仕事は最優先で、全ての送信メールは、【!緊急!】で始まる。作業の順番は重要性ではなく、切迫度によって決められる。したがって、長期的な見通しは存在せず、全ての仕事は、ある日突然、「緊急」になるまで放置される。
- プロジェクト成功のために
- ソフトウェアは、多数のチームやプロジェクト、硬く結束した作業グループで開発するので、ハイテクビジネスではなく人間関係ビジネスに携わっているといえる。
- プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な対人関係の結果である。
- 仕事の人間的な側面より、技術面に注意を多く払う理由は、重要だからではなく、単に解決しやすいから
- 正解を知っていても、あえて黙っている方がよい状況を知る 2009.1.30
- 正解を知っていても総合的に見て黙っていた方がよいことに加えて、あと2つ重要なことがある。「正解を知らない人たちはダメだ」という愚痴を言わないことと、結果が出てから後出しじゃんけんのように「正解はこうだったんだ」と言わないことだ。
- 旧来の手法では最先端の製品は開発できない 2008.4.24
- 昔風の開発のやり方で最新の高度で複雑な製品を開発しようとすると,個人に限界を超える負担を強いる場合が出てきます。その結果,個人に対して非常に過酷な影響が出る。しかも度々です。私も健康を害したことがあります。こうした環境は,どこの企業でも開発の最前線を歩いている人たちに共通かもしれません。僕は開発の責任者をしている期間がすごく長かったので,その恐ろしいほどのムダを身に染みて知っています。結局,(発展性が乏しかったり,汎用性が低かったりする)弱い技術を一生懸命育てようとすることになってしまい,手間がかかるだけで何の意味もありません。そういうことを何度も繰り返しやることに対して,本当にムダだなあ,と強く思っているんです。
- アプリとインフラの担当者はなぜ分かり合えない? 2008.3.5
- (1)お互いがインフラ(アプリ)のことを知らない
- アプリ・チームが作成した設計書をインフラ・チーム側で精査して各種パラメータを検討するとか,性能が出ないと思われるアプリについて単体テスト段階からインフラ・チームと検討する,といった協力体制があれば問題は未然に防げます。PMOはそのような協力体制を「仕組み」として作り込んでしまうことが必要なのです。メンバーの自主性だけに任せておくと,いつまでも同じような問題が繰り返し起こります。
- (2)プロジェクトの成功よりも自分の組織の成功を最優先に考える
- プロジェクトが1つの方向を向くようにナビゲートしなければなりません。上位組織に呼びかけるなどの対応は不可欠ですが,あくまでも『プロジェクトの成功が最も重要なゴールである』とプロジェクト全体に示す必要があります。その意味において,「プロジェクトとして成功したかどうか」を人事評価項目に含めるのも1つの手だと思います。
- (3)「相手が決めてくれないと自分の作業が進まない」という理屈が横行する
- 「担当者同士の課題」から「プロジェクトの課題」へとエスカレーションできる仕組みを作る
- わたしの7つのふりかえり 2007.10.2
- ■01 定期的に、ふりかえる
- ■02 わたしたち v.s. 問題
- ■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:見直しは絶対しましょう
- プロジェクトキックオフオリエンテーションで話すこと 2006.6.20
- 機能要求仕様はユーザー側が主体となってまとめるべきものであり、ベンダへの丸投げはプロジェクトの失敗につながること
- システム仕様の作成とは要求事項を羅列することではなく、取捨選択、検討して絞り込むことであること
PMBOK†
関連Webサイト・参考資料†
Last-modified: 2025-02-11 (火) 13:01:20