ボクは、自分を「データ入力作業が得意な人間」だと思ったことはない。
ただ、常に入力に意味を持たせる仕事をしてきました。
いわゆるデータ入力作業を担当した経験はありません。
専門学校時代、ワープロの授業では「かな入力」を使っていた。
入力速度や正確さはクラスでも上位だったと思う。
ボクが練習していたのは、
音楽の歌詞を曲に合わせて、無変換で入力し続けることだった。
言葉を“考えて入力する”のではなく、
指に言葉を覚えさせる感覚に近かった。
社会人になってからはローマ字入力になりました。
プログラミング作業では英字キー配列を使います。
入力方式としては、英字キー配列と一貫して使えるローマ字入力のほうが使い勝手が良かったので使うようになりました。
社会人になり、最初に配属された会社では、
新人研修が終わるとすぐに顧客先へ常駐することになった。
配属先は、顧客の運用管理プログラムを作る部署。
使う言語はCOBOL。
専門学校と社内研修で触れただけの状態で、いきなり実務だった。
驚いたが、やるしかない。
3か月ほど現場で業務をこなし、少なくともクレームなく仕事はできていたようです。
会社の事務所は1990年当時としては珍しい、
UNIXベースのワークステーションがあった。
マウス操作ができ、ウィンドウがあり、
ワープロや表計算ソフトも使える環境だった。
一方で、顧客先では大型汎用機の端末に向かう。
黒い画面に緑色の文字。
マウスはなく、キーボードだけで専用エディタを操作する。
今のWindowsやMacの原型のような環境と、
完全なCUIの世界。
両方を同時期に使っていました。
だが、どちらが正しいかを考えたことはない。
与えられた環境で仕事が成立するなら、それでよかった。
後になって振り返ると、
この感覚が今の自分の考え方の土台になっている気がする。
本当に苦労したのは、作業環境ではなかった。
仕様が決まっていないのに「システムを作れ」と言われた時だ。
複数のプログラムを寄せ集め、
一応「○○システム」と呼ばれるものを作った。
正直、死にそうだった。
この経験で痛感した。
先に設計がなければ、プログラムはただのバグになる。
最初に出力を定義し、
それに必要な入力と条件を決め、
その上で処理を書く。
この順序を外すと、すべてが不安定になる。
別の顧客先では、
リレーショナルデータベースの移行作業を担当した。
メーカー提供の移行ツールがあり、
旧環境からSQLを吐き出し、新環境で読み込む仕組みだった。
だが、移行結果がおかしい。
SQLの知識はほとんどなかったが、
出力された内容を一つずつ確認し、不備を見つけて修正した。
最終的には、製品側の不具合として正式なパッチが出た。
ここでも同じだった。
入力が正しく定義されていなければ、
出力が正しいかどうかを判断することすらできない。
最近、遊び半分でAIを使うようになって、
この感覚を何度も思い出す。
AIが賢いかどうかよりも、
こちらが何を入力しているかのほうが、
結果を大きく左右する。
だが、重要なのは入力だけではない。
出力をどう評価するか、
何をもって「正しい」とするか。
それを決めて初めて、入力は意味を持つ。
私にとって、コンピュータは世代を超えて同じ構造をしている。
大型汎用機も、DOSも、UNIXも、
見た目や操作方法が違うだけで、
入力・処理・出力という基本は変わらない。
そして本質は入力だけではない。
出力を定義し、入出力を設計して初めて、処理が意味を持つ。
その間にあるブラックボックスは、ただの変数だ。
AIプロンプト入力は、才能ではない。
設計である。
