開発外の業務でも Expected と Actual を意識して Unit Test の視点を持つ

こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。

開発業務においては当たり前に行われる「 Unit Test 」。

私がウェブエンジニアから人事に転身した後、人事業務のちょっとした資料作成などでケアレスミスをすることがありました。

その原因を掘り下げると、それは開発でいうところの Unit Test を実施していなかったからでした。

実際に、開発の仕事をしているときでも、システムそのものを扱う以外の周辺業務をしている場合に Unit Test にあたるものが抜け落ちることはないでしょうか？

まずは対象業務の Expected を明確にすることです。開発において、要件を明確にするのは当たり前です。

一方で、その他の業務においてゴールがふわっとしていて不明瞭、ということは珍しくありません。まずはゴールを明確にすることです。依頼者からの依頼が曖昧なら確認をする。依頼者自身もゴールを明確にもっていないなら、想定されるゴールを推測し、すり合わせるなどして Expected を明確にします。

開発において、対象機能の実装が終わったら一つ一つの項目表示や動作が期待値通りになっているか、実際の動作を確認します。

変更があれば、影響範囲を再テストします。

一方で、その他の業務において、ざっと仕上げて中身をもれなくチェックしないということは珍しくありません。

変更が発生した際に再チェックをしないことも珍しくありません。

作業が完了したら、その成果が想定通りか Expected と Actual を確認しましょう。

残念ながら組織開発や人事の業務において開発の Unit Test のように自動化をできるケースは多くありませんが、成果物が期待値に沿ったものであるかどうかを確認する Unit Test の目線を活かすことはできます。Unit Test の目線で「なんとなくできた」から「確実にできた」にしていきましょう。