ピープルウェア第1部「人材を活用する」ハンバーガー屋と開発チームのマネジメントは本質的に違う？！

[引用している本]

トムデマルコ；ティモシーレスター. ピープルウエア　第3版 (Japanese Edition)

こちらの第1部「人材を活用する」の一部分を自分なりにまとめてみました。

(※以下記事で表現しているハンバーガー屋は、紹介する本が例として載せている表現ですので、悪しからず)

[ひとことで言うと、こんな記事]

ハンバーガー屋のマネジメントの例は、横展開しやすいのだが、開発マネジメントに関してはそれが当てはまらない！
開発チームのマネジメントは、厳格なルールで縛らず、多くの試行錯誤ができるように促すべき！

[こんな人におすすめ]

「マネージャーってむずかしいなぁ」、「管理職ってむずかしいなぁ」な人
「"仕組みの実現"と"仕組みづくりを推進する"のマネジメントが大きく違う」というのを知りたい方

[目次]

開発プロジェクトは"政治的"な要因で頓挫する
ハンバーガー屋は「仕組みの実現」のためマネジメントする
開発チームは「仕組みづくり」をマネジメントする
まとめ：「仕組みの実現」と「仕組みづくり」のマネジメントの対比
その他：第1部「人材を活用する」で記載されているもの

開発プロジェクトは"政治的"な要因で頓挫する

システム開発が失敗する理由として、その多くは "政治的"な理由 で頓挫することが多いという。技術的な理由で頓挫するものは少ないと言われている。

"政治的"な要因の本質は？

著者は 人に関する問題である と言っています。本文で以下のように記されています。

政治的要因とは、直接関係しない、意思疎通の問題、要員の問題、マネージャーや顧客への幻滅感、意欲の欠如、高い退職率などであった。

引用：トムデマルコ；ティモシーレスター. ピープルウエア　第3版 (Japanese Edition)

上記を受け、以下の項目でハンバーガー屋と開発チームのマネージャーの思考を比較してみたい。

メンバー自身へのスタンス
メンバーのミスに対するスタンス
メンバーの振る舞いとして求めること
業務プロセスに関する考え
メンバーへの働きかけ

ハンバーガー屋は「仕組みの実現」のためマネジメントする

項目	マネージャーの思考
メンバーの捉え方	代替できるように
メンバーのミスに対するスタンス	ミスしたら罰を与える
業務プロセスに関する考え	手順を標準化し、新しいことをじしするのは本部の仕事
メンバーの振る舞いとして求めること	決めたやり方だけをうまくやって欲しい
メンバーへの働きかけ	考えるより手を動かすように、人を働かせる

特徴：メンバーは仕組みの"実現"のために

仕組みの再現性や標準性を大事にし、それを実施してもらうことが多いです。すでに標準化されている作業ですので、 メンバーは頭よりも手を動かすことが重要視 されます。

利点：横展開しやすいこと

本には書いてない内容 ですが、このマネジメントの利点を記述してみたいとおもいます。

ズバリ 横展開しやすい ということです。

仕組みを標準化する
マネージャーを採用
横展開の実施と同時に品質やプロセスのガバナンスを実施する

上記3点を実施することで、大成功を収めた「マクドナルド」の例が面白く描かれた映画があるので、ぜひ見てみてください。

ファウンダー　ハンバーガー帝国のヒミツ(字幕版)

開発チームは「仕組みづくり」をマネジメントする

項目	マネージャーの思考
メンバーの捉え方	キーマンのナレッジを失うコストは膨大、チームに馴染むかが大事
メンバーのミスに対するスタンス	試行錯誤と捉える、失敗を恐れさせないことが大事
業務プロセスに関する考え	厳格なメソドロジーを無理強いしない
メンバーの振る舞いとして求めること	よく考えてから仕事をすることが大事
メンバーへの働きかけ	人を働く気にさせる

特徴：メンバーは仕組み"づくり"のために

上のようなまとめから上がってくるキーワードとしては、 試行錯誤 、 自発的（考え、働く気） 、 人材代替不可 みたいなところでしょうか？

基本的にシステム 開発というもの自体が「仕組みづくり」 な気もするので、 「本当にこの仕事が必要なのだろうか?」 、 「設計はこうしたほうがいいのではないか？」 、ということ自体を考えてもらうマネジメントが必要だということではないでしょうか？

利点：プロジェクト失敗する要因が減る

政治的要因とは、直接関係しない、意思疎通の問題、要員の問題、マネージャーや顧客への幻滅感、意欲の欠如、高い退職率などであった。

引用：トムデマルコ；ティモシーレスター. ピープルウエア　第3版 (Japanese Edition)

再掲しますが、多くのプロジェクトを分析してきた著者が、失敗したプロジェクト"政治的要因"を分析し、うまくいったプロジェクトとの比較でまとめたものですので、利点はプロジェクト失敗要因の減少だと思います。

（鶏卵的な順番の記載なってしまい申し訳ないです…）

まとめ：「仕組みの実現」と「仕組みづくり」のマネジメントの対比

項目	「仕組みの実現」をするマネージャー	「仕組みづくり」を推進するマネージャー
メンバーの捉え方	代替できるように	キーマンのナレッジを失うコストは膨大、チームに馴染むかが大事
メンバーのミスに対するスタンス	ミスしたら罰を与える	試行錯誤と捉える、失敗を恐れさせないことが大事
業務プロセスに関する考え	手順を標準化し、新しいことをじしするのは本部の仕事	厳格なメソドロジーを無理強いしない
メンバーの振る舞いとして求めること	決めたやり方だけをうまくやって欲しい	よく考えてから仕事をすることが大事
メンバーへの働きかけ	考えるより手を動かすように、人を働かせる	人を働く気にさせる

その他：第1部「人材を活用する」で記載されているもの

下記の内容も記載されています。ご興味ある方は、ぜひこの本を読んでみてください。

品質

Quality Is Free という言葉の本質についての解説が載っています。

ソフトウェア開発であれば、こちらの記事がとても参考になりますので、ぜひご覧になってください。

品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？和田卓人氏による「質とスピード」（後編）。デブサミ2020

生産性

開発チームにおける生産性に関しても記載されています。

ひとことでいうと 「無理な目標設定をすると、生産性が下がるよ」 という内容です。

マネージャーが陥りやすい錯覚

付け焼き刃的にマネージャーがやってしまいがちな例が7つほど記載されています。

__一緒に様々なことを学んでいく仲間を募集__しています。

このサイトのお問い合わせなどからご連絡いただけると幸いです。

ピープルウェア 第1部 「人材を活用する」 ハンバーガー屋と開発チームのマネジメントは本質的に違う？！