『ピープルウエア』を読了しました
はじめに
大分前になってしまいますが、FJORD BOOT CAMPのSlackでkomagataさんが『ピープルウエア』を勧めて下さいました。
時間はかかってしまいましたが、ようやく読み切ることができたので、感想と学んだことをまとめたいと思います。
本書の章立て
第1部 人材を活用する
第2部 オフィス環境と生産性
第3部 人材を揃える
第4部 生産性の高いチームを育てる
第5部 肥沃な土壌
第6部 きっとそこは楽しいところ
章ごとの感想
第1部 人材を活用する
マネジメントのアンチパターン、陥りやすい思考がまとめられている章でした。
「長時間働かせることが成果に結びつく」、「生産性を飛躍的に向上させる方法があるはずだ」という思考がそもそも間違いであり、人をやる気にさせることこそマネジメントの本質であると述べられています。
少し本書から離れた話かもしれませんが、臨床心理学の分野では「解決志向」という考え方があります。これは問題の原因を考えるのではなく、解決に目を向けるというものですが、その中に現在のリソースを把握するというものがあります。
ここでリソースとは、クライアントの持っている長所や、クライアントを取り囲んでいる頼れる資源などを指しますが、マネジメントの分野においても、ないものねだりをしていくよりも、現状のリソースを確認するところから始まるのかなーとふと思いながら読み進めていました。
第2部 オフィス環境と生産性
プログラマーはどのような環境で働くと生産性が低くなるのか、高くなるのか。そもそも生産性に関連する要因はなんなのかということを探った章でした。
非常に面白かったのは、オフィスの設計の話で、「ドアから距離があればあるほど、個人的空間であるという意識が高くなるため、ドアの近くに共有スペースを作ろう」というお話です。
プログラマーを取り巻く物理環境にまで言及しているのは、とても興味深かったです。 やはり仕事をする時の、外的要因は生産性にとても大事なのだと知りました。
第3部 人材を揃える
「標準を押し付けることの弊害」、「リーダーシップ」や「会社における人的資産の評価」など人材について幅広く書かれた章でした。
特に面白かったのは、リストラや退職させることはコスト軽減にならないということです。退職した人の業務を引き継ぐ人がいて、その人が退職した人と同じレベルまで作業できるようになるまでの損失や教育コストを考えると、決してリストラなどは人的コストの軽減になりません。
人的資源を考える際には、短期的な目線でのみ考えるのではなく、長期的な目線で考える方が、コストや効果を適切に認識できるのかなーと思いました。
第4部 生産性の高いチームを育てる
チームの生産性を損ねる手法を「チーム殺し」として紹介している章です。
印象的だったのはチームにおける競争が実は生産性を損なうものであるということ。なぜなら、競争があると、自分の価値を評価されたいがために仕事を属人化したくなり、チームメンバーに対して何かを教えるということが行われにくくなるからだそうです。
これについて、最近、FJORD BOOT CAMPのスクラム開発のプラクティスに取り組んでいて思うところがありました。
自分より素早くissueを解決できるプログラマーに劣等感を持って悩んでいるよりも、教えていただくことで、チームとしての生産性はあがるのだと、スクラム開発のプラクティスを通して実感しました(詳細は以下のページ)。
個人間が競争して、個人の価値をいかに証明していくのではなく、協調して、チームの生産性をどのように上げるのかが重要なことなのだと、ここでも改めて考えさせられました。
第5部 肥沃な土壌
メソドロジーの話に始まり、意味のない会議、社内スパム、コミュニティ形成など、幅広く書かれた章でした。
メソドロジーに傾倒することは作業の標準化を押し進めることであり、そもそもの問題に意識が向かなくなる。あるメソッドを広めるのは、そのメソッドを用いて効果が上がってからで遅くないという部分はとても納得しました。
効率の良い手法を考えすぎると、そもそもの問題が解決されないことが往々にしてありました。
また、良いコミュニティを形成するのに最適な手法はなく、時間をかけて築かれるものだという内容は勇気が出る内容でした。
第6部 きっとそこは楽しいところ
「秩序が全てではなく、秩序の中に混沌状態を作り出すことで、モチベーションや生産性があがる」という内容でした。
ここら辺のお話は、実際に業務に携わっていないので、あまり納得することができませんでした。 業務に携わって、プログラミングコンテストや開発合宿など、そういう機会があると、やはり生産性が変わってくるもなのかなーとぼんやりと理解しました。
全体を通しての感想
自分が元々臨床心理学を勉強し、人間関係、コミュニケーションについて考えてきたということもあってか、読む前からワクワクしていました。
自分はまだ実務についてないし、チームをマネジメントする立場でもないので、本書の言わんとしていることを実感を持って理解できてはいないと思います。
ただ、コードを書く以外でも、ソフトウェア開発を取り巻くチームというものにも気を配って立ち回って行けたら、自分の培ってきたものが発揮できて、自分の武器になるのかなーともぼんやりと考えました。
ある程度経験を積み、チームで働いているんだということを意識できるようになったら、本書に書かれていることを少しずつ実践していきたいと思いました。
追記
誤って第2版のリンクを貼ってしまっていたため、ご指摘をいただいて、第3版のリンクを貼り直しました🙇♂️