プロセスを導入/改善するときに意識していること

既存の開発プロセスに新しいプロセスを導入したり、プロセスを改善したかったりするときがある。

僕はそういうとき、その場の状況によって２つの方法を使い分けている。

①既存のプロセスが存在せず、新規に立ち上げる場合

例えば、１人目QAとしてチームにジョインしQAプロセスを立ち上げがミッションとなっている場合。この場合は、JSTQBのシラバスや専門書を参考にしてフローチャートや図、表を作って数枚のスライドにまとめる。そして、開発チームのメンバーに「こんな感じで進めたいと思うのですがどうでしょう」とプレゼンする。フィードバックを基にして数回ブラッシュアップし、チームの合意を取ってからプロセスの実施を開始する。

形式張っているというかフォーマルというか、セレモニーを経て導入するイメージ。そこそこ大きめのプロセスを導入する場合はチームに与えるインパクトも大きくなるし、そのプロセスに関して専門知識を持たないメンバーもいると思われる。そのため、関係者と事前に打ち合わせて、影響範囲やリスクを把握した上で導入したほうが良いだろうと思っている。

②既存のプロセスが存在しており、これを改善したい場合

例えば、テストデータの作成がボトルネックになっていて、これを自動化したい場合。この場合は、まず個人レベルで実験を繰り返して試行錯誤し、効果が出たらチームメンバーに紹介するようにしている。別にコソコソやる必要はないんだけど、かといってセレモニーを経たり合意が必要な粒度ではないため、まず自分でやってみて効果を実証してからジワジワ広げていくと良いだろうと思っている（このとき、ドキュメントを用意したりハンズオンセッションを開催したりすると、他のメンバーにも伝わりやすくなる）。

逆にアンチパターン的な振る舞いは何かあるかな、、と考えてみたところ、「虎の威を借る狐」「野次馬」は推奨されなさそうだと思った。

①虎の威を借る狐

例えば、

〇〇っていう技術が話題なんです！A社もB社も導入しています！QA界隈で有名なCさんも使ってるって言ってました！私達も今すぐ始めるべきです！！

みたいな、皆がやってるから凄いんです的な説明の仕方は、チームメンバーから理解を得るのは難しいだろうと思う。「チームの課題は何か」「そのプロセスを導入/改善することで何が得られるか」をロジカルに説明すると納得感が得られると思う。

②野次馬

例えば、

この課題解決するためには〇〇っていう技術を使うといいらしいですよ！すごくないですか？さあ始めてください、ほら、ほら！！

みたいな、要は口は動かすけど手は動かさない的な振る舞いも理解を得られなさそうだなと思った。まずは自分で動くことが大事だと思う。