→プロジェクト管理
- 直感を超えたソフトウェア開発８つの常識と注意点 | Social Change! 2023.6
- 1章 完成しても、終わりではない
- 2章 人を増やしても速く作れるわけではない
- 3章 たくさん作っても生産性が高いとは言えない
- 4章 人に依存せず同じ品質で作ることはできない
- 5章 プレッシャーをかけても生産性は上がらない
- 6章 見積もりを求めるほどに絶望感は増す
- 7章 一度に大きく作れば得に見えて損をする
- 8章 工程を分業しても、効率化につながらない
- デッドライン ソフト開発を成功に導く101の法則
- 適切な人材を雇用する。
- その人材を適所にあてはめる。
- 人々の士気を保つ。
- チームの結束を強め、維持する。
- （それ以外のことは全部管理ごっこ）
- どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。
- 短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。
- 成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。
- 優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い。
- 優れたプロジェクトは、設計に費やす時間の割合がはるかに高い。
- 相手を好きになり、気遣わなければ、人に違うことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない。
- プレッシャーをかけても思考は速くならない。
- 残業時間を増やすのは、生産性を落とす方法である。
- 一時的なプレッシャーや残業は、人々の焦点を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。
- 管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
- 入出力の完全なリストのない仕様書は、見込みなしである。仕様を明確にする最初の一歩にもならない。
- 理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤（プロジェクト期間の最後の６分の１ぐらい）に人数を大幅に増やすというものである。
- おそるべき推察：無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。
- 病んだ政治を下から治療することはできない。むだな努力で時間を浪費したり、自分の立場を危険にさらす必要はない。
- プロジェクトには目標と予想の両方が必要だ。この二つはちがっていて当然である。
- 仕事の仕組み化は万能か？仕組み化の副作用 2008.4.11
- うかつに「仕事の仕組み化」を行ってしまい、「仕組みを作り出す人」だけが自己満足に浸り、チームの生産性が逆に低下していくケースが多々発生するのです。論理的に、完璧な「仕事の仕組み化」を行っても、その中で働く「仕組みにより動かされていく人」のモチベーションがどんどん下がってしまい、相談に来られるというケースが増えています。
- 生産性は計測できない
- チームの生産性というのは、構築したソフトウェアをリリースしてから数年後に初めて分かるようなものかもしれない
Last-modified: 2025-06-20 (金) 14:36:01
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
