2020年の思い出

公開日: 2020年12月31日最終更新日: 2021年04月20日

ウイルスに振り回された 2020 年がそろそろ終わりを迎えようとしています。月並みな表現ですが今年は大変でしたね。2020 年は仕事以外のことで活動の幅を広げようと考えていたのですが、結果的に仕事ばっかりの 1 年でした。そんな 1 年を振り返りつつ、ポエムとして残しておこうと思います。

仕事:転職と自分の役割の変化

2020 年 4 月に転職して東京に出てきました。前職は色々触りつつもフロントエンドを好む感じの IT エンジニアで、転職後はフロントエンドエンジニアとなりました。React を使って自社サービスを開発しています。

担当サービス領域のフロントエンド開発リーダーという感じで役割的にはリードエンジニアだと思っています。自分でコード書くよりも開発の方向性や仕様、技術調査、コードレビューを行い、チームが効率良く、品質の高いプロダクトを作れるようにすることが仕事の中心でした。また、機能実装とは別の路線で UI/UX 改善もだいぶ力を入れました。あとは開発環境のブラッシュアップをしたり、品質向上の試みをしたりです。

取り組んだことの一部

  • フロント開発環境のアップデート (ライブラリ関連)
  • フロント開発のドキュメント、コーディングルール作成
  • ユニットテスト作成、ユニットテストの設計
  • UI 作成環境の作成 (Storybook 導入)
  • UI パーツのビジュアルレグレッションテストの作成(Storybook 上)

かなりがんばったように思います。まだまだ手探りな部分も多く、特にユニットテストは中々開発に馴染んでいません、テスト設計をもっと詳細にすることが 2021 年の課題です。

自分の書くコードだけでなくチームとしてどうするかを強く意識する必要があったため、悩むことも多かったですが良い経験にはなったかなと思います。

開発の体制の色々

開発メンバーは社員、フリーランス、オフショアと色々な人がいる環境でした。元々、プログラムを触る開発メンバーは全員社員という環境で仕事をしてきたのでこのような環境は初めてでした。考え方というか、文化面でも勉強になることが多かったです。

例えばオフショアの人たちは行間をあまり読んでくれないですが、指示に対してのアウトプット品質は平均的に高めに感じました、こちら次第で納品物が良くも悪くもなる印象です。ただ、日本語はダメなのでエンジニアとの間に翻訳する人とマネジメントの人が必要で、どうしても細いところまで伝わりきらない分、お互いに慣れるまでは細かなやりとりをした方がスムーズでした。

フリーランスの人はパフォーマンスや仕事の取り組む姿勢が人によって大きすぎるくらいに違いました。それぞれが独自の文化を持っているような感覚です。

今のところはどの雇用形態の人が良いというわけでもなく、社員含め良い人は良く、合わない人は合わないという当たり前の結果に行きついています。重要なのは、開発の方向性を決める人はどうして欲しいかをきっちりと伝えることです。先ほど行間のことを書きましたが、行間が必要なうちは中々上手くいきません。徹底してどうしたいかをルールやレビューで伝える必要があると思いました。

ただ、雇用形態としては社員と明確な違いがあるのは、契約に期間や時間の制限があることです。

品質と基準

契約期間がまちまちなので、開発としては人の入れ替わりを想定しておく必要があります。その分、開発の品質の捉え方が難しく感じました。社員だと成長を視野に入れて教育コストをさくことが出来ても、短期間だとそうも言っていられません。

今の時点で思うことは、突き抜けた高品質のコードを増やすよりも、一定の品質を割るコードを増やさない方が重要なのではということです。例えば React だと state や props を直接書き換えるコードはご法度ですが、フロント経験の浅い人は割とやります。慣れている人でもオブジェクトのネストが深いとコピーが足りないこともあります。また、プロジェクト内にすでにある機能を再実装したり、特定ブラウザのための歪なコードを消したりするケースもあります。

チームの状況をみて何を使用し、何を使用しないかは常に考えて伝える必要がありました。そのためにもコードレビューは重要で、チームの状況と自分の理解を深める上でも役立ちました。多少効率は悪くても学習コストの高いアーキテクチャを入れるよりは、入れ替わりを前提として愚直なコードの方が良いと感じることもありました。

まだまだ正解はわからないので、自身の実力を高めつつより良い方針を考えていかないといけません。

コードレビューと主観

1 日に何件もレビューする状況で、リリースが近いなどスケジュールがカツカツの時、コードレビューで指摘することが精神的に辛くなることがありました。相手の状況を考えると、これくらいは見逃してあげるべきでは?多少怪しいけどもう帰りたいだろう・・・、次に直せば良いのでは?などコードとは別のことに関心がうつってしまい、結果的に品質を下げる方向に行きがちです。

この対策として、まず主観を排除して機械的に指摘する部分と、どうするかを質問する部分に分けることで解決できる部分がありました。例えば、開発ルール的に禁止している場合は何も考えずに修正を依頼します。state の書き換え、非推奨関数の使用、意図しない仕様の変更、テスト範囲外の影響など、相手がどのような状態でも何も考えず指摘します。

そうでないものは質問をします。自分はこう思いますがあなたはどう考えていますか?というところや、ここはこうした方が良くないですか?とコード例を書く時もあります。コードの動きがわからない時もどう動くかわからないので教えて欲しいと書きます。不具合がなくても気になったところは全て質問します。返答に納得できないところがあるが相手が折れない場合は、まず開発ルールから見直すべきかもしれません。ただし、絶対に修正すべきと判断した場合は責任をとる意味でも妥協はしないようにしました。

修正した方が良いが時間がないからマージする必要がある、もうこれ以上作業時間が取れないから妥協して欲しいという状況は、コードレビューとは別に相談すれば良く、最初からそれを想定する必要はありません。また、過剰に相手の状況を想像してしまうと、人によってレビュー態度が変わってしまうことになります。

相手が誰であれ気になったところは指摘して、直せない部分があるなら相談したりペアプロしたり方向性から考えるなど、対処する方法は妥協する以外にもあります。そういう部分は想像して独断で決めるよりは相談で進めた方が良いです。

趣味:できたようなできなかったような

6〜8 月は自転車に乗り楽しんでいたものの 9 月以降は全然乗りませんでした。リモートワークが終わり生活に余裕がなくなったのと、10 月以降は寒くて外に出る気になりませんでした。来年の春くらいから乗れたら良いなと思っています。

プログラム

2020 年はこのブログを改善している時間が多かったように思います。あまり趣味でコード書く時間を取れていなかったのもあり、残念ながら新しい言語を触ることはありませんでした。

Gatsby Crudzoo

このブログの改善は切り替えが面倒になってしまって update-style というブランチでずっと行っていて、年末になんとか修正を master ブランチにマージして v0.3 としました。使用するとこのブログと同じ見た目、機能になります。

book review

あと、ついでに本のレビューをするテンプレートが欲しいと前々から思っていたので作りました。テンプレートを切り替える機能をマークダウンを設置するフォルダで分けるか、マークダウン内の key で分けるかは迷い、最終的に key で分けました

id: 'article-1'
title: 記事のタイトル
template: 'book-review'
score: 4

フォルダで分けると初期のセットアップが多少面倒になるのと、1 記事は最低書かないと GraphQL でエラーになりがちという理由です。theme とはいえ、現状でも設定項目が増えてきて使いにくくはなっているので、そろそろ工夫が必要ですが個人用だとどうしてもその当たり適当になるので考えるのいつになるやら。

総括

2020 年はコロナの年でもあり、結果的にかなり仕事の年となりました。2021 年も引き続き頑張るのか、燃え尽きてしまうのかはわかりませんができる範囲で頑張ろうと思います。

2021 年の小目標としては、仕事で支給されている Mac を 16 インチの MacbookPro にしたいというものがあります。2020 年は改善を唱え続けたものの、結局改善されず悲しい思いをしました。仕事でもそれなりに良いマシンを使いたい。

そんな要望が軽く通るくらいの実力を身につけるべく 2021 年もがんばります。2020 年ありがとうございました。


Tags: ポエム

コメント

頂いたコメントは管理者のみ確認できます。表示はされませんのでご注意ください。