感想

• （受発注関係なく）プロジェクト管理者

• 今後、管理者になる可能性はある人

• ビジネスオーナー（またはビジネスオーナーを目指す人）

👉プロジェクトに関わる全ての人に必読かな

「自分には自分のコード打ち方やスタイル」

で協調性がない人は、個人開発向けかなあ。そんな人チームにいても、ややこしくなるだけだし。チームで仕事をする人なら読んどいて損はないなあ。

P.264にある「プログラマの時間の使い方の一例」

は、一読の価値あり。
管理職で、ここまで洗い出しと把握してきちんと工数の見積もりを出している人ってどのくらい存在するんだろう、、、。

前章「プログラムサイズが及ぼす影響」

とも関連するけど、

人数さえ増やせば、その分生産性が上がるわけではない

ことを、Brooksの研究を引き合いに、よりわかりやすい例を出しながら、p.258のチームを増強するで説明してる。

この本を昔全部読んでた上で、

いろいろな開発現場で実践できてないところばかりを見てきたから、
前章までで何度か、

ガントチャートは×1.5で引く

って書いてた、、、💦

詳細

見出しとしては、

1. 良いコーディングの奨励

2. 構成管理

3. コンストラクションスケジュールの見積もり

4. 測定

5. プログラマは人間である

6. 管理者の管理

7. 参考資料

8. まとめ

て感じ。

ゼミ、研究室、サークル、バイトリーダーなどで学生時代に、

人の上に立ってまとめてきたみたいなことを、就職活動でアピールする人も多いとちらほら見るけど、ビジネスとして具体的に、ひとつでもアプリやプロジェクトを企画立案、リリースまで通してやった人ってどのくらいいるんだろう。

リーダーや管理者になる人って、

• プレーヤーとして優秀な人（少数）👉理想

• 何も挑戦しない分、失敗もしない（それなり）👉波風もない分、新しい発想もない

• 生来的な気質で「自分は人の上に立つ人間」と思い込み、普段から声が大きく、自分の意見を押し通し、反対意見には、耳を貸さず、反対意見を言う他者を蹴落とす、都合の悪い部分は論点すり替え論法で煙に巻くパワーゲーマー（圧倒的多数）👉管理できず、責任も取らない。

ないずれかしかどこの職場でもみたことないなあ。

「なってから経験を積んでもらえればいい」＝経験が人を育てる論

で、安易に抜擢しちゃうのに、管理者教育や研修などを行わないか行っても抽象的な研修だけで、現場の抱えた問題を分析できてない管理者しかいない会社も多いしね。
現場をよくするために、管理者に研修を受けさせてるはずが、社外研修と会議ばかりで管理者がほとんど現場にいないなんて現場もたくさんあったし。

「うちの職場にはデキる人しかいらない」

って（IT業界に関わらず）管理者も結構いたけど、「デキる」の定義が曖昧で、
①履歴書や職務経歴書、資格が優秀　＋　②上司や先輩に逆らわない（別に逆らってないが）　👉　会社にとって都合の良い人　＝　デキる
と勘違いしてそう、、。

管理能力の乏しい管理者にとっては、

• 管理者である自分の邪魔をせず、

• 余計（だと思う、実は必要最低限）な説明をしなくても、

• 期待どおりに動き、期待以上の成果を出す人

👉（会社にとってではなく、自分にとって）都合の良い人＝ただのイエスマン＝優秀
て思考パターンなのかな？
そんな管理だと本当に優秀な人から見切りをつけて、会社を辞めていくだけなんだけどね。
（他にも山ほど会社はあるし、もはや個人から世界に発信できる時代だから、会社の存在意義自体が揺らいでるし。）

①履歴書や職務経歴書、資格が優秀　でも、

長年、開発部署にいただけで実は、

• ドキュメントの作成や工数管理（これも組織にとっては必要な仕事だけど）しかやったことがない。

• 会社の業務に関するプログラミング言語しか触ったことがない。

人なんてザラにいるし、

②上司や先輩に逆らわない　結果、

• プロジェクトを頓挫させた

• 下の意見を跳ね除け続け、イノベーションの芽を潰して会社全体を傾けた

• 大損害を与えて実は自主退職した

人も、言わないだけで多いけどね。

例えば、

Javaのエンジニアを募集してるとして、
「学校後、社会に出てからCOBOLやFORTLANで、こんなにすごいプロジェクトをいくつも成功させてきました！！！」
って応募者が来た場合、面接担当の管理者が、
「それで、うちのプロジェクトで今回必要なJavaの経験は？」
ってならず、
「それは素晴らしい！！！じゃあうちのプロジェクトももう成功が約束されたようなものですね。（うちもJavaと言ってないけど、これだけ輝かしい経歴なら、聞かなくてもできるんだろう）」
で採用し、入社後いざコードを書かせようとすると、
「なんでJavaならJavaって面接時に言わないんですか！！！」
とか、
「私はCOBOLやCの専門だと面接時に伝えていて、なぜ内定から入社まであんなに時間があったのに、Javaって言わなかったんですか！！！！」
または、
「実は何もできないけど、営業トークで、、、。嘘は付いてません。てへぺろ」
てのがオチ。

面接時に具体的にコードやプログラミングの話をしない
👉ジャグリングの面接で実技を見ずに採用するようなもの。
↓
履歴書と過去の経験、人柄が、今回も利益を生むわけではない。

巨大企業にできて、他の企業にできてないこと

（しっかりした管理者教育に基づく）
垂直的統合【Vertical Integration】
⇅
（精神論や経験論、自分理論の前にやることや学ぶことはあるだろうに）
学ばない管理者は、余計な作業と会議を増やす（＝より忙しくする）だけ。

忙しい管理者ほど管理方法を学べばいいのに（時間がないから）学ばない

プログラマか否かに関わらず既に、

ある程度のコードを書ける、読める、簡単なツールを作れて当たり前

の時代（令和の読み書き算盤）
👉「自分は〇〇だから関係ない」と肩肘張っても、遅かれ早かれ学ばざるを得ないのに。

●プログラマの役割：
必要な素材を判断する、要求を実現するコードを打つ、事態が起きた時に対処する　など。

●管理者の役割：
要求を整理する、必要な素材を集める、コードを打ちやすい環境を作る、トラブルを未然に防ぐ、納期を調整する　など。

それを弁えず、管理される側に

• 精神論を振りかざす

• なんとかしろと尻だけ叩く

• 現場の問題を放置する

• 納期だけ厳守する

だけなら誰でもできる。

「仕方がない」で片付けられても、プログラムは動かない。
経験豊富なプログラマはこの章に書いてるとおり、管理者を管理する。
風通しのいい職場作りで初めのうちに気付いてないところを提案しながら。

まとめ

マネジメントやリーダーシップは所詮、「えこ贔屓（TSL）」
👉優秀と思う部下を優秀と思っているだけ
↓
本当に優秀なプログラマは地位どころか、会社にすら執着しない。
👉人格と才能は両立しない
↓
💃（個人的な経験、希望的観測、べき論などの）
先入観を捨てて、急がば回れ🕺
会議を繰り返しても見えるのは、上司の顔色だけ。
解決策は現場にしかない。

参考文献（今までの記事で紹介してる本ばかり）

プロジェクト管理

については、こちら。

古典的な名著ばかりだし、管理者向けの本なんて腐るほどあるから、読んだことある人ばかりだろうけど、、、💦

TSL（トランザクショナル・リーダーシップ）

については、こちら。

経営学の本だけど、18章あたりに、新しいリーダーシップ研究の成果が纏まってるので、面白い。（オーセンティックリーダーシップが好き）

Vertical Integration 

については、こちら（GAFAの原著）

chapter 7 The T Algorithmは必見。てかGAFAやらGAFAMやらトレンディな言葉を多用する人で、T-アルゴリズムを話す人に会った事ないんだよなあ。 

名著と理論は腐らぬ〜〜〜〜〜🕺