あらかじめ、チェックすべき内容がわかっていて言語化されていない場合の話。
チェックリストがない。これはどういう状態になればよいのか、だれもわからない。これは本当に良い状態になったのだろうか？全部見た気もするけど自信がない。あれ？これ前回なおした気がするけどまたバグってる？おかしい。いったい何をすればいいんだ…。
よくある光景ですね。
まずは暗黙知を形式知へ変えていきましょう。まずはチェックリストですね。何をやったのかをリストアップしていけば、それがチェックリストになります。まずはこれを作る。
幸いにして、Markdownの書式でチェックリストが書ける。まぁ書けない拡張もあるんだけど。
- [x] 書いたけどはてなブログでは有効にならないっぽい？
早速書けなかった。まぁいいか。
チェックしたことを書く。このときに、何を、というかどういう項目をチェックしたのか、を分類しておこう。
- [x] 日付がYYYY-MM-DDの書式になっている
みたいな。
- [x] チェックツールのログにエラーがゼロ
とか。チェックリストの項目は、正しい状態で定義しても、間違った状態について定義しても良いが、統一した方が良い。あと説明は書くな。読みづらい。説明が必要ならば別途マニュアルを書くのだ。
チェックの完了報告ならば、正しい状態を定義したリストでよい。その方が日本語的にもわかりやすいし、終わった時に全てにチェックが入っていてよい気持ちになる。
道中、必要なタイミングでチェックをする。このときは次に引き渡してはいけないような問題をキャッチアップできるように、悪い状態を書いておく。具体的に書く。これが正しいタイミングで行われて、それが重要で、かつ具体的であれば効果がでかい。
これは、最終的な状態のリストが出来て、それを処理する時系列にまとめたあとに配分すればよいが、実際に手を動かしているのであれば、どういうフェーズでやったかを書いておけばよい。やったことは全部かけ。
最終的にはリストは長大になる。可能であれば項目を削る。しかし、その代わりにどこかに分離する。問題が起きたことであればいずれまた再発する。設計者が注意して対応する、では解決にならない。
チェックツールのログを見る、という話であれば、そのツールが見ている項目はサブチェックリストとなる。仕様を把握してリストアップし、このツールによるチェックがパスしていたらどの項目が信頼できる状態になっているか？をまとめよう。これらを階層化して管理しておけるならばそれが一番良い。
ツールでチェックできるようにするためには、入出力の仕様が必要。なので、ここで目視でチェックしている項目も、何をチェックしてどのような状態になっていればよいのか？の情報がまとまっているだけで、先に進めやすくなる。
そのために、まずはチェックリストを作っていくのだ。はよつくれ自分。
しかし、こういったことをやれる人が全然いない気がする。はじめは小さく始めればよいのに。長大なマニュアルなんて誰も読まないでしょ …？
というポエムでした。
昔、アナタはなぜチェックリストを使わないのか？を読んで、久々にチェックリスト作成のためのチェックリストを見直してみたけど、全然できてねぇのな…。
アナタはなぜチェックリストを使わないのか？ | 晋遊舎ONLINE
まぁ、遊びがなさすぎるんでしょうね。なければ作ればよい。何事も。
