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

ネオキャリアグループ開発者ブログ

ネオキャリアグループの技術者による開発ブログ

インフラを主体にWeb業界の思い出を振り返ってみる

自己紹介

自己紹介

はじめまして、業界歴が20年近くなるアラフォーのポンタっす。

河野パパとは同い年です!

で、「ブログ書けよ(゜ロ゜)」って言われたんですが、最近開発とかやってないのでネタに困り思い出に浸ろうかと思います。

実際にはキレイなお姉様に「ブログ書きませんか?」って言われたので、二つ返事で「書きます(*´∀`*)b」って言ったんですがね、お姉様には逆らえません(*´ω`*)

 そんな訳で、特にインフラ屋さんではないんですがインフラを触る機会も多かったり今も触ったりするので、Web業界をインフラ主体に振り返ってみますよ! 

2000年頃 

今は亡き人生初の奉公先では、i-mode向けのサービス開発をよくやってました。

この頃のWebサービスのインフラといえば、データセンターにサーバーを設置して、1Mと10Mとかの専用線契約をしてとかが多かった気がしますが良く覚えてません。

はっきり覚えてる事と言えば、データセンターのコロケーションサービスでスペースを借りて、自前で組んだラックサーバをマウントしたりして、各種配線をどう美しくケーブリングできるかに時間掛けてたって事くらいですな。I love Panduit(○´3`)

f:id:ponta-kun:20160928172503j:plain

自前でサーバ組むのは、当時はベンダーのサーバとかはとても高価だったからなんですが、正直に言うと趣味というところが理由の大半です(*´∀`*)

LinuxRedhatが主流でしたが、なぜかTurboLinuxを使いext3の遅さに嫌気がさし、ReiserFSを使うといったことをやってました。

アプリケーションもPerlで開発してましたが、まだフレームワークとかも充実しておらずオレオレフレームワークがいくつか社内で跋扈するという感じで、カオスな環境だったなと(;・∀・)

 

続きを読む

新卒エンジニアは見た! 〜ネオキャリア開発現場の実態〜

ネオエンジニアの日常 自己紹介

はじめまして!

新卒1年目のよう太です。
今回は、私の自己紹介とネオキャリア開発チームの雰囲気をご紹介いたします!
求人情報や会社HPだけではなかなか分からない、
開発現場・開発チームの雰囲気を新卒ならでは(?)の切り口で紹介していきますので、
最後まで読んで頂けると嬉しいです!

自己紹介

あのケツの正体

改めまして、ケツ出しNGことよう太(女子)です!!
詳細はこちら

neo-developers.hatenablog.com

 

今年の4月末からエンジニア配属になりました。
学生時代は社会学を専攻し、中国移民について学んでいました。
統計学の講義以外ではほとんど計算が必要ではなく…
PCを使用するのはレポートとパワポを作成するときだけ…
コマンドプロンプトを開いたこともない…
そんな生活を4年間続けた私は


ど文系です!!!!!!(´>ω∂`)

 

やせいの 文系が あらわれた!

ど文系の私は、ネオキャリアに「営業職」として入社しました。
しかし、一ヶ月の新人研修の後「エンジニア」配属になりました。

当時の私の知識レベルは、

「なんかC言語Javaは聞いたことがある…」
「HTMLとCSSは高校の授業でちょっと齧った…」

この程度でした( ˙-˙ )

最初は「まずコマンドって何だ…」とPCの黒い画面を見ながら絶望したり、
赤文字のエラー文を見てビビり倒したりしていましたが、
周りの先輩方のおかけでなんとか1/10人前くらいにはなれたと思います…!
おそらく(´>ω∂`)

会社選びで大切なことって?

さて、就職活動が近くなると「会社選びの基準」という言葉を一度は耳にすると思います。
「やりがい」「給与」「勤務時間」「福利厚生」「職場の環境」…
例を挙げるとキリがありませんが、人それぞれ譲れない基準があるのでしょうか?

私が就職活動中に重視していたのは、

ずばり「社風」でした。

働きだすと、家族よりも長い時間を会社の人と一緒に過ごすことになると考えると、
企業風土や社員の方の雰囲気は無視できない要素の一つでした。

最優先条件ではなくても、「社風」を意識する方は多いはず…

しかし、制度で決められている「給与」や「福利厚生」と違って、
求職サイトを見るだけではなかなか理解できないのが「社風」です。

ネオキャリアの雰囲気が知りたいけど、エンジニアの情報があまり掲載されていない…
 どうしようかな…

そうお思いのあなたにm9(`・ω・´)
ネオキャリア開発チームの雰囲気!魅力!そして愉快な仲間たち!
採用HPには一切掲載されていない情報を
包み隠さずご紹介いたします!!

f:id:Yoko_Takaki:20160916074040j:plain

だがケツは隠す!!!!!!!!

ネオキャリア開発チームのご紹介

ネオキャリアの開発チームはいくつもあるのですが、
今回は私が所属しているチームのご紹介をさせて頂きます!
他の開発チームに関しては、他の方が詳しく紹介されると思いますので、
ご期待ください( ͡° ͜ʖ ͡°)

Anteleチーム

私が働いているチームは、「Antele」というInstagramのまとめサービスを開発・運用しています!

 

antele.me

Anteleチームの魅力は、ここでは挙げきれないほどあるのですが、
今回は厳選して2点、ご紹介いたします!

スタンディング!

既に河野さんがこのブログで取り上げられていましたが、スタンディングはAnteleチームの象徴とも言えるほど支持されています

Anteleチームのデスクにあるスタンディング台数は、なんと6台!
気分転換や集中力の向上、運動不足の解消など、
様々な理由でスタンディングされています!

*運動不足・ダイエットに関心がある方はこちら

₍ ( ˙ω˙) ⁾⁾

coregano.fine.me

お腹に優しい!

f:id:Yoko_Takaki:20160916075157j:plain

見てください、この胃薬の充実っぷり…
決してお腹が弱い自慢をしたい訳ではありません。
先日、私が賞味期限が切れた食品を食べて食中毒を起こし、一週間ほどトイレの神様になっていた際に先輩方から頂いたものです(´ω`)

お腹の調子を気にせず仕事に集中できます!!

ゆかいななかまたち

次に、私の同期である16新卒のメンバー7名(企画・開発職)を紹介いたします!

まずはこの5名!

f:id:Yoko_Takaki:20160916075724j:plain

右の2名はマーケティング、左の3名はエンジニア(2名)と事業企画配属のメンバー達です。
「真面目な写真を撮りたい」と伝えたら、大臣就任風に並んでくれました。
真面目さが伝わって来る一枚ですね。

f:id:Yoko_Takaki:20160916075803j:plain

真面目です。

 

続いてはこの2名!


いや、全員で写真撮ろうと思っていたものの、
時間が合わなかったから写真が分かれているとかそんなことはないですよ!

 

f:id:Yoko_Takaki:20160916080001j:plain

この二人はエンジニアで、左は以前Ansibleで燃えたまっつーです。

 

neo-developers.hatenablog.com

 

ピースを被せて「やったった」顔をしている右の彼(Sくん)も、近々ブログ記事を書くと思いますのでご期待ください!
彼の名前はその時にわかるはずです(•̀ω•́ )

 

f:id:Yoko_Takaki:20160916080637j:plain

二人で写真を撮ろうと思ったら裏切られたSくん

 

ゆかいななかま大募集


普通のエンジニアブログとは一味違う記事を意識して書いてみたのですが、
如何でしたでしょうか?(•̀•́)و

開発チームの雰囲気を感じて頂けでしょうか?

「もっとネオキャリアについて」知りたい!という方は、

弊社のHPや求人情報をチェックして下さい!

www.wantedly.com

 

 

 

これでうまくいく スマホアプリ開発 

自己紹介

ネオラボ事業部の76世代のマグナムです。

平日は、jinjer人事の開発プロジェクト、

VR系のプロジェクトマネジメント、

土日は、自分のブランドの革製品の製造、企画、販売を行う生活を営んでおります。

今回は、スマホアプリ開発のお話です。

f:id:haruhisamatsunaga:20160902083952j:plain

でも、その前にネオラボ事業部って何してるのかをお伝えしておきます。

ネオラボ事業部って?

ネオラボは、ベトナムオフショア開発・沖縄ニアショア開発・ラボ型の開発をしてます。

特長は、社員はどこで仕事しても良いことです。

ベトナムで仕事、

沖縄で仕事、

新宿オフィスで仕事、

自宅で仕事、

そう、どこでも仕事OKフリーダムです。

「子供が熱出ているので、今日は家で仕事します!」なんて融通がきく職場です。

どんなことしてるの?

常に20〜30程度のアクティブなプロジェクトが進行していて、

多くの場合プロジェクト進行管理、お客様との要件の決定や、仕様作成、デザインなどを日本側で行い、その他をベトナムや沖縄にて開発するというスタイルをとっております。

WEBシステムや、スマホアプリや、3Dビューア、360度動画再生アプリ、お話ができるアバターやら、3Dのホログラムを作ったり、、、WEBシステムも作るが箱物も作ります、、、えっと何してるんだ?

「xxやられてるんですよね?」という問いに対しての回答は単純ではないです。

当然、B2B、B2C、B2B2C、C2C など様々なビジネス形態のシステムを作っているのですが、

今回は、スマホアプリの話をしたいと思います。

どんなアプリに関与してきた?

2010年にはじめて、スマホアプリの開発マネジメントを行ってから、2011年に、スマホアプリを作る会社に入ってから、怒涛のごとく沢山のアプリケーションの開発マネジメントをしてきました。

  • 企業向けファイル管理アプリだったり、

  • 無料で動画が見られるアプリをたくさん作ったり、

  • キャリア決済と連動した動画アプリであったり、

  • 世界初のxi(クロッシー)動画アプリとか、

  • ゲームアプリだったり、

  • 音楽アプリだったり、

  • 出会い系アプリとか、

  • ショッピングアプリとか、

動画好きなので動画のアプリのことばかり覚えてます。

色々なアプリに関与してきて、

評価の高かったアプリケーションについてお話します。

評価が高かったアプリの特長

  • 企画側が本気
  • 開発側も企画側の作りたいものがどのようなものなのかを理解できている
  • プロトタイピングをする
  • 似たようなアプリがあるならば、良い部分悪い部分は研究しておく
  • 機能は沢山盛り込まない
  • Androidは後にできる状況であれば、後にする
  • 改善し続ける

上手く行かなかったプロジェクトや、上手くいったプロジェクトなど多数あります。

システム開発というものは、大抵の場合はうまくいかない事が多いのも事実です。

どうすると上手く、ぶれないものができあがるかを考察します。

さて、どうやるか?

  • 企画側を本気にさせる
  • 開発側も企画側の作りたいものがどのようなものなのかを理解できている
  • プロトタイピングをする
  • 似たようなアプリがあるならば、良い部分悪い部分は研究しておく

企画者の気合が十分で、何を作ればよいのかブレていないのが理想ですが、作りたいと思っているものはあるが、同じシステムのコピーやリニューアルでもない限り、最終形がイメージしづらいものです。

形がないものを形にしていく作業の連続です。

靴やスーツのオーダーであれば、ある程度形が決まっていて、

完成イメージが頭に浮かぶでしょう。

しかし、ソフトウェアは自由度が高いです。

プロジェクトの終盤になってから、

「あ、この機能も欲しい」「やっぱりこれも、、、」となることを体験したことがある方は多いと思います。

理由は非常に簡単です。プロジェクト終了に近づくに連れて、

全てが可視化されて、プロジェクトの理解が深まるからです。

そして、最後になって理解が深まり本気度が増すことにより、

要件が増大するという悪循環が起きます。

事前に、アプリ開発者やマネジメントを行うものは

スマホ上で動くアプリはどのようなものかを理解するべきであるし、みんなに理解させるべきです。

f:id:haruhisamatsunaga:20160901193930p:plain

Apple社が作っている資料

ユーザインタフェイスのデザインヒント

Apple社のサイトで閲覧できます。iPhoneに対してのUIの考え方が簡単にわかります。
ユーザインターフェイスのデザインのヒント

iOSヒューマンインターフェイスガイドライン

この資料について、「アプリケーション設計戦略」という章で、 述べられているアプリケーション定義ステートメントを作るという話は、 一読の価値ありです。
この資料全体はiOSの開発者、画面設計者、仕様設計者は必読です。 マネジメントを行う人は知っていると知識を広げることができます。

iOSヒューマン インターフェイス ガイドライン

でも、Androidだって勉強したい

マテリアルデザインというコンセプトが有り、現在のAndroidはこちらを参考に Accessibility - Usability - Material design guidelines

iOSAndroidの大きな差は Androidには戻るボタンがあるということ。

これにより、アプリが終了したり、前の画面に戻ったり、、、ユーザ体験が違います。 iOSしか使ったことない人は、Androidアプリをつくるときにはよく研究しましょう。

完全じゃない。企画者だって人間だもの。

これは、全てのプロジェクトに対して、経験や、想像力が異なるメンバーの集合なので、「仕方ない」ことなのです。

この「仕方ない」を、減らす努力はするべきで、デザインを先行させてプロトタイピングをすることで、ブレを少なくすることができます。

プロトタイピングというのは、完成形に近いデザインをスマホで見せるのです。

ある程度ボタンを押すと動いていくようなアプリケーションです。

この時、ボタンを押してリストがでたり、画像がでたり、映像がでたりしますが、このときはアテと言われてる本来とは異なる画像、映像を使うことが多いのですが、

アプリケーションの使い勝手などがわかります。

なぜプロトタイピングを行うのかというと、紙やPCでデザインの確認をしても

画面のサイズ感とは異なるのと、実際の画面で見ると発色も異なるため

是非、実端末での確認をおすすめします。

完成イメージに近いデザインの動きをスマホでみせるのです。

実際のスマホで動いている様子を見せて頭で思い描いている事のレベルを合わせます。

提案書では、魔法みたいなことが書かれていたが、その魔法がどのようにスマホの上で実現されるのかは、最終的にできあがる画面を見せるべきです。

ここで意識が合えば、大きなブレは減ります。

また、意識が合わなかったとしても「ラッキー」と思うべきです。

だって、リリースまであと1週間!というときに、「えっと、、、違いますね。」って言われても手の施しようがないです。

いまは、プロトタイピングをするのに便利なツールがでております。
Adobe Experience DesignはUIのアニメーションの制御(何秒でxxするなど)もできるようになっており、今後の正式リリースが楽しみなアプリです。

prott

Adobe Experience Design CC(Preview)

Adobeのツールは、iOSの標準のDesignが入っているので、非常に簡単にピコピコつくれます。開発者に説明する資料としても利用できます。(Preview版は無償で利用できます) f:id:haruhisamatsunaga:20160902091702j:plain

似たようなアプリの研究

開発するアプリに対して先駆者がいる場合には、そのアプリケーションを研究しましょう。

  • どのような機能があるのか
  • 使いやすいところ
  • 使いにくいところ
  • なぜ好かれているのか?

などを把握してみましょう。

また、常にランキング上位にあるアプリケーションはインストールして日常からチェックしておきましょう。

そうしないと、あのインスタのxxフィルターみたいなの入れたい、、、、

などと言われた時に、話ができないのです、、、、

機能盛り込み過ぎのアプリは使いたくない

スマホになって、アイコンをタップして起動するアプリケーションは、

アイコン=機能 と意識の中で使ってます。

あれも、これも、それも、、、、何でもできるんだぜ!ってアプリは、機能を呼び出すのにタップを沢山する必要があり、これが使いづらい所以です。

Androidはあとにしたい。

コンシューマ向けサービスを狙うのであればiPhoneのほうがシェアが大きく、端末の種類が少ないです。

そして、iPhoneユーザの方がAndroidユーザよりも積極的にアプリを利用します。

2016年1月現時点のStatCounter調べでは、

端末 シェア
iPhone 66.43%
Android 32.9%%

iPhoneの機種 iPhone 4S , 5 , 5S , 6 , 6S , 6plus , SE

を考えればよいですが、Androidは数百種類は存在します。

開発において大変な作業は、確認作業です。

Androidの場合には、検証費用はiOSの5倍程度に膨らむことがあります。

改善し続ける

アプリケーションを常に改善するつもりで作成しましょう。

ワンショットで作って終わりというよりは、定期的にアプリケーションを更新することを想定しておく必要があります。

コンシューマーサービスの場合には止まったら、他のサービスに追いぬかれてしまいます。

常に改善していく必要があります。

最後に

システム開発のプロジェクトマネジメント、デザイナー、開発者 絶賛大募集中です。 こちらからご応募ください。(ネオラボ希望と言っていただければ、大丈夫!) ↓

www.wantedly.com

さとり世代の俺が燃えた! 初めてのAnsible

自己紹介

始めまして!新卒1年目の松崎です。
94年生まれなのでゆとりならず最近流行りのさとり世代です!
さとり世代なので僕は旅に行くより家が好き!です!
よろしくお願いします!

ある日、Vagrant環境の構築が終わって...
現在、教育していただいている先輩エンジニアの方から
「まっつん次これやろうか!」と本を授かりました。

Ansible2 ....環境構築の自動化??
Google先生に教えてもらいながらつい先日、
何とか現在使っている環境構築は半自動化することができました!!
Ansibleを使ってみて学んだことなどを書きたいと思います。

f:id:daiki-matsuzaki:20160818204025j:plain

目次

Ansibleとは??

  • 対象サーバーに特別なソフトウェアは不要!

  • シンプルな構造になっておりhostファイルとplaybookだけで使用可能!

  • ネットワークの知識も不要で覚えることはYAML記法とコマンドの扱いのみ!

例えば複数台のPCでVagrantの環境構築を行う際に手順を間違えてインストールが抜けていたり、 環境構築に時間を取られることも....

しかし!Ansibleなら!

最初のansibleの設定をgithubなどで共有していれば、開発者が何人増えても全く同じ環境を、 時間をかけることなくカップラーメンを待つかのようにできてしまいます☆-ヽ(´∀`)八(´∀`)ノイエーイ

Ansibleの利用環境&利用方法

※今回はansibleをvirtualboxvagrantの管理構成ツールとして使いました。

実行ホスト(自Mac
python2.6以上(python3は対象外、windowsは非対称)をインストールします。

対象ホスト(virtualbox仮想環境)
python2.4以上(python3)
ssh接続が可能であること。

次にansibleを実行ホストにインストールします。

$ brew install ansible

brewを使用しましたがapt-getやpipなどでもインストールすることが出来ます。

Vagrantで仮想サーバ構築
  1. 対象ホストVagrantVirtualboxを利用しCentOSの仮想サーバーを起動します。

  2. Vagrantfileを作成しIPアドレスを割り当てます。

  3. vagrant sshコマンドでSSHログインできることを確認しましょう!

Ansibleを実際に使ってみる

ここではplaybookを簡単に書いてみます。

vagrant/
 ├ Vagrantfile
 └ provision/
    └ hosts
    └ main.yml

ざっと書きましたがMacにあるVagrantディレクトリの中に
既に存在するVagrantfileの階層にansibleのファイルを追加しただけです。

Vagrantfile
・・・・
config.vm.provision "ansible" do |ansible|
    ansible.playbook = "provision/main.yml"
    ansible.inventory_path = "provision/hosts"
    ansible.limit = 'all'
end

Vagrantfileにansibleの為の設定を追記してください。

  • ansible.playbook = "provision/main.yml"・・・後半に説明するplaybookのメインファイルを設置します。

  • ansible.inventory_path・・・hostファイルを設置します。

hosts
[vagrant]  # グループの指定
XXX.XXX.XX.XX ansible_ssh_user=vagrant ansible_ssh_private_key_file=~/.vagrant.d/insecure_private_key
  • XXX.XXX.XX.XX ・・・対象のアドレス

  • ansible_ssh_user・・・vagrantssh接続時のユーザー名(vagrantのデフォルトではvagrant)

  • ansible_ssh_private_key_file・・・vagrantssh接続時の鍵(vagrantのデフォルトの秘密鍵)

main.yml
---
- hosts: vagrant
  become: true
  tasks:
  - name: Apatchをインストール
     yum: name=httpd state=latest
  - name: Apatchを再起動
     service: name=httpd state=started enabled=yes 

それでは解説です。
- hosts: vagrant・・・hostファイルで設定したグループの設定を適応しています。(対象アドレスの記述でも可)
- become: true・・・Ansible2の変更点でsudo: trueから変更されました。
- tasks・・・実行するタスクを記述します。

例)
- name: Apatchを再起動
  service: name=httpd state=started enabled=yes 

全ての記述が終わると記述が正しく動作し指定したタスクが全て実行されるか見ます。
恐らくそれぞれやり方があると思いますが、今回はVagrantfileの記述があるので$ vagrant provision実行ホストで入力します。
その後、vagrant ssh対象ホストにログインしてApatchをインストールされていることを確認してください!

凄くあっさり書きましたがここまでが、Ansibleを実行する一連の流れです。

便利!Ansibleモジュール

全てのモジュールを挙げていたらきりがないので、実際に今回書いていて頻出したモジュールです。

モジュール名    用途   
command shellコマンドを実行したい時に使いますが、様々なサイトで使いすぎないように言われます。使うなら何度実行してもできるだけ変わらない記述をしましょう。
copy ローカルに用意しているファイルをリモートの指定した場所に置くとき使うコマンドです。設定ファイルでよく使います。
template ローカルに用意しているファイルをリモートの指定した場所にテンプレートとして生成します。変数が必要なときなど変化する設定ファイルなどに使います。
get-url httpでファイルをダウンロードする時に使います。
yum パッケージのインストールに使用します。

全て使用したわけではないのですが実際にはかなりの数のAnsibleModuleがあります。

ベストプラクティス?な階層構造

今回、かなり悩んだのがファイルの階層構造です。
AnsibleGalaxyなどの便利な機能もAnsibleにはありますが、構造の理解のために完全にファイルを手作業で作っていきました。
(全部書くと長くなるのでRuby環境のセットアップのみで、その他割愛します。)

vagrant/
 ├ Vagrantfile
 ├ README.md
 └ ansible_files/
    ├ roles/
    │  ├ Initial/
    │  │  ├ handlers/
    │  │  │  └ main.yml
    │  │  └ tasks/
    │  │     └ main.yml  
    │  │
    │  ├ nginx/
    │  │  ├ handlers/
    │  │  │  └ main.yml
    │  │  └ tasks/
    │  │     └ main.yml  
    │  │
    │  ├ rails/
    │  │  └ tasks/
    │  │     └ main.yml  
    │  │
    │  ├ mysql/
    │  │  ├ tasks/
    │  │  │  └ main.yml
    │  │  └ tamplates
    │  │     └ my.conf  
    │  └ anyenv/
    │     ├ tasks/
    │     │  └ main.yml
    │     └ tamplates
    │        └ my.conf
    │
    └ hosts
    └ provision.yml

ここで重要なファイルはprovision.ymlです。

---
- hosts: vagrants
  become: yes
  user: vagrant
  roles:
    - initial
    - mysql
    - anyenv
    - ruby
    - nginx

role

roleはplaybookを読み込むモジュールで、1ファイルにまとめると肥大化するplaybookを
ミドルウェアごとに分散して記述することができます。

roles以下のディレクトリ名と連動していて実行順序もrolesの順番通りに実行されます。

はまったポイント

1. 用意されたモジュールのなかに使用したいモジュールがない!
Ansibleは冪統制(何度コマンドを実行しても、結果が同じになる!)を大事にしている為、 できるだけAnsibleモジュールを使うことを推奨していましたが、実行するモジュールが用意されていないモジュールがありました。
これはcommandやshellを使用する際、
既にファイルが存在する場合実行しない」等の記述をして回避しました。

2. Vagrant再起動を実行中に次のタスクが動いて失敗する
vagrantCentOSを使用していて再起動が必要な場面がありました。
Ansibleで次のtaskの実行を遅らせる必要があり、そこに気づくまでハマりました...

3. handlerの実行順序がわからない
taskのnotifyでhandlerを呼び出す際に、狙った場所でhandlerが実行されずにハマりました...
後から知りましたが、全てのtaskの実行が終了した後にhandlerが実行されるみたいです。
解決策としては、現状実行順序に左右されないものはhandlerを使用し、左右されるものはtaskを使用して対処するという方法があります。

Ansibleを使ってみて思ったこと

割とはまるポイントも少なくすんなり......? 導入できたのでAnsibleすごい! となりました。
しかし、実際のところ機能のほんの一部しか利用できていません、 まだまだ道のりは険しそうです....

最後まで読んでいただきありがとうございます(´∀`*)ノ
初めてのブログということで、間違いやご指摘等かなりあると思います。
今後の為にも是非!コメントいただけると幸いです!

新しい技術や触れたことのない技術に
触れる機会を多く与えてくださる先輩方多数いらっしゃいます!!
是非こちらもチェックしてみてくださいσ( ̄∇ ̄o)
www.wantedly.com

エンジニア立ち居振舞い: ゆとり新卒エンジニアを劇的に伸ばすトリセツ

ネオエンジニアの日常 自己紹介

お題「エンジニア立ち居振舞い」に合わせて更新しました!

 

こんにちは、エンジニアのAJAです。最近マーケティングにも手を出してる平成3年生まれのゆとり女子です。嫌いなものは早起き。

今日は、新卒入社して現在3年目(エンジニア歴1年半)となる私が、どうやって育成されてきたのか、ということをご紹介します。

f:id:ajarakko:20160722021225p:plain

個人的に超まんぞくな2年を過ごしてきたな〜と思っているので、

「うちの新卒、仕事楽しくなさそう鬱になってそう」

「これだからゆとり世代ないわ〜あいつらすぐ辞めるわ〜」

とアンチゆとり世代な方、面倒くさいわーと思わずぜひ見ていただきたいです^^

ゆとり新卒エンジニアはのびのび自由にさせろ

私は営業職を半年経験した後、エンジニアになりたくなって社内でジョブチェンジしました。

  • もともと営業職、企画職として採用されている
  • エンジニア未経験だから全然使い物にならない
  • 使い物にならないどころか教育コストでマイナス

会社側からみるとこんな大迷惑な要素しかないジョブチェンジでしたが、教育コストを承知の上で、私の挑戦したいことに耳を傾けてくれたことによって、今のエンジニアとしてのキャリアがあるんだと思っています。

 

ジョブチェンジからもうすぐ2年たつけど、

エンジニア超楽しいです。幸せ。

ゆとり新卒エンジニアは突き放せ

エンジニアになって1ヶ月が経った頃、当時の上司に突然

「ベトナムで開発チーム立ち上げるんだけどさ、駐在いってみない?ひとりで。」

と言われました。

ちなみにこの時のわたしのスペックは、

  • HTML, CSS:簡単なコーディングができるようになった
  • PHP:基本の文法はなんとか。簡単な課題が実装できず、PCの前でひとり号泣。エンジニア採用の同期の説明がわからなすぎて質問もできない。
  • その他エンジニアスキル:海外開発チームとのブリッジがちょっとできるよ!ER図とかワイヤーもちょっとかけるよ!
  • 英語:高校でならったね!

という感じ。

海外開発チーム運営の難しさ、プロジェクトマネジメントの難しさなんて微塵も知らなかったので、「わーいベトナムベトナム〜」と喜んでいました。

 

無知って怖い。

 

そしてクリスマスイブに初めてのPHPを携えてベトナムに行きました。現地スタッフも「普通駐在員ってベテランPMじゃないの・・・」と思っていたと思います。

 

でもこれが、プログラミングの勉強にはとっても良い環境でした。なかでも、特に今の仕事で役立っているスキルがついた環境はこちら。

詰まったところは自分で調べるしかない

知り合いがいなかったのは、人見知りだからというのもあるんですが・・・。

プログラミングでちょっとわからないことがあった時に、気軽にきける日本人がいないので、自分でググるしかないんです。

その結果、

  • ググるスキル
  • 最初に自分で調べてどうしても困ったら先輩に聞くという、ゆとり世代には貴重な自立心
  • ググった時に見かけた周辺の知識

がつきました。

現地スタッフからの英語版プログラミングトレーニング

まったくフレームワークがつかえなかったので、現地スタッフから英語でトレーニングをうけていました。

もらう参考資料とかも全部英語だったので、英語のドキュメントに対する嫌悪感が薄れました。

 

立ち上げたばっかのチームに新人を単独駐在させるとか、下手したら拠点つぶれかねないし、今のわたしなら絶対決断できない。。

 

と思うのですが、当時こんな身の丈に合わない役を

「まあ、いけるでしょ。」

と任せてくれた先輩たちの判断に感謝です。

ゆとり新卒エンジニアが苦手なことはねちねちリマインド

ゆとりなので、こつこつ頑張ることが苦手です。日記は、気合いを入れて日記帳は買うものの三日坊主にすらなりません。

ある時、勉強のアウトプットを兼ねてTechブログを書くことになったのですが、何の気なしに「じゃあ月曜、木曜に更新することにしますね〜」といった結果・・・

毎週ブログ更新を催促されるようになりました。

サボれない・・・

 

でも催促されたおかげで(+公開した記事へのフィードバックをもらえたおかげで)、いまだにブログ執筆が継続しています。

 

このTechブログ執筆作業、

  • 「ブログ書かなきゃ」→「ネタ探そ」→「この技術ためしてみよ」というように新しい技術に挑戦してみた
  • ブログをど忘れしたときのメモ帳がわりにつかった

など、やっててよかったなあと思う機会が多々あったので、エンジニア初心者には本当オススメです。

ゆとり新卒エンジニアは大げさに褒めろ

ゆとり新卒エンジニアには、これが一番即効性が高いかもしれません。

とにかく褒めてください^^

そんな大したことないTech記事でも、アプリでも、なんでも。

とりあえず、頑張ってやったんだなと思ったら(もしくは頑張ってますアピールされたら)徹底的に褒めてください。フィードバックやアドバイスはその後にしてください。

 

思い返すと、1年半で怒られたことってなかった気がします。

正しくないことを言ったときに、「●●だからそれは違う」という指摘はいただきましたが、駐在後の1発目サービスの実装スケジュールが大遅延し日本・他拠点の全開発メンバーに迷惑をかけたときも、怒られたり嫌味を言われることがありませんでした。

これやってみたい、あれやってみたい、と提案できるようになったのは、怒られることがなかったからだと思います。

ゆとりは怒られるとすぐにやる気なくなっちゃうので。

 

その代わり、ブログ書いたとか作ってみたとか、そういう時はすごい褒めてもらえました。褒めるポイントがないかなってときは、

「えらい!すごい!しっかりしてる!」

と無理やり褒められました^^

 

褒められると嬉しくなって、次も褒められるように頑張ろう(`・ω・´)となるんです。ぶっちゃけ昇給よりもスゴいなって思ってる人に褒められる方が嬉しいです。

まとめ

かなり長くなりましたが、AJAの1年半の実体験に基づく「ゆとり新卒エンジニアを伸ばす方法」はこんな感じです。

本当に伸びてるの?そんな手間かけないと伸びないなんてryという疑問やダメ出しは受け付けませんが、楽しく仕事ができているし、範囲も広く・深くなってきているので、多分伸びてるんだと思いますよ^^

 

こうやってみると本当に新卒の教育ってコストがかかるんですね。自分にしてもらった分、これからの後輩たちに返していこうっと。

 

ちなみに・・・

たくさん褒められながら働きたいゆとりに朗報(`・ω・´)

新卒採用やってます(第二新卒・既卒もOK)

超絶優秀な先輩エンジニアの知識と褒め言葉を独占しつつエンジニアになりたい人、かもーん。

静的WEBサイトならcapistranoとS3で運用作業からもっと解放される

概要

どんなにシンプルなWEBサイトであっても、グローバルIPアドレスを持つサーバーを準備、公開し続ける限り運用、キャンペーン施策をやるなら負荷対策が必要でした。AWSが静的WEBサイトのホスティングをS3で提供したことでこれらから解放されました。この記事では開発サーバーから本番サーバーの代わりとなるS3バケットへのデプロイ方法を記載します。

 

方法

デプロイにはCapistranoを使用し、開発サーバー内にデプロイが完了した(deploy flowが終了した)時点で公開用バケットにAWSコマンドでsyncさせます。

 

具体的には以下を設定します。

・本番サーバーの代わりとなるS3バケットで作成・削除等可能なIAMを設定します。

・開発サーバーで使用するデプロイユーザでaws configureコマンドで上記IAMのAccess KeyとSecret Access Keyをセットしておきます。

・deploy.rbのnamespace :deploy内に以下を追加しておきます。つまりproducionを引数にした時には当該バケットに同期されるようにします。

  after :finished, :rsync_s3 do
    if "#{fetch(:stage)}" != "staging"
      on roles(:web) do
        execute "aws s3 sync #{fetch(:deploy_to)}/current/ s3://バケット名/ --delete"
      end
    end
  end

 

結果

cap production deployコマンドを実行すると、開発サーバー内のdeploy_toでセットしたパス(deploy.rbのdeploy_toで設定)にソースコードが展開され、そしてS3(s3://バケット名/)へ同期がされます。

 

終わりに

AWSは動的サイトもサーバーレス構成を可能とするようになり、ますます運用から解放されてサービス開発に集中できて嬉しいですね。

現在、私は"jinjer労務"というサービスに取り組んでいます。jinjerとは人事領域のデータを横断的にマネジメントできるプラットフォームです。詳しくは以下をご覧ください。

hcm-jinjer.com

Posted by Yoshihiro Noumi

 

はじめまして

自己紹介

株式会社ネオキャリアの経営企画部の河野と申します。

今回、弊社の主にITエンジニア(リング)を知ってもらおうとエンジニアブログを始めることになりました。

その第一回目になるのですが、とりあえず僕の自己紹介と弊社の紹介をさせて頂こうと思います。

続きを読む