今の会社に入ってから１年ちょっと経ったので、自分が導入してきた改善策をまとめてみました。
前提として、自分のチームではスクラム開発を取り入れているため、スクラムありきの施策が入っていたりします。

半期毎の開発チームフィードバック会

背景

成長実感や自分の強み、弱みなどを把握する機会がほしかった。

内容

毎週チーム内での振り返りがあるので、細かいフィードバックは行っているものの
半期という長い期間を通してどう成長したのかをチームメンバーがお互い共有し合う会を設けた。

やってみてどうか

自分が思うより一緒に働いている仲間からの意見の方が成長実感が湧くし、気づいていなかった自分の強みを知ることもできて良かった。
他のメンバーの評判も良かったので定期的に行いたいと思っている。

個人の消化ポイントを計測

背景

中長期的な開発スケジュールを決める上で、個人がどれくらいの仕事をこなせるのか把握しておく必要があった。

内容

毎スプリントの消化ポイント量を計測しスプレッドシートにまとめ、直近１０スプリント分の消化ポイントの平均値をベースにスケジュールを組むようにした。

やってみてどうか

平均値を使うことで安定したスケジュールを組むことができるようになってきていて、大幅なスケジュールのブレというものはなくなった。

売上に関すること以外のバックログも管理するようにした

背景

エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。｜みやたけ｜note を読んだことがキッカケ。
自分のチームではそれまで、売上重視で開発優先度を決められており、リファクタリングやテストコードを書く時間がほとんど取れない状態だった。

内容

売上に関するバックログとは別に、システム改善のためのバックログなども残すようにした。
また、テストコードに関しては機能実装の完了の定義に含め、必須とした。

参考にした記事では、事業系：保守系：改善系を６：２：２にしたらどうかと書かれていたが
今の事業部はまだ若く、保守よりも開発したい内容が多いため、事業系が８〜９割と多めになっている。

やってみてどうか

機能実装におわれて、保守性の向上ができない状態から抜け出せており
定期的にリファクタリングやアーキテクチャ改善をすることで保守性を高めつつ、新規機能実装に取りかかれている。

学ぶ時間を作る

背景

「この技術使ったらもっとサービスが良くなりそうだから検証したい。」
「技術書やマネジメント本などを読んで知識を深めたい。」

などの声はあったものの、目先の開発が優先されるのでなかなか手を出す時間を持てなかった。

内容

全エンジニア社員を対象に制度が作られた。
週に２．５時間分（３０分ｘ営業日分）、仕事に関係するもので興味のあることを学ぶ時間を設けることができるもの。
AWSのサービス検証をしたいという要望もあったため専用の予算が割り当てられおり、一定金額以内であればAWSサービスを扱うことも可能。
本に関しては申請すれば会社負担で購入してもらえる。

やってみてどうか

検証を踏まえた上でシステムに使う技術をより適切なものに変えてこれているし、便利ツールを作ってくれる人もいるし、インプットしたノウハウを活かす動きもできている。
ただ、目標を持って取り組まないとただの休憩時間のような感じになってしまったり、目先の開発を優先させたいなどの理由で、チームによっては形骸化してしまっている。

月次の全職種対象の振り返り会

背景

エンジニア内では毎週振り返りの機会があったものの、全職種対象のものはなかった。
他職種の人がどんなことをしているのかも見えにくかったし、現場が困っていることも把握しづらかった。

内容

KPT形式で、ルールとしては

その職種だけの話ではなく、事業部としてどうかという目線で話すように心がける
意見しても営業や開発の優先順位が変わる保証はない（検討はする）
の２点を設けている。

最強の振り返りメソッド「KPT法」で、失敗を反省するどころか、長所も希望も見つかった話 - STUDY HACKER｜これからの学びを考える、勉強法のハッキングメディア

やってみてどうか

大きなメリットとしては

職種をまたげるので事業部として影響度の大きい改善ができる
- プロダクトマネージャーがあれこれ全部やることになっているから、各職種でここの部分は巻き取ろうとか
- 社内ドキュメントが乱雑になっているから、こういうルールで整理していこうなど
他の職種の人がどんな成果を上げたのか、どんな問題を抱えているのか知ることができる
- フルリモートになって雑談する機会がないので、尚更こういう場での共有に重要性がでてきた

WorkingAgreement

背景

特にチーム内に問題があったわけではなく、カイゼン・ジャーニーという本にオススメされていたので用意した。

内容

チーム内での約束事を決めておくもの。
メンバーの動き方を縛るのではなく、チームの生産性をより高めることが目的なので、細かく決める必要はない。

例えば

朝9:50からデイリースクラムをやるので、時間までにハングアウトにする
欠勤の時は、9:30までにSlackのこのチャンネルで、この人たちをメンションに連絡しよう
午前リモート使う場合はこうしよう（後述）
中抜けして運動する場合はこうしよう（後述）

など

やってみてどうか

既存メンバーにおいては、普段から会話している中で共通認識を持てているのであまり活用する場はない。
ただ、新しいメンバーが入ってきた時に、これに目を通してもらうことで、チームの文化を知れる１材料になるかと思う。

チームポモドーロ

背景や内容に関してはこちらに記事を書きました。
ポモドーロ・テクニックを導入したことで解決できた課題とやり方について - Qiita

補足

新しく入ってきた人に言われたのですが、これのおかげで気軽に質問ができるから、心理的に良いとのことでした。
ただ、決まった時間に通話に戻ってこないといけないため、それによって集中が途切れてしまうというデメリットもあります。
今のチームでは、新しい人が入ってきた場合１ヶ月くらいはポモドーロにし、以降はチームでのポモドーロは廃止し、朝会と夕会を設けて情報共有しています。

Discordでのコミュニケーション促進

背景

フルリモートになった影響で、雑談が生まれにくく物理的距離ができた分チーム感も薄まってきてしまうのではないかと懸念を持っていた。
そんな時に、この記事を読んで弊社でも導入してみようと思い立った。
リモートワークでもさみしくない！Discordでバーチャルオフィスをつくりました｜フィードフォースのnote

内容

Discord上に社内用のサーバを設けて、ボイスチャンネルのみ作って運用。
気軽に話しかけられるということを目的としていたので、個人単位のボイスチャンネルを作ってもらって
「可能であれば」そこに入ってもらうようにお願いした。

会議用のチャンネルもあり、会議を行う時はそこでやるようにしていた。

やってみてどうか

人によって通話がうまくできなくなってしまうことが多々あり、会議が中断されることがしばしばあった。
これが原因で、安定して使えるGoogleMeetを使う人が増え、気づいたらDiscordに誰もいなくなってしまった。
雑談は生まれたので、その点においては良いと思った。安定性があれば…

業務委託の権限開放

背景

業務委託の人は
Slackはパブリックチャンネルすら招待してもらえないと見れないし
Githubはリポジトリ作ることができないし、見れるリポジトリも制限されている。

なので、情報共有も一手間かかるし、タスクの割り振りで気を使わないといけなかったりと余計なコストがかかっていた。

内容

業務委託も正社員と同じ権限にした。

やってみてどうか

余計なコストは削減されたのでめでたしめでたし。

中抜けして運動してくる時間を設けた

背景

コロナでフルリモートになった時に

一日中家にいるため体を動かすことがなくなった
気分転換をしたい

などの話がよくでていた。

内容

１５時〜１６時の間を運動推奨時間としてチーム内の制度として設けた。

ルール

制度を使うか使わないかは各自で決める
もし使うのであれば、終業時間をその分後ろにずらす

裁量労働制なのにどうして制度として設けたのか？

チームとして取り組んだほうが運動するキッカケになりやすい
日中の方が日光を浴びれるので、心身ともに良い

やってみてどうか

現状ほとんど使われていない…
導入当初はみんな使っていて良いと言ってたものの、気がついたら廃れていた。
働き方の自由として制度を設けておくこと自体は良いかと思って残しており、今もごく少数の人は使っている。

午前中のみリモートワーク（コロナが流行する前）

背景

通勤で、満員電車に乗って会社に来るだけで疲れてしまう…という問題を解決したかった。

内容

午前中はリモートワークでOK！
弊社は、9:30始業なので、（始業時間 - 通勤時間）から仕事を開始するようにしましょうとルールは設けていた。

やってみてどうか

自分は元々歩き通勤だったので、特に恩恵はなかったものの、１時間近く満員電車に乗って会社にくるような人には好評だった。

おわりに

弊社ではこういう問題があるからこうしたいと言えば、割となんでもやらせてくれるので、施策を考えて試すには良い環境でした。
まだまだ改善真っ只中なので、ネタが溜まったらまた記事にしたいと思います。