まくろぐ
更新: / 作成:

感想

マネージャー、リーダーの立場にある人にはぜひ読んで欲しい本です。 ずいぶん前に書かれた本ですが、ソフトウェア開発の本質は「人」であるということを訴えているバイブル的な書籍であり、その内容は色褪せることがありません。

多くの企業が生産性について誤解している部分を「人」を中心に解き明かしていきます。 **オープンすぎるオフィスレイアウト**、**リーダーとの進捗確認になってしまっているチームミーティング**、**競争心をあおいでしまう管理者**など、誰しも心当たりのありそうなことをはっきりダメなものと指摘しています。

21世紀に入り、「オープンなオフィスはよいものだ」というおかしな風潮が広がってしまったように感じます。 世の中の「できる」ソフトウェア開発者はそのような盲目的な考え方が間違いであることを認識しているはずですが、オフィスのレイアウトをオープンなものに変えようとする人ってプロのプログラマーじゃないことが多いんですよね。。。 この本がもう一度見直される日が来ることを願ってやみません。

抜粋&メモ

  • 担当者が自分で作り込んだ問題を摘出した場合でも、「よくやった」と誉める。
  • 管理者は、むしろ働き過ぎないように、時折、気を配らなければならない。こうすると、すばらしい仕事がどんどん出来上がる。
  • 本当に人を知る管理者は、ユニークな個性こそが、プロジェクト内の不思議な作用を活発にし効果的にすることをよく認識している。
  • プロジェクトチームを結束させる能力のある人は、普通に仕事をする人の二人分の価値がある。
  • 生産性を論じるときは、退職問題に触れないと全く意味がない。生産性を上げると退職率も上がる危険がある。
  • コストは全体のコスト、つまり、退職者の補充に費やした余計な費用を含むべきである。
  • 早くヤレとせかせれば、雑な仕事をするだけで、質の高い仕事はしない。
  • チームワークのよいチームの管理者は、チーム内のお荷物的な作業者に対してどなりたい気持ちをぐっと我慢している。
  • 目標値の設定者は以下の順で生産性が高い。
    1. 目標なし
    2. システムアナリスト
    3. プログラマー
    4. 管理者
  • 生産性向上の問題は、安易な解決法では手に負えない。そんなものは、すべてとうの昔に考えられ適用されてしまった。よい実績は、効果的な人の扱い方、作業場所は社風の改善などの手段を講じることで得られる。
  • 開発者の主な仕事は、ユーザー流の表現で表したユーザー要求を、厳密な処理手順に変換するための、人と人とのコミュニケーションである。これは絶対に必要な仕事であり、自動化できるはずがない。
  • 管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。
  • 企業におけるプログラマーの能力差は10倍あるといわれている。しかし、企業自体の生産性にも10倍の開きがある。
  • 作業環境と生産性の相関関係は極めて顕著である。以下のオフィス環境を考慮すべき。
    • 一人当たりのスペース
    • 十分に静かか?
    • プライバシーは十分か?
    • 電話の呼出音を消せるか?
    • 電話を他へ転送できるか?
    • 無意味な割り込みが多くないか?
  • 現在のオフィスを今はやりの「開放型オフィス」に変える場合、その前にプログラマーの生産性への影響を十分に調査する必要がある。
  • プログラミングコンテストの結果を総合すると、参加者の58%が現在のオフィスは騒々しいと考えており、また、61%が個人の場所がなく、プライバシーが脅かされていることに不満を感じている。さらに、54%が自宅には会社よりもずっとよい作業場所がある、と回答している。
  • 「オフィスは騒々しい」と回答したプログラマーは、「自分は不良を作り込む可能性が高い」と公言しているのに等しい。
  • 特定の作業に対して投入された時間の総合計を集計しているところはあるが、これだけでは投入時間の質は不明である。
  • どんなものでも、計測しようと思えば必ずできるし、測定しないでいるよりもずっとよい。── ギルブの法則
  • 困ったことに電話の弊害にはみんな慣れてしまい、誰も気にしなくなってしまった。
  • 精神集中して仕事に没頭したいときには、かかってきた電話を無視できるような、現実的で効果的な方法を考えなければならない。
  • 前面8フィート(2.4m)以内にめくら壁を設けてはならない。8フィート以内にめくら壁があると、目の休まることがない。
  • 窓から外の景色を見えないような部屋は、凶悪犯をぶちこんでおく刑務所と変わりない。
  • もし、彼が最初からその仕事に適していなければ、変化は決して起こりえない。
  • 力のある管理者は、チームのメンバーが頭を丸坊主にしようがネクタイをしめないでいようが一向に気にしない。チームの誇りの対象は、チームメンバーが成し遂げた成果だけである。
  • 成功する管理者の多くは、局所的なエントロピーを大幅に下げる。── 組織は死後硬直を起こしているかもしれないが、その一部であるプロジェクトは生き生きとして活動することができる。
  • 応募者に過去の仕事について聞くのはよいが、見せてほしいというのはよくない、といった不文律があるようだ。だが、要求すれば、応募者はほとんど例外なく喜んでサンプルを持参する。──求人側が応募者に成果一覧表を持参するよう支持することはあまりないが、なぜそうしないのだろう。
  • 能力テストは、従業員の「自己」評価には素晴らしい道具だ。
  • 失敗の最もたるものは移転だ。退職がどんなに高くついたか信じられないだろう。
  • 最良の組織は、意識的にベストになろうとして奮闘する。これは、全員に共通した目標であり、これによって、共通の方向づけ、共に分かち合う充足感、および強力な結束効果が生まれる。
  • 退職率が最も低い会社に共通した特徴は、生涯教育プログラムの充実である。
  • 書類の山は災いをもたらすだけで、問題の解決にはならない。
  • 作業規定が示す全くその通りに仕事を行えば、仕事はほとんど止まってしまう。
  • ソフトウェア業界全体では、新しいアプローチを探し求め、それを自社内でやってみたこともないのに、規格として強制するようなことが広く行われている。
  • 人は、他と違った扱いを受けることに魅力を感じ、注目されることを好み、珍しいものに好奇心をよせる。これはその後、ホーソン効果と呼ばれるようになった。つまりホーソン効果は、人は何か新しいことをやろうとしたとき、それをよりよくやろうとする、ことを示している。
  • 挑戦はチームのメンバーに一緒になって努力する目標を与えることからこそ重要なのだ。──人は最良の仕事仲間を持ったとき、愉快な気分になるし、力の限りを尽くす。
  • 結束したチームは、生意気で、自己満足的で、神経を苛立たせ、排他的かもしれないが、管理者の真の目標に対しては、交換可能な部品の集まりのようなグループが果たすよりも、はるかに、大きな役割を果たすことは間違いない。
  • 陰険なイメージをふくらませるために、チームのメンバーは黒い服を着用しはじめた(ここから黒集団の名がついた)。プログラムがテストに引っかかると恐ろしい声でケタケタ笑った。
  • 与えられたグループでやっていこうといったん決めたならば、最良んの戦術は部下を信頼することである。
  • 少しはミスをさせたらよい。
  • 自己防衛的な管理手段の中で最も明白なものは、作業規定マニュアルと、管理者による技術的な干渉である。この2つが揃えば、プロジェクトは長期的に見て失敗する運命にある。
  • 隣にいる他のグループの作業者は、騒音と分裂の源である。作業者が同じチームにいるときは、同じ時間帯では静かにすることとが多いから、精神集中を妨げられることも少ない。
  • 複数の結束したチームに同時に身を置くことはできない。時間を分断されたらチームは結束しない。
  • まやかしの製品を開発している開発者同士は、互いに視線を避けるようになる。自分たちがやっていることをやめられるなら、救われた気持ちになると、みんなが感じている。
  • 部下に自分の評価の一部を委ねていることは、少々乱暴で恐ろしいことと思うかもしれないが、それがみんなに最善を尽くさせる道なのだ。
  • どの地位の人も、どんな不服従が許されるかよく知っている。──判断を誤っても、部下は自分たちのことを考えてくれるその管理者を支持するだろう。
  • 自分が働きたいと思っている人と仕事ができる方が重要だったのだ。
  • 品質至上主義は、世間一般からチームを際立った存在にするので、チームを一つに結束させる役割を果たす。
  • 「不器用な作用」を醸し出すがうまい管理者は、仕事をいくつかに分割し、その一つひとつが、それなりに完成感を味わえるようにする。そんな管理者は、上級管理者やユーザーには、せいぜい2つに分ければ十分な仕事を、20ものバージョンに分けるように工夫する。──分割した新バージョンは、要するに打ち上げ用である。
  • 成功する管理の本質は、みんなを同じ方向に向かわせ、管理者でさえ前進を止められないところまで燃え上がらせることにあるのだ。
  • プロジェクトが完了した際には、少なくとも他のプロジェクトを選択する余地を与えるべきである。
  • 恒久的なリーダーは、やがて仲間として扱われなくなり、チームメンバーとの相互作用は崩壊しはじめる。
  • プロジェクトを、新しい技術を用いた試行プロジェクトとして実施した方が、費用が少なくて済む可能性が高い(生産性が上がる可能性が高い)。
  • 試行プロジェクトの賢明なやり方は、一部分だけを新しい方法でやってみることである。
  • 人は、期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りできそうもないことがわかったときに、非難から身を守るためにそれをやるのだ。
  • チーム内の競争は、コーチングを困難にし、または不可能にするという直接の影響がある。──管理者が、何かチーム内の競争心をあおるようなことをしたら、チーム殺し的と見なければならない。
  • 真の利益をもたらすプロジェクトのすべては、それと共に真のリスクを伴うものだ。
  • 組織が「成熟」するにつれて、次第にリスクを避けるようになる。CMM のレベルが上がったことを証拠で示せ、との厳しい監視の下にいる組織に、真の挑戦は期待できそうもない。
  • 最もやる価値のあるプロジェクトとは、それはあなたのところの(CMM の)レベルを一つ完全に下げざるをえないプロジェクトだ。
  • サタイア・モデルがきわめて重要な理由は、「混乱」が変化には絶対必要な部分であることを、我々に認識させたことである。素朴な第二ステージだけのモデルでは、混乱を予期しない。それが起こると、それを「新しい状況」になったものと誤解してしまう。
  • 逆説的に、変化は、もし失敗──少なくともちょっとした失敗──が、成功と同じように許される場合のみ、成功の可能性がある。
  • 中間管理層の強力なリーダーシップがあって、はじめて学習センターは成功する。
  • 管理における究極の罪は、人の時間を浪費することだ。
  • 現状を把握するためにはミーティングは必要ない。現状把握だけの問題なら、他人の時間の浪費をもっと少なくする方法がいくらでもある。
  • 本当に有効な会議は、出席者全員が一つの問題を一緒に討議する必要がある場合に開く。ミーティングの目的はコンセンサスにたどり着くことだ。そんな会議は、定義からも明らかなように、臨機応変に開く。臨機応変ということは、定期的ではない。
  • 設計作業は、集中しなければならないし、作業場所が静かで、少人数での密度の高い会話が必要。

関連記事

まくろぐ
サイトマップまくへのメッセージ