管理者: 2007年9月アーカイブ
良い設計が本質的であるのは当然として、管理者たる読者はそれについて何をすべきか？一つはっきりしているのは：読者自身が設計者たらんとはしないことである。もし読者がそうしたいなら、管理者をやめて第一線に戻ることだ。しかしちょっと努力すれば、組織が最悪の設計ミスを予防するのに少なくとも手を貸すことはできる。
「ワインバーグのシステム変革法」
おそらく良い管理者の最大の挑戦と試練は、終結すべきプロジェクトを終結すべきときに終結する能力である。
「ワインバーグのシステム変革法」
あまりにも性急に速く、多くの変革を組織に押しつける管理者は、加速しようとしているまさにその変革を遅らせてしまう。同時に、もし管理者が「多くの変革を試みよ。そうすればそのうちのいくつかは定着するだろう」という戦略を採用すると、最後にはそれらのいずれも定着しないことを思い知らされる。
「ワインバーグのシステム変革法」
多くのプロジェクトは、特定の役割を割り当てられた人々から構成されており、これらの人々は自らの守備範囲を超えた（あるいは自らの役割と誰かの役割の隙間にある）ものごとには責任を取ろうとしない場合がほとんどです。しかしより大きな問題は、私たちのほとんどが他者との衝突を避けようとする点にあるのかもしれません。多くの場合、PMは関係者をどれほど不快にしようとも、質問を行い、前提に疑問を投げかけ、真実を追究しなければならないのです（とは言うものの、関係者にできるだけ不快な思いをさせないようにしつつ、これらのことを実践するのがPMの目標となります）。
「アート・オブ・プロジェクトマネジメント」
「成功にも失敗にも等しく報いる。罰するのは怠慢だけだ」---デービッド・ケリー
「セクシープロジェクトで差をつけろ！」
許可を求めるのは、「だめだ」と言ってくれと頼むのと同じ。
「ブランド人になれ！」
優れた管理は優れた技術より重要である。最良の技術でもまずい管理の埋め合わせはできないし、逆に優れた管理者なら乏しいリソースでもすばらしい成果を上げることができる。優れた管理なら要員に最善を尽くす気を起こさせるが、すべての場合の当てはまる「正しい」管理のやり方など存在しない。
「ソフトウェア プロジェクト管理」
開発マネージャの立場として、あなたはたった3つの要素を相手に仕事をする。それはリソース(人と金)、機能（製品とその品質）、そしてスケジュールである。この三角形の中があなたの働く場所なのだ。これら以外に相手にすべきものはない。この三角形のどれか1つの辺を変えれば、残りの少なくとも1つの辺、しかしほとんどの場合2つの辺に影響が出る。
「ソフトウェア開発のダイナミズム」
プロジェクトが遅れているとしたら、何かが間違っている。原因を無視したり、チームメンバーを長時間働かせたりしないこと。原因を究明し、そして修正すること。
「デバッギング ザ デベロップメント プロセス」
何をすべきか従業員がわかっていないとしたら、それをやらなかったからといって、従業員を叱る資格は経営者にはない。経営者がある日、会社の目標を思いつき、退屈な幹部会議でその目標達成を指示し、あとは何もやらなかったら、従業員が目標達成のために何をやればいいのかわからなくても当然である。
「大逆転」
コーチは選手に何をして欲しいかを考えると同時に、どうすればそれをやってもらえるかを考えなければいけない。相手は血が通う人間であり、業務命令の紙ではない。コーチが試合に出て、選手の代わりにプレーすることはできない。パスもできなければ、ブロックもできない。コーチの仕事は何か。それは、選手にプレーさせることである。それを忘れてはいけない。
「大逆転」
みんなで力を合わせるということは、みんなで仲良く飲んで騒ぐことではないし、みんなにやさしくすることではないし、成り行きにまかせることでもない。ポイントは、一日中つきっきりであれこれ指示せず、あとでとやかく言わず、従業員を信頼して、現場の判断は現場に任せることにある。
「大逆転」
マネージャーの仕事のうち、やさしいほうは制御と調整に関係する。難しいほうは、動機づけ、調和、チームワーク、個人の成長、そして仕事に対する満足度のような人間的な配慮に関係する。模範指導型マネージャーにはとても手が回らないのが、この2番目の範疇、人間的側面なのである。
「デマルコ 大いに語る」
管理とは、社員が生産的に気分良く働けるようにする一連の触媒となる活動である。化学の触媒のように、マネージャーの働きそのものは製品にならないが、他の人の労働が製品になるために絶対不可欠である。
「デマルコ 大いに語る」
あなたが完璧な模範を示そうと頑張れば頑張るほど、部下はとてもじゃないが期待には沿えないから、初めからやってみてもしょうがないと感じるようになる。懸命に働けば働くほど、彼らの仕事の達成感を蝕むことになる。懸命に働けば働くほど、彼らはそれだけ自動機械になり、その日その日を消化するだけの最小の労力しか費やさない。
「デマルコ 大いに語る」
プロジェクト・リーダーの主たる業務は、適切な人が適切なときに適切な意思決定をするようにしむけることである。リーダーがすべてを決定する人になってはいけない。
「デマルコ 大いに語る」
一番下っ端の開発作業者が、日程遅れも品質不良もみな自分たち自身の落ち度になると知ったら、こう考えるしかない：どんな間違いだったらボスの落ち度になるのかな、と。
「デマルコ 大いに語る」
究極の管理上の罪とは人々の時間を浪費させることである。
「ピープルウエア 第2版」
管理者の役割は､人を働かせることにあるのではなく、人を働く気にさせることである。
「ピープルウエア 第2版」
みなを同等に扱うことはみなを平等に扱うことを意味しない。
「ワインバーグのシステム行動法」
中間管理職の仕事は「人を育てる」ことである。生気のない書類を作ったり、退屈な会議で半日を費やしたりすることではない。その役割は、率直な心を持って人の話を聞いたり、手助けをしたり、議論のための時間をとったりすることである。人それぞれの幸福に関心を持ち、彼らの潜在力を育成することである。
「ワインバーグのシステム行動法」
フィーディーニの手法：こみいった公式と変換で煙に巻き、じっさいになにをやっているのかわからなくする。
「ワインバーグのシステム行動法」
リップ・バン・ウインクルの手法：2年後に目が覚めて「どうしてこのプロジェクトは2年も遅れているんだ？」ということを知りたがる。
「ワインバーグのシステム行動法」
悪い兵士などいない、いるのは悪い将校だ。
「ワインバーグのシステム洞察法」
生き残るために、管理者は非難を免れるためのこつを知る必要がある。何にも優るこつは気づかないことである。
「ワインバーグのシステム洞察法」
過去の実績統計は変革のために用いられるのではなく、全てがうまくいっていることを証明するために用いられる。
「ワインバーグのシステム洞察法」
行動は早めに、かつ少しずつ。
「ワインバーグのシステム思考法」
管理者が部下を刺激するために屈辱を使うことは、部下ではなく管理者の能力不足のしるしである。
「デッドライン」
管理者の怒りと屈辱は伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる。
「デッドライン」
チームの結束については必要のない賭けはしない。既存のチームを探して利用する。
「デッドライン」
失敗した作業は早く打ち切る勇気をもつ。
「デッドライン」
戦闘が始まるときには、管理者の本当の仕事はもう終わっている。
「デッドライン」
正しい管理の本質は、適切な人材を雇用し、適所に当てはめ、士気を保ち、チームの結束を強め、維持する。
「デッドライン」
プロジェクトチームは計画を立てたのにもかかわらず、スケジュール上のトラブルが発生すると決まってその計画を放棄してしまう。問題は計画を放棄すること自体ではなく、変わりの計画を作成できないままコーディングとその修正を繰り返す状態に陥ってしまうことにある。
「ラピッド デベロップメント」
「なせばなる」姿勢は真の大惨事にいたる小さなつまづきを積み上げていくことになるのである。
「ラピッド デベロップメント」
開発速度を落とすには大きなミスを1つ犯すだけでいいが、効率的開発を実現するには、大きなミスは1つも犯してはならない。
「ラピッド デベロップメント」
ソフトウエア プロジェクトの管理にありがちの問題の1つは、特にそんなつもりもなく、計画をないがしろにしてしまうことである。
「ソフトウェア プロジェクト サバイバル ガイド」
「管理されたプロジェクト」の逆は「管理されない（自由な）プロジェクト」ではなく、「管理できない（手のつけられない）プロジェクト」である。
「ソフトウェア プロジェクト サバイバル ガイド」
