闇の魔術に対する防衛術 Advent Calendar 2020 16日目の記事です。
はじめに
いまだに少なくないシステム開発現場の最前線で品質を守っている『チェックリスト』。
プロダクトが長く続くにつれ肥大化していくチェックリストはディメンターの如く活力を奪っていくものです。
そんな『チェックリストの牢獄』から脱獄するための改善方法についてつらつらと書いてみたいと思います。
※ この記事における『チェックリスト』について
レビューなど成果物のチェックを行う際のポイントが記載されたものを指します
対象とする読者
チェックリストの量がすさまじい。
むだっぽいチェック項目が多くてうんざりしている。
なんかいけてないチェックリストを使っている。
脱獄するには
とにかくチェックリストをより良いものにし、数を減らしていくしかありません。
しかし不用意に減らして不具合を起こしてしまっては本末転倒。
今までの私の経験から、有効と思えるチェックリスト対策を以降で書いていきたいと思います。
改善１．チェックリストのターゲットを明確にする
どの成果物に対して、誰が使うのかを明確にしましょう。
例えば『コーディングチェックリスト（Java・実装担当者向け）』のようにです。
また、使う人のレベルも想定していることが望ましいです
行った作業に対して必要最低限のチェックとなれば自然と作業効率は向上します。
私が過去にいた現場では、CとJavaとbashが入り乱れていました。そして、なぜかチェックリストも共通になっていました。
『Q.インクルードヘッダの重複チェックは行ったか？ A.対象外：Javaのため』ほんとうに無益です。
改善２．チェックリストの内容を明確にする
定めたターゲットが理解でき、判断結果がぶれない表現にしましょう。
考える時間や無駄な悩みを減らすことができます。
誰も理解できないような項目があれば、それは消すしかないでしょう。
また、可能な限り～のような努力項目は多くの場合『可能ではありませんでした』と扱われるでしょう。消すか徹底するか決めた方がよいです。
妥協の基準を明確にしてもよいです。
経験則からすると、理解できない項目は「OK」または「対象外」とされてしまいます。
『あ～、その項目はとりあえずOKにしとけばいいよ』なんて扱われる項目はもう要らないでしょう。
改善３．チェックリストの運用を定める
チェックリストをどう使うか決めましょう。
ポイントは下記です。
- いつ使うか
- いつ見直すか
改善３－１．いつ使うか
作業のどのタイミングで使うかを明確にしましょう。
作業のはじめに目を通しておき、おわりに成果物と照合する運用が手戻りも防げて効率的です。
ドキュメントにするなどして、必ずこれが守られる運用を構築することが重要です。
顧客とネゴった内容がチェックリストに反していたとき、変更を受け入れて貰うのは精神的にも顧客の心情的にも非常に厳しいものがあるでしょう。
実装などでも同様で、さんざん作ったあとにチェックNGですべて作り直し。これでは目も当てられません。
『手戻りに大変ですし、今回だけそのチェック項目無視しましょう』なんて言いがちですが今回だけにはならないでしょう。
改善３－２．いつ見直すか
チェックリストの見直しタイミングを明確にしましょう。
案件の終わりでも、3か月置きでもよいです。誰がいつ見直すかを決めておくことでチェックリストの陳腐化が防げます。
無意味なチェックが並んでいるとチェックリストが軽視され、チェック漏れやみなしOKが多発します。
『記載内容が古いんで使われてないと思って、適当にOKにしてました～(^^)』とリスペクトされないチェックリストは無意味です。
改善４．チェックリストの内容を減らす
脱チェックリストです。最終目標でもあります。
- 勉強会を定期開催して知識定着させることで項目を減らす
- 自動化により項目を減らす
- チェックリストの必要な作業自体を何らかの方法で消す
方法は色々とあるはずです。改善１，２によって各項目が理解できていれば、消す方法はいくつか浮かんでくると思います。
『チェックリストは使ってたんですけど……。その、項目が多くて見逃しました』何のためのチェックリストなのか。ザ・本末転倒。
まとめ
少しでもチェックリストを『まとも』に近付ける方法について書いてみました。
- ターゲットを決める
- 内容をわかりやすくする
- 運用する
- 減らす