ITプロジェクトで“状況を隠す行動”はなぜ起きるのか|組織的背景と可視化の対策

ITプロジェクトにおいて進捗管理や課題管理のプロセスが導入されていても、意図的に状況を隠されてしまうと、状況の可視化は難しくなります。プロジェクトには優秀な人たちがたくさんいます。そういった人たちが意思を持って状況を隠してしまうと、それを検知するのは大変困難です。
やっかいなのは、そういった悪い状況の隠ぺいを、悪気なく、善意でやっていることです。今回は、どうしてそういう状況が発生するのか、どうすれば解消するのかについてお話していきます。
可視化が意図的に阻まれるときの組織的背景
プロジェクトメンバが状況を意図的に隠すケースには、色々あります。今回は典型的な3つのケースを取り上げたいと思います。3つのケースに共通することとしては、隠している人達は、プロジェクトにとって致し方ないことだと考えていることです。
ケース❶ チームリーダ ➡ プロジェクトリーダ
まずは、チームリーダが正しい情報をプロジェクトリーダに伝えないケースです。プロジェクトリーダは、プロジェクト全体進捗会議をはじめ、色々な場面で、チームリーダ陣と良く会話をしています。そのため、プロジェクトリーダが実態を把握できないといったことは、本来考えにくいです。
しかし、よく会話をしていたとしても、プロジェクトリーダとして、正しい情報を把握できていないことがあります。その理由のひとつが、チームリーダが意図して情報を隠している場合です。
背景となる事情
- プロジェクトリーダが「怖い存在」になっている。進捗遅れがあると、叱責・責任追及される
- プロジェクトリーダが強権的で、各チームに発言権が無い。問題を言っても、押し返されるだけ
- スケジュールが非現実的で、そもそも「できない前提」の計画である
働く心理
- 怒られたくない・評価を下げたくない
- 自分たちの努力不足だと思われたくない
- 「言っても無駄」という諦め
- 集団心理(周りも言っていないから自分も言わない)
ケース❷ プロジェクトリーダ ➡ マネジメント
次は、プロジェクトリーダが、同じ社内のマネジメントに対して、状況を隠すケースです。本来は、大事な判断を行うために、同じ情報を持って、一枚岩になっていなければならないのですが、すれ違っていることが大変多いです。
ひとつの要因は、プロジェクトリーダが正しい報告をしないことです。会社によっては、普段コミュニケーションしない関係性でもあるため、プロジェクトリーダが情報を隠す場合には、マネジメントが正しい情報を得ることは大変困難になります。
背景となる事情
- プロジェクトリーダの評価指標が「納期遵守・予算遵守・トラブルなし」になっている
- マネジメントのITプロジェクトへの理解が浅く、詳細を説明しても理解して貰えない
- 問題報告が「なぜ防げなかったのか」という詰問・責任追及に直結する
働く心理
- 「今はまだ何とかなるかもしれない」正常性バイアス
- 悪い知らせを持っていくことへの恐怖「最悪、プロジェクトを止められてしまうかもしれない」
- 自分の管理能力を疑われたくない防衛心理
- 「報告したところで助けてもらえない」という学習済み無力感
ケース❸ ITパートナ ➡ ユーザ企業
ITパートナは、ユーザ企業と一枚岩でプロジェクトを進めることにコミットしていますが、ユーザ企業とは別の企業体です。そのため、自分の立場が守られるよう・有利になるように動くことがあります。
決してウソは言いませんが、言い方を工夫したり、特定の事実を言わなかったりします。
背景となる事情
- 問題を出すと「追加作業」「責任問題」「契約不履行」に直結
- 力関係の非対称性で、ユーザ企業の要求を否定しにくい
- 営業が取って来た無理筋案件で、現場は「最初から詰んでいる」と分かっている
働く心理
- 「今言うと関係が壊れる」「契約交渉が不利になる」恐怖
- 炎上を現場で何とかしようとする自己犠牲
- 「完成させることが正義」という職業倫理
- 顧客の期待を裏切りたくない心理
意図的な不可視化に共通する本質的な要因
多くの場合、隠ぺいは「悪意」ではありません。「正直に言った結果、状況が良くなる未来が想像できない」という認識が大きな要因です。この認識がある限り、人は沈黙を選びます。
- 問題報告が「善」になっていない
- 早期報告した人ほど損をする
- 隠した人ほど、短期的には評価される
- 組織が「問題」を扱う力を持っていない
- 問題=犯人探し
- 問題=責任転嫁の材料
- 人は合理的ではなく、感情で動く
- 恐怖・保身・希望的観測
- 社会的立場を守ろうとする本能
「正直に言っても良くならない」どころか「悪くなる」経験が一度でもあると、この心理は非常に強固になります。そして、その心理は説得では消えません。構造と体験の積み重ねでしか変わりません。
次に、現実的な対応策について、お話していきたいと思います。

どうすれば、「言えば良くなる」と意識を変えられるか
一朝一夕では実現できません。複数の打ち手を根気よく続けていく必要があります。
❶「言ったら助かった」という実体験を意図的につくる
これが最も重要です。人は、ロジックではなく、過去の体験から未来を予測しがちです。
- 小さな問題・初期兆候を拾う
- それを即座に是正・支援する
- その後、必ず言語化して返す
地味ですが、これを何度も繰り返して、「言う=損」から「言う=得」へ考えを書き換えて貰う必要があります。

言ってくれて、本当に助かった。おかげで、問題がより深刻になる前に解決できた。
ありがとう。
こういった言葉を、繰り返し意識的にかけていくことが大事です。そのためには、最初の「小さな問題・初期兆候を拾う」ことが重要です。つまり、より主体的に、現場を見るように心がけることも大変大事になってきます。
❷「正直に言った人が損をしない」ことを可視化する
人は他人の扱われ方をよく見ています。「言っても、大丈夫だ」と誰の目にも明らかにしていくことが必要です。
NGな対応
「ありがとう」と言いながら
- 評価が下がる
- 無理なリカバリを押し付ける
- 責任を集中させる
➡ これを1回やると、全員黙ってしまう
OKな対応
問題を出した人を
- 責めない
- 矢面に立たせない
- 攻撃から守る
「この問題は個人の責任ではなく構造の問題」 と明言することが効く
❸「解決」より先に「状況が良くなる兆し」を見せる
問題状況を解決するのは、それほど簡単ではありません。また、人が求めているのは、「完全解決」ではありません。
「言った結果、少しマシになった」
これだけで十分です。小さな改善・アクションを即打ち出せるかどうかが、信頼を作ることに直結します。
- スケジュールが調整されて、1週間の猶予ができた
- タフなユーザへの説明を上司自ら、代わりにやってくれた
- 無駄だと思っていた作業をやらなくてよくなった など
❹「不都合なこと」を先に出す
上司がミスを認めると、下の人も、自分の抱えている問題を言い出しやすくなります。ただ、部下の前でミスを認めるというのは、なかなかできない人が多いように見えます。
しかし、他の回でもお話したように、プロジェクトはある前提(仮説)に基づいて進められていますから、前提(仮説)が外れることなんてあって当然なのです。そういった考え方を持つということが、まずは大変重要だと考えます。[関連記事]

私が立てた見積は、甘かったかもしれない。現場のみんなが過負荷になっていないか心配だ。

あ、この人には言っても大丈夫かもしれない...
それでも問題を隠ぺいしている人は、合理的に黙っている
上記のような対策を行っても、黙り続けている人はいます。
- 過去に深く傷ついた
- 立場的にリスクが大きい
- 契約・評価構造が変わらない
人間の考え方は、なかなか変わりません。そういった場合、「全員が正直になる」は、目指さない方が健全です。もっというと、「情報を隠ぺいしている人がいるかもしれない」ことを考慮に入れて、行動することが肝要です。
- 定点観測を続けて、小さな問題・初期予兆を拾えるようにする
- 現場が過負荷にならないよう気を付けつつ、数字やログで正確な情報を把握できるようにする
- 1 on 1や現場ヒアリングで、より現場に近いところから情報を吸い上げる
人間の心理は、論理や説明ではなかなか変わりません。構造×体験×一貫性でしか変わらないことが多いです。しかも、変わっていくには、時間がかかります。さらに、それでも変わらない人いるのが現実です。
だからといって、マイクロマネジメントで細かく情報を取り出すと、プロジェクト全体が疲弊していきますし、健全ではありません。「正直に言っても、生き残れる」という確信が持てるよう、地道に行動を起こしていきながらも、冷静に、変わらない人への対策を行っていくことが重要です。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会





