失敗事例からノウハウを学ぶ
失敗知識データベースというサイトがある。モノ作りで発生した事故や問題の事例を集め、その分析を行い教訓として生かしましょうというのが主旨だ。例えば、2002年に起きた「みずほフィナンシャルグループ大規模システム障害」といった事例も載っており、問題発生時の状況や原因分析が簡潔にまとめられているので参考にある。今でこそ、こんな問題が有ったねぇと読み返せるけど、当時の関係者はかなり大変だっただろうと思う。他人の不幸は蜜の味なんて言ってはいけない。明日は我が身に起こりえることなのだから。
このサイトにヒントを得て、バグ事例をグループ内に集めて示したことがある。例えば、nullアクセスが起こりソフトが異常終了したという事例を載せ、問題が発生した状況や対策案などを並べてみた。問題を引き起こした担当者は「nullチェックが漏れていました」と反省の弁を述べていたが、技術面から言えばnullチェックを怠らないという防御的プログラミングの姿勢が足りないし、プロセス面で言えばそのようなコードを見逃してしまったチェック体制に問題があるようにも思う。もちろん、同種の問題を今後如何に防ぐか？という前向きな方策も必要だから、対応案を幾つか載せてみた。
- 常にnullチェックを行うことをコーディング規約にする。でも、人間なら忘れることもある（今回の問題）ので、ツール等で自動チェックさせる。
- 変数には常に値を設定しておくものとして、決してnullにはならないようにする。これなら煩わしいチェックは一切不要になる。
- 「nullで有っても良い」のか「決してnullでは無いべき」なのか変数毎にまちまちなのが問題の一つなので、assertで変数の使い方を意思表明する。これなら早期に問題を顕在化できる。（特に大人数で開発を行う場合、変数を作る側と利用する側が異なることが珍しくないので有効）
- デザインパターンで言うところの「nullオブジェクト」を使って、nullチェックを省く。
...等の案を出して、あれこれと検討してみた。もちろん、正解は一つではないし、対象によってベストな案も異なるので、一般的な意味で「この方法にすべき」と断言することは出来ない。結局のところ、各プロジェクト（対象）に応じて最も適切な方法を選べばよいし、一旦選んだ方法を徹底して守るべきという無難な結論に落ち着いた。
それは良かったのだけど、気がつけば議論をしているのはごく一部の開発者だけであった。経験の浅い開発者は、そもそも防御的プログラミングという考え方を知らないし、nullオブジェクトが何なのか知らない人もいた。当初の狙いとして、対策案の比較検討というレベルの話を期待していたのだけど、知識が足りずにそこまでの議論が出来ないわけだ。
なるほど、一つの問題に対する各自の対応はこんなに異なるものなのかと驚きつつ、既に知っている技術を比較して適材適所の議論を出来るのは、ある一定の知識と実戦経験を持ち、しかも問題に積極的に関与しようという志の高い開発者だけだと改めて気がついた。誰もがソフトウェア工学のあらゆる知識を持ち合わせている訳ではないから、同じレベルの議論が出来ないのは仕方ないとは言え、その差は思った以上に激しい。知識習得の場として、これはこれでかなり有効なのかも知れない。
結果的に、失敗事例を元に議論して効果があるのは、自らの経験に基づき活発な意見交換が出来るベテラン開発者と、新しい知識を学べる若い開発者だったような気がする。その中間の開発者は、何を議論しているのかよく分からないという人もいたし、他人の問題だから自分は関わらないという冷ややかな姿勢を取る人も少なくなかった。開発の現場で中心になって作業をする人こそ必要な知識だと思うのだが、意欲の乏しい人はそんな情報へ自分から近づこうとしないので少々残念だ。
関連
