#コンピュータ談義 #システムの切れ目が非効率の温床 #一行野郎(ワンライナー)
あるWEB/CGIシステム開発
もう四半世紀前の話になりますが、私がIT部門でUNIX サーバーSE をしていた頃に他部署の方から相談を受けまして...
最初は、”こんな事出来ますか？”
といった風な質問であったのですが、よくよく掘り下げて聞いてみると...
あるシステムの出力をオペレーターの方が紙にプリントアウトして、その内容を別システムに手入力する工程があったのですが、時間もかかるし、人が行う事であるので入力ミスも発生するので何か改善は出来ませんかという話でした。
（生産品目に合わせて製造装置へパラメーター入力が必要という良くある話）
工場の生産工程の一部でしたので、入力ミスがあると影響が大きいとの話でした。
最初この話を聞いて”何て非効率で非人間的な事をしているんだ！”と頭をかかえました。😝
結局あるUNIXサーバー上にあるテキストベースのDB的な情報を検索して、入力に適した形式にフォーマットして表示するWEB/CGI システムをPerl ででっち上げました。
質問を受けてから、大体１ヶ月程でリリースにこぎつけました。
（それ以前に上司からの依頼で予約システムやワークフローを含むシステム等をWEB/CGI で構築していましたので、ノウハウと環境は既にあって開発難易度としては低かったからです）
オペレーターの方はブラウザで品番検索して、表示をコピペして入力するだけになり、省力化・入力ミスの低減に繋がりました。
きっと入力操作のストレスがかなり減った事でしょう。
こうして相談者には大変喜ばれました。
相談者は工程管理を行うエンジニアの方で、予算も掛からず短期間で実現できたので、そりゃハッピーだったと思います。😊
こういったシステム開発はUNIX SE としては業務範疇外でしたが、実質コーディングに費やした時間は数時間程度でしたので誰からも文句は出ませんでした。
（まあ、気分転換の余暇程度で実装可能な範疇でしたのでコッソリと内緒で...w）
DB形式の仕様書等が無かったので、数百程度の生データーのパターンをリバースエンジニアリングして自分なりに纏めるのが一番面倒でした。
データ形式に少し変則的な部分もありましたが、そこはエイヤーと決め打ちしました。
ただ今後どの程度想定していないパターンが現れるかと不安に感じたのを憶えています。(＜− 仕様は大事！）
まあ以上は単なる自慢話でしかないですが、ここで２点程感じた事・教訓を。
システムの切れ目が非効率の温床
現在でも、ある出力を別のシステムに入力するという業務は多いと思います。
ただ単純に形式（データー順序、複数の所からデータを取って来る等）が異なるので、チマチマとコピペを繰り返す様な非効率な作業は割と多いと思います。
こういったシステム間の切れ見にある非効率な事はかなり一般的で、それなりにスキルがあればEUC (End User Computing) という掛け声の下、誰もメンテ出来そうにないVBA マクロを量産したり、最近ではRPA (ロボティック)なんて流行ましたね。
そういった事を解消する為の需要は大きいと思います。
完全に定型な処理ならば、エンドユーザーでもかなり硬い自動処理が実現出来ると思いますが、そういった完全定型パターンは実際には少ない様にも見受けられます。
ある程度安定して動作する物を作るには、それなりのプログラミングスキルが無いと難しいと考えます。
プログラミング経験が少ないと、例外処理という考え方が甘かったりしますからね。
自分でもRPA を少し試してみましたが、実用的に使えそうな範疇は案外狭そうだという感想を持ちました。
パイプ
ここでやや強引な話題転換ですが、UNIX というOSには元々こういったあるシステム（コマンド）出力を別のシステム（コマンド）入力に簡単に繋げられるパイプという機能が実装されています。
カレントディレクトリにあるファイルの数を表示するためには
% ls -1 | wc -l
とすれば簡単に結果を得る事ができます。
'|' がコマンド間を繋げるパイプ記号となります。
'ls' はファイル情報を出力するコマンド('-1' オプションで、一行に１ファイル名表示)、'wc' は行数・ワード数・文字数をカウントするコマンド('-l' オプションで、行数のみを表示）です。
UNIX には'awk' (Aho, Weinberger, Kernighan というUNIX界隈では有名人の頭文字からきています。因みにAho はアホではなくエイホーと発音しましょうｗ)という整形に便利なツールも用意され、'awk' コマンドを絡めた数々の１行野郎（ワンライナー）という使い捨て文化が存在します。
私が上記ででっち上げたWEB/CGI システムは、こういったシンプルな使い捨て組み合わせコマンド（システム）と、正規に開発されたシステムの中間辺りのEUC 的システムであったなと思い返してみた所です。
私がクイック＆ダーティーなやり方に抵抗が無いのは、アマチュア無線のジャンク文化に源流があると自己分析しています。
そういった背景から「銀河乞食軍団」「ミニスカ宇宙海賊」みたいなSF小説は大好物です。😝
相談は真に受けるな！
私は何故か人からお人好しと思われやすいらしく、色々と相談を受ける事が多かった様に思います。
そういった経験から言えるのが”相談は真(字義通り)に受けるな！”です。
”XXXしたいんだけど、どうしたら良いですか？” みたいな形式の問題解決に関する相談は要注意です。
相談者は事前にある程度自分なりに考えて、こうしたら問題を解決出来るかもという独自の検討結果からさまざまな相談をしてきます。
ただ相談者は必ずしもITに詳しいとは限らず、かなりの確率で私から見てとんでもなく非効率でトリッキーな方法を検討しています。
ここで本当に必要な事は、字義的に質問されている事に直接回答するのでは無く、実際に解決したい問題自体を聞き出せるヒアリング力です。
内容によってはIT技術を活用する事無く、部門間の調整など非技術的手段で済むような事も多々あります。
また１０円の利益を得る為に１万円を費やすような、やらない方が良い事も多いですね。
またまた、それやってしまってはセキュリティー、コンプライアンス的に大問題だろうと言った事もあります。
時間が経てば要求項目・水準は変わってきますし（昔はセキュリティー面はあまり重視されていませんでした...）、使える手段・環境も変わってきますので、常にノウハウのアップデートが必要なのは時に少ししんどく感じる事もありました。
UNIXをやっていると、OS、ハードウェア、ミドルウェア、DB、ネットワーク、ストレージ等々全て絡んできますので、システム全体を見渡して適切な提言がし易いという面はあります。
なのでUNIX系エンジニアと繋がりを持っておくと色々と便利ですよ。😊
直近だとクラウドのAWS とか少しかじっただけですが、使いこなせれば色々な要望に比較的迅速かつ簡単に対応できそうな印象を受けました。
ただ複雑度はそれなりにありますので、コンシェルジュ的ポジションの存在が、クラウド使いこなしに対する成功の可否を握るのでないかと感じました。
最初にクラウド管理から入るエンジニアは、どういったシステム観を持つのか興味があります。
私はシステムを見渡した際に、ハードウェアレベルでの動作はバスの動き、内部のフリップフロップの動作まで想像が働きますし、プログラムのインストール時にはプログラマーの気持ちも分かるので、ああこういう実装をしているのだと思い描く事もします。
そういった諸々の事柄全てがクラウドでは仮想化され、実際に物に触れる事無くブラウザからの操作で導入が出来てしまうので、逆になぜそういう実装がされているのか理解し辛いのでは無いかと危惧しています。
まあこんな事を考えるのも、きっと時代に取り残されつつあるという事なんだろうなぁと寂しさを感じつつ、”老兵は去るのみ”ですね。😝