やるからには圧倒的な当事者意識と絶対に成功させるという気迫を持つ。
全てのメンバーが目的・段取りのわからない仕事をしない／させない。
プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識する。
プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。
プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。
リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは中長期的には失敗する。
メンバーの強みを見つけて伸ばすことに注力する。その強みを持ち寄ってチームで仕事をするイメージ。
一つとして同じプロジェクトはない。どれだけ成功体験を積み重ねて実績のある方法論を確立しても、常に考えて工夫して改善し続けよう。常識という思考停止をしてはいけない。
人は一人一人別人であり仕事に対するスタンスは様々だが、ほとんどの人にとって仕事はあくまで生活の手段であり、生活のイベントより大切な仕事のタスクなんてないと考える。
リソース（ヒト・モノ・カネ・タイム）が十分に足りてるプロジェクトなんてめったにない。それでも工夫と仕組みでなんとかするのがマネジメントの醍醐味。
業務システムの開発でどんだけ失敗しても人は死なない。気楽にやろう。最も大切なのは人の心。なるべく楽しくやろう。
リーダーシップやマネジメントは効果の見えづらいものだが、人の集まりである組織には絶対に必要なもの。誰にも理解されなくても淡々とやるべし。

働・学・遊・美をミックスしましょう
by 川瀬武志（コンサルタント）

フラット＆オープン

リーダー、サブリーダー、メンバーはたんなる役割であり、対等に仕事を譲り合い奪い合う関係である。
役割に関係なくお互いになんでも言い合えるフラットでオープンな関係を作ることが最も大切。
リーダー自身が自由で本音な発言をすることでしかフラットな関係は作れない。
全ての情報を全てのメンバーにオープンに。基本的にはメール・メッセージは常に全てのメンバー宛に。
情報連携はできるかぎり速やかに。リーダーとメンバーの情報格差は百害あって一利なし。オープンにできないことはやましいことである。
チーム内に何してるかわからない人がいたり、一部の人しか知らない事情があると、とても雰囲気が悪くなる。
見積り・計画・スケジューリング・アサインは全員参加で。

門限なんかできたら私が一番困る。幼稚園の子どもではあるまいし。
by 仰木彬（NPB監督）

スピード＆フレキシビリティ

やってみないとわからないことの方が圧倒的に多い。トライ＆エラー＆リスケを繰り返す。スモールスタート＆リスケジュール。
考えてもしかたないことやわからないことを考えない。下手に予測するより聞いたり試したりする方が速い。
早く失敗することは遅く失敗することよりも何倍もよいことである。
スピードとクォリティは反比例する。どんな要求にもまずは素早く対応する。
リーダーは自分の作業に集中していてもメンバーからのアクションにはすぐ応える。「今いいですか？」の答えは常に「YES」。メンバーを待たせてはいけない。

明確なのは、楽しく笑顔が生まれる環境ほど、物事は成功しやすいということだ。我々はそういった環境を作り出そうとしている。
by ジョセップ・グアルディオラ（サッカー監督）

スケジューリング

日々リスケする。プロジェクトの初日に完璧なスケジュールが引けるはずがない。実態と乖離した変化しないスケジュールは失敗の素。
スケジュールはCCPMに準拠したやり方で管理する。これが現状の把握と未来の計画が最もやりやすいやり方。
1. 個別のタスクにはバッファを積まずに最短期間とする。
2. フェーズ毎にプロジェクト全体のバッファを持たせ、人単位で管理する。
3. スケジュールには全てのタスクと人単位のバッファを掲載する。
4. 個別のタスクの長さは、日々、現状に合わせて変更する。（常にオンスケ状態になる。）
5. プロジェクトの状況把握はバッファの消費率とメンバーの稼働状態で判断する。
スケジュールとWBSは似て異なるもの。スケジュールは見易さと扱い易さが命。メンバーが手元にスケジュールを持っていないプロジェクトは失敗する。
どの時点でもどれだけ未確定なことがあっても、実際に全体のスケジュールを引いて実名でアサインしてリソースの過不足を確認することは大切。
リソースの状況に関わらず必ずやるべきことと、リソースから逆算してやれる範囲でやることを区別すること。
重要であること／ないこと・緊急であること／ないことのマトリックスを意識する。
スケジュールを変更する時は必ず担当者と話して一緒に考えること。
森を見ずに木に手をつけてはいけない。木を見ずに森を見積もってはいけない。

計画は役に立たないが、計画することは不可欠だ。
by ドワイト・D・アイゼンハワー（第34代アメリカ大統領）

アサイン

一人一人の特徴や好みに合ったアサインをすることはとても重要。
メンバーがちょっと頑張ればできるくらいのちょうど良い質量の仕事を担当させることが理想。
全てのメンバーが自分の役割と他人の役割に納得できるようになるまで見直す。
プロジェクト期間中に成長したり変化するメンバーもいる。最後まで柔軟に変更する。
経験年数や業務知識よりも、頭の良さや心の強さや柔軟さを重視する。前者は変わるけど、後者はほとんど変わらない。
ダメな人をイイ人の上につけない。年齢や役職を無視する。新人が入社初日から旧人より仕事ができることもある。
「どんな仕事でも長時間かけても平気」「面白い仕事なら長時間かけても平気」「どんな仕事でも長時間は嫌」という仕事に対するタイプを意識する。
アサインに関してチームとメンバーの利益が一致しないことはよくある。ありのままをメンバーに話して一緒に考える。
いったん良いチームができたら同じチームで様々な仕事をしていくのが理想。（とても難しいけど。）
本人がその役割を好きかどうかはとても大切。
適切なアサインができたら、チームと個人に明確に責任を持たせ、信頼し、任せる。
各カテゴリのチーム内の権威が自然にチームリーダーをするのが望ましい。
適材を適所に。それが全て。適材がいなければ始めてはいけない。
下流工程は人数さえそろえば誰でもいいというのは大きな間違い。また、レビュイーとレビュアーの比率には要注意。
少数精鋭がベスト。できる人を入れることとできない人を入れないことは同じこと。「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ。」（ブルックスの法則）

人を最もダメにするのは「全体像」を見せずに「部分的なこと」をずっとさせること。
これ続けてると何も考える力のない指示待ち人間ができあがる。こわいこわい。
by 外尾悦郎（スペイン、バルセロナのサグラダ・ファミリア主任彫刻家）

プライド

全ての人には美意識や価値観やプライドやこだわりがある。それをできるかぎり尊重し傷つけないようにする。
人が一生懸命に話をしてる時にはなるべくさえぎらない。ため息をついたりしない。
「ダメじゃーん」と言った方ががんばる人もいるし、「よくできました」と言った方ががんばれる人もいる。
いったん優秀さを信頼した人には、どーんと仕事を任せて長い目で見る。
ほめる時はみんなの前で、注意する時は一対一で。
短期的な効率よりもやる人の気持ちを優先する場面も多い。
踏んだ人はすぐに忘れても、踏まれた人はその痛みをいつまでも覚えいている。リーダー・マネージャーは常に踏む側。

腹が立ったら自分にあたれ、悔しかったら自分を磨け。
by 村上春樹（小説家）

コミュニケーション

チーム全体で話す。数人で話す。一対一で話す。それを上手に使い分けること。
状況によって話がぶれないようにする。相手によって話を変えてはいけない。
常にメンバー全員の気持ちを知っておくことは大切。定期的に一対一で話すなど。
常に明るく楽しく。仕事に負の感情を持ち込まない雰囲気を作ることが大切。
必要な話を必要なレベルで必要な人にする。相手が望んでない話を理解できないレベルでしてもムダ。
神経質な人にはおおらかに、おおらかな人には神経質に、楽観的な人には悲観的に、悲観的な人には楽観的に。
仕事でミスした人に「ミスしただろ！」と怒っても百害あって一利なし。原因や対応や予防策などを一緒に考えることが重要。
人や仕事をなめてると感じられるメンバーを見つけた時だけは厳しく。なめられてもなめてもダメ。
仕事も遊びも類友ではあるが、できるかぎり負の影響が出ないようにする。また、類友とそうでない人の意思疎通の差は要注意。
議論の対立は失敗ではない。対立を敵視すると自由な議論ができない。
沈黙を同意と思ってはいけない。多くの場合、沈黙とともに問題が潜在化する。明確なYES以外は全てNOと受け取る。
全てのステークホルダーと良い関係を築き、明示的・暗黙的な期待を察知してコントロールすることを心がける。
人と人との問題は徹底的に話し合うしか解決の道はない。感情のぶつかりを恐がってはいけない。

ミスした選手に「ミスしただろ」と言ったり責めてもしかたない。本人が一番わかってる。
by ピクシー（サッカー監督）

クォリティ

目的、内容、責任の所在、〆切、優先度、質重視かスピード重視かなどは常に明確に。曖昧さを徹底的に排除する。
どんだけ簡単な話でも箇条書きや表や図にして考え、人と議論する時にはどんだけ簡単なものでも良いので必ずなんらかの紙を用意する。
必要のない冗長性を排除する。ルーティーンワークについては、できる限り何も考えずに簡単にまわる仕組みを作ること。
成果物・タスクの粒度に注意する。一つ一つが大きいと数が減って管理しやすい。小さいと数は増えるが柔軟にアサインできたりする。
問題を相談する時は、根本原因を明確にした上で選択肢を洗い出し、最終的な自分の意志を持って臨む。
最新の問題が最優先ではない。最古の問題が最優先でもない。発生順と優先順位に関係はない。
目に見える成果物だけではなく、段取りや、会議や、議論などの質を意識する。
頑張りや心がけではなく工夫と仕組みで救う。

神は細部に宿る。
by ミース・ファン・デル・ローエ（建築家）

コスト

なにかを作るコストとそれを利用するコストのバランスには細心の注意を払う。
〆切ぎりぎりに慌ててやるのが一番コストが低い。意識的に上手に利用すること。
メンバーの作業を遮る度に生産性はどんどん落ちていく。
だらだらした会議は諸悪の根源。会議のコストは莫大であることを常に意識する。
短期的に生産性を上げる方法はない。プレッシャーをかけても思考は速くならない。過度の残業（短期を除く）は生産性を落とす。
費用的なコストだけではなく精神的・身体的なコストを意識する。サービス残業は費用的なコストをメンバーの精神的・身体的なコストに転嫁している。
全ての仕事を全力でやってはいけない。（そんなことしてたら家に帰れない。）重要度に応じてコスト配分すること。

放っておくと会議の時間の九十五％は「コメントの交換」に使われている。
これを「明確化のための質問」「代替案の提示」「リクエスト」の三つだけに絞ると面白いほど会議が前進する。
by 大橋禅太郎（コンサルタント）

リスク

フラット＆オープンの実現が最大のリスク管理（メンバーからのアラート頼み）である。
契約前にできる限りリスクを洗い出して契約に反映する。契約後にリスクを洗い出しても手遅れ。
問題が起きた時は、暫定対処をした後に何度も「なぜ」を繰り返して根本的な原因に到達するまで対処しない。
知らないことが問題になることより、知っているつもりで誤解していることが問題になることの方が圧倒的に多い。
リソースが足りなければリーダーは無力。それを闇雲に根性で埋めようとするリーダー・マネージャーが最大のリスク。
リスクのない仕事はない。リスクがあることが当たり前。リスクがなければマネジメントなんぞいらない。

たとえば、よく晴れた日曜日の朝に戦争がはじまる。
by 「ケッヘル」（中山可穂）

リーダーシップ

「いいからやれ！」というのは通用しないし、それを言う人もそれで動く人も信用してはいけない。
正直に誠実に。自分のミスは素直に認める。公平にはできないけどできるかぎり公正でありたい。
リーダーだけは結果責任。正しくても結果がダメなら意味がない。
常に問題や誤りが起きるのが当たり前。要件も見積りも常に変化するのが当たり前。問題や誤りや変化に対応することがリーダーの最も大切な仕事。
過度の残業の発生はマネジメントの失敗をメンバーに救ってもらっているということ。残業は悪ということを徹底する。
平和だったらリーダーはヒマなのが正しい。メンバーが忙しくなる頃にはリーダーの仕事のほとんどは終わってるはず。
リーダーの笑顔は義務。加えて絶対にくじけない胆力。いつでもヒマで上機嫌が理想。
どれだけオープン＆フラットを実現しても、管理者は同僚ではないし純粋なチームの一員にはなれない。これはしかたない。
メンバーからの信頼は絶対に一朝一夕には得られない。長期間にわたる日々の積み重ねでしか得られない。
個人の評価は難しく苦しいことが多いが、厳しく明白に成果の差をしっかり反映するように努力すること。
問題が起きた時には必ず先頭に立って矢面に立つ。絶対に逃げてはいけない。結果が伴わなくともその姿勢がチームの雰囲気をよくする。
外部からの雑音を遮断することは難しい。一つ一つ理論的に検証してメンバーと共有する。
旧来の悪習は自分以降の代には持ち越さないという強い意志を持つ。
リーダーの成功は優秀なメンバーに支えられている。常に感謝の気持ちを忘れない。
北風ではなく太陽でいよう。

重要なことは、正しいか、間違いかではない。うまくいくか、いかないかです。
マネジメントとは、そのようなものです。
by ピーター・F・ドラッカー（マネジメントの神様）

その他

数値はたんなる道具であり、現場の判断の材料であったり後を追うもの。数値を計測・記録する事務作業はマネジメントの本質ではない。
ウソはあらゆる面でものすごくコストの高い最悪の手段。
夕会は人気がない。朝会か午後会で。
人は変化を憎悪することが多いし、変化への基本的な反応は論理的なものではなく情緒的なものであることが多い。
ハラスメント系の問題は何もしなければ絶対に見つからない。発見するための仕組みを用意すること。
ストレスやプレッシャーは逃げると追いかけてくるけど立ち向かうと逃げていく。でもしんどい時は相談してね。

やってみせ　言って聞かせて　させてみて　ほめてやらねば　人は動かじ
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず
やっている、姿を感謝で見守って、信頼せねば、人は実らず
by 山本五十六（連合艦隊司令長官）

クロージング

評価や反省は厳しくごまかしなく。それが最も本人のためになる。
反省会は必須。記憶が定かなうちに他者も交えて反省・改善をしないとせっかくの経験がムダになる。
反省会で、全員がオープンにフラットに悪い部分も含めて相互を評価し合えたら、そのチームはうまくいったということ。
全ての項目が○な人はいないし×な人もいない。固有のミスや特定のカテゴリで人を評価しない。全期間を通したトータルで評価する。
打ち上げは必ずやる。絶対にやる。やる。

あなたに幸運の女神が微笑んだのであれば、プロジェクトは無事に完了し、幸せになれます。とてもとても幸せになれます。多くの人々は、自分では何の失敗もしていないのに、ここまで到達することができないのです。豪勢な夜を計画してください。どんちゃん騒ぎをして散財してください。そして、その時のことをいつまでも語り継げるようにしてください。
by 「アート・オブ・プロジェクトマネジメント」

ヒント１（仕事の進め方）

〆切を確認する。
成果物の内容を確認・提案して合意する。
タスクを分割してスケジューリングする。
難しいタスクの目処を早めにつける。放置してはいけない。
参考になる前例や詳しい人を探す。車輪の再発明はダメ。
定期的に報告する。ただし、困った時はすぐ報告する。

ヒント２（ミーティングのコスト）

１人が事前に１０時間かけて準備して２時間で終わった場合、５０人時間。
だれもなにも準備せず５時間かかった場合、１００人時間。

この５０人時間の差が大規模で長期間のプロジェクトの場合に大差を生む。

ヒント３（生産性）

２０人のチームの場合。

各人の生産性が１０％上がったら、２２人分。
各人の生産性が１０％下がったら、１８人分。

この４人分の差が大規模で長期間のプロジェクトの場合に大差を生む。

ヒント４（報告メッセージ／メール）

ミーティングと同じようにコストを意識する。読む人の時間をムダに奪ってはいけない。

目的を明確に。問題提起なのか周知なのか依頼なのかメモ（エビデンス）なのか。難問だったり緊急なら直接話そう。
必要のない重複を削ってなるべくサイズを小さくシンプルにする。時間をかけられる時の方が十分な推敲で文章が短くなるのが正しい。
リーダーは結論だけを知りたい。サブリーダーはその経過も知りたい。他のメンバーは具体的なやり方まで知りたい。だからその順番で書く。
文章だけのメッセージでもレイアウトとマトリックスを意識する。例えば「ＡはＢでＣはＤで」みたいな部分は箇条書きにする。
「ご連絡」とか「お願い」というタイトルはダメ。検索できるとはいえ後から探すコストはバカにならない。

ヒント５（オンライン 反省会）

反省会は、社内グループウェアのメッセージ機能を使って、こんな感じでやってます。

全員がなるべく全員の良かったところと悪かったところを書く。
プロジェクト全体やお客さんや会社についてもなにかあればなんなりと。
非定型に自由にコメントＯＫ。気付いたことがあれば数年後でも書き込みもＯＫ。

オンラインで反省会をする理由はこんな感じ。

声の大きさや考えるスピードの影響が少ない。
その場の雰囲気や感情に流される確率が低い。
自分のペースでじっくり消化・表現できる。
場所とか時間とかの制約がない。
完璧な記録が残る。

ヒント６（ファイアー プロジェクト）

ファイアープロジェクトに助っ人参戦した場合にどうするか。原因のほとんどはマネジメントもしくはコミュニケーション。

全てのメンバーと１：１で話をして問題や要望を挙げてもらう。リーダー、サブリーダーからは出てこない様々な話が出てくるはず。
面談でキーマンが浮かび上がってくるのでアサインを見直す。ただし、人を腐らせて雰囲気が悪くならないように細心の注意を払う。
スケジュールに全てのタスクと全てのメンバーの空き工数を記載し、進捗もぴったり現状に合わせて状況をはっきりさせる。
リソース不足や課題が出てきたらすぐに手を打つ。スピード感が変わったことを印象づける。
マネジメントの問題だった場合はメンバーに「君たちの問題ではないよ」と明確に伝える。

２０人程度のチームならこれらを１～２日で終わらせて雰囲気を一新する。あとはふつーのマネジメントへ。

ヒント７（ヒューマン スキル）

ヒ

Permalink | 記事への反応(0) | 22:54

2015-12-29

■http://anond.hatelabo.jp/20151229193840

プロジェクトによりけりだろうね。

ブルックスの法則は、常に当てはまるとは言っていない。

往々にしてそうなりやすいというだけの話だから。

Permalink | 記事への反応(0) | 21:55

■遅延したプロジェクトに人を投入すると遅延が拡大する（ブルックスの法則）

っていうけどさ。

じゃぁ遅延したとき、どうするのが正解なのよ？

日程延ばすか、機能を落とすか、品質を諦めるかなんだろうけど、どれもムリっていわれるじゃん。

じゃぁ、増員して独立性の高いタスクを割り振るぐらいしかないんじゃないの？

テスト工程など、教育コストが低そうなタスクやってもらうぐらいでしょないの？

Permalink | 記事への反応(1) | 19:38

2015-11-15

■遅延したプロジェクトに人を投入すると遅延が拡大する（ブルックスの法則）

っていうけどさ。

じゃぁ遅延したとき、どうするのが正解なのよ？

日程延ばすか、機能を落とすか、品質を諦めるかなんだろうけど、どれもムリっていわれるじゃん。

じゃぁ、増員して独立性の高いタスクを割り振るぐらいしかないんじゃないの？

テスト工程など、教育コストが低そうなタスクやってもらうぐらいでしょないの？

Permalink | 記事への反応(2) | 17:27

2015-04-04

■ブルックスの法則

「遅れつつあるプロジェクトに人を追加するとさらに遅れる」という法則。

仮に２名追加するとして、その人たちの教育のコスト、３名でやっていた作業を５名でやるので、作業のやり直し分割のコストなどがあらたに発生し、それらのコストはあらかじめ見積もられていなかったので、結局期日通りに完了はしないのである。6名追加する場合は、さらにそのコストは増加する。

Permalink | 記事への反応(1) | 11:36

2015-01-28

■http://anond.hatelabo.jp/20150127233249

システム開発の場合、建築等と違って人が増えると逆に仕事が進まなくなるという現象（いわゆるブルックスの法則）があるので、

大規模化すればするほどそれだけでプロジェクトは困難になる。

Permalink | 記事への反応(0) | 00:30

2013-06-12

■SIerに向いていない人の特徴

拝承できない人の特徴は、よくネットやテレビで見かけますが、SIerに向いていない人の特徴　はあまり見かけたことがないので、10個挙げてみました。

ウォーターフォールがバカみたいに思える（Excel ガントチャートの欠如）
自分がやっていることを人に知られるのが好き（コードの共同所有力の高さ）
放っておいてほしい（自己組織化）
元請けを尊敬したことは一度もない（下請け力の弱さ）
遅れているプロジェクトは人員を追加してやるより、一人でやったほうが質も高いし早いと思っている（ブルックスの法則）
チームを信頼しなかったことなどない（協力すること）
最初にたてた計画を厳守しない（アジャイルな計画づくり：現実と向きあう）
プロセスを改善する（フィードバックループ）
Excelで設計書はやれば書ける。やる気がでないだけ（Excel力の低さ）
口には出さないが、実際に動くソフトウェアにはExcel 設計書にはない価値があると感じている（Excel 設計書知らず）

いくつか似たようなのが含まれてますけど。

過去に出会った人々（自分も含め）の中で、「SIerに向いていない」と思った人々の特徴をあげていってみました。さすがにこの特徴を全て満たしている人には会ったことないですが、近い人はいた気がします。（自分も含め）

協調性とかコミュニケーション力に起因する項が多めですね。

あくまで「SIerに向いていない」なので、納品しない受託開発などの場合にはこの限りではありません。

他にもたくさんあると思うので、これぞという特徴を思いついたらぜひ教えてください。

http://anond.hatelabo.jp/20130611130854

http://anond.hatelabo.jp/20130611231619

Permalink | 記事への反応(0) | 23:00

2012-01-27

■http://anond.hatelabo.jp/20120127061544

「人数増やすと…」について補足。

http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1

スケジュールが遅れているソフトウェア開発プロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる。これを「ブルックスの法則」という。この大幅に遅れることの原因は、新しく参加するプログラマがプロジェクトについて学ぶ時間が必要となること、およびプログラマが増えることでコミュニケーションのオーバーヘッドが増えることである。N 人の人々が自分たちの間でコミュニケーションをとる場合 (階層的な組織を構成していないものと考える) 、N が増加すると、彼らの生産量 M は減少する。生産量 M が負の量になることさえ起こりうる (例えば、ある日の終業時点における全ての残務作業量が、その日の始業時点における全ての残務作業量よりも大きい場合——たくさんのバグを作りこんでしまった場合など) 。
グループ内のコミュニケーション量の公式: n(n − 1) / 2
例: 50人のプログラマ -＞ 50(50 − 1) / 2 = 1225 のコミュニケーション経路

今回のケースでは、60人が1300人になったので、コミュニケーション量は約477倍になるわけだ。

Permalink | 記事への反応(0) | 21:36

2009-12-14

■http://anond.hatelabo.jp/20091214195946

ブルックスの法則

人月の神話は古典だけど今でも面白いので読むと良いよ

Permalink | 記事への反応(1) | 20:02