システム開発で各工程ごとにチェックリストを用意するケースがあります。
正直チェックリストはなくて良いもの、自動化すべきものだったのですが、最近重要性を認識したので、その辺りを個人的な備忘録としてまとめておきます。

システム開発での一般的なチェックリストの存在意義

以下、　プログラマー向け成果物セルフチェックリスト | Fintan 　の記載内容を引用します。

大規模なシステム開発では、様々なスキルや経験を持った多くの開発者が参画するため、開発者が有するスキルや経験の差による品質のばらつきが多くなる傾向があります。 スキルや経験が不十分な開発者の成果物は、レビュー時に本質的でないレビュー指摘が増えることでレビューアの負荷が増大し、本質的なレビュー指摘に注力できないことで品質低下につながるリスクがあります。 そこで、本チェックリストは、開発者自身で事前にチェック・修正することで、レビュー前の品質向上およびレビューアの負荷軽減により、品質低下を防止する役目を担います。

  • スキルや経験の差から来る成果物品質のバラツキを抑える。
  • バラツキから来るレビュー時のレビュー作業の負荷を低減する。

というのが大きな目的かと思います。

チェックリストと失敗学

エンジニアのための「失敗学」のススメ：特集｜gihyo.jp … 技術評論社　に失敗学の失敗の種類についての記載があります。チェックリストはと各要因には以下の関係があると考えました。

  • 未知

チェックリストに記載されていない留意点、これから起こる事象

  • 未知

チェックリストにより、発生確率を低減出来る失敗

  • 不注意

チェックリストにより、発生確率を低減出来る失敗

  • 不遵守

チェックリストにより、発生確率が高まる失敗 (チェックリストを守らない)

  • 誤判断

曖昧なチェックリストの記載により発生する問題

  • 調査・検討不足

曖昧なチェックリストの記載により発生する問題

  • 制約条件の変化

制約情報の変化により、チェックリスト内容が陳腐化

  • 企画不良

チェックリストの内容が実行不可能

  • 価値観不良

独自ルールが多すぎるチェックリスト

  • 組織運営不良

チェックリストの内容が、陳腐化、形骸化

チェックリストと、MORSの法則

行動科学では、チェックリストがよくもちいられているそうです。

チェックリストの項目は以下を満たすとできているのか、できていないのかの評価がしやすくなります。

  • 計測できる（Measured）
  • 観察できる（Observable）
  • 信頼できる（Reliable）
  • 明確化されている（Specific）

チェックリストと、死人テスト

何々をしないことを確認するチェクリストよりも、行動をとったことを確認するチェックリストの方が、

チェックリストの使用者側は、チェックがしやすいように思います。

行動かどうかを確認するために行動分析学の死人テストを活用できます。

チェックリストと自動化

チェックリストの項目が増えすぎると、チェックが形骸化してしまいます。

自動化が可能な領域は、ツール等でチェック自動化、修正自体の自動化をするべきです。

システム開発であれば、プログラムに対するチェックのうち静的解析ツールでチェック可能なものは、チェックリストから除外してツールに任せるべきです。

codefactor-io/awesome-static-analysis: A curated list of static analysis tools, linters and code quality checkers for various programming languages

もしくは、静的解析ツールによるチェックを行ったかどうかをチェックリストに記載しておくのが良いと思います。

参考

コメント

カテゴリー

最近の投稿