日本人はリスクを表に出すのが嫌い？

プロジェクトの会議に参加していると、ソフトウェアエンジニアはリスクがあるにもかかわらず上にリスクを言いたがらない傾向があるような気がする。日程が遅れるというリスクを言いたがらないのは心情的に分かるが、技術的なリスクやプロジェクトのリスクは抱え込んでいて後で報告するよりもできるだけ早いうちに上に報告してしまった方が得だと思っていたのだが、どうもそうでもないようだ。

後でリスクが現実のものとなってしまったら責任は自分自分が全部負うことになるが、早いうちにリスクの可能性を表明してしまえば上司にも責任を一端を負ってもらえる。この考え方が成り立つのは、責任と権限が明確な組織の場合だ。

でも、日本の組織では責任と権限は曖昧なことが多い。だから、問題はそんなに簡単ではない。リスクを早い段階で明らかにして誰も助け船を出してくれなかった場合、危惧していた問題が現実のものになってしまったら、失敗の実績プラスリスクを知っていたのに未然に回避できなかったという負の実績も背負うことになってしまう。日本の組織では評価も曖昧なので給料が下がることはあまりないが、印象が悪くなる。曖昧な社会において「あいつは役に立たない」というレッテルを貼られるのはイヤだという者がおおいだろう。

だから、リスクを知りながらリスクが具現化してしまうと、リスクを隠しておいたときよりも自分の評価が下がってしまう。リスクは言わないでおいて、何かの拍子にうまく解決できてしまえば自分に対するマイナスポイントを減らすことができる。

逆に，早期にリスクの可能性をポンポン会議で発言できる技術者は、裏返せばリスクを回避できる自信があるからだ。

早期にリスクを表に出し、そのリスクを解決することができれば、その技術者の実績として周りに認知してもらえる可能性が高いが、リスクを報告せずに解決してしまうと、誰もその実績に気がつかない。

そう考えると、技術力に自信のないエンジニアはリスクを隠す方向に動き、技術力に自信のあるエンジニアはリスクを表に出す方向に動くと言えないだろうか？

もちろん、このロジックの前提は、リスクを上司に報告しても責任を負担してもらえない、リスクを回避できる能力が上にありそうにないという組織の場合だ。

部品に調達や内部・外部との交渉など技術的な要因が伴わない手助けはよろこんで動いてくれるハードウェア出身の上司も、ことソフトウェアの技術的な問題や、ソフトウェアプロジェクトに特化したマネージメントの問題となると相談しても、「大変だね」という同情のことばをかけてくれるだけだ。

そうなると、ハードソフト混在のプロジェクトの場合、ソフトウェアプロジェクトの問題解決能力が低ければ低いほど、リスクが表に現れず製品開発の最後になって、先にも進めない後戻りもできないという状況に陥ってしまうことがある。

最後の手段としてあらかじめ計画していた機能の一部をが削られたりする。このような日本のソフトウェアプロジェクトに特有のシチュエーションはソフトウェア開発における悪循環を生みやすい。

プロダクトマネージャや組織上位層は、悪循環を回避するために自分自身がソフトウェアに関する問題の解決の手段を持っていなくても、ソフトウェアエンジニアから何とかリスクを聞き出す（引き出す）努力をすべきである。

そして、そのリスクが技術的な問題なら、その問題を解決できそうな技術者を組織の内部、外部から見つけ出してサジェスチョンしてもらえるような手配をすべきだ。組織内部に問題解決の知恵がないのなら、コンサルタントに相談するものいいだろう。

問題は、プロダクトマネージャや組織上位層が日頃ソフトウェアの問題解決に役立ちそうなコネクションを広げようという努力をしていない点にあると思う。

だから、ソフトウェア技術者から相談を受けても何も助け船を出してやることができないので、下には「相談しても無駄だ」と思われ、積極的にリスクを伝えておこうという気が起きないのだ。

悪循環から抜け出すには、まずはリスクを早め早めに表に出すという習慣をつける必要がありそうだ。