読者です 読者をやめる 読者になる 読者になる

富士通にソフト開発職で入社して2年目くらいまでのこと

こんばんは tnaotoです。

気がつけば3本目のネタですが、一応これでラストです。

本当はこの2年目で終わるつもりだったんですが、2年目ネタを温存して

キャッシュのネタを書いて先に出しました。

tnaoto.hatenablog.com

反響

週明けて、10年過ぎたブログを社内でいろんな人から読んだよ〜と声をかけられておりますが、相談等の連絡はありませんでした。

お叱りのメール等も今のところ来ておりません。

昔は、超能力の研究とかやってて、気功師にセンサー付けて観測したり、地震予測だーなんて言って関東上空にセスナ飛ばしまくったりしたんだよ〜

なんて話を聞いて、だいぶ自由な世界だったんだなぁと思いました。

そんな話が聞けるのも大きな会社ならではなんですかね。

さて、今回は僕の配属から残業100時間超えになった時くらいのお話をします。

はてぶコメントに運が良かったとか、こいつは特殊解なんて書かれていますが、そういった面は確かにあるかと思います。

ですが、僕が配属後半年で4人の上司を転がり、その4人目になった当時の課長はパワハラの塊みたいな方で、

電話でいつも怒鳴り散らしているような人でした。

導入研修

僕の世代は、比較的研修が長かった時代です。

入社して2ヶ月は、職種関係なしの導入研修でした。

ビジネスマナー研修や合宿研修、工場研修(僕は福島のFIT:富士通アイソテック)で、

ドットインパクトプリンタの製造ラインに経っていました。

www.fmworld.net

いわゆる、銀行で通帳に記帳するときに、「ブィーン」って聞こえるアレです。

伝票等をカーボン紙で挟み印刷することで、コピーを取りながら印刷するようなイメージのものです。

これらの研修の最後に発表されたのが、ソフト開発職への配属辞令であり、

同時に「山奥の工場」への転勤でした。

この「山奥の工場」での研修は、主にソフト開発職としての基礎研修でした。

独習Cや独習Javaを使ったプログラミング研修から、OSやネットワークの基礎、

サーバ機を使った実機研修を行い、その後グループ演習を1ヶ月半くらいかけて行い、

ウォータフォールの工程に従ったものづくり研修を行いました。

仕様書作成からコーディング、テストなどすべてを実習。

途中、講師に「この研修の意味が分かりません」と噛み付いたこともありました。

若気の至りですね。 反省は・・・していませんが(笑

その後、全員が約4ヶ月のソフト検査部門研修に入りました。(ここでさらに転勤が発生した同期もいる)

ソフト検査

富士通のソフト開発の現場には、一般的にはあまり馴染みの無い「検査」という工程があります。

海外グループ会社からも、「kensa」という言葉で認識されています。

これは、開発したソフト製品を「第三者検証」にかけることで、開発が気がついていないバグを

お客様に渡す前にチェックするという作業になります。

このチェックを合格して、初めて出荷ということになります。

ソフトウェアは無形物なのに出荷というのは、慣れないととても違和感のある表現ではありますが、

記録媒体に入れて渡されるため、まぁそんなもんかなって感じです。

この検査部門に、製品開発を行う前に配属されて、検査が見る視点や取り組みなどを学びました。

後から気がついたんですが、この時、頼まれていた雑用の1つでメインフレームに触れていました。

Javaアプレット上に、いわゆる「ダム端」をエミュレートしたもので、

そこからファイルを印刷し、大型の印刷機に取りに行くという作業でした。

メインフレームの検査をやっていたわけではなく、たまたま同じグループになった人が

そっち系の仕事していたから触れることがあっただけですが、大型サーバの実機を

見せて頂いたり、箱ものが好きな自分にはいろいろ楽しかった思い出です。

そいえば、ドラムロールのHDDとかも見ましたね。

配属から最初の半年

そんな長い研修を経て、配属が発表されたのが12月22日(金曜日)くらいだったかと思います。

当時は、「山奥の工場」にいました。

そのまま山奥の工場への配属になると思っていた自分は、車等を買ってしまっていたのですが、

渡された辞令は、新横浜への転勤。引っ越しは翌日。出社は週明け。

なんとも無謀な引っ越しです。そして、車・・・

まぁこのあたりはなんとかいろいろ駆使してこなし、月曜の出社を無事に迎えました。

ちょうど年末でしたので、すぐに正月休みに突入。

年が明けたら・・・部署が無くなり、上司が変わっていました(笑)

「あれ?電話取っている人が言っている部署名違う」と思って、

目の前にいた管理職に聞いたら、「あー変わった。上司は今日から俺ね」という

すげーラフな感じで、上司が変更となりました。

担当製品は変わっていなかったので、そのまま続行となりました。

担当製品は、「基幹バッチシステム基盤」

www.fujitsu.com

これの、バッチ受付機能のチームでした。

実行ランタイムのチームではなかったので、COBOLと触れ合うことはサンプルアプリくらいでしたが、

いろんな機能が密にくっついており、コードを見ただけでは中の構造を

把握するのは無理っていう巨大な製品でした。

「なんかすごいとこ来ちゃったなぁ」なんて思いながらも

面白い先輩が指導役として付いてくれたおかげて苦ではありませんでした。

そんなこんなで4月を迎えたとき、関西方面に居たリーダが課長に昇進しました。

そしてチームが、4拠点に分かれていたものも関西に集約することとなりました。

あー、転勤かぁと覚悟を決めていたら、製品開発だけ集約され、僕は違うプロジェクトに移ることになりました。

運命の出会い

プロジェクトが変わりましたので、製品も変わりました。

www.fujitsu.com

はい。まだCOBOLです・・・今度はオンライン基盤。

しかし、僕はそこに関わる事無く、この製品が抱えるとある機能を兄弟製品に提供するための開発に関わることになりました。

そこの課長が、上にも書いたパワハラの塊のような方でした。

2年目と2ヶ月くらいの頃だったと思います。

右も左も分からない状態で、いきなり「○○を作れ」という指示だけが来ました。

その機能がどこにあって、どんな機能なのかも分からずな状態でした。

今でも当時のそれがなんだったか分からないですが、データベーススキーマをなんとかする的なものだったかと思います。

「作業指示は、○○(関係会社の担当者)に聞け」というだけで、出張にいかされ(飛行機にのって移動するレベル)、出張先で僕のスキルを聞いた担当者は、僕では不適と判断し、当時の上司に回答しました。

帰ってきて言われたことが、「はぁ?データベースが分からない?windows上で開発したことがないだと?」みたいな感じでした。

僕は粋がっていましたので、「無いものはない。分からないことは分からない」とほぼ逆ギレ的な対応をしたような気がします。

このあとも「XMLが分からない」と答えれば、名前も聞いたことがない人を挙げられ、聞いてこいと言われる始末です。

しかし、このやりとりからハッキリものを言い、戦う姿勢が徐々に作られていきました。

僕は、自分で手をつけたものを投げ出すのが嫌いなタイプですので、文句は言いながらもきっちりやっていました。徐々に残業はひどいことになっていましたが・・・。

こんな感じでパワハラ上司に耐えながら最初の開発(Linux/Solaris向けのセットアップ系コマンドのwindows移植)をやっていました。

言語は、CとJavaのハイブリッドでした。

win32APIでcreate_processとか、Ctrl+Cで動作キャンセルする場合のシグナル処理なんかも、初めてここで学んだ気がします。

そいえば、「Javaでやれ」みたいなコメントもありましたが、javaでもプラットフォーム向けに切り分けを仕込んだりしてました。

とまぁ、こんな上司を嫌う人は多かったのですが、なぜか呑みの場ではいい人で、サシで飲みに行くほどな関係でもありました。

相互理解と信頼関係

僕はこの上司を見て、接し方というものを学びました。

この上司は、嘘や見栄を張ることや周りくどい説明が大嫌いなタイプでした。

また、確かに言葉は悪いが、正論を言っているということに気が付きました。

それらに気がついたあとは、誇張や推測なども止め、事実だけを述べることに徹しました。

そして、意見を求められたときだけ、「僕はこう思う。こう考える。なぜならこうだから」と

答えることにしました。すると、言葉は悪く威圧的な部分は変わりませんが、それ以上の圧力みたいなものは感じませんでした。

このあたりをしっかり言ってなくて、のらりくらりする人が思いっきり怒られているということに気が付きました。

これが、100時間超えの残業をしても、「責任は取るから、やり遂げろ」という前回のエントリーに話が続いていきます。

この時は新規製品の開発をやっていて、コマンドは他からの流用も多少ありましたが、ほぼスクラッチ開発でした。

この製品のマニュアルがこれ。

http://software.fujitsu.com/jp/manual/manualfiles/M100004/J2X17456/01Z201/J2X1-7456-01.pdf

動作メッセージやマニュアル作成なんかもやっています。

セットアップから操作系コマンドまで作ったコマンドは15個くらいでしょうか。共通モジュールやら設定ファイルの処理やら、コマンド引数のパーズからコマンド間の排他処理なんかをC言語で実装していました。

mallocやmemsetで領域の過不足がよく発生し、「なんで、Intel(x86)とItaniumでは問題ないけど、SPARCだけコアダンプするのー?!」みたいなことよくやってました。

この時に、gdbの使い方やステップ実行デバッグなんかのやり方を学びました。

夢の中でステップ実行して見つけたバグが、実際に同じものがあったなんていうこともありました。

残業時間は確かにブラックな域ですが、これをやりきったのも上司の信頼を得た結果の1つではないかと思います。

上で述べた「検査工程」では、バグを出す事もなく、お客様先で障害を出したこともありませんでした。

また、上司の信頼の他に得たものは・・・「体重」ですね。

タバコを止めたのも重なって1年で10kgも太りました。

自分の仕事が生む価値

残業時間はほぼ武勇伝ですが、これだけの給与(残業代)を貰って作ったものが、お客さま先で稼働して意味を成す。

エクセルでも書いたコードでもなんでもいいですが、それが売上にどれくらい貢献したかを考えたことがあるでしょうか。

会社は払った給料以上に、人件費、開発費がかかっています。

この時いきなり売上が上がって・・・みたいなことは無く、

後の別の仕事で、この時自分がもらった給料分はペイできたかなって思っています。

どこでも生きるスキル

はてブコメントで、頭の良さみたいなことが言われていました。

僕は東大や早稲田、慶應みたいな高学歴な人でありません。

偏差値50前半くらいで、大学院の実績もほぼないような大学の理学部出身です。

運で生きていると言われれば、否定は出来ません。

しかし、上記で述べた上司から言われた言葉がずっと響いていてそれが残っているからだと今でも思っています。

富士通でしか使えない資格(スキル)を身につけることはない。社外資格(OracleやMSなど)を取ったほうがよっぽどいい」

当時は、ふーんとしか思っていませんでしたが、今はとても響く言葉です。

これは、富士通が仮に倒産した、退職しなければいけなくなった場合に、生きる場所が得ることが出来るからです。

「管理職やってました」って一言を聞いても、実際何が出来るか分かりません。

エクセル開いて数字叩いて、人の管理だけやってても、それは他では使えない存在です。

僕はそんな風にはなりたくないなーなんて思いながら、会社生活を送っています。

なので、出世には縁がなく、勿体無いと言われることもあります。

自らアピールする昇進・出世にはあまり興味はなく、評価されて上げて貰えるなら嬉しいですねって感じです。

名声とお金は欲しいですよ?

富士通にはない部分を生きること

すでに誰かがやっていることなら、その人が専門家なのでその人がやればいい。と考えています。

何かを率いてプロジェクトを進める的なことも断っています。

理由はいくつかありますが、出来なくはないですが僕には向いてないと思っているからです。

相談やコンサル、アドバイザーみたいなことは求められてばやっています。

僕は貰っている自由という特権を使って、富士通に足りないことをしようと思っているからです。

例えばこのブログもその1つなんじゃないかなんて思っています。

こんな記事を個人特定出来る状態で書く人は他にはないですからね。

他には、

勉強会に会場を貸す-> 人が必要なので人(若手)を借りる

 -> 彼らに世間を教える -> 自発的に勉強会に参加する、興味を持つ

みたいなことをしています。

自由という難しさ

会社生活での自由は、とても難しいです。

誰かに決めてもらった仕事をするのは、忙しくても何をすればいいかわかっているから

答えやゴールはあります。

しかし、何をしてもいいということは、何も決まっていないということです。

自分がやっていることが正しいのかすら分かりません。