中規模チームを支える自動化と属人化しないノウハウ共有の取り組み
講演者
矢吹 遼介 さん（面白法人カヤック）
資料
講演内容
マスターデータの運用を自動化することで色々なことが出来ると思い自動化を決意
前提としてこのセッションの内容ではマスターデータの編集にGoogleSpreadSheet（GSS）を使用
GSSのメリット
- 同時に編集することが可能
- インターネットに繋がっていればどこでも編集可能
- 編集の履歴が残る
- JavaScriptでプラグインを記述することが出来る
デメリット
- 式や関数を使うとすぐに重くなる
- インターネットに繋がっていないと編集できない
自動化前の問題点
同時に編集出来るが作業の衝突が発生し易いため使用する際に宣言をしていた。
テスト前のデータを入力中に本番に公開しているデータの修正が入った場合にRevertしていた。
現にこれと同じ状況に遭遇していたりする
対策（まるっとコピー）
本番のマスターデータをコピーし、QA前は複製したものに記入しテストを行い、
完了したものを本番に移動して順番待ちという状況を一旦回避した。
だが！
これでは解決せずに修正したものが編集中のものに反映されずに巻き戻ってしまうことなどがあり
問題が発生した祭の調査にエンジニアの手間が増えるという状態に陥っていた。
対策（GSSの分割）
基準となるシートとそれに追加するシートに分割を行い、
データを取り組む際に元のシートと追加したシートを統合するように対策を行った。
これによりデータの入力待ちという無駄な時間の発生がなくなり、
また、データの不具合の調査等も追加されたデータのみを見ることで可能となり
調査する手間も併せて減少することが出来た。
新たな問題
だが、マスターデータの更新頻度が上がったことにより、テスト環境が足りなくなった。
テスト環境は約10個ほど用意していたが、テストする際にその環境を他の人が使っていないかなどの
確認をする手間が増えてしまった。
docker×mirage（内製のミドルウェア）で対応
確認環境を自動的に立てるように対応を行った。
こうすることで、サーバーの空き待ちなどをする必要もなくすぐに確認することが出来るようになった。
※一定間隔で未使用の環境や無くなったブランチの環境などは削除するように対応
さらなる問題が発生
データ入力の高速化、テスト環境の改善を行った結果
施策内容が増加しその影響でQAチェックが甘くなってしまっていた。
そのため、マスターデータを反映する前にチェック機能を設けて入力ミスを未然に防ぐように対応を行った。
属人化しないノウハウ
- アチーブメントシートを作成する
アチーブメントシートは自身の主観でそのプロジェクトにおいて何が出来るかを見える化したもの。
これを元に同じ人に同じようなタスクを常に割り振るのではなく、メンバの成長のために挑戦的な形で
タスクを割り振ると良い。
ただし、いくつかのデメリットが存在している。
- アチーブメントシート自体を作るのが大変
- メンテが大変（機能追加などがあるたびに更新しないといけない）
- 主観で作成するため完全に信用しきってはいけない
- 評価に結び付けない ←結びつけると誰もやらなくなる。
- ノウハウがある人でないと出来ないタスクも存在する（緊急時対応など）
これに対応するために専用タスクが完了した際に簡単な資料をまとめてもらい
それを元に情報共有を行い、ノウハウの蓄積をしていくことが大切
まとめ
マスターデータの入力の手間を解決することで、今まで見えていなかった問題が浮き彫りになり、
最終的にはQA体制の見直しなど他人事とは言えないような話を聞くことが出来、
とても参考になりました。
対応できそうなこともあったりするので、合間合間に対応していってもいいのかと思いました。