「もういいんだ、田舎に帰る」、キャリアプラン無き会社を辞めた話

 初日から徹夜になった。現場に着くなり、いきなりプログラムを作らされ、何がなんだか分からないまま、次々に作業を続けるはめになった。

 ある金融関係のシステム開発現場に放り込まれた時のことだ。その仕事を請け負っているIT企業の下で働く、いわゆる2次派遣だった。

 それから2カ月間、朝出勤し夜遅くまで現場に張り付いた。家に帰れたとしても、翌朝から勤務を再開しなければならず、疲れた身体を短時間横たえるだけで、仮眠以外のプライベートタイムは一切無かった。人と顔を会わせるのは、生気のない顔した同じメンバーばかり、といった日々が続いた。

 難航する情報システム開発の状況を、火事に例えることがある。現場がすでに燃えている状況で投入された私は、とにかくプログラミングとドキュメント作成をがむしゃらにやるしかなかった。

 約2カ月で解放されたのは、一応の火消しが終わったからだ。その後、別の金融関係の現場に同じく2カ月ほど派遣された。こうした短期の2次派遣を2カ所経験したのは1991年のことであった。

 短期間の消火活動を振り返ってみると、体はきつかったが、気持ちのほうは案外楽だった。動くプログラムを作りさえすれば文句を言われなかったからだ。とりあえず動かせばいい、と割り切れば、それほどのストレスは感じなかった。

 短期の仕事が一段落したある夜、帰り道に空を見上げた。よく晴れた日だったので、夜空には手が届きそうなほどに星がまたたいていた。試しに手を伸ばしてみたけれど、当たり前のことながら、のばした手の遥か先に星がまたたいているだけだった。

「とにかく動けばそれでよい」

 短期の派遣を経験する直前、私はあるSIerの中で仕事をしていた。私が勤めていたソフトハウスがそのSIerの子会社から会計システムの開発を請け負っており、その現場に通算1年半ほどいた(『「電車に乗ろうとすると気持ちが悪くなるんだ」、現場に来られなくなった話』参照)。

 私たちの会社が担当していた会計サブシステムの稼働に目途が付いたのは1991年の夏、私は27歳になっていた。その頃には、私が当初作成した出来の悪いプログラムをなんとかまともな形に整えることができた。

 その現場では最後までモチベーションを高めることはできなかったものの最低限、「やるべきことはやらなければ」という思いをなんとか持ち続け、その現場の仕事を完遂できたと思っている。

 その仕事が終わり、冒頭で述べた通り、短期の2次派遣を2カ所経験した。「何がなんだか分からないまま」と書いたが本来ならそういうことはありえない。訳が分からないままプログラミングなどできないはずである。

 もう少し正確に書けば、渡された仕様書を読み、ひたすらプログラムを製造しただけ、ということだ。自分が作っているプログラムがシステム全体の中でどういう位置にあるのか、このプログラムはどういう現場でどのような業務に使われるのか、そもそも発注者の狙いは何か、といったことはほとんど知らされなかった。各現場特有の業務知識を習得する余裕もまるでなかった。時間という制約に追いまくられ、作業を続けるだけの日々だった。

 発注者の担当者も、元請けの担当者も「とにかく動けばよい」という姿勢だった。レビューはあるにはあったが一応動けば細かい事はスルーされた。こんな乱暴な作り方では長くは使えないプログラム群が積み上がるだけで情報システムとしてのライフサイクルが短くなるのでは、という思いが頭の片隅をちらっとかすめることもあった。だが、後々の心配までする余裕はなく、その場をなんとか乗り切る、それだけしかなかった。

工程や用語の定義は現場ごとにばらばら

 プログラマーとして働き始めてからしばらくは、比較的長期の仕事をしてきた。それから短期の仕事を2回こなしてみて、一番戸惑ったのは工程や成果物に対する考え方が現場ごとに異なることだった。火事現場はひたすら忙しかったと書いたが、それでも多少の時間ができた時に上流のドキュメントに目を通す機会があり、そういう違いに気付いたのである。

 基本設計、詳細設計、外部設計、内部設計のそれぞれでやるべきこと、つまり工程ごとの成果物に対する考え方が現場によって異なっていた。成果物のフォーマットは違うし、書くべき内容も違った。コーディング規約も違っていた。

 それぞれの現場の中では、ドキュメントやプログラムについて何らかの標準化がされていたのかもしれなかったが、参加した技術者にきちんと教育されていたようには見受けられなかった。まして、短期間だけ投入された私は誰からも教えてもらえなかった。他人が作ったドキュメントやプログラムを真似て書くしかなかった。

 ソフト開発の業界で工程や用語の定義がもう少しでも標準化されていれば、生産性も品質も確実に上がったに違いない。火が着いてしまい短期間で人員を投入するはめになったプロジェクトの立て直しにも寄与したはずだ。定義や標準がはっきりしていれば、メンバー全員のベクトルを同じ方向に向けられる。定義や標準に込められたプロジェクトの魂というか、基本のようなものを継承することもできただろう。

 そういうことをプロジェクトリーダーが心掛けて、プロジェクトに関わる全員に伝えるだけで少しはいい方向に進みそうなものだったが、そんな現場に出会うことはなかった。なにしろ火事の最中であり、標準がどうの、品質がどうのと言える状況ではなく、全体のベクトルがどこに向かっているのか分からないまま作業を続けるしかなかった。

リソースを「消耗品」として使い捨てる

 ソフトハウスでSEやプログラマーをやり、色々な現場をたらいまわしにされているうちに「業界で工程の定義が統一されていれば、もっとスキルの蓄積が可能になるだろうに」と思うようにもなった。

 スキルを蓄積するには、技術者一人ひとりにキャリアプランがあることが前提だ。プロフェッショナルとしてそれは自分で立てるべき、という正論があるだろうが、会社員をしていたらどうしても会社頼みになるところがある。

 ところが思い返してみれば、派遣中心(受託と称していても実際には派遣が中心)のソフトハウスにキャリアプランなど無かった。今はどうか分からないが、当時、私が所属していたソフトハウスの社員は、その時その時稼げると判断された仕事に当てはめられ続けるだけだった。運が良い人はキャリア形成につながる仕事に就け、それが続くこともあるが、反対に運が悪い人はキャリアにつながらない現場をさまよい続けることになる。

 企業は、持っているリソースを最大限活用して売り上げを最大にしようとする。この考え自体は商売の基本であり、“そもそも論”としては正しい。問題なのは派遣で儲けようとしていたソフトハウスの場合、リソースが生身の人間だということだ。

 儲かりそうな現場というだけで、本人のことなど何も考えずに放り込み、しかも放置する。これではキャリア形成につながらない。人というリソースを「消耗品」として使い捨てることになってしまう。

 たらいまわしの逆として“塩漬け”があった。その仕事を続けてもキャリア形成にまったくつながらないのに、発注先から支払ってもらう単価が高かったために、その人を同じ現場にずっと置いておくことである。

 彼もそうであったのだろう。短期の仕事をしていた頃、私にとって最初の現場で一緒だった同僚から電話がかかってきた。「田舎に帰る」という話だった。若いのに随分思い切った決断をするな、と思い、あれこれ聞いてみたが「もういいんだ」の一点張りだった。

 彼は高校卒業後、専門学校を経てすぐ入社したので、年下ではあるものの社歴では先輩だった。ところが彼は入社以来、ずっと同じ現場にいた。彼はそこしか知らなかったから、煮詰まってしまったのだろう。同じ現場で同じようなことしかやらせて貰えない。漠然とした不安を感じ、耐えられなくなったのではないか、と想像した。

 人の決断に対して何か意見を言える程の立場に私はなかったから、「これからも頑張ろう」とお互いにエールを交わして電話を切った。同じことばかりやらされて気の毒だったなと思った半面、正直なところ、彼がうらやましいという気持ちにもなった。

 田舎に帰って仕事があるかどうかは分からないが、少なくとも彼には帰る場所がある。私は東京生まれの東京育ちなので、この大都市が故郷であり生活の場でもある。私に「帰る」場所はなかった。こんな風に思ったのである。

「こんなことを年食ってまでやっていられるか」

 私がSEやプログラマーをしていた今から20数年前、至る所で言われていたことに「SE35歳定年説」があった。当時はそんな説が当たり前にまかり通っていたのである。SEやプログラマーの仕事は、それも派遣されて現場を渡り歩き続けることは、年をとってまでやることではないとされていた。

 当時の我々のような、消耗品扱いの人達を見た誰かが言い出したのだろうか。私も消えていった先輩、同輩を目の当たりにして「こんなことを年食ってまでやっていられるか」としばしば思っていたものだ。

 だが、これは年齢の問題ではない。ベテランになっても、複雑なアーキテクチャの上で複雑な設計をして、ばりばりソフトをつくっている技術者は当時いたし、今もいる。本当の技術者であれば年齢など関係ない。年を食って役に立たなくなるのは、技術者ではなく、やはり消耗品ということだ。

 私のように消耗品扱いされたSEやプログラマーであっても、気の持ちようで技術者になれたはずである。今ごろになって思うのは、当時与えられた仕事をしながら、もっとスキルアップできる余地があったし、充実感を得る方法もあったということだ。実装だけでなく、アーキテクチャ設計など上流のスキルを磨く機会はなさそうで実は沢山あった。もったいないことをしていたのかもしれない。

 自ら動けば運命を切り開ける。当時の私でも、このくらいのことは頭で理解していた。だが、私は動けなかった。消耗品の状態に置かれ続けると精神が麻痺してくる。人は弱いものだ。使い捨てされても仕方ない、運命とは切り開くものではなく受け入れるものだ、などと思うようになっていく。そうなると技術者であろうという強い意志を持つことなく、消耗品のままでもいいかな、と諦めてしまう。

 当時の私には、そうした負け犬根性が染みついていた。這い上がろうという気力を自ら奮い立たせることができず、結局、言われたことをやっているだけだった。そうなると、「どうせ俺は」といったように、考え方がどんどん後ろ向きになっていく。

「社会人として失格だ」

 1991年の夏に、会計サブシステムの開発プロジェクトが終わったと書いた。複数経験したプロジェクトの中では無事に終了したほうだろう。少しは晴れやかな気分になりそうなものだが、この時期にも下請けの立場にうんざりしてしまった出来事があった。下請けの立場というより「下請けで働いている私は社会人として失格だ」と改めて気づかされたというべきか。

 我々に対する慰労会を発注側(あるSIerの子会社)の部長が開催してくれ、そのサブシステムに関わったメンバーが参加した。発注側の部長、プロジェクトマネージャー、私が所属していたソフトハウスのメンバー全員が車座になって座った。

 先方の部長、プロジェクトマネージャーは我々となんとかコミュニケーションをとろうと色々な話題を振ってくる。ところが、応答するのは我々の会社のリーダーとサブリーダーだけだった。二人は杯を手にしたまま口をつけることもなく、先方の話に一生懸命応えていた。

 私を含むそれ以外のメンバーは何をしていたのかというと、気を遣って貰っているにもかかわらず、愛想のひとつも言えず、隣の席に座った同じ会社の者同士で、ビールに口をつけながら小声で話すだけだった。せっかく開催してもらった慰労会は、なんとなく白けた雰囲気のまま、お開きになった。

 その宴会で私は苦いビールを飲みながら、前にも同じようなことがあったと既視感を抱いた。私がプログラマーになって最初に配属された現場で、大元の発注者である生命保険の情報システム部長が主催する懇親会が開催された時のことだった。

 部長やプロパーのシステム部員は、我々下請け全員にわざわざ酌をしに回ってくれた。そのくらい気を遣っていただいていたのだが、我々は杯を差し出しながら小声でお礼を言うくらいしかできず、まともな会話は成立しなかった。

 それでもプロパーの社員達は、白々しい空気をなんとかしようと世間話を必死に振ってくれた。だが、我々の会社のリーダーがそれに応えようとした位で、他の誰もまともな反応が返せなかった。

 先方の部長やプロパーの人達はうんざりしたに違いない。我々が担当させているサブシステムの開発プロジェクトがうまくいくように、コミュニケーションの一環で席を作ったのに、全く反応がない有様だったからだ。

 まともにコミュニケーションが取れない一員であった私は、情けない気持ちで一杯になった。そんな光景が数年経ってまた繰り返されたのである。

発注者に食費補助、下請けは自腹

 宴会を楽しめなかった話の次に、社員食堂で感じた不満を書く。「飲み食いの些事になぜそこまでこだわるのか」と思う読者がいるかもしれないが、SEやプログラマーとして2次請け、3次請けの現場をはいずり回っていた当時の私の心境を示す一例なので、ご容赦いただきたい。

 私が配属された開発現場には、社員食堂があるところが多かった。火事場への短期派遣はともかく、一応開発を受託したということで行った現場はそれなりの人員を抱えるオフィスが多く、社員食堂も立派であった。何度か述べた会計サブシステムの開発現場においても、別のビルに社員食堂があった。

 昼食の時にはわざわざ作業場所のビルを降りて、別ビルに出向くことになるが、高い階にあったその社員食堂の見晴らしは素晴らしかった。もっとも見晴らしの良い席は発注者の社員が占領しており、下請けの我々は空いている入口近くの席に座るのが常だった。

 それでも、その食堂は清潔な雰囲気で、昼食の日替わりメニューはどれもおいしく、快適な食事の時間を過ごすことができた。社員食堂があることにより、「昼飯をどうしようか」と思い迷わなかったのはありがたかった。

 ところが、あることで明確な立場の違いを改めて認識させられた。食事の精算をする際に発注者の社員が使うプリベイトカードは我々が購入したものと若干レイアウトが違っていた。それは食費を補助するため、支給された精算用プリペイドカードだった。昼食代の自己負担はほとんどなかったようだ。福利厚生がきちんと充実していた証であろう。それに比べて我々は自腹でプリペイドカードを買っていた。私が当時所属していたソフトハウスは食費の補助など考えたことすらなかったに違いない。

 発注者と我々のような事実上の派遣者では置かれた立場が違うので、当たり前といえば当たり前の話であるし、そこまでひねくれることもなかったと今にしてみれば思う。だが当時は、自分の懐具体が寂しかったことも影響したのかどうか分からないが、給料が高く、その上に食費の補助まで受けている相手に対し、「そんなにレベルが高い仕事をしている訳ではないくせに……」という不満をいだいていた。

鼻についた「下請けの気持ちが分かるような素振り」

 当たり前で仕方がない、しかも些細といえば些細なことにいちいち不満を持つようになったのはいつからだったろう。思い返してみると、最初の現場であった大手生命保険会社に派遣され、そこで業界の下請け構造を思い知って以降、そうなった気がする(最初の現場については(『「新人なのに経験者」、偽の職歴で売られた話』を参照)。

 そのきっかけを作った生命保険会社の情報システム部門のプロパー社員は恰幅がよく、関西弁かつ大声で話す人だった。我々に仕事を出しているお客さんであり、悪気は何も無かったはずの彼には失礼な話だが、我々は彼が苦手だった。

 一つの理由は彼なりのコミュニケーションの取り方だったのか、我々下請け対して常に“ため口”をきいたことだった。明らかに自分より年上であってもため口だった。私は彼より年下であったのでその点はさほど気にならなかったが、彼が下請けの気持ちが分かるような素振りを見せることについては鼻についた。

 彼がたまたま、我々が休憩している所に入ってきた時、我々が週末の競馬予想をしていると必ず話に入ってきた。机に置かれたスポーツ新聞を手に取り、空いている椅子にどっかり座り、自分なりの予想を大声でまくしたてた。プロパーの彼が我々の作業場所まで来てコミュニケーションを取ろうとしている以上、相手をしない訳にはいかなかったので仕方なく話を合わせていた。

 どうしてそれを「素振り」だと決め付けたのかと思われるだろうが、普段はため口をきき、仲間のように接していたくせに、都合が悪そうな話になると彼がすっといなくなることが何度かあったからだ。体格がよいのに、こういう時の逃げ足は速いなと思ったものだ。

 その彼が、社員食堂の日当たりのいい場所で他のプロパー社員と大声で笑い合っていた姿を日の当たらない片隅の席から見たとき、面白くない気持ちになってしまった。もちろん、自分の会社の社員食堂で同僚と話をしているのだから、何をしようが勝手なのだが、間借りしている派遣プログラマーの私からすればとてもまぶしく見えた。ここまで書いたので、かまわず付け加えておくと、その社員食堂でもプロパーには食費の補助があり、私は全額自己負担だった。

 当時は働いても、働いても薄給であったため、なにかにつけて出て行く金が多いような錯覚にとらわれていた。今にして思えば、負け犬根性から来る考え過ぎであったわけだが、当時の正直な気持ちである。

「回りを自由な風が吹いていた」

 自分自身に対して歯がゆい思いをし続けた派遣SE、派遣プログラマー時代であったが、今思い返すと、懐かしい気分になる面もある。それは、肉体的あるいは精神的に圧迫された時でさえも、私の回りを自由な風が吹いており、その自由な風を感じることもできていた気がしたことだ。現場をたらい回しにされ続けていたにも関わらず、である。

 そう感じた理由は二つあったのではないか。私の場合、大した力は無かったが、それでも技術で生きている、自分の腕一本でやっている、という自負があった。それから企業組織にとらわれることなく息ができていた。私はソフトハウスの社員だったが、勤務場所は常に社外の現場であったし、社員のことはほとんど何も考えていないような企業だったから、逆に組織内にいる息苦しさは感じなかった。

 その後、私はソフト開発の業界から足を洗い、いわゆるユーザー企業に就職して今日に至っている。組織人の一員になった後には、あの当時感じた自由な風を感じることはなくなった。転職には満足しており、あの世界に戻りたいわけではないが、幾多の苦い思い出とともに、あの風を懐かしく思うこともある。

 短期の現場を体験した後、私は地獄のようなプロジェクトに配属されることになる。その体験から、私は派遣のSE・プログラマー仕事から足を洗うことを決めた。次回以降、地獄について書いていきたい。

赤 俊哉 (せき としや)
1964年生まれ。ソフトハウスでプログラマー、SEとして従事した後、サービス業の情報システム部門に転職。全社の業務改革、データ経営の推進、データモデリングとプロセスモデリングなどに従事し、現在はIT戦略の策定を担当。現場の視点にこだわりつつ、上流工程におけるコミュニケーションのあり方を追求している。2016年3月、『ユーザー要求を正しく実装へつなぐ システム設計のセオリー』(リックテレコム)を出版。