こんにちは。DIGGLEエンジニアリングマネージャーのzakkyです。先月は埼玉県民の日（11/14）で学校が休みだったので、有給を取って家族写真を撮りに行ってきました。娘も息子も可愛かったです。

ということで、開発生産性 Advent Calendar 2022の23日目の記事となります。

前回のブログ投稿から約半年立ちましたが、その間に役職が変わりまして、エンジニアリングマネージャーになりました。今回は、マネージャーになって最初の記事という事で、技術的な話からは少し離れて、DIGGLEの開発効率向上施策について書きたいと思います。

そもそも開発効率ってどうやったら向上するんだろう

開発効率向上と一言で言っても色々な視点や施策があるかと思います。

ざっと思いつくだけでも以下があるかと思います。

CI/CDの導入・高速化
IaC化
よく使うコマンドをaliasとして展開
自動生成系のツールの利用（無ければ作成）

上記はDIGGLE内で実施している一例なのですが、今回は先ほどお伝えした通り、上記のような技術的な話からは少し離れ、開発チームとして行っている開発効率向上施策にフォーカスして書いていきたいと思います。

差し込み作業の発生頻度を減らす

皆さんも経験があるかと思いますが、今の作業に差し込みで新しい作業が発生するとガクッと作業効率が落ちることがあると思います。他の業種に比べてエンジニアは特にここの部分が顕著で、いかに作業に集中してもらえるかが肝になると考えています。

弊社では、そんなエンジニアの効率を下げる差し込み対応を、スクラムマスターに集約することで、他のメンバーが作業に集中できる状況を作るようにしています。

スクラムマスターには負荷になってしまいますが、トータルとしてチームの生産性は向上することとなります。また、余談となりますが、スクラムマスターを輪番にすることで、各メンバーの自律化を促す施策も行っています。こちらについて、詳しくは下記の記事で語っておりますので参照ください。

www.wantedly.com

自律したフルスタックエンジニアで構成する

弊社エンジニアはバックエンドやフロントエンドの垣根なく全員フルスタックに開発を行っています。また、全員が仕様の確認＆調整、CSなど他チームとの連携なども含めて自律して行うことができるので、開発要件1件につきエンジニア1人を割り振れば事足りることが多いです。（開発工数次第で複数人で開発することもあります）

これにより、作業工程間での連携で引継ぎ工数が掛かってしまったり、バックエンド（またはフロントエンド）側のタスクだけが積みあがって滞留してしまうといった事を防げます。

また、自律したエンジニアで構成されたチームとすることで、一般的にメンバーが増えれば増えるほど増加していくマネジメントコストの増加を抑えることができます。そしてマネージャーはマネジメントに追われることなく、開発へリソースを回すことができるようになります。

実際、今回マネージャーとなりましたが、マネジメントに関する工数はほぼ掛かっておりません。優秀なエンジニアに囲まれて嬉しい限りです。

チューター制度を採用することにより素早い立ち上がりをサポートする

せっかく新しいエンジニアの方に入社いただいても、実際に開発できるようになるまでに時間が掛かってしまっては意味がありません。ということで、弊社では新規参画エンジニアの方にはチューターを付けて、立ち上げをサポートする仕組みがあります。

チューターには、業務内容の説明や、各作業方法の伝達など細かなサポートをお願いしています。どのようにサポートするかについては、それぞれのエンジニアの裁量にお任せしているので、チューターとなるエンジニアごとに多少の違いはありますが、だいたい1カ月ほどで上記の自律したフルスタックエンジニアになれるようにサポートをお願いしています。

もちろん個人差もありますし、1カ月で「はいおしまい」ということではなく、チーム全体として新規参画エンジニアを受け入れる土壌を作る。ということに重きを置いています。

開発効率向上施策が打てる土壌を持つ

日々の開発の中で、「開発者として実施したいけど、目先の作業に押し流されてできないこと」があると、それが積み重なって負債となり、開発効率を低下させる要因となります。

例えば、以下のようなものがあるかと思います。

ライブラリやミドルウェアを最新バージョンに上げたい
CIが遅いから高速化したい
リファクタリングがしたい
- unusedなコードがあるから消したい
- 冗長なロジックを見つけたから共通化したい　など

弊社では、上記のような開発効率向上施策に全体工数の何%を使用して良いかを事前に経営層と相談し、工数を確保しておく仕組みを取っています。（およそ10～20%程度）

これによりプランニング時に、「次のSprintではRailsのバージョンを上げたい」であったり、「CIを高速化しないと作業効率が悪すぎるから今やってしまおう」といった事が行いやすくなっています。

※無論、予定していた機能リリースが遅延したりしては元も子もないので、杓子定規で測るのではなく、都度都度柔軟に対応しています。

メンテナンスする資料をむやみに増やさない

README、新規参画者向けのキャッチアップ資料、各種議事録など、ドキュメント化は率先して行っています。

ただ、エンジニアの本分はコードを書くことですので、資料を作成する際には必ず以下を確認するようにしています。

なぜ必要なのか
用途は何なのか
似たような資料、もしくは代替しうる資料は他に存在しないか
メンテナンスし続けることができるか（※議事録や調査資料など揮発性の高い資料は除く）

特に「メンテナンスし続けることができるか」が重要だと思っています。作ってはみたけど、メンテナンスせずに放置してしまうと、新規参画者へ間違った情報を与えてしまったり、逆に悪影響を及ぼすことすらありますし、メンテナンスするトリガーが明確か、工数を確保できるかも考えていくと、そこまで重要ではない資料は作成しない方向へ進むことが多いです。

そして、作ることに決めた資料は、チームとしてメンテナンスする意識を持ち、メンテナンスコストを認識・許容するようにしています。