その他の管理: 2007年9月アーカイブ
必要なのはツールを増やすことではなく、またツールを特効薬と信じる管理者を増やすことでもなく、入手するツールからもっと多くの利益を引きだす管理方針なのだ。
「ワインバーグのシステム変革法」
設計が解決しなければならない矛盾（パラドックス）がまるっきりないなら、あなたは問題を理解していないのだ。
「ワインバーグのシステム変革法」
設計が障害を起こしてしまう環境を三つ考えつかなければ、その設計についてまだ検討が足りないのだ。
「ワインバーグのシステム変革法」
計画は、敵の最初の一手までは有効である。----チェスの格言/軍事の格言
「ワインバーグのシステム変革法」
管理レビューは、管理層への輝かしい報告ができないプロジェクトを懲罰する方法として、非難文化において愛好されている。
「ワインバーグのシステム変革法」
ソフトウェア工学管理は一連の選択であって、一連の強制ではない。良いソフトウェア工学管理とは、ベストプラクティス曲線上かその近辺にある。変数間のもっとも望ましい取捨選択（トレードオフ）を表すある地点に留まる能力のことなのである。
「ワインバーグのシステム変革法」
工学とは、ある環境下でできるだけ多くを獲得するアートであるから、欲しいものすべては獲得できないときにこそ行使するものなのだ。工学とは、何かをあきらめる代わりに何を獲得するか、それはなぜかについての意識的な意思決定を意味するのである。
「ワインバーグのシステム変革法」
システムは、外部要因を無視しようとはするが、まったくは無視しきれない。組織はふつう外部要因を排除して、「いままでの状況」に戻ろうとする。というのも、サティアが言うように、
慣れは、つねに快適さより強力である。
「ワインバーグのシステム変革法」
こういった状況の難しさは、状況それ自体にあるのではなく、その状況が発生しているコンテキストにある場合がほとんどです。問題の発生がプロジェクトの終盤に近づいているほど、チーム（またはPM）の士気が低下し、問題への対処が難しくなっていくのです。プロジェクトが終盤に近づくにつれて、こういった問題を解決するための手段が少なくなっていく上、そのコストも高くなっていくためです。
「アート・オブ・プロジェクトマネジメント」
気をつけるべき最後の点は、結果ありきの調査です。何かを理解しようとすることと、特定のお気に入り理論を裏付けようとすることとの間には、天と地ほどの差があります。
「アート・オブ・プロジェクトマネジメント」
ほとんどの難しい意思決定において、問題となるのは調査やデータの欠如ではありません。どれだけ情報を持っていたとしても、難しい意思決定というものはこの世から無くならないのです。
「アート・オブ・プロジェクトマネジメント」
懸案事項の効果的なマネジメントは、純粋にやる気の問題となります。誰かが問題になりそうなものごとを調査し、それを文書化するために時間を割かなければならないのです。ここには何の仕掛けもありません。いったん文書化されれば、優先順位を付け、誰かに割り当て、解決することができるのです。
「アート・オブ・プロジェクトマネジメント」
技術革新は滅多なことでは起こらない。技術革新は短期的には過大評価され、長期的には過小評価されるものである。顧客という視点をトレンドという一時的流行に対する切り札とするべきである。
「アート・オブ・プロジェクトマネジメント」
予算管理はいやでもやらざるをえない。それはたしかに必要だが、巷に氾濫するプロジェクト管理の教科書がのたまうごとく、それがすべてではないし、肝心かなめではない。
すべてにして、肝心かなめのもの、それは挑発だ！
「知能販のプロになれ！」
広告の神様デービッド・オグルビーはこう言っていた。「うちの会社がやっていることは２つしかない。お客さんに尽くすこと、人材を育てること、その２つだけだ」
私が付け加えることは何もない。
お客さんに尽くす。
人材を育てる。
あなたはこの２つを、プロジェクトを通じてやるしかない（願わくは、すごいプロジェクトでありますように・・・・・・）。
「知能販のプロになれ！」
「構えて撃ってから狙え」---ロス・ペロー
「セクシープロジェクトで差をつけろ！」
『プロジェクト管理のエクセレンス』という本を読んでいると、あくびが出てくる。プロジェクト管理とは、これほど眠くなるものなのか。どの本を読んでも、似たようなことしか書いていない。みんな、そう思っているのだろうか。私は違う。私は、プロジェクト管理とは、胸がどきどきわくわくし、鳥肌が立ち、髪が逆立ち、血が騒ぐ、カッコいいものだと思っている。
そして、プロジェクトの実行段階では、「試作に狂う」ことほどカッコいいことはない。
「セクシープロジェクトで差をつけろ！」
フォーチュン誌は1998年、全世界を対象に「最も尊敬される企業」のアンケート調査を行い、その結果、尊敬される企業と尊敬されない企業の特徴がはっきり出た。同誌によれば、リスクを最小限に抑え、命令系統を尊重し、上司の顔色をうかがい、予算を重視するするのが、尊敬されない企業に共通した特徴だという。
「セクシープロジェクトで差をつけろ！」
ソフトウエア開発の経済的側面のうち重要な事柄の1つは、労力と規模の関係がスケールデメリットを示していると言うことです。…大半の製造プロセスとは逆に、ソフトウエアを作れば作るほど、単価が上昇します。
「ソフトウェア プロジェクト管理」
デスマーチ・プロジェクトが長期にわたると、例えば「優秀な人がだんだんいなくなり、いずれ会社がつぶれる」のように、ネガティブな雰囲気が醸成させるのが普通だ。しかし、この手のデスマーチ・プロジェクトは、なぜ実現不可能なスケジュールや予算を設定したか質問できる雰囲気にはない。
「デスマーチ」
「ヒステリックな楽観主義」とは、これまでに開発経験が無いので、どう見積もっても３年はかかる複雑なシステムなのに、うまく行けば９ヶ月でできるとプロジェクトの全員がやけくそで信じようとする状態を言う。
「デスマーチ」
真のボトルネックは、プロジェクト管理の革新なのだ。
「プログラマーの復権」
成功のためには、プロジェクトに携わる人々の質、及びその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因である。
「人月の神話」
定例会議に注意すること。定例会議がそれ自身がもたらす損害に値するものかどうか確かめること。
「デバッギング ザ デベロップメント プロセス」
どこにいるのか知らなければ、地図はまったく役に立たない。
「ソフトウェアインスペクション」
どんな処方にも二つの部分がある。その一つは薬、もう一つはそれが正しく使われることを保証するための方法だ。
「コンサルタントの秘密」
ある方向に動けば、別の方向についてコストが発生する（トレードオフ）。
「コンサルタントの秘密」
政治問題には政治的解決策を；技術問題には技術的な解決策を。
「ソフトウェア開発プロジェクト技法」
目標は夢物語とは違う。達成が不可能なことを目標に掲げれば、従業員はしらけるだけである。逆に、現実的に目標を明確にすると、びっくりするような成果が出てくる。
「大逆転」
個々人は技量を求めて努力し、よいスキルを積み重ねるが、組織はそれらを規則にすることができるのみである。危険なのは、この規則化である。
「ピープルウエア 第2版」
お粗末な管理は他のどんな要因よりもソフトウエアのコストを急速に増大させる。
「ワインバーグのシステム行動法」
官僚制のある定義は「一つひとつは管理されているが、全体が管理できていない」。
「ワインバーグのシステム洞察法」
Xドルの損失はいつでも財務上の責任がXドルを超える取締役の責任である。
「ワインバーグのシステム洞察法」
フィッシュボーン図を展開する活動のほうが出来上がった図よりもずっと重要である。図表は重要ではない、図表を作ることがすべてだ。
「ワインバーグのシステム洞察法」
地図と土地とが一致しないとき、つねに土地を信じよ。
「ワインバーグのシステム洞察法」
恐るべき推論：プレッシャーや残業を使う本当の理由は、プロジェクトが失敗したときにごまかすためかもしれない。
「デッドライン」
新しい仕事を引き受ける意欲のある結束の硬いチームは、プロジェクトの成果の一つと見なす。
「デッドライン」
成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。
「デッドライン」
最良のプロジェクトは、必ずしも最先端の方法論や広範な自動化またはツールを備えているとは限らない。実際に頼っているのは、強力なチームワーク、プロジェクトのコミュニケーションあるいはプロジェクトコントロールといった基本的な原則である。優良な組織と管理のほうが、技術よりもはるかに重要な成功要因であるように思える。
「ラピッド デベロップメント」
重要なことは２つしかない。1つは顧客、もう一つは製品である。顧客を大事にすれば、彼らは再び戻ってくるだろう。製品を大事にすれば、顧客は戻ってこない。
「ラピッド デベロップメント」
プロジェクト チームの全員が、各段階の最後にソフトウエアを出荷可能な状態にすることを最優先の課題として扱うべきである。
「ソフトウェア プロジェクト サバイバル ガイド」
以前Algolというプログラム言語を設計したチームに与えられた助言をここに紹介する。「完璧」にこだわると「優良」というレベルさえ達成できなくなってしまう。
「ソフトウェア プロジェクト サバイバル ガイド」
変更の管理とは、必要な変更は全て行うが、その際、変更の影響をプロジェクト全体に周知徹底することである。
「ソフトウェア プロジェクト サバイバル ガイド」
