システムをリリースしエンドユーザの利用が始まって以降、プロジェクト・メンバーや営業担当、お客様より、「本番障害です！」「トラブル発生！」「お客様からのクレームが・・」という言葉が飛び込んできた瞬間、びくっと全身に力が入り、身体がこわばります。「待ってました！」という気持ちもいくぶんありますが、大きな息を吸い込んでゆっくりと吐き出しながら、まずは頭と心と身体が冷静になるように努めます。
多種多様な経験を積むための１つの有力な方法は、障害・トラブル・バグといった不具合発生時のトラブル・シューティングにあると思っています。致命的な障害・トラブルは絶対に避けなければなりませんが、そうでなければ、障害・トラブル・バグへの対処をいかに上手くするか、そのコントロールにかかっています。そして、障害・トラブルの対処を通して、個人レベル・組織レベル双方での絶好の改善チャンス・・個人レベルでは、能力発揮・能力育成のチャンス、組織レベルでは、プロセス改善のチャンスと捉えることが大切です。
システム構築プロジェクトにおいて、障害・バグが発生した場合、「障害管理表（障害記録票）」を起票しますが、その中には、「障害内容・現象」「直接原因」「暫定対策」「根本原因」「類似調査」「恒久対策」「再発防止策」等の記述欄が設けられています（付帯情報として、「原因分類」「影響度」等もあります）。少し簡略化した様式だと、「原因」と「対策」が各々１つずつしかないケースもあります。
ところで、「障害内容・現象」「直接原因」「暫定対策」まではどのプロジェクトでも記述されると思いますが、「根本原因」以降の対応をどこまで真面目に取り組むか・・ここに、個人レベル・組織レベルでの改善がかかっています。
個人レベルでの改善チャンスについては、柴田芳樹氏の著書「プログラマー現役続行」の中で、デバッグはエンジニアの総合力であると示されています。
柴田氏曰く、「デバッグには、論理的に推進する力だけでなく、その推論を支える膨大な知識が必要です。初心者や見習いレベルの場合には、その両方が欠けています。論理的思考は日々の指導で、知識は継続した学習で、それぞれ身につけていきます」と。
具体的には、まず、障害・バグの現状・・どのような現象が発生しているのか、その発生頻度はどの程度なのかを把握します。
次に、その原因を特定するための仮説を立てます。この仮説を立てるために、設計書やソースコードを調べたり、再現させたりという活動も含まれます。設計書やソースコード上で、原因と思われる箇所が見つかった場合には、それが原因でバグが発生していることを論理的に必ず説明できるようになること。原因と推定される箇所が複数発見された場合、そのどれが本当の原因かをじっくりと考え論理的に説明できる必要があります。
自分で把握・整理した原因と対応方法を、第三者に説明することによって、論理的な矛盾点を指摘されたり、もっと良い方法の指摘を受けること。相手に理解してもらえない場合、相手の理解レベルを考慮して、説明の抽象度を上げたり、別の観点から説明する工夫が必要になります。
この「仮説・検証」と「説明」の努力を通して、論理的思考力をベースとする能力が高まります。
次に、組織レベルでの改善チャンスについてです。
Ｅ．Ｗ．ダイクストラ氏が「プログラムテスティングは、バグが存在することを示すためには使えるが、バグが存在しないことを示すためには使えない」というように、システム開発、プログラムにバグ・障害は避けられないとも思われます。しかし、類似した障害・バグが複数発生し、プロジェクトの進行に伴っても収束しない、同じように散見されるという場合、その直接原因がミス・うっかり・・であった場合でも、個人レベルではなく組織レベルの問題と捉えて対応するべきです。根本原因は、要員・体制面であったり、プロセス面の不備であるケースが大半であり、そこに手を入れた対策を採らない限り、再発防止につながりません。
事故や災害について調査した結果確立した法則として、「ハインリッヒの法則」があります。この法則では、１件の重大災害の裏には、２９件のかすり傷程度の軽微な災害があり、さらにその後ろには、ヒヤリとしたりハッとして冷や汗が流れるような事例が３００件潜んでいます。３２９件の事象を軽視・黙認した結果が、１件の重大事故となります。３２９件のヒヤリハットを見逃し続けた責任もさることながら、問題から学べなかったことこそ問題なのだと思います。
日常のヒヤリハットを意識しつつ、組織的な改善のためのベースラインとして「プロセス標準」を持ち、再発防止策を取り込む漸進的な「プロセス改善」のＰＤＣＡを回るようにすることで「学習する組織」になれると思います。
「学習する組織」になるような組織風土をつくるために。
失敗学の畑村洋太郎氏によると、失敗を隠した結果、判明した場合、「ツケの大きさはだいたい、予兆や事実を無視したり、隠したりして「得をしたつもりになっている」金額の３００倍くらいになる」といわれます。
また、トラブルから学ぶことのできる組織とできない組織について、スコラ・コンサルトの柴田昌治氏は、こう述べられています。
「問題はあること自体が問題ではなく、解決されていっていないことが問題」である。失敗は「あってはならない」という精神論で、問題発生の都度、犯人探しが始まる組織では、現場は問題を隠し、問題解決のＰＤＣＡは回らない。人というものにはどんなに努力しても「失敗」はつきものという現実論に立った上で、「めざすものを共有する」「厳しく向き合う（協力し合う）」「当事者として自分の役割を認識する」というこの３つの進化に必要な価値観を共有することで、「学習する組織」にできるといいます。
プロマネの役割の大きな部分は、プロジェクトの推進とともに、プロジェクトの推進母体である自分たちのプロジェクトチームを「学習する組織」となるようにすることです。プロジェクト・メンバーとともに、このプロセスに取り組むことがプロマネの醍醐味であると思っています。