少し前ですが、Reproさんのイベントで登壇させていただきました。
その際に使用したスライドの共有と、深掘りをしたいと思います。
スライド
まずは耳障りの良いKeepからいきます。
Keep
リリースしたり、効果が良かったりすると事業側のメンバーから感謝される
素晴らしく良い雰囲気で仕事できます。何気ない一言で救われる場面が多々あります。
（自分は特にちょろい気がする）
Githubフローをちゃんと回せている
当然の話ではありますが、事実良い習慣なのでKeepしたいです。
開発環境をDockerで構築できるようにした
新しいメンバーが参画する時にめちゃくちゃ楽になりました。特定のバージョンのミドルウェアを使用していたりするとセットアップ手順のアップデートが大変なのですがコマンド数回でセットアップできるようになりました。
効率的にレビューをするために色々ルールを設けた
2名以上のレビュアーに見てもらうというローカルルールがあるのですが、一日10プルリクエストほどレビューしないといけないので気を抜くとすぐ溢れてしまいます。
レビューをする時間を決めたり、レビュアー毎に権限を設け この人のレビューを貰わないとリリースできない というルールを設けました。
権限のあるレビュアーはしっかりと見ますし、通常のメンバーはレビューに対して重い責任を負わずに済みます。
良かったのは メンバーが軽い気持ちでレビューができ、レビュアーはメンバーのレビューを参考にできる という点です。
Jenkinsを使ってデプロイやタスクの実行をできるようにした
DevOps的な。ここはSlackに移行するなどTryが挙げられそうなKeepです。
RspecとSeleniumが主要な機能をカバーした
テストのカバレッジが極端に低かったので、サービス(ビジネス)として障害になってはいけないところのテストを厚くしました。ユーザーの基本フローを網羅することで実装者、事業者が安心して過ごすことができるようになりました。
Reviewdogで自動的にコードの書き方を指摘されるのでロジックに対して議論することができる
導入はぐぐっていただけると助かります。
ドキュメント管理システムを導入して非エンジニアも巻き込んだ
色々なツールを試しましたが、カスタマイズが可能なオープンソースに落ち着きました。
API連携も見据えた動きができています。
ここからは直近のプロジェクトを振り返ってみた結果
プロジェクトのキックオフをすることでコアメンバーの意識を統一できた
なんだかんだキックオフは大事。ゆるゆると始まるプロジェクトはだいたい炎上する気がします。
プロジェクト進行においてシンプルなルールだけ決めて守るようにした
blameしない、前を向く、などプロジェクトマネジメントの基本を守りました。
当然ながら良い習慣だと思います。
何のためのプロジェクトなのかを明確にした
めちゃくちゃKeepです。意思決定のスピードが格段に向上し、方向性が明確なので決定事項について背景を説明することができるので、
メンバーが納得感を持って業務に当たることができます。
ガントチャートをすぐ更新できるように専用のツールを導入した
Backlogを普段使っているのですがガントチャートの更新が非常に多かったのでxPlanというツールを導入しました。
クリティカルパスの設定も簡単にできるのでおすすめです。（有料）
Backlogは基本的にFIXした内容とスケジュールのみ記載するようにした
ガントチャートと分業したので相応の使い方にまとめました。
情報が散らばらないのは良いことです。
Try
KeepからTryに挙げられるのは以下です。
- Jenkinsで運用しているものはSlackやクラウドサービスへ移行できそう
- Rspec, Seleniumのカバレッジを増やしたい
- とは言えテストリソースの上限はあるのでバランスを取るべき
- 開発用DockerImageを配布できるようにしたい
- Reviewdogはタイミングによって邪魔な場合があるので任意での実行も視野に入れる
- ドキュメント管理者が不在なので責任者を据えたい
- 進行管理の雑務に時間を割くことに対する心理的ハードルを下げたい
- ガントチャート、Github、Backlog、スプレッドシートを使って進行管理すると情報が分散して効率が下がるポイントがある
- プロジェクト管理及びドキュメント管理のベストプラクティスを探る
重い話になるProblemは後編で綴っていきたいと思います。