技術とか戦略とか

SIerで証券レガシーシステムを8年いじってからSESに転職した業務系エンジニアによる技術ブログ。

高度な技術が最適解とは限らない

AIや難しいアルゴリズムに憧れる人は少なくないと思いますが、そのような高度は技術が常に最適解であるとは限りません。
高度ではない技術には、以下のようなメリットがあります。
・人間が結果を予想しやすい
・保守が容易である
 
一言で言うと、「扱いやすい」ということがメリットになります。
高度ではない技術は、人海戦術になりがちで導入コストがかかり、システム構築時のヒューマンエラーも起こりがちですが、システムを保守・運用する上では、そのようなデメリットよりも「扱いやすい」というメリットが上回る場合が少なくありません。
 
この記事では、高度ではない技術の方が優れていたという例を2つ挙げます。
 
1.ソースコードの変数名の翻訳
ある現場では、ソースコードの変数名を日本語から英語へ翻訳して書き変える、という案件が走っていました。
 
この案件では、当初は「形態素解析」と呼ばれる技術を使うことが検討されました。
この技術は、文章の文法を読み解き、文章中に含まれる単語を切り分ける、という高度な技術です。
 
しかし、形態素解析を用いた解釈とその解釈結果に基づく翻訳を試みた所、翻訳結果を予想しにくいという問題が発見されました。
ソースコードの変数名を翻訳する場合、翻訳結果が予想できないとバグに繋がるため、この問題は致命的でした。
(例えば、翻訳した結果変数名が被ったり、同じ変数が異なる翻訳結果になったりした場合、そのソースコードから作られたロードモジュールの挙動が変わってしまう)
 
検討した結果、形態素解析は用いず、csvの定義ファイルを用いた単純なパターンマッチングにより翻訳を行うことになりました。
csvの定義ファイルは約8,000レコードであり、その定義ファイルを作成するのに人手が必要になりましたが、結果として翻訳したプログラムは安定稼働しており、案件は成功を収めました。
 
2.RPGの複雑なバリデーションチェック
あるRPGロールプレイングゲーム)を攻略する上では、そのRPGのシミュレーターを作成し、シミュレーターにより最適解を探し出す、という手段が有効です。
このシミュレーターでは、実際のRPGと同じ状況を再現するために、入力のバリデーションチェックの実装が必要になります。
 
今回問題になるバリデーションチェックは、キャラクターが覚える技の組み合わせに関するバリデーションチェックです。
攻略対象であったRPGでは、キャラクター毎に覚える技が決められており、またキャラクターの育成方法によっても覚えられる技が変わってきます。
育成方法に関する条件は大きく分けて5つあり、その5つの条件について、キャラクター毎に細かい分岐条件を考える必要がある、というものでした。
 
シミュレーターは日本製と海外製の2つがありますが、それぞれで実装方針が以下のように異なっていました。
日本製:人手をかけて調査し、調査結果を約15,000レコードのcsvファイルにまとめる。
海外製:「NP完全問題」を解く、というアプローチで高度なアルゴリズムを実装。
 
結果として、日本製のシミュレーターにも、海外製のシミュレーターにも、実装ミスはありました。
 
しかし、日本製のシミュレーターは、csvファイルのレコードを書き変えるだけで改修作業が完了するので、実装ミスに対して容易に対応することができました。
また、csvファイルは人間が読んでも意味がわかるものなので、プログラムによるバリデーションチェックで使うだけでなく目視のチェックにも使える、という副次的なメリットもありました。
 
それに対して、海外製のシミュレーターは、複雑なアルゴリズムを読み解かないと実装ミスへの対応ができません。
結果として、誰も修正することができず、実装ミスが放置され続けています。