『ピープルウェア』のアウトプット

はじめに

ピープルウェアを読みました。
この本はソフトウェア開発におけるマネジメント像を著した古典的名著です。
印象的な部分をピックアップして自分用のメモアウトプットとして残しておきます。

参考リンク:ピープルウェア

第一部:人材を活用する

今日もどこかでトラブルが

ソフトウェア開発上の問題の多くは、技術的と言うより社会学的なものである
マネージャーの役割は、人を働かせることになるのではなくて、人を働く気にさせることである

『ソフトウェア開発は人間関係の構築である』というこれらの趣旨が本を通して語られるメインテーマとなっています。最近常々思っていることと全く同じでぶっ刺さる言葉でした。

  • 人の問題に本当に取り組んでいるマネージャーは滅多にいない
    • メンバが解決する技術的な難問を、自分で解くことに時間を割く
    • 作業をマネジメントするのでなく、作業そのものをやっている
  • ソフトウェアは多数のチームで開発するので、ハイテクビジネスではなく人間関係ビジネス
    • PJの成功:関係者の緊密な対人関係、PJの失敗:疎遠な対人関係
    • 人間関係は複雑で割り切れない、やりやすい技術面に注意を払いがち

前者はいわゆるプレイング・マネージメントに言及しているのだと思います。後者の、人間関係の問題解決に目を背けて、手を付けやすい技術面に目を向けることを例えた以下の比喩が絶妙です。

暗いところに落とした鍵を明るいところから探すような馬鹿げた行為

パーキンソンの法則の改定

ニューサウスウェールズ大学 マイケル・ローレンスとロス・ジェフリーのPJ調査はパーキンソンの法則が成り立たないことを示す結果を示しています。

目標値設定者平均の生産性PJ数
プログラマ8.019
マネージャー6.623
プログラマとマネージャー7.816
システムアナリスト9.521
目標なし12.024
  • 上司に課されるよりも自分で決める方が良い
  • それよりも、仕事の全体像を詳しく知り、担当者が陥りがちな楽天主義やマネージャーが陥りがちな政治的な考え・先入観に影響されない専門家に決めてもらったほうが良い
  • 最も驚くべきは、誰も目標を指図しない時が最も良い

特に最後の結果は驚きでしたが、決まった正解がない知的労働においては誰からも指図されることなく、高い自由度の中で主体性を持って取り組める環境が素晴らしいのは確かにそうだと思いました。

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

頭脳労働時間vs肉体労働時間

本当の意味での仕事は一人のときにできるという言及はいわゆるフロー状態についてのものです。

  • スイッチを押すようにフロー状態になることはできない
  • 15分ほどの精神集中過程が必要
  • 机の前に何時間座っていたかではなく、神経を集中して取り組んだ時間が重要
  • 環境係数 = 中断なしの時間数 / 机の前に座っていた時間

自分がフロー状態にいるときに話しかけられ、作業に戻ると「あれ?何してたんだっけ?」と集中力がゼロリセットされてしまう経験は誰しもあるはず。めちゃくちゃ共感しますが、自分が話しかけることでメンバのフロー状態をかき消してしまう危険性にも気づくことが出来ました、気をつけます。

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

チーム殺し

以下、ぶっ刺さった項目をピックアップしました。

守りのマネジメント

本当の自主性とは、マネージャーとは違ったやり方で仕事を進められること
本当の自由とは、間違ったことをしても良い権利

  • 部下を信頼して自主性を与える
  • PJがミスしたって良い
  • 部下にどんな誤りも許されないと思い込ませてしまってはいけない

官僚主義
頭を使わないでどんどんドキュメントを作ることは、人間の能力の浪費

製品の品質削減
短時間で出荷しようとすると結局品質が下がる。安く早く納品されるので顧客は喜ぶが、開発者は能力以下の製品作りを強制されるので苦痛となる。

残業の予期しない副作用
たくさん残業させるのは生産性を下げるやり方。

人は期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りできそうもないことが分かった時に、避難から身を守るために残業する。

競争

チーム内の競争は、仲間同士の指導・助言を困難、あるいは不可能にする。
指導はチームを動かす上で必要不可欠なので、競争を煽るとチーム殺しに直結する。

というのがこの章のメッセージでした。

単純で明確な査定や表彰を用い、投資や部下の動機づけ、チーム形成、引き止めといった曖昧で困難な問題に取り組まない言い訳をしてはいけないと、耳の痛い言葉に頷くばかりです。つくづく、マネージメントは difficult でやりがいのある仕事だと気づかせてくれます。

第五部:肥沃な土壌

自己修復システム

この章では、仕組みやノウハウの横展開、ドキュメント化(総称してメソドロジー)の功罪に触れていました。

メソドロジーをまとめる人間は頭がよいが、それを用いる人たちは思考しなくなる、頭脳労働にとってこれは自己修復機能を失ったに等しいこと
との言葉にハッとさせられます。

仕組みを作り、新卒や未経験者でも稼働できる状態を作ることを無意識に「善」としがちですが、それに警鐘を鳴らす一言です。
たしかに知的労働なのだから頭を使ってもらってなんぼですもんね。

思考しなくなると、失敗をメソドロジーのせいにする責任観念の欠如にもつながる危険を孕みます。

リスクとダンスを

本当に価値があるものの、リスクがほとんどあるいはまったくないようなPJは先人たちによってやり尽くされている。PJがリスクを抱えていることは、それに価値があることの証左。

との言葉には痺れました!ついつい「リスク」=「避けるべきもの」となりがちですが、うまく取り込み乗り越えることが必要だと気付かされます。

変化を可能にする

新たな技術を導入する人にとって、古い秩序から恩恵を受けた人はすべて敵であり、新たな秩序から恩恵を受ける人からは、気のない支援しか受けられない。

古い方法をマスターした人たちを敵に回すリスクを冒すと同時に、利益を得ると思われる人々からも僅かな支援しか受けられない不合理な状態になる。

これは人が変化を嫌うから。何かを変えようとし始めた時点では利益を得る可能性より不確実性のほうが大きい。

これは数年間の仕事経験のなかでさえ幾度となく体験した状況です。なぜそうなるのかの一つの理由がわかった気がしました。


具体的な解決策を提起してくれるわけではないですが、ソフトウェア開発が人間関係の構築であると再定義して提示してくれる素晴らしい本でした。

この記事の内容が役に立ったと思いましたら、SNSで記事を共有していただけますと幸いです。