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

Twitterでそういう話を書いたら結構反応を貰ったので記事として書いてみる。
まあ、こうやってブログ記事で書くとあんまり読んでもらえないんだけどね…。

おことわり

私の原子力関連事業でのキャリアというのはそうそう長いものではありません。なので、これがイコール原子力の世界であるというわけではないということは、強く強調しておきます。あくまでも私の経験の中で、私の視点によって捉えられた世界で、しかもそれの一部分だけを書いているに過ぎません。

あと、基本的に読み返しておらず書きっぱなしなのでいつにも増して誤字脱字の類がたくさんあるかと思いますが多めに見てやってください。

余談

いきなり余談なんですが、原子力の仕事をしている会社を辞めた時に今書いているような話をまとめて本にしたいと思っていました。私の原子力関係のキャリアは2009年に始まり、2011年の東日本大震災を経て確か2014年ごろまで続きました。5年程度という非常に短いものでしたが、その3年間の経験が強烈に自分の中に刻み込まれています。2009年はまだ「原子力ルネッサンス」という言葉が使われていて、社としてもアメリカに原発を輸出する計画があり、英語で仕様書を書いて議論していたりしてました。米GE社に作ってもらった原発を改良したものを米国で建設するのですから、日本の商用軽水炉の歴史をなぞってもあの時が一番盛り上がっていた時期ではないかと思っています。

そんな時期に東日本大震災があって、技術者の多くは散り散りになりました。新卒で入って仕事を覚え、将来はアメリカで仕事をするぞという話から突然こうでしたから落差としてはとても大きくて本にしたら面白いんじゃないかなと思ってました。まあ、それは結局やらなかったわけですが今回の記事はそれの短縮版みたいなつもりで書いてみます。

会社に入るまで

私は子供の頃からエネルギーに興味がありました。ラジコンやミニ四駆、ゲームボーイなんかの電池がすぐに無くなってしまうのが惜しくて、無限のエネルギーの生じさせる機械を作ればすべて解決するのでは?などと思っていました。20歳のときの同窓会で小学生の時に埋めたタイムカプセルを掘り起こして「将来の自分へ」という作文を読みましたが、内容としては「今の環境問題というのは根源的にはエネルギーをどう作るかという話に行くつくのであって、であれば無限のエネルギーを取り出せる装置があればエネルギー安全保障も環境問題もすべて解決するではないか」という感じのことを小学生の文体で記しており、将来の自分には「というわけなのでそれを作ってください。じゃ、よろしく。ばい〜」的なことしか書いていませんでした。

小学生のときから20歳になるまでに私は熱力学の法則を勉強して永久機関は作れないと学習したわけですが、それと同時に世界は4つの力、電磁気力、弱い力、強い力、重力から成り立っているということも学習しました。そして「弱い力」を使う原子力は現在の技術でもっとも永久機関に近い存在であるな、という印象を持ったのでした。昔も今も、ゲームで原子炉が出てくると何基も建設します。SimCityなり、Factorioなり。

中学〜高校はパソコンに熱中した時期でした。当時はまだインターネットが普及し始めた頃で最も早い回線はISDN 128kbpsでした。私の家はダイヤルアップ回線とテレホタイムという構成です。4kB/sの回線速度が出れば良い方で、Webサイト1ページの総容量は12kB程度に収めるべき、みたいなことが言われてた時期でした。私はその回線を使って今と同じように自分のWebサイトを作って更新するというのをやっていまして、そこでFTPだのTCP/IPだのHTMLだのといった知識を得ました。

大学は工学部に進みました。大学に入るまでも本を一つ書けそうなひと悶着があったのですがそれは割愛します。私が入った研究室は計算機科学の講座でしたが、その教授の専門は核融合でした。専門が核融合とは言っているものの、何の分野のどんなことでも知っている神様みたいな人で私からすると異次元の世界の人でした。その先生からいろんな話を聞いて再び原子力熱が高まり、原子力をやってる会社に入社することにしました。

当時、内定を貰っていたのはデジタルカメラ事業をやってる某社と原子力の会社の2つでした。カメラも好きだし原子力も好きだし、自分の体が2つあるなら両社に入りたいと思っていましたが、同級生に「カメラをやってるX社と総合メーカーのY社だったら、俺だったら悩むこと無くY社に入るけどな…」と言われて原子力の方に進みました。ちなみにどちらも本社ではなくて、実際に開発をやってる子会社の方です。本社に行ったらあんまり開発をやらせてもらえない、今どきはどのメーカーも子会社に技術は移っていると聞いたのでそうしたのですが、まあ、もともと有名企業の本社に入れるような学歴ではなかったです。

入社後

入社後はたっぷり1ヶ月の研修期間があって、そこで東大とか京大とか有名大学出身の人たちだったり、海外から日本に来た人たちだったりと肩をならべて研修をこなし、一流のお仲間になったつもりで有頂天で居ました。そもそも大学院卒業、24歳までずっと秋田の田舎で暮らしていたので東京に来るのもほとんど初めてでしたし。ありきたりな言葉ですが、見るもの、やるものすべてが新鮮でした。当時は遠距離になっていましたが付き合っている彼女も居て結婚も考えてましたし(1年後結婚しました)、もう何も怖いものはない無敵の状態でした。今考えるとすべてが恥ずかしくて思い出してうわーーーーーっ!となることがたくさんありますが。毎日がエブリディみたいな感じで日々充実していました。

研修の中でプラモデルを作って動かすという内容があり、パーツのいくつかはヤスリで研いだり多少の加工が必要なものも含まれていました。私はDIYerを自負していたので張り切って手を動かし、100人くらい居る中で1番に完成させて商品(ボールペンとノート)をゲットしたこともありました。あれは今考えても嬉しかったですね。たかがプラモデルですが…。

一番最初に与えられた仕事は原子炉内部の燃焼状態(余談:この業界の人は核燃料が核分裂反応を起こすことを「燃える」「燃焼」と表現します。我々がよく見るような炎を伴う燃焼が起きているわけではないです)をシミュレーションするシステムのクライアントプログラムにボタンを一個追加する、というものでした。Windowsで動くプログラムで、C++, MFCで作られてました。Windows 95くらいの世代で使われていた技術で、このときは2009年だったのでもうプログラミング言語ではC#がだいぶ普及しており、いかにも古いな〜という印象でした。

「IDEのライセンスがまだ用意できてないので、コードだけ読んでどう修正すべきか考えて欲しい」と言われ、コンパイル出来ないんじゃ何も出来ないし暇だな〜とコードをWindows メモ帳で見ていた(FOSSなソフトをインストールするのも面倒な許可証を書いて申請せねばならず、しかもその設備担当が偏屈なおっさんで新人の申請はまず通してくれなかった)ところ、どうも設定ファイルを修正することで独自のボタンをツールバーに表示させることができる機能があるらしく、それを見つけて「ボタンを表示するところまではできましたよ」と伝えたところ「IDEも渡してないのにどうやって…?」と不思議に思われました。昔から市販のPCゲームを改造していた知識が活かせました。

ただ、原発だとそんな感じで1日で終わるような小さなコードの修正も実際に適用するまでが非常に長くて面倒だということも理解しました。私が書いたコードを原子力発電所に収めるまでに書いた書類は覚えている限りで

  • コード払い出し申請書
  • 基本仕様書の修正
  • モジュール変更計画書
  • モジュールテスト計画書
  • モジュールテスト報告書
  • システム変更計画書
  • システム変更テスト計画書
  • システム変更テスト報告書
  • 工事作業要領書
  • 工事作業試験計画書
  • 工事作業試験報告書
  • 工事作業報告書

が必要で、その中にレビューが5〜6回くらいありました。それとは別に、すべての書類は上長5〜6人のチェックと承認が必要です。たとえたった一行のコード変更であってもこれらすべてをこなさないと、現地には納入できません。

ざっくり解説すると、まず「コード払い出し申請書」というのはソースコードのマスター(Windows SMB ファイル共有で保存しているコードのフォルダ!)から修正が必要なコードを取得する(払い出してもらう)という申請書です。払い出したコードは戻ってくるまで他の人が変更することは許されません。これによってコードの競合が発生するのを避けてるわけですね。「えっ、GitHub的なシステムがあればそんなものは要らないのでは…」とIT界隈の人は思いますね?そうですね、そのとおりです。当時、GitHubは設立したばかりでほとんど知られていませんでしたが、SVNやGitやMercurialは普通に使われていました。SVNに関してはTortoiseSVNがあってWindowsでも動いていました。でも、原子力の世界ではFOSS資産を極度に嫌うんですね。何かあったときにメンテ出来ない、というのが彼らの口癖でした。原子力とOSSの関係については後述します。

「基本仕様書」というのは文字通り仕様書なのですが、これはまったくあてになりませんでした。原子力の仕事で頼りになるのは実際に動くコード、それが全てでした。仕様書は仕様書としての体裁を保つことが目的として書かれており、人に何かを伝えようという意思をなにも感じなかったです。仕様書はすべて印刷され紙で管理され、最新版がどれかもわかりませんでした。仕様書の内容を信じてコーディングしたものはテスト時に必ず裏切られました。なんなら日本語の文法としておかしい文章もちらほら見かけ、時折見かける東大とか京大とかいう学歴と比較して、現場はなんでこんなことになったんだろう?とがっかりしました。

「モジュール」「システム」「工事」の違いは、それぞれ「単体」「結合試験」「現地試験」みたいなイメージです。結合試験以上は実際に納入したのと全く同じマシンでテストすることが求められていました。今思い返すと「実際に動いている環境と全く同じ状態で試験する」という点は正しいと思います。IT関係でも「CI/CDは通ったのに実際動かしてみるとなんかおかしい」みたいなのはたまに出てきますよね。

で、それら全てに試験報告書といって操作した履歴と結果のスクリーンショットを取って添付します。これがめちゃくちゃ面倒な仕事でした。スクリーンショットを取り忘れたらまた最初からやらなければならない…みたいなことを何度も繰り返しました。

後述しますが、ソフトウェア開発者の観点からはこの業務プロセスが原子力業界での最も非効率なところだと思います。まあ、誰の目にも明らかかもしれませんが…。ただ、当然ながら生産性を高めるためにチェックをそぎ落とせば良いという単純な話でもないので難しいところです。

原子力発電所内部の話

「工事」というステージはなぜ「工事」なのかというと、原子力発電所の作業は文字通りすべてが工事という扱いになるからですね。新しいソフトウェアを中央操作室奥にあるサーバマシンにインストールするという作業も一つの工事となります。工事なので、朝に原子力発電所敷地内にあるメーカーの事務所に集まってラジオ体操を行い、それが終わると危険予知活動や通勤災害、労務災害の報告とかケーススタディみたいなことをやります。ソフトウェアをインストールするためにWindowsにログインしてファイルをコピーする、Linuxのコマンドを打つ。それらも全部、指差呼称します。「sudo killall mybrightfulprocess、ヨシ!」みたいなね。

この時に学習した安全意識みたいなものは、日常生活でも非常に役立っている気がします。細かいところだと、階段・エスカレーターでは手すりを持つか、手すりをすぐ握れる位置を歩くようになりましたし、ポケットに手を入れて歩くこともなくなりました。車やバイクを運転するときも大げさに確認します。うちのキッズたちが階段で遊ぶのは絶対に許しません。1m超えたらもう高所作業として注意する。指差し確認とかKY(危険予知)とかは他の業界も見習うべき文化だと真面目に思ってます。みんなで現場猫になりましょう。

初めて原子力発電所に入ったときは感動しました。これが子供の頃からゲームでは何度も建設した発電所なのかと。私が仕事をしていた計算機室というのは、運転員が集まって原子炉の各種操作を行う中央操作室のさらに奥にあるため、おそらく最も奥に位置して最もセキュリティの固いところだと思います。どういったセキュリティがあるかは話したらまずい気がするので書きませんが、物理的に突破するとしたら重機を使わないと無理だと思います。そんなセキュリティも柏崎刈羽原子力発電所の東電社員がIDカード貸し借りで突破してたりしてニュースになったりしてますが…。(重要なところはカード貸し借りでも突破できません)

雰囲気を感じ取ってもらうために、とある出張の様子を書いてみます。

まず、原子力発電所への出張は前日入りが基本です。東京からだとどこの発電所に行くにも時間がかかるというのがまず一つありますが、それ以外にも原子力発電所には早朝に入らないといけないという規則があるところが多いためです。原子力発電所には電力会社のみならず、メーカー、建築・建設会社、それら下請けの人たちが大量に出入りするので近隣の道路が混雑して地元住民から苦情が来るので、その対策らしいです。東京からの出張組はメーカーが運行しているバスに乗って原子力発電所に入ります。ちなみに、昔は自家用車で出張に行くことが暗黙的に認められていて、車好きの上司などは行くたびに車を改造して高速でテストしたりして楽しんだ、6年で18万km走った、みたいなことを言ってました。今だとまあ、どこの会社でも認められないでしょう。80年代くらいの話だと思います。

事務所に到着して朝の6時20分とか、そのくらいの時間だったと思います。私は農家の息子だからか朝早いのは昔から得意ですが、苦手な人はすごく辛そうでした。事務所はよくある質素な市民会館とか市役所の分館とか、そんな感じのイメージです。出張者用にパイプ椅子と長机が部屋の隅にあります。

そして前述した通り、ラジオ体操が始まり、朝礼、災害の報告がなされます。機械で指を落とした、というのもあれば、酔って帰り道で転んで骨折した、なんてのもあります。原子力発電所ではとにかくケガをするな、ケガをしたら大変なことになると上司から言われました。冗談でよくそのとき語られていたのは「原子力発電所構内で作業員が歩道を歩いていたところ、転倒して膝を擦りむきました。この事故による放射能漏れは確認されておりません」というプレスが出るぞ、ということでした。とにかく、そのくらいよく報道されてしまうから気をつけろということですね。もともと建築・建設業界では労働災害は大事になり、そのルールと文化のもとで働いているという影響も当然あります。後々、プレスに載ってしまうような事態も起きてしまいましたが…。

朝礼が終わって自分たちのグループで危険予知活動(その日の作業で起きうる事故を列挙して注意喚起する)をします。我々はソフトウェア技術者なのでケガをするような危険はなかなか無いですが、それでも原子炉構内はバスが回っている程度の広さはあってよく歩くので、冬などは「滑って転ばないよう注意する」とかは当然注意すべきことの一つですね。あとは「コマンドを打ち間違って警報を発報させる」とか?私は一度やりました。常駐しているプログラムが死ぬと「計算機軽故障」というアラートが中央操作室に上がりアラームが鳴ります。私が作業していたときは定期検査中だったので大事にはなりませんでしたが、もし運転中だったら大変なことになっていたと思います。まあ、運転中にそもそもそういう作業(ソフトウェアを入れ替えて数日かけてテスト)はしませんが。

事務所で危険予知活動が終わって一段落したら、最初にやるのは出張者用PCに事前に教えられた静的IPアドレスを設定してネットワークにつなぐところですね。これで事務所のプリンタや社内システムなどにアクセスできるようになります。

それから電力会社の担当者の人と連絡を取り、作業に立ち会ってもらいます。短くても数時間、長いと数日の作業になることが多いのでたいてい途中で帰ってしまいますが。その間、我々は誰も居ない計算機室でファンとエアコンの音を聞きながら黙々と作業を行います。

(唐突ですが、ですます調を以降やめます。打つ文字数が若干増えて面倒なので)

作業の一番最初にやることはバックアップを取ることだ。操作するサーバーはサーバーラックに収まっているUnixマシン(Solarisだったかな?)で、ラックの中にDATテープドライブがあり、それにファイルシステム一式を書き込む。その時、tarコマンド(Linux/Unixシステムでファイルの単一アーカイブを作るコマンド)でバックアップを取るのだが「tarでテープにアーカイブを作っている!!」と感動した。 tar は tape archives の略である。

そこから黙々と作業を行う。

私がよく現地作業で行っていたのは炉心性能計算定数装荷工事というものだった。仰々しい名前のこの作業は、炉心内部の燃焼シミュレーション(これを炉心性能計算と呼ぶらしい)に使っているパラメータを新しい燃料の挿入に合わせて交換するという、それだけの話である。核燃料を製造している会社は日本原燃とか三菱原燃とかグローバル・ニュークリア・フュエル・ジャパンとか色々あるが、その会社は自社で製造した燃焼のシミュレーションモデルも提供しており、メーカーはそのモデルと、モデルで動かすための定数、初期パラメータなどを受け取ってシステムに組み込むという流れになっている。

これはだいたい1〜2日がかりの作業になる。決まりきった手順を機械的に操作するだけの単調なものであって、専門知識はほとんど要らない。全制御棒全引き抜き時にどういう計算結果になるとか、定格出力時にどういう計算結果になるとか、それを事前に燃料屋さんから貰った計算結果と見比べて同じになることを確認していくだけである。一回計算して計算結果をプリンタで出力して見比べて、次の計算結果をプリンタで出力して見比べて…というのを淡々と繰り返していく。

昼になったら一度事務所に戻り、事務所横の食堂で昼飯を食べる。食堂も非常に簡素な作りで、例えるならば「こぢんまりとしたパーキングエリアに唯一ある食堂」をもうちょっと質素にした感じ、あるいは、「地方の免許センターに申し訳程度に併設された食堂」という感じだろうか。ラーメン、そば、うどん、カレー、みたいなメニューのやつだ。食堂はいろんな会社の人が交じるので各々の作業着のデザインが違っているのを観察するなどして飽きることがなかった。事務所に駐在している人らは家族でその街に住んでいる人が多く、おそらく奥さんが作ったであろう手製の弁当を食べているひとが多かった。昼休みが終わったら厳重なセキュリティを幾重も突破して再び寒い計算機室に戻って作業を行うことになる。

それが終わったら事務所に戻って工事作業報告書を書く。これは現地に駐在するチームに手渡して最終的にお客さん(電力会社)まで渡る報告書である。現地のチームに渡さないといけないので急いで報告書を書き上げないといけないわけだが、我々にしてみればさっさと帰って次の仕事に取り掛からないといけないのだが、現地駐在の方々にしてみれば報告書にミスがあったときには「東京から出張に来た奴らが突貫で仕上げた報告書の手直しをさせられる」という認識になるわけで、時折「お前らが書いた適当な報告書を俺らが毎回直してるんだからな!最初くらいちゃんと書けよ!」などと怒られることもあった。

現場は「工事作業」なこともあってか、関わる人も体育会系な感じの人が多かった気がする。休憩時間はみんなで喫煙所にタバコを吸いに行ってパチンコや競馬や車の話をする、という、関東のIT系の人らが嫌いそうな付き合いがなされる。私は秋田に居たときはそれが普通だったので何も違和感を感ずることもなかったが。

よく行っていた発電所のメーカー事務所に居る課長は結構怖い感じの人だった。その時に私の上司Yさんがアドバイスしてくれたのは「あの人とあの人は怖くて礼儀にこだわるからちゃんとしとけよ。ちゃんと挨拶してはっきり受け答えすれば怒られないから。で、名前と顔もちゃんと覚えておくんだ。課長の方はイチローに似てるだろ?だからイチローだって覚えとくんだよ。その横の課長補佐は太ってて丸メガネでなんとなくドラえもんに似てるだろ?だからドラえもんって覚えとけばいいよ」という話だった。

そのアドバイスが私にとっては非常に良い方向に動いた。「東京からやってきて事務所の一角を専有して、面倒な報告書を置いてさっさと帰ってくやつら」という居心地の悪い環境で笑顔のままはきはき受け答えできたのは「イチローとドラえもん」が心の中にずっとあったからだと思う。もちろんあだ名をつけて馬鹿にしてたわけではない。イチローとドラえもんという名前を心の中で与えたことによってその人たちに親しみを持つと同時にコミュニケーションを柔和な方向に無意識的に持っていくという効果があったように思う。

宿はルートインみたいなビジネスホテルを取ることもあれば、民宿みたいなところを取ることもあった。出張時に宿の手配を行うのは新人の仕事だったが、これは難儀だった。どこを確保しても文句を言われる。いいホテルを取れば「なんでこんないいホテルを取ったの?」と言われ、安いホテルを取れば「別のところが良かった」と言われる。じゃあどこにしたら良いです?と事前に上司に聞くと、忙しそうにExcelの報告書をタイプしたまま「どこでもいいよ!取れるところを取って!」と言われる。

一度、協力会社の人に「どんなところが良いんすかねぇ?」と聞いて教えてもらったのは、自分では絶対に予約を取らないようなこぢんまりとした民宿だった。当時は「じゃらん」でしか予約を取ってなかった。教えてもらった民宿に電話して予約を取ると、もう先輩社員、上司と民宿の女将さんは顔なじみであって夕飯のときなどはビールをお酌してもらっていた。そういう馴染みのところがあるなら予め教えてくれればいいのに、と思う。原発は海岸沿いに建てられるのでそういった民宿では海の幸がふんだんに出てくることも多く、夕飯はボリュームがすごくて食べるのが大変だった。私は海産物がそこまで好きではないので…。

その民宿も東日本大震災で水没してしまったと思う。名前だけは覚えているが、検索しても出てこない。場所も大まかにしか覚えていない。あの女将さんがどうなったのか、今でもわからない。大型バイクを買ったので近くまで行ってみたいと思うものの、コロナや日々の雑務や仕事の都合などもあってなかなか行けずに居る。

テキサス州

そんな感じで徐々に仕事にも慣れてきた1年目の冬のことだった。私と同期で入ってきたA女史はテキサス州に原発を新設するというプロジェクトに配置された。ちなみにA女史について簡単に説明しておく。A女史は実家が太くてお父さんが某メーカーの重役であった。父親のコネでそっちに入ればいいじゃん、などと私なんかは安易に思っていたが、しかし彼女はそうしなかった。もしかしたら父親の会社に入ったらあからさまだからあえて入社試験を受けなかったのかもしれない。

そのプロジェクトの具体的な職務とはサウステキサスに原発を新設するにあたり米国某社の技術者が来るので基本設計書を英語で書く、というものであった。新入社員には荷が重すぎる内容に思えるが、上司Yさんいわく「基本設計は日本語の仕様書としてすでに存在するからそれを英訳する、という内容になる」ということであった。おじさんたちは英語が苦手だ。私だって苦手は苦手だが、まあ、英語のドキュメントくらいは読めるという点でおじさんたちよりもややマシ、と見なされたようであった。

その時の私の気持ちとしては、私が見たことのある「仕様書」なるものは前述したとおりひどいもので、中には客先に渡すマニュアルを「仕様書」と呼んでいるケースもあった。客先に渡すマニュアルはあくまでもマニュアルなので詳しい仕様が書いているわけではない。しかしながら、客先に提示しているマニュアルは正しくなくてはならないので、そこから逆説的に仕様が導き出される、というひどい論理(と私は思うのだがどうだろうか?)で仕様書扱いされていた。そこから本当の意味での「仕様書」など書きようもないことは明らかであった。

相手方は米国某社の若干29歳の技術者Lさんが担当であった。彼は一人で日本とのやり取りを行い、仕様をまとめるというミッションを行う役割であった。アメリカというのは若い人に重要な仕事を気軽に任せるんだなと漠然と思った記憶がある。単に日系メーカーで若年層が抜け落ちてしまっているだけかもしれないが。

案の定、仕様書を英語に翻訳するだけでは済まなくなった。我々が取り組んだのは端的に言うとリバースエンジニアリングであった。私が生まれるよりも前の世代の技術者が作り上げた原子炉というシステムを紐解いて何が仕様だったのかを導き出すというものである。私がお気に入りのYouTubeチャンネルの一つががCuriousMarcというものなのだが、このチャンネルではアメリカのアポロ計画で使われた実際の宇宙船に装備されたのと同じハードウェアを持ってきて、当時の設計書などと照らし合わせ、オシロスコープなどなどの機材をもってその動作を解明したり、時にCTやX線撮影して内部の部品を調べたりする。アポロ計画当時の技術はすでに考古学に近いのだと思う。同様にして、原子炉においても「考古学」化が進んでいた。原子炉の寿命は数十年と長いので、特に古い炉だと技術の属人化が進み、当時の担当者に聞かないとわからない、ということがたくさんあった。というか、ほとんどの情報がそうであった。

英語で仕様書を書くときに米国某社のLさんが指示したのは次のようなことだった:

  • すべての仕様は shall be ないし must be で書かねばならない
  • すべての仕様は一文で書かねばならない
  • すべての仕様には一意に識別できる通し番号を振ること
  • すべての仕様はテスト可能で無くてはならない
  • 仕様に補足説明が必要な場合は Guidance として記し、仕様の中に説明は書いてはいけない

これを聞いて私は感動した。今まで見てきた仕様書が頭の中で崩れ去り、そうだよ、仕様書ってのはこうあるべきだよ、と思った。仕様なのだからテスト可能であることは当然だし、誰がどう見てもゆらぎの無い文面で書かれていなくてはならないし、仕様がすべて実装・テストされていることを網羅してチェックするためには通し番号が必要である。ここまでやれば後任者が当時の文書を読んで技術者の意図を汲み取ることができるだろう。

一応、彼らの名誉のために書いておくと、彼らもちゃんと仕様の網羅性チェックは行っていた。すべてのテストは最終的に仕様書の塗りつぶしチェックが必須である。「仕様書の塗りつぶし」とはテストを行った結果確認できた仕様に該当する部分の文章を仕様書上で蛍光マーカーなどで塗りつぶす作業のことである。テストが完了した時に塗りつぶしていない箇所があればそれはテストが漏れているということが分かる。これは原子力に限ったことではなく、実施している業界は多いとは思う。

ただ、これはソフトウェア開発において「カバレッジ100%必須」と似ていてすべて塗りつぶす事そのものが目的化してしまう段階に至るとそれはソフトウェアの品質向上への寄与度がどんどん薄くなっていくし、仕様書を書くのもテストするのも同一人物だとテストを見越して塗りつぶししやすいようにわざと文章を削ぎ落とすなんてことをやる人も居る。一番の問題はトレーサビリティが無い、という点である。単純に塗りつぶしていてはどの仕様がどのテスト項目と紐付いていたのかという情報が失われてしまう。これではテストのエビデンスとして役に立たない。だから私は塗りつぶしをするとしてもテスト番号を同時に記載しておいた。

話を英語仕様書の件に戻す。その時に私がやっていた業務とは以下のような感じであった。

  1. 操作マニュアルから仕様らしいものを取り出して英語で記す
  2. レビューを受けて修正
  3. アメリカとテレビ会議を行い調整
  4. 上記までに出てきた不明点を「有識者」に問い合わせる
  5. コードから該当箇所を発掘して裏取りする
  6. 仕様書を修正する
    1. に戻る

もうちょっと具体的に書いてみよう。たとえば、操作マニュアルには「ボタンAを押すと炉心冷却材流量を計算して表示します」などと書かれている。これを英語に直す。(REQはrequirementの略)

** [REQ AFR-123] The core coolant flow rate shall be calculated and displayed at the request of the operator. **

これに対してレビューおよびテレビ会議にて以下のコメントがつく。

  • calculatedはtestableではない
  • どういう計算式で計算するかが書いていないとtestableではない
  • 計算式については某課の某氏が詳しい

計算式については絶対的な仕様書として崇められる唯一神として崇められる客先向けの操作マニュアルには書いていない。操作員はいちいち計算式まで理解している必要は無い。操作マニュアルのことを私は唯一神と書きましたがこれは適切な表現であって、すなわち神だっていちいち「何月何日は某市に向かってください。すると駅前にすき家がありますね。あるでしょう。そこに入って三種のチーズ牛丼を食してください。カウンターに座ってください。すると同じくチー牛を食べている男性がおることでしょう。その人とあなたは結ばれる運命にあります。幸せな家庭を築き子供を生み育てることであなたは救われますよ」みたいな具体的な示唆はしませんね。唯一神操作マニュアルもそうなのです。炉心冷却材流量を計算しなさい、と優しく諭してはくれますが、じゃあどうやって計算するねん、という疑問は世俗の問題なので神は関知しない。

なのでドラクエみたいなRPGがそうであるように、代わりに「どうやって計算するねん」というヒントが与えられる。それが某課の某氏、である。

おっと、そのまえに出来ることはやっておきましょう。上記のREQは修正を行い、

** [REQ AFR-123] The core coolant flow rate shall be displayed at the request of the operator. **
** [REQ AFR-124] The core coolant flow rate shall be calculated the by the following equation. **

f() = ... // TBD

となる。炉心冷却材流量はオペレーターの要求によって随時表示されなければならないし、その計算式は次式の通りで計算されなければならなくなった。ああ、これでテスト可能になった。あとは関数のところだけ書けば良い。

というわけで某課の某氏のところに向かうと、その人が優しい場合は「それはねえ、この仕様書に載ってるよ!」と見たこともない厚さ(指先から手首よりも大きい)のバインダーを手渡され、中の仕様書(と言う名のメモ帳。メモ帳なので正しいかどうかはわからない。コードをみて裏取りする必要がある)から該当部分を見つけ出すことになる。その人が不機嫌な場合は「わかんないなぁ。コード見れば書いてるんじゃない?」と舌打ちしながら目も合わさず言われる。いずれにせよコードを見なければならない。彼らの神様は操作マニュアルだったが、私の神様は実際のコードであって、信じている神様が違っている。

炉心冷却材流量の一件に関しては、「確か、ルンゲクッタ法で解いてるコードがあったはずだ」というヒントを頂いた。このヒントを元にコードを見ていくことになる。ルンゲクッタ、大学でちょっと習った記憶があるが詳細は覚えていない。

実際に見るコードというのは70年代くらいの水準の仕様を満たしているFORTRANで書かれている。一応、FORTRANは大学の授業でも行っていた。数値解析の教授が「皆さんはC言語とか好んで使ってるんでしょうけど、数値解析はやっぱりFORTRANですからね。FORTRANは配列の添字が1始まりでしょう。Cはどうです?0じゃないですか。皆さん、身の回りで前から0番目の椅子、とか数えたりしますか?しないでしょう」と分かるようなわかんないようなことを言っていたのが記憶に残っている。たしかにそうかもしれないが、慣れればどっちでも良いと個人的には思う。

さて、そのFORTRANをTerapad(設備担当の人が唯一許可してくれたテキストエディががこれだった)で開いて見てみる。するとコードの先頭に「看板」がある。書いた人の名前や書いた日にち、変更日などが記載される。初版は1983年などと書かれていた。私が生まれる前のコードである。書いた人の名前をたどると、私の上司Yさん(イチローとドラえもんを教えてくれた方)の名前もある。Yさんのコードは関数(サブルーチン)名に特徴があって、「ruru」とか「lala」とか一見して何をしているのかわからない名称が多かった。詳しく聞くと「風邪薬のルルから取った。詳しくは覚えていない」と笑っていた。

コードは10万行とか20万行とかあったと思う。頭から見ていって見つけ出せる分量ではないので、それらしいキーワードで当たりをつけて調べていく。それでようやく見つけた「炉心冷却材流量の計算式」はルンゲクッタではなくて古典的なニュートン法で解かれていた。あとは、本当にその関数が「使われているか」を調べていく必要がある。ソースコードがあることと、そのコードが実際に使われているかは別問題だ。じゃあブレークポイントを貼って動かしてみれば…などと思うかもしれないが、それは無理だ。このコードを動かすには昔のFORTRANが動く環境を構築した上で、いくつかの周辺のシステムと一緒に起動し、また別のいくつかのシステムはMさんという歴戦の古参兵しか知らないエミュレーションプログラムを起動し入力値を模擬しないといけないからだ。それらが動く環境は計算機室の隅に置かれた古いSolarisマシンだけでいつも誰かが使っている上に、おそらくデバッガも存在しないだろう、とのことだった。

実行環境がないんじゃソフトウェア開発なんて出来るわけがないと個人的には思う。だから再三再四、私は事あるたびに「せめて仮想環境に持っていって動くようにしましょう」と声を上げていたのだけれども、どうにもならなかった。よくネットでも「正しいことを正しいと説明するのは技術者の責務であるからそれを放棄することはよくない」みたいなことを言う人が居るが、それはあまりにも楽観的な態度だと思う。人間が集まれば必然的に政治は発生し政治力が幅を利かせる。その上で上層部が決定した戦略を下部組織が実行するという企業統治の力が働く。その仕組みの上で新入社員が正論をまくし立てたところで、「ううん、そうだよね」と苦笑いされるだけである。

そんなことを考えながら3時間も4時間も繰り返しコードを捜索して「必ずここは実行されている」と確証の取れたルーチンをたどり、「必ずここは実行されている」というコードを増やしていく。その結果、このニュートン法のコードを通る、という所まではっきりさせて確証を得て初めて「計算式はこうである」と書くことができる。それをテレビ会議の前に事前に上司らに説明し了解を得て(LGTMをもらうという程度のチェック)、ようやくLさんに説明可能となる。

ということを私とA女史は毎日行っていた。

私はこの作業は今考えるとそれなりに楽しかったように思う。なんというか、昔から市販ゲームの改造を行っていたがそれに近いものを感じたのだった。ブラックボックスの中がどのような仕組みで動いているのが調べ上げるという作業は私が昔から好んで行っていたことの一つだった。機械があれば分解し、ソフトウェアがあれば解析を行っていた。だから、配属されて半年後くらいには「この会社はソフトウェア開発を行う会社ではなくて、あくまでもハードウェア主体のメーカーに仕方なくソフト屋が付随しているだけなのだな」という印象を持ちがっかりしたが、と同時に、それはそれで別の楽しみがあるということもわかっていた。

ただ、A女史はそういうタイプではなかった。前述したとおり実家が太くて本人も「箱入り娘のお嬢様として育てられた」と自称していて、それはなんとなく雰囲気からも感じ取れた。ある時からA女子は仕事に平気で遅刻するようになった。うちの会社は8:15始業であってもともと早いという事情があったにせよ、それにしてもA女史が出社してくるのは10時とかそのあたりだった。一応、形式的なフレックス出社制度はあったものの、使っている人は皆無だったしA女史が正しい手続きを踏んでいるとおも思えなかった(使おうとすれば申請フローのどこかで待ったがかかったことだろう)。米国とのテレビ会議は時差の影響があっていつも早朝か深夜に行わなくてはならなかったが、それて疲れているのかな、というように思った。

A女史は

「部長面談がすごく嫌なんだよね」

と、当時私にはそのように伝えていた。部長面談というのは新入社員のフォローのために所属している部の部長が定期的に開催している面談で、そこで新入社員はどんな仕事をしいててどんな所が上手く行っていないのか、などを報告する。私は別にどうってこと無いと思っていたが、A女史はその部長がすごく嫌だったとのこと。一緒に面談を受けたので詳細も理解していたのだが、その面談は非常に和やかな雰囲気だと少なくとも私は思っていて、部長が「ここはどうなの?」と聞いてA女史が答えられないところもいくつかはあったが、それは今後頑張って行きましょうね、と皆がニコニコしながら会話して終わり、という程度だった。

結局、A女史は会社を辞めた。4月に入社して、12月あたりのことだったと思う。早朝、テレビ会議のために出社してまだ温まっていない会議室でエアコンの風切り音だけ聞きながら、A女史がお嬢様育ちだったから業務がキツかったのか、それともおじさん連中の中で働くことが苦痛だったのか、何もかも嫌だったのか。いろんな事を考えたけど結局よくわからなかった。

ある時、米国からLさんがやってきて数日かけて仕様書を詰めたことがあった。そのときに立川の居酒屋で飲み会をして色々な話をした。みんな英語は得意ではないが、なぜかその場の雰囲気で伝わってしまうような気がする。気がするだけで伝わってはいないかもしれないが。

そのときLさんが私のことを「炉心性能計算のスペシャリストだ」と褒めてくれたのが嬉しかった。今では「炉心性能計算」を英語でなんと言えばよいのかも忘れてしまったが。まあ、実際にコードを見て仕様を調べてきたのは私だったのでLさんから見ればそういうバイアスがかかっていたのと同時に、お世辞もあったのだろうとは思う。Lさんは「最近はみんなの大学の専攻を聞いて回ってる」と言う。私の学位はMaster of Engineeringということになっていたが、実際、最後の数年でやっていたのは計算機科学だけだったから端的に「Computer Scienceをやっていた」と言うと、「あーなるほどね」みたいな反応だった。

続いてその場にいたもう一人の上司(正確には親会社の係長クラスの人)に話が及ぶと、「聞いたらきっと驚くだろう」と前置きしたあとに「Accountant」と言った。私も驚いた。その場面を今でもよく覚えている。なぜ会計を専門にしていて今、原子力をやっているのだろうか。詳細は私も聞かなかったが、しかし、大企業というのはよくわからない組織で、そういう事をよく目にした。学歴が良くて受け答えがはっきりした学生を採用し、それぞれの能力はあまり精査せず部門の要求数と用意できた新人の数を勘定して機械的に割り振っているような印象を受けた。この人に関しては本当に、会計を専門にしていたがある日突然原子炉に目覚めて原子力の世界に飛び込んだのかもしれないが。

私が担当した仕様書はすでに書き上げたのだが、その後もいくつかの会議には招集された。その後の会議は私が理解できないところで紛糾することが多かった。ある時、ある人は「国内プラントとの整合性が取れなくなる」と、とある仕様の策定に難色を示した。なぜテキサス州に新しく作る原発で国内の原発との整合性が問題になるのか私は理解できなかったが、どうも

  • テキサス州に新設する原発の設計は国内某発電所のX号機が基礎となっている
  • しかるに、特段の理由がなければ設計は合わせないといけない
  • ただし運用する地域も国家も違うのだから同じ設計にはならない
  • 同じ設計にならなければ国内のお客さん(電力会社)から突っ込まれた時に説明できない

というところを心配しているようだった。電力会社が自社設備のメーカーの米国事業まで口を出すものなのだろうか?と今でも疑問に思うのだが、とにかくそういう話を延々としており、いつまで経っても仕様は決まらなかった。Lさんは頭を抱えて日本語の議論をやりすごしていた。

本件に限らず、多くの場面でいろいろな人が「既設に準じる」ということに重きを置いた。既設とは文字通りすでにある設計であって、原子力のようなミッションクリティカルなシステムは安易に設計を変更して新たなバグを組み込んではいけないという意識が非常に強く、設計流用出来るところはすべて設計流用するという方針が現場の技術者にも強く根付いていた。その考えは一定程度正しいとは思うものの、その考えに固執してしまって新規設計を忌避するのは良くない。技術者自身が成長しないし、正しい設計をする力も失われてしまう。いくら既設流用とは言えど、発電所の立地は全て異なるし、異なるお客さんが運用するし、それに応じてカスタマイズは入る。そのカスタマイズは正しいのかどうか、を判断できる能力は常に必要だ。

ただ、原子力の場合はあまりにもシステムの規模が大きすぎて全体像を把握できる人がほとんどいないという問題点もあった。これは多くの人が口を揃えて言うことだった。

ともかく、本件については「既設流用」ありきでそこで判断が停止してしまってるような印象を私は受けていた。

テキサス州のプロジェクトは、最終的に我々が現地に行ってコーディングとテストを行うことになるだろう、という話を聞かされ、それらしい会議にも何度か出席した。が、それも徐々にフェードアウトしていき私には別の業務が与えられ始めた。

というあたりであまりにも文章量が膨大になってきたので次の記事で書きます。多分更新するのは1週間後だと思います。