探索的テストはベテランがやるものだと思ってた
今週、急性気管支炎で平日全部休む目にあいました showです。
各方面に本当にご迷惑をおかけしました。。。申し訳ない。。
さて、そんなときにTwitterで尊敬するブロッコリーさんと少しやりとりしてこんなことがありました。
探索的テストはベテランがやるのは誤解。
ってスライドのページを頂きました。
ちなみにWAKATEっていう「若手エンジニア向けワークショップ」ってのがあるらしい。
※行きたい
で、探索的テストはベテランがやるってのは誤解。
まじで？
JSTQB（ってかテス友）でも「探索的テストは経験とかがいるよ」みたいな話になってた記憶なんですが、どうもそうとも限らないらしい。
www.slideshare.net
このスライドをみてみると、たしかに誤解って書いてある。
で、22ページ目に
探索的テストは「テストを設計しながら実行する」「事前にテストケースは書かない」とある。
で、27ページ目になると
学習→設計→実行のサイクルを何度もまわすモノになってる。
あー・・・
言われてみればたしかにそうだなと。
探索的テストってなんとなく闇雲にやるイメージを正直もっていて
僕個人の勝手な経験だと、仕様がよくわからんシステムのサーバにXMLをwgetで送ってそのレスポンスを確認するテストをやったことがあって
その時は本当に手探りで闇雲な試験になったので、あれが探索的テストかなってイメージがあった。
けど、このスライドによると
無駄を省くためにやるもので、テスト設計しながら実行する
ってのが探索的テスト
つまり、闇雲とも限らなくて、学習→設計→実行を繰り返して精度をあげていく。
そうか。
そりゃそうか。
その通りである。
なので、事前に決められた（設計された）テストを実行するテスト方式ではないのが探索的テストというモノを指すのであれば
たしかに、ベテランがやるものというより、むしろそれこそ若手がやって学習していくのも十分アリである。
で、このスライドにでてきている本、読むことにします。
テストについて真面目に0から（1から？）学びなおすのもいいかもしれない。
何事も守破離である。
ブロッコリーさん
ありがとうございます。
JUnitでassertじゃなくてErrorCollectorを使うという選択肢
showです。
風邪気味です つらぽよ。
今回は掲題の通り、JUnitを使ってるならばErrorCollectorってのも使えるよ という話。
E2E試験（受け入れ試験）でWebページのテストをするときにSeleniumを使うことは結構あるとして
それをJavaでJUnitを使って実装しているとき、assertを使うことって結構あると思ってます。
けど、これ欠点があって
例えば、あるWebページにチェックする項目が3つあるとして
assertなんちゃらで上から3つチェックを書いた場合、
1つ目のassertで異常が見つかると、その場で動きが止まってしまう。
それはそれで正しいっちゃ正しいんだけど、これだと2つ目、3つ目の試験すべき箇所が正しいのか間違ってるのかを検証することができない。
ミッションクリティカルな試験だとこれはおそらく正しくて、止まるべきである場面もあるけど、そうでもない場合
1つ目で引っかかりましたー
デバッグしますー
直しましたー
再度試験を走らせましたー
2つ目で引っかかりましたー
デバッグしますー
直しましたー・・・・・・
って1つ1つやるのめっちゃ効率悪いと思ってます。
※そもそもバグを埋め込むのが悪いとかそういうのは別として。
そんな時にErrorCollector君が使えます。
この子をassertの代わりに使ってあげると、チェックしている箇所でfail扱いになってもJUnitは動き続けてくれます。
で、「これをチェックしたら期待値はこれだったけど、こうなってましたー」ってのがまとめて出力してくれる。
ってサンプルコードをここに記載しようと思ったら既に記事が存在した・・・ｗ
この記事では期待値が何で、結果こうなってますーってのが書いてあるんだけど
ここに書いてなくて、僕が個人的に使ってるやり方は
public class UseErrorCollector {
@Rule
public ErrorCollector errorcollector = new ErrorCollector();
//Seleniumの設定類を書く
@Test
public void errorCollector() {
//hogehoge画面のタイトルバーの文字列を確認する
if(!(driver.findElement(By.id("hogehoge:id/titlebar_text")).getText().equals("こんにちは"))){
errorcollector.addError(new Throwable("試験No.XX hogehoge画面のタイトル文字列が「こんにちは」ではありません"));
}
}
}
こんな感じです。
ErrorCollector にもやり方はいっぱいあるけれど、僕はこれでやることもあります。
なんでかっていうと、もともとassert文を使ってたけど、trueとfalseがごっちゃになる場合があって
かつ、うちのメンバーにプログラム書けないテスターさんもいるので、あんまりJUnitのassertシリーズを使い分けさせたくなかったから。
なのでif文で分けて、fail("hogehoge画面がーーー")って書いてた。
※サービスとかメンバーとかにもよる
正直、若干めんどいのも事実ではあるのですが、Seleniumを使ったコードを書いていると
自分でもたまに条件がよくわからんってなる時があったりするので、明示的にif文を書いてます。
なので最初にコメントで何を試験するのかを書いて、それに沿うようにif文を書いてる感じです。
テストコードがバグってるってのは、かなりよろしくないと思っていて、それを防止する意図も若干あります。
これをやると、「あぁこの試験やってんだな」ってのが他の人でもわかりやすい（気がする）。
はい。
こんなやり方もありますよってお話でした。
JSTQB Foundation受験記
showです。
2018年2月10日（土）にJSTQB Foundation試験を受けたので受験記を書いておく。
受験記
受 験 日 ： 2018/02/10
合 否 ： たぶん合格 ※発表まで2～３か月かかるらしい
受験科目 ： JSTQB Foundation
受験言語 ： 日本語
取 得 点 ： 非公開
合 格 点 ： 6割説と8割説がある
問 題 数 ： 40
出題形式 ： 単一選択
試験時間 ： 60分＋アンケート10分
勉強期間 ： 20時間くらい
受験目的 ： 自分のスキルアップ
勉強形態 ： 独学
実務経験 ： そこそこ
勉強前のレベル ： SIerのガチガチな品質の世界で生きてた
本試験のレベル ： 定められてる用語がわかったなくらい
何度目の挑戦か ： 1回目
セクション毎の正解率
非公開
使用教材
「ソフトウェアテスト教科書 JSTQB Foundation 第3版」
「テス友」
一押し >>> テス友
勉強方法
「ソフトウェアテスト教科書 JSTQB Foundation 第3版」を1週読んだら、
あとは通勤時間を中心に「テス友」をスマホでポチポチ
市販のなんちゃって対応テキスト・問題集や
対策問題のWebページもあるが一切やらなかった
試験の感想
問題用紙がでかい冊子でビビる。
「でっか！！」
ってなる。
時間がなくなることはおそらくない。
途中退席者も多い。
が、すべての問題をもう一度解きなおす見直し時間まではあるかないか微妙。
また、複数選択の問題が（今回は）（僕の認識では）なかったことと
・「適切な」ものを選べ
・「不適切な」ものを選べ
・「高い順」はどれか
などの問題文にアンダーラインが引いてあり、うっかりミスを救済する意図を感じた。
重箱の隅をつついてくると言われていたが、そんな印象はなかった。
そういう意味ではOracleのSQLやJavaのOCJ-Pの方がよほど意地汚い。
受験者へのアドバイス
基本的にはシラバス暗記ゲームなのだが、
テキスト一周したら、あとはひたすらテス友すればいい。
テス友そのまんまの問題はほぼない。
しかし、テス友で聞かれる問題を応用すれば十分対応できる。
テスト工程や品質知識に疎い場合は覚えることが多くなるかもしれない。
学生には厳しい可能性がある。
終わりに
受験票がこなくて半べそかいたんで、指定日に受験票がこなかったら即時運営に連絡すること。
以上
JSTQB受験がやべぇ話
showです。
JSTQBの試験が2月10日に迫っております。
土日にブログを書いているので次の記事は受験後のはず。
で、「テス友」というアプリで勉強してて今の正答率がこんな感じです。
だいだい75％を超えているくらいですね。
なんとかなるかもしれない感じです。
はじめの方はミスってばかりいましたが、今では正解率も高いので今の実力だともうちょい正答率は高くなるはず。
で、さっき
「そーいや受験票きてないな」
って思ったら。
受験票・受験のご案内は郵送にて2018年1月19日発送予定でございます。
2018年1月29日までに書類が届かない場合には、必ず下記受付までお問合せください。
って
おおおおおいいいいいい！！！！！！！
先ほどお問い合わせメールを慌ててだしました。。。
明日電話連絡もします。。。
僕がなぜ勉強するのか
showです
今回は 僕はなぜ勉強するのか について書く。
僕の答えの要約
自己投資として価値があると思うから。
記事内容
はい。
まぁぶっちゃけ上の要約に集約されるんだけど。
先日、ある人に言われた
「showさんってなんで勉強できるの？」
会話の流れから、この「できる」は成績がうんぬんではなくて
そもそも勉強という行為がなぜできるのか という話だった。
もう少し言うと、「業務時間外に資格勉強とかできるのはどうして？」という流れだった。
その場では突然聞かれたこともあったので
「うーん。。単に好きだからですかね。大学院までいっちゃう僕ですから」
『あーそれはそうだね』
ってなったんですけど
エンジニア界隈でも「勉強」ってよく話題になる。
なのでその理由を考えてみた。
今回は勉強会とかイベント系ではなくて、自分でやる系の勉強の話。
そもそも好き
好きなのである。
楽しいのである。
だからできる。
好奇心なのか
向上心なのか
探求心なのか
わかんないけど、好きなのである。
デメリットが浮かばない
僕の場合、勉強することのデメリットが特に浮かばない。
勉強時間で他の時間が減るくらい。
けどそれって勉強じゃなくても何でも同じ。
強いて言うなら、
技術書とか資格試験とかのお金がかかる。
本が場所をとる。
くらい。
けどたぶん、それってデメリットの本質じゃないから僕はどうでもいい。
某プラチナ試験100万円とかいくと厳しいけど。
できることが増える
勉強して知らないことを知ることができると、できることが増える。
知識が増えるから、その知識を持ってる人と話すフィールドに近づくことができる。
それによって、幅が広がってできることも増える。
法律とか裁判の仕組みとか知ってると弁護士と話せるとか。
世の中のためになる可能性がある
エンジニアが技術的な勉強をすると、できる技術の選択肢が増える。
ということは、それが活かせる環境なら、設計もよくなるし、コーディングの幅も広がるし、品質もあがる。
それはシステムやサービスが良くなるので、ユーザに反映される。
それは世の中のためになる。
かもしれない。
組織でまわってる以上、個人の勉強がサービスやシステムにすぐに直結はしないけど、その可能性は増えると思う。
資格試験は受かると客観的材料になる
資格試験って、その道の専門の人がいろいろ推敲して作られるので
勉強する時に体系的にまとまってるので、学ぶのは効率が良い。
けど
資格試験に合格する ＝ その知識が業務で使える
にはならない
特殊な乗り物の操作とか、医師免許とかそういうのは別の話。
そもそも資格に合格するということは
受験時に、出題された問題で、合格レベルの技能があったことの証明にしかならない。
ただ、一応、それなりの資格に合格していると
「あぁ、このレベルはあるのね」
の判断材料程度にはなる。
これが活かせる場面は僕が知ってる限り３つ。
１．社内で待遇がよくなる
２．転職活動時
３．仕事を請け負う権利
１．社内で待遇がよくなる
社内で資格推奨とか昇格要件とか、そんな感じで決まってる場合は取得すると待遇に反映される。
お金もらえる会社とかもある。
２．転職活動時
書面審査がある転職活動だと資格を持ってると有利になる場合がある。
あくまで場合がある。
３．仕事を請け負う権利
仕事を請け負う権利が発生しうるのは、
他社と連携する もしくは 業務を受注する際に
「Java Goldのエンジニアが対応します」とか
「Oracle Goldのエンジニアがいます」とか
「セキュリティの専門家がー」とか
そういう時の目安になる場合に活用される。
けど、「基本情報持ってます！」とかは経験年数を踏まえると逆効果かもしれない。
ってかそもそも別に必須でも必要でもない
どんな職業でも勉強は必要だと思うんだけど
特にITソフトウェア関連の人は必要性が高いのかもしれない。
だから
「エンジニアは勉強して当然だ」とか
「勉強すべき」とか
「常に新しい技術がでてくるんだから勉強しないと話にならない」とか
そんな話がたまにTwitterでも流れてくる。
けど、正直やんなくてもいいと思う。
やりたくないことをやるのって効率悪いし、身につかないと思う。
仕事はお金をもらうためだけって人なら、むしろ必要ない気がする。
お金もらって生活するだけなら、勉強しないで趣味とか家族と過ごすとかに注力すればいい。
まとめ
いろいろ並べてみたけど、結局は自己投資なんじゃないかな。
そこに価値があると思うならやればいい。
やりたくないのに無理したり、強要されたりするのは人生の時間が減るだけだと思う。
はい。なので結論は
そもそも好きだけど、理由をあげるなら自己投資として価値があると思うからやってます。
AppiumでAndroid driverを使うときに少しでもNoSuchElementExceptionを回避するための僕なりの方法3つ
showです。
AppiumでもSeleniumでも試験を自動化してると、でくわすやーつの代表格が
「NoSuchElementException」
だと僕は勝手に思ってます。
DOMの関係とかいろいろあって、見た目上では画面にテキストボックスがあるのに「そんなもんねーよ」とか言われるやつです。
そんなわけで、僕が最近AppiumでAndroid driverを使ってる時に少しでもNoSuchElementExceptionを回避するための僕なりの方法をとりあえず3つ書きます。
iOSはまた別の話があるので別で。
とはいっても、お仕事系は会社のブログがあるのでそっちに詳しいことは書くかもしれないので、とりあえずはざっくり。
そんなもん知ってるわ！
って人ももちろんたくさんいらっしゃると思いますが。
1．uiautomator2を使う
Android 7.0以上？ならuiautomator2が使いやすいです。
Android Studio 3.0.1で、それなりにSDKとか環境が整っていれば
capabilities.setCapability("automationName", "uiautomator2");
を宣言するだけで使えます。
これだけでだいぶ違う。
そもそもuiautomator2の前のuiautomatorが一部バグってるっぽくて、イマイチな動きをします。
ごにょごにょしたんですけど詳しく書いたらいろんな人に怒られるかもなんで詳細は今回は控えるとして
とりあえず回避できるなら「２」を使った方が良さげだと思ってます。
２．要素の取得をMobileBy.AndroidUIAutomatorで実施する
これは環境にもよりけりで、↑のuiautomator2を使うとぶっちゃけ必要度が下がるんですけども、要素を取得する際に、こいつで取得する方が成功率が高いです。※僕の環境だと。
使い方は申し訳ないですが、ご検索を。
３．ExpectedConditions.presenceOfElementLocatedを使う
ちらっとSleepとは書きましたが、何秒待てばいいかなんて、そもそもナンセンスで運要素強いと思ってます。
本来は0.1秒で読み込めるかもなのに、無駄に数秒待ったりとかは塵積って山となるで、結果的に非効率です。
性能系の試験をする場合はあえてSleepで待たせるのもアリな場合があるかもですが。
なので、非同期処理というか、
ExpectedConditions.presenceOfElementLocated
を使用してあげて、現実的なレベルだけ要素が特定できるまで待機をさせるのがいい気がします。
特に画面遷移する際に読み込むのが遅くなる画面だと効果があります。
画像が読み込みまくるとか、ネットワーク処理がたくさんある場合とかではかませます。
「いやいやvisibilityOfElementLocatedの方がちゃんと表示されるまで待つだろ。DOMの読み込みだけになるだろが」
ってのもその通りかもなので、テストケースとか仕様とか、そこらへんと調整してください。
はい。 今回はこんな感じで。
ソフトウェア品質とかテストとかの勉強会があったら、偉い人OKがでれば詳しく話せるかもなんだけども。
偉い人に聞いてみるか。。
話題の客先常駐と新卒入社の話に便乗して僕の経験を書いてみる
showです。
最近こんな記事がありました。
どうも「客先常駐」と「新卒でIT企業に入るにはうんぬん」みたいな流れに見えます。
なので、SIer、SES、Web系の順で生きている自分の経験と考えをつらつらと書いてみようかと思いました。
完全に僕の主観です。
だからポエムでしかないです。
いいですか？完全に僕の主観ですよ。
大事なことなので2回言いました。
結論から書くと
そもそも自分はIT業界（もしくはその会社）で何をしたいのか？
に尽きるのですが。
これは新卒でも、今働いてる人でも同じだと思います。
もっと抽象的になると、そもそも働く理由とは？になってきてしまいますが。
働く理由のNo.1がもし「お金」ならIT業界じゃなくてもいいんじゃないかと僕は勝手に思います。
僕が新卒として選べる立場なら
僕が新卒として選べるなら1次請けか2次請けのSIerを選びます。
※選んだけど
これは人によるし、会社によるし、配属先によるし、あくまで僕の場合ですが。
元請けになると、下請け企業の管理が多くて技術的なことよりプロマネ的なことが多いようなイメージが経験上、個人的にあります。
手を動かすならその下の1次請けか2次請けがいいかなぁと。
下手すると、技術的なことがまったくわからんけど、スケジュール管理するだけの人になってしまう。
僕が新卒でIT企業に入るときは
「研究室がネットワーク系だったからネットワーク知識・経験を活かしたい」
「かといってネットワークだけやるのは嫌だ。開発もやりたい」
「インターネットで世の中をハッピーに、便利にしたい」
って感じになって、ネットワークまわりに強く、かつ、システム開発もやってるところを当たっていきました。
会社の規模はそこまで考えてませんでした。 結果的に大企業でしたが。
IT企業およびITエンジニアという言葉は広すぎるのですが、そもそも自分が何をしたいのか。
まったく未経験の場合は、
IT企業って何してるの？
どんな職種があるの？
から調べないと、ギャップがでます。
なので、業界を調べるところからちゃんと入った方がいいです。
多重請負構造とか。
会社のシステムのユーザとの距離感とかも大事ですね。
BtoBなのか、BtoCなのかとか。
そして新卒入社の場合は日本の場合はいまだに「新卒カード」が強いと思います。
それなりに大きなSIerだと「新卒カード」が使えるうちに入社すると
それなりに教育してくれる傾向にあるようなのでSIerに入るのは悪くないと思います。
Web系企業に入ってもそれはそれはアリだと思います。
ただ、僕の個人的な経験だと、時代もあると思いますが
BtoBをやっているSIerは各種ドキュメントも成果物扱いになる場合が多いので
紙を書く習慣が身につくのと、システムを作る上での各種工程がしっかりできるんじゃないかなと。
Web系企業はドキュメント類が少ない傾向にある気がします。
アジャイルが基本なので、リリースしてなんぼなところがあるように思いますので、
ドキュメントを書いたり、テストをしっかりやったりとかはどうしても省かれ気味な気がします。
コードを書いてる時間はSIerよりは長くなるかもしれません。
SESは僕は嫌です。
配属先の運要素が特に強いですが、業務内容が限定されやすい気がします。
気がするだけです。
4か月で辞めちゃったんで、長期的な視点はわかんないです。
ただ個人的には向いてなかった。得られるものもほとんどなかった。
ただ、どの組織を選ぼうとも「教育してもらえる」という意識で入るのは受け身なので、あんまりよろしくないと個人的には思います。
どんなに会社の教育がたくさんあっても身につくかどうかは別ですし、
実務で使えるようになるかどうか、
業務以外の関連知識を自ら求めていくか、
社外の人といかに連携できるか、
そこらへんがIT関連では必要なんじゃないかと思います。
新卒はあくまで最初の会社なだけで、入ってから自分がどういう方向で仕事したいかが見えてきたら、その方向の技術を伸ばして、適性がありそうな会社に転職する時代な気がします。
自由度（勉強会に行けたり、業務以外にツール作れたり）が高いのはSIerよりWeb系かなぁと思いますが。
客先常駐の経験
■大手SIerにいた時の話
僕は新卒入社は大手SIerで、結構名前が有名な大企業に入りました。
客先常駐はその頃は僕はなかったのですが、同社内で実施している人も結構いました。
僕自身だとアメリカ、インド、ロシア、フィリピンなどに行く可能性もありました。
なので日本国外の場合もあり得ます。
また、こちらがお客さんの場合も、先方がお客さんの場合もあり得ました。
僕はプロパー（発注側）になることがたまたま多かったです。
国外は輸出入の制限とかいろいろ問題・課題があったりします。
人間は日本に来ているけど、会社が国外にあると共有できる資料に制限がかかったりとか。
国内に関しては
システムを作る上でセキュリティの問題とか
関係者がまとまってる方がコミュニケーションが効率的とか
そんな理由が多かったと思います。
下請けの会社（パートナーさんと呼んでいました）の人たちが、僕の会社に常駐して開発していることも多々ありました。
海外の会社もありました。英語でやりとりすることもあったりしました。
パートナーさんがこちらに常駐する場合は、座席やネットワークの管理もしっかりやらないといけないのでパートナーさん専用のフロアや場所があり、そこで各社ごとにグループで固まってた感じでした。
ただ、会社（人材）の能力によってランク分けがされていて重要度が高いシステムだと「ゴールドレベル以上のパートナー会社のみ提携可」とかそんなのもありました。
レベル扱いは当初「なんだそれ」って個人的には思ってましたが
やはり、レベル扱いが高い企業は提供される人材のレベルが高くて
成果物がしっかりしていたり、期日に忠実だったり、ただ言われた通りに動くだけでなく改善提案をしてきてくれたりしました。
そういう会社がいわゆる「お得意様」になって、扱うレベルがあがってました。
逆にレベルが低い扱いをされてしまっている会社の人たちは
コミュニケーションミスが多いとか、
成果物が（いろんな意味で）よろしくないとか、
レビューの手間がめちゃかかるとか、
進捗で嘘をつくとか
そんな会社もありました。
そして、僕の会社から外に行った人は自社との接点がめっちゃ減ってました。
派遣とは違うので指揮系統とかも違うのですが、ともあれ自社の上司や同僚との接点がほとんどなくなってしまった方が多かったです。
家が変わらない場合はまだマシで地方に行く場合もあり、そうなると転居かホテル暮らしかみたいな。
「長期滞在」という扱いでしたが、人によっては実質転勤、もしくは転職に近い人もいました。
何年も戻ってこないとか。。。
■SESの時の話
転職して小さな会社に入ったらいわゆる「SES企業」でした。
入社時に社長に
「うちは上流は絶対やらないよ。大変だからね。」
とか言われました。なんだそれ。
で、入社時に配属エリアを選択するシステムでした。
「東京近郊のみ」or「全国可能」のおかしな二択でしたが。
ここで「東京近郊のみ」を選ぶと給与が減ります。昇給・昇格も制限されます。
よーするに配属先が限られる人になるので、SESの人材として欠点になるからです。
すんごい嫌でしたけど「全国可能」を選びました。
これはかなりの運要素があって、自分の希望を自社に伝えても、それが叶うわけではないです。
常駐先も「東京圏内」という話だったので、ギリギリ東京と言えなくもないところに配属される人もいます。
もちろん「全国」をチョイスしたので福岡とかもあり得ました。
そして中途入社だったので教育とかも基本的にはなかったです。
配属形態としては、基本的に1名を常駐させることはないらしいですが、
新規開拓時のみ1人だけ切り込んで徐々にメンバーを増やすみたいなこともやってたみたいです。
さて、僕の場合はどうなったか。
僕はデータベースエンジニアとして、それなりに有名な会社にSESで常駐してました。
入社1日目からでしたが、誰がどう言おうとも東京と言える場所でした。
これはラッキーだったです。
僕の配属先は技術的にはOracleまわりにそこそこ触れましたが配属先によっては、必ずしも技術的なことが常にできるというわけでもなかったみたいです。
ただ、Oracleまわりとbashでのシェル作成が技術的な面で大きかったですが
配属先でしか使わないマイナーなツールを使わされたりするのが大変苦痛でした。
よそでも有用する技術がいじれたかといわれると正直Noでした。
リンクさせてもらった記事にもありますが、やはり技術的に成長できるのか、雑務が多くないのかは運要素がありました。
あくまで僕の場合はですけども。
配属というか雇用形態について、
僕の会社をA社
常駐先をB社とすると
実はB社が雇うのがC社で、C社がさらにC社の要員としてA社のうちを雇う感じでした。
となるとどうなるか。
A社用、B社用、C社用の3重勤怠管理になり、すこぶるめんどくせーことになります。
全社で記入する内容と提出時期が異なり、かつ、自社は帰宅後にネットで報告するというサービス残業が発生してました。
自社のメールも帰宅後にみるので勤怠時間に入らない。。。
また、常駐先の人B社の人は、フロア内でも携帯電話とか自由に使えましたがA社の僕や、C社の人は職場への持ち物が制限されていて携帯電話はもちろん、カバンの持ち込みも禁止でした。
職場に入るまでに通る部屋にロッカーがあって、そこにしまっておくのがルールでした。
あと、弊社は特殊？なルールがあって、うちはSES契約なので成果物の約束がないのですが、加えて残業も月にX時間までの契約になってました。
1日の残業も原則2時間まで。
それで契約を切られることもちらほらあったみたいです。
ただ、時間で雇用される扱いなので、月の稼働時間が契約時間未満になることはならない感じでした。
そして、自社の人とは同じ職場の数名以外、接点がほとんどなかったです。
退職届を出すときに初めて組織上の上司に会いました。
月に1度、東京付近の社員は東京の事務所に集まり、他拠点とネットでつないで
「全体会議」
みたいなことをやってました。
そこで会社の利益がうんぬんとか、社長の筋肉がどんだけついたかとかクソどうでもいいことを共有されました。
ただ、社内でゴルフとかビリヤードとか部活みたいなのがあって、
休日に関係者が集まって練習にでたり、大会にでたりはしてました。
あとは年に1回、全員強制参加の運動会が実施されてました。
よーするに、帰属意識がなくなってしまうので、そういう社内連携イベントがあった感じです。
そして、月～金までは配属先での業務のため
自社の研修（僕の場合はOracleプラチナ）が土曜日開催でJavaの研修は日曜日開催でした。
これは自主参加扱いなので無給でした。
僕の新卒就活
工学部の大学学部3年次に少しだけ就活して、結局修士に進学したので本格的な新卒就活をしたのは大学院1年の時になります。
そもそも修士行くか、声優になりたくて専門学校いくかとか、そういう悩みもありましたがここでは別の話。
なので修士1年の話なので、学部卒の人とは毛色が違うかもですが。
当時はぎりぎり就職バブルの頃でしたが、僕は結構本気で就活やりました。
エントリーは200社くらい、実際に訪問した会社は選考で繰り返し来訪したのもカウントすると100を超えていると思います。
最終的には大手SIerに新卒入社しましたが、他の業界もちらほら見て回ってました。
自己分析を本とか大学の就職課のセミナーとかでやったあとに
各社が「自己分析セミナー」とか「業界研究」とかそういうイベントを開催してたので顔をだしてました。
IT企業はもちろんですが、教育系、金融系、銀行系とか最初はとにかく幅広く見て回りました。
で、やっぱりIT系だなとなって、IT企業じゃないけどIT部門がある会社は選びませんでした。
社内SEとか情報システム部とかに魅力を僕は感じなかったからです。
世の中をハッピーにしたいのに社内SEってのはないだろうと。
じゃあ世の中をハッピーって具体的に何よ？
となるわけですが
修士1年当時の僕は「世の中の縁の下の力持ち」なポジションになりたいと面接とか書類とかに書いてました。
公共インフラとか、携帯電話のネットワークとか、プロバイダとか、そういう系でした。
そのために開発もネットワークもやっていきたいと志望動機を伝えていたら
それなりに結構内定がでたのを覚えています。
研究内容も災害時を想定したネットワーク形成の話だったので、そこから志望動機とか将来的になりたい自分のイメージとかを伝えることができたのが大きかったのかもしれません。
結局、新卒の就活の場合は、企業側もそこまで即戦力は期待してなくて
会社に入ることがゴールではなく、会社に入ったあとに何ができるかという人材を欲する気がします。
僕が採用側ならそういう人が欲しいですし。
その会社に入社したらこいつはどのような動きをして、どういう貢献をしてくれるのかをイメージさせることが重要なのかなと。
転職の中途入社だと今までの経歴とかスキルとかを求められますが新卒だと、
なりたい自分がイメージ出来ていて、今までこういう行動をしていた、だからできる
それが伝えられるかなのかなぁと。
今の時代なら
今の時代ならIT業界にいる人がブログを書いていたりTwitterやってたりする世の中なので直接自分から絡んでいって、業界の話とか聞いてみるのが良いのかもしれません。
話したがりの人も多いじゃないですかｗ
はい。そんな感じで。
