富士通がAdvent Calendarに参加することになった理由

これは、

qiita.com

FUJITSU Advent Calendar2日目の記事です (はてブコメント付いて気が付きましたので追記しました。ありがとうございます)

急遽12/1の夕方に決まって始まったばかりで、どんな経緯だったかと少し 技術的内容じゃないって突っ込まれそうですが、大目に見てもらえることを期待して・・・

あと、これ書いて置かないと、社内からも何してんの?って内部から刺されるのでご理解をw

Qiitaのadventじゃなくて、adventarで良かったんじゃないかとも思いつつ

さて、始まって2日目ですが、すでに一日目がツッコミを食らっていたりしますね

まぁ富士通の認識なんて世の中からすればそんなもんですよね。否定はしません。

富士通社内でもAdvent calendarは認識されています。 2015年から社内でカレンダーはやっていましたが、1枚のカレンダーを埋めるのが精一杯だったような気もします

引き続き、今年もカレンダーを分野に分けてやってますというメール等が流れていました。 が、今年は閑散としていて1人も人がいないような状態なものもあり・・・。

元々は、ソフト系エンジニア(not SE部門)発の取り組みなので、活動の認識が狭いのも1つの要因かもしれません。

まぁそんなカレンダーですが、二フティさんを始め他社はやってるよーなんて話は上がっていましたが、

結局のところ社内で何書くの?って感じだったわけです。

技術の話を書くとして、それは製品開発で得た知識なのか、趣味で調べたものなのか。

特に後者であるならば、なぜわざわざ社内に書かなきゃいかんのか。

そんなことを思っていた僕は、以下のようなメールを投げました。

たかはしです

社外の富士通advent calendarだったら書いてもいいかなーと思うけど
社内のadvent calendarだったら別になーって思うのは僕だけですかね

そしたら、外部に書くには事務手続きがうんぬんという話が出て、 やれ、該非判定だの社外公開手続きだのって話になってしまいました。 それらがめんどくさいから、社内でやるんだと。

そうじゃないと思うんだよなーと思いながら、ちょっと若いのと社外で活動する楽しさって何かねーって会話をしてたんですが、

身内じゃない知らない人に認められるのが嬉しい
OSSの場合人に使ってもらえることが嬉しい
技術的に社外の方がレベルが高くておもしろい

こんなことを言われてハッとしました。

僕自身は、まぁ好き勝手にやっているのでほぼ無自覚無意識だったのですが(いいのかそれ)、

改めて文字でもらうとそうだよなーと思いました。

OSSやコミュニティじゃないですが、情報は発信するところに集まると僕は思っていて 情報クレクレくんが多いと発信してるほうはつまらないと思います。

社外に記事を書いたり発表したりすると、情報が繋がったり、人脈が増えたりして 違う世界が見えて、人としても、エンジニアとしての技術の幅も増えたりすると思っています。

しかし、社内で発信する立場を取ると、こう回らない現状があります。 社内での経験や認知度が増すと、

・言ったからには責任を取れ

・言ったんだからお前がやれ

みたいな悲しいことになってしまっています。

個別にメールが来て、心痛くなるなんてことはザラです。

これは悲しいと同時に、実は社内でカレンダーやるほうが敷居が高いのではないか?という仮説が生まれました。

失礼ながらQiita等で記事を書いたとして社内よりは匿名性が高い。いきなり刺される心配もないと思いました。

そんな議論や批判が飛び交う中、突然「QiitaやAdvent Calendarってソーシャルメディアなんじゃないの?」っていう 解釈が飛んできました。

さて、富士通はいわゆる大企業。最近いろいろ話題になった大きな会社もあったので、「あ〜またダメな布石か」と 思いながら、添付されたURLを開きました。

そして、飛び込んできた1行目に驚愕しました。

ソーシャルメディアを利用する場合のルールとマナー
近年、ソーシャルメディアに新しい機能が次々と組み込まれ、その利用者が拡大しています。ソーシャルメディアは、複数の利用者間でのコミュニケーションに非常に有効であり、富士通グループとしても積極的に取り組むべき領域です。

( ゚д゚) ・・・ (つд⊂)ゴシゴシ (;゚д゚)?!

もう何かのギャグかとw

もちろん、このページには利用する上での注意等が書かれていました。

がしかし、これはあくまでガイドライン。最終的にこれを問題ないというのは誰なのか。これが一番の重要ポイントでした。

社内教育を担当する部門は、結局は個人判断ですって言うので話になりません。あと一歩なのに。

「俺が責任取るからどんどんやれ」みたいなカッコイイ人は居ないのかなぁなんて会話をしていました。

今年は無理かなぁ、このあたりを議題に来年なのかなぁと議論していた人たちは意気消沈しかかかったところに、

○○の○○です。(いわゆる執行役員)

ソフトエンジニアが社外発信するとっても良い機会なので、
僕は大賛成です。社内SNSガイドライン的にも問題ないよう
に思います。ぜひ、今年からやりましょうよ。

突然のカッコイイ人登場

そこからの社内の行動は早かった。。 僕はかっこいい人登場のときには打ち合わせに出ていたのですが、 やりましょうから2時間以内で、カレンダー作って始まっていました。

最近バズってた「SIerにSlackを導入した」ブログがありましたが、 内圧が上がってしまっていのではないかという実情を見た気がしました。

小野和俊のブログ:SlackをSIerに導入した話。そしてSIerの未来

現在の富士通グループでは、社内規定によりSlackの単体導入はNGとなっていますが、 今回のような話をきっかけに、世の中のスタンダードをどんどん取り入れていきたいと思います。

それが、自分たちの体験こそが知見ノウハウであり、お客様のビジネスをよりよくするための糧になると私は考えています。(個人の見解です)

富士通にソフト開発職で入社して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つなんじゃないかなんて思っています。

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

他には、

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

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

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

自由という難しさ

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

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

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

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

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

キャッシュコヒーレンシとジョブマッチング

こんばんは、tnaotoです。

前回のブログの反響がすごくて驚いています。

ビビって消そうかなーと思っていましたが、今のところ怒られてないので大丈夫だと思っています。

例のブログで”キャッシュコヒーレンシ”の話で、社内で何人かの方から情報を得て、いろいろ考える面があったので筆を取ってみました。

キャッシュコヒーレンシとは

キャッシュコヒーレンシ - Wikipedia

簡単に言えば、マルチCPUの時のメモリとCPUキャッシュを一貫性を保つかみたいな話だと思います(専門じゃないので見ただけの話)

昨今では、マルチコア、マルチソケットのサーバ環境は手に入りやすいですが、

5、10年前くらい前だと2ソケットくらいはありましたが、4ソケット以上になると

大型サーバ(Solaris,IA64など)やメインフレームのような汎用機の世界でなければ、そこまで一般的ではなかったように思います。

富士通とキャッシュコヒーレンシ

ちょっとググッてみたところ、特許公開情報がヒットしました。

astamuse.com

確かに富士通では、研究開発が近年でも行われているようです。

例の彼はこれを見て、富士通への就職を決めたのであれば、残念なことです。

この出願者に会って話をする機会は無かったのかなと思います。

出願者でググれば、研究所の人だと分かる人が含まれています。学会やメアド直接アタックして欲しかったなーと思います。

研究所は、一本釣り入社が多いので、そのまま大学院での研究を発展していけたかもしれません。

ジョブマッチング

ここからは推測です。

おそらく、富士通としか書いてないから、富士通でソフト開発を目指せばたどり着けると思ってしまったのでしょう。

10年以上前に就職活動していた自分を全く同じ状況だなーと思っています。

そして、ジョブマッチング時にいくつかの選択ミスがあり、人事も本人もそれに気がつけなかったことがいろんな大失敗の原因でしょう。

ここから先に書いている内容は、私が選考を受けた10年前のものですので、現在は異なるかもしれません。

富士通への就職の道は、富士通への就活エントリを経験された方なら大まかに理解されていると思いますが、

応募の時点で、大きく3つの道(営業、SE、開発)が決まります。

選考途中で、強い要望と情熱で人事を説得しないかぎり、変更出来ないと思います。

自由応募でも学校推薦応募でもここは同じだっと思います。

そして、選考が終わり内定となった段階で、開発の中で希望する分野を選択します

この時、ソフト開発職か、ハード開発職に分かれます。

おそらく、彼はここでソフト開発職を選択したと思います。

  • 私の体験談で入社後に気がついたことですが、ハード開発職を選んでもそのハードに乗せるソフトの開発は、ハード開発職でした。
  • つまり、メモリキャッシュのようなハードべったりな部分であれば、ハード開発(特にサーバ系)を選択しなければいけないと思われます。
  • ちょっとググッて見ると、SPARC64 VIIIfxあたりの話が出てくるので、スパコン「京」をやっている部隊を目指すのが良かったのかもしれません。

しかし、ソフト開発の現場で、現在キャッシュコヒーレンシを扱うようなものはなく、一番関われそうなものとして汎用機部隊への配属(出向)となってしまったのではないでしょうか。

メインフレームの中の高度な実装技術

メインフレームCOBOLというイメージは、世間では普通のことでしょう。

しかし、よくよく考えると、実は異なる側面があります。

メインフレームの上のアプリケーションは確かにCOBOLで書かれます。

しかし、メインフレーム自体はアセンブラ機械語のようなもので書かれていると聞きます。

メインフレームの技術者は、16進数で流れる機械語を眺めるだけで処理がわかり、バグを見つけると聞きます。ある意味今では失われつつある職人技です。

メインフレームはいくつものCPUは周辺機能を持ち、昨今一般的になった仮想マシンVM)という概念も、メインフレーム上でのマルチテナントが発祥だったりします。

メインフレームは高価な機器であり、買うより借りる世界でした。そのためCPUを共有し多くの利用者で資源を共有していました。

このメインフレームの上で培われた技術の1つに「キャッシュコヒーレンシ」があります。

富士通メインフレームの上の「キャッシュコヒーレンシ」は、教科書にはないかなり攻めた実装だったとオープン系にこの機能を10年以上前に移植したご飯友達の先輩が言っていました。

つまり、

とどめに「君はオープンプラットフォームでの開発には多少覚えがあるらしいけど、メインフレームではそんなものは役に立たないから。」なんて台詞が飛んできた。

このセリフがちゃんと説明したものであれば、彼の配属は正しかったのではないかと思うわけです。

彼は、この情報が溢れる世界には出てこない高度な実装技術を目にすることが出来るかもしれない機会を失ってしまったということです。

確かにメインフレームの実装はすでに枯れていて、システム側を見ることは稀でしょう。

そのため、SIの手伝いをさせられてしまった可能性は充分にあります。

特に基幹系のコア部分を経験の無いものが実装改変するなんていうのは、誰が考えても怖すぎて無理です。

突然、銀行の残高が0になったら社会問題に発展します。そんな問題の責任を被るのは会社です。

転職を決めるきっかけ

とまぁ、会社を擁護するような発言になってしまいましたが、上司の対応はまぁダメでしょうね。

すでに、役員レベルで把握されている事案らしいので、この上司は呼び出しを食らっていることでしょう。

日本の場合、転職するってのは、新しいことをしたいというよりかは、人間関係に悩んで辞めるほうが多いと思うので、今回転職してしまったのは、彼にとってはいいことでしょう。

前の上司が見たら凹むと思いますが、僕が転職しようと思ったきっかけもそんなとこも含まれます。

しかし、会社としては実務をしていない彼に1年間、給与と教育をしてきたわけですから大きな損失です。

今回の件が明るみに出たことで、動いている人がきっといると思うので、次にこんなことが起こらないことを祈るばかりです。

相談相手

富士通社内に居て悩んでいる方、富士通に入社したいけどこんな話を聞くとちょっとって人がいたら、僕でよければお話を聞いたり相談に乗れる範囲で対応します。密告でも構いません(笑)

社内検索で僕を見つけて、メールでもメッセージでも送ってみてください。

富士通に入社して10年が経った

こんばんは tnaotoです。

富士通の退職エントリーが何かと話題ですが、いろんなことが混ざっているので一度整理してみようかなと思います 。

昔は、リクルータや採用イベントに出ていたこともあるので、そこらで話をしてたことを思い出しつつ。

突然、この記事が消えたら会社からの圧力があったか、話題になりすぎてビビったかのどちらかです。

anond.hatelabo.jp

自己紹介

僕は約10年前に、新卒入社(情報系院卒)し、 ソフト開発職を5年くらいやった後に、社内公募で研究所に異動し、 以後、事業部と研究所を行ったり来たりしています。

最近では、publickeyあたりに僕のことが乗っていたりします。

www.publickey1.jp

また、僕は研究所にはいますが、研究してない研究員という謎の立場です。

富士通の職種

よくSIerがーとか言われる業界ですが、富士通の職種はいろいろあります 。

特に大きな違いは、SE職と開発職の違いです。 ハード系開発職は、それだけで判別出来ますが、ソフト系開発職とSE職の違いを知らない方が多いかと思います。

SE職の中もいろいろありますがここは割愛します。就活する中で聞いてみてください 。

さて、今回いろいろ言われているのはこの「ソフト開発職」です。

僕の世代で、500人の同期の中、ソフト開発職はだいたい40人くらいでした。

「ソフト開発職」というのは、主にミドルウェアの開発を行っていて アプリケーションサーバやデータベース、運用管理ソフトを作っていたりします。 これらのミドルウェアの上にSEがフレームワークを作ったり、アプリケーションを乗せたりしています。 ソフト開発職のお客様はSEであって、実際の顧客に会うことはほぼありません。 会うことがあるとすれば、大きな障害が出て謝りに行くことが多いような気がします。

大学院で研究していたテーマを仕事にしたいなら、富士通研究所に行くしか無い気がします。 富士通研究所は、研究室繋がりや学会等でのヘッドハントがメインで、 通常エントリーから新卒入社する道はほぼないですが、テーマややる気が役員に伝われば富士通本体に入るよりかは簡単かと思います。 僕が会ったことないだけかもしれませんが、新卒は修士博士ばかりな気がします。

追記: 高卒や高専卒や専門専攻外からの採用もあるそうです。興味のある人はアタックあるのみってことみたいです

社内での異動はよくありますし、総務等もあるので、所員すべてが修士博士ではありません。ご注意を。

また、研究所は富士通本体からの出向という扱いになります。

入社直後のこと

入社後全体研修の後もらった辞令は、話題に出てきた「山奥の工場」でした。

配属後に部門の研修が半年くらいあり、これは帰れないなーなんて思いながら過ごしました。

僕のときは、ソフト開発職内定後のマッチングは無かったような記憶があります。 入社後の配属前の面談というものはありました。 この時の面談中に言われた言葉は、「君は地に足がついてない」という僕の主張・希望は一蹴りされるようなものでした。

そして、部署配属言い渡された時には、部署説明のときにはなかった新設部署。

つまり情報0。

転勤と配属後に聞かされた担当製品は、「オープン系COBOLバッチ基盤」でした。

あー・・・と思ったこともありますが、面白い先輩にも恵まれ、

硬いコードテストの技法などを学びつつ、

1つの機能を実装する(CとJavaの混合)ということもありました。

しかし、3ヶ月もしないうちに先輩たちは異動し、僕は置いていかれました。

僕の配属理由

配属後に、教育担当だった方と飲む機会がありました。 どこの部署に誰が配置されたとか理由とか詳細部分はデリケートな問題を含むから言えないけど おおまかに言えば、出身大学と情報系資格(旧1種)、部署によってTOIEC点数で並べていったものだと聞かされました。

なぜかといえば、それくらいしか評価する基準が無いからということでした。 製品開発に、大学の研究テーマはあまり関係がなく、関係がある場合には事前マッチングやさらにその前に確定しているということです。

注意

約10年前の話なので、今は違うかもしれません。また、僕がいた部門の話なので、他の開発職種やSE部門とは異なります。

出身の学位専攻はほぼ関係なかったような気がします(僕はHPC系の情報科学系の出身)

インターンや事前マッチング、面談で合っていればそこに配属されたが、事業部側の受け入れが無ければそもそも配属はないという現実も知りました。

後に、希望していた製品は、開発が終了し、保守ベースに移行していたことも知りました。

半年で4人の上司

あれよあれよといているうちに、違う担当に割当てられ、C言語の経験(大学の実験程度)があるからと、コマンドを作る担当になりました(プロジェクトは5人くらい)。

しかし、2年目が若造が出来ることなんてごく僅かで、どうやっても作りきれる気はしませんでした。

どうやっても作れないので、僕は正直に無理です。と報告していましたが、

当時の上司は、

「お前しか出来るやつがいないから仕方ない。残業時間が100時間超えてしまうのは仕方ない(月上限が100時間、それを越える場合には3ヶ月で300時間という規定があった)。 上には説明しておくからどうにかやれ」

という指示でした。

気がつけば、表示上の月残業は130時間弱、半年で600時間の残業をしていました(当時の上限は年間900時間まで)。

毎日2時までコードを書き、帰宅し、朝8時には会社にいてコード書いてました。

一ヶ月半で8000行くらいのCのコードを書きましたが、全部覚えてしまっていました。 また、1つのコードで、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

jawsdays資料まとめ

見当たらなかったのでまとめてみる。見難くてごめんなさい

とりあえず、全部見つかってないので見つかったところからちまちまと。 まとめ記事のリンクもあとで付けるか・・・

発見・間違いがあったら @tnaotoまでmentionを。

JAWS DAYS 2014 http://jawsdays2014.jaws-ug.jp/timetable/

-

No. ビッグトラック #big
1
2 Benchmarking on AWS
3 What Would OFA do Now?http://snickerjp.blogspot.jp/2014/03/JAWSDAYS2014-OFA.html
4 日経電子版のAWS活用事例
5 世界で展開する新しいネットワークサービス「Miiverse 」のAWS活用事例https://speakerdeck.com/hatena/jaws-days-2014-miiverse
6 東急ハンズを支える技術」はAWSか?

-

No. Immutable Infrastructure #infra
1 Immutable Infrastructurehttps://speakerdeck.com/naoya/immutable-infrastructure-number-jawsdays
2 クックパッドのデプロイとオートスケールhttps://speakerdeck.com/mirakui/cookpads-deployment-and-auto-scaling
3 Infrastructure as Codeと組織のドキュメンテーション+Immutable Infrastructureの事例http://www.slideshare.net/YukihikoSawanobori/jawsdays-infra
4 プロビジョニング&デプロイ on AWSのキホンhttp://www.slideshare.net/Ryuzee/the-basics-of-provisioning-and-deploy-on-aws-jawdays-infra
5 Immutable Infrastructure時代の構成管理ツール基盤SpecInfrahttps://speakerdeck.com/mizzy/specinfra-at-jaws-days-2014
6 「技術的負債」を問いなおすhttp://blog.kentarok.org/entry/2014/03/15/224227
7 パネルhttp://blog.stanaka.org/entry/2014/03/15/215437

-

No. AWS Technical Deep Dive #deepdive
1 Amazon Kinesisで広がるクラウドによるリアルタイムデータプロセッシングとその未来
2 Amazon WorkSpaces Deep Divehttp://www.slideshare.net/GentaWatanabe/amazon-workspaced-deep-dive
3 I/Oを極めろ! 」 I2インスタンスパフォーマンスhttp://www.slideshare.net/MatsumotoHiroki/20140315-jawsdays-i2-instance-io-performance
4 AWSクラウドデザインパターン for Enterprisehttp://www.slideshare.net/c95029/enterprise-cdp-20140315public
5 マルチキャストがないならユニキャストすればいいじゃない/ほしいプロトコルはカプセルすればいいじゃないhttp://www.slideshare.net/kentayasukawa/multicastunicast
6 Active Directory on AWShttp://www.slideshare.net/ryukiyoshimatsu/active-directory-on-aws-jaws-days-2014
7 CloudFrontで実現するセキュアコンテンツ配信と効果のトラッキングhttp://www.slideshare.net/kkitasako/jawsdays2014-cf

-

No. テクニカルトラック#tech
1 はじめてのAWS
2 意外と知らないリザーブドインスタンス。すぐに効くコスト削減http://www.slideshare.net/HiroshiTakayama/jawsdays20140315-publix
3 スタートアップCTOパネルディスカッション(前編)
4 スタートアップCTOパネルディスカッション(後編)
5 OpsWorks事例紹介!リモートワークを支えるリアルタイムツールの舞台裏http://www.slideshare.net/kuranuki/opsworksremotty20140315
6 IaaSとPaaSの微妙な関係
7 クラウドソーシングLancers」を支えるRDS for MySQL

-

No. ACEに聞け!#ace
1
2 EC2 ココが違うよEC2 〜オンプレVMとの徹底比較〜
3 S3http://www.slideshare.net/idacchi/20140315-jawsdays2014s3
4 RDS
5 ELB/AutoScaling
6 SWFhttp://www.slideshare.net/okeee0315/20140315-jawsdays2014-swf
7 EMRhttp://www.slideshare.net/youheiyamaguchi/ace-32403313
8 Redshift RedShiftベンチマーク 〜POSデータはSSDの夢を見るか?〜
9 CloudFormationhttp://www.slideshare.net/daisuke_m/20140315-jaws-days-2014acecfn
10 OpsWorks
11 DynamoDB MyColor 〜私色〜 DynamoDB使って世界中で私色になろう!
12 AppStreamhttp://www.slideshare.net/kawaji/jaws-days2014-app-stream
13 Kinesis Amazon Kinesisでリアルタイム分析の世界へhttp://www.slideshare.net/tkonparu/jawsdays2014-amazon-kinesis-for-beginner

-

No. iJAWS #ijaws
1 What is AWS?http://www.slideshare.net/rasmusekman/what-is-aws-32386367
2 Scaling Gengo on AWS: from 10,000 translators, 150 million words, and beyond!.
3 Building Moneytree’s data aggregation system with SWF
4 Language Cloud (Use Case in AWS)http://slid.es/sergioarcos/language-cloud-use-case-in-aws--2
5 Lessons learned from 8 years of hosting Ruby web appshttp://www.slideshare.net/mreinsch/rubyhosting-32386774
6 How to tune MongoDB on AWS
7 AWS Geek Talk: An Inside story of AWS users

-

No. 最強のサムライ
1 (旧)SAMURAIハンズオン:WordPress on AWS(網元AMIを使って5分でWordPress構築)http://www.slideshare.net/megumithemes/jawsdays2014-amimoto
2 SAMURAIハンズオン:AWSクラウドデザインパターンから始めよう!
3 SAMURAIハンズオン:AWS Meetup!AWSを学んでWebサーバを立ててみよう!http://www.slideshare.net/tomyankuns/samurai-aws-meetup
4 九州・沖縄SAMURAIハンズオン:AWS料金体系グランドマスター王者決定戦〜料金を制覇する者は全てを支配する、王者への誘い〜http://www.slideshare.net/popowa/aws1-32456866
5 九州・沖縄SAMURAIハンズオン:AWS料金体系グランドマスター王者決定戦〜全てを支配する覇者は誰だ〜http://www.slideshare.net/popowa/aws-2-32456996
6 これで最強のAWSに with Miles #最強のAWS
6.1 全部AWSでやらないワケhttps://speakerdeck.com/takus/why-dont-we-use-aws-for-all-our-infrastrctures
6.2 What makes AWS invincible? from JAWS Dayshttp://www.slideshare.net/Yuryu/jaws-days-2014-what-makes-aws-invincible
6.3 複数VPCでのベストプラクティスhttp://www.slideshare.net/SachieMiyazaki/2014-jaws-daysawsrtc
6.4 |星野 豊
6.5 |Miles Ward
6.6 |大谷 晋平

懇親会 LT

[初音ミク] Kinesisフリーザを撃て! http://www.slideshare.net/shimy_net/kinesis-32355276

エンタープライズDevOpsについて思うところ

いわゆるDevOpsは開発と運用が仲良くしようという話 しかしこれは、お互いに目指すものが同じ このDevOpsがうまくいかないだろうと言われるのが、エンタープライズ なぜそうなのか

エンタープライズの場合と決定的に違うのは、「ビジネス計画」だろうか エンタープライズDevOpsの場合には投資予算があり、結果を求められる これは技術的な問題ではなく、会社の運営の問題。 昨今話題のDevOpsにはお金の話はあまり書かれてない気がする。

Product-Outで会社が成り立っている場合にはDevOpsだけでうまくまわり そうであるが(Web系ベンチャーは主にこれかな)、 ここに単年計画の予算計画と中長期のビジネス計画(投資計画)が必要な エンタープライズとは大きく隔たりがある

エンタープライズはよくも悪くも設計重視であり、プログラミングは軽視されていると思う これは、「設計書があればプログラムは誰が書いても同じ」という思想が今も残っているものだろう。 また、現在のICTの大本となっている話が、「コスト削減」であり、自動化もこの延長線でしかない。

つまり、エンタープライズは「やるべきことが分かっている」ということであり、 時間をかけても求めているものにだいたいなるということだろう また、それは顧客の要求に答えたスペシャルなものであり、替えがないというところも 時間が掛かっても顧客が逃げないといったところがあった名残であろう

現在DevOpsが流行っている(?)界隈では、上記のような顧客の課題を解決するのではなく、 ユーザが本当に欲しいものから提供することで、ユーザの心を捉え、ユーザの要求に 迅速に応えることで自らのサービス(製品)を継続的に改善していくところにある。 継続的イノベーションと呼ばれる話のことだ。 完璧さを求めるエンタープライズに対し、小さく単機能でもいいから速くリリースし、 自らがイノベータとなって先導していくとがとても重要である。 先導するためには、継続的イノベーションにチャレンジすることでチャンスを掴むわけだ。 じっくり良いものを考えていても、先に出したほうが勝ちなのである。

エンタープライズDevOpsが成功する肝は、予算を握るビジネスが、しっかりとした ビジョンと計画を持ち、それをDev & Opsと共有し、同じ方向を見据え協力し、 ビジネスが現場を理解し、現場が運用を理解し、運用がビジネスにフィードバックする フィードバックを受けたビジネスが次のビジョンを・・・とループを回す必要がある。

エンタープライズの判断が遅いのは、DevOpsとコミュニケーションがうまく行ってないため 無理な開発計画の押し付けや、迫った納期による開発とそのつけを運用に回し、それが悪循環になるという あたりだろう。ビジネスは反省し、負債にDevに押し付けるのではなく、潔く負債を捨てる必要もある。

経営層の判断に期待したいところである。