人材紹介エージェントから事業会社のエンジニア採用担当に転職した話
とっってもご無沙汰してしまったわたしのブログですが、
意外と訪問者がおり、月に100〜200件くらいいるんですよね、感謝！
今は技術力の高いエンジニアがわんさかいる企業にいるので、
その話を書いていこうかと思っています。
その前に、そもそもわたしがエージェント会社から事業会社の人事に転職しようと思い立った経緯をせっかくなので書いておきます。
主な理由
日本のIT業界を変えていきたいという気持ちが強くなり、
今のエージェント業では限界があると感じたから。
もちろん長時間残業がきついとか、評価制度が属人的とか副次的要素はあります。あしからず
わたしが在籍していた企業は、他の人材紹介会社よりかは断然人に向き合い、
支援している会社でした。
エンジニア達の次のキャリアを創造するのは我々であり、P社やR社には負けない自負がありました。
また、わたしは元々SI企業は好きではないので、
自分の担当企業も４名のスタートアップ企業やベンチャー企業、大手であっても新規事業チームへの支援など
エージェントからしたらまじで嫌う（≒決まらない企業と見られがち）トンガリ系企業ばかりを担当していました。
なので、毎月毎月超辛かったです。
簡単に決まる特定派遣常駐企業や微経験受け入れるSI企業などほとんど持っていなかったです（100社中2社とか）
スキル要件高すぎるか、ブランディングほぼ０の企業で決めていくのはとっても大変でしたが、
それを上回るようにめっちゃくちゃ楽しかった。
わたしが、この企業を大きくしたと自信をもっていえる企業が本気でありました。
大手SI企業に一人決めるインパクトはそこまで大きくないけども
10名満たない企業に一人決める事業成長インパクトはとてつもなくでかい。
4名の会社に2名入社支援するなど、そこに貢献できたと本気で思えました。
本気で向き合った結果は売上にも反映し、事業部が持つ売上ギネス記録を二ヶ月連続で自分で塗り替えることもできました。
しかしながらやはり葛藤もあります。
人材紹介ビジネスは年収の数十パーセントを手数料としてもらう仕組みです。
そのため、月末までに計上したいという気持ちが先行し求職者のためにならない行動に出てしまうこともある。
また、残念ながら日本のIT業界の約8割はSI企業であり、
わたしの保有クライアントではスキル要件が全く合わない流入が多くなり、
仕方なく特定常駐派遣の企業や微経験受け入れるSI企業を開拓するなども行わざるをえなかった。
本気でエンジニアに向き合いたいなら、そもそもの仕組みを変えていかなければ無理。
情報感度をより高く持ち、間違った企業を選ばずに住む世界を作りたい。
他の先進国に負けないレベルでエンジニアや企業の価値を高めていきたい。
そして日本のSI構造をぶっ壊したい。
注:すべてにSI企業が悪だとは思っていません。あくまで構造
この気持ちを無視することができず、転職を決意しました。
おそらくこの気持ちは人材紹介を生業としているRA,CAのみなさんなら理解してくれると思います。
転職先の事業会社ではエンジニアの採用を行っています。
まだまだ小さな、発展途上な企業ですが、プロダクトへの想いとコミット力が強い会社です。
同じ人間とは思えないほど優秀で尖りまくっているエンジニア達が、今後どのようなわくわくを創り上げていくのか。
それはまた次のお話で。
SEが懲戒解雇されたコワイ話
軽はずみなひとつの行動で
人生狂わすことも
明日あり得るなと思った話。
-----
SI企業に勤務しているインフラエンジニアA君のお話
A君の担当は、有名大手企業のサーバ周りの構築請負
事件の当日も、
企業のデータセンターでの作業があり、
セキュリティチェックを受けてデータセンター内へ入室。
いつものように作業していると、
あ、ヤバイ。
携帯の充電切れる…！
見回すとコンセントアダプタはない。
そう、データセンターにアダプタがない現場は多いのだ。
だからといって作業するときに調べ物ができないと業務に支障がでてしまうこともあり
電源落ちはかなりのピンチ。
A君『あのー、すみません、
どうしても充電切らすわけにはいかなくて、
今日だけ特別にこのサーバにUSBケーブル挿していいですか？』
企業担当者『んー、本当はだめですけど、
まぁいいですよ！』
と許可をとり、充電しながら作業再開。
しばらくして、
いつもは滅多にデータセンターにこない部長が来て
こんにちはと挨拶、しようと思ったら
部長『何でサーバに携帯挿してるんだ！！！何考えてるんだ！！！』
と激怒&大炎上。
その場の謝罪では収まらず、
この問題はSI企業側の役員まで議題があがり、
結果、A君を懲戒解雇するという形で鎮火。
懲戒解雇は解雇の中でも、最も重い対応である。
現場担当者がどれだけいいよって許可くれても
そもそもの契約書内容でアウトな事例た。
ちなみに、絶対やってはいけないことと分かっているが、
サーバで充電したくなった気持ちはわからんでもないらしい。
パソコン持ち込みできないし、
携帯貸してくれないし、
コンセントないし。
すぐ終わるし大丈夫だろ
別に悪いことやろうとしているわけでないし
現場担当に許可取ったし
という考え。結構やりがちではないか。
あーあ、やっちゃったねって思う人こそ
次やる予備軍。
セキュリティ意識は常に、当事者意識とともに
持たなければならない。
改めて身の回りのセキュリティ意識を徹底しなければとおもった
今日この頃。
ガクブル
なぜ炎上プロジェクトはなくならないのか？
私はよく思う所があるんです。
IT業界に入り早くも２年が経とうとしているこの時期に。
『炎上プロジェクトに参画していて毎日２２時帰りで面接行けません』
なんで炎上しちゃうの？
『仕様書なくて、ソースコードから読み解いて解決してます』
なんで仕様書ないの？
『テスト段階でバグ大量発生して帰れない（涙）』
なんで開発前に防げないの？
何故デスマプロジェクトはなくならず
何故仕様書通りにつくったものが動かない？
何故若手エンジニアが酷使されていて
何故ユーザー企業は文句ばかり言うのだろうかと。
その大元の理由を大手SIer勤務の遥くんに聞きました。
※非エンジニアのブログなので超要約してます。間違ってたらご指摘ください
遥くん
『それは要件定義をしっかり行わないから。』
もう少し詳細かつ非常に乱暴に再現すると、こんな感じ。
↓
ユーザー企業『2018年３月にリリースするシステム作りたい』
多重請け構造の中でもTOPのSIer『どんなシステム作るんですか？要求定義から始めましょう。』
ユーザー企業『担当部門に詳細聞いておくわ』
TOP SIer『わかりました。ヒアリング結果を2017年4月3日までにその要求ください。』
・
・
・
4月3日当日
TOP SIer『担当部門からのヒアリング状況如何でしょうか？』
ユーザー企業『あ、まだ返ってきてないわ。』
TOP SIer
『。』
その下請けSIerに『ちょっとスケジュール押してるから待っててな。』と伝える
下請け企業『。』
↑
文句言いたくても言えないのである。
それだけSIerの立場が弱いから。
ユーザー企業の動かす金はおおきければ数千億にもなり、SIerはユーザーのミスであってもNOと言えない
言いたいことも言えないこんな世の中である。
スケジュール通りに動いていたら要件定義が始まる期日になり、
ユーザー企業『要求定義できたで。ほらよ！』
TOP SIer『（すでにスケジュール押してるな…下になんとかやらせよう）ありがとうございます！』
といった具合で、最も重要な『何を解決するために、どんなものを作るのか？』が抜けた状態で無理やりプロジェクトが走り始めるのである。
ということで、だいたいの炎上プロジェクトは、要件定義を行っている段階で見抜けるものなのだ。
しかしそれを隠したまま基本設計、詳細設計、各パーツの開発へと進んでいく。
そして大規模案件であればあるほど担当部署は細分化され、
TOP SIer『こんな感じで要件きてるからよろしく。』
ユーザーには『順調です』と言う
要件定義担当SIer
『（スケジュール押してるやん。てか要求定義ずさんすぎ）』
『これが要件定義書です。（ずさんで絶対あとから揉めるけど）』
ユーザーには『順調です』と言う
基本設計担当SIer
『（ずさんだな…絶対あとで炎上するけど指摘したら自分達の責任になるからなんとか形作ればおけ）』
『基本設計できました（あとはよしなにやってくれ）』
ユーザーには『順調です』と言う
詳細設計担当のSIer
『。』
『詳細設計です。開発担当の皆さん宜しくお願い致します。』
ユーザーには『順調です』と言う
項目ごとに割り振られた開発担当のSIer複数社
『。』『。』『。』『。』
『。』『。』『。』『。』
『。』『。』『。』『。』
・
・
・
～～～ここでテストスケジュールも後ろだ押しされる～～～
2018年3月某日
開発担当SIer
『『『できました！納品します！』』』
単体テスト、結合テストなど手順を踏まずいきなり受け入れテストを行う
結果・炎上。
各担当のSIer達
『『『複雑すぎて、どこにミスがあったのかわからないので責任負えません』』』
といった具合で逃げる（本当の話らしい）
上記のようにユーザー側の非協力的な態度や、自分の所さえなんとかなればOKという考えから、
要件定義⇒基本設計⇒詳細設計⇒開発⇒単体テスト⇒結合テスト⇒総合テスト⇒受け入れテスト⇒リリース
といったやり方が
要求定義⇒⇒
要件定義⇒
基本設計・詳細設計⇒
開発⇒⇒⇒⇒⇒⇒⇒⇒
（各テスト省略）
受入テスト
という風に、各工程が重なり合ってぎりぎりのスケジュールで行っている。（本当の話らしい）
なぜ元凶である要件定義はいつの世も蔑ろにされるのか？
■そもそも技術がわかる人がいない
■ベンダーに丸投げ体質
■各部門が仲悪すぎで自分の仕事しかしない（関連作業を怠る）
■中立の立場であるコンサルは結局ユーザー立場なので、上手くいってなくても『概ね順調です』と言い張る
色々理由はあると思うが、
結局のところ、
ユーザー側に、自分達のシステムを作っているという認識がない。
これが全ての元凶である。
自分たちが使うシステムを作っているという認識ではなく、
上から与えられた仕事をとりあえずこなすからこうなる。
ユーザー企業のメンバーに主体性がないから部門間で仲悪かったり
非協力的だったりする。
そして、そこにNOといえないSIer構造の日本が
炎上プロジェクトを盛り上げる拍車となっている。
責任のがれ、自分だけいい顔しては良いものは作れない。
主体性を持った行動こそ、
『自分たちのシステムをより良くつくる』ことに繋がる。
なので、アメリカのように、
SIerに頼らず自前で作ることが当たり前の世界にしたいと想う。
IAAS PAAS SAASとは？
やっと技術にも慣れてきて、
ドヤリながらAWSのEC2を使ったり
少しずつポテンシャルエンジニアとしてそろそろ転職できるんじゃないの？！
とか思うのは早急であり、
それは、
実際に声かけたことないけど、
恋愛マニュアルHOW TO本を100冊読破したからイケメンと簡単にお知り合いになり
付き合えると思ってるくらいの勘違いさんである。
その勘違いさんから脱却すべく、今日もエンジニアリング実践に励む。
重要なのは、インプットではなくアウトプット。
もっと開発が楽になるよう、クラウドの開発統合環境のCloud9をMacちゃんにインストールした。
※非エンジニアの超要約ブログです。間違ってたらご指摘ください。
今までは、家ではエディタはAtom使用、
会社ではSublime textとサクラエディタを使用しデスクトップに保存していたが、
クラウド上で開発すればより楽なんでない？
と思い、クラウド化を実行。
Cloud9とは？
簡単に言うと、ブラウザ上で動き、PCに依存することなく開発ができる
最強プログラミング開発環境のことである。
きっとエンジニア初心者ならこういう疑問がでるであろう。
何が違うの？
よくわかんないしIT難しいし、なんかもう眠くなってきたわ。Zzz...
という人向けに書いている。
今回も、もちろんプロのエンジニアの方にはご遠慮いただきたい内容である。
その点、Cloud9は上記のPAASまでできている。
MySQLもPHPも実行環境もあるし、最初から全部準備されている
あとは自分で書くだけという開発統合環境である。
なんとなくやれることが違うのはわかったけど、
IAAS,PAAS,SAASって、それぞれなんなの？
もっと超要約してくれないとイミフだし眠ぃZzzzzz....
という人は下記参照。
超要約・それぞれのas a Serviceの違いとは？
私『そうだ！
渋谷まで2時間もかかる田舎から脱出して、イケメンが集まる東京に住みたい！』
と一念発起し、全財産を持ち出したとしよう。
そして、
私『どのへんに住もうかな』
と考え、不動産に話を聞きにいった。
不動産屋『イケメン探しに上京ですか（苦笑）頑張ってくださいね。
で、今すぐ住みたいなら、家具付きの部屋にします？（Software as a Service）
家具とか揃えたいなら、この賃貸物件どうです？家具選び楽しみですね。（Platform as a Service）
え！？10億円持って上京したんですか！？なんなら自分で家建てちゃいます？（Infrastructure as a Service）※土地は購入しない』
この違いがIAAS, PAAS,SAASの違いである。
AWSなら全て提案できる不動産屋さんで、Cloud9なら、賃貸物件のみ扱っている不動産屋さんということになる。
AWS上のイメージでは
IAAS…EC2
OSレベル以上のサービスであり、自分で色々構築したりカスタマイズできる。
超要約→土地貸してあげるから、家は自分で好きなように建てていいよ！
PAAS…RDS
ミドルウエア以上のサービスであり、中身のアプリは使用できるが、本体のデータや仕様はカスタマイズ不可
超要約…家は貸してあげるから家具は自分で選んでね。でも、柱切ったり壁を塗り替えたりしちゃダメよ。
SAAS…AWS上に構築されたサービスがすでにあり、すぐに使える状態
超要約…家具も全部あるから、今日から住めるよ。
家のことは心配せずにバーに行ってイケメン探しておいで。
って感じ。
用意されているものが多ければ多いほど簡単に開発できるけど
慣れてきてもっと自分色に染めたいな…とおもってきたら
０ベースから構築すれば良いと思う。
ということて、初心者は簡単なものからどんどん使うべきだ。
WEBサーバの三段階構造について
前回はLAMP環境のお話したので、
今回はWEBサーバについて。
正直、実際にLAMP環境を作ってください！と言われても
どのような構成で作るのかは、色々と選択肢がある。
そういえば、そもそもWEBサーバって何やねん？
それさえあればインターネットで何でもできるの？
という人用にブログ書いてます。
古参はスルーしてください。
間違ってたらご指摘いただけると嬉しい。
基本的に、WEBサーバは三階層構造で作られている
・WEBサーバ（Apache,Linuxが入ってる）
・APサーバ（PHPとLinuxが入ってる）
・DBサーバ（MySQLとLinuxが入ってる)
LAMPについては前回の記事を参照。
なんでひとつにまとめられないの？
まじ意味わかんないし、ITって面倒くさいわ。
っていう人は下記参照
今回は下２つのお話。
①webサーバ→インターネットの受付場所
apacheやNginxなど
例）
暇だな…暇つぶしに２ちゃんねるでもネットサーフィンするか。
といって、アクセスするドア
これがないとサイトの存在を知っているが、つなぐことができない
Apacheについては前回の図書館のドアを参照
②APサーバ→ぽちぽちタップすると色々とページだしてくれる行動の場所
JavaやPHPで実際に作ったアプリが動く場所だと思ってください。
③DBサーバ→資料の保管庫
MySQL,PostgreSQLなどのデータベースが実際に動く場所
インフラエンジニアのよく言う『自己研鑽』は上記サーバを立てたりしていること。
サーバの実機を購入したりクラウドサーバ使って、自分で組み立て、物理的設計、論理的設計したり。
中にLinux入れる？？WEBアプリ入れる？データ出し入れするからデータベースも作る？
みたいな。
OSはデバイスとユーザーを仲介しているのみのもの。
上記の環境構築は、それぞれ３つのパソコンに分けてサーバを立てても良いし、
1つのパソコンに全部入れても良い。
<お金がない場合:主に個人>
一つのMacbook（物理サーバ）の中に、LinuxOSをインストール。
このOSの上にWEBサーバー、APサーバ、DBサーバ全部インストールし
もともとのMacbookの容量を使ってアプリを動かしている
メリット：コストもかからず、管理も楽チン。
デメリット：容量大きいパソコン使わないと、すぐにメモリいっぱいになっちゃう。
<お金がある場合：主に会社>
それぞれの物理サーバを立てているため、３つの種類のサーバが出来上がっている
※超売れっ子のパズドラやモンストのサーバは１，０００台単位である。
一台のサーバに裁く容量決まってるのでたくさん必要なのね。
ではなぜWEBサーバー、APサーバー、DBサーバーと分けた方がいいの？
メリット：
①通信スピードの速さを守る。
DBサーバの負荷がかかりすぎると、道連れみんな動きが遅くなるけど、
分かれていたら負荷の道連れがなくなる
②物理サーバーが壊れた時に他サーバを守る。
例えばMacbookちゃん１台でサーバ立ててた時に、いきなりお亡くなりになったらみんな壊れてしまうが
分かれていたら、ほかのサーバーは生きのこれる。
壊れたものだけ立て直せばOK
デメリット：金かかる
じゃあクラウドサーバは？
例えばAWSなら有事のときにも備え複数のサーバに同じデータを保存してるので
壊れてもデータがなくなる危険性が非常に低い。
（100％ではないが、それにできるだけ近しい）
って感じ。
LAMP環境とは
みなさんご存知の iPhoneのアプリやネットのサービス、システムたちは
全てエンジニアの汗水たらしながら（リリース前は白目むいて徹夜しながら）作り上げた
涙と寝不足の結晶である。
では、そのサービス達って、どうやって作られているのか？
IT業界入るまでは
『は！？なんで繋がらないの？意味わかんないしこのサービスまじ使いにくい』
みたいなこと普通に言ってた気がします。ごめんなさい。
では、そのエンジニアの努力の結晶はどのように反映されて
我々のPCやスマホの中に反映されるのか？
簡単に言うと、データをたくさん貯める箱を作り、
インターネット回線を使って（ネット使わないこともある）
それを出し入れしたりする指示を書いている。
という感じ。
その王道バリューセットが、よく言うLAMP環境である（今この例を出すのはいかがなものかという議論は無しです
そして、
これからプログラミングを学んでいこうと思う人達の、最初の登竜門が
LAMP環境)での開発勉強になる。（多分）
そもそもLAMP環境とは何？
↓
ググるとこう出てきます。
『LAMP環境とはWEBシステムを作る際に使用するツールの頭文字のこと。』
Linux(WEBサーバのOS)
Apache(WEBサーバ)
MySQL(データベース)
よくわからないですよね。
なので
超要約LAMP環境とは ↓
Linux＝図書館 Apache=図書館の玄関 MySQL=本と本棚 PHP=図書館のスタッフ（司書）
となります。
＜例えば＞
『そうだ、少年ジャンプの初回創刊号を読みたいから、国立図書館に借りに行こう。』
とします。（本当にやったことがある）
がしかし！
ど、ドアがない！
え？なんでドアない？？？？？？？？？
ってなったら図書館入れないじゃないですか。
なので、図書館(Linux)に、ドア(Apache)を作ってあげるんです。
このApacheが、みんなが見たいサイトの入り口を作るわけ。
ふぅっ！
やっと図書館に入れました。
よーし！
受付で頼んでジャンプを書庫から出してもらおう！
と思ったら、、、、
受付誰もいないし。
しかも、え？？？
ほ、、本棚が、ない！！！！！
見渡す限り本が山積み状態やねん！！！！！！！！！！
１２００万冊の山の中から少年ジャンプ創刊号とか探せないじゃないですかー！
とか無駄に叫んでも無駄であり、
もし探してたら人生かけても見つからない。
ってなりますよね。
そうならないように本は本棚（MySQL）に収めるんですよね。
がしかし、
でも、ここでたとえば漫画、小説、史実書とかカテゴリ詳細分けないで、
まさかのあいうえお順だけで整理整頓しちゃうと
『し』から始まる本、３００万冊あるじゃん！！！！！
とかなること必至ですよね。
だから、速攻でお目当の本を探せるように、
きちんと作品やカテゴリ、年代などの詳細カテゴリをしっかりと仕組み作りを行い
（MySQLのチューニング）
司書さんが簡単に検索できるような指示やマニュアルを用意しておくんですよね。（PHP言語）
まとめると、
図書館（Linux）で
ドアを叩き（Apache）
司書さん（PHP）が検索指示を出し
本棚から本を取り出す（MySQL）
この一連の流れで図書館から本を借りる
（WEBサービスを利用する）のである。
では、何故このいわゆるLAMP環境が一般的なのか？
正直なところ、LAMP環境でなくても、他のものでも良いんですよね。実際は。
例えばOSはwindowsでもいいし、PHPの代わりにPyhonでもいいし、Apacheの他にIISを使用してもOK
それぞれの機能を果たしていれば問題ない。
あくまでもLAMPは手段である。
それでもLAMPが一般的なのは、
①普及しているから
みんな使ってて安心だからってやつ
②みんなが使用している環境が多いから、バグが事前につぶされている可能性高いから
初めて歩く道でも、草木が生えてなく歩きやすい感じ
③学習コストが低いから
すでに多くの情報がたくさんあり、使いやすい環境があるし、
ネット検索も書籍もたくさんある。
④全部無料で始められるから
やっぱ重要。
ということは、
これに尽きる。
次回はWEBシステムは三階層構造の話
VMwareとは
やっと開発エンジニアとはなんぞやということがわかってきたころ
その事件は起きました。
それはある日のカウンセリング共有のこと。
リーダー『朝会はじめまーす。本日のカウンセリング共有お願いしまーす』
アドバイザー『１７時に◯◯さん来社です。
この方はVMwareを中心に仮想環境の構築していた方ですね』
とアドバイザーが。
は！？
仮想環境って、何や？？？？
とググった結果
仮想化環境とは、コンピュータ上にソフトウェアによって仮想的に構築されたコンピュータ（仮想マシン）が備える仕様や機能の総体のこと。
ハイパーバイザ型の仮想化では、コンピュータ上にハイパーバイザが仮想マシン（VM：Virtual Machine、バーチャルマシン）を構築し、その上でOSなどのソフトウェアが実行される。ソフトウェアから見ると仮想マシンが物理的なコンピュータ本体のように見え、その提供するCPUやメモリ、ストレージやそれらの仕様・機能などの資源の総体を仮想化環境という。対義語は物理環境。
コンテナ型の仮想化では、元になるOSの一部を分離して他と隔離された専用のエリアを用意し、その上でアプリケーションソフトが実行される。その際の隔離されたエリアがOSとしてアプリケーションに提供する機能の総体のことを仮想化環境という。
なるほど。
しっかりと意味不明である。
ということで、変態データベースエンジニアの山田くんに聞いてみた。
VMwareとは？
うーん。。
ミニパソコンがたくさん入る意味がわからないので、
あー、なんかわかってきた。
現実の世界で考えると、こんな感じである。
メッセージが気持ち悪くなってきたのは無視。
↓
↓
お、なんか理解できてきたが、
まだ何故複数OSを入れるメリットがあるのかが理解しきれない。
ので、
なるほど。
よって、自分なりに超要約してみた。
