はじめに
この度、マネジメントの勉強の為に「ピープルウェア」を読みました。
PMBOKの解説本を読んで以来、2冊目のちゃんとした(?)マネジメント本のインプットでした。
私はここ一年程小さなチームを纏めているのですが、メンバにはよく「アウトプットしてね」と依頼しているにもかかわらず、
自分はインプットばかりで全然アウトプットしてないな～と気づいたのでここに記そうと思います。
(冷静に見ると棚上げクソ野郎ですね、メンバの皆さんごめんなさいでした)
ということで、本稿では「ピープルウェア」を読んで、個人的に刺さったところを
かいつまんでメモ＆感じた事を書いていこうと思います。
※刺さった ＝ 読んでいてハッとした と捉えてください
「ピープルウェア」とは
「ハードウェア、ソフトウェアと共に、コンピュータ技術の三つの中心的な側面の一つを表す用語である」そうで、
字のごとくコンピュータを操る人間を指した言葉で、色んな含みを持った学術用語のようです。
出典_Wikipedia) ピープルウェア
で、私が今回読取り上げるのは単語そのものではなく、「ピープルウェア」という題名を冠した
通称「デマルコ本」と呼ばれている、トム・デマルコ著のマネジメントについて書かれた本の中の一冊です。
初版は1987年と、改訂で最新化されているとは言え もはや30年以上前の本になります。
しかし、IT業界では有休悠久とも思える時を経た今なお、随所で良著と評されています。
個人的に、読んでみて
「開発現場/マネジメント層の2つの目線から的確に、芯のとらえた話」が書かれていてスッと頭に入るような感じがしました。
ところどころポケベルといった時代を感じるアイテムだったり、いかにも"ギーク"なエンジニア像が前提とされていて
今となっては違和感を覚える記述もありますが、全体としては時代に囚われない内容でとてもタメになりました。
小難しい理論が書き連ねてある教科書、というよりはエンジニアの現場あるある本、という感じで読み進められますので
私のような教科書アレルギー及び、ユーモアなしには文章を読めない病を患っている方にもお勧めです。
「ピープルウェア」の章立て
全体として6部構成になっており、以下のように部ごとに違った観点から
「エンジニアのパフォーマンスを発揮させ、組織/プロジェクトが成功するにはどうすればよいか」
という主題にアプローチしています。
- 人材を活用する
- オフィス環境と生産性
- 人材を揃える
- 生産性の高いチームを育てる
- 肥沃な土壌
- きっとそこは楽しいところ
という章立てになっています。
(って箇条書きした題名だけでは全然内容がわかりませんね...)
ちなみに章立て～といいつつ、「第一部 人材を活用する」、第xx章～～、第xx節～～という感じの構成になっています。
では刺さったところベースで、それぞれの部/章ごとにをつらつら書き起こしていきたいと思います。
読んでて「意味わからん」「それはちゃうやろ」と首傾げてたところはざっくりカットする予定です
※1 本稿では地の文が私が書いている要約や意見で、引用部分が本書の著者が書いたところです
※2 引用の都合上、言葉尻を変えることがありますが、極力原文のまま記載します
※3 勢いでまとめている節があるので、丁寧語等の文体が崩れてしまう事をご容赦下さい
～第一部 人材を活用する～
第一部ということもあり、ここではこの本の概要を示している。
著者はコンサルタントとして働いていていくつもの会社を見てきた中で次のように述べている。
ピープルウェアプロジェクトの最初の十年間、筆者は毎年開発プロジェクトとその結果について調査した。
(中略)
調査した失敗プロジェクトの圧倒的多数は、原因が単なる技術的問題として片づけられないものばかりだった。
そんな訳で、本書ではエンジニアを取り巻く、プロジェクトの社会学的な側面(要するに 人に関する問題 )から、
プロジェクトないし組織運営をどうすればうまくいくか、また、何をすると失敗しやすくなるのかという事を紐解いていく。
一章 今日もどこかでトラブルが
先述のようにプロジェクトで問題になるのは社会学的なところ、人に関するところが問題である。
これには人自身の性質/性格といったことだけでなく、人を取り巻く環境も該当する(作業環境とか組織の特色とか)。
マネージャーのほとんどは、技能面より、人に気を配っていると思い込んでいる。
しかし、本当にそうしているマネージャーは滅多に居ない。
(中略)
本来は、担当者が解決する技術的な難問を、自分で解くことに時間を割くのだ。
作業をマネジメントするのではなく、作業そのものをやっている。
思ったこと)
いわゆるプレイングマネージャー云々の話ですね。身も蓋もないですが現場の要員に依りけりなところですので
「プレイングマネージャー ＝ 絶対悪」 というわけではないと思います。
著者としては、技術的なところにばかりにかまけていないでマネージャーなら人に気を配れ、と言いたいのかなと思いました。
年次的にもそうなってしまうのは仕方のない事なのですが、現状私もプロジェクト内ではプレイングマネージャー的立ち位置で
技術的な作業の比率が高くなってしまっているので、のっけから刺さりました。
この原因は、マネージャーが企業に入ってから受けた教育にある。
どのように仕事をするかは教えられたが、どのように仕事をマネジメントするかは教えられなかったからだ。
(中略)
仕事の人間的な側面より、技術面に注意を多く払う理由は、重要だからではなく、単にやりやすいからだ。
人間関係は複雑だし、あれはあれ、これはこれと、はっきり割り切れるものではないが、仕事で一番大切なのである。
思ったこと)
実際上記引用の通りなのですが、
本書を通して忘れてはいけないのは「著者は世界を飛び回るコンサルタントで、内製が多い欧米の大企業をよく見ている」という前提があることです。
プロジェクトや会社に従事するエンジニアは、皆エンジニアとしてしかるべき技術レベルや学習における姿勢を持っていて、
いわゆる「ギーク」と呼ばれるオタクっぽいいかにもなやつ、という前提のもとに成り立っている気がします。
(勿論、著者によって明記されている訳ではないですが)
現状日本のエンジニアの中にはエンジニアとしての基礎知識や理論、学歴をすっ飛ばして成った、文学部出身、音大卒、はたまたゴリゴリのパリピなんてザラにいるのです。
(パリピじゃないですが私もゴリゴリのウホウホ文系出身エンジニアです)
となると当然現場のエンジニアのレベルもまちまちです。「仕事で一番大切なのは人間的な事」と言い切れるのは
エンジニアのレベルが高く、少なくとも技術面で現場の仕事に支障が出る事が少ないような企業だけなんじゃないかと思います。
ともあれ人間的な事が大切なのは全くその通りですね。
二章 チーズバーガーの生産販売マニュアル
ソフトウェアの開発作業は、工場における大量生産とは本質的に異なる。
しかし、開発作業のマネージャーやそれに携わる人々は、製造作業のマネジメント哲学が形作った考えを、知らないうちに受け入れている。
以下のようなやり方はファーストフード(あるいは製造作業)ではうまくいかもしれないが、ソフトウェア開発ではうまくいかない。
知的労働者を効果的にマネジメントするには、これと逆のことをやらなければならない。
- エラーを叩き出せ。人間という機械を極力スムーズに動かせ。
- 仕事でヘマをやった奴は厳罰だ。
- 人はいくらでも補充がきくものとして扱え。
- 決めたやり方を手早くやれ(どうやってスピードを上げるかとか、何を止めたらよいか、ということは決して考えるな)。
- 作業手順を標準化せよ。万事、マニュアルに従え。
- 新しいことを試みてはいけない。それは本部の連中の仕事だ。
思ったこと)
幸いなことに私はすべてに当てはまるような現場、組織に属したことはありませんが、
自分の置かれている環境と照らし合わせると、どこかしら当てはまるところがあるのではないでしょうか。
以降の節ではこれらの逆をいくことを細かく説明しています。(すべての対になることが挙げられてるわけではありませんが)
長いので要約すると
- 間違いを恐れさせない。間違いを許容するような試行錯誤設計を実践すべし。(現状を訊いて、担当者が問題をぶちまけたら寧ろ褒める)
- 画一的な製造業的マネジメントではメンバの個性が邪魔となる。しかし知的労働者のマネジメントにおいてはユニークな個性こそがプロジェクト内の不思議な作用を活発にし、効果的に働く。
- プロジェクトが安定状態になるときは終わったとき。プロジェクトの静的な面だけでなく、動的な側面にもフォーカスすべし。人を入れる場合はコーディングやドキュメント作成能力だけでなく、その人がどれだけグループ全体にうまくなじむかも注視すべし。
- 設計や開発といった目に見える作業上の役割だけでなく、メンバにはチームに結束や安定化といった作用をもたらす「触媒」となる人がいることも忘れてはならない。
- 頭を使う仕事の重要性は、仕事が大きくなるほど増大する。
となっています。
間違いを恐れさせない。この本では書かれていませんが昨今話題の「心理的安全性」にも繋がる重要なことだと思います。
メンバの個性についてもその通りですね。
「一人だけリモートワークでフレックスで作業しますわ～」とかあまりに逸脱していることは問題ですが、
本の中にもある通り、給料の使い方など仕事に直接関係ないところまで踏み込んでどうのこうの言ったり、
メンバが作業環境について意見したことを「わがまま」と決めつけて排除してしまうなど、
各人の意見や個性を頭ごなしに排除するのは製造業的マネジメントに他なりません。当然メンバのフラストレーションも貯まります。
(メンバのモチベーション、マネジメントの良し悪しの観点でも、最低限素直な姿勢で一旦は聞き入れる、という姿勢が理想ですね)
「触媒」についても同意ですね。(いわゆる「ムードメーカー」ってやつですね)
余談ですが、世間一般では「ムードメーカー ≒ 本質(やるべき事)の面はそれほどでもない」みたいなイメージってなんとなくないでしょうか。
恐らくは「仕事ができる＝強いイメージ」という図式があり、「ムードメーカー＝やわらかいイメージ⇒仕事苦手」みたいな事なんでしょうが、
不思議とITの現場では「ムードメーカー ＝ 仕事もできる人」だったりする事が多い気がします。
チーム力が重要になる現場では、実力を持つ人は雰囲気の重要性を(例え自覚はなくても)分かっているってことなのでしょうか。
三章 ウィーンはきみを待っている
思ったこと)
この章の最初の節は正直そこまで共感できませんでした。
要するに、アメリカには「部下の尻を叩いて馬車馬のように働かせるのが生産性を上げる事だ」という考えているマネージャーが多くいるが
それらは当然間違いでメンバにはそれぞれ人生があり、今やっている仕事よりもはるかに大切なことがある、ということを頭にいれるべき。
という話でした。
(章のタイトルは「人生にはやりたいことがたくさんあるよ～ウィーンは君を待っている～」というビリー・ジョエル「VIENNA」の引用らしいです)
今時そんな19世紀の悪徳資本家みたいなマネージャーいますかね？
(それこそ画一的なやり方でガリガリ手を動かす事＝仕事になるような現場ならあるかもしれませんが)
もはやマネジメント論を学習する入口にも立っていない話で、論外すぎてそんなこと今更言われてもなぁって感じでした。
次の節では、
40時間をはるかに超えて実のある仕事をすることは、生身の人間にはとてもできない。
少なくとも創造的な仕事に必要な張り詰めた状態で、そんなに長い間続けて仕事ができるわけがない。
といった感じで馬車馬のように働くことそのものを否定しています。
(節のタイトルも「残業なんかくそくらえ」)
これもその通り過ぎて特段思うところはなかったですね。当たり前ですが企業(経営者側)にとっても残業はないに越したことはありませんし。
次の節では以下のようにワーカホリックについて触れています。
まじめに残業し、無業時間(残業の反動で必要になる、生産性が上がらない時間)で埋め合わせができない人が、ワーカホリックに陥る。
ワーカホリックの患者は効率は低いが、メチャクチャに長い時間働くし、十分なプレッシャーをかけなければ、自分の生活を犠牲にしながら働き続ける。しかし、人生にとってそんなに大切でないこと(仕事)のために、もっと大切なもの(家族、愛情etc)を犠牲にしていると気づいたとき、
その人はプロジェクトが終わったあとで永遠にいなくなる。
思ったこと)
本の記述を読んでいると「終わらせられない私が悪いんです...」と暗い顔で残業している人がイメージに浮かんだのですが、
これって本人のテンションに関わらず成りうることかなと思いました。
というか "本当にやらなきゃどうしようもない状況" になったら本人の真面目さにかかわらず残業しなければいけない状況になりますからね。
ともかく残業そのものが必要かどうかにかかわらず、ワーカホリック(仕事より大切なものを犠牲にしている状態)に陥らないように
作業面、身体/精神面でメンバをマネジメントすることが肝要なのかなと思いました。(退職というその後の悲劇を回避する為にも)
上記の流れを汲んで、次の節はマジでぶっ刺さるので覚悟しておいてください。(結構辛辣な内容になると思います)
生産性の話を聞く機会があったら、退職に触れているか注意してほしい。触れていない可能性は非常に高い。
(中略)
生産性を論じるときは、退職問題に触れないと全く意味がない。生産性を向上させる典型的なやり方について考えてみよう。
- もっと長い時間働くようにプレッシャーをかける。
- 製品開発を機械的なプロセスにする。
- 製品の品質について妥協する(第4章にて詳述)。
- 手順を標準化する
こうした方法は仕事を面白味のない、やり甲斐のないものにする恐れがある。
その結果、生産性を上げると退職率も上がる危険性がある。
思ったこと)
残念ながら本著の中では他に上記以外の生産性を上げる手立てが書いていませんが、
2019年のエンジニアを取り巻く環境なら、やりがいの低下に直結しない「ツールの活用」という素晴らしい選択肢がありますので
必ずしも「生産性のアップ＝痛みを伴う事」という図式ではないと思います。
ただ、結局のところ標準化や機械的なプロセスの順守は知識労働とは遠ざかってしまいますので
やり甲斐が低下する危険性は十分にあるかと思います。たとえプロセスが機械的なものでなくても、
そもそも "決まったやり方でやらせる" ということ自体が苦痛になったりもしますしね。
ということで、以上のことから著者は以下のように述べています。
生産性は、利益をコストで割ったものと定義すべきである。
利益は、作業時に節約できた金額、または仕事からの収益とみることができ、コストは全体のコスト、
つまり、退職者の補充に費やした余計な費用を含むべきである。
これは生産性に限った話ではありませんね。退職の原因が明確に特定のプロジェクトにあるならば
プロジェクトの売り上げからも退職者のコストを差し引いて利益計算すべきだと思います。
四章 品質第一……時間さえ許せば
この章ではエンジニアの感情を切り口に、製品の品質について切り込んでいく。
誰しも、純粋に仕事に関係したことで、一度ならず感情をあらわにした経験があるだろう。
今、それを思い出し、この感情はどこから湧いてきたか自問してほしい(おそらく今まで何度もそうしただろうが)
そのことについて何も知らなくても、原因は、自尊心を脅かされたことによると断言できる。
個人の生活では、いろんな原因で感情が高ぶることがたくさんあるが、オフィスで感情を刺激する最大の要因は、自尊心を傷つけられることである。
思ったこと)
恥ずかしながら(？)私も経験あります。そして御多分にもれず自尊心を脅かされたことが原因でした。
ここの部分だけでも正直ハッとしてぶっ刺さった感があったのですが、まだまだ続きます。
大抵の人は、自尊心を、自分の作った製品の品質(製品の量ではなく質)と強く結びつける傾向がある。
(本当に必要だとはいえ、アクビが出そうな仕事をどんなにたくさんこなしても、どういうわけか、何の満足感も得られない)
どんなことでも、製品の質を落としかねないことを指示すれば、それに反抗する部下たちの感情に火をつけることになる。
私は生粋のめんどくさがり屋なので、最後の一行は100％同意できないのですが(妥協＝楽になるってことですしね)
前半の2行で死ぬほど同意しました。
コードレビューとか資料作成でダメ出しされて少なからずショックを受けるっていうことも、こういう事なんだなぁって改めて思いました。
以降の章については、要約すると
マネージャーは得てして品質を軽視しており、製品の価格(コスト)と品質はトレードオフの関係にあると考えている。
しかし開発者は上記のように己の自尊心と品質とを同質に捉えており、コストカット(＝品質面で妥協する)は開発者自身の満足度やモチベーションの低下にも繋がってしまう。
また実際には、(他国と比べると)低コストで品質の良い製品を出荷する日本企業のように、
長い目で見ると高品質がコスト低減をもたらす、という事が言える。
といった感じの内容が書かれています。
私は生粋のめんどくさがり屋なので(以下略
あと、この章では内製の企業が前提になっているので、受託開発の現場にそのまま当てはめることは難しいのかな、という気がします。
なのでサラッと読み飛ばしました
五章 パーキンソンの法則の改訂
この章ではパーキンソンの法則の話から始まり、逆説的に納期や品質について、またエンジニアの生産性について展開されていく。
英国の作家C・ノースコートパーキンソンは、1954年の著作で。仕事は与えられた時間に見合うところまで膨張する、という説を唱えた。
いわゆるパーキンソンの法則である。
(中略)
パーキンソンの法則は公理とはいえない。ニュートンの法則を法則と呼ぶのと同じ意味での法則ではない。
パーキンソンは科学者ではない。データを集めたわけでもないし、統計的推論の方法など理解していないはずだ。
しかし、パーキンソンはユーモアのセンスがあった。
この法則は、真実を表しているから人気を得たのではない。皮肉が利いていて面白いから当たったのだ。
思ったこと)
私もこの法則は以前聞いたことがあって、その時は「なるほどなぁ」と素直に感心したのですが、
著者の通り、何かの研究成果として発表されたものではないようです。
驚きと共に、何事も鵜呑みにしちゃいけないなぁと改めて感じました。
余談ですが今では当たり前のように広まっている物事や考え方も、このように当時の背景がわかると面白いですよね。
そういった意味では古い書籍でも読む価値があるのかなぁと思います。
このように著者はこのパーキンソンの法則が一人歩きし、自明の真実であるかのように世のマネージャー達に広まっている事を嘆いて(？)いました。
そしてここからはパーキンソンの法則は正しいものではないということをベースに、エンジニアの生産性について論じられていきます。
パーキンソンの法則は、ほぼ確実にあなたの部下にあてはまらない。
人生は、だらだら仕事をするにはあまりにも短い。彼らは楽しく仕事をしているから、永遠に引き延ばす気にはなれない。
長引かせると、誰もが心から望んでいる仕事を仕上げたときの満足感を味わう時期を遅らせるだけである。
妥協して自分の品質基準を下げる必要がない事さえ保証すれば、スタッフはマネージャーと同様に真剣に仕事を完成させようとするものだ。
思ったこと)
よくよく考えると、上記の通り、やっていて楽しい仕事であればどんどん進んでやりますし、
たとえ楽しくない仕事で、低いモチベーションを以て仕事をしたとしても
つまらない仕事をずっと続けたい人はいないと思うので、いずれにせよ「与えられた時間に合わせて仕事量が伸びる」
なんてことはそうそうないかな、という風に思いました。
健全な作業環境の下で、スタッフが職務をきちんと遂行しない理由は、
能力不足か、自信の無さか、プロジェクトの目標や同僚になじめないことにある。
いずれも、納期によるプレッシャーは、大した解決策にはならない。
(中略)
つまり、自分の部下をパーキンソン流に扱っても、何の効果もない。
そんなことをしたらプログラマーの品位を落とし、意欲をくじくだけである。
思ったこと)
私の所属する組織では受託にせよ請負にせよ、基本的にお客さんからゴール要件と期限が提示
されていますので、
マネージャーが意図的に納期を縮めてメンバに負担をかける、といったことはないと思います。
が、個人的に社内プロジェクトにおいてマネジメント的な役割を担当した際に、
上記のように期限を意識させて作業を遂行させようとしたことがありました。
(流石に期限を縮めるのではなく、「何時何時までですよ～もうすぐ期限ですよ～」といった感じでプレッシャーをかけた形ですが)
そして実際、大した改善は見られなかったので、この章を読みながら「他の原因に着目してアプローチすべきだったな」と反省しました。
しかし、パーキンソンの法則を少し手直しすると、どんな組織でも驚くほど真実味のあるものになる。
会社のルーチンワークは、就業時間に見合うところまで膨張する傾向がある。
この傾向は、会社の設立時に始まり、毎年ひどくなる。
成熟の頂点にある企業で働くのがあまり楽しくないのは、この理由による。
思ったこと)
他の会社の事情は知りませんが、ルーティンワークが煩雑になるのは十分考えられる話だなぁと感じました。
組織としての知見が溜まるにつれて、気を付けるべき事項の発見や資料が洗練されていく(＝えてして手間がかかるようになる)ということは想像に難くありませんね。
余談ですが、以前某巨大SIerさんの方式に則って設計書のレビューをした際には、
指摘点の性質やそれに対してどのように対応するのか、またレビュー対象となるドキュメントの量や掛かった時間等を事細かく記述しなければならず、
大企業って大変だなぁ(小学生並の感想)、と感じると共に「ここまで細かくデータ分析して、手間に見合うだけ役に立つのかコレ？」と疑問に感じました。
クッソ不毛だったので、マジでもう二度とやりたくないです
六章 ガンによく効く？「ラエトライル」
タイトルの「ラエトライル」というのは、かつてガンに効く謳われていた、アンズの種の事で、
ガン患者は例え根拠がなくても、藁をもすがる気持ちでこの「ラエトライル」を買い求めたそうです。
この章では上記の比喩のように「マネージャーが、いかに生産性向上という課題に苦しんでいるか」にフォーカスして、
そんなマネージャーが陥りやすい錯覚(失敗)を列挙しています。
以下要約です。
- 生産性を飛躍的に向上させる方法があるはずなのに、今までずっと見落としてきた。
⇒そんな基本的なものを見逃すほど馬鹿ではあるまい。
そして、そんな状況を簡単に打破できるほど画期的な方法もそうあるものではない。
ただ、学んだり改善したいというその姿勢自体は決して間違っていない。
他のマネージャーは2倍も3倍も成果を上げている。
⇒そんなことは気にするな。大げさに宣伝されている魔法の方法は、
ソフトウェア開発ライフサイクルのコーディングとかテストの部分に焦点を合わせているに過ぎない。技術は日進月歩で、油断するとすぐに置いて行かれる。
⇒その通り。技術は日進月歩である。しかし、これまで述べてきた通り、
マネージャーが行っている作業のほとんどは、本当はハイテク作業とは呼べない。
ソフトウェア開発の手法や流れも従来のまま大きく変わっていないはずだ。プログラミング言語を変えれば、生産性は大幅に上がる。
⇒プログラミング言語は、問題を考える方法に大きな影響を与えるので重要だが、
これもコーディングの工程にしか影響を与えない。
5％は上昇するかもしれないが(馬鹿にできない値ではある)、それより大きくなることはない。バックログが多いから、すぐにでも生産性を2倍にする必要がある。
⇒プロジェクトの完成時にコストを計算すると、当初予算をはるかに上回るのは常識である。
当初予定していたが実装できなかった機能の中でバックログになったものは
えてして優先度が低いもしくは開発コストに比べて利益が少ないものである。
そんな機能に対して無理に生産性を上げてまで取り組む必要はない。何もかも自動化してしまおう。そうすればソフトウェア開発者がいらなくなるのではないか？
⇒これはソフトウェア開発者は簡単に自動化できるような仕事をやっている、という思い込みである。
開発者の主な仕事は、ユーザー流の表現で表したユーザー要求を、厳格な処理手順に組み替えるための、
人と人とのコミュニケーションである。これは、どんなにソフトウェア開発のライフサイクルを変えようと、絶対に必要な仕事であり、自動化できるはずがない。部下に大きなプレッシャーをかければ、もっと働くようになる。
⇒違う。ヤル気をなくすだけだ。
思ったこと)
箇条書きだったので抜粋が長くなっちゃったので感想もサクッと行きます。
2についてはマネージャー毎に成果の差はあれど、本やセミナー、ツール等の宣伝で謳われているように
2倍も3倍も差がつくことは無い、という事なのでしょう。
私も「あからさまに自分が駆け出しのマネージャーで右も左もわからない」といった状態でなければ
そこまで他のマネージャーと差がつくことは無いと思います。
もしそこまで差がついてしまっているのであれば、マネジメントとは関係のない場所、
元々のプロジェクトの規模感や要員の特性等々、違う要因があると思います。
3もその通りですね。純粋なマネジメントの作業としては技術に囚われる部分はあまりないのではないかと思います。
とはいえ「マネージャー ＝ 技術を全く知らなくでもできる」 かと言うと、それもまた違うと思います。
最先端技術の取り扱いやコーディングまでは分からないまでも、技術の概要や
「万が一誰も分からなくなった場合に、自分でも作業できる入口に立てる知識」は抑えて置いた方がよいと個人的には思います。
残りの項目はごもっともすぎて著者が書いた事にただ頷くばかりですね。
～第一部の締め～
いかがでしたでしょうか。
ご覧いただいたように、第一部は本書の入り口である為にこれから展開されていく内容が随所に散りばめられています。
第一部だけでも相当含蓄がありますね、ちゃんと落とし込んで読もうと思うと同じ量でも小説の3倍くらい時間がかかります。
次の第二章はエンジニアの環境面をこれでもかと掘り下げた話で、ぶっちゃけあんまり面白くないので
記事としてもまとめる内容が少なくなる予定です。
てか画像は無いわ量は多いわで、ハチャメチャに読みづらい記事になってしまいました。
この記事をここまで読んでくれた方は果たしてどれだけいるのでしょうかね？？
もしあなたが今この文を読んでいるのであれば、あなたはとてつもない根性の持ち主です。おめでとうございます。
適当な締めですが、私も書いてて疲れたのでこの辺で終わろうと思います。
ピープルウェアまとめ記事自体は続くので、是非次の部の記事も読んでくださいね！