転職ACを書いたら仕事が出来た話。

転職 Advent Calendar 2016 20日目が空いていたので埋めておきます。

1日目にこんな記事を書きました。

2016年内に2回転職した話とか

転職 Advent Calendar 2016 1日目。 今年もやってきましたAdvent Calendarの季節。 ノリで作ったのにすぐ埋まった上に、さらには 転職(その2) Advent Calendar 2016 も出来ていて、みんないろいろ溜まっているんだなと感じています。 自己紹介 まずは自分の自己紹介から。 今年29歳、2011卒の社会人6年目です。 既婚で子供は2人、転職回数は2回、

実はこの記事が現職の会社の方の目に留まり、社名や名前に気付いたことから、「フロントエンドの課題解決のために前職での知見を聞かせて欲しい」と新しい繋がりと仕事が出来ました。

そこで会話したフロントエンドエンジニアとしての役割や立ち位置、仕事の仕方をまとめてみます。

今まで

通信→web広告→ITサービスと転職してきて、それぞれ文化やスピードが全然違うなと感じつつも、良いプロジェクトや良い仲間にも恵まれて成果も出してきました。

ただ、そこに至るまでにはやはり紆余曲折があり、ビジネスサイドやバックエンドの下請け状態ということが続き、チームの中で不平や不満が溜まってしまうということが2社目の時にありました。

手戻りが多かったり仕様把握が足りずにリリースが遅れるなど、不満はチームをまたいでお互いにあったと思います。

体制改善

「サービスを提供するユーザに一番近い部分を担うはずのフロントエンドやデザイナーが、なぜビジネスサイドと折衝しないのか」

そこで、いろいろな不満や負債を解決するために、個人ではなくフロントエンドチームとして、他チームとの関わり方を変えていきました。

ビジネスサイドとの要件定義、デザイナーとのUI/UX調整、バックエンドとのAPI設計

フロントエンドが各レイヤーと橋渡しになるように仲介をしながら開発するにようにした結果、仕様把握漏れや結合ミスによる手戻りやバグの発生件数を下げることが出来ました。

代わりにフロントエンド自体の開発スピードは多少落ちてしまいましたが、精神的にも品質的にも安心出来るようになったのは良かったと思います。

成功要因

フロントエンドがその他のレイヤーまで染み出していくことで、その時は上手く機能しましたが、それを支えた要因として「フロントエンドのメンバー全員がバックエンドの経験を持っていた」ことが大きかったです。

Java, Ruby on Rails, Node.js, 言語は違いますが、バックエンド経験があったおかげで、画面構造やテーブル構造まで見据えたAPI設計が出来ました。

バックエンドの方たちも今まで後回しにしていたDBチューニングやリファクタリングに注力出来るようになったので、Win-Winだったのではないかと思います。

画面の設計や開発は普段からしているため、ビジネスサイドやデザイナーとの連携は特に問題は無かったです。

これから

結局フルスタック的な働きが誰もに求められそうな気はするものの、それぞれメインとする職域や職能はあるので、関連するチーム同士がお互いにリスペクトし合っていくことが大事なのかなと思います。

以上

Diary