
今夏、我が家に初めての赤ちゃんが産まれる予定なので色々と準備をしているのですが、
今までどおりの勉強時間が確保はできなくなるのは簡単に想像できます。

不安に思ったエンジニア1年生の僕がこんなツイートをしたら思った以上に反応いただけたので、
ブログにまとめておこうと思いました。

```twitter
https://twitter.com/seventhseven/status/1149117945068449792
```


以下、教えていただいた方たちのツイートをご紹介します。


## きっかわさん

```twitter
https://twitter.com/kikkawapapa/status/1149124726939193344
```

いつもお世話になっているきっかわさん。
家族第一で家事もお仕事もバリバリされている憧れのエンジニアさんです。

フルコミットで家事をやられているとのことなので、
吸収するスピードと深さは領域を絞ることで担保されているようです。

## えぐちさん

```twitter
https://twitter.com/egu777/status/1149119447786913793
```

ベテランエンジニアのえぐちさん。
やはり一緒に寝てしまうだろうなぁと思うこちらのツイート。
自分の体力との相談だなぁと思います。

1歳のお子さんがいらっしゃるようなので、ぜひ色々お話をお聞きしたいです。。

## isa_minさん

```twitter
https://twitter.com/isa_min_/status/1149120146968961024
```

日本に来られて10年になるisa_minさん。
エンジニアになられたのは39歳からとのことで、最近Webエンジニアになられたようです。

isa_minさんもお子さんを寝かしつけてからされているスタイルのようです。
フロントは技術の流れが早く、キャッチアップし続けるのが難しい部分もあるので、
スキマ時間をいかに使うかが大切ですね。

## なかちゃんさん

```twitter
https://twitter.com/nakasin52/status/1149265661907963904
```

長野でフリーランスエンジニアのなかちゃんさん。

なかちゃんさんもお子さん寝かしつけ後のようですが、
冬以外は朝5時に起きてから勉強されている朝活スタイルとのことで、
朝に弱い僕にはなかなか真似できなさそうです。。

## さくらさん

```twitter
https://twitter.com/sakura_engineer/status/1149274190219902976
```

3人のお子さんを育てるシングルマザーのさくらさん。
フロントエンドでバリバリやられてるフリーランスママさんです。

ここまで来ると効率化の鬼だと思われますので、
ぬるいこと言わず頑張れと思わせてくれるような力強さも感じられます。

そして続きのツイートで奥さんをケアするようアドバイスも頂いたので、
これまで以上にいたわるつもりです。

## Suzakingさん

```twitter
https://twitter.com/szaking/status/1149163479661551616
```

Suzakingさんもフロントエンドの方で、1歳になったばかりのお子さんをお持ちのエンジニアさんです。
やはり通勤時間がキモになってくるように思います。

勉強のスタイルも本なのかブログなのか動画なのか、今はいろいろなサービスもあるので、
自分にあった勉強方法を編み出していかないと辛いですね。

## TAKASHIさん

```twitter
https://twitter.com/cloverkizuna/status/1149284619008667648
```

個人開発者のTAKASHIさん。
働きながら子育てもして、さらに個人開発もやるという、自分が今一番目指してるようなスタイルです。

やはり時間の節約・効率に命かけてるところがあり、
- 髪は短くして極力セットしたりする時間はなくす
- 服は決まったものしか着ない
- 家事は家電に任せる

など、参考になるTIPSが色々とあるブログを紹介していただきました。

僕自身はシンプリストなので、私服の制服化などは済ませているのですが、
どうしても気力と体力を言い訳に効率が落ちてしまう部分があるので、
仕組みでカバーしていきたいと思いました。


## りらぞうさん

```twitter
https://twitter.com/rirazou_/status/1149289587493101569
```

色々な言語を使いこなす1歳半のお子さんをお持ちのエンジニアのりらぞうさん。
りらぞうさんも通勤時間は勉強にあてていらっしゃるとのことで、
やはりどうしても子育てしながらですと限られるようですね。

りらぞうさんも模索中とのことなので、なにか編み出されたら教えてください！

## 勉強法はぜひぜひ募集中です！

みなさんでシェアして効率のいい開発者人生を歩みたいです。

**そして奥さんのねぎらい方もシェアしましょう！！！！**

子持ちエンジニアの方に質問！勉強時間はいつ？


こんばんは、Shumpei[(@seventhseven)](https://twitter.com/seventhseven)です。
今回は、フロントエンド定番のビルドヘルパー**Gulp**についてのお話です。

ビルドヘルパー（ビルドシステム）とは、コンパイルやファイルの更新などを感知して、
ブラウザのリロードを自動でしてくれたりなど、
面倒なタスクを任せられるシステムです。

node.jsで動くので、バックエンド用に新たにサーバを立てる必要もありません。

圧縮して、結合したり、ソースマップ作ったり、ブラウザの更新をしたり…
そんな作業をgulpにやってもらいます。



## npmでインストール
鹿野 壮さんの[最新ビルドシステムGulp 4入門 〜環境構築からタスク作成まで〜](https://qiita.com/tonkotsuboy_com/items/9ab83fe0f25cf0b010f3)を参考に、
コマンドでちゃちゃっとインストールしちゃいましょう。

```
$ cd /Users/myproject

$ npm init -y
# -yはインストールの際の質問に、入力しなくてもすべてyesと答えるオプション

$ npm install gulp -D
# -Dは--save-devの略。ローカルにインストールしてこのプロジェクトのみ使用します。

$ npx gulp -v
# バージョンの確認
# 
# グローバルにインストールしなかった場合、
# 通常はpackage.jsonにnpm scriptとして
# gulpコマンドの使用を書かなくてはいけないのですが、
# npm5.2.0から「npx」コマンドを使うことで、グローバルと同じふるまいをしてくれます。
```

## gulpfile.js

さて、下記に紹介するのは自分が使ったgulpの設定です。

**pug + sass + javascript**

の更新をwatchで監視しながら、ブラウザシンクで自動でブラウザをリロードするようにしています。

※requireで書かれた部分はgulpのプラグインになりますので、
別途インストールが必要です。

```js
// gulpプラグインの読み込み
var gulp = require("gulp");
var browserSync = require("browser-sync").create();


// sass系
var sass = require("gulp-sass");
var autoprefixer = require("gulp-autoprefixer");
var plumber = require("gulp-plumber");
var sourcemaps = require("gulp-sourcemaps");
var progeny = require("gulp-progeny");


// js系
var concat = require("gulp-concat"); // ファイル結合
var jshint = require("gulp-jshint"); // 構文チェック ※別途gulp-jshintとjshintをインストールする必要がある
var rename = require("gulp-rename"); // ファイル名変更
var uglify = require("gulp-uglify"); // ファイル圧縮


// sass
gulp.task("sass", function() {
  return gulp
    .src("src/scss/style.scss")
    .pipe(plumber())
    .pipe(progeny())
    .pipe(sourcemaps.init())
    .pipe(
      sass({
        outputStyle: "expanded"
      })
    )
    .pipe(
      autoprefixer({
        browsers: ["last 2 version", "iOS >= 8.1", "Android >= 4.4"],
        cascade: false
      })
    )
    .pipe(sourcemaps.write())
    .pipe(gulp.dest("dist/css"));
});


// JS - concat js files
gulp.task("js.concat", function() {
  return gulp
    .src(["src/js/*.js"])
    .pipe(plumber())
    .pipe(jshint())
    .pipe(jshint.reporter("default"))
    .pipe(concat("bundle.js"));
});


// JS - compress js files
gulp.task("js.compress", function() {
  return gulp
    .src("dist/js/bundle.js")
    .pipe(plumber())
    .pipe(uglify())
    .pipe(rename("bundle.min.js"))
    .pipe(gulp.dest("dist/js"));
});


// Browser Sync
gulp.task("server", function(done) {
  browserSync.init({
    port: 8000,
    server: {
      baseDir: "./dist/",
      index: "./html/index.html"
    }
  });
  done();
});


// watch
gulp.task("watch", function(done) {
  gulp.watch("src/scss/style.scss", gulp.task("sass"));
  gulp.watch("src/js/*.js", gulp.task("js.concat"));
  gulp.watch("dist/js/*.js", gulp.task("js.compress"));
  gulp
    .watch(["dist/html/*", "dist/css/*", "dist/js/*"])
    .on("change", function() {
      browserSync.reload();
    });
  done();
});


gulp.task("default", gulp.parallel("server", "watch"));
```

gulpfile.jsはこんな感じです。

- HTMLのテンプレートエンジンであるpugで書いたファイル
- CSSプリプロセッサ（CSSメタ言語）のsassで書いたファイル
- 細かく分かれたJavaScriptのファイル

これらのファイルを`watch`タスクで監視し、
監視下に置かれたファイルが更新されたら、
それぞれpipeで書かれたタスクで処理が走ります。

あとはコマンドで`npx gulp`と叩けばnodeサーバが起動し、
Chromeが自動で開いてlocalhostの8000ポートでアクセスした結果が表示されます。

様々なタスクがありますが、`gulp`と叩くと`default`に書いたタスクが走ります。
`default`は最終行にあるタスクで、`server`や`watch`を登録したので、
ざっくり全体をラップした形で管理しています。

## おわりに
gulpを設定するのは大変ですが一回作ってしまえば楽なので、
この設定をだいたい使いまわしています。

npm installをすると毎回node_modulesが出来上がってしまう問題があるので、
シンボリックリンクで解決されているエンジニアの方もいらっしゃるようです。

node.jsのいい練習にもなるかと思いますので、
挑戦してみてはいかがでしょうか。


参考
[最新ビルドシステムGulp 4入門 〜環境構築からタスク作成まで〜](https://qiita.com/tonkotsuboy_com/items/9ab83fe0f25cf0b010f3)
[現場で使えるgulp入門 第1回 gulpとは何か](https://app.codegrid.net/entry/gulp-1)
[[Node.js] npm installするときはどのパッケージもローカルインストールで十分](https://arui.tech/why-locally-install-is-much-better-than-globally-in-npm/)


Gulp4のシンプルセッティング


## はじめに

こんばんは、Shumpei[(@seventhseven)](https://twitter.com/seventhseven)です。
今回もGitのお話です。

バージョン管理としてスタンダードなGitですが、
複数人で開発する際の手法が色々とあると思います。

有名なものですと、Git Flowや、GitHub Flowなどかと思いますが、
みなさんのGitフローはどういったものでしょうか？

僕は**Git Feature Flow**というものを知ってやってみたところ、
複数人開発した際のフローがわかりやすかったのでお伝えします。


## Git Feature Flowって？

ぐるなびさんのエンジニアブログで紹介されていたフローです。


> GitFeatureFlowで使う主なブランチはこの3つです。
  - master：本番環境にリリースするブランチ
  - feature：案件ごとにmasterから切ったブランチ
  - test-env（もしくはstg-env）：テスト環境と（stg-envはステージング環境と）同期されているブランチ
  このブランチモデルの特徴は下記の通りです。
  1. 改修案件ごとにfeatureブランチをひとつ割り当て、テスト環境と同期されているブランチに対して個別に featureブランチをマージする (GitFlowは複数のfeatureブランチを含んでいるdevelopブランチをマージする)
  1. 各featureブランチは独立しているため、急なリリースの発生、リリース日変更にも対応しやすい

  引用：[GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します](https://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama)

個人開発なら関係ないですが、複数人で開発する場合、
おそらくmasterブランチの扱い方が結構迷うのではないかと思います。

Git Feature Flowであれば、リリースのタイミングだけmasterブランチに触るので、
masterブランチがごちゃつかず、
整理されたブランチがマージされて管理がしやすいのが特徴のようです。


### 自分たちのプロジェクト用にアレンジ
社内のあるプロジェクトに、僕と同僚の2人で1つの成果物を作ることとなった際に、
Gitの運用に悩みましたが、Git Feature Flowを知っていた同僚の提案で導入が決まりました。

以降、会社の同僚がGitマスター（師匠）となって僕にGitについて教えてくれるようになりました。
ありがたい。

少し自分たち用にアレンジして運用することになりました。

以下、その中でもポイントとしていることを書いていきます。

### ブランチの扱い方 - コマンド

ざっくりいうと、

1. 準masterブランチ（以下、develop）を作成
1. 各人個別の開発ブランチ（以下、hoge）を作成
1. developブランチの更新差分をpullしてくる
1. developブランチにリベースしてから--no-ffオプションをつけてマージ
1. リリースのタイミングだけmasterにdevelopをマージする

という流れになります。

Gitコマンド的に書くと、キモの部分は以下のとおりです。

```
git fetch
git checkout develop
git pull
git checkout hoge
git rebase develop
git push origin hoge
git checkout develop
git merge --no-ff hoge
git push origin develop
git checkout hoge
git merge develop

```

fetchして更新があるか確認し、あればpull。
手元のdevelopブランチにマージする前に、
先にリモートのdevelopブランチをpullして、他のメンバーのコミットを取り込みます。

自分のコミットをプッシュする前に、
まずは全員の歴史を揃えてから作業を行うことで足並みを揃えます。

### git rebase

開発ブランチのhogeにチェックアウトしてdevelopにrebaseします。

rebaseはdevelopブランチを1本のきれいな歴史にするために行います。

rebaseはmergeと同じように統合されますが、
それまでの他のメンバーが行った作業を加味した状態でその上に自分のコミットを積みます。


なんとなくのイメージですが、

- 本流のブランチに横から生えて本流に合体するのがmerge
- 本流のブランチから映えるのは一緒でも、あたかも本流が積んだコミットのように振る舞うのがrebase

という感じです。

- merge(C5が最新コミット)
![merge](/img/posts/190709-git-merge.png)

- rebase(C3のコピーであるC3'が最新コミットになり、C3は消える)
![rebase](/img/posts/190709-git-rebase1.png)
[引用：git公式ドキュメント](https://git-scm.com/book/ja/v1/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%99%E3%83%BC%E3%82%B9)

そうすることで本流のブランチ（ここではdevelop）が1本の歴史になります。
「rebaseはあくまでプッシュする前のコミットをきれいにするための方法である」と
公式にも書かれているので、それくらいの温度感で運用していました。

そのあと念の為hogeブランチをバックアップのためにpushしておきます。


### git merge --no-ff 
次にdevelopブランチにcheckoutして、今まで作業していたブランチをmergeします。

mergeをする際、普通に行うとmerge元とmerge先のブランチが同じ位置に並びますが、
「--no-ff」オプションをつけることで、「ここでマージしました」というコミットを作ることができます。
※no ffはNo fast-fowardの略です。

そうすることで、**本流の歴史は1本で運用しつつ、どのタイミングでmergeしたのか**が
わかりやすくなり、管理がしやすくなります。

developブランチにいながら`git merge --no-ff hoge`とすると、
ターミナル上でエディターが開き、コミットメッセージが書けます。

デフォルトでは、`Merge branch 'hoge'`となりますので、
そのままでよければ`:wq`と入力すると画面が戻り、mergeされます。

流れ的には

1. developにチェックアウト
1. git merge --no-ff hogeをして、コメント付きでmergeしたというコミットが積まれる
1. developブランチ側の歴史が1つ進む

というフローになります。


### きれいなmasterブランチでいたい
Gitフローはプロジェクトごと個々にあるかと思いますが、
自分たちが採用したフローはこのような感じでした。

今回はなるべくmasterおよびdevelopブランチをきれいにしながら運用する
ということをテーマに進めていったのですが、
見た目が綺麗な分、見通しやすくわかりやすかったです。

ただ手作業で行っていた分、僕がよくフローをミスって
コンフリクトおこしたり`git cherry-pick`でコミット積み直したりしたので
次からはCIツールを使いたいなと思いました…。

【Git】Git Feature Flow（的なもの）でシンプル運用する


今回はGit初心者向けにリモートリポジトリの作り方をお伝えします。


## おさらい
### リモートリポジトリの作り方
`git remote add origin 該当プロジェクトのパス`

### コマンドラインでリモートリポジトリの確認する
```
$ git remote -v

# origin       https://github.com/remote-v/sample.git (fetch)
# origin       https://github.com/remote-v/sample.git (push)

```

### configファイルから確認する

ローカル側の.git/configファイルを確認する

```
.
.
.
[remote "origin"]
       url = https://github.com/remote-v/sample.git  <= これ
       fetch = refs/heads/*:refs/remotes/origin/*
.
.
.
```

## リモートリポジトリを作る時は--bareオプションをつける
会社ではリモートリポジトリをGitHubと社内のGitサーバの両方で運用しています。

社内のGitサーバにリモートリポジトリを作成する際は、`--bare`オプションをつけて作成しています。

というより、基本的には--bareをつけておくべきものですね。

### bare（ベア）リポジトリを作る
コマンドで表すと、

```
$ mkdir bare_sample.git
$ cd bare_sample.git
$ git init --bare

### 必ずリポジトリ名の最後に.gitをつけてください
```

となります。

`--bare`をつけると、このリモートリポジトリにプッシュしても、

該当のファイルは視覚的には見えません。


### なんで見れないの？

例えばGitHubにプッシュすると、手元のファイルと同じようにファイルを見ることができますが、

`--bare`オプションをつけたリモートリポジトリはワーキングディレクトリを持ちません。

ワーキングディレクトリとは、ファイルそのものがあるディレクトリ、

つまりローカル側の**gitが管理しているディレクトリ**のことです。

なので上の例で言うところの`bare_sample.git`ディレクトリの中を見ても

git関連のファイルやディレクトリがあるだけで、

プッシュしたファイルなどは見えません。

ざっくりいうと、更新・変更した差分だけを情報として保存していて、

cloneやpullする時にそれらの実ファイルが現れてきます。

### どうして空にする必要があるの？

それには[Pro Git / Gitサーバー - プロトコル](https://git-scm.com/book/ja/v2/Git%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB)から引用させていただきます。

> リモートリポジトリは、一般的に ベア（bare）リポジトリ となります。これは、作業ディレクトリをもたな
い Git リポジトリのことです。 このリポジトリは共同作業の中継地点としてのみ用いられるので、

ディスク上にスナップショットをチェックアウトする必要はありません。単に Git のデータがあればそれでよいのです。

端的に言うと、ベアリポジトリとはそのプロジェクトの .git ディレクトリだけで構成されるもののことで
す。

実ファイルじゃなくてGitのデータがあればそれでよいという設計なので、

GitHubのようなサービスでなく、管理用のリポジトリであればこれで問題ありません。

実ファイルがリモートリポジトリにあって複数人で更新していくと、

ファイルに不整合が起こる場合もあるのでルールに従ったほうがよいかと思います。


[参考：ベアリポジトリとノンベアリポジトリ：理論編〜GitでWordpressのテーマを管理](https://www.nekotricolor.com/entry/theory-of-bare-and-non-bare-repository-manage-wordpress-themes-with-git)


## 普段意識しないもの
個人で開発する分には、GitHubが有能なので普段意識しないオプションなのですが、

Gitサーバにリモートリポジトリを作成する際は注意してみてくださいね。

プログラミングを学んでいくと、開発を便利にしてくれる様々なものがありますが、

それはどんな仕組みなのか、ラップされて隠れているものは何なのかを知ると

半歩進んだ感じがします。

これからも引き続き宜しくおねがいします。

【Git】いわゆるベアリポジトリ


## ディレクトリの作りで見通しが変わる

これは転職後はじめてのプロジェクトで設計したディレクトリの構成に失敗した話です。

自分が作業を進めていくなかで、どんなディレクトリが出来上がっていくのか知らなかったため、

あとから見返したときにファイルがすごく見つけにくくなってしまった反省として書きます。


### 静的サイトって？

ここでいう静的というのは、マークアップしたHTMLがそのまま画面に表示されたページのことです。

モックは見本という意味です。

ちなみにこのブログも、Javascripitを使った[Hexo](https://hexo.io/)というライブラリで静的サイトをネット上にアップロードしています。

逆に動的なサイトは、なにかフォームに文字を入力してサーバに送信したら、画面に表示された何かが変わるということとします。

### 後悔してる構成

今も後悔している、ディレクトリとファイルの構成はこんな感じです。

初めてタスクランナーのGulpを使ったのもこの時でした。


- ダメな構成

```
project ━┳━ src ━┳━ html
         ┃       ┣━ css
         ┃       ┣━ pug ━┳━ header.pug
         ┃       ┃       ┣━ footer.pug
         ┃       ┃       ┣━ etc...
         ┃       ┣━ img
         ┃       ┗━ js
         ┃
         ┣━ scss ━┳━ style.scss layout
         ┃        ┣━ header.scss
         ┃        ┣━ footer.scss
         ┃        ┣━ etc...
         ┃ 
         ┣━ .git
         ┣━ .gitignore
         ┣━ node_modules       
         ┣━ gulpfile.js       
         ┣━ etc...       
```

どこがいけなかったのか、このときの自分に教えるつもりで書いていきます。

また、ここに出てくるディレクトリ名は一例です。


## どこがいけないのか

**なぜscssディレクトリだけがsrcでディレクトリと同じ階層にいるんだ！**

### 原因
今まで個人で活動してきた中で、HTMLとCSSだけでサイトを作っていた僕は、

ディレクトリの構成手法の知識が2000年頃で止まっていました。

要は、srcディレクトリの中に、HTMLとCSSとimgディレクトリが入っているだけの、

ごくごくシンプル…を通り越して素材の味を楽しむだけのものでした。

### srcディレクトリとdistディレクトリ

**- src**
`src`は`source`の略。
だからページの**元になる**ディレクトリの名前になる。

今回でいうと、例えばpugはコンパイルされてHTMLになるし、
scssはCSSになるので、これらがsourceになります。

つまり、pugやscssがsrcディレクトリに入って、
Gulpによって生成されたHTMLやCSSは別のディレクトリになるべきです。

**- dist**
`dist`は`distribution`の略。
distributionは配布という意味。

つまり、Gulpで生成された後、ネット上に配信されるファイル群がここになくてはいけない。
上記のダメな構成には出てこなかった、作ったほうがよいディレクトリ。


### メンテナンス性
フロントエンドは、HTMLやCSS、JSファイルを細かくパーツ単位で制作し、
**Gulp**や**Webpack**などのコンパイラー（タスクランナー）で整形させます。

特に静的なページは、ヘッダーのいち部分を修正したいとなった際、
すべてのHTMLのページを開いて、該当部分を見つけ出して、ひとつひとつ修正していく…

なんて作業を、2,3ページならまだしも5ページ以上あったら大変ですし、
ヌケモレが出てくると思います。

パーツが細かくなっていれば、そのファイル1つを更新するだけで
そのパーツファイルを読み込んでいるすべてのページに反映されるので、
見通しもメンテナンス性もぐっと良くなりますね。



### 今の僕がやるならば...
こんな感じのものになると思う。（一例です）

- やりたかったもの

```
project ━┳━ src ━┳━ pug ━┳━ header.pug    
         ┃       ┃       ┣━ footer.pug
         ┃       ┃       ┣━ etc...
         ┃       ┃
         ┃       ┣━ scss ━┳━ layout ━┳━ header.scss
         ┃       ┃        ┃          ┣━ footer.scss
         ┃       ┃        ┃          ┣━ etc...
         ┃       ┃        ┣━ variables.scss
         ┃       ┃        ┣━ top.scss
         ┃       ┃        ┣━ etc...
         ┃       ┃
         ┃       ┣━ js  ━┳━ hoge.js
         ┃       ┃       ┣━ etc...
         ┃       ┃
         ┃       ┗ img
         ┃
         ┣━ dist ━┳━ html ━━ index.html
         ┃        ┣━ css ━━ style.scss
         ┃        ┣━ js ━━ bundle.js
         ┃        
         ┣━ .git
         ┣━ .gitignore
         ┣━ node_modules       
         ┣━ gulpfile.js       
         ┣━ etc...       
```

distとsrcにわけて何がいいのかというと、

distは生成されたものだけが入っているので、実質無視していい。

そしてこういう場合のディレクトリは、状況のような感じに構成されています。

ということは、他の人と作業するときも、共通の認識で作業が進められるわけですね。


## 【結論】役割をはっきりさせる

ディレクトリにつける名前は、いわばそのディレクトリの中には

**どんな役目のファイルが入っているのか**を明らかにするべきだと思います。

そうすることで、srcディレクトリの中に生成されたHTMLファイルが入ることもなくなりますし、

ファイルのありかがわかるので、自分にも他の人にも優しい構成になるので参考にしてみてください。

静的サイトのディレクトリの構成を失敗した話


※注意※
この記事はQiitaに投稿したものを加筆・修正した記事です。
2019年2月頃のポエムです。

[前回の話](https://www.mb-js.tokyo/2019/07/05/job-change-completed/)


## アバン
こんにちは、Shumpei[(@seventhseven)](https://twitter.com/seventhseven)です。

昨年の11月半ばに晴れてエンジニアとして入社し、あっという間に3ヶ月が過ぎてしまいました。
恐ろしいスピード感ですけど、毎日奮闘しています。


今回もポエム的な記事ですが、未経験者が入社して3ヶ月間何していたのかを残しておきたいと思います。
少しでも参考になれば幸いです。


## はじめに
* バックエンドが強い自社開発のWeb系企業に入社しました
* まずは過去にも個人で経験したことがある、フロントエンド側のプロジェクトに入りました
* 先日試用期間が終わり、現在は正社員として勤務しています

## 開発環境
自宅ではmacを使用して開発していましたが、
社内ではWindowsにLinuxの仮想環境を入れて開発を行っています。 

Linux環境にはCygwinを使用し、CUIにてコマンドで操作しています。
GUIでも色々とアプリはあるかと思いますが、
どんな環境でも出来るようなるべくCUIにて操作するようにというアドバイスがありました。

> Cygwinとは、Windows上で動作するプログラムで、Unix系で利用できる一般的なシェルコマンドを入力・実行ができます。
[引用：Cygwinを使って、Windows環境でシェルとjavaを実行する方法](http://naoberry.com/tech/shell-java-cygwin-1/)


取り急ぎPC起動時に自動で立ち上がるアプリとしてCygwinや自分が担当するプロジェクトのディレクトリを開くようにしてみたり
Chromeを立ち上げ時にはよく開くサイトをタブで開くように設定したり、
環境構築を進めていきます。
**すべてのファイルの拡張子を表示させるように設定するのも忘れずに。**

Cygwinのエイリアス(ショートカットコマンド的なやつ)にもいくつか設定しました。
起動時はルートディレクトリにいるので、プロジェクトのディレクトリに一気に移動できるよう
 `cd 該当ディレクトリ` などを設定したり、
 `cygstart 該当ディレクトリ` と入力することで、該当ディレクトリのウィンドウを呼び出してGUI上で操作できるようにしたり、
好きなようにカスタマイズしています。
この辺も自分の手間を減らすように、当初設定したものです。

Cygwinのウィンドウを何個か開いてずっと作業していたので、
1枚のウィンドウで画面が分割できるScreenを導入して操作方法を先輩に教えて頂きました。
ちょっと慣れが必要でしたので毎日触りながらCUI環境を使いこなしていきたいと思います。

エディターはVisual Studio Codeを使用しています。
入社して初めて使ってみたのですが、今現在かなりお気に入りのエディターです。
とても軽く、拡張性も高いので、ストレスは感じません。

初学者の方向けに、Twitterで自分が使っているプラグインをご紹介しているので、もしよろしければ御覧くださいませ。
[●該当ツイートへ](https://twitter.com/seventhseven/status/1079359709331677184)


## 社内環境
少数精鋭で強いエンジニアが技術力で殴るスタイルの会社ですが、
社長はじめ穏やかな人が多いので居心地がいいです。

自分は色々な領域を浅く広く知っているタイプなのですが、
先輩の中には自分の業務領域以外の分野でもやたらに詳しい方ばかりなので対等にお話できるようになりたいです。

勉強会などに関しては、会社の規模的に大々的なものはないのですが、Slackやら口頭で質問をすると丁寧に教えて頂けるし、
新人向けに社内での講習も慣れた方から教われるので、非常に良い環境だと感じています。


## 業務では何をやってきたか
### 通常業務として
自社のウェブサイトをリニューアルするということで、僕がメインで担当することになりました。
先輩にアドバイスを頂きつつ、コード書くのは自分だけです。

PhotoshopとIllustratorである程度しっかりしたモックを作成した後、
静的サイトのメインどころのページを一通りまず作り上げて、
更新作業の業務フローを考えてWordPressに移行させるというステップを踏むことにしました。
現在目下作業中です。


静的サイトを作成する際、**タスクランナー**というWEBサイトを作る際に自動で色々やってくれるプログラムや、
**テンプレートエンジン**や**Sass**を初めて知りました。

フロントエンドをやられている方からすると何を今更という話かもしれませんが、
メモ帳やCot Editor(メモ帳に毛が生えたエディター)で、
がんばってコーディングして手作業ばかりしていた自分からすると革命です。

現在、自分はタスクランナーは[**Gulp**](https://gulpjs.com/)を使い、
テンプレートエンジンは[**PUG**](https://pugjs.org/api/getting-started.html)でHTMLを書き、
CSSは[**sass**](https://sass-lang.com/)で書いています。

PUGはHTMLを楽に書けるようにしてくれるもので、
閉じタグを書かなくてもあとでゴニョゴニョしたらちゃんとHTMLとして読み込んでくれるものです。

変数やlayout、includeも使えるので、
`header.pug`、`layout.pug`、`footer.pug`などパーツで管理できるので、
「footerのこの部分を変えたい！」となったときも、すべてのページ１つずつを修正するのではなく、
`footer.pug`だけを更新できれば良いのでメンテナンスも楽です。

sassも変数など使えるので、`variable.scss`という使う変数だけをまとめたファイルに繰り返し使う変数を登録しておくことが可能です。

```css
# 例
# variable.scss
$font-size: 16px;

# nanika.scss
font-size: $font-size
# コンパイル後 => font-size: 16px;

```

その変数を別のscssファイルから呼び出すが可能なので、
何度も使う幅や高さなどの値を変数として登録しておけます。

そうすることで`variable.scss`の中に登録した`$font-size`の値を`16px`から`18px`などに変更することで、
この変数を使用しているすべてのところで値が変更されます。


Javascriptに関しては、今回はあまり使わないので個別に機能を持たせたファイルをそれぞれ用意するにとどめています。


Gulpは、PUGで書いたHTMLを自動でコンパイルしてちゃんと閉じタグなどを整形してちゃんとしたHTMLにしたり、
sassもちゃんとしたCSSに整形したり、
その整形したファイルはどのディレクトリに保存させるのか、
あらかじめ設定しておいた任意のタスク（スクリプト）が更新されたら自動でブラウザをリロードするように設定したり、
色々できるのでかなり強力です。

自分はこちらもまだ全然使いこなせていないので、こちらも勉強中です。


過去、半分趣味・半分仕事としてHTMLとCSSはある程度慣れ親しんでいましたし、
PhotoshopやIllustratorに関しては学生の頃から触っていたので何とかなるかなと思っていたのですが、
紙とWEBでは考え方やアプローチの仕方、概念などが異なり、まずそこに慣れるのに時間がかかりました。

PhotoshopやIllustratorも前は使わなかった機能を使ったりなど、
こちらもWEBデザイン向けの知識を入れているところです。


そして、現在は作成した静的サイトをWordPressに移行作業中です。
WordPress自体は触ったことがあったのですが、数年前な上に有料テーマを使ってブログを書いていたので、全然理解していませんでした。

投稿やテーマ、URLなどを管理しているダッシュボードから、
フロント側の構造を理解するところから再スタートです。

静的サイトは1ページ1ページそれ専用のページを作れば良いだけですが、
WordPressはブログ的な機能の一面があるので、
自分が作りたい箇所（例えば最新情報などこまめに更新されることが予想されるところ）だけはブログのように動的にしなくてはなりません。

そしてそれはWordPressにおいて静的な1ページを作成するのではなく、
投稿としてダッシュボードから行わなくてはいけないので、それ専用のテンプレートファイルを作成したりして実現していきます。

WordPress独自の呼び出されるページの優先度や関数の解釈、
functions.phpで行うURLのコントロールなどの独自の設定を書き加えたり、
アップデート対応を考えるとなるべくプラグインに頼らない方針でいきたいので
ドキュメントと技術ブログを見て悶絶しながら覚えて理解して作っています。



さて、そんなことをしながらある程度出来上がったタイミングで都度都度全員の前でプロジェクターに写しながらプレゼンしていきます。
基本的に緊張はあまりしない方なのですが、イマイチ伝わっているのか掴みきれていないので、
パブリックスピーキングのスキルが欲しいところです。

### 社内講習
上記の業務に加え、今年の1月からずっと社内講習が週1回行われています。

はじめはコンピューター概論として、CPUやメモリなどの五大装置を含めた低レイヤーを学びました。
レジスタやバス、演算装置などを大まかに捉えることが出来ました。

次にアルゴリズムを学びました。
一つの検索結果を求めるにしても、結果が出る時間はn^2なのか2nなのかlognなのか…グラフやらを交えながら学びました。

パズルは元々好きですが、ソートに関しては脳に汗をかきながら取り組みました。
バブルソートや選択ソート、クイックソートやマージソート、ヒープソートなどほんのさわりを習ったのですが、
[**アルゴリズム図鑑**](https://itunes.apple.com/jp/app/%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0%E5%9B%B3%E9%91%91/id1047532631?mt=8)がかなり理解の助けになりました。

アルゴリズム図鑑は無料のアプリですが、300円ちょっとの課金で色々なアルゴリズムについてや、
秘密鍵やデジタル署名などのセキュリティ方面の話などもわかりやすいビジュアルで学ぶことが出来るのでオススメです。

> [AppStore **アルゴリズム図鑑**](https://itunes.apple.com/jp/app/%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0%E5%9B%B3%E9%91%91/id1047532631?mt=8)


現在はフロントエンド講習を受けています。
こちらはHTTPやWEB、UI/UXについて学んでいます。

普段何気なく使っているブラウザですが、
CSSである色を指定しても、ブラウザエンジンによっては表示される色が異なることに驚きました。
差は微妙なのですが、結構気になります。
コントロールはできないのでどうしようもないのですが…。


フロントエンド講習が終わると、次にRuby講習が始まるので、ぼちぼち準備していきたいところです。
他社さんの教育環境はわかりませんが、新人教育に関してはすごく手厚い感じがします。
もちろん、受け身な姿勢ではよくないので、食らいつけるように努力しています。



### 小ネタ
HTTPについて、先日講習で行ったことをシェアしたいと思います。

まずChromeで適当なページを開き、
デバッグモード( F12 / Cmd+alt+i )にします。
最初はHTMLタグが開かれていると思いますので、
デバッグウィンドウ最上部にある `Elements`や`Console`、`Sources`などがあるタブの、
`Network`をクリックした状態で画面をリロードします。

そうするとそのページを開くまでにどんなリクエストとレスポンスが走ったか見ることが出来ます。
`Name`に表示されているファイルを適当にクリックすると、ブラウザにレンダリングされる前に何が起きたかが見れます。
`Headers`ではIPアドレスやリクエスト・レスポンスの詳細(View parsedをクリックするとhttpステータスも確認できます)、
`Timing`では実行された時間がビジュアルで確認することが出来ます。


## 個人での学習でやっている（た）こと
ニュースチェックははてなのIT・テクノロジー関連はとりあえずざっと見て、あとは社内で気になるnewsが取り上げられるとそれを読む感じですね。
SEO観点から見るレンダリングのタイミングについての議論など、レベルが高いので理解するのにはまだかかりそうです…。

また、先月から**基本情報技術者試験**に向けて勉強をしています。

資格に関しては色々な意見があるので置いておいて、
自分の目的は資格を取るのが目的ではなく、体系的に勉強することが目的です。

経験上、基礎練習を大切にしているので、それにあたるのがまずは基本情報かなぁと思いました。
今年は基礎固めの年として、知らないことをどんどん減らしていくのが目的なので
業界に馴染むためにもちょこちょこ進めています。

ただ、気負っても疲れてしまうので、スキマ時間を見つけたらやるスタイルです。
テキストも買いましたが、[**基本情報技術者試験ドットコム**](https://www.fe-siken.com/)さんと併せて過去問対策をしています。

> [**基本情報技術者試験ドットコム**](https://www.fe-siken.com/)

ただどうも試験となると答えるのが目的になってしまって、
答えを覚えちゃう方に頭が持っていかれるのは果たして意味あるのかなと頭によぎります…


また、Javascriptが全然わからないので勉強したいなと思って易しめの技術書を買ってやっていたのですが、
JSの皮を被ったjQueryのテキストだったので、完走はしましたがイマイチ身にならなかったです。

jQueryはパワフルなものですが、便利すぎてそれに頼ってしまうので、
まずはネイティブなものを知って思い通りにコントロールしたいので、また勉強し直しです。
僕はフロントエンドの方なので、サーバーサイド側のJSよりかはクライアントサイドのJSをまずは学ぶほうが良い気がしています。


## 今年やっていきたい学習
基礎固めをしつつ、まずは普通のJavaScriptを理解して書いていきたいです。

CSSはある程度書けるようになってきたのですが、JavaScriptはまだまだなので強化していきたいですね。


## まとめ
長くなってしまいましたが、3ヶ月でやってきたことを書いてみました。
ここまでお読みいただき、本当にありがとうございます。

若い人のように爆速で成長するということは難しく、
正直亀みたいなスピードしか出せないのですが、日々淡々と勉強していく所存です。

少しでも参考になれば幸いです。

***

[Twitter(@seventhseven)](https://twitter.com/seventhseven)もやっているので、よろしければフォローくださいませ。
一緒に強いエンジニアを目指しましょう！

未経験者は入社後3ヶ月でどんなことが出来るようになるのか


※注意※
この記事はQiitaに投稿したものを加筆・修正した記事です。
2018年10月頃のポエムです。

[前回の話](https://www.mb-js.tokyo/2019/07/03/first-post/)

今回は引き続き転職活動について、完結編というような位置づけの記事です。
よろしくお願いします。



## はじめに
結論からいうと、無事、正社員採用にて内定を頂きました。
活動期間というと、本格的に動き始めてから内定を頂くまで、ほぼ1ヶ月でした。


実は前回の記事を投稿した当日、
午後に面接があったのですが、
当日中にその企業様から内定のご連絡まで頂けたので、
非常にタイムリーかつ驚きました。

契約内容も非常にフェア…というより未経験者という立場からするとありがたい条件で
雇用頂けることとなりました。


今回の記事は、自分がどれくらいの企業様に応募し、どれくらい通過したのかと、
ここ数ヶ月で取り入れ始めた情報源をご紹介させて頂きます。
なにか一つでも参考になれば嬉しいです。


## 書類通過率について

オンラインスクール[TechAcademy](https://techacademy.jp/)のキャリアカウンセラー、dudaのキャリアカウンセラーの方に言われたのですが、
僕のスペックだと、恐らく書類通過率は2割程度だろうということでした。


単純計算で10社受けたら2社は話を聞いてくれる可能性があるということで、
未経験30歳がいきなり応募してきたということを踏まえると
個人的には意外に確率は高いなと思いました。

実際の応募数と通過数は以下のとおりです。


## 何社応募したか
### TechAcademy(オンラインスクール)
応募数：6社
スカウト数：２社
面接までいった数：1社
内定数：1社
備考：スカウト頂けたのでお会いしたらそのまま採用となり、来月よりお世話になることになりました。
また、書類選考に落ちてしまった企業様から、エンジニアではなくディレクターはどうか？
という打診も頂きましたが、エンジニアを目指していたので、せっかくですが遠慮させて頂きました。


### duda
応募数：7～10社程度
スカウト数：0
面接までいった数：1社
内定数：0
備考：単純に紹介される求人が多く、見きれないというのもありましたが、
面接して頂いた企業様はしっかりとしたところだったので、
媒体への安心感を強めました。

### Green
応募数：10社程度
スカウト数：1社
面接までいった数：3社
内定数：0
備考：転職活動を始めて、初めての面接はGreen経由での企業様でした。
面接は終始ガチガチで反省点も多かったのですが、後に繋げられるよう糧にしました。
比較的少人数で運営されている企業様を中心に応募させて頂きましたが、
それぞれ企業様によって面接時の雰囲気や色があって面白かったです。



## 会社を選ぶ時に参考にしていた情報
主にYouTubeを起点に収集していました。
普段から見ているメディアなのと、
外で歩きながらでもラジオのように聞けるのが
個人的に都合がよかったからです。

視点としては、

- エンジニアという職について
- 労働というそのものの視点

の2軸。

現在正社員として働いているものの、
- このまま正社員としてまた働くのか
- 派遣なのか
- フリーランスになるのか...など

より大きな視点でも見ていくため、
色んな情報を集めていきました。


働き方については、どうしても自己啓発的な要素も絡んでくるのですが、
既婚者という立場なので、今後家族を養っていく上で何が一番ベストなのかという点と、

経営者側から見て、どんなことを考えて会社を経営しているのか、どんな会社が"強い"会社なのか、
どんな人間なら採用したくなるのか…など、雇用する側からどう見られるのかも気にしていました。

今回は正社員雇用を目指していたのですが、
フリーランスや派遣という働き方をする場合、また違った視点でものを考えなくてはならないかと思います。


**現在は色々な方と出会いを通じて、更に知識を得ています。**

## 内定を頂いた企業様について
今回は、結果的に受講したオンラインスクールTechAcademy経由にて、
スカウト頂く形で面接に伺いました。


初めは現場のエンジニアの方と採用担当の方2名とお話させて頂きました。
ある程度話して落ち着いた後、
社長さんがいらっしゃり、そのまま社長面接に移行しました。

社長面接では、社長自ら会社の事業を説明頂いたり、成り立ちなどを教えて頂きました。
面接開始当初から僕の人柄を気に入ってくださったこともあり、面接はなごやかに終わりました。

その日のうちに内定の連絡を受け、
一晩考えた後、お世話になることを決めました。


## 未経験は人柄勝負
その業界がはじめての場合、実績がないので「なぜやるのか」という自己分析をしっかりと行った上、
「やる気をアピールできるもの」を実績代わりに
運に身を任せて動き続けることが大事なような気がします。


実は、この企業様の面接を受ける直前まで、
それまで面接して頂いた企業様からは全部お祈りメールをもらっていました。

立て続けに落ちていた僕は、この時良くも悪くも肩の力を抜いて面接に迎えたような気がします。
また、予想に反して初めから採用を前提に面接が進んで行ったので
こういう事もあるんだなぁという不思議な気持ちでした。


また、企業研究はそこそこしましたが、
面接対策はあまりしていませんでした。
中途採用ということもあり、なにかを暗記して話すのではなく、
多少とちってもいいから自分の言葉で伝える意識が大切ですね。
これは、自分が現職で採用活動をしていて感じたことです。

また、経歴が良くて欲しいスキルを持っていても、
その会社で一緒に働くというイメージを面接担当官に与えられなかった場合、お祈りされてしまいます。

こればかりはそういうものだと割り切っていたので
あまりくよくよせず、ダメだったらすぐに切り替えていくことが必要です。


## おわりに
以上で僕の転職活動は終了しました。
小売業を10年勤めたのち、来月から未経験業界に入ります。
30歳という年齢のハードルを何とか超えられた一つの例として、
少しでも皆さんの参考になれば幸いです。


並行して現在は退職手続きも進めています。
出て行く人間に対しての扱いに思うところあるのですが、
また別の話ということで…。

気持ちを切り替えて、新しい職場で一刻も早く一人前になります。
また、次回からは技術的な記事も書いていきたいと思います。

お読み頂き、ありがとうございました。

業界未経験の30歳がプログラマーに転職できた話


※注意※
この記事はQiitaに投稿したものを加筆・修正した記事です。

2018年10月頃のポエムです。


## はじめに
私は現在小売（雑貨・インテリア系）業界にいる30歳（既婚・子無し）です。

~~Webエンジニアになるべく転職活動中です。（2018年10月初旬現在）~~

2018年10月、無事エンジニアとして採用して頂くこととなり、

晴れて11月よりエンジニアとしてのキャリアをスタートいたします。


この投稿はエンジニアになるために行ったことや、現在行っていることを、

自分自身の記録を残すとともに、同じような立場の方の参考になればと思い書きました。


## 転職する目的
- 自己分析した結果、性格的に技術職の方が好きだった
- ITスキルを高め、自分の市場価値を上げたい
- 給与面の可能性

最終的には我が家が幸せに暮らせるための手段として

適正・可能性がマッチしているエンジニアになることでそれが得られると考えています。


## 現職の状況・スキル
### 現職の状況
私は東京のとあるお店の店長を努めています。

お店では店長職として、店舗での個人・法人様の接客・応対や、在庫の管理・手配、

メーカーや契約倉庫、コンサルタントとの連携、

店頭に並ぶPOPやDMなどの作成、SNS（Instagram、Facebook）運用、

採用活動などなど…

日々細々とお仕事をしています。

### スキル
- Illustrator
- Photoshop
- EXCEL（表計算・グラフ・リスト作成など）
- Word（文章作成）

元々はグラフィックデザイン系の専門学校を卒業しており、

IllustratorやPhotoshopを使用して、グラフィックデザインやイラストレーションを学びました。

個人では[「**なな爺**」](https://twitter.com/1gatsu_7g)という名義で同人作家としても活動しています。

漫画やイラストをTwitterに投稿し、同人誌を作成したりなどもしています。




## 転職活動をする前にどんなことをやったのか

2018年6月から約3ヶ月間、オンラインスクールの[TechAcademy](https://techacademy.jp/)にて、

[Webアプリケーションコース](https://techacademy.jp/rails-bootcamp)を受講しました。


ちなみに、仕事では採用活動はしたことはありますが僕自身は転職をしたことがなかったので、

転職活動に対しかかる自分や妻への負担（主に時間やお金）は計り知れません。

ですので、**「転職する」というゴールに対し、

プログラミングを学ぶというフェーズと、

実際に転職活動をするというフェーズにわけて、

それだけに集中して動こう**と決めました。


### TechAcademyのカリキュラムについて

Webアプリケーションコースは、TCP/IPモデルの勉強から入り、

RubyとMySQLを使っていくつかのアプリケーションを作った後、

自分で企画・実装までを行うオリジナルサービスをリリースするところまでがゴールとなっています。

AWSのCloud9を使用してコーディングをし、

Git／GitHubでバージョン管理を行い、コードレビューを受け、

Herokuにデプロイするのがベースです。

フレームワークはRuby on Railsを使用します。


カリキュラムで作るのは、

Twitterのクローンや、APIを使った検索サービスなどです。


受講生には、担当のメンター（現役プログラマー）がつき、

週に1〜2回、ビデオチャットで面談し、進捗具合などを話します。

それ以外の時間で、カリキュラムについて困ったことや質問がある場合、

Slackを使って質問を投稿すると、

担当メンター以外のメンターが質問に対し的確なアドバイスをしてくれます。

**アドバイスと書いたのは、単純に答えを教えてくれるわけではないからです。**

プログラマーになるにあたり日々発生するエラーの対処について、

自分で調べたり試したりするステップがあるかと思いますが、

まずその感覚を身に着けなくてはいけないかと思います。

ですので、自分で質問を投げかける時も、

**自分で調べ、自分で試し、どのような事がしたかったのに、どのような事が起きた**のか、

しっかり説明しながら投稿しました。

質問を受けてくれるメンターの方も、その部分を踏まえて**非常に丁寧に対応して頂けました。**

受講を終えて思ったのですが、

TechAcademyのカリキュラムについては、

**Railsチュートリアルを少し優しくしたレベルのテキストを、

並走しながら進めていくようなオンラインスクール**でした。


## 転職活動を始めた

そんなこんなで、ペットの寝顔の写真をシェアするオリジナルサービス「[nelco(ネルコ)](https://nelco.tokyo/)」をリリースした僕は、

それを[GitHub](https://github.com/Shumpei0111/nelco)に公開し、転職活動を開始しました。


### 優先事項
正社員募集で探していますが、優先している事項がいくつかあります。

- 通勤距離
- メンバーは常に勉強している環境であるか
- 評価体制

です。
通勤距離は言わずもがな。近ければ近いほどいいと思っています。

また、社内で勉強する環境が存在するかどうかも重要視しています。

常に走りながら学ばなくてはいけない業界だと思っているので、

勉強するということが当たり前にある環境で働きたいです。

人間、いくら意思が強くても環境に左右される割合が高いと感じるので、

どれだけ自分の望む環境で過ごせるかがかなり大事だと思います。

評価体制については、未経験があまり強く言えない部分ではありますが、

人が人を評価する場合、評価する側の好みや相性の影響も入ってくるかと思います。

それはそれでいいので、その他客観的な視点での評価も受けられる仕組みがあると、

より良いかなと思っています。

## 転職活動に使用したサービス

以下は、その際に使用した（している）サービスです。

※これを書いている現在も、転職活動中です。（2018年10月初旬現在）


## TechAcademyの転職支援サービス
受講したオンラインスクールに付帯している転職支援のサービスです。

履歴書や職務経歴書などを登録フォームに入力・作成し、

TechAcademyが持っている求人案件に応募することができます。

また、企業側からもスカウトを頂ける場合もあります。

キャリアカウンセラーがいるので、一度ビデオチャットで面談を行い、

自分で入力した職務経歴書などの書類の書き方、アピールポイントなどについてアドバイス頂きました。

### 良い点
- カウンセラーの方に業界感や各社の求人媒体の特徴を聞けた。
    - 各社の求人媒体を通じて応募することもいいけど、企業へ直接応募もおすすめ 
- アピールポイントについて書き方のアドバイスを受け、書類のブラッシュアップすることができた。
- 実際に企業側からスカウトを頂けた


### 物足りない点
- 求人案件の数が少ない気がした。


## Green
まずはIT転職といえばGreenかなと。

先述したTechAcademyのキャリアカウンセラーも、求人媒体の一つとして挙げていました。

TechAcademyで教えて頂いた部分を踏まえ、ガンガン応募しています。

そのうち、何社か面談して頂きました。

まだ選考途中ですので、ドキドキしながら結果を待っています。

また、会社側から面談確約スカウトも頂けました。

### 良い点
- 業界に特化しているだけあるので、案件数が豊富。
- スマホで見ると、割とUIがわかりやすくデザインされているので、使いやすいと感じた


### 物足りない点
- 今の所なし


## Doda
第一目標はプログラマーになることですが、

プログラマーとしての道以外の選択肢があるのかどうかも保険として考えています。

現在の自分の市場価値はどれくらいなのかも含め、

色々な視点で物事を見るのはいいかと思ったので

大手のサービスを受けることを決めました。

現在私に来ているオファーは、面接確約を含め**400件以上**来ているので、

小売業界は特にそうですが、どこも人手不足なんだなという事を感じるとともに

自分の需要はありそうです。

### 良い点
- 大手求人会社なので、ある程度案件にはスクリーニングができていそう。

### 物足りない点
- スマホで見た時に、企業側とのメッセージをやりとりする際に使う送受信ボックスが、周りの配色と同化してしまい見つけにくかった



### その他
WantedlyもGreen同様、あらかた埋めましたがまだスコアが32しかないので、

もう少し上げられるよう手を加えていきたいです。



## 面接で聞かれたこと
- 志望動機
- 積み重ねてきた店長職からの転職に不安は？
- 現在は週にどれくらい休日はありますか？
- 残業について（納品前の休日出勤についてなど）


## 面接で聞いたこと
- 社内の勉強会など、勉強する環境・文化について
- お話した中で私の印象はどうでしたか？（聞き方が難しい）
    - 社内で馴染めそうか、エンジニアとしての適正はありそうか直感でお答え頂いています 


## 初めて転職活動をしてみて（今のところのまとめ）

「エンジニアになる」と決めているので、まずはエンジニアとして振る舞う行動を続けています。

（情報収集や、エンジニアの方との交流など含めて。）

不安はありますが、動いたら動いた分だけ状況は変わると思いますので、

目的を見失うことなく続けていきます。

また進捗がありましたら、あらためて記事にしたいと思います。

あまりQiitaぽくない投稿ではあるかと思いますが、

少しでも参考になれば幸いです。


## 無事に内定を頂きました
オンラインスクールTechAcademy経由で面談して頂いた企業様から

内定を頂くこととなり、現在現職との引き継ぎ期間中です。

次回は内定までのことを書いた記事を鋭意製作中です。

是非お待ち頂ければと思います。



MB.js

BLOG