はじめに
この記事は「エディトルブログキャンペーン」3日目の記事です。昨日はバックエンドエンジニアの三島による「LaravelでレイヤードアーキテクチャとCQRSの導入事例」でした。
11月に大雨のなか山中キャンプを経験し、それ以降は毎月1回の休暇をキャンプに当てている垣花です。
内定者インターンとして主にバックエンド開発に従事したのち、1年目後半あたりからエディトルの開発に携わっています。 エディトル開発チームでの自分の役割について振り返り、今後メンバーとしてやっていくことを改めて考えるための機会になればと思い記事を書いています。
エディトル開発メンバー構成概要
現在の開発メンバーは内定者インターン生をあわせて5人で主な役割内訳は以下になります。
- マネジメント 1人
- フロントエンド開発主担当 1人
- バックエンド開発主担当 1人
- フロントエンド、バックエンド開発 2人 (内1人、内定者インターン生)
役割は別れていますが、各々が部分的に他のこともやりつつサポートし合いながら進めています。
現在の役割
メンバー構成の中でいうと、私の役割はフロントエンド、バックエンド開発です。
役割としてどちらも対応する頻度が高いだけで、フロントエンドとバックエンドの開発主担当の両名ともどちらの開発もできます。
そのため、私の役割はフロントエンドとバックエンドのリソース調整というのが大きいです。
- リリース時期が決まっている中で休暇や体調不良が出たとき
- 片方に作業量が偏ってしまう機能開発をするとき
- 中、大規模な改修や機能追加と並行して直近で対応が必要な小規模開発
開発と合わせて最近はサービスの運用保守もよく担当しています。
運用保守ばかりしていると開発するための時間がなくなるので、いかに素早く正確に対応するかを考えています。
そのために2回同じ作業をした際には対応テンプレを用意するようにしています。
同じような依頼が来たときに対応テンプレがあり、自分以外が対応しても問題ない状態になっているときなど密かに喜びを噛み締めています。
運用保守は比較的開発よりも面白みが少ないと感じていますが、誰もができる状態や自動化の提案できるのは運用保守を進めていなければ得られない喜びです。
課題
開発速度や品質を上げるために開発方針は日々変わるものです。
どちらも開発するということはフロントエンドとバックエンドの開発方針の変更を常に把握する必要があります。
現在は常に把握するだけで良いですが、これからは自らより良い設計や方針を考え提案できる必要があると感じています。
もう1人設計や方針について話し合える人がいれば主担当の負担や不安も減り、より良い方針を決められるはずです。
両方の主担当に対してより良い設計や方針の案を提示できないのが大きな課題です。
役割を増やす
開発チームとしてフロントエンド、バックエンド、運用保守などをメンバーの誰でもできるような動きを進めているので、今全てできるからということに大きなメリットはありません。
今後、弊社の開発室内で弊社サービスのエディトル開発チームとサグーワークス開発チームなどとの垣根をなくすために体制変更の動きもあります。
更にエディトルをユーザを増やし質の良いサービスにするためにも、今後の個人的な目指す場所は下記になるだろうと意識しています。
- フロントエンド、バックエンド両方の方針決めにも意見出しや相談ができる人
- エディトル以外の弊社サービスや弊社の方針を踏まえた開発チーム同士の連携をして、ボトルネックを解決できる人
色々課題や目標を挙げていますが、いつも考えているのはどちらの開発もできて運用保守など細かいことはできるが秀でたものはないという、器用貧乏状態の脱却です。
今は、他のメンバーの手が回らない箇所を主に対応して自身がチームを引っ張っていける状態にはありません。
今後はこれまでよりこの人に仕事を頼みたい、相談をすれば解決できると思ってもらえる人を目指していていきます。
明日はエディトル開発チームのマネジメントをしている横道で「品質スプリント、独自の開発フローでチーム再建」」です。乞うご期待！
