これについて考えてみた。
最初のツイートはこちら。
「自分は文系だからプログラミングはちょっと…」
— HPEO🌐資格部 (@hpeo_jp) 2022年11月3日
とか泣き言いう人に対しては
「プログラムって“文”やで」
と優しく逃げ道を潰してあげてください
理系・文系なんて大雑把な分け方が良いわけじゃないんだけど、
実際問題として就職先として考えるならプログラマーは理系・文系問わないかな。もちろん、個人の資質として合う合わないはある。あと、中学・高校レベルの数学は把握していたほうがいい。ちょっとした時に役に立つんだよ。
ソフトウェアエンジニアとプログラマはきっちりイコールじゃないと思ってる。ここから先はプログラマの話。
趣味としてのプログラミングは好きにすればいいんだけど、文系出身が趣味でプログラミングというのはあまり想像できない。たまたま文系学部に進んだというだけで元々プログラミングに興味あるっていう感じなら分からなくもない。
でも仕事としてのプログラミングの場合、文系学部卒でも意外とマッチする人が多い。最初に貼ったツイートにもあるようにプログラミングって文だというのもある。それに世の中の9割以上のプログラムは小難しいアルゴリズムは不要で、データを右から左に移したりたまに計算したり程度である。OSとかミドルウェアとか大作のゲームとかを作るならもう少し面倒だが、仕事としてそっちに進める人はそれほど多くなく、ほとんどは業務アプリがメインである。それがユーザ固有なのかパッケージやSaaSやASPなのかどうかは別として。
条件分岐だって2択とか3択とかがほとんどで、境界値や組合せが面倒な条件分岐を一括で処理するなんてそう多くは無い。オレは昔一本すごく面倒なのをやったことがあるけどそれ1本である。それは後述する。
そもそもこの問題、1986年に新卒でソフトウェア企業に就職したオレが同期の人間の半分くらいは文系学部卒だったということでも立証できている。1年目はCOBOLのコンパイラ屋に配属されたが、システムエンジニア志望だったのでその1年間はプログラマ実習扱いだった。同じ課に配属されたのは他に3名で高卒男子1、高専女子1、文系大卒女子1名だった。COBOLのコンパイラ屋でさえ文系女子1名である。25%である。もちろん、工学部卒で大学時代からCやBASICでプログラミングしていたオレは飲み込み早いけど、文系女子に問題があったわけではない。普通に評価されてた。それに先輩方にもやはり25%くらい男女問わず文系卒いたし。オレの直属の先輩も文系卒だった。松坂屋を松板屋って書くような人だったけど。
じゃあ、50％くらいいた文系卒はどこに行ったかというと、多くは受託でユーザアプリを開発する部門である。言語仕様を把握して、コーディング規約を理解し、要件や要求仕様を顧客と詰めたり把握したり、ミドルウェアなどの仕様を把握すればプログラミングできる。あとは、自分の担当外で関連がある部分の担当をしている人とすり合わせも必要か。きちんと上から設計が段階的に詳細化されていれば、(仕様として明確だから)担当同士のすり合わせは少なくて済むけどなかなかそうもいかない事情もよく発生するし。
これはどちらかと言えば文系学部卒の人が得意な作業もある。そうなると、全部理系学部卒で固めるより文系学部卒も入っている方が適材適所ということになる。それに受託でユーザアプリを開発する時に、凝ったロジック・アルゴリズムはあまり使われないし。
凝ったロジック・アルゴリズムはあまり使われないって書いたけど、上で後述すると書いた話は凝ったロジック・アルゴリズムだった。システムエンジニアとして案件の取りまとめをしていて、部下は後輩一人がシステムエンジニアであとは協力会社の皆さんがプログラミングを担当という体制。実際にはオレはそのプログラムのプログラミングは担当せず、協力会社の若手エースの人が担当。
どういう話かというと、東証から値の情報(初値・高値・安値など)が降ってきて(東証相場報道システム)それを証券会社の他のシステムで利用できるようにデータベースに格納するというだけのもの。それまでは、面倒なので社名を書くとQUICKからデータを磁気テープで貰っていたのだが、そのサービスが無くなるということで東証からデータを回線経由で貰うという新システムが必要になった。
証券会社が速い回線のサービスを選んでいれば何も問題無く、受け取ったデータを淡々とデータベースに格納していくだけの話。ところがオレの担当している証券会社はそこをケチった。遅い回線のサービスを使うことに決めていた。すでに。
速い回線のサービスの仕様はきちんと見ていないので分からないが、この遅い回線のサービス、無手順単向というプロトコルである。仕様を最初に見た時にコレ考えた人はアタマイイって思った。SYN3つ送ったら、あとはリンク確立とみなすという最も無駄がないプロトコルである。ACKさえ送らなくていい。ベーシック手順よりさらにスリムである。
そこまで削りまくったサービスである。そこで起きた問題は送ってくる値の情報(初値・高値・安値など)の桁数が少ないというもの。それこそ一桁円の銘柄から、当時もっとも桁数があるのはNTT株。NTTだけではないが、複数の銘柄で桁数の上か下を削って送ってくる。上だけでも下だけでもなく上か下かであり、削ったよという情報は無い。どちらを削るかのルールはある。
人が目で見るならそれまでの値動きがあるので問題無く補完できるのだが、データとして使うためには落ちて届く桁の数字を復活させなければならない。全部の条件を洗い出し、ロジックを考えて桁数補完プログラムを作った。大したステップ数ではないが、かなり面倒な条件判定をしている。どの銘柄がそうなるかは分からないので、汎用的に作る必要もあるし。決め打ちでいいならもっと簡単である。
でも、今まででそんな面倒なロジックを組むはめになったのはその1回だけである。と思ったけどもう一つこのシステムで思い出した。計2回か。
このシステムでは夜間バッチにデータが揃っていればいいので、朝の取引開始から値動きのたびに送られてくる銘柄情報をただただ更新していく。桁数が少ないという問題が無ければ特に苦労も無いはずだった。証券会社の店頭ではこのシステムの銘柄情報は見てなくてQUICK端末見てたので、特に昼間は何もない。でも、夜間バッチを開始する前には全銘柄の更新が完了していて欲しい。そこで後から要求されたのは、「全銘柄の更新が完了したら夜間バッチを実行するオンライン号機に教えてね」というものだった。何を全銘柄の更新終わりとするかだが、うろ覚えだが確か場が終わってからもずっとデータを送ってきていて、それが終わったら(送信されてこなくなったら)全銘柄の更新完了である。
当時のその証券会社のメインフレーム、通信としては直接にはそれぞれ独立で繋がっていない。今で言えばLANが無い。オレが構築していたシステムが動いているマシンとオンライン号機で通信する手段がない。でも、ディスクは共有されている系があった。銘柄情報のファイル渡しが必要だったためである。全銘柄の更新が完了したという情報の通信はできないが、それは渡す銘柄情報ファイルとは別に、更新完了ファイルも渡すことにして運用ソフトウェアで更新完了ファイルの到着を確認したら後続ジョブを走らせるという自動化を組んだ。ファイル到着チェックだけなのでそういう意味では簡単な話だが、通信していない独立したメインフレーム同士で「なんだかわかんないけど、うまくやりとりする仕組み」はできた。顧客にも仕組みは説明したしドキュメントもきちんと書いたけど、オレは毎回「なんだかわかんないけど、うまくやりとりする仕組み」と呼んでた。いや、オレは分かってるけどね。
ということでこういう無理難題がそうそう発生することはなく、文系出身でも問題無いはず。個人の資質にはよるけど。
なお、弊社は遺伝的アルゴリズムを用いた組合せ最適化問題が得意。この文が何を言っているのかわかって何か解決したい組合せ最適化問題があれば是非ご用命を。
