管理者の最近のブログ記事

良い設計が本質的であるのは当然として、管理者たる読者はそれについて何をすべきか？一つはっきりしているのは：読者自身が設計者たらんとはしないことである。もし読者がそうしたいなら、管理者をやめて第一線に戻ることだ。しかしちょっと努力すれば、組織が最悪の設計ミスを予防するのに少なくとも手を貸すことはできる。

「ワインバーグのシステム変革法」

おそらく良い管理者の最大の挑戦と試練は、終結すべきプロジェクトを終結すべきときに終結する能力である。

「ワインバーグのシステム変革法」

あまりにも性急に速く、多くの変革を組織に押しつける管理者は、加速しようとしているまさにその変革を遅らせてしまう。同時に、もし管理者が「多くの変革を試みよ。そうすればそのうちのいくつかは定着するだろう」という戦略を採用すると、最後にはそれらのいずれも定着しないことを思い知らされる。

「ワインバーグのシステム変革法」

多くのプロジェクトは、特定の役割を割り当てられた人々から構成されており、これらの人々は自らの守備範囲を超えた（あるいは自らの役割と誰かの役割の隙間にある）ものごとには責任を取ろうとしない場合がほとんどです。しかしより大きな問題は、私たちのほとんどが他者との衝突を避けようとする点にあるのかもしれません。多くの場合、PMは関係者をどれほど不快にしようとも、質問を行い、前提に疑問を投げかけ、真実を追究しなければならないのです（とは言うものの、関係者にできるだけ不快な思いをさせないようにしつつ、これらのことを実践するのがPMの目標となります）。

「アート・オブ・プロジェクトマネジメント」

「成功にも失敗にも等しく報いる。罰するのは怠慢だけだ」---デービッド・ケリー

「セクシープロジェクトで差をつけろ！」

許可を求めるのは、「だめだ」と言ってくれと頼むのと同じ。

「ブランド人になれ！」

優れた管理は優れた技術より重要である。最良の技術でもまずい管理の埋め合わせはできないし、逆に優れた管理者なら乏しいリソースでもすばらしい成果を上げることができる。優れた管理なら要員に最善を尽くす気を起こさせるが、すべての場合の当てはまる「正しい」管理のやり方など存在しない。

「ソフトウェア プロジェクト管理」

開発マネージャの立場として、あなたはたった3つの要素を相手に仕事をする。それはリソース(人と金)、機能（製品とその品質）、そしてスケジュールである。この三角形の中があなたの働く場所なのだ。これら以外に相手にすべきものはない。この三角形のどれか1つの辺を変えれば、残りの少なくとも1つの辺、しかしほとんどの場合2つの辺に影響が出る。

「ソフトウェア開発のダイナミズム」

プロジェクトが遅れているとしたら、何かが間違っている。原因を無視したり、チームメンバーを長時間働かせたりしないこと。原因を究明し、そして修正すること。

「デバッギング ザ デベロップメント プロセス」

何をすべきか従業員がわかっていないとしたら、それをやらなかったからといって、従業員を叱る資格は経営者にはない。経営者がある日、会社の目標を思いつき、退屈な幹部会議でその目標達成を指示し、あとは何もやらなかったら、従業員が目標達成のために何をやればいいのかわからなくても当然である。

「大逆転」