全2411文字

炎上案件から何を学ぶのか

 炎上案件からはいろいろと学ぶことができますが、最も学べるのはマネジメント手法です。マネジメント手法を全て一般論だけで理解することは不可能です。なぜなら、人間が関わることなので、それぞれのプロジェクトの事情が大きく影響するからです。

 炎上したプロジェクトで、誰がどのような認識で作業を行い、誰がどういうところに不満を持っていて、なぜそういう状況に陥ったのか、といったことを時系列で整理するだけでも非常に勉強になります。そして、どうすればそれを回避できたのかをシミュレーションすることもできます。

 炎上案件の原因は高い確率でマネジメントにあります。直接の原因が何であっても、根本的な原因はマネジメントにあることが多いのです。その原因を表層的に捉えるのではなく、本質的に解析することが非常に重要です。

 例えば、あるエンジニアが重大なバグを作り出したとします。しかし、そのエンジニアを怒っても何も解決しません。むしろ、怒られたエンジニアはモチベーションが下がり、場合によっては次の日から出社しなくなるかもしれません。

 それよりも、なぜそのバグの発生を回避できなかったのかをそのエンジニアからきちんとヒアリングすることが重要です。「寝不足だった」「設計書がない」「最初から無理だと思っていた」など、さまざまな理由があるはずです。その根本原因こそが解決の糸口なのです。それを怠ってエンジニアを厳しく叱責しても、遅かれ早かれ再び同じことが発生するでしょう。

解析学のススメ

 炎上案件から学べるもう1つに、解析テクニックがあります。トラブルの原因が最初から表面化していることはまれです。状況から考えられる原因を逆算し、想像しながら情報収集して解析を行う必要があります。

 例えば、ネットワークの遅延が発生しているとします。この場合、ネットワークパケットをキャプチャリングし、そのプロトコルのどこで遅延が発生しているのかというところから原因を推測しなければなりません。これには非常に高度な知識が必要ですが、大変重要なことです。

 ソースコードを一生懸命眺めているプロジェクトをよく目にしますが、解析せずにソースコードを読んで原因を探るのは効率が悪過ぎます。このような解析は、ハッキングの手順とよく似ており、今後さまざまな場面で役に立ちます。こうした解析手法に長けているのが一流のエンジニアの条件といっても過言ではないでしょう。

 以上、今回は炎上案件から何を学ぶかについて書きました。次回は、実際に筆者が体験した炎上プロジェクトの事例を基に、どのような原因で、どう解決していったのかについて述べたいと思います。