JavaScript書けなかったフロントエンドエンジニアのその後
デザイン部の石橋です。
昨年9月、このブログが立ち上がって間もない頃に記事を１つ書きました。
フロントエンドエンジニアになった私のその後について少し書き残しておこうと思います。
最近のぼく
立場
肩書きが、フロントエンドエンジニアからリードフロントエンドエンジニアになりました（つよそう）
求められるものが増えてきたので、それを区別するために新しく作りました。
主な役割としては通常のWeb開発業務に加えて、↓こういうのもやっています。
- 技術的知見でのリード
- チームリーディング（※Notマネジメント）
（チーム云々については後述…）
やってること
そして今はReact+redux+react-router+webpack+云々でSPAをつくるという、すごい2016年っぽいことをしています。
CSS周りについて検討していた時に書いたメモですが、せっかくなのでペタリしておきます。
前回の記事ではまずjQueryを覚えた私ですが、今はもうほぼ書いてません。
HTML・CSSといった今までの世界ではありえないくらい、最近は英語の文献ばかりを参考にしています。 うまくいかないなぁ…と思って調べてみると、Githubのissueで絶賛議論中の問題で、次リリース分でbugfixされます、みたいな状態。たのしい。
やりたいこと
あと最近少しかじっているのはWebパフォーマンスに関して。
ただ実装するだけじゃダメなのは当然ですが、運用コストばかりに目がいってプロダクトに影響がでてユーザー体験が落ちてしまっては元も子もありません。
これから大事なのは品質です。
今となってはデザイナー的な実業務はかなり減りましたが、そこで培ってきた「視る力」はエンジニア業務でも相当使っています。
もしいきなりエンジニアになっていたら、ただの1人月工数おじさんになっていたかもしれません。こわい。
さらに上に行くにはどうすれば…と悩んだぼくは。
チームビルディング
チームビルディング
同じ一つのゴールを目指し、複数のメンバーが個々の能力を最大限に発揮しつつ一丸となって進んでいく――そうした効果的な組織づくりや、チームをまとめる手法
入社しての1年でなんとなく成長を感じた私ですが、そこからさらに貢献を最大化するために個人のスキルアップだけでなく、チームを作ることに徹しました。
正直これは苦労しました。
- 人によってモチベーションを感じるところや、負担に感じるところは違う。
- どこまで管理するのがベストなのかわからない
- コミュニケーションの重要性を説くのが大変
- 謎の業務が増える（←これ本当に謎）
チームビルドって、要するに文化形成なのでどういったチームが良いのかが凄く難しいです。
ただ、一応技術のチームなので日常的に最新の技術情報を共有する文化が作れたのは良かった。今では毎日必ず4〜5件くらいの注目記事が自主的に流れます。
あと、真面目すぎないチームにならないように気をつけました。 業務は楽だけど堅苦しい環境よりも、たまに大変なこともあるけれど動きやすい環境のほうが私は好きなので。
色々ありましたが、現在はマネジメント関連はもっと得意な方にお任せして自分は技術面に特化することにしてます。
判断軸
多分やろうと思えばできる仕事っていっぱいあるんですが、50%しか力が発揮できないものもあれば、100%発揮できるものもあるし、中には120%や、200％発揮できるものもあるかもしれない。
それが何かを考えてから仕事するようにしています。
得意な人がいたら、その人にやってもらう。自分は自分が一番得意な業務、自分じゃないと出来ない業務をします。
目先の効率ではなく中長期的に一番メリットがあるのは何か。（教育的な意味も含めてね）
今は立場上技術選定を任されることが多いのですが、この場合でも同じですね。
登壇します
90c0ba03fdaf930c0a4048bb06.doorkeeper.jp
7/23（土）に石川県の弊社事業所にて行われる、株式会社DeNAさんとのイベントで登壇することになりました。 デザイナーとエンジニア両方を経験してきた身として、なにかいいお話ができればと思ってるので来れそうな方は是非是非！！！
