ネガティブな課題の隠蔽は悪

2018年9月5日水曜日

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

t f B! P L

システム開発チームの運営でやってはならない事の上位に来るのが「ネガティブな課題が発生したときに報告しないで隠してしまう」行為である。

例えば、
「開発が予定より遅れているのに締切間近になってそれを報告する」
「予想より多くの人員が必要になり余分なコストが発生しているにもかかわらず、発注元に報告しない」
「仕様変更が明らかに発生しているにもかかわらず受託者に対してそれを連絡しない」
といったものだ。

どれも課題発生直後に即時報告してくれれば、すぐに対策を立てて計画を変更し納期に間に合わせることができるのに、締め切り間近になって問題が発覚し、損害を招く。
というモノだ。

ちなみにシステム開発チームとは発注元の業務担当者や経営サイドの人間を含めた大きな意味でのプロジェクトチームのことてある。

システム開発では問題の発生は日常茶飯事であり、日常的に問題が発生するたび上長や関係者にリアルタイムで報告しなければならない。
システム開発で発生した課題は仕様変更や構造変更の対象になることが多いため、できる限り早くマネージャーに報告しなければ開発が間に合わなくなる。
また、同時にチームメンバーにアナウンスしなければならない。誰の作業に影響するかマネージャーには完全に把握しきれないものだからだ。

課題が隠蔽されるチームは風通しが悪く、人間関係がギスギスしており「簡単な報告すら気軽にできない」状態になっていることが多い。
こういうチームが形成される責任はアサイン担当者とプロジェクトマネージャー(リーダー)に責任がある。
メンバーの人格や性格に問題がある場合もあるがその場合は「そのような問題のある人間」をアサインした人間の責任である。

現代のSIer業界では「人的レバレッジ」と言われる体制でシステム開発を行っている会社が多い。
開発会社は仕事をいつ受注できるかわからない。開発者を全て正社員として雇用すると、仕事を受注できないときのエンジニアの人件費は会社の大きな負債となってしまう。
だから正社員をできる限り雇わずに、派遣エンジニアを必要に応じて雇用する。仕事がある時だけエンジニアを雇用し仕事が終われば解約する。
契約する派遣エンジニアも合法的な派遣会社の場合もあるが、多くの場合は SES と呼ばれる客先常駐の請負契約又は準委任契約のITエンジニアを雇う。
民法上これらの契約は指揮命令管理をしてはならないし、やれば偽装請負という犯罪なのだが、よく行われている。
労働法に定められた雇用者責任を放棄し社会保障費などの負担を回避してコストを最小限度にする為だ。
このようなSIerの経営形態を「人的レバレッジ」と呼ぶ。
レバレッジとは金融用語で資本が少ないとき、その資本を元手に何倍かの融資を受け、その融資資金を投資して利ザヤを稼ぐ手法で、これを「人」でやっているわけである。
ハッキリ言ってロクデナシなのだが「赤信号皆で渡れば怖くない」状態になっている。

このような体制でチームメンバーの人格性格に問題があったとしても、元々正規雇用しているわけでもなく、違法常駐委託で雇ったメンバーの責任にするのは無理があるだろう。
機械部品のように簡単に人を交換できる体制で運営しているのだから。

メンバーの人選含めてチームの報告し難い雰囲気や体制を生じた責任は100%アサイン担当者とマネージャーの責任だ。

報告し難い雰囲気を作り出す原因の大半を占めるのがマネージャー(リーダー)の人格だ。
真っ当な報告に対してすぐに「怒る」マネージャーは非常に多い。
「予定より遅れる」「初めから見積もりが甘い」「設計にミスがある」「指揮命令が間違っている」こういった現実を事実として受け入れられず報告されると拒絶反応を起こして怒る者は多い。
「怒る」とは「目前の現実の拒否」なので彼らは現実逃避をしているのだ。
問題が発生したら現在取り得る対策をして天命を待つしかないのに、いちいち怒ることで現実逃避をしているのだ。
これは一々仕事をさぼっているのと同じなのでマネージャーとして以前に職業人としてのモラルに問題がある。

ちなみに仕事では「怒る」と「叱る」は違う。メンバーがやるべき事が明らかになっているにも関わらずやらないのなら叱る必要がある。(もちろん十分に説明した上でだが)

真っ当な報告をするたびマネージャー(リーダー)が怒ればメンバーは段々とネガティブな報告をしなくなる。
マネージャーには良い報告しか上がらなくなり締め切り間近に致命的な問題か浮上する。
締め切り間近では殆どが対処不能である。

これはブラック企業の経営者に似ている。
ブラック経営者や上司のマネジメントは「アレもやれ!コレもやれ!全部やれコノ野郎!」といった一方通行の命令に頼ったフィードバックを受けない指揮命令を行う者が多いが、こういうマネジメントしていると部下は報告をしなくなる。また、自主的に行動して問題が発生すれば責任を追及されるだけなので「言われたことしか、やらなくなる」。
やがてこのマネージャーは必要な情報を受け取ることが出来ない状態でプロジェクト運営することになる。

「暗闇で船を漕ぐ」状態だ。
どこへ向かっているかもわからない。
どこまで進んだのかも分からない。
さらに部下は指示されるまで何もしない。
たとえ浅瀬に乗り上げようと、氷山に衝突しようと指示されるまで決して何もしようとしない。
船長は自分で周囲を観測し、船の状態を確認し、一々細かい指示を部下に出しながら、暗闇の中て船を進める。

「怒る」ことによって得られる結果が「暗闇で船を漕ぐ」ことだ。

自業自得、因果応報というものを馬鹿にしている人は多いがこれは真理てある。
仮に過去の悪行の結果が返っていないとすれば「まだ返っていない」だけだ。
行為の結果は必ず返ってくる。

チーム内の報告は気軽にできるようにした方が良い。SNSに投稿するように気軽に書き込めた方が良い。
ただそれだと重要では無い報告の量が多すぎて捌ききれなくなる。
重要度ABCなどの情報を付けさせ、さらにネガティブな報告を優先させた方が良い。
ポジティブは報告は極端に言えば受けなくて良い。
「遅れています」と報告が無いのは順調な証拠である。

忙しすぎるので管理できないは本末転倒

マネージャーか一人で15人も20人も管理しているプロジェクトを時々見かけるが、こういうのは大体「マネージャー」が忙しすぎて掴まらない。
この場合もメンバーはマネージャーに報告できない。
マネージャーがすっと会議室に篭り外に出て来ない場合があり「今日もマネージャーに会えなかったな」ということも珍しい事では無い。
こういうケースは根本的にプロジェクトの編成のしかたが悪い。
開発手法にもよるが人間が管理できる部下の数は10人が限度だ。それ以上の人数が必要ならピラミッド型の階級を作らなければならない。
陸軍でも小隊は指揮官含めて11人。
モンゴル帝国の軍も10人単位で階級を作っている。
アジャイル開発の一つであるスクラムではチームの総人数は最大9人までとされている。
これはプロダクトオーナーとスクラムマスターを含めての人数なのでメンバーの人数は最大7人までとなる。
これはおそらく人間がランダムに規則性も無く記憶できる要素数の上限である「マジックナンバー オブ ザ セブン」が人数の上限になっているのだと思う。

何にせよ15人も一人で管理できるわけないのである。
このような間違った編成になるのはシステムの設計と編成が間違っているからだ。
つまり開発しているシステムが非現実的に大きく複雑すぎるのだ。
こういう時は複数のサブシステムに分割して一つ一つのシステムを単純化する。
チームは二つに分かれそれぞれにマネージャーが付きその上にチーフマネージャーが付く。(アーキテクトも同様)

これでマネージャーが忙しすぎて掴まらないということは無くせる。
だいたいマネージャーが忙しすぎて管理が出来ないなど本末転倒であり、このような体制を作って疑問を感じないリーダーや経営者はバカである。

複数の情報源で状況把握せよ

現場の人間は管理者の視点に立ってプロジェクト全体を俯瞰することは通常はできない。
必要な情報が与えられていないし、それはメンバーの仕事ではない。
日本の企業社会ではマネージャーは「全体のこと考えて仕事してくれ」と言い、経営者は「経営視点に立って仕事してくれ」と言うが、それに必要な情報は公開しないし計画についても説明しない。
リーダーは業務の説明もしないし、経営者はバランスシート一つ見せようとしない。
これでプロジェクトを俯瞰したり経営視点に立って働くことは出来ない。
それに何より「マネジメントはマネージャーの仕事」である。

「それはお前の仕事だろう!」という話だ。

マネージャーが「全体を俯瞰しろ」とか、経営者が「経営視点に立て」というセリフは「オレの代わりにお前が働け」と言っているのと同じだ。

これに対する正しい回答はコレだろう。
「ならばお前の地位をオレにヨコせ!」

繰り返すが、現場は管理者の事など理解できない。
管理者は現場の状況を複数の手段を使って把握しなければならない。
現場の報告だけでは状況は把握できない。

少なくとも、
「ボトルネックの確認と解消(無限に出てきます)」
「成果物の内容確認(設計書やソースコード)」
「成果物の品質確認」
「成果物の簡易的な結合テストを時々やる」
「担当者の理解度チェックを随時行う」
「人間関係の円滑度チェック(情報の流れを中心に)」
「顔色、表情、感情面のチェックを随時に」
「何となく全体の雰囲気を感じる」
などはやるべきだと思う。

全部を完璧にやるわけではなく出来る範囲内で気を配れば良い。

人間は言葉ではいくらでも嘘をつくが、行動では嘘がつけない。
だから言葉を聞くより行動を見た方が良い。

秘密を探ったり裏を読んだりするのは本来好ましいものではない。
やはり現場が気軽に問題や課題を相談してくる関係や雰囲気を作るのが大事だろう。

ネガティブな課題の隠蔽にはくれぐれも気を付けて欲しい。
安全のために。


このブログを検索

Translate

人気の投稿

自己紹介

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

QooQ