"形を作っただけでは機能しない。仕組みは作れるが、目的は共有されない" ソフトウェア開発の現場も同じ
縁あって福島第一原子力発電所の事故についての 政府事故調査報告書 を読んだ。
非常にボリュームがあるので流し読みしただけだが、最後の総括と提言には非常に考えさせられたのでメモ。
（１）あり得ることは起こる。あり得ないと思うことも起こる。
（２）見たくないものは見えない。見たいものが見える。
（３）可能な限りの想定と十分な準備をする。
（４）形を作っただけでは機能しない。仕組みは作れるが、目的は共有されない。
（５）全ては変わるのであり、変化に柔軟に対応する。
（６）危険の存在を認め、危険に正対して議論できる文化を作る。
（７）自分の目で見て自分の頭で考え、判断・行動することが重要であることを認識し、そのような能力を涵養することが重要である。
形を作っただけでは機能しない
特に考えさせられ・共感したのが "（４）形を作っただけでは機能しない。仕組みは作れるが、目的は共有されない。" だ。短いので全文を引用する。
（４）形を作っただけでは機能しない。仕組みは作れるが、目的は共有されない。
事業者も規制関係機関も地方自治体も、それぞれの組織が形式的には原発事故に対
応する仕組みを作っていた。しかし、いざ事故が起こるとその対応には不備が散見さ
れた。それは組織の構成員がその仕組みが何を目的とし、社会から何を預託されてい
るかについて十分自覚していなかったためと考えられる。各構成員が何をしなければ
いけないかを自分の問題として自覚している状態を作らなければ、仕組みを作っても
全体としては機能しない。目的が共有されないからである。緊急時のために構築され
た SPEEDI のシステムが避難に活用されなかったのは正にこの例である。
構成員全員が目的を共有するには、それぞれが社会から何を預託され、自分が全体
の中でどこにいるのか、また自分の働きが全体にどのような影響を与えるかを常に考
えているような状態を作らなければならない。その状態を更に維持するためには教育
と訓練が必要である。社会がそれぞれの構成員に預託している事柄をきっちり自覚で
きるような社会運営をしなければならない。
特にこのあたり。
- 事故に対応する仕組みを作っていたが、実際の事故時には不備が散見された
- 自分の問題として自覚していなければ、仕組みを作っても機能しない
- 自分が全体の中でどこにいるのか、自分の働きが全体にどう影響するのか
- その状態を維持するためには教育と訓練が必要
これはソフトウェア開発や保守の現場で常に議論され、考えさせられることとまったく同じだ。人気のビルドツールを使ったからといってビルドが上手くいくとは限らないし、最新の言語を使ったからといってシステムの質が向上するとも限らない。もっと大きな枠で見ても、ウォーターフォールで開発したからといってプロジェクトが失敗するとは限らないし、アジャイルで開発したからといってプロジェクトが成功するとも限らない。なぜなら、ツールやプラクティスといったものは箱モノではないからだ。だから、導入しただけでその価値を得られることなどそうそうない *1
まとめ
使えば使うほど・習熟すればするほど "お得になる"、それがツールやプラクティスだと思う。もちろん、ここでの習熟には使うべきではないところの見極めなども含まれるのはいうまでもない *2
むろん、原子力発電所で過酷事故が発生したときのような影響範囲の巨大さはそうそうあるものではないと思う。よって、前述の提言が自分の関わるシステムやプロジェクトにそのまま適用できるものではない。しかし、こういったことを常に意識し・目指す姿勢を持つ / 持たないとでは、出来あがるプロセスや組織、そしてシステムもまるで違うものになる。ソフトウェア開発に何年も携わってきたが、あながち外れてはいないんじゃないだろうか。
