富士通に入社して13年が経った
富士通退職エントリーが話題な時期となってまいりました。
新卒で入社して13年が経ちましたが、いまだに在籍しております。
前回の記事から3年くらい経ったので、その差分でも書いてみようと思います。
2016年
富士通研究所では共通インフラとして開発環境整備が行われており、研究員全員が使えるGitHub Enterpriseの導入を仕切っておりました。 2019年現在でも、GitHubEnterpriseは利用されております。 もちろん富士通のクラウドサービスを活用しております。
この導入に関し、富士通事業部やGitHub社と連携し、海外カンファレンス(GitHub Universe)に参加させていただくなど初体験のことがありました。 これらの活動から、富士通の職位で一般最高位であるプロフェッショナルプロダクトエンジニアの取得やスクラムアライアンス認定スクラムマスターなども取得しました。
デブサミでこのあたりの話しようかと思って応募したけど、見事に落選しました(2019年の話)
2017年
K5 GitHubサービスのリーダを拝命し奔走しました。 ここには書けないようないろいろなことがありましたが、SEの仕事の進め方でのお仕事を初体験しました。 （プロダクト系ソフトウェア開発、研究職、SE職と社内転職多数） 前半はチームの立て直し、サービスの立て直しを中心に行い、後半は（社内としては）大きなサービスエンハンス（メニュー追加）や商談対応（スーツ着て客先）なんかもしました。 営業さんに、研究所だったんですか？？と疑問に思われるような立ち振る舞いだった模様
あとは、GitHub Constellation Tokyoに登壇したり、OpenStack Days Tokyoでパネルのモデラーやったりなんかしました dev.classmethod.jp cloud-direct.jp.fujitsu.com
2018年
主なトピックとしては、育休4カ月を取得しました。 男性の育休がまだまだな世の中での育休取得は、手続きも含めいろいろ面白かったです（イレギュラーいっぱいで） また、育休を取得して思ったのは一人目の時になんで取っておかなかったのかぁというところです。 男性のみなさん、仕事が抜けられないとよくいいますが、それは言い訳ですからね。
ちなみに、育休給付金がありますので給料面では心配は不要ですよ！ 13imi.me
どっちかといえば、休むより復帰のほうが大変です。4ヶ月の休暇はマジでポンコツになります。 反面、体は肩凝り知らずの健康状態になります。まじメリット。 もちろん遊んでいたわけはなく、3食用意し、掃除洗濯買い物すべてやっておりました。 幸い、育休中に上の子が赤ちゃん返りすることもなく無事に終えたわけですが、むしろ復帰してから一気にきたようで奥様が毎日発狂しております。
復帰後の上司がスパルタな方でしたが、関わったプロジェクトはきっちり形にできたので、上司の指導のおかげかなと思います。 世間では弄られキャラですが、仕事人としてはマジすげぇ。どうやっても追いつけません。
2019年
保育園落ちた。
育休した影響で、在職日数が足りず、また復職後の予定時間ではダメということでランクが落ちてしまいました。 いやーこのときばかりは復帰のタイミングを見誤ったなぁと大変でした。 幸いにも2次募集で追加枠が出来て、無事に上の子と同じところに入ることができました 横浜市の待機児童0はまじ詐欺的な勘定なので、興味ある人はぐぐってください（無いと思うけど）
現在
2019年4月から、富士通クラウドテクノロジーズに出向して、ニフクラのストレージ系のサービスに関わることになりました。 引き続き、富士通の中にはいるようです。
ニフクラよろしく
さて、お待ちかねの冒頭に出た退職ブログにアンサーしてみようと思います。
＃いっぱい書いたんですが、かきすぎたので削っています。話飛んでたらごめんなさい
＞開発環境がダメ
たぶんお持ちだったパソコンは、従業員に一括配備される事務機ですね。開発機ではないです。 もっとも、開発機をくれない部署もあるのでそれを事務機兼用で使っているのは事実ですね。 また、察するに開発系の部署ではなくSI系の部署で、かつ、開発系SEではなくフィールド系ではないでしょうか 配属ガチャ失敗の可能性はあります。これはなんとも言えません。。。 私は最終的には、MBP15、メモリ32GのWinノートPC（U728）、DELL31インチ4Kなんかを持っていました。 あとサーバ数台。このあたりは、立ち回りと購入稟議をどうやるかって感じな気がします。 まぁ、若手には何それって言われそうですが、黙っていても誰もくれないので策を練りましょう（その機器が必要な理由）
＞机上環境
これがよくわからないんですが、工場ラインを事務所にしたところで、かつ、SI方面ってどこだろうという 私もあまりわからない感じですが、机が狭そうなので、昔の事務机を転用した古い建屋っぽいですね おそらくどこかのお客様のプロジェクトに投げ込まれてしまったのではないでしょうか
2人掛け机に3人とかたまに見かけますが、大抵は炎上が始まって人が投入された現場ですね。。。 もちろんSIの現場です。
＞成果評価
若手の頃は正直見ている範囲が狭いので、成果と言われてもなぁという印象。かくゆう自分も最初5年は井の中の蛙だったと思います。 結局、自分のプロジェクトや上司以外が、自分を認識できているか（活躍していたかをアピールできるか）なので、 言われた仕事だけしていても評価はされないですね
まぁ年功序列でランクが上がらない（上げようとしたけど前詰まってて無理だったごめん って言われたことはあります）
＞古い方法へのこだわり
＞＞何かがうまくいかなかったときに「なんで開発標準に従わなかったの？」という責められ方をする
これは、説明の仕方が悪いとしか言えないかなぁ、内容が古いっていうなら新しいものを定義して説明すればいい もちろんしたのかもしれないけど、これだけだと説明してないのでわからないけど SI文化の中で明確に従わないって宣言して、バグ出したけど、ちゃんと直してテストして見解を書いて説得すればいい 試験してバグ1件というのも、どんなテストをしてなぜ1件でよいのかを説明してないように思えます。 ソフトウェアに対する品質の考え方を理解してないと、お互い噛み合わないんじゃないかなぁと思います。 もちろん指摘してきた人も経験則で語っていて、うまく説明できないのを誤魔化しているような気もします。
＞新しい方法、なんちゃってアジャイル
SIの世界は、決められた金額で決められた成果（納品）をするのが基本なので、ふわふわした要件をきっちり固めるのが得意な人は多くいても、要件を走りながら決めるのは得意ではなかったのが実情かと思います。
もちろん得意な人や部署もあるので、一概には言いきれないです。
大企業のSEはレベル高いよ。上がしっかりしてないのに商談まとめないといけないんだから下手な社長より能力がいる。反面技術で仕事する業界ではないので若いSEみてるとスキルの低さばかりが目についてアレ
— 令和うまれの恐竜 (@gachacomplete) 2019年4月6日
ちょうどこんな発言をしている方を目にしたのですが、まさにこんな感じです。
＞残業と給料
これってどうなんですかね、残業しなかったらそんなもんでは？ いまでこそ働き方改革とかいってますが、残業青天井でやりたいだけできるみたいな側面もあるので 見込みだったり上限10時間と言われるよりはエンジニアとしては幸せな部類な気もします。ちゃんと残業代出るし。
＞異動
僕はリーダ時代は、1on1して、やりたいことをちゃんと聞いて調整したりしたので、場所によるんですかねぇ。。 この4月からのニフクラ異動も、自分で決めた部分があったりします。
＞社外技術
まぁ無い人はないね。無くても仕事はできちゃうし。 そこらは割りきっていくしかない部分はどうしても大きいとこだとあるかなぁと思います。 相手に期待しすぎないこと大事
＞フレックス
8:50から12:00は、過去の経験からそうなっていたんですよね（制度的に一律の設定しかない） 昔は10時だったのですが、みんなこなくて段々早くなっていったと聞きます。 これは、お客様のシステムが稼働しているのに富士通の従業員がいなくて、問い合わせに答えられなかったことが多発したからと私は聞いています。サポートも通常契約であれば8時半から稼働しています。 社会システムを担っている以上、それは念頭においておくべきかと思います。
いまは、働き方改革の影響もあり、部署次第ですが11時-12時がコアの部署もあるようです。 ちなみに、午前にしかコアがないので、半休を取ると午後の出社時間が何時でもよかったり（！）、午前のみで帰れたりします。（あんまり気がついている人がいなかったりしますが。）
ちなみに、裁量労働でも大体定時に来ることが望まれていますね。もっとも会社こないと仕事終わらないわけですが。
＞未来のほの暗さ
未来は、自分で作れとしか言えない。 退職する後輩を何人か背中おして送り出しているので、残るも出て行くも自分で考えればいいと思います 暗いと思うなら、明るいとこに行けばいい。それだけのことです
https://twitter.com/diceken/status/1115380432143437824?s=21
エアリプいただきましたが、ぼくがリーダでメンバーみる必要あるときは、毎月1on1してました。
2年目なんかはキャリア像を持ってない人が多いようで、 どうなりたいかを今の得意不得意と照らして考えていました。
若手6年目くらいの子は、無事にリーダとしてまとめられるようにはなったかと思います(育休で抜けたあとをお願い)
長くなってしまいましたが、この辺で。 このエントリーが消えたら、お察しください。
そいえば、このエントリー書いた日が誕生日だったので、お気持ちお待ちしています
https://www.amazon.jp/hz/wishlist/ls/DECO20OW54TZ?ref_=wl_share
MacBook Pro 2013 lateのバッテリーを交換した
気がつけば今年で５年になるMacBookProのバッテリーを交換した。
ふと、トラックバックが重く、反応が鈍くなったと感じた 会社の端末が最近2017のMacBookPro15インチになったので、そのせいかなと思ったのだが、 ぐぐってみると、同じモデルでバッテリー膨張しているという話が昨年くらいから ちらほらあったようだ
クラムシェルで使っている期間もあったので バッテリーの充電回数が200回に達していなくても過充電と経年劣化で膨張してしまうようだ。
修理が困難を極めるというMacBook Proなので、潔くAppleリペアサービスを頼むことにした すでに5年も経っているため保証は無いが、バッテリーの交換サービスがある。
Apple 修理サービス getsupport.apple.com
しかし、iPhoneのバッテリー交換のようにポチポチすれば荷物のお迎えが来るわけでもなく、 そもそもバッテリー交換したいという案内がどこにも無い
そのため、「ハードウェアの問題」から「バッテリーに関する質問」を選択する。
ここで簡単に聞けそうなチャットサービスは、保証が切れているため繋がらない （なのに、待ちが数分ですと出るのはどうなのか・・・ログインしている状態で）
引き上げ修理にしてもらうには、「後日電話したい」を選択する。
そうすると、受付番号が発行され、それをサポートに電話するときに 電話口でポチポチすると、名前から希望するサポート内容まで伝っている状態からスタートする。
今回電話してみてわかったのは、担当者につながるのが早い。 よくある接続していますの状態（課金されている）で数十分待たされるサービスがよくあるけど、 Appleの場合は、ほんの数秒だった。
電話では、バッテリーの状態などが聞かれ、必要に応じてハードウェアテストの実施があるようだが 自分は事前に実施していて問題なかった旨を報告しただけで終わった。
今回、火曜の夕方くらいに電話して、水曜の18時以降のピックアップになり、土曜の午前中には返ってきた。
登録してあるメアドに、リペアセンターの到着から案内が来るのだが、木曜の午前中に到着の連絡があり、 金曜日の午前に修理開始て、午後に完了発送となっていた。
箱は新品ではなかった。 おそらくピックアップ時に使ったものなのだろう。 ピックアップ時には、裸のままヤマトの配送員に渡すだけでOKだった
中身はこのような感じで梱包されていた 包むだけで中空になり固定されるシートに包まれていた。
バッテリーの交換に伴いトップケースとバッテリーを交換したと書いてある。 5年使ってキートップと筐体に擦れが出ていたが今回にバッテリー交換によって 新品になって返って来た
これで総額2万ちょい
これを売って新型を・・・とちょっと心揺れたが、 新しいの買ったつもりでもう暫く使って行くこととしよう
富士通がAdvent Calendarに参加することになった理由
これは、
FUJITSU Advent Calendar2日目の記事です （はてブコメント付いて気が付きましたので追記しました。ありがとうございます）
急遽12/1の夕方に決まって始まったばかりで、どんな経緯だったかと少し 技術的内容じゃないって突っ込まれそうですが、大目に見てもらえることを期待して・・・
あと、これ書いて置かないと、社内からも何してんの？って内部から刺されるのでご理解をｗ
Qiitaのadventじゃなくて、adventarで良かったんじゃないかとも思いつつ
さて、始まって２日目ですが、すでに一日目がツッコミを食らっていたりしますね
富士通にアドベントカレンダー知ってる人なんていたんだな / “Fujitsu Advent Calendar 2016 - Qiita” https://t.co/z154mlNTZ3
— よしなに (@hiragram) 2016年12月2日
と思ったらQiitaの使い方は全然分かってないっぽい Advent Calendarに初参加する on @Qiita https://t.co/9rf0c4QDit
— よしなに (@hiragram) 2016年12月2日
まぁ富士通の認識なんて世の中からすればそんなもんですよね。否定はしません。
富士通社内でもAdvent calendarは認識されています。 2015年から社内でカレンダーはやっていましたが、１枚のカレンダーを埋めるのが精一杯だったような気もします
引き続き、今年もカレンダーを分野に分けてやってますというメール等が流れていました。 が、今年は閑散としていて１人も人がいないような状態なものもあり・・・。
元々は、ソフト系エンジニア（not SE部門）発の取り組みなので、活動の認識が狭いのも１つの要因かもしれません。
まぁそんなカレンダーですが、二フティさんを始め他社はやってるよーなんて話は上がっていましたが、
結局のところ社内で何書くの？って感じだったわけです。
技術の話を書くとして、それは製品開発で得た知識なのか、趣味で調べたものなのか。
特に後者であるならば、なぜわざわざ社内に書かなきゃいかんのか。
そんなことを思っていた僕は、以下のようなメールを投げました。
たかはしです 社外の富士通advent calendarだったら書いてもいいかなーと思うけど 社内のadvent calendarだったら別になーって思うのは僕だけですかね
そしたら、外部に書くには事務手続きがうんぬんという話が出て、 やれ、該非判定だの社外公開手続きだのって話になってしまいました。 それらがめんどくさいから、社内でやるんだと。
そうじゃないと思うんだよなーと思いながら、ちょっと若いのと社外で活動する楽しさって何かねーって会話をしてたんですが、
身内じゃない知らない人に認められるのが嬉しい OSSの場合人に使ってもらえることが嬉しい 技術的に社外の方がレベルが高くておもしろい
こんなことを言われてハッとしました。
僕自身は、まぁ好き勝手にやっているのでほぼ無自覚無意識だったのですが（いいのかそれ）、
改めて文字でもらうとそうだよなーと思いました。
OSSやコミュニティじゃないですが、情報は発信するところに集まると僕は思っていて 情報クレクレくんが多いと発信してるほうはつまらないと思います。
社外に記事を書いたり発表したりすると、情報が繋がったり、人脈が増えたりして 違う世界が見えて、人としても、エンジニアとしての技術の幅も増えたりすると思っています。
しかし、社内で発信する立場を取ると、こう回らない現状があります。 社内での経験や認知度が増すと、
・言ったからには責任を取れ
・言ったんだからお前がやれ
みたいな悲しいことになってしまっています。
個別にメールが来て、心痛くなるなんてことはザラです。
これは悲しいと同時に、実は社内でカレンダーやるほうが敷居が高いのではないか？という仮説が生まれました。
失礼ながらQiita等で記事を書いたとして社内よりは匿名性が高い。いきなり刺される心配もないと思いました。
そんな議論や批判が飛び交う中、突然「QiitaやAdvent Calendarってソーシャルメディアなんじゃないの？」っていう 解釈が飛んできました。
さて、富士通はいわゆる大企業。最近いろいろ話題になった大きな会社もあったので、「あ〜またダメな布石か」と 思いながら、添付されたURLを開きました。
そして、飛び込んできた１行目に驚愕しました。
ソーシャルメディアを利用する場合のルールとマナー 近年、ソーシャルメディアに新しい機能が次々と組み込まれ、その利用者が拡大しています。ソーシャルメディアは、複数の利用者間でのコミュニケーションに非常に有効であり、富士通グループとしても積極的に取り組むべき領域です。
( ﾟдﾟ) ・・・ (つд⊂)ｺﾞｼｺﾞｼ (；ﾟдﾟ)？！
もう何かのギャグかとｗ
もちろん、このページには利用する上での注意等が書かれていました。
がしかし、これはあくまでガイドライン。最終的にこれを問題ないというのは誰なのか。これが一番の重要ポイントでした。
社内教育を担当する部門は、結局は個人判断ですって言うので話になりません。あと一歩なのに。
「俺が責任取るからどんどんやれ」みたいなカッコイイ人は居ないのかなぁなんて会話をしていました。
今年は無理かなぁ、このあたりを議題に来年なのかなぁと議論していた人たちは意気消沈しかかかったところに、
○○の○○です。（いわゆる執行役員） ソフトエンジニアが社外発信するとっても良い機会なので、 僕は大賛成です。社内SNSガイドライン的にも問題ないよう に思います。ぜひ、今年からやりましょうよ。
突然のカッコイイ人登場
そこからの社内の行動は早かった。。 僕はかっこいい人登場のときには打ち合わせに出ていたのですが、 やりましょうから２時間以内で、カレンダー作って始まっていました。
最近バズってた「SIerにSlackを導入した」ブログがありましたが、 内圧が上がってしまっていのではないかという実情を見た気がしました。
小野和俊のブログ:SlackをSIerに導入した話。そしてSIerの未来
現在の富士通グループでは、社内規定によりSlackの単体導入はNGとなっていますが、 今回のような話をきっかけに、世の中のスタンダードをどんどん取り入れていきたいと思います。
それが、自分たちの体験こそが知見ノウハウであり、お客様のビジネスをよりよくするための糧になると私は考えています。（個人の見解です）
富士通にソフト開発職で入社して2年目くらいまでのこと
こんばんは tnaotoです。
気がつけば3本目のネタですが、一応これでラストです。
本当はこの2年目で終わるつもりだったんですが、2年目ネタを温存して
キャッシュのネタを書いて先に出しました。
反響
週明けて、10年過ぎたブログを社内でいろんな人から読んだよ〜と声をかけられておりますが、相談等の連絡はありませんでした。
お叱りのメール等も今のところ来ておりません。
昔は、超能力の研究とかやってて、気功師にセンサー付けて観測したり、地震予測だーなんて言って関東上空にセスナ飛ばしまくったりしたんだよ〜
なんて話を聞いて、だいぶ自由な世界だったんだなぁと思いました。
そんな話が聞けるのも大きな会社ならではなんですかね。
さて、今回は僕の配属から残業100時間超えになった時くらいのお話をします。
はてぶコメントに運が良かったとか、こいつは特殊解なんて書かれていますが、そういった面は確かにあるかと思います。
ですが、僕が配属後半年で4人の上司を転がり、その4人目になった当時の課長はパワハラの塊みたいな方で、
電話でいつも怒鳴り散らしているような人でした。
導入研修
僕の世代は、比較的研修が長かった時代です。
入社して2ヶ月は、職種関係なしの導入研修でした。
ビジネスマナー研修や合宿研修、工場研修（僕は福島のFIT：富士通アイソテック）で、
ドットインパクトプリンタの製造ラインに経っていました。
いわゆる、銀行で通帳に記帳するときに、「ブィーン」って聞こえるアレです。
伝票等をカーボン紙で挟み印刷することで、コピーを取りながら印刷するようなイメージのものです。
これらの研修の最後に発表されたのが、ソフト開発職への配属辞令であり、
同時に「山奥の工場」への転勤でした。
この「山奥の工場」での研修は、主にソフト開発職としての基礎研修でした。
独習Cや独習Javaを使ったプログラミング研修から、OSやネットワークの基礎、
サーバ機を使った実機研修を行い、その後グループ演習を１ヶ月半くらいかけて行い、
ウォータフォールの工程に従ったものづくり研修を行いました。
仕様書作成からコーディング、テストなどすべてを実習。
途中、講師に「この研修の意味が分かりません」と噛み付いたこともありました。
若気の至りですね。 反省は・・・していませんが（笑
その後、全員が約４ヶ月のソフト検査部門研修に入りました。（ここでさらに転勤が発生した同期もいる）
ソフト検査
富士通のソフト開発の現場には、一般的にはあまり馴染みの無い「検査」という工程があります。
海外グループ会社からも、「kensa」という言葉で認識されています。
これは、開発したソフト製品を「第三者検証」にかけることで、開発が気がついていないバグを
お客様に渡す前にチェックするという作業になります。
このチェックを合格して、初めて出荷ということになります。
ソフトウェアは無形物なのに出荷というのは、慣れないととても違和感のある表現ではありますが、
記録媒体に入れて渡されるため、まぁそんなもんかなって感じです。
この検査部門に、製品開発を行う前に配属されて、検査が見る視点や取り組みなどを学びました。
後から気がついたんですが、この時、頼まれていた雑用の１つでメインフレームに触れていました。
Javaのアプレット上に、いわゆる「ダム端」をエミュレートしたもので、
そこからファイルを印刷し、大型の印刷機に取りに行くという作業でした。
メインフレームの検査をやっていたわけではなく、たまたま同じグループになった人が
そっち系の仕事していたから触れることがあっただけですが、大型サーバの実機を
見せて頂いたり、箱ものが好きな自分にはいろいろ楽しかった思い出です。
そいえば、ドラムロールのHDDとかも見ましたね。
配属から最初の半年
そんな長い研修を経て、配属が発表されたのが12月22日（金曜日）くらいだったかと思います。
当時は、「山奥の工場」にいました。
そのまま山奥の工場への配属になると思っていた自分は、車等を買ってしまっていたのですが、
渡された辞令は、新横浜への転勤。引っ越しは翌日。出社は週明け。
なんとも無謀な引っ越しです。そして、車・・・
まぁこのあたりはなんとかいろいろ駆使してこなし、月曜の出社を無事に迎えました。
ちょうど年末でしたので、すぐに正月休みに突入。
年が明けたら・・・部署が無くなり、上司が変わっていました（笑）
「あれ？電話取っている人が言っている部署名違う」と思って、
目の前にいた管理職に聞いたら、「あー変わった。上司は今日から俺ね」という
すげーラフな感じで、上司が変更となりました。
担当製品は変わっていなかったので、そのまま続行となりました。
担当製品は、「基幹バッチシステム基盤」
これの、バッチ受付機能のチームでした。
実行ランタイムのチームではなかったので、COBOLと触れ合うことはサンプルアプリくらいでしたが、
いろんな機能が密にくっついており、コードを見ただけでは中の構造を
把握するのは無理っていう巨大な製品でした。
「なんかすごいとこ来ちゃったなぁ」なんて思いながらも
面白い先輩が指導役として付いてくれたおかげて苦ではありませんでした。
そんなこんなで４月を迎えたとき、関西方面に居たリーダが課長に昇進しました。
そしてチームが、４拠点に分かれていたものも関西に集約することとなりました。
あー、転勤かぁと覚悟を決めていたら、製品開発だけ集約され、僕は違うプロジェクトに移ることになりました。
運命の出会い
プロジェクトが変わりましたので、製品も変わりました。
はい。まだ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の使い方やステップ実行デバッグなんかのやり方を学びました。
夢の中でステップ実行して見つけたバグが、実際に同じものがあったなんていうこともありました。
残業時間は確かにブラックな域ですが、これをやりきったのも上司の信頼を得た結果の１つではないかと思います。
上で述べた「検査工程」では、バグを出す事もなく、お客様先で障害を出したこともありませんでした。
また、上司の信頼の他に得たものは・・・「体重」ですね。
タバコを止めたのも重なって１年で10kgも太りました。
自分の仕事が生む価値
残業時間はほぼ武勇伝ですが、これだけの給与（残業代）を貰って作ったものが、お客さま先で稼働して意味を成す。
エクセルでも書いたコードでもなんでもいいですが、それが売上にどれくらい貢献したかを考えたことがあるでしょうか。
会社は払った給料以上に、人件費、開発費がかかっています。
この時いきなり売上が上がって・・・みたいなことは無く、
後の別の仕事で、この時自分がもらった給料分はペイできたかなって思っています。
どこでも生きるスキル
はてブコメントで、頭の良さみたいなことが言われていました。
僕は東大や早稲田、慶應みたいな高学歴な人でありません。
偏差値50前半くらいで、大学院の実績もほぼないような大学の理学部出身です。
運で生きていると言われれば、否定は出来ません。
しかし、上記で述べた上司から言われた言葉がずっと響いていてそれが残っているからだと今でも思っています。
「富士通でしか使えない資格（スキル）を身につけることはない。社外資格(OracleやMSなど）を取ったほうがよっぽどいい」
当時は、ふーんとしか思っていませんでしたが、今はとても響く言葉です。
これは、富士通が仮に倒産した、退職しなければいけなくなった場合に、生きる場所が得ることが出来るからです。
「管理職やってました」って一言を聞いても、実際何が出来るか分かりません。
エクセル開いて数字叩いて、人の管理だけやってても、それは他では使えない存在です。
僕はそんな風にはなりたくないなーなんて思いながら、会社生活を送っています。
なので、出世には縁がなく、勿体無いと言われることもあります。
自らアピールする昇進・出世にはあまり興味はなく、評価されて上げて貰えるなら嬉しいですねって感じです。
名声とお金は欲しいですよ？
富士通にはない部分を生きること
すでに誰かがやっていることなら、その人が専門家なのでその人がやればいい。と考えています。
何かを率いてプロジェクトを進める的なことも断っています。
理由はいくつかありますが、出来なくはないですが僕には向いてないと思っているからです。
相談やコンサル、アドバイザーみたいなことは求められてばやっています。
僕は貰っている自由という特権を使って、富士通に足りないことをしようと思っているからです。
例えばこのブログもその１つなんじゃないかなんて思っています。
こんな記事を個人特定出来る状態で書く人は他にはないですからね。
他には、
勉強会に会場を貸す-> 人が必要なので人（若手）を借りる
-> 彼らに世間を教える -> 自発的に勉強会に参加する、興味を持つ
みたいなことをしています。
自由という難しさ
会社生活での自由は、とても難しいです。
誰かに決めてもらった仕事をするのは、忙しくても何をすればいいかわかっているから
答えやゴールはあります。
しかし、何をしてもいいということは、何も決まっていないということです。
自分がやっていることが正しいのかすら分かりません。
キャッシュコヒーレンシとジョブマッチング
こんばんは、tnaotoです。
前回のブログの反響がすごくて驚いています。
ビビって消そうかなーと思っていましたが、今のところ怒られてないので大丈夫だと思っています。
例のブログで”キャッシュコヒーレンシ”の話で、社内で何人かの方から情報を得て、いろいろ考える面があったので筆を取ってみました。
キャッシュコヒーレンシとは
簡単に言えば、マルチCPUの時のメモリとCPUキャッシュを一貫性を保つかみたいな話だと思います（専門じゃないので見ただけの話）
昨今では、マルチコア、マルチソケットのサーバ環境は手に入りやすいですが、
５、１０年前くらい前だと２ソケットくらいはありましたが、４ソケット以上になると
大型サーバ（Solaris,IA64など)やメインフレームのような汎用機の世界でなければ、そこまで一般的ではなかったように思います。
富士通とキャッシュコヒーレンシ
ちょっとググッてみたところ、特許公開情報がヒットしました。
確かに富士通では、研究開発が近年でも行われているようです。
例の彼はこれを見て、富士通への就職を決めたのであれば、残念なことです。
この出願者に会って話をする機会は無かったのかなと思います。
出願者でググれば、研究所の人だと分かる人が含まれています。学会やメアド直接アタックして欲しかったなーと思います。
研究所は、一本釣り入社が多いので、そのまま大学院での研究を発展していけたかもしれません。
ジョブマッチング
ここからは推測です。
おそらく、富士通としか書いてないから、富士通でソフト開発を目指せばたどり着けると思ってしまったのでしょう。
10年以上前に就職活動していた自分を全く同じ状況だなーと思っています。
そして、ジョブマッチング時にいくつかの選択ミスがあり、人事も本人もそれに気がつけなかったことがいろんな大失敗の原因でしょう。
ここから先に書いている内容は、私が選考を受けた10年前のものですので、現在は異なるかもしれません。
富士通への就職の道は、富士通への就活エントリを経験された方なら大まかに理解されていると思いますが、
応募の時点で、大きく３つの道（営業、SE、開発）が決まります。
選考途中で、強い要望と情熱で人事を説得しないかぎり、変更出来ないと思います。
自由応募でも学校推薦応募でもここは同じだっと思います。
そして、選考が終わり内定となった段階で、開発の中で希望する分野を選択します
この時、ソフト開発職か、ハード開発職に分かれます。
おそらく、彼はここでソフト開発職を選択したと思います。
- 私の体験談で入社後に気がついたことですが、ハード開発職を選んでもそのハードに乗せるソフトの開発は、ハード開発職でした。
- つまり、メモリキャッシュのようなハードべったりな部分であれば、ハード開発（特にサーバ系）を選択しなければいけないと思われます。
- ちょっとググッて見ると、SPARC64 VIIIfxあたりの話が出てくるので、スパコン「京」をやっている部隊を目指すのが良かったのかもしれません。
しかし、ソフト開発の現場で、現在キャッシュコヒーレンシを扱うようなものはなく、一番関われそうなものとして汎用機部隊への配属（出向）となってしまったのではないでしょうか。
メインフレームの中の高度な実装技術
メインフレーム＝COBOLというイメージは、世間では普通のことでしょう。
しかし、よくよく考えると、実は異なる側面があります。
メインフレームの上のアプリケーションは確かにCOBOLで書かれます。
しかし、メインフレーム自体はアセンブラや機械語のようなもので書かれていると聞きます。
メインフレームの技術者は、16進数で流れる機械語を眺めるだけで処理がわかり、バグを見つけると聞きます。ある意味今では失われつつある職人技です。
メインフレームはいくつものCPUは周辺機能を持ち、昨今一般的になった仮想マシン（VM)という概念も、メインフレーム上でのマルチテナントが発祥だったりします。
メインフレームは高価な機器であり、買うより借りる世界でした。そのためCPUを共有し多くの利用者で資源を共有していました。
このメインフレームの上で培われた技術の１つに「キャッシュコヒーレンシ」があります。
富士通のメインフレームの上の「キャッシュコヒーレンシ」は、教科書にはないかなり攻めた実装だったとオープン系にこの機能を10年以上前に移植したご飯友達の先輩が言っていました。
つまり、
とどめに「君はオープンプラットフォームでの開発には多少覚えがあるらしいけど、メインフレームではそんなものは役に立たないから。」なんて台詞が飛んできた。
このセリフがちゃんと説明したものであれば、彼の配属は正しかったのではないかと思うわけです。
彼は、この情報が溢れる世界には出てこない高度な実装技術を目にすることが出来るかもしれない機会を失ってしまったということです。
確かにメインフレームの実装はすでに枯れていて、システム側を見ることは稀でしょう。
そのため、SIの手伝いをさせられてしまった可能性は充分にあります。
特に基幹系のコア部分を経験の無いものが実装改変するなんていうのは、誰が考えても怖すぎて無理です。
突然、銀行の残高が０になったら社会問題に発展します。そんな問題の責任を被るのは会社です。
転職を決めるきっかけ
とまぁ、会社を擁護するような発言になってしまいましたが、上司の対応はまぁダメでしょうね。
すでに、役員レベルで把握されている事案らしいので、この上司は呼び出しを食らっていることでしょう。
日本の場合、転職するってのは、新しいことをしたいというよりかは、人間関係に悩んで辞めるほうが多いと思うので、今回転職してしまったのは、彼にとってはいいことでしょう。
前の上司が見たら凹むと思いますが、僕が転職しようと思ったきっかけもそんなとこも含まれます。
しかし、会社としては実務をしていない彼に1年間、給与と教育をしてきたわけですから大きな損失です。
今回の件が明るみに出たことで、動いている人がきっといると思うので、次にこんなことが起こらないことを祈るばかりです。
相談相手
富士通社内に居て悩んでいる方、富士通に入社したいけどこんな話を聞くとちょっとって人がいたら、僕でよければお話を聞いたり相談に乗れる範囲で対応します。密告でも構いません（笑）
社内検索で僕を見つけて、メールでもメッセージでも送ってみてください。
富士通に入社して10年が経った
こんばんは tnaotoです。
富士通の退職エントリーが何かと話題ですが、いろんなことが混ざっているので一度整理してみようかなと思います 。
昔は、リクルータや採用イベントに出ていたこともあるので、そこらで話をしてたことを思い出しつつ。
突然、この記事が消えたら会社からの圧力があったか、話題になりすぎてビビったかのどちらかです。
自己紹介
僕は約１０年前に、新卒入社（情報系院卒）し、 ソフト開発職を５年くらいやった後に、社内公募で研究所に異動し、 以後、事業部と研究所を行ったり来たりしています。
最近では、publickeyあたりに僕のことが乗っていたりします。
また、僕は研究所にはいますが、研究してない研究員という謎の立場です。
富士通の職種
よくSIerがーとか言われる業界ですが、富士通の職種はいろいろあります 。
特に大きな違いは、SE職と開発職の違いです。 ハード系開発職は、それだけで判別出来ますが、ソフト系開発職とSE職の違いを知らない方が多いかと思います。
SE職の中もいろいろありますがここは割愛します。就活する中で聞いてみてください 。
さて、今回いろいろ言われているのはこの「ソフト開発職」です。
僕の世代で、500人の同期の中、ソフト開発職はだいたい40人くらいでした。
「ソフト開発職」というのは、主にミドルウェアの開発を行っていて アプリケーションサーバやデータベース、運用管理ソフトを作っていたりします。 これらのミドルウェアの上にSEがフレームワークを作ったり、アプリケーションを乗せたりしています。 ソフト開発職のお客様はSEであって、実際の顧客に会うことはほぼありません。 会うことがあるとすれば、大きな障害が出て謝りに行くことが多いような気がします。
大学院で研究していたテーマを仕事にしたいなら、富士通研究所に行くしか無い気がします。 富士通研究所は、研究室繋がりや学会等でのヘッドハントがメインで、 通常エントリーから新卒入社する道はほぼないですが、テーマややる気が役員に伝われば富士通本体に入るよりかは簡単かと思います。 僕が会ったことないだけかもしれませんが、新卒は修士博士ばかりな気がします。
追記： 高卒や高専卒や専門専攻外からの採用もあるそうです。興味のある人はアタックあるのみってことみたいです
社内での異動はよくありますし、総務等もあるので、所員すべてが修士博士ではありません。ご注意を。
また、研究所は富士通本体からの出向という扱いになります。
入社直後のこと
入社後全体研修の後もらった辞令は、話題に出てきた「山奥の工場」でした。
配属後に部門の研修が半年くらいあり、これは帰れないなーなんて思いながら過ごしました。
僕のときは、ソフト開発職内定後のマッチングは無かったような記憶があります。 入社後の配属前の面談というものはありました。 この時の面談中に言われた言葉は、「君は地に足がついてない」という僕の主張・希望は一蹴りされるようなものでした。
そして、部署配属言い渡された時には、部署説明のときにはなかった新設部署。
つまり情報０。
転勤と配属後に聞かされた担当製品は、「オープン系COBOLバッチ基盤」でした。
あー・・・と思ったこともありますが、面白い先輩にも恵まれ、
硬いコードテストの技法などを学びつつ、
１つの機能を実装する（CとJavaの混合)ということもありました。
しかし、３ヶ月もしないうちに先輩たちは異動し、僕は置いていかれました。
僕の配属理由
配属後に、教育担当だった方と飲む機会がありました。 どこの部署に誰が配置されたとか理由とか詳細部分はデリケートな問題を含むから言えないけど おおまかに言えば、出身大学と情報系資格（旧1種）、部署によってTOIEC点数で並べていったものだと聞かされました。
なぜかといえば、それくらいしか評価する基準が無いからということでした。 製品開発に、大学の研究テーマはあまり関係がなく、関係がある場合には事前マッチングやさらにその前に確定しているということです。
注意
約10年前の話なので、今は違うかもしれません。また、僕がいた部門の話なので、他の開発職種やSE部門とは異なります。
出身の学位専攻はほぼ関係なかったような気がします（僕はHPC系の情報科学系の出身）
インターンや事前マッチング、面談で合っていればそこに配属されたが、事業部側の受け入れが無ければそもそも配属はないという現実も知りました。
後に、希望していた製品は、開発が終了し、保守ベースに移行していたことも知りました。
半年で4人の上司
あれよあれよといているうちに、違う担当に割当てられ、C言語の経験（大学の実験程度）があるからと、コマンドを作る担当になりました（プロジェクトは５人くらい）。
しかし、２年目が若造が出来ることなんてごく僅かで、どうやっても作りきれる気はしませんでした。
どうやっても作れないので、僕は正直に無理です。と報告していましたが、
当時の上司は、
「お前しか出来るやつがいないから仕方ない。残業時間が100時間超えてしまうのは仕方ない（月上限が100時間、それを越える場合には3ヶ月で300時間という規定があった）。 上には説明しておくからどうにかやれ」
という指示でした。
気がつけば、表示上の月残業は130時間弱、半年で600時間の残業をしていました（当時の上限は年間900時間まで）。
毎日2時までコードを書き、帰宅し、朝8時には会社にいてコード書いてました。
一ヶ月半で8000行くらいのCのコードを書きましたが、全部覚えてしまっていました。 また、１つのコードで、windows,Linux(x86,x64,IA64),Solarisに対応するように書かなければならず、 mallocやmemsetの境界値でよく泣かされていました。
もちろん書いたコードに対してテスト等や結合をするので、半年以上時間がかかっています。
夢の中でコードを書き、visual studioでステップ実行デバックするデジャブもありました。
月の手取りが賞与を越えるってこともありました（残業代はちゃんと出ます）。
はたから見ればブラックですが、僕は不思議と楽しかった記憶があります。
その後、この作った製品のサポートやエンハンスをしていましたが、お世話になった人もいなくなったところで 暇もあったので社内公募に応募し、異動（出向）したのでした。
はてぶコメントより追記
異動と共に引き継ぎをしていますので、異動後に問い合わせを何回か受けただけで、今ではどうなっているかを知るよしはありません。
（この時、公募には必要条件があったりするのですが、未達のまま応募し受かっています。）
なんか思い出話になったな・・・・
その後
その後研究所では、よく分からない研究に従事し、あー合わないなーって思って転職考え始めたころに
違う人に拾われ、事業部での新製品開発へ逆出向。
そして、自分の中で一段落して、転職活動を水面下で実行し、内々定が決まったあたりで、知ってる人に相談の後、
「好きにしていいから、辞めないで」というお言葉を頂き、今にいたります。
結局どこも似たようなもの。だったら自分が納得する場所に行けばいい。
この期間の間に、外に出るということを少しずつ始め、Cloud Foundryに出会い、
コミュニティというものを知り、外部のエンジニアを知り、隣の芝が青いなー論をいっぱい見ました。
特に、WEB系企業のエンジニアの方々は、輝いて見えるのは今でもあります。
到底敵いません。
彼らは努力し、睡眠時間を削って、サービスを作っているのも知っています。
目に見えるサービスを作っているのか、見えないサービス（社会インフラ）を作っているのか、
実は同じなんじゃないかと思う部分は多々あります。
何が違うかといえば、それは一緒に仕事をする「人」であるということ。
富士通という会社にはいろんな人がいて、いろんな「経験」が転がっています
一緒に仕事したことないけど、ご飯食べにいく人もいます。（not社食）
社内で意思疎通がうまく出来れば、自分の辛さも吐き出せるし、助けてもらえることもあります。
キャリアカウンセラーもいます。
転職を考えるときは、この人間関係がうまく行かなくなってツライってことが多いんじゃないかなって思います。
お金が倍くらいになるならクラっと来ますが、仕事も2倍だと精神的にどっちが幸せかという天秤にかけて、 「平和」に過ごせるほうを僕は、幸せなんじゃないかと思います
僕は転職で3割くらいの給与アップの希望も通っていましたが、残業せず定時で帰れる、仕事を自由に選べる今の状況が良かったのかなと思っています。
最近は、第一線から退いていて現場の経験値が積まれてはいないので、次のキャリア（40時くらいのときどうしてるか）を考えていかないとなーと思っている日々です。
追記
「ソフト開発職」とか「研究職」に興味がある学生さんとかは、声かけてくれればいくらでもお話しますのでなんなりと。
githubのgit cloneで「fatal: HTTP request failed」が出たときの対処
CentOS6.5を使ってて突如遭遇。
とりあえず、以下を打つことで問題を回避
git config --global http.sslVerify false
