かなりシステム業界に偏っているけど、しばらく仕事の話をしていきたい。
ボクが入社したシステム会社は、ある業界の自社パッケージソフトの開発＆販売をしていて、業界内では、そこそこ売れている有名なソフトだった。
今になって振り返ると恥ずかしい話なのだが、システム会社に入社した時、システムというものは毎回、導入する企業ごとに、まっさらの状態から作るものだと思っていた。
しかし、パッケージソフトになると、標準パッケージというものが土台としてあって、システムを導入する企業に合わせて、その標準パッケージでは対応できない箇所を、カスタマイズをしていく流れになっていた。当初のまっさらの状態から作るという、ボクの愚かな想像とは随分状況が違っていた。
会社内には、標準パッケージのバグ対応や新規機能の開発を行うチーム。新規導入案件を対応するチーム。さらに導入した後のサポートを行う保守チームなどもあった。
ボクはその中でも新規導入案件を対応するチームに配属された。
他部署にウェブサイトを構築するチームなどもあったけど、そちらの部署に配属されなくてよかったと思った。この辺は会社の上司がボクの適性を見て配属先を考えてくれたんだと思う。
パッケージソフトの場合、その業界の「業務知識」があればよい。
入社して一年も経てば、与えられたスケジュールには、常に前倒しでプログラミングの作成はできるようになっていたが、プログラミングのスキルは人並みのレベルに達した段階で、関心を失っていた。ボクはもともと文系思考なのか、その業界の業務の流れといった、業務知識に強く関心を持っていた。
その点、ウェブサイトの構築になると、もちろん業務知識も必要だとは思うが、言語の習得やプログラミングのスキルなど求められるし、場合によってはデザイン的なセンスも求めらていた（あくまでボクが入った会社の状況であって一般的ではないかもしれないけど）。
パッケージソフトの場合、言語の習得は、毎日同じ言語のプログラムを見てれば、嫌でも覚えられるよね……という感じだった。さらにプログラミングのセンスもそこまで強く求められる感じではなかった。もちろん、一部はスキルのいる作業もあったけど、その辺の作業は、どこの会社にでも一人か二人はいる理系オタクの社員に教えを乞えばよくて、普段から職場の仲間と人間関係が築けていれば問題なかった。さらに大型案件の場合は、プログラミングは下請け企業に依頼されることも、しばしばあった。
少し極端な気がするが、パッケージソフトは業務知識（例えば銀行や医療や会計などの業界ごとの知識）があって、標準的な業務の流れさえ理解できていれば、他社のパッケージソフトでも、画面を見れば何の機能か理解できるしし、データの流れとかも推測できる。自社のソフトとどこが違うかと確認していけばよかった。開発する言語は違って多少は癖があっても基本的な言語の構造は、ほとんど同じだと考えていた。
パッケージソフトのシステム開発は、ウェブサイト構築と違って、業務知識という普遍的な物があってボクには向いていた。この業務知識を優先する考え方が、五年後に転職を決意する、きっかけになる。そして業務知識以外に、自分の中でもう一つ、仕事をする上で大きく重要視していることがあったんだけど、それに本当に気がついたのは転職して一年くらい経ってからだった。それは別の機会に書くことにする。
とにかくボクは自分の適性を見極めて、配属先を決めてくれた会社の上司に感謝していた。
＜つづく＞
