アセンブラカウボーイ ～ わしらは、高齢プログラマー！ ～

第三章:問題発生！ さらに問題発生！

一

“焦ることは何の役にも立たない。
　後悔はなおさら役に立たない。
　焦りは過ちを増し、後悔は新しい後悔をつくる。“
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　ゲーテ
 
　一
　
　正月明け早々、安村と話をした。
　現状の課題を我々だけで抱えていても進まないし、後で大問題になってしまう。現在の状況を堀田に包み隠さずに話し、対応策を相談するタイミングは今しかない。
　安村も同じ想いだった。
これは、嫌な部類の会議になるのだが、プロジェクトの推進では往々にしてあり得る。抱え込んでいて炎上してしまう前に相談しておかなければならない。だが、そのタイミングは、本当はもっと早かった方がよかったのではないのか？そう思うと、途端に胸にすっぱいものがこみあげて来た。動悸も激しくなる。　
 
　会議室には、すでに堀田と竹内がいた。こちらは、安村と私だけ。神妙な顔を入っていったので、空気がピンと張り詰め、部屋の温度が下がったような感じがする。
 
　用意していた資料を大画面テレビに映し出す。
　私がまず、解析の見通しを具体的数字で示した。室山の解析ツールを使っても、生産性五割アップは困難であること、フルタイムでは働けないメンバーの多い今の陣容では解析だけでも一年近くかかることを正直に話した。
また、解析要員を追加したくても、伝田と私で退職者にあたった結果が今であり、これ以上の増員は難しいことも話した。
　更には、今のメンバーも、介護問題、健康面の問題もあって、当初予定の工数消化が難しくなってきており、契約工数を減らしてほしいことも話した。
　全てが後ろ向きな現状報告、解決策もない手づまりな話だった。
 
　安村は、解析結果を基にしてJavaプログラムに落とし込むには、オブジェクト設計もできる上級技術者が新たに必要であること、解析結果からのプログラム製作に要する工数を試算すると、最低一年必要であることを話した。要は“人”が欲しいという話だ。
 
　解析、Java化、各々一年だが、単純に足して二年という計算にはならない。解析が終わったプログラムをさみだれ式に作り替えていくため、各々の工程はラップして進められる。このため全体の工期は一年半だった。しかし、当初計画に対しては一年近い遅れとなる。
　堀田は苦虫をかみつぶしたような顔をしつつも、ある程度は想定していた雰囲気もあった。その日は「単純に延長はできませんし、人の追加も容易でなないでしょう。しかしまずは受け止めておきます」とだけ言った。
 
　堀田との打合せ後、DXチームと我々は、この先、何か効率よく進めていける方法はないか、解決策はないか、と打合せを持った。年の瀬までは、やや楽観的な雰囲気もあったが年が明けると、後がないという押し迫った感じにもなりだした。このためかみんなが真剣になり、その日の打合せは、飲み会で話した昔の会議のように、朝から夕方にまで及んだ。
　解析して、その結果からオブジェクト設計しなおして、Javaプログラムを作る。それをスケジュール通りに行うには、やはり“人”を追加するしかない、いろいろアイデアを出してみても、結局、議論はそこで煮詰まってしまう。
 
　夕方の休憩の後、DXチームの若手が、
「アセンブラから直接、Javaプログラムを作れないかな」と、つぶやいた。
安村がそれを聞いて、「えっ？もう一度言って」と言った。
「解析するんじゃなくて、その、アセンブラプログラムからロジックを“直接”Javaにしてしまうようなことができないかな？　ということです」「ようするに、同じ動きをすればいいんでしょ？ “同じ動きをする別のもの”に単純に置き換えられる方法があれば解決するんですよね？」と、その若手は、思っていたことを言った。
　若者は更に続ける。「今回、Java化するアセンブラプログラムは、DXパッケージとの連携だけなので、新たな要件の追加改修はありませんよね？単純にJava化できればよいだけですよね？そうですよね！」
「単純移行か！」と、安村が手をポンとたたいた。
今まで、リバースエンジニアリングのセオリーに則り、解析・再設計・再製作を粛々と行うことで頭が凝り固まっていた。若手の意見は、純粋に素直な目線からの意見だった。
「われわれの頭は柔軟ではなかったな。“単純移行”する方法を考えてみよう」
　アセンブラからJavaへの“単純移行”、翌日からはそれについて検討することになった。
 
　人手には頼らず、機械的にアセンブラからJavaに移行するツールがあればよい。しかし、そんな都合の良い魔法みたいなツール、そんなものは世の中には存在しなかった。正直、アセンブラの連続した手順的なプログラム記述を、オブジェクト指向のJavaに直接変換するのは、素人目にも難しく思える。
　また、そもそもアセンブラプログラムというもの自体が少なくなってきている。仮にそういうツールがあっても需要が少ないのではないか、という感じもする。
　結局は、いろいろ検討してみても、人手に頼る今の方法しかないのかもしれない。
 
　“単純移行”検討の間、作業の手を止めてしまってはお互いにロスタイムが大きくなる。
このため、我々のチームは、解析作業は進めることとし、DXチームはJava化作業を開始することとした。
　しかし、解析結果からオブジェクト設計をするのは、実際にやってみると、ハイレベルのJava技術者をアサインしても、想定以上に時間を要していた。
　ここも慣れによって生産性が上がったとしても、この方式で行っていった場合、更に工数が膨らみそうな印象だった。
 
　DXチームとの何度目かの打合せ。
　最近、いつもお互いに、ため息と苦笑で挨拶をし、雑談からの開始となっていた。しかしその日は、安村が見つけてきたツールの紹介から、いきなり始まった。
　それは、Midas（ミダス）というツールだった。ミダスは、触ったものを黄金に変えるというギリシャ神話の神の名だ。このツールは、黄金に変えるのではなく、COBOLをJavaに置き換えるものだった。
　「COBOLで書かれたプログラムをJavaオブジェクトに置き換えるツールはあった」と、安村は言った。
「しかし必要なのは、アセンブラからJavaに置き換えるツールだし・・・」
「まずはCOBOLがどんな感じでJavaに置き換えられるのか、ツールの試供版を使って環境を作って、試してみましょう」と、鹿野が言った。
 
　打合せの後、室山が机で考え込んでいた。作業の手が止まっている。天井を見上げ、何かぶつぶつ言っている。そして、私に言った。
　「ちょっと急ですが、今日の午後、もう一度、DXチームとの打合せをセットしてもらえませんか。詳しい話はその時にします」
 
　DXチームを前に室山がホワイトボードの前に立った。
「資料が間に合わなかったので、ホワイトボードで説明します」
　室山は、三個の四角を描き、それぞれに、アセンブラ、COBOL、Javaと書いた。
「Midasを使ってCOBOLからJavaに変換しましょう。それで、そのためにまずアセンブラプログラムをCOBOL化します」と言って、アセンブラの四角からCOBOLの四角へと大きな矢印を描いた。そして、COBOLとJavaの四角の間には、Midasと書いた。
「アセンブラからJava、直接移行するのではなく、COBOLを中間成果物とし、それを踏み台にするのです」
　思いもよらない発想だった。
　アセンブラを、一旦、COBOLに置き換える。そのCOBOLプログラムを、Midasを使ってJava化するというのだった。
「しかしアセンブラをCOBOLに置き換え・・」安村が言いかけるのを室山は制した。
「ええそうです。そのツールを作るのです！」
「このツールは私に検討させてもらえませんか？　かなり昔、完成はしませんでしたが、アセンブラソースからCOBOLロジックに置き換えるツールの検討をしたことがあるのです。それを思い出したのです」と、室山は言った。
　しかし室山がそのツールを検討したのは二十年以上も前の話だった。室山自身も自信を持ってツールを作れます、とは断言できなかった。
　まずはこの移行ツールを作ることができるか、それを検討してみるしかなかった。
 
　数日後、DXチームからMidasの試行結果が出てきた。
COBOLからJavaに置き換えた結果は、人間にとっては、決して読みやすいプログラムとは言えなかった。しかし、テスターにかけると同じ動きをした。
「まったく同じ動きをする別のものだな」
　ここで室山は、似たものへの置き換えではなく、別のものに置き換える場合は、読みやすくないものになってしまうのは仕方のないことだ、という話をした。
　例えば、COBOLからPL/Iへ置き換えを考えた場合、この二つは同じ構造化言語で兄弟みたいなものだ。そのため記述作法も非常に似ている。従って、COBOLからPL/Iに置き換えた結果は、非常に似たものが出来上がる。
　しかし、COBOLからJavaの場合、言語仕様が異なるため別のものができあがる。当然、COBOLの作法とは異なるから、読みやすくはなくなる。
　これは、アセンブラからCOBOLに置き換える場合にも言えることだった。その読みにくいCOBOLから、更にJavaに置き換える場合は、もっと読みにくいものができあがるのは必至だった。しかし人間にとって読みにくくても、少なくとも同じ動きはするのだ。
　プログラムが読みにくいと、保守性が悪くなる。しかしその場合は、プログラムロジックを説明する何らかのドキュメントがあれば、読みにくさは補完できる。
室山は更に続ける。
　「この先、何を優先するかということです。私は読みやすさを犠牲にしても、同じ動きをするものが出来ればよいと思っています。そこが達成すべき目標です。今は、アセンブラからJavaへの移行を優先して考えることにしましょう！」
 
　プログラムの読みやすさは犠牲にせざるを得なかった。アセンブラからJavaへの移行が最優先だ。
　アセンブラからCOBOLに置き換えるツールが出来てしまえば、移行作業は淡々と進めることができる。しかし室山は移行ツールの検討を始めたばかりだ。万が一、移行ツールが出来なかった場合、今まで通りの解析結果を基にしてのJava化となる。移行ツールが出来上がっても、読みにくさを補完するためには、ロジックが記述された解析ドキュメントが必要になる。
　このため、室山以外の各自には、今まで通りに解析作業を続けさせる。