「ピープルウェア」を読んでブッ刺さった話 1.5刺し目 

# はじめに
「ピープルウェア」読後アウトプット記事の第二弾です。
 前の記事は[こちら](https://qiita.com/wryu/items/86efa18851d17c71b44f)

本稿では「ピープルウェア」を読んで、個人的に刺さったところを
かいつまんでメモ＆感じた事を書いていこうと思います。
※刺さった ＝ 読んでいてハッとした と捉えてください


※1 本稿では地の文が私が書いている要約や意見で、引用部分が本書の著者が書いたところです
※2 引用の都合上、言葉尻を変えることがありますが、極力原文のまま記載します
※3 勢いでまとめている節があるので、丁寧語等の文体が崩れてしまう事をご容赦下さい

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

第二部では、社員のやる気を向上させる環境づくり、ということで逆に社員のやる気を失わせる要因を理解しよう、という内容になっている。<br>

書いていたらなんやかんや内容が多くて前後編で分けることにしました。
なので**今回は二部の途中までになります。**

---
### 七章 　設備警察

>
つまるところ、プログラマーは仕事をするために頭を使わなければならない**知的労働者**であり、騒音・雑音があれば集中を乱される。
　　(中略)
意外ではないと思うが、会社(特に大企業ほどこの傾向は顕著だが)のオフィス環境整備の担当部署は、このような「本当のオフィス環境」には全くおかまいなしである。
現状把握のためのデータを集めようともしないし、プログラマーの生産性という非常に複雑な問題を理解しようという姿勢が微塵もない。


**思ったこと)**
オフィス環境整備の担当部署なんて存在しない「!大企業」に勤めている私ですが、
自社はもちろん、常駐作業を含めて仕事でお邪魔したいくつかの大企業様のオフィスでも
プログラマーが作業しやすいように～という具体的な観点の配慮を感じたことは正直ありません。

"メンバ同士が作業しやすいようにオープンスペースがあったり～" といった「従業員」に対しての配慮はあるかと思いますが、
「プログラマ」ないし「エンジニア」に焦点を置いた環境づくりがなされている職場って
そうそうあるものではないのでは、と思います。
なので正直読んでてもあんま刺さりませんでした。どうしても遠い世界の話にしか聞こえなくて...。

ともあれ、真に仕事をしない設備部隊がいない＝オフィス環境がエンジニアに真に適した環境になっていない、という状態は一緒ですので
そういった意味でも「作業しやすいようにする何か」というプラスの何かを用意することより、
まずは「作業をしづらくさせてしまっている何か」というマイナスの何かを除去することに焦点を当てた方が現実的かもしれませんね。

 <br>

>この「警察」の「本部長」は一体、何を考えているのだろうか？
おそらくこの程度の事だろう。
　　(中略)
「あの連中ときたら、壁にベタベタとポスターを張るわ、狭いスペースに自分らしさを演習しようとするわ、**とにかくだらしない。**...略」
>
帰宅時には机の上をきれいに片付けること、壁には会社のカレンダー以外は貼らぬこと、という社内規定を作るのもこいつである。

**思ったこと)**
私の所属組織ではここまでｶﾞﾁｶﾞﾁな規定はありませんが、自分自身の環境に照らし合わせると
「そんなところまで規定しなくてもいいんじゃ、、」というルールの一つや二つは思い当たるのではないでしょうか。

ポスターをベタベタ貼るのは流石にどうなのって気はしますが、個人的には最低限ティッシュ箱とゴミ箱くらいは私物で置いておいても許容してほしいですね。。

<br>

>
「設備警察」の精神構造をもう少し掘り下げるために、図7.1に示すオフィスの見取図に注目してほしい。
このオフィスの間取りは、今やアメリカではごく当たり前のものだ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131674/11d6efd6-63f1-48b7-a265-db25d0b1dded.png)
(※著書の図を基にエクセルで似た図をお絵かきしました) 

>
この間取りの弊害を考えてみよう。
人の出入りが一番激しいのは、エレベーターから各部屋、および、部屋から部屋への往来だが、その道筋には窓が一つもない。
この平面図通りにオフィスを建てると、窓はまったく活用されない。窓際の廊下は、人っ子一人いないという不思議な風景を形作る。
　　(中略)
どちらの向きでも、窓にはすばらしい景色が広がっていたが、その景色は誰も見たことがないのだ。
社員は、地下室で働いているのと何ら変わりなかった。
　　(中略)
そんな環境がプログラマーの生産性にどんな影響を与えるのか、誰も気にしないのが現状である。

**思ったこと)**
正直具体的過ぎてあまり刺さらなかったのですが、オフィスビルの間取りとしては比較的よくあるものとして共感できると思います。

このあとも「人間は自然の光のもとで働く方が、ずっとよい仕事ができる」といった間取りと生産性に関する詳しい記述がなされていますが、
全体通して「間仕切りで作られた画一的なスペースが一人一人に割り当てられるが、管理のしやすさはあるものの、
"騒々しく、邪魔が入りやすく、無味乾燥で、プライバシーのかけらもない場所"として
利用者の利便性は考慮されていない」という事が主張されています。

しかしながら間仕切りで一人一人にスペースが割り当てられている職場自体、私はこの目で見た事がありません。
著者の主張では「間仕切りでも不十分で、扉で完全に区切られた空間が理想」としていますが、
日本の職場では間仕切りすら嫌う傾向があるのかとなぁとぼんやり思いました。

とにかく細かいレイアウト等に違いはあっても、作業場所が 
"騒々しく、邪魔が入りやすく、無味乾燥で、プライバシーのかけらもない場所" である事については
アメリカでも日本でも同じなのかもしれません。

じゃあ実際に個別に作業部屋が割り当てられたらどうなるか、と考えると

 - 一人静かに周りを気にせず、伸び伸び作業できるプラスの作用
 - 周りの目が無さ過ぎて緊張感がなくなるというマイナスの作用

という二つが相反して、個人的には結局生産性はﾄﾝﾄﾝになってしまうような気もします...。


---
### 八章 　プログラムは夜できる

>開発や設計をする人は「残業なくして人生はなし」と信じこんでいるきらいがある。
これは通常に与えられた時間だけでは全く仕事にならないということだ。
　　(中略)
プログラマーをはじめとする知的労働者は、なぜこんなに残業が多いのだろうか？
意外なことに、残業の真の目的は、仕事の量をこなすよりも品質向上のためなのだ。
　　(中略)
まともな仕事をするには、朝早くオフィスに来るか、夜遅くまで残っているかだ。


**思ったこと)**
ここでは残業という切り口からオフィス環境と生産性について論じています。
「残業の真の目的は、仕事の量をこなすよりも品質向上のため」というのは
第一部の品質向上の意味合いとは少し違って、作業における質の向上を指しています。
単純に夜の方が静かで捗るから、という理由で残業をしているならば、それはオフィス環境に問題がある、と記されています。
(改めてココを読むまで、昼間は騒がしい という事が当たり前過ぎて何も思ってませんでした...)

>
オフィスに遅くまで残ったり、朝早く出社したり、はては、静かな自宅で仕事をしなければならないのは、
オフィス環境の悪さに対する強烈な告発である。
驚くべきは、環境が悪くて仕事にならないということではない。
誰もがそのことに気付いているのに、誰も何もしないことだ。

**思ったこと)**
全くその通りですね。
言うほど静けさが問題で残業している人っているのか？って話もありますが、
もしそういった方が一定数いるならば改善した方が良いと思います。

また、静けさは関係ないですが、マネージャーや現場で力を持っているシニアエンジニアには、日中は横入りのタスクや質問が多くて
就業時間外の方が集中できるわ～という方が多いのではないでしょうか。

そういった場合も先の例のように、裏を返すと、タスクの割り振りがおかしかったり、
属人化が進んでいるサインと言えるのでは、と思いました。



<br>


---
### 九章 　オフィス投資を節約すると

ここらへんから段々と生産性の話がメインになってきます。

>オフィスの設備投資をケチッたところで、浮いた金額は生産性低下の危険性に比べれば微々たるものだ。
プログラマー一人にかかるオフィスのコスト全体は、給料の数％程度でしかない。
どれくらい小さいかは、不動産の評価額、社員の給与水準、買い取りかレンタルかの戦略によって左右されるが、大雑把に言うと、
オフィス投資分はプログラマーの給料の６～16％程度なのである
　　(中略)
福利厚生費も加えれば、エンジニアに対する投資は、オフィスにかかるコストの20倍ぐらいになるだろう。
　　(中略)
１ドルのうちのごくわずかを節約するために、20ドルの大部分を犠牲にしかねないのだ。


**思ったこと)**

**ほんとそれな。**
細かい金額とかは個々の会社毎に違うから野暮なことは言いませんけど、
ケチって生産性を下げるっていう事はナンセンスですよね。

別に超都会の一等地30Fのクソデカオフィスでアーロンチェアに座って仕事する必要はないんですけど、
メモリ4GBしかないPCとか、油断すると周囲の人と足先とか肩があたっちゃうような狭小作業環境は明らかに能率を下げるんですよね。
（言うて肩は当たらんか）
そんなんでそれこそ残業が増えて人件費が嵩むくらいなら 設備投資で解決せいや！って思います。

完全に余談＆個人的な意見ですが、イマドキ作業PCはメモリ16GBが標準にした方がいいと思うんですよね。
逆に記憶領域は200～300GBくらいでいいと思うんですよ。
インフラエンジニアでvhdファイルめっちゃ保存する～とかってシチュエーションでもない限りそうそう使わないと思うんですがいかがでしょうか。
~~あとはやっぱりデュアルディスプレイもほｓ~~

で、このあと具体的な実験調査に基づいて「一人当たり何平方メートルあれば作業に集中できる～事が分かった。 」みたいなことが書いてあるんですが、
そこはまぁ あっそ って感じで。（具体的すぎるねん！っていう）

<br>

>
良いオフィス環境と悪いオフィス環境で生産性を計測して、オフィス環境と生産性の相関関係を解明できないのはなぜだろうか？
環境と生産性の問題は、いわゆる「生産ライン」では比較的簡単に分析できる。
しかし、計測対象の労働が知的な性格を持つと、話はそう単純ではない。
　　（中略）
オフィス環境が、ソフトウエア生産性に与える影響を実験するのは実に簡単で、次のことを行えばよい。
・新しいオフィスでの作業量を測定する。
・その作業に要したコストを測定する。
・新しいオフィスの広さと投入コストを、旧オフィスのものと比較する。
頭の中で比較方法を考えるのは簡単だが、いざ実際にやってみると非常に難しい。

**思ったこと)**
単純ではない～といいつつ、簡単だ～実際難しい～とか どっちやねん！って感じですが
実際に比較しようと考えたら難しいですよね。少なくとも比較対象となる新旧オフィスで計測する必要がありますからね。
（しかも片方は事前にやっとかなくてはなりませんし）

<br>

>
企業によっては、特定の作業に対して投入された**時間の総合計**を集計しているところはあるが、
これだけでは投入**時間の質**は不明である（これは我々の言う「肉体労働時間」と「頭脳労働時間」のことである。詳細は第10章参照）。
生産性の測定は、マネージャーにとって実に頭の痛い問題である。額にシワをよせて考えたあげく、
「生産性から派生する問題は、理解の限度を超えている」とあきらめてしまう。しかし、実際にはそれほど悩むほどのことでもない。
　　(中略)
ソフトウエアの構築という私たちの最も得意とする分野には、有効な測定方法が数多くある（代表的なものは巻末の注釈を参照のこと）。
依頼された企業の生産性を計測し、ソフトウエア業界全体から見てどの程度かを評価するサービスさえある。
自分で自分の生産性を何らかの形で評価できない会社は、まだ本気で評価したことがないのだ。

**思ったこと)**
抜粋が長くなって恐縮ですが、要するに最後の一行にすべてが集約されている気がします。
人月という工数の計算手法にも表れている通り、この業界では時間当たりの作業の質までは
真剣に考慮されているケースって少ないのでは、と思います。

私の所属している組織でも勤怠記録に絡めて、作業時間を記録するようになっていますが、
一日タバコ休憩やおしゃべりしつつだらだら8時間やるのと、超集中して8時間やるのも一緒くたです。
「時間当たりの作業の質なんて計りようがない」と最初から諦められているのかもしれません。
(~~その割に生産性あげろ～とか言われたりするんですけどね~~)

具体的な方法は本書の巻末等々色々あるようですので、やれ「作業効率や生産性を上げろ～」だのなんだの言う前に
"成果量や時間の相関を明らかにして、一度本気で作業の質(生産性)を計測してみる"  というのが生産性向上の第一歩なのかな、と思いました。


<br>

>
生産性測定には、
・ソフトウエアの生産方法を改善できる
・目的意識を明確にできる
・仕事に対する充実感を与えられる、
などの効果がある。
>
しかし、実際に、その目的で適用されたという話はあまり聞かない。
生産性測定のやり方が、プログラマーを脅かしたり、心理的負担をかけるものへ変わりつつある。
つまり生産性測定に最大限の効果を求めるなら、個人データは上位のマネージャーには知らせず、担当者本人だけに知らせよ、ということである。
生産性に関する個人別のデータは、その個人の利益のためだけに使うべきだ。
ただし、集計した平均値だけを上司に見せるのは、一向に構わない


**思ったこと)**
実際に私は生産性を計測した/されたことがないので推測ベースの話になってしまいますが、
確かに、自分の数値が色んな人に知れ渡ってしまうのはどうなんだろう、って思ってしまいますね。
生産性の高さ＝業績、社内評価に直結しうる材料ですので、著者の記述通り、注意して扱われるべきだと思います。

ただ、結果を見て「あぁ、私の生産性は低いのか...。これからもっと頑張ろう！」って必ずしもいい方向になるとは思えないんですよね。
人によってはガッツリ凹んで立ち直れないかもしれないし、あー私は低い(or高い)のか～ ふーん。 で終わっちゃうかもしれない。
データの扱いには厳重に注意を払ったうえで、各人に対する適切なフィードバックがなされるといいのでは、と思います。
(もっと○○してみましょう～とか、ｘｘは効率が悪いので違うやり方を試してみましょう～とか)

個人的には 自分自身はそこそこ生産性あるんちゃう？ と思っている節があるので、
無邪気に "自分にはどれほどの生産性(力)があるのか" っていうのは知りたいです。
言うならばエンジニアとして、一社会人としての戦闘力が数値化したみたいなもんですからね。気になりますよそりゃあ。
そして欲を言えば 自分が尊敬する先輩はどれくらい力を持っているか～ とか、他の人の値も気になります。

<br>

>
この考え方(生産性に関する個人別のデータは個人の利益のためだけに使うべきという事)は、マネージャーには承服しがたいだろう。
その理由は簡単で、集計した個人データをもとに管理体制を能率の良いものにしたいという下心があるためだ
（例えば、昇格昇給等の人事考査を正確にする、あるいは、クビにするときの理由にするなど）。
しかし、個人別の生産性という非常に微妙なデータを有効に収集するには、正直なデータを積極的、自発的に申請してもらうことが必要だ。
個人データの一部でも他人に漏らしたり、あるいは、社員の足を引っ張る目的で使ったりすると、生産性測定計画全体が崩壊する。

<br>

デマルコ先生に置き論破されちゃいました。

<br>

>
プログラマー個人もマネージャーと同じようにデータを活用したいと思う。
個人データをもとに自分の欠点を正し、また得意分野をさらに伸ばそうとするのだ。
また極端な場合は、足りないことがわかったスキルに頼らないようにするために、自分で自分をクビにしてもよい。
マネージャーからすれば、個人データから利益が得られれば、個人データ自体は必要ない。

こういうことらしいです。データそのものを数値として直接利活用すんじゃなくて、
そこから良い効果があればそれでいいじゃない、って事ですね。
きっと色んな調査結果とかを鑑みると、こういう事に留めた方が総合的にはプラスなんだ、っていう事なんでしょう。

でもやっぱりデータとしても使いたいけどなぁ。。。

<br>

---
### 十章 　頭脳労働時間　対　肉体労働時間


**思ったこと)**
ここでは、第九章で記述されていたIBMがサンタ・テレサ研究所を建設するとき、
事前に社員の労働環境を調査した結果を基に、作業における質について考察をしています。
なので細かい数値とかはざっくり省きます。
というかあくまで調査結果に基づくものなので、数値は参考程度にとどめてください。この世の真理ではありません。

　
>
一日の労働時間のうち、30％は騒音に神経をとがらせるが、残りの70％は逆に騒音を出す側にまわる。
オフィスには、一人で黙々と仕事をしている人もいれば、２、３人で討議しながら進める人もいるため、作業態勢はぶつかり合う。
これにより、被害を受けるのは、一人で仕事をしている人だ。
ある時間を切り取って見ると、単独作業をしている人は少数派だが、かといって無視することはできない。
本当の意味での仕事は一人のときにできるためである。
複数人数による仕事は、別の言い方をすると、次の仕事の準備、休憩、あるいは、暇つぶしなのだ。

**思ったこと)**
最後の行はちと言い過ぎでは、と思いましたが、エンジニアにとっては確かにそうかもしれません(それでも過激ですけど)。
マネージャーやお客さんと折衝をするといった立場の方であれば、むしろ一人では何も仕事になりませんからね。
私のプレイングマネージャーという今の立ち位置でも、一存で決められないシーンは多々ありますし。

そんな野暮なツッコミは置いといて、ここからは**作業における集中できる状態**という点にフォーカスしていきます。
その為「本当の意味での仕事は一人のときにできるためである。」なんて言っているんですね。

<br>

>
単独で作業をする場合、プログラマーは心理学者のいうフロー（Flow）状態になっていることが理想だ。
これは、一つのことに没頭し、ほとんど瞑想状態になることである。
この状態に入ると、幸福感（euphoria）で一杯になり、時間がたつのを忘れる。
　　(中略)
世の中のありとあらゆる仕事において、生産性を上げるには何が何でもフロー状態にならねばならぬ、ということではない。
しかし工作、設計、開発、執筆などでは必要不可欠だ。
これらは高いモーメントを必要とする仕事であり、フロー状態になってはじめてうまく運ぶ。

**思ったこと)**
皆さんもご経験があると思います。
我々日本人には「フロー」という言葉よりもスポーツでよく言われる「ゾーン」の方がしっくりきますね。  ~~手塚ゾーンとか。~~
たぶん厳密には似て非なる言葉なんでしょうけど、まぁイメージがつかめればよいでしょう。
やはり設計や開発は集中して取り組む時間がないと進みませんよね。

<br>


>
残念ながらスイッチを入れたり切ったりするように、自分をフロー状態にすることはできない。
徐々に近づいて行き、その後にフロー状態になるのであり、通常、15分以上の精神集中過程が必要といわれている。
このフロー状態に入る過程の時間では、騒音や中断に非常に敏感となる。
したがって、騒々しいオフィスではフロー状態に達するのは困難、あるいは不可能だ。
一度フロー状態になっても、直接的な中断や、しつこい騒音で、いとも簡単に元の状態に戻ってしまう。
邪魔されて元の状態に戻ると、再びフロー状態に入るのに15分以上かかる。
その間、実質的な仕事はできていない。

**思ったこと)**
正直私は集中力にはそれなりに自信があるので、言うほど困難か？って思ってしまいますが、
きっと自分が思っている以上に、真に集中できている状態を「フロー状態」として、
作業能率とか脳波とかきちんと測ったらそのくらい困難なものなのでしょう。

(この辺の心理学とか脳医学？とかに詳しい人がいたら追記お願いします)
打ち合わせの時間といった、直接的に個人の作業ができない時間だけでなく、
電話応対や周囲の人から話しかけられるといった、中断時間そのものは僅かなものでも
集中の妨げとなり、結果的にパフォーマンスを落とすことになっているということですね。


<br>


# ～第二部 ここまでの締め～
突然ですが、ここまでで既にだいぶ長くなってしまったので
今回は前後編で分けたいと思います。
いやー短くなる予定だったんですけどね。おかしいな～

あと本書はKindleで購入したものでして、この記事を書くのにも適宜KindleのReader上から
コピペしていたのですが
ここまで書いた段階で「出版社が定めたコピー制限に到達しました」みたいな表示が出てコピペできなくなりました。ｶﾞｧｯﾃﾞﾑ！

次回からはめんどくさいですが手打ちでやろうと思います。
それかコピペするための代替手段を見つけます。

<br>

ではでは、次の2刺し目でお会いしましょう。