IT技術者から見た原子力の世界 (2)

前回からの続き。

ミッションクリティカルと八百万の神

テキサス州の一件が終わってから私はまた国内プラントの仕事に戻された。様々な仕事を行ったが、すぐに思い出せるものを書いていく。

私のチームは「炉心性能計算」のチーム、ということになっていた。ただ、炉心性能計算という機能だけで常時仕事があるわけでもなかったので、関連する別機能を担当することや、別のチームの仕事を手伝うこともよくあった。そんな頃、TIPの制御プログラムを書いた。TIPとはTraversing Incore Probeの略。元をたどるとGEの技術らしい。こちらの資料に概要がかいてある。


image from BGE WR_4 Technology - 5.6 Traversing Incore Probe System (1209).

簡単に説明すると、これは原子炉内を移動する中性子線センサープローブだ。その名の通りである。中性子線の計測は計数管(ハードウェアの詳細は知らないが、世間一般で知られるいわゆるガイガーカウンター、ガイガー=ミュラー計数管とほとんど変わらないのではないかと思う)を使っているので、炉内にセンサーを設置すると放射線に晒され続けるためにすぐに劣化してしまう。だから、炉内にセンサーが通過するパイプを予め設置しておき、その中に必要なときだけセンサーを挿入して炉内を上下に移動させ、中性子密度分布を計測するという使い方をする。こういうシステムは複数あるが、それらをまとめて核計装と呼んでいた。これら、原子力で用いられる単語がいちいちかっこいいと思うのは私だけだろうか。

計測した中性子線密度分布は炉心性能計算で使われる。炉心性能計算は過酷な環境であるために監視が難しい炉内の状態をシミュレーションによって求める機能であるが、あくまでもシミュレーションであるので実際の状態とは乖離が発生する。そこで、時々実際の中性子線密度分布を使用して内部状態を補正するというわけだ。中性子密度分布はつまり、核燃料の燃焼(核分裂反応)の激しさを表している。

…ということを私はひたすらググることによって当時も勉強していた。会社内にそれらを詳しく知っている人は居るには居るが皆忙しそうにしているし新人のために何時間も講義を開いてくれるわけでもなかった。だから、ググった情報をもとに勉強して要所要所で先輩に確認して答え合わせをする、ということを良くしていた。

ネットで原子力の情報など出てくるのか?あるいは、ネットの情報は正確なのか?と思われるかもしれないが、原子力に関しては情報公開が非常に進んでおり、ネットで正確な情報がたくさん得られる。上掲のGE社の資料などもその一つだ。日本語だとATOMICAが有名だ。

ちなみに、本記事を書くときも曖昧な記憶は適宜調べつつ書いている。これはなるべく正確な情報を提供したいというのももちろんあるが、すでにインターネット上に公開している情報であればすでに公知の情報と言えるので私が同様の情報を語っても問題ないというコンプライアンス上の問題もクリアできるという事情もある。

さて、そんなTIPの制御プログラムを書いていたわけだが、そこまで複雑な制御を行うわけじゃない。決められた速度で決められた位置までプローブを挿入して引き抜く、というコードを書くだけだ。プローブを挿入するとか引き抜くとかいうのはAPIのようなものが提供されており、決められたフォーマットで決められたデータを書き込めばそれでよい。動作環境はLinuxとかUnixという、世間一般でもごく当たり前のように使われているものである。ソフトウェアのおおまかなアーキテクチャも「古臭いな」とは感じるものの、そのOSで用いられる標準的な手段が使われていた。(古臭くてこなれたソフトウェアを信頼性が上がったとみなして好むのは原子力の常である)

我々が担当するところは「非安全系」と呼ばれるシステムだった。原子力ではシステムを構成する機能を「系統」と呼ばれるグループに分けていて、その中でも特に原子炉を運転する上で安全性に直接関わる重要なところを「安全系」、そうでないところを「非安全系」と呼んでいた。私のようなソフトウェアエンジニアが担当するのは常に「非安全系」であった。なぜならば、原子炉の運用においてLinux/Unixシステムは相対的に信頼性が低いとされているからだ(と、いうのは設計から私が読み取った肌感であって、そう明記されていた何かを見たわけではない)。

原子力レベルの安全性とは、たとえ電気が無くても戦闘機が建屋に突っ込んできても、というレベルを想定しているからたとえエンタープライズサーバーレベルのハードウェアが搭載されていたサーバがホットスタンバイ二重化された上で保守チームが24/365待機していたとしても安全系は任せられない、ということらしい。

ただ、非安全系とはいえ炉心性能計算などは「ダウンしたら二日以内に原子炉を停止しなければならない」とされているらしく(確か原子力基本法に根拠があったと記憶している)、これも世間一般で言うミッションクリティカルと言えるシステムであることは間違いなかった。噂話程度に聞いた話によると、原子炉は起動と停止に億単位の金がかかるらしい。ちなみに1日動かせば2000万円の利益、という話も聞いたことがある。噂話で根拠は殆どないと思うが。

私は非常に責任を感じていて絶対にバグを出すまいと作業した。これまでの作業は既存のコードの一部分を修正するというものだったが、この時に初めて自分で一からプログラムを書いたと記憶している(仕事上では)。入社当時から私が思っていたのは、ソフトウェアのテストはやはりソフトウェアによって担保されるべきであるということであったしそれが当時の世の中のトレンドだったとも思う。ちょうどユニットテストツール、ライブラリの使い方が日本語圏でも広まっていた時期だったと記憶している。

そういうわけで私はユニットテストを行う自作のツールを書いた(OSSなツールは使うと怒られるので)。このテスト結果は社内規則では単体テスト報告書には添付できない。この頃は私もある程度は仕事に対して自信が付いていたので「単体テストツールを開発しましょう」と周囲によく主張していた。C言語のユニットテストツールは当時もあったと思うが、そこは「OSSは使用できない」の前提があるのでユニットテストが必要ならばツールは自作する他ない。だから私はそう主張した。

周囲の反応は「そしたらそのツールが正しいことを証明しなきゃいけないじゃん。自作のツールでテストした結果なんて認められるわけがない」みたいなものが多かった。世の中一般の単体テストツール群がそれ自身のテストを行っていないわけではない。だから、当然ツールを開発したらそれは十分なテストを行う。このテストは他のテストと方式は同じわけだから、他のソフトウェアに比べてテスト品質が悪いということはないはずだ。

人間が全て手動で確認作業を行った場合のエラーレートがプログラムに依る確認作業のエラーレートよりも低いという暗黙の前提もおかしいと思う。

何よりも、変わり続けるソフトウェアを保守していくためにはテスト項目を増やし続けるしかなく、その増えたテストは毎回全てやらなければならない。ソフトウェアを変更したことによる影響範囲を推定することは非常にこんなんだからなだ。

だから、誰がどう文句を言おうとソフトウェア品質を担保するならば、テスト項目を山ほど増やすしか無い。そしてそれを現実的なコストで行おうと思ったら、自動化するしか無い。その説明を理解してくれる人はほとんど居なかった。ほとんど居ない、ということは、ゼロではなかった、ということだ。賛同してくれる数人の人たちも、硬直した業務フローを変えるのはほぼ不可能だろうと諦めていた。

何故ならば業務フローの中に所属する会社の隔たりがあるからだ。当時のメーカー各社の目論見としては開発部隊の主体を子会社化して、子会社に発注するコストを抑えることで利幅を確保できるという目的だったのではないか、と私は推察している。もしそうならば、その試みはあらゆる会社、あらゆる組織で数多の失敗を生んでいることは皆さんにも予想が付くだろうと思う。

異なる会社に所属する人たちが同一のフロアで業務を行うと統一的な業務改善を行うための意思決定が不可能になる。自分のテリトリー部分だけを局所最適化するしか方法がない。大胆な施策は取りにくくなる。

業務も発注してそれを受け取ることが中心となり、技術の流出も始まる。原子力は古い資産がたくさん動いている分野なので過去に活躍した人たちの知識が活用できるから、まだマシなほうだったのだと思う。

さて、話をTIP制御プログラムのテストに戻そう。結局私は簡単なユニットテストフレームワークを使ってそれを試験した。そのプログラムがやっていることと同じことをデバッガで再現してそのスクリーンショットで撮影してExcelに添付するという非常に非効率的な作業をも行った。

その甲斐あって私が担当したプログラムではバグが出なかった…と思いきや、結合試験でバグを出してしまった。炉心は円筒形なので上から見ると円になり、その形に沿って四角い燃料集合体が収まっている。その間に制御棒が入る。これらの燃料と制御棒は座標として表示されるのだが、GE式だの燃料屋さんの座標系だの複数の座標系がバラバラに使われていた。原点が左上だったり左下だったり。

言い訳がましいかも知れないが私は当時、そもそも別の座標系があるなど知らなかった。だから基本設計書だの詳細設計書だのを書いてレビュー会を行い、その後の承認ルートもあり、それらで誰一人指摘してくれなかったというのは正直なところ納得はいかなかった。当時よくあったのは誤字脱字の指摘とか、ページ番号の間違いだとか、そんなものが多かった。いちいち紙で出力しなければならないので、編集を重ねているとページ番号がよくずれるのである。

Nさん

こういった話をいつか書くときはNさんの話は必ずしておかなければならない、と思っていた。そのくらいNさんは印象深い人だった。

入社当時、Nさんは私達のチームのメンバーではなくちょうどTIPの仕事が終わったか終わらないか、あたりで加入したように思える。確か火力の部署から来たひとで、「昔原子力の仕事をしていた」という話を聞いた記憶がある。

この頃は「3プラント同時リプレース」などという言葉が盛んに使われており、特に忙しい時期だった。原子力発電所は一回動かし始めたら運転中は保守作業が出来ないので、全ては運転を停止している定期検査期間中に行わなくてはならない。だから火力からも人を集めてきていた時期だった。原子力と火力はこんな感じで忙しさに合わせて多少の人事移動を行うことがあり、原子力も火力も両方をやったことがある人というのは少なからず居た。大雑把に言えば原子力と火力は熱源が違うだけなので、その熱源を取り囲む所は似通っている。というと省略し過ぎかも知れないが。

Nさんの他にもこの時期はいろいろな人が入ってきて一番活気があった時期だったように思う。特にこの頃はグループ会社で人材派遣を行う会社があって、そこから派遣された人が多かった。この会社の名前がどうしても思い出せないのだが、元々はグループ企業全体に事務用品を販売したり、職場の自販機とかそういう類を提供していたり、あるいは賃貸住宅や不動産物件を紹介したりしていた会社だったように思う(うろ覚え)。この会社から派遣される人は元々は原子力のことは何も知らない、理系ですらなく事務作業などを中心にやってきた人たちだった。そんな人たちでも必要になるほどに手は足りていなかった。

その会社から派遣されてくる人は何故か皆女性だった。年齢は20代から40代、50代まで様々だ。その女性たちに職場のおじさんたちは非常に優しかった。元々極端に女性の割合が少ない職場だったから嬉しかったのかも知れない。私自身、この時期(2010年の終わりから2011年のはじめ頃)が一番活気があって面白かったと記憶している。一人、30歳くらいの女性が居てその人はセルシオに乗って飲み会ではカラオケをずっと歌っていたような記憶がある。件のあだ名をつけるのが得意な上司はその人のことを「〇〇さんはヤンキーだからね」と嬉しそうに言っていた。

Nさんからだいぶ話がそれてしまった。一方のNさんはというと、おそらく40歳前後だったと思うが、ムキムキの肉体で寡黙でほとんど喋らない人だった。決して愛想が悪いわけではなく、ときに冗談も言えば笑ったりもする、けれども基本は寡黙で余計なことは喋らない、という感じだった。

私はNさんと一緒にRWM, Rod worth minimizerというシステムのテストを担当することとなった。我々は略してロッドワース、と言っていた。これは原子炉の起動時に安全に制御棒を引き抜いていく操作をサポートするためのシステムだ。原子炉が停止しているときは全ての制御棒は全挿入されている。この状態をそのまま「全制御棒全挿入」と言っていた。「全挿入」だと一本の制御棒が全部入っています、という状態と区別が付かないので「全制御棒全挿入」はこれ以上略せない言葉だった。

その状態から原子炉を起動するときは制御棒を引き抜いていくわけだが、その制御棒が引き抜かれることでどの程度核反応が進むか、言い換えるとその制御棒は引き抜き操作でどの程度反応を進ませる価値があるか、という無次元量を持っている。これは反応度(核反応が進むことは放射線量を測定することで知ることができる)の単位時間あたりの増加率という無次元量であって、その単位を昔のアメリカでは「ドル」と読んでいた(今もそう呼んでいるかもしれない)。それがGEなどによって日本に輸入されたわけだ。

あまりにも制御棒価値が高い制御棒を一気に引き抜いてしまうと急激な温度変化が発生し、燃料棒が損傷してしまう。核燃料はジルコニウム合金で包まれており高い耐熱温度があるが、急激な温度変化で破損してしまうと核燃料が漏れてしまう。だから、制御棒価値が小さいものを少しずつ引き抜いていかなくてはならず、「Rod Worth Minizer」というはつまりそういうことである。制御棒の価値を最小にするシステム、というわけだ。

これが難しかった。

元々炉心性能計算や炉心監視とかをやってきていたが、RWMの知識はここまででゼロだった上、これがどのようなものなのか分かっている人は全然居なかった。というのは後になって私が分かったことだった。

Nさんと一緒に仕事をし始めたとき、Nさんは既にRWMの各種操作やその意味をほとんど完全に理解していた。だから、以前取り扱った経験があるのだと私は思っていたが、なんと触ったことが無いという。ではなぜ全て理解していたのかと言うと、以前に同種のプラントで試験した試験結果、およそ400ページほどを読み込んだ上で工場にあった試験中の実機を用いて触って確かめたのだという。その手順はひたすら難解で、ほとんどは試験仕様書や試験報告書などといった書類には何も記載されていない。

「たとえば、な」

Nさんは工場で実機を前に私に説明してくれた。

「この試験手順にはこう書いている。『制御棒X-Yを引き抜く。確認事項:引き抜いた制御棒がラッチすること』と。ラッチって何だ?分かるかお前」

「わからないです」

「それはだな、引き抜き操作をするとこの画面右下のインジケーターが緑色になるだろう。これで『ラッチした』ということになるんだそうです。そんな事は何処にも書いてねぇだろ?でもこれを読み解いていかないと仕事が終わらないんだ。俺達の仕事ってのは、こういうふうに先人がやってきたことをリバースエンジニアリングすることなんだ」

Nさんはそう言っていた。私は大層感心した。

皆さんは上記のようなことを目にした時点で言いたいことが100も200も出てくるのではないかと思う。その一つ一つが正論だと思う。まず、後任の人が分かるように操作手順は残しておくべきだし引き継ぎもなされるべきだ。試験仕様書はそもそも誰がどのように見ても明らかに判定基準が分かるようにしておかなければならない。そもそも、原発というミッションクリティカルなシステムで、しかも失敗したら事故のリスクがある危ないプラントでリバースエンジニアリングを行うことで設計・開発しているとは何事だ、などなど。その全ての指摘は正しいと思う。

しかしながら、Nさんはそれを全部分かった上で、いま現状できることの最善を愚直に行っているのであった。100個も200個も改善点はあるが、いまここに居る人が試験をして原発のシステムをちゃんと動くようにしなければならないのである。それは皆聞いた瞬間に嫌になるような仕事であったが、Nさんはそれを完璧にこなしていた。

ちなみに私も常々、原子力の仕事はリバースエンジニアリングだと感じていた。既に何十年も前に建築された原子炉の全体を知っている人はおらず、当時の設計書から意図を汲み取り、新しいプラントでどうあるべきかを考える作業であった。しかしその泥臭い仕事をここまで完璧になるまでやりきった人は見たことがなかったし、この後の人生でも見ることは無いだろうと思う。

この時期は既に述べたように大変に忙しくて試験スケジュールが確保できていなかった。結合試験段階にあるフェーズでは工場の中に設置された「実機」、その中身はLinuxやUnixが入ったサーバマシンだったり、あるいはPLC(Programmable Logic Computer)だったりするわけだが、現地に納入する機械そのものを工場の中で接続し、模擬的なプラント情報を読み込ませて試験するというものだった。だから、あるシステムをテストしているときは他のシステムは基本的にテストが行えない。そうすると全てのシステムの試験スケジュールは基本的に直列で並ばせるしか無い。RWMの試験はもはや日中に行うことが出来ず、私とNさんは夜勤シフトとなった。

なぜこんな事になっているのだろうと思う。設計段階からテスト方針を定めておくべきだったのは明らかだ。具体的にはそれぞれのシステムは他のシステムをエミュレーションするシステムと接続して並行して試験を行い、最終的に全て接続して行う試験を極力減らすべきだった。エミュレーションでも構わない所はどんどんそうすべきだった。

これに関してはいろいろな人が問題だ、どうにかしないといけない、と話をしていた。その根本的な解決策として我々が働いている建屋の一階に何千万円だかを投じて設置したサーバーマシンとその上で動く仮想マシン群がそうだったらしい。これが出来たのはこの忙しい時期が終わってからだったと思う。それも、我々子会社の従業員は「そういう巨大なコンピュータが設置されていて、仮想マシンによってプラントシステムを模擬するので結合試験が楽になるらしい」という話を聞いただけでそれを使わせてもらえたことは無かったし、実際に使った評判も聞かなかった。結局、物理的なシステムを仮想環境に持っていくノウハウが無かったのかも知れない。

隣にある部署(本社)の人が苦労して実マシンのハードディスクイメージをVMWareか何かのイメージに変換して仮想マシンとして動かそうと四苦八苦していた。P2Vというやつだ。経験上、こういうものはすんなり動かなかった場合はもう一から環境を作り上げたほうが早かったりする。が、そんな手間暇はかけられなかったのだろう。その人は本社の計算機システムを取り扱える精鋭の一人であった。LinuxやUnixの知識を持っている。おそらく、そのあたりのIT企業ではゴロゴロ居る人だとは思うが、それと原子力計算機システムの2つに精通している人であるから、極端にできる人は限られていた。だから、そういった人たちには常に仕事が集中していた。それを見て、私は大企業というのは上位数%の精鋭が残りの95%くらいの社員を食わしている組織なのだな、などと正直な所は思った。まあ、数値は誇張しているが。

ともかく、原発というのはこのように硬直化して保守的な開発体制によって作られた重厚なソフトウェアの信頼性をNさんのような人たちが血のにじむような努力を重ねて品質を上げていく、ひたすら精鋭のマンパワーで絡まった紐を解きほぐしてまっすぐにしていく、それによって確かに品質が担保されている。そんな印象を私は持つ。

また話がそれてしまったが、Nさんとの夜勤の間、私はどうしても眠くて眠ってしまった。その時もNさんは「いいよ、寝てていいから。俺がやっておく」と担々と試験を進めていた。そういう人だった。

Nさんの人柄についても触れておく。Nさんは既に述べたようにムキムキの肉体をしていた。キックボクシングをしているらしく、「K-1のステージに立つのが夢だ」と飲み会の席で言っていた。仕事でも怒ると怖い人で、私も何度か怒られた。上司はそれを冗談交じりに「N道場」と呼んでいた。新人は全てN道場に送り込まれて鍛えられるのだと。私はそれでも怒られない方だったらしく、気の毒になるほど怒られている人も私は実際に見たことがある。ただ、Nさんの名誉のために言っておくが今で言うパワハラのように人前で大声で怒鳴りつけるのではなく、静かな口調でダメ出しを行い圧をかけてゆくというスタイルだ。

きっちりリバース・エンジニアリングするNさんであるから、そのダメ出しもすべて的を捉えたものであるから怒られている方は反論する余地が全く無かった。Nさんが言うことは常に正しく、その正しさは誰でも理解できる言葉で伝えられた。

ああいった人は貴重な人材だと思うが、今ではパワハラとみなされるのかも知れない。ダメな所はダメだと伝える。言葉に真剣味をもたせる。それはコミュニケーションとして必要なことだと思うが、昨今のパワハラというのはどうも「相手が嫌になるのは全てアウト」という線引きがなされているように思えてしまう。嫌になることが絶対あってはいけないのだとしたら、もはやエアコンの効いた部屋で延々と犬猫や草原の動画を見続ける人生を送るしか無い。

Nさんはまた、バイクが趣味だとも言っていた。私もバイクが趣味だったので飲み会ではそんな話をした記憶が残っている。普段は寡黙で雑談をほとんどしない人であったが。

ちょうどRWMの夜勤が終わった直後だったと思うが、私の妻が腎盂炎になって入院したことがあった。結婚してすぐのことだったはずだ。このとき、あだ名をつけるのがうまい上司のYさんは忙しい中で「今すぐ帰って病院に行け」と即答してくれた。それがとても有り難かったのを記憶している。ただ、このときは色々としんどい時期であった。慣れない夜勤をしていたのも体調が悪い一員だった。

RWMはそんな感じで、私はほとんどNさんに頼り切りになってしまったことを反省している。Nさんが完璧すぎたので、振り返ってみて私はなにか出来たのだろうか、と。すごく頼りになる人であった。もし可能ならばまた一緒に仕事をして恩返しをしたいと思うが、もはやそういうチャンスは宝くじが当たるような確率でしか巡ってこないだろう。

RWMの仕事が終わった後は私はN道場を離れて別の仕事をしていた。

チームは一緒だったので、別の仕事をしていてもNさんの席は私の真正面であった。

そして次にNさんとタッグを組んだのは件の派遣社員の女性の一人であった。おそらくその人は50歳前後だったと思う。私は一緒に仕事をしたことが無かったのでどういう人だったかまでは記憶にない。

Nさんはこの人のことをべた褒めしていた。本当にすごい、優秀だと。原子炉の知識は何もないはずなのにまさに1を教えたら10を返してくる人だと。このときはNさんが笑っているのを見かけることも多かったように思う。二人の席は隣で私は正面であったが、二人で談笑しているのもよく見かけた。

仕事は常々忙しかったが、チームでの飲み会も増え、一番充実していたのもこの頃だった。私はチームのメンバー一人ひとりを尊敬していたし、1年ちょっとが過ぎ、私もようやく新人から同僚の一人として認められつつあった時期だったんじゃないかな、と自己評価している。

これが、2010年の終わり頃だった。次回は震災前後の状況を書きます。全部で4回構成くらいになるかな。