昨日の記事ではアクセス履歴の話から業務知識の話まで脱線してしまいました。
せっかくなので、業務知識の重要性について別記事で書きたいと思います。
前職では、証券総合取引システムを開発する元請け企業で保守開発を担当していました。
金融系のシステムは金融庁が定める複雑なビジネスルールを網羅する必要があるため、規模が大きくなり、自社の社員だけではシステムを完成させられません。特に製造やテストといった末端の作業では人手が必要です。
そこで協力会社に技術者派遣を依頼するのですが、自社の社員ではないため、派遣される技術者の知識レベルや技術力はまちまちです。
この問題に対処するため、このような大きなシステムの開発には独自のフレームワークが用いられ、誰が作業しても同じような成果物が上がるように仕組み化されています。
（これは私の勤めていた会社がたまたまそうだったという話ではなく、日本のIT業界に通じる一般論です）
このような背景があるので、「言われたことをコードに起こしてテストできる」というレベルの技術者であれば、仕事にありつくことができます。
しかし、このレベルに留まったのであれば、二次請けや三次請けの、あまり条件の良くない仕事しか取ってくることはできません。
実際に、私が前職で直接やり取りしていたIT企業は以下の２つの内のどちらかの条件を満たす企業でした。
①パッケージベンダー
②業務知識に強みがある協力会社
①について具体的に言うと、独自のフレームワークに組み込めるようなパッケージや、証券総合取引システムと連携できるインターフェースを持ったパッケージを開発する会社のことを指しています。
自社パッケージを作成し取り入れてもらうためには高い技術力が必要になります。
（偉そうに言っている私も、残念ながらパッケージ開発を主導できるような技術力は持っていません）
②に関しては、言い換えると「言われたこと」を超える判断ができる技術者を派遣できる協力会社のことを指しています。
そのシステムに関する業務知識がなければ、「言われたこと」が正しいのかどうかの判断がつきません。
しかし、業務知識があれば、どのようなシステムを作るべきか自分の中でイメージすることができるため、要件定義や仕様策定にも関われますし、末端の作業をするにしても仕様の誤りやテスト結果の妥当性の判断を行うことができます。
技術力が多少足りなくても、そこはフレームワークで補われます。特定の言語しかわからない（知らない技術には抵抗感がある）、というのでなければ大丈夫だと思います。
私が昨日提案した「金融業界の業務知識を身に付ける」というのは、②の方向性を目指すための提案です。
（COBOLで新しいパッケージを作る理由はないと思うので、COBOLを勉強する時点で②の方向性を目指すことになるとは思います）
なお、未経験の状態からスタートする場合、業務知識を身に付け知識を有していることを外に示すためには、その業務に関する資格を取るのが良い方法だと思います。
例えば証券業界では証券外務員という資格があります（私も持っています）。
