管理者が管理できる人数は10人が限度

2018年10月13日土曜日

システム開発 システム業界問題

t f B! P L

システム開発業界を渡り歩いていると、おかしなマネジメントしているチームに遭遇することは良くある。
その中で参画者に迷惑なのが人数が多すぎるチームである。
単にチームが多いだけなら別に迷惑では無い。
適切にマネーシャーの下にサブマネージャーが複数配置されていれば問題ない。
問題なのは「マネーシャー一人で10人以上のメンバーをマネジメントしているチーム」である。
人間一人で管理できる人数は10人が限度である。
陸軍や陸上自衛隊の分隊も11人編成だ。
隊長一人に隊員10人の編成だ。
多くの組織は10人単位で階層を作りピラミッド型組織を形成している。
この編成はモンゴル帝国のころに発明されたらしく、この編成により革新的マネジメントを行ったモンゴル帝国は世界の大半を支配した。
以来、組織はこの10人単位の階層で組織を管理している。

大雑把なアサイン

SIer業界は人員配置がかなり雑なところが多い。
以前にも説明したがSIer業界では多重請負が普通になっており、大規模なプロジェクトになると8次請けまでの多重階層が形成されていたりする。
だいたい3次請け以下になると人材派遣かSESの会社になり多重派遣している。多重派遣は違法なので偽装請負で誤魔化している。
3次請けあたりが派遣やSESを集めて開発チームを仕切っている。
この3次請けの会社は「人的レバレッジ」という形で経営しているケースが多い。
自社では正社員を多くは雇わずに、受託開発の案件を受ける度に必要な情技師(ITエンジニア)を雇う。プロジェクトが完了すれば情技師を解約(クビに)する。
雇われる情技師は派遣やSESである。
人的レバレッジを行う理由は案件の無いときの人件費負担を免れる為である。

人的レバレッジを行う会社は案件成立の度に人を集めるため、そうそう都合の良い人材を確保できる訳では無い。
また、雇われる派遣やSESの情技師も熟練者から素人まで様々である。
派遣情技師もプロジェクトが終わったら次のプロジェクトに参画するので、次のプロジェクトの始まりのタイミングにちょうど良く参画できるとは限らない。
開発工程の途中から入ることも少なくない。
するとプロジェクトのアサインは必然的に「早い物勝ち」で決まっていく。たまたまプロジェクトの開始時期に、担当していたプロジェクトの終わった情技師が前工程から参画する。
前工程から参画した者は指導的立場になる。そのプロジェクトに詳しいので当たり前だ。
すると能力と関係無い序列ができてしまう。
前工程から参画できたのが経験年数の少ない情技師で、後工程から参画したのが熟練者の場合、未熟な情技師が熟練者に対して指導的な立場に立たざる得ない状況になる。
これは未熟な情技師にとっても熟練者にとっても、やりにくい状況だ。
例えば先に入った未熟な情技師が作った設計には欠陥が多いとする。後から入った熟練者は正しく作る為に設計の欠陥を指摘して修正を求める。これは未熟な情技師にとってストレスになる。熟練者も仕事がやりにくい。
人的レバレッジという体制がこのような状況を生む。
本当は熟練者が前工程から入り指導的立場に立ったほうが良い。(熟練者は必ずしも年長者とは限らない)

以上のように人的レバレッジを行う会社はアサインがデタラメであることが多い。
このことだけで本を書いた人が居るぐらい問題は深い。

多すぎるメンバー

人的レバレッジによるチーム編成を行う組織は管理階層がほぼデタラメなので管理者が管理しきれないほど大人数になっていることか多い。
15人ぐらいのチームを一人の管理者が管理していることはザラである。
こういう管理者は忙しすぎて管理が行き届かない。メンバーが相談や質問をしたくても管理者が他の用事で捕まらないので個々人が不明確部分について曖昧な推測に基づいて仕事を進めていたりする。
当然間違いだらけになる。
こういうケースは管理者やメンバーに問題がある訳ではなく、アサインを担当した偉いさんが悪いのだ。

チームは10人未満で構成すべき

管理者が純粋に管理だけを行うなら最大10人のチームが限界だ。
もしシステムの全体構造に責任を持つアーキテクトをマネージャーが兼任するなら精々5,6人が限界だろう。
この場合でも自分自身は作業をできない。
マネージャーもアーキテクトも兼任した上で、更に自分も開発作業を行うなら、3,4人のチームを纏めるのが限界である。
一人の人間の頭の中に入る「複雑さの量」には限界があるのだ。情報処理能力にも限界がある。
日本人は大東亜戦争のときから精神論と根性論でインパール作戦戦うように、非合理的な仕事の進め方をすることが多い。精神論については敗戦してもなにも反省していない。
計画管理、人員配置、予算、情報などもう少し合理的に考えて計画を立てて欲しいものだ。

複雑すぎるシステム構成(モジュール分割とチーム編成)

大きすぎるチームが編成される原因に、大きすぎるシステムがある。
モジュール分割についてよく考えない状態で悪戯に機能を追加することを繰り返したシステムは、一人の人間の頭で理解できないほど複雑になっているものか多い。

システムはある程度以上複雑になったら、複数のサブシステムに分割してある程度以上複雑にならないようにするモノなのだが、そういう基本的な常識の無いSIerも増えた。
プログラムも組めない人間が設計やってるぐらいだから驚くことでもないが、絶対上手くいかない方法で計画管理されているプロジェクトの顧客はそれで良いのだろうか。

システムを複数のサブシステムに分割する手法をSOA(Service-Oriented Architecture:サービス指向アーキテクチャ)と呼び、機能単位に分割して実装する方法をMSA(マイクロサービスアーキテクチャ)と呼ぶ。
いずれにせよ、機能をモジュールの中に閉じ込めることによって複雑さを隠蔽することが出来るのでシステム全体の複雑さも大幅に低下する。
複雑さが減るということは工数が減ると言うことだ。
また一つのサブシステムは少人数で作れる為、管理負担を低減できる。
チーム編成は9人以下のチームが複数で編成されマネージャーが複数のサブマネージャーを管理する形態になる。

システムの複雑さの分割はマネジメントの複雑さの分割でもある。
複雑さを分割しているので一人一人のマネージャーの負担を軽減することができる。

多すぎる階級

いくつかの会社で働いた経験から言えば、会社組織の多くが、必要以上に多くの階級を作っている。
階級と言うものは管理と統率の為に存在する。しかし会社組織の階級には管理を目的としていない階級が多く見られる。

部下の居ない管理者に何の意味があるのか。
また、一人の管理者に部下が三人ぐらいしか居ないこともある。これなど上位の管理者が纏めてあと四人管理すれば良いでは無いか。
単に昇級する為に役職を与えていることも多い。これなど役職無しの専門性だけで評価する仕組みを作れば良いでは無いか。

このような感じで無駄に階級が多すぎるのだ。承認の判子の数が多すぎて、末端からトップまで情報が流れていかない。

もし10人単位の管理体制で組織を作ったら、
10人の組織なら階級はマネージャーとメンバーの2層で管理できる。
百人の組織なら3層で管理できる。
千人の組織なら4層で管理できる。
一万人の組織なら5層で管理できる。
十万人の組織なら6層で管理できる。
一般の会社は100人程度の会社で会長、社長、副社長、常務、次長、部長、担当部長、課長、課長補佐、係長、室長、主任など10層ぐらいの階層はザラにある。
ものスゴイ無駄だ。

管理やアサインが上手くいかない原因の一つとして無駄な階級も含まれると思う。

少人数チームの連携体制が必要

開発チームは9人以下の小人数で編制し、小チームの集合体によって全体を纏めた方が良い。
チームとチームの接点も必要最少限にすべき。
SOAの考え方でサブシステム間のインターフェイスを最小減にして互いの影響を最小減にすることで、工数を減らすやり方を「疎結合」と呼ぶ。
チーム間の相互依存関係も「疎結合」であるべきだ。無駄な仕事が発生しないように。

無計画な大人数チームは辞めるべき

SIer業界は人的レバレッジにより必要に応じて必要な人員を招集して解散する。ということを繰り返してきたが、いい加減に秩序や効率というものを考えるべきだろう。
人手不足で益々人員は集め難くなっており人をえり好みできなくなっている。
人的レバレッジ自体を止めた方が良いのでは無いだろうか。

「ではどうすれば良いか」は過去の記事で書いたので良かったら参照されたし。


このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ