見出し画像

「プログラマーの業務改善」の思い出(その1) (T2:Pt0:Ch01)

mottie (nob_mottie)

𝕏(Twitter)でたびたび「IT技術者がボランティアで業務改善した話」が賑わいますが、それで思い出す話。


時代背景――仕事場の環境と、自分の状況

仕事場の環境は：

  • 1990年代初頭。「社員一人に一台PC」はまだ遥か遠かった

  • FDベースのノートPCが支給され、ターミナルサーバー経由でUnixマシンにつながっていた（全員に、ではなかった記憶がなくもない）

  • もっともそれは技術用途で、事務作業は手作業、「紙に手書き」

自分はというと：

  • プログラミングの勉強と実践に邁進していた時期

  • かつ、言語への興味が募っていた時期（これは設計者時代を通してずっとですが）

  • Awkに熱中していた時期

    • 当時愛読していた「The BASIC」の記事で興味を覚えた。仕事場の「Unix環境(前述)」がアクセス可能になり、使ってみたら面白い！

    • “クリスマスプレゼントに金槌をもらった子ども”のように、「なんでもAwkでプログラミングで解決！(^▽^)/」みたいな気分でいた

  • これらが組み合わさって、Awkで「小さな言語」を創る機会を虎視眈々と窺っていた

やったこと①作業実績表集計・jiscalc

状況(問題、課題)

当時から、原価計算、案件ごとのコスト把握のために、われわれ技術者には「作業実績表」というものの記入が課されていました。
これが面倒で、しかも用紙が使いづらかった。

当時は 紙 でした。

要するにスプレッドシート(集計用紙)、「行(日付)×列(案件)の巨大な表」で、列にはその月関わった案件をひとつ以上記入し、行の日付と交わるマス目に、どの案件に・どれだけの時間を費やしたか記入する。

Fig.01 作業実績表(紙)

とにかくでかくて(A3判)使いづらかった。
複数の案件に従事しても対応できるよう、用紙の幅いっぱいに列が組まれている。

が、ソフトウェア設計なんて仕事はだいたい一案件に専属となりますし、複数の案件に関わってもそれらに毎日時間を割くようなことはあまりなく、従って基本的には「疎な(すかすかの)表」になるのは、Fig.01をご覧の通りです。なのにA3判のでかい紙にちまちま記入しなければならない。

そもそも、案件に熱中していたら「作業時間を毎日記入」なんてしないし……面倒なだけ……（まだまだ判っていなかった……）

しかも 紙 ですから、月末の集計は電卓を叩いて計算・記入しなければならない。

さらに（使いづらさとはあまり関係ないけど）「原本」のコピーを何世代も繰り返して印字や罫線が潰れているような代物で、なんか悲しかった。（昔のハードコピーはアナログでした）

Awkを手に入れた私はついに「集計の自動化」を志したわけです。

開発

Awkの最も得意とする領域「読み込んだ行を欄(＝案件ごとの作業時間)に分解して処理」だから、やることは単純、楽勝です。

……の割には、けっこう難渋した記憶がうっすらあります。たぶん：

  • データの書式。
    入力はプレーンテキスト、紙の作業実績表を模して「行(日付)×列(案件)」の二次元配列方式を採用。ただし列(欄)数は可変、先頭行に書かれた案件の数に従うこととする

  • というのはさっさと決めたけれど、（元の紙が「A3ヨコ」である位）横幅を食う。
    入力も出力も、当時の画面(80文字×24行のキャラクタディスプレイ)では折り返しが不可避で見づらい。（その見づらさをどうにか軽減できないか。けっきょく、効果的な手は思いつかず）

  • 「数値と見なせない入力を見つけた場合」「作業時間としておかしい値を見つけた場合」「案件の数と作業時間行の欄数が合わない時」といった、イレギュラーな入力/入力誤りの対応。
    虫取りの領域とも言えるが、今なら「当初の設計が甘かった」と思う

といったところで労力を使った気がします。
（Awkのような「気軽に書くことができる言語」を手にすると陥りやすい問題――「深く考えずに(デザインを詰めずに)書き始めて、後で苦労する」の実例でしょう）

このツール(Awkスクリプト)を 作業実績表集計⇒jiscalcと名づけました。
awkが使える環境なら：

awk -f jiscalc.awk 何年何月の作業実績ファイル.txt

でその月の作業実績を集計し、標準出力に出力する感じです。

開発後

  • 記入は「PCで、テキストエディタで入力」。集計はjiscalcで一発。が実現した

  • 「集計結果を作業実績表に手で転記」という謎の作業が残ったが、記入と集計の労力が軽減されただけでも「ずいぶん楽」になった

  • 「よかったら使ってみて」と周囲にばらまいた。どれだけ広まったかは知りませんが、同じ課の人や、プログラミング談義をよくしていた同僚などが使ってくれたようです

  • 縁の薄い課にも知れ渡ったようで、プログラムの改良点について「アドバイス」をくれに来た子もいました

昔から何度となく繰り返されてきた話

「プログラマーは、(自分が)楽ができる為なら何でもするし、労力を惜しまない」というのは、今でも𝕏(Twitter)を賑わせている“格言”ですが、私が開発現場にいた頃もそうでした、というお話でした。

その数年後から二年ほど別の仕事場で過ごし、戻ってきた頃には、全社員に一台、DOS/V PCとMicrosoft Windows 95が支給され、たぶんその頃を境に 紙の 作業実績表も姿を消し、jiscalcも役割を終えたと思います。

回顧

こうして昔のことを掘り起こすとあれこれ思い出したり考え直したりすることもあるものです。

「FDベースのノートPC」

と、何気なく書いていますが、補足しないと伝わらない時代になってる気がしました。

ラップトップ/ノートブック型のPCの発売が本格化するのが1980年代末。

これらの最初期ノートPCはフロッピーディスク(FD)から起動していました。
もっとも、当時はデスクトップPCでもFDDモデルは珍しくありません。

1台20万円超でしたが、デスクトップPCはもっと高価なので、端末用には「手頃」という判断だったのでしょう。

なお、この時期より少し前、当時の私の愛機だったMacintoshのシリーズにもラップトップ機 Macintosh Portable が登場していますが、重量7kg Σ(･ω･ﾉ)ﾉ！　価格1M円超え Σ(ﾟдﾟlll)　いくら物好きでも手は出せなかった……

データの書式（のデザイン）って大事だよね

書いていてふっと思ったんですが、jiscalcを考える時にたぶん本当に“難しい”、かつ一番楽しいところは

データの書式、というか、表現形式のデザインだったんじゃないかな。という気がします。

元の作業実績表(紙)やそれを模したjiscalcだと、先述の通りデータは(多くの場合)「疎な二次元配列」になって、色々な点で“無駄”が多いだけでなく、誤りも紛れ込みやすい。

↓のような書式にしていたら、入力がちょっぴり面倒になる代わりに手間が減り、入力誤りを少なく抑えられたのではとも思います（ん～……その時ここまで考えていたら！）。

12/10: XXXXXX(案件ID) 7.5(時間)
12/11: YYYYYY 7.5
12/12: XXXXXX 3.0
12/12: ZZZZZZ 3.0

当時は「データのデザイン」ということへの意識がまだまだ甘かったかも知れません（「熟慮の上で『疎な二次元配列』に決めたという記憶はない）。
Awkの「入力行を勝手に欄に分解してくれる」能力に目がくらんでいたかも。
（「データ記述言語」の試みにはjiscalcから5年以上後に挑戦することになります）

むすび

こんな軽い話でもけっきょく3,400字になってしまった(´；ω；｀)

T2では、プログラマー/ソフトウェア設計者の時代のことを職業プログラマー立志編から順を追って綴っていくつもりでしたが、いつまでも着手する気配が見えないので、ちょっとしたエピソードを小出しにしてみることにしました。

参考文献

  • A.V.エイホ(著), P.J.ワインバーガー(著), B.W.カーニハン(著), 足立高徳(訳) 『プログラミング言語AWK』 ユニバーサルシェルプログラミング研究所 2010

(2024-12-17 R001)

いいなと思ったら応援しよう！