ひょんな事から、人の作ったツールに機能を追加する仕事をしました。人の書いたプログラムを解読するのは学びの機会になるので大好きですが、目的とする業務を理解した上で眺めてみると、そのツールやシステムを使用する現場を無視した作り方がされていることが結構多いのです。

例のツールも、内部処理は単純ではあるものの、ユーザーの利便性や汎用性は無視された作り方になっていて、開発者都合で作られたような印象でした。

ユーザーが可哀想。

感情論で言えば、そんな感じです。ユーザーはもちろんソフトウェア開発の素人。だからこそ、技術力や知識を持っている玄人（開発者側）が、どのようにそのツールを業務で使用するのかを充分に聴取して、予測される業務変化に柔軟に対応できる（真に使える）ツールとなるように、提案をしながら作り上げるのが本当ですね。
（この辺り、翻訳も本来、こうあるべきなんですけど）

私がツール開発をする上で心掛けていること、それは「汎用性」が高く、変化に対して「堅牢」であり、ユーザーの操作が「簡略化」されていること。今から30年以上も前、大規模な情報管理システムの導入を経験したことがあるのですが、その時の失敗から学んだことが私の考え方のベースになっています。

ユーザーが使いづらさを感じると使われないツールになるし、無理に使わせようとすると「運用で逃げる」という無駄な業務工数を発生させる。企業内のツールによく見られる傾向で、業務改善を目的にツール導入して他の業務工数が増えるのでは本末転倒です。もちろん、開発必要工数と投入できる工数の関係もあり、やむを得ずツールの実現性を優先してそういうツールになっている可能性もあるのですが、そもそも開発工数は技術力と比例関係にあるので、裏返せば技術力がないのが原因なのでしょうね。

何のためにそのツールが必要なのか、どういう機能と拡張性を必要とするのかといった基本的なことを押さえるのはもちろん必要ですが、それよりも、ツール開発をどういう理念で行うのかをちゃんと定義づけるなど、方針の部分が大切なんだと思います。それがないと、プロとしての提案が生まれてこない。

なんでこんな話を持ち出したかというと、「ツールを作ること」に「その先にあるもの」が忘れられている状況が、「翻訳すること」に「その先にあるもの」が忘れられている状況と同じだと思ったからです。

「翻訳すること」という行為のみに焦点を当てているから、いまのMT開発のような発想がまかり通る(それを翻訳と呼ぶのはどうかと思うが)。技術的難易度もあり、実現性を優先させてそこを切り捨てているのか、単に認識していないから切り捨てているのかわからないけども、「その先にあるもの」が開発にせよ利用方法にせよ考慮されて完全に実現されない限り、人間を超えることはないだろうと思うのですよね。(だから安泰だと言うつもりはまったくないです)

日々の仕事の中でも「その先にあるもの」を含めて「翻訳」である、そこを勘違いしないようにしなくてはいけないとの思いを強くした一件でした。