Booklog - ピープルウエア ヤル気こそプロジェクト成功の鍵 第 3 版
Tom DeMarco, Timothy Lister, 松原友夫, 山浦恒央, 長尾高弘
まえがきと目次。 本書ではシステムの仕事の社会学的な側面を考察する。 目次を見るに、人・環境・チームみたいな軸の話みたい。 解説もつまみ読みしたがちゃんと解説していて良い。 版を重ねるごとに内容も増えていて、第 3 版が 2013 。あと数年で 4 版が出てもいい頃合いか。 本書ではウェアじゃなくてウエアが正式名称なのでそれに倣う。
2025-09-17, read count: 1, page: i ~ xx, pages read: 20
第Ⅰ部 人材を活用する。部品と違って交換不能な人的資源の扱い方について。 第 1 ~ 3 章。 ピープルウエアプロジェクトの調査対象のプロジェクトの 15% 、大規模プロジェクトだと 25% が完成しなかった。 いずれも失敗の原因を技術的要因と片付け、人に関する問題を軽視していた。マネージャーの多くはこういった人の問題に対処するすべを学んでいない。 システム開発のプロジェクトのように頭脳的な労働はチーズバーガー生産販売哲学のように何も考えずにとにかくマニュアル通り手を動かして解決できるものではない。 メンバーの個性を活かす・チームの結束を高めたり考える時間を確保する必要がある。 人の創造性を活かして生産性を生むのでなく、人から生産性を搾り取る方法だと、過度の残業からワーカホリックにつながり、プロジェクトを追えた暁にはメンバの離脱という付けを払うことになる。 平均的なソフトウェア開発者は読書しない、ってのも含め今も変わらないことが散りばめられてるな。時代を超えて変わってないのが笑える。 これは面白くて良いわ。
2025-09-18, read count: 1, page: 1 ~ 20, pages read: 20
第 4 ~ 6 章。 提供する品質を顧客の要求レベルに応じて下げることがヤル気を削ぐ要因になる。 パーキンソンの法則に従ってスケジュールを切り詰めるといった誤った目標設定はヤル気を削ぎ生産性を下げる。 生産性を渇望するあまり証拠に基づかない手法に飛びつくのはマネージャの仕事ではない。やるべきなのはメンバーを働く気にさせること。 日本が高品質で生産性が高いって話が載ってるが、わたしの 2000 年代の SES 経験では全くそんなことはなかったな。 20 年近く空いてるから時代が違うのかな。 無茶なスケジュールで走るより目標を設定しない方が生産性が高いというのは、経験上メンバーに自律性がないと上手くいかないけど、同意できる。
2025-09-19, read count: 1, page: 21 ~ 38, pages read: 18
第Ⅱ部 オフィス環境と生産性。 第 7 ~ 8 章。 環境がプログラマーの作業効率に与える影響について。 集中を途切れさせて作業を中断しうる要素が作業効率を下げる。 往々にしてマネージャーは環境の改善に無頓着。 プログラマー個人の能力差より、良い環境を提供する文化に属していることが、生産性の高さにつながる可能性がある。 リモートワークで快適な作業環境を得るまでは、洒落たフリーアドレス、電話当番兼務、折りたたみ机とパイプ椅子、と色々体験してきた。 その経験から、リモートワークは緊急対応や密なコラボのような祭りには向かないけど、平常時の作業効率は段違いに高くできると実感している。
2025-09-20, read count: 1, page: 39 ~ 56, pages read: 18
第 9 ~ 10 章。 オフィス投資をケチって開放型オフィスにプログラマーを鮨詰めにすると、騒音レベルが上昇し、作業能率を著しく阻害する。 環境と作業能率の関係に気づかないのは、そもそも真面目に計測したことがないから。 フロー状態≒頭脳労働時間を計測することが重要。割り込みのない時間の係数を求めることで、環境を評価できる。 また頭脳労働時間でなく勤務時間≒肉体労働時間でプロジェクト進捗を分析した場合、それは意味のない危険なものになる。 時代の変化もあろうけど、なんとなく目的なしに異種交流を狙った開放型オフィスや出社強制が多い。 本当に集中すべき時とイノベーションにつなげたい時を区別するのに難あるのかな。
2025-09-21, read count: 1, page: 57 ~ 77, pages read: 21
第 11 ~ 12 章。 中断の最も多い理由は電話。メールなら受信側がいつ見るか選べるが、反面メッセージがいつ伝わるかという点で信頼性に劣る。 ケチって開放型のオフィスにしたとか見せかけの活気を求めて BGM を流すとかの画一的なオフィスよりも、目的ごとに区画が分かれたオフィスの方が良い意味で独創的なアイディアがでるだろう。 人それぞれ快適なオフィスが違うのだから、好きにさせておくのがマネージャの仕事。 現代なら電話以外にも音声チャットやビデオチャットというところか。 わたしは音声通話も mention も自分のタイミングでしか応答しない(というかミュートしてて気づかない)ので表明しててかつ許されてる方なのだろうな。
2025-09-22, read count: 1, page: 78 ~ 91, pages read: 14
第 13 章。 活気のあふれるオフィスを作る手段として、アレグザンダーのパターンに基づく手段がある。 本書では基本のパターンを補うオフィス設計の 4 つの失敗を是正するパターンを提案する。 過度の個室を避ける・窓を多くする・屋内と屋外スペースの調和・共有スペースといった具合に。 画一的なオフィスから抜け出して、個性的なオフィスを作ることが活力につながりプロジェクト成功の可能性を高める。 本書で言うようなうまく設計されたオフィスで働いたことがないのでなんとも実感がわかない。 ただ画一的で窓がなくてしかも天井が低くトイレも少ない現代的なオフィスは経験がある。 すし詰めでかなり苦しかったので、そこを抜け出すのは妥当な気がする。
2025-09-23, read count: 1, page: 92 ~ 104, pages read: 13
第Ⅲ部 人材を揃える。 第 14 ~ 15 章。 無個性な駒で机上の戦争ゲームを考える戦略家としてのマネージャーの役割ではなく、人材を揃え辞めないようにする原則に基づく手法を紹介する。 親が子供を何年もかけて育てるのと違い、マネージャーは人材を選ぶ必要がある。 企業文化にあう均質な人材を選ぶのは不健全で、標準から外れても優秀な人材を選び、彼らの力を発揮させる必要がある。 リーダーシップは、権力による後押しで仕事をさせるのではなく、率先してリードし周りの触媒となるのが主たる役割。 人材の選択やリーダーシップに関しては、まだ本書で言うような有機的な組織の特徴をうまく取り入れれるところは多くなさそう。 不言実行のところ、表明する暇があれば手を動かした方が速いという点でも同意できる。許可さえ貰えばあとはやる的な。
2025-09-24, read count: 1, page: 105 ~ 117, pages read: 13
第 16 ~ 18 章。 ヒトを雇う際に何ができるか実際に見ずに話だけで決めるのがおかしいという話。 また適性検査についても自己評価に利用するなら良いが採用で使うようなものではないとのこと。 これはプログラミングの心理学でも似た話があって時代を感じさせる。 人材の多様化によってチームで上手くやっていくためのランチ会などの tips 等。 あと所謂「若い世代」の注意の分散と仕事でのフロー状態の相性と仕事での注意の向け方に馴染むための話。 この世代をまたいだチームの話は最近の事情を酌んでいて面白い。似たような違いを動画で勉強するか否かでも感じる(わたしは動画を使わない)。
2025-09-25, read count: 1, page: 118 ~ 130, pages read: 13
第 19 ~ 20 章。 退職は見えるコストも見えないコストも含め無駄である。オフィスの移転も従業員に負荷を課すだけで無意味。 社内にコミュニティができることで長く続けることに繋がり、教育によって良い組織になりうる。 人的資産への投資は勘定科目上経費になるため軽く見がちだが、そうではない。 ベテランが抜けた穴を新人で埋めると生産性が回復するまでに非常にコストがかかることからも、人材への投資を回収するのが非常に難しいことがわかる。 移転の件は日本なら忌まわしき転勤も同じ悪影響があるなと思った。 ただ長く居続けられると、自律的に変化を注入することができる人も組織もそうないし、それだけ人材が均質化するから両刃の剣ではあるよな。
2025-09-26, read count: 1, page: 131 ~ 148, pages read: 18
第Ⅳ部 生産性の高いチームを育てる。 第 21 ~ 22 章。 仕事の楽しい思い出は往々にして仕事自体ではなく結束して取り組んだチームによるところが大きい。うまく結束したチームとは何か、その作り方について。 結束したチームは共通の目標を持ち、その実現に向けて協力しあう。その勢いがあるので管理は必要ない。 結束したチームは、退職率の低さ・強い一体感・選抜された意識・成果物の共有意識・明らかな楽しさといった特徴を持つ。 チームが自律的に成長し、メンバーが入れ替わってもチームのエネルギーと個性が生き続けた例として、ブラックチームを挙げる。 「結束感」みたいな感覚はもう随分感じてないな。 自分の経験では、できたてのチームというのは祭りみたいなものでそれだけで結束力があるのだけど、徐々に待遇の違いといった外圧や互いの不信で勢いが落ちていく。 チームメンバー間の信頼関係が強固ならその勢いを削がないようにできるのかなと思っている。特に根拠があるわけでない。
2025-09-27, read count: 1, page: 149 ~ 160, pages read: 12
第 23 章。 チームの育成は農業にて完全に制御できるものではない。そこで本章ではチームが自然に育つのを阻害する 7 つの要素を挙げられている。 部下の能力を信用しない守りのマネジメント。 部下に頭を使わない書類仕事させる≒官僚主義では目標の大切さは伝わらない。 チームの作業場所を分散すると日常会話から結束を育む機会が失われる。 複数のプロジェクトを掛け持ちさせるとチームとの時間も細分化され結束できなくなる。 コスト削減のために短期で製品を仕上げ品質を落とすと、チームの喜びが奪われ一体感が失われる。 マネージャーがチームにはっぱをかけるためハッタリの納期を設定すると、チームの信頼を失う。 経営陣のチームへの恐ろしく低い興味から、プロジェクト毎にチームを解散させてしまう。 妙に解像度高いのは、それだけどこでもある問題ということやろな。自分でもよくある話ばかりと感じた。
2025-09-28, read count: 1, page: 161 ~ 169, pages read: 9
第 24 ~ 25 章。 チームが自然に育つのを阻害するさらに 2 つの要素。 忌々しいポスターや会社のスローガン入り動機づけグッズは経営層の不勉強差を明らかにする。 残業で分担できない痛みが上手くいっていたチームに不和をもたらす。ワインバーグ流に言うと仕事が期限通りにいかない場合に避難から身を守る手段として人は残業する。 競争は調和の取れたチーム内のコミュニケーションを阻害する。例えば年次評価や目標管理が競争を煽る。 随分昔から評価制度と目標管理の問題点が指摘されてたのか。 なくならないのは単に経営層の興味の無さと不勉強だけのせいでなく組織的に表面的な統制が必要だからやろな。個人的に要らない派やけど。
2025-09-29, read count: 1, page: 170 ~ 180, pages read: 11
第 26 ~ 27 章。 チームのみんなで作るスパゲティディナー。生まれつきの良いマネージャーは意図せずチームが成功する小さな機会を頻繁に提供する。 マネージャーはチームのメンバーを信頼し、自主性を尊重して、部下の行動に責任を取る。 チームのメンバーは、一緒に働きたいと思える人と仕事をしたがる。これは採用についても重要な要素になる。 この点では所謂カジュアル面談は(全然隠れてない)隠れ選考として効果があるということか。
2025-09-30, read count: 1, page: 181 ~ 191, pages read: 11
第 28 章。 チーム形成におけるマネージャーの仕事は化学反応を生み出す環境を作ることにある。 高い品質を誇り、仕事を分割し達成感を味わえるようにし、チームの一員であることを特別なことのように感じさせる。 チームのメンバーの多様性を保ち、優れたチームを継続させる。 ここで言うマネージャーはリーダーシップを取らない。サーバントリーダーシップに近いのかな。 リーダーシップを取るのはチームのメンバーであるというのは、ワインバーグ氏の考え方とも合致するな。
2025-10-01, read count: 1, page: 192 ~ 200, pages read: 9
第Ⅴ部 肥沃な土壌。 チームはより大きい組織のコンテキスト≒企業文化の影響下にあることを知ってく必要がある。 第 29 章。 組織の効率化のためのシステムは、典型的な業務を念頭に置いているため、例外的な状況に対処できない。 例えば方法論がそう。方法論は平凡な社員から優れた成果を得るために上から押し付けられる決定論的な手法である。 それは人から責任と意欲を奪い、仕事を破壊する。 もし統一的な手法を広めたいのであれば、薄い標準を、研修の実施・ツールやレビューの形で緩やかに広める必要がある。 本書の時代から数十年経った現在でも「ある手法」が全てを解決するかのように話す著名人は多い。時が経っても学ばないな。
2025-10-02, read count: 1, page: 201 ~ 210, pages read: 10
第 30 ~ 31 章。 取るべきリスクを可能性を秘めた取らず、取らざるべき馬鹿げたリスクを取る会社が増えてきている。 自分達が失敗した場合に備えた代替策を管理できないのは、失敗する可能性を恐れて考えないようにしているから。 自分たちが遅れることのリスクを管理できないのは、その仕事がどうでも良いものだから。 会議をやり過ぎるか、やらな過ぎるか。会議をやり過ぎるのは、私欲・無駄話・儀式・不安などによる。 健全な会議は必要な人が必要な場で話し合うようなオープンスペースでのネットワーキングのようなコミュニケーションである。 会議多過ぎは、現代でも油断すると無策にとりあえず集まってという形でやりがちな気がする。喋り過ぎは身に覚えがあるので行動を変えたい。
2025-10-03, read count: 1, page: 211 ~ 222, pages read: 12
第 32 ~ 33 章。 マネジメント自体が時間を浪費するケースについて。マネージャー自身が儀式的な会議でチームの時間を浪費してしまう。 時間的制約が厳しいプロジェクトで、不用意に人を早期から導入し時間を浪費してしまう。どうせ遅れるなら人員の導入を断るべき。 更に導入した人員が少数精鋭メンバの貴重な時間を浪費してしまう。 E メールのお陰でコミュケーションのコストが下がったが、多くの調整メールは無駄である。 知る必要のない情報を送りつけるのは社内スパムといえる。 FYI を送らなければならない状況は組織の機能不全の傾向である。 「沈黙は同意なり」の不文律に基づく提案メールが飛び交うのは、組織の機能不全の傾向である。 わたしも関係者から意見が得られないので期限を切って沈黙は同意とみなすメッセージを送ることがある。許可だけを得るのが目的だが、もうそれすら不要なのかもな。
2025-10-04, read count: 1, page: 223 ~ 233, pages read: 11
第 34 章。 システムの仕事は人を変化させるものであり、同時に開発者も新技術や新しい手法に変化していくことが求められる。 しかし人は変化を憎んでいる。反対は情緒的なもの。変化は古い習慣の利益供与者からは反対を受け、唯一質問者だけが味方たりうる。 サティアの変化のモデルでは、必ず最初に混乱を伴うことが警告されている。 変化は人々に安全地帯から出ることを要求するが、人々は失敗して恥をかくことを恐れるため、失敗が許される環境でなければ成功することはない。 バージニア・サティアはワインバーグ氏も推してたので調べてみるのも良いかも。
2025-10-05, read count: 1, page: 234 ~ 243, pages read: 10
第 35 ~ 36 章。 組織の学習の過程で、主導する人材にだけ知識が偏る時期がある。人材が離れれば学習効果が失われるため、組織の学習能力は人材を引き止めておけるがで決まるといえる。 組織の学習の中枢は中間管理職のネットワークに置くのが良いが、中間管理職の整理で失われるリスクが有る。またマネージャーを集めただけの仮初のチームだと学習の鋳巣として機能しない。 現代では本当の意味のコミュニティは身近から消えたが、見つけられるとしたらオフィスだ。 組織におけるコミュニティは人材のエンゲージメントを高める。人がやめないので投資効果も好循環するようになる。 コミュニティの素晴らしさや学習効率が高いのはよく知っているが、ほんとにそれしかないのかなというのはいつも思うな。 仲良しクラブじゃ、あまり干渉されたくない身としては、息苦しい。
2025-10-06, read count: 1, page: 244 ~ 254, pages read: 11
第Ⅳ部 きっとそこは楽しいところ。 仕事は楽しくあってはならないとい考え方があるが、ここでは仕事は楽しくあるべきだと考え方を推す。 第 37 章。 仕事が楽しいのは混乱したものに秩序をもたらすときである。優れたマネージャなら部下にその機会を配分できる。 ここではそのような小さな混乱をチームに注入して楽しむ術を挙げる。 パイロットプロジェクト・プログラミングコンテスト・ブレーンストーミング・研修・旅行・カンファレンス・お祭り・冒険旅行。 個人的に数年前から会社が旅行とかお祭りとかを企画したら信用しないし結構断ってきた。 実際に障害対応のような緊急の祭りがチームのつながりが強くするが、それは仕事を通じてのつながりだから意味があると思ってて、先に挙げたようなのは情緒的な部分でビジネスの至らぬ点を有耶無耶にしようとしたり干渉がきつくて好かん。 仕事は楽しくあるべきというのは大賛成だが、仕事を楽しみたいのであって、今はもうお祭りを楽しみたいわけじゃないねんよな。
2025-10-07, read count: 1, page: 255 ~ 266, pages read: 12
Years (2)
Books (25)
- Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう
- People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け
- サンダー・キャッツの発酵の旅 世界中を旅して見つけたレシピ、技術、そして伝統
- サンダー・キャッツの発酵教室
- スーパーエンジニアへの道 技術リーダーシップの人間学
- ピアリング戦記 日本のインターネットを繋ぐ技術者たち
- ピクルスと漬物の歴史
- ピープルウエア ヤル気こそプロジェクト成功の鍵 第 3 版
- プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか
- プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ
- プログラミング F#
- プログラミングの心理学 25 周年記念版
- ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング
- 世界の作りおき野菜 みんなに愛される味付けの魔法
- 世界一流エンジニアの思考法
- 入門・倫理学
- 分子調理の日本食
- 型システムのしくみ TypeScript で実装しながら学ぶ型とプログラミング言語
- 実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう
- 家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99
- 本を読む本
- 演奏するプログラミング、ライブコーディングの思想と実践
- 男のスコッチウィスキー講座 100 蒸留所 巡礼試飲旅
- 習慣と脳の科学
- 魏武注孫子