ML大学Python学部NumPy学科

主に学んだことのアウトプットの場として

【書評】プログラマにとっての理想的な環境とは?「ピープルウエア」

 とても良い本に出会いました。ソフトウェア開発を行う企業において、経営層やマネージャーは、スタッフ(プログラマ)に対してどのようにあるべきか、どのような環境を提供すべきか、を記した本です。

新進のマネージャー、またはこれから技術者のマネジメントをやっていくことになるけども自信が無い、という人たちにとって、多くの学びがある本じゃないかなと思いました。

ピープルウエア 第3版

ピープルウエア 第3版

  • 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
  • 出版社/メーカー: 日経BP
  • 発売日: 2013/12/18
  • メディア: 単行本(ソフトカバー)

そういった役割の人は勿論、彼らから指示を受ける側のプログラマが読んでも大変有益だと感じました。

なぜなら、今自分の所属する組織よりももしかするともっと良い職場環境を提供してくれる組織が他にある、と本書が気付かせてくれる可能性があるためです。

というか、ここに書かれていることは、ソフトウェア開発企業に限定した話ではありません、多分。

以下、Wikipediaより引用。

ピープルウェアとは、ソフトウェア・ハードウェアシステムの開発、使用に際する人間の役割、関連したいかなるものも指す。たとえば、開発者の生産性、チームワーク、集団力学、プログラミングの心理学、プロジェクト管理、組織上の要素、ヒューマンインターフェイスの設計、人間と機械の相互作用、などである。

ピープルウエアとはつまり人に対して言及している概念なわけですから、どのような業界でも考慮しなければならないことだと思います。

特にこんな人が読んだら良いのでは

  • ソフトウェア開発会社の経営層
  • ソフトウェア開発会社のマネージャー
  • ソフトウェア開発会社の人事・総務
  • プログラマ
  • 優秀なプログラマと一緒に働いていきたい人
  • プログラマの生態に興味がある人

目次

第I部 人材を活用する

第1章 今日もどこかでトラブルが
第2章 チーズバーガーの生産販売マニュアル
第3章 ウィーンはきみを待っている
第4章 品質第一……時間さえ許せば
第5章 パーキンソンの法則の改訂
第6章 ガンによく効く?「ラエトライル」

第II部 オフィス環境と生産性

第7章 設備警察
第8章 プログラムは夜できる
第9章 オフィス投資を節約すると
ちょっと休憩 インテルメッツォ
第10章 頭脳労働時間 対 肉体労働時間
第11章 電話、電話、また電話
第12章 ドアの復権
第13章 オフィス環境進化論

第III部 人材を揃える

第14章 ホーンブロワー因子
第15章 リーダーシップについて話そう
第16章 ジャグラーを雇う
第17章 他者とうまくやっていく
第18章 幼年期の終わり
第19章 ここにいるのが楽しい
第20章 人的資産

第IV部 生産性の高いチームを育てる

第21章 全体は部分の和より大なり
第22章 ブラックチームの伝説
第23章 チーム殺し、7つの秘訣
第24章 続、チーム殺し
第25章 競争
第26章 スパゲティディナーの効果
第27章 裃を脱ぐ
第28章 チーム形成の不思議な化学反応

第V部 肥沃な土壌

第29章 自己修復システム
第30章 リスクとダンスを
第31章 会議、ひとりごと、対話
第32章 マネジメントの究極の罪
第33章 E(悪い)メール
第34章 変化を可能にする
第35章 組織の学習能力
第36章 コミュニティの形成

第VI部 きっとそこは楽しいところ

第37章 混乱と秩序
第38章 自由電子
第39章 眠れる巨人よ、目を覚ませ 

覚えておこうと思ったポイント

マネージャーの基本的姿勢。

マネージャーのほとんどは、技術面より、人に気を配っていると思い込んでいる。しかし、本当にそうしているマネージャーは滅多にいない。実際には、技術だけに関心があるというマネジメントをしている。

知的労働者が時々ミスを犯すのは極めて自然で、仕事を真面目にやっている証拠である。しかし、仕事の上の誤りを、聖書で言う「罪」と同じように考えている人がいる。この考えを正すのは非常に骨が折れる。

間違いを許さない雰囲気が社内にあると、担当者は守りに入り、失敗しそうなことには絶対に手を出さなくなる。(中略)間違いを犯さないよう手段を講じたプロジェクトでは、平均的な技術レベルは、それなりに上がるかもしれないが、チームの空気は重く沈む。これと正反対のアプローチは、間違いを恐れさせないことだ。

担当者を指示どおり働かせて、短期間の生産性が上がっても、長期的には大した効き目はない。担当者の自発的なヤル気が認められず、マネージャーがヤル気を補給するという考えほど、担当者の士気をくじくものはない。

担当者一人ひとりの個性は製造業でのマネジメント手法をそのまま採用しようとするマネージャーにとって頭痛の種である。一方本当に人を知るマネージャーはユニークな個性こそがプロジェクト内の不思議な作用を活発にし効果的にすることをよく認識している。これはもっと奨励されてしかるべきだ。

誰かに頼るしか問題の解決策がないという深刻な場合ですら、マネージャーがその誰かになってはならない。チームの中から助けの言葉をかけた方がはるかにうまくいく。

マネージャーの役割は人を働かせることにあるのではなくて、人を働く気にさせることである 。

マネージャーがいくらかでも意味のある方向に部下の人格を変えられることはまずない。部下が部下として留まる年月はあまり長くないし、またマネージャーも部下の本質的な人格を変化させるほどの影響力を持てないのが普通である。

したがって部下の本質は部下として過ごした期間に関係なく、その終わりの状態は初めと大して変わらない。(中略)

こうしたことは最初に人材を揃えることが何よりも重要だということを意味する。

力があるマネージャーは、チームのメンバーが頭を丸坊主にしようが、ネクタイを締めないでいようが、一向に気にしない。チームの誇りの対象は、チームメンバーが成し遂げた成果だけである。

最も大きな成功を収めるマネージャーは自部門のエントロピー=均質性を撹乱し、社内標準からかけ離れていても適切な人材を集め、彼らに本来の力を発揮させる人々だ。

リーダーシップは、私たちから何かを引き出すということではない。サービスである。(中略)明確に指示を出すこともないではないが、主要な役割は指揮官ではなく触媒である。

高品質の徹底。

早くやれとせかされれば、雑な仕事をするだけで質の高い仕事はしない。仕事を速くするためには製品の品質と仕事の満足感を犠牲にせざるを得ない。

大抵の人は自尊心を自分の作った製品の品質(製品の量ではなく質)と強く結びつける傾向がある。どんなことでも製品の品質を落としかねないことを指示すれば、それに反抗する部下たちの感情に火をつけることになる。

達成不可能な納期をマネージャーが設定すれば、製品の品質を危険にさらすことになる。マネージャーは自分のやっていることがそんな意味を持つとは思ってもいない。逆に面白くて挑戦するに足ることを部下に与え、人間的成長を助けているとさえ思っている。(中略)

古参で少し擦れた部下はそうは考えない。プレッシャーの下では作業には過度に制約がかかる。納期通りに完成するためにプロジェクト資源をやりくりする自由もなくなる。

例えばもっと人を投入するか実現する機能を削るかを選択できなくなる。犠牲にできる唯一のものは品質だ。そこで極端な時間のプレッシャーをかけ続けると部下は品質を犠牲にし始める。

問題が見つかってもカーペットの下へそっと隠し、後回しにしたり、エンドユーザーに捕まったりするのだ。不安定で本当は完成していない製品がこうして出荷される。好んで行っているのではないが、他に選択肢はないのだ。(中略)

会社自身の品質基準に満たない製品を早く出荷するようにとスタッフにプレッシャーをかけることは間違いである。(中略)

エンドユーザーの要求をはるかに超えた品質水準は生産性を上げる一つの手段である。

健全な作業環境のもとでスタッフが職務をきちんと遂行しない理由は、能力の不足か、自信のなさか、プロジェクトの目標や同僚に馴染めないことにある。納期によるプレッシャーは大した解決策にはならない。

短時間で出荷しようとして何かをすると、結局品質が下がってしまう。製品のエンドユーザーはこの取引(安くで早く納品する代わりに、品質が下がる)に進んで同意することが多い。

しかしそんな譲歩は開発者にとっては苦痛である。自分の能力以下の製品づくりを強制されることで、プログラマーの自尊心を傷つけられる。

品質削減が最初に破壊するのは、 長い間培ってきたチームの一体感だ。

プログラマが集中できる環境を作る。

オフィスに遅くまで残ったり朝早く出社したり果ては静かな自宅で仕事をしなければならないのは、オフィス環境の悪さに対する強烈な告発である。

貴重な時間を潰されるのと同じように深刻なのは、邪魔されてイライラすることだ。仕事に集中しようとしてその度に邪魔されては面白かろうはずがない。あと一歩で仕事に没頭できるというところで、結局自分の周りの現実に引き戻されてしまう。(中略)

これはまさしく近代的オフィスの弊害そのものである。

机の前に何時間座っていたかはどうでもいいことで、全神経を集中して仕事に取り組んで時間が重要なのだ。(中略)

1日のうち邪魔が入らない時間が少なくとも2、3時間あって当然だと考えるようになれば、邪魔の入らない時間をそれだけ確保しようと行動するようになるだろう。

絶えず中断を意識するようになれば、何の気なしに軽い気持ちで隣の人の仕事を邪魔することもなくなる。

オフィスの騒音や音楽が創造性やひらめきに与える悪影響は、表面には現れてこない。そもそもひらめきは時々しか起きないものなので、それが減ったとしても気づかないことが多い。創造的な思考に割り当て量があるわけでもない。創造性の低下による悪影響は、長い間に蓄積される。

かくして会社の能力は下がり、ひらめきのない仕事が垂れ流され、優秀な人は辞めていくのだ。

マネージャーができることは、せいぜい社員が自分に適したまともな作業空間を作れるように、十分なスペース、静かさ、および、プライバシーを確保することだ。

スペースについて、年月を超えで適用できるパターンがある。それはプライバシー深度というもので、建物の中に入るに従い徐々にプライベートになるというものである。

オフィスのいちばん外側は部外者が入ってくる場所である。一歩中は関係者のための空間であり、さらに奥は各個人用のプライベートのオフィスとなる。

グループがミーティングをする場所には、テーブル、全員分のイス、ホワイトボード、意見を全部書き留めておける掲示板が必要である。理想を言え、ば簡単な食事を作って食べられる設備と広さが欲しい。

会食なしにはいかなる人間集団も団結を保てない。すべての組織や生活集団に集まって食事のできる場所を用意すること。 会食を定例の行事にすること。特に仕事場では昼食会を始めること。

もちろん個人個人の貢献のすべてが積み上げられて統合されて全体になるのだから、最優秀チームでさえ協調は不可欠である。しかし、人材が揃ってさえいれば各人の努力を統合するのはどちらかというと機械的に事が運ぶ。大抵のプロジェクトの成否は、チームが構成され最初にある方向に歩みだす瞬間からおおよそわかる。

プログラマの採用、辞めないことの重要性。

新プロジェクトに入れる人を評価する場合、プログラマーの静的な能力を重視しすぎるきらいがある。

例えばコーディングがどのくらいできるか、ドキュメントがどのぐらいかけるか、などである。プロジェクトに加えたい人たちの一人一人がどれだけグループ全体にうまく馴染むかにはほとんど注意を払わない。

生産性は、利益をコストで割ったものと定義すべきである。利益は作業時に節約できた金額又は仕事からの収益と見ることができ、コストは全体のコストつまり退職者の補充に費やした余計な費用を含むべきである。

マネージャーは製品を作る人を採用しようとしている。その製品は応募者が以前作ったものと同じようなものだと思っている。それなら応募者がやっている仕事の質を評価するために、それらの製品のサンプルを検証する必要がある。

退職率が30%以上と病的に高い会社の場合、退職のほとんどは次の理由で説明がつく。

腰掛けメンタリー:この仕事を長く続けようという雰囲気を同僚が醸し出さない

使い捨てにされる予感:経営者が社員を交換できる部品としか考えない

会社への忠誠なんて馬鹿馬鹿しいという意識:人を部品と思っているような組織に誰が忠誠心を持つだろうか?

退職が次の退職を呼び、その影響は深く静かに潜行する。社員が長く居付かなければ研修に金を使うのは意味がない。(中略)

企業が社員への投資を全くやらないので、会社を変えることを何とも思わなくなる。(中略)

企業が社員の優秀さを認めないという印象は、個人として評価されていないという感じを社員に抱かせる。同僚が次から次へと辞めていくと、翌年までやめないでいたら何か自分に問題があるような感じになる。

すでに必要な技能を持っている人を雇った方が安上がりだ。ほとんどの組織はそうやっている。しかし、最良の組織はそうはしない。

再教育がずっとい続けるという気持ちを育て、 結果として低い退職率と強いコミュニティ感覚を生むことを認識している。そして、それがコストの問題よりもずっと大切であることをよく認識している。

チーム。

実際の仕事では本当にチームワークが必要になることは極めて少ない。しかしそれでもなおチームは重要だ。チームは、メンバーたちを同じ方向に引っ張るための道具として機能するからだ。チーム編成の目的は、目標を達成することではなく、目標を一致させることである。

結束したチームは生意気で自己満足的で他人を苛立たせ排他的かもしれないが、交換可能な部品の寄せ集めよりもマネージャーの本当の目標のためにはるかに役立つことは間違いない。

日頃密接に連絡を取るべき人々を物理的に引き離すことは、どの道全く意味がない。(中略)

チームのメンバーを一緒にしておけば、チーム形成にとって必要な日常の何気ない会話を交わす機会も生まれる。

マネージャーレベルでは結束したチームはありえない。マネージャーがチームに入るとすれば、二つの役割、つまりマネージャーとチームのメンバーを兼ねる時に限られる。部下の一時的な同僚として、チームに受け入れられるのだ。

組織での地位が上がるほど、結束したチームの概念は薄らぎ、遠く忘却の彼方へ去ってしまう。

最後に

以前いた会社で、開発者が一斉に辞めてしまうという悲劇があったのですが、そこの経営層は、この本に書かれている「ダメな経営層」に驚くほど類似した行動を取っていました。

しかし、この本で良しとされる振る舞いをしていたように思えるマネージャーもその企業にいましたが、その人は残念ながら結果を出せずにすぐ辞めてしまいました。何が悪かったのだろうか。まあ、業務時間中に寝てたからな(笑)

なお本書は、実際の事例を多く交えて、経営層・マネジメント層が犯す過ちを記していくスタイルなので、少々長ったらしく感じる方もいると思います。

しかしながら要点は非常に明快であり、決して読みにくいものではありません。Amazonの評価は芳しくないようですが、 当てになりませんね。

冒頭にも書きましたが、より良い職場環境を作りたい人、より良い職場環境で働きたい人、どちらにとっても読む価値ありの良書と思いました。

ピープルウエア 第3版

ピープルウエア 第3版

  • 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
  • 出版社/メーカー: 日経BP
  • 発売日: 2013/12/18
  • メディア: 単行本(ソフトカバー)