エンジニアの役割
福島第一原発での事故は、私たちにいろいろなことを教えてくれた。畑違いとはいえ、エンジニアの一人として最初に感じたのは、「エンジニアたちはいったい何をしていたんだ？」「システムアーキテクトはいたのか？」という疑問である。
核エネルギーを発見したのは科学者たちである。そして、そのエネルギーは原子爆弾だけでなく、発電にも使えるかもしれないと考えたのも科学者たちである。科学者たちの仕事は、自然を観察し、法則を見つけ出し、そこから私たちの生活や経済活動に役に立つ可能性のあるものを見つけることである。その意味では、「原子力の平和利用」という発想はすばらしいものであった。
一方、原発を日本のエネルギー政策の中心に置いたのは政治家である。その政策に従い、日本各地に原発を作り、そこで作った電力を販売しようと決めたのは電力会社のビジネスマンたちである。彼らの仕事は、国なり会社なりの枠組みの中で、国を豊かにしたり、会社に利益をもたらすためには何をすべきかを考えることである。
しかし、科学者の「原子力のエネルギーを使って発電ができる」という発想と、「日本各地に原発を作って、そこで作った電力でビジネスをしよう」という発想の間には、大きなギャップがある。科学者と政治家とビジネスマンだけでは、核のエネルギーを電気に変えることはできない。
誰かが、その「夢のエネルギー」を「実際に営利事業として販売できる」システムにまで作り上げる必要がある。そのシステム設計を担うのがエンジニアであり、システムアーキテクトである。
システム設計の範囲
ちなみに、「科学者が発見したものを実際の社会に役に立つものにする」という意味での「システム設計」は、単に「原子炉の設計」をすることだけではない点に注目すべきだ。
経済性や安全性を度外視した原子炉ならば科学者にも作ることができる。原子炉を運営する人たち、原子炉やその周りの施設を作る人たち、原発で生まれた電力を販売してビジネスをする人たち、そして原発の安全性を監督・監視する人たちまですべてひっくるめて、経済的でかつ安全な原子力システムを設計するのがエンジニアの役割である。
ここで重要なのは、このシステムに関わるそういったさまざまな人々の、人間ならだれもが持つ怠惰さ、強欲さなどの「弱さ」をも考慮に入れたシステム設計をすべきだということだ。特に原発のように「万が一の事故」の被害が莫大なものの場合、そういったヒューマンファクターまでも考慮したうえでのシステム設計をしない限りは、本当に安全なシステムなど作れない。また、そういったものも考慮したうえでの設計に基づいてコスト計算をしない限りは、本当のコストは導き出せないし、それが本当に実用化すべきものかどうかを見極めることは難しい。
「人間はミスをするもの」という前提でシステムを設計する
つい先日も、私が関わっているDAFLOIDというiPad・iPhone向けのスポーツ情報アプリのアップデート時に事故が起こった。Appleへのアップデート版の提出当日の夜までテスト用のサーバへ接続してストレステストを繰り返していたのだが、アップデート版をアップルにリリースする際に、担当者がテストサーバ向けのコンフィグレーションファイルを使ってビルドをしたものを間違ってリリースしてしまったのだ。
最終的には、このアップデート版がAppleの審査もすり抜けてエンドユーザの手に渡ることになってしまい、サーバのリダイレクトでしのぐなどの対応に大わらわとなる事故となってしまった。
この手の「人的ミス」は、そのミスをした担当者、もしくはその担当者の上司の監督責任とされることが多いが、実際に問題視すべきは、そんなミスを許してしまったシステム設計そのものである。
このケースで言えば、テストサーバと商用サーバとの切り替えを、「コンフィグレーションファイルの手動での置き換え」という「人的ミス」の生じやすい方法で行っていたことに問題がある。「人間はミスをするもの」という前提のもとに、ビルドスクリプトの中にこのコンフィグレーションファイルの差し替えのロジックを用意しておき、ディストリビューション用のビルドを作る際には自動的に商用サーバ向けのコンフィグレーションファイルを使うように作っておけばよかっただけのことだ。
作りやすく設計することも大切
上の例はまだわかりやすいほうだが、私がMicrosoft でWindows 95 の設計において直面した問題は、もっと微妙であった。当時、Windows 95の開発において、私はデスクトップやエクスプローラーなどのユーザインタフェースの設計をしていた。本格的なマルチスレッドをサポートした最初のOS上のGUIの設計という前人未到の領域であり、マルチスレッドをどう活用するかという部分で手探りの部分もあった。
開発当初は、ユーザインタフェース部分のコードを書いているのは私を含めた2人のエンジニアであったが、次第に人数が増えてくるにつれ、システムが思わぬところでデッドロックに陥ることが多くなった。
解析してみると、いずれの場合も排他的な処理を実行している2つのスレッドがお互いを待ってしまうという典型的なデッドロックであった。マルチスレッドという新しい道具を手に入れたエンジニアたちが、慣れないが故のミスを多発していたのだ。
当初は私自身もこの問題を軽視しており、その場しのぎのバグフィックスとエンジニアたちの教育で十分に対応できると考えていた。しかし、デッドロックが多発するにつれ、個々のケースに対応しているだけでは安定したシステムは到底作れないことが明確になってきた。
最終的には、排他処理向けのヘルパーAPI を作り、マルチスレッドの活用を簡単にするだけでなく、間違った使い方をした際にはすぐに開発者にわかるようなしくみを導入した。それに加え、「スレッドはそれぞれのエンジニアが必要に応じて好き勝手に作るものではなく、基本的には（エクスプローラーの）ウィンドウ1つあたり1つのスレッドを作るだけにとどめる」というルールを導入することによりシステムを安定させることに成功した。ただ、当初の見積りの甘さのために、かなりの時間と労力を無駄にしてしまったことをよく覚えている。
システムとして見た原発
この経験をとおして日本の原子力発電というシステムを見てみると、いくつかの根本的な欠点が見えてくる。
- 本来、国民の安全を第一に考えるべき立場にある原子力安全・保安院が、原子力発電推進の立場にある経済産業省の下に置かれている
- 経済産業省でエネルギー政策を担当していた人たちにとって、電力業界およびそこに関連する企業と公益法人は格好の天下り先となっている
- 日本の「原子力の専門家」の大半が、コンサルタント料や電力会社からの寄付金などの形で原子力発電のもたらす経済効果の恩恵を受ける立場にあり、客観的な「評価」や「批判」をすることが難しい
- 原発に関わる人たちの役割が細分化されており、システム全体を客観的・俯瞰（ふかん）的に見て、原発の安全性・経済性を合理的に判断する立場の人がいない
- 最終的な判断をする政治家は、経済産業省・電力会社など原子力の専門家の意見をもとに安全性の判断をするしかないが、彼らのほとんどすべてが「原発推進派」なので、ここでの客観的な判断は不可能である
- 「 万が一の事故」のときのコストがあまりにも膨大なため、「事故の確率×コスト」でコスト計算ができない。そのため、「事故は何があっても起こさない」という非現実的な目標を設定したシステム作りになっている
- 減価償却費を含めた「コスト」から電気料金を決めることのできる電力会社にとって、先行投資型の原発は「経営リスクを負わずに簡単に帳簿上の資産を増やすことができる」という意味で不自然に魅力的なビジネスになっている
- 廃炉には膨大なコストがかかるため、減価償却が終わった古い原子炉を延命して使い続けるという「問題を先送りして、安全よりも短期的な利益を優先する」という行動を促した
原発事故に学ぶ
ここで学ぶべき教訓は、原発という「システム」を考える場合、単に「原子炉」や「冷却ポンプ」などの「設備」だけでは不十分で、原子力発電所を運営する人（電力会社）、原子力発電所の安全性を監視する立場の人（原子力安全・保安院）、原発を推進する立場の人（経済産業省）を含めた総合的な「システム設計」が必要であるということである。それも、そういった関係者の人間としての「弱さ」や「欲」を十分に考慮したうえで、「人的ミスの発生する余地」や「利益の相反」を徹底的に除去した設計が必要なのである。
そして、この教訓は原発のような複雑なシステムだけでなく、より簡単なiPhoneアプリだとか、Webサービスなどにも当てはまる。サービスを運営する人のちょっとしたミスでシステムダウンを招くようなしくみになってしまっていないか、サービスの運営に携わる人たちが（昇進やボーナスのために）がんばると、逆にユーザにとってのサービスの質が低下してしまうようなしくみ[1]になってしまっていないか、ユーザの数が急激に増えたときに対処する体制はできているか、アプリをビルドするしくみは可能な限り自動化されているか、API は間違った使い方をされたときにすぐに間違いに気がつくような仕掛けがされているか、などである。
