ピープルウェア
以下に書く前の下書き。転記するときに厳選。
プロジェクトの失敗の原因は、技術的な問題ではなく主に政治的要因、つまり人の管理に関する問題が多い
http://bukupe.com/summary/10707
ピープルウェア
著者トム・デマルコ
ティモシー・リスター
捨てるつもりでシステムを作る
愚者は、私が恐れて近づかないところに踏み込む
優れた概念はたとえそれが企業文化に関することであっても西洋東洋問わず意味を持つかもしれない
第一部人材を活用する
第二部オフィス環境と生産性
第三部人材を揃える
第四部生産性の高い人を育てる
第五部きっとそこは楽しいところ
第六部ピープルウェアの小さな続編
印象的な言葉メモ（未整理）
■第一部人材を活用する
プロジェクトの失敗の原因は技術的な問題ではなく主に政治的要因要するに人に関する問題で起きていた
実際のところソフトウエア開発性の問題の多くは技術的とより社会学的なものである
円滑なソフトウェア開発を行うためにはチーズバーガー生産販売管理哲学の逆を行うとよい
間違い許さない雰囲気が社内にあると担当者消極的なり失敗しそうなこと絶対にしなくなってしまう多少の間違い大目に見ることによって新しい技術開発に取り組み間違いを検出し検出したことを褒めた方が良い
管理者とは人が働きすぎないように気を配るべきである
ソフトウエア開発で人と交換可能な部品とは違う
プロジェクトチーム結束させる能力がある人は仕事ができなくても2人分の価値がある
君にはちゃんとわかっている
人生には欲しいものを手に入れるか欲しいものを手に入れるか
何度も何度も全力疾走のような環境をさせることは管理者の権威を失墜させる
生産性の話を議論する時は退職に触れなければならない
生産性を向上させるために開発
機械化し品質に妥協し長時間労働強いるようなことは仕事の面白みよさげ退職率あげる危険性を伴っているのである
生産性とは利益をコストでわったものと定義すべきである退職者の補充に費やした費用も含むべきなのだ
人は実現不可能のの納期をおしつけたほうが働くというのは幻想である
早くやれと急かせば雑な仕事になるのは目に見えている
品質を犠牲にしないようにできるだけ気を使っても結果としてそうなることが多い
たいていの人は自尊心を自分の作った製品の品質と強く結びつける傾向がある
納期通りに完成するためにプロジェクト資源をやりくりする自由もない場合がある人を投入できず、機能も削れず、品質を削ることになる
ユーザーの品質意識はかなり低いことが明白である
開発者が求める品質の最低ラインは過去最高の品質である
ユーザーに品質基準を決めさせることは品質第一主義からの逃避である
それは長い目では低い品質の製品を生み出し余計なコストがかかるものである
エンドユーザーの要求はるかに超えた品質水準は生産性を上げる1つの手段である
価格と品質はトレードオフの関係にあるという考えが日本には存在しない
高品質がコスト低減もたらして考えた広く受け入れられているのである
パーキンソンの法則、与えられた時間はあまらないように使うという法則は実際の作業者には当てはまらない
目標値設定者による生産性の違い管理者が立てるよりも実作業者が目標をたてたほうが生産性が高いことが多い、しかしさらに目標がないほうがもっとも生産性が上がるという調査結果もある
管理の本質とは人を働かせるのではなく人を働く気にさせることである、そう口を出すよりスープでもだしたほうがいい。とか。
■第二部オフィス環境と生産性
意外なことに残業の真の目的は仕事量こなせるも品質向上ためであることが多いのである
ソフトウェアの生産性日で調査するためにプログラミングコンテスト300社を超える企業の協力のもと実施した
生産性と関係ないということがわかった、プログラミング言語、経験年数、残存不良数、年収
生産性は誰とチーム組んでいるかが大きく影響する
企業におけるプログラマーの能力差が10倍あると言われているが企業自体の生産性にも10倍の開きがある
オフィスの環境の設計改善が行われてない企業からは優秀な人材が流出するため良い環境に良い人物が集まり悪い環境は悪いまま。
環境破壊し尽くした後に空見上げる人間ブルーナの小説空を見上げた羊より
広くて静かな場所であることで生産性を向上する
会社騒々しいと回答したプログラマは自分が不良作り込み可能性が高いと公言しているにも等しい危険な状態なのである
どんなものでも計測しようと思えば必ずできるし測定しないでいるよりはずっと良い
多くの管理者は自分の部署生産性についてきちんと把握していない
生産前測定値がプログラマーに心理的負担を与えたのでは意味がない、ので本人だけに開示すればよいのである
集計した平均値は公開しても良いと思われる
管理者は人事の生産者見たがるので本当はそれもほしがるが、、
プログラマはフローの状態で仕事に臨んでことが理想である
勤怠は肉体労働時間を記録し実際に集中出来ていたかはわからない
フロー状態になるには15分以上の精神集中過程が必要と言われている
割り込みなしの連続時間数記録してもらうのは良いかもしれない
3000精神集中時間が必要と見積もった場合精神集中の時間を計測するなど
環境係数=割り込みなしの時間数/机の前に座っていた時間
割り込み禁止を掲げること
仕事の時間に割り込み不可時間設ける一方で割り込み時間を作り一日3回電子メールチェックするなど。
音楽おきながら数学の宿題する場合数学および数学的思考をつかさどる大脳の部位は音楽の影響を全く受けないためである
スペース静かさプライバシを確保してやることで生産性を向上する
たゆみなき建設方法に従った建物に入ると穏やかな気持ちになる
形の合成についてのノート
デザイナー設計者のバイブルともいえるもの
各部門の従業員の相違要望に伴って建物全体の機能進化論的に変遷するということで、
メタプランの基本は以下の3つ
各部門を独立して少しずつ進化する、進化の方向決定する1連のパターンや設計計画がいる、現場で仕事してる従業員からの要望をきく
専門家にオフィスをデザインしてもらうのは良い
窓は重要な多い方が良い
屋内スペース都区外今日はも重要である
全人類共通空間が設計されていることが重要だ
■第三部人材を揃える
人材を揃える
人々に満足感を与え、辞めないようにする
人々を束縛から解放する
ホーンブロワー因子
部下が有能か無能か宿命論的な先入観で見抜く才能のことを指す
あらゆる人がなんらかの才能があるとしてもそのチームに求められる資質があるかは最初の状態が肝要である
チーム誇りの対象はチームメンバーが成し遂げた成果のみである、
そのほかは些事に過ぎない
プロらしく行えということで平均的で同じような行動を求められる
才能を見抜き平均からずれているからといって除外しない最高のチームを作ることが重要である
私のすごい芸をみないんですか？
1人に仕事サンプル持ってくるように指示する以上に懸命な能力測定方法があるだろうか？
ただ短期的に良い仕事をする人材が分かっても長期的に良い仕事をするかはわからない
今いるメンバでオーディション形式で選考するのは割と良い
退職は明らかに無駄なコスト
一人当たり立ち上がりに3ヶ月かかるとみよう
退職率の高い企業では社員が短期的に物事を考える傾向にある
みな目先の利益をみて後始末を考えず破綻する
組織論的観点から言えば昇進が遅いのは健全な印である
なぜなら退職率が低く長期的な視野に立って物事考えているということがわかるからである
退職率高い気が退縮理由は次の3つに分類できる
腰掛けメンタリティ
使い捨てされる予感
忠誠心なんて馬鹿らしい
永続性のメンタリティ
退職率低い会社で仕事をするということを調べる
そこで働く従業員関心事はベストを目指すということである
ずっと勤め続けることをれて期待されている感覚
既に技術を持った人を雇うのでなく今いる社員に再教育プログラムを施して人を育てた方が組織としての結束力が高まるのである
決定論的のシステム作るとその結果としてシステム自己修復能力を失われていく
システム化によって手作業にあった柔軟性が失われてしまうということである
人からなるチームでも他のシステムと同様にそれが決定論的になるにつれて自己修復機能を失ってしまう、作業規定書でガチガチに固められた業務の遂行等はこれに該当してしまう、結果として意味のない作業に時間を使うことに追従する...よくみられる現象でバランスが難しい。
■第四部生産性の高い人を育てる
楽しかった仕事の経験振り返ると挑戦的要素含んでいることか多い
挑戦はチームメンバーに一緒になって努力する目標与えるからだ
結束したチームをどのように作れば良いのだろうか？
チームは個人個人の力を単純に加えたものより大きな力を発揮するグループを指す
全体は部分の和より大なりの状態である
上司としてのジレンマ
個人が組織の目標受け入れる仕組みは複雑だ
会社の目標は一般社員から見ると大部分が独断的にあるとみられていることが多い
チーム編成の目的は目標の達成ではなく目標に向かって一体になることである
結果的にそれが効率の良い組織につながる
強固なアイデンティティを獲得する
チームの結束の可能性を高めるようにはできるか結束させることができない、コントロールしようとすると壊れてしまうチーム編成ではなくチーム育成について考える
発想があまりなかったのでチーム殺しの方法考えた...
チーム殺し7つの秘訣
自己防衛的な管理
官僚主義
作業場所の分散
時間の分析
品質低減製品
鯖を読んだ納期
チーム解体の方針
部下に誤りを許さないという姿勢が伝わると信頼していないっていうことも伝わってしまう
なんでもマニュアルを徹底させるとばかなのでこれなしではシステム開発できないと言っているのと同じである
官僚主義の形式主義、ペーパーワークの増大がチーム形成を阻害する
顔を合わせることがグループの結束を強める
1人の作業者が複数のプロジェクト同時に関わることがチームの結束を阻害する
エンドユーザーは品質が悪くても安くて速いものを受け入れることがあるかプログラマーにとっては苦痛である
鯖を読んだ無理な納期は部下のやる気を減らすだけだ
チームを人員の有効活用といって積極的に解体する
スパゲッティーディナーと言う仕事ではないが生産的な調和を見出す交流がある
作業の上司とは管理されていることを部下に気づかせずに同僚から幸運だと思われている人である
チーム編成の時点で最適な人を最適な職務に付けたのだから、自分でやっていればなどと考えるのはおかしな話である
後は有能な部下の行動に責任を負い能力を頼みにしてることを示してゆだねることである
専門の技術者は公でないスカンクワークプロジェクトを少しずつやる
尊敬から生まれる自然な権威で支持せよ
良いチームは自己防衛な姿勢が見られず、周囲を出し抜こうともしない
健全な会社にするための戦略的要素
品質至上主義を作り出す
満足感を与える打ち上げを用意する
エリート感覚を熟成する
チームに異分子を混ぜることを奨励する
成功チームを解散させないで保護する
戦術でなく戦略を与える
品質至上主義はもっとも重要な要素である
正しい方向に進んでいる事を確認させる
祝うことを喜ぶくせをつけることが大切だ
成功する管理の本質はみんなを同じ方向に突き動かすこと
チームのメンバーが別の道を選ばせるのはよい
チームはネットワーク構造
異分子を認めるのは各人の個性を認め合っている明確な印
■第五部きっとそこは楽しいところ
仕事は楽しんではダメだという風潮があるが、逆に仕事は楽しくあるべきだ
管理者は混乱を小さくして配分することである
小さな混乱の建設的な再導入
試行プロジェクト
プログラミングコンテスト
ブレーンストーミング
冒険体験
試行プロジェクトでは一部を変えて試すこと
たまには出張させる、またはアウトドアに参加させる、昼食を共に取るなど小さなコミニケーションが組織に良い効果をね
社内起業家という自由電子と名付けられた人たちがいる
人が自発的にやるべきことを見出したりするときに本当の意味での研究が始まる
企業エントロピーと戦い、チームを殺さないようにし、製品の品質を重視し、パーキンソンの法則を無効にし、形式主義の作業ゆるめ環境係数を改善し、雰囲気の良いチームを作ることができるだろう
1人で変化を作るの難しい大きな問題が起こったときにみんなの感心をそこに集めることだ
■第六部ピープルウェアの小さな続編
動機付けのためのアクセサリー(ポスターなど)は実質よりも形式に固執したものである
無理な残業は短期的には効果はあるが継続すると品質の低下、疲労困ぱい、退職率の増加、チームの離散につながる
人は期限通り終われそうもないとき非難から身を守るために残業する
組織内の競争心は管理者の時間、尊敬、注意、および部下への愛情の欠如によって育まれているのではないだろうか？
コーチングはチーム内が相互に作用するために重要な要素である、教える側と学ぶ側は必要な時に入れ替わる
競争心を取り除くことがチームに良いとするならば人事評価、業績評価、目標管理はあまり賢い手段とは言えない
一人ひとりの成功が全体の成功に直接結びつくということを理解してもらうことが必要だ
Capability maturity model が公に知られるようになった
現代世界における標準化内での処理が全て標準インターフェイスによるものだ
プロセス改善はいいことだがプロセス改善プログラムは良くないか少なくともよくないことが多い
Cmmiでレベル3を達成するためにおっかないプロジェクトを改善対象から外そうとする
真の利益をもたらすプロジェクトは真のリスクを伴う
組織の成熟するにつれてやがてリスクを避けるようになる
常に安定した成果を出し続けるというプレッシャーの下ではリスクを減らす力が働く
有能になればなるほどリスクを負う、それが自然でやらないなんてもったいない
レベルを下げるような開発に挑戦せよ
先頭に立って新たな秩序を導入することほど管理するものが危険な事は無い
変化に対する抵抗の連続体
1盲目的に忠実
2信じているが質問あり
3戦闘的な反対者
盲目的に忠実な人はある方向からある方向へすぐに変わるため危険である
信じているが質問ありが唯一の潜在的な味方であると主張する
変化の基本的な反応は論理的なものではなく情緒的なものである
変化させたいなら古い技術たたえつつ
道すじを示さなければいけない
もしあなたが少しも変わらないならばあなたは決して改善できない
変化は従来→より良いやり方→良い状況とはならない
変化は古い状況→混乱→実践と統合→
良い状況の方が現実にはあっていそう
サタイアモデルが重要なのは混乱が変化には絶対に避けては通れない道だと認識させたことだ
変化は失敗が成功と同じように許される場合のみ成功近づける
子供のようにチャレンジできる組織であると良い、短納期開発では難しい
光熱費は消えていくが固定資産は残る
社員を教育セミナーに連れていったとして本来は投資であるはずだったが簿記の項目上は経費となる
組織はたまに短期的な収支を重視しすぎて長期的な利益を逃す
メンバーの入れ替えによる生産性の低下は免れられない
ベテラン技術者の学習時間は入れ替えで消えてしまう、新人であれば6ヶ月特定ソフトについては2年以上かかる場合も多い
人への投資は経費の1部という考えは改めなければ生き残れないだろう
学習能力のないものに将来の繁栄はない
組織の学習能力は組織がどの程度人を引き留めておけるかで決まる
組織が学習能力を持てるかどうかの鍵はどのようにするかではなくとこでやるかである
トップは無理だし最下層にも無理で中間のいずれかになる
チームは共通の目標持ち様々な能力を備えた人たちが力を合わせないとチームと呼べない、管理者チームは特に
学習は組織の余白に登場してくる
ただ現状の把握だけなら会議である必要は無い
有効な会議は出席者全員がある問題対して通する必要がある場合である
コンセンサス数を求める
工程会がは多くの場合ただの再確認でしかない
人員投入の計画は最初少なくが理想的だ
ただよく納期が短いため本来後工程でやるべき仕事が前のほうにやってくる
担当者複数のプロジェクトに割り当てると作業効率圧倒的に落ちる
特にユーザーサポート設計などを一緒に割り当ててはいけない
すぐれたマネジャーコミュニティーを作り上げる人がコミュニティーを必要とするのはファームウェアとして組み込まれているためだろう
5つの学問、形而上学、論理学、倫理学、政治学、美学
コミュニティーづくりに成功した組織は人を惹きつける
会社の中にコミュニティをつくる事はまさに偉業である
従業員の子供が通いやすいように仕事場の横に学校があるようなところを選んでたてた
一般公式は無い自分の解を探しましょう
##感想
ソフトウェア工学で語られる数多のプロジェクトの失敗を共有することが理想的な開発に近づけるための第一歩だと思う。CMMIなどで品質に対する意識を共有しつつもガチガチにならずにリスクも引き受けることの出来る組織風土が作れると良いと思うが難しい。読み物としてもユーモアがありおもしろいです。
