泳ぐオダジン放送局

日々フラフラっと回遊しながら気づいたことをラジオでフリートークするようにお届けします。ラジオ好き、少年ジャンプ好き、ハンバーガー好き、ヒトが好き。※本ブログの内容は、私個人の考えです。所属する組織・団体とは関係ありません

エビデンスは揉めないためではなく上手く行くために自ら作ろう

今日は自分の業務に関連する社内システムのリリース日でした。IT企業の元エンジニア、今は人材開発担当の私ですが、エンジニア時代にシステム開発を担当したことはありません。そんな私が、システム開発を依頼するユーザ部門側として関わって感じたことを書いてみます。

充分にやったはずでも要件定義が不充分

今回のプロジェクトでは「最初にきちんと要件定義をしよう!」と開発側とユーザ側で意識合わせをして、数回の打ち合わせを行って洗い出しをし、Excelファイルに要件をまとめました。しっかり出来たと思って安心していたのですが・・・、テスト段階でExcelの要件一覧と突き合わせながら、動きを確認していると、「あれ?なんでこの動きが漏れてるんだろう・・・?」「この機能、必要って言ってたよね・・・?」のような考慮漏れが、いくつも出てきました。結構ショックでした。orz

エビデンスを残してなかったらアウト

f:id:odajin:20171021014930j:image

そもそも考慮漏れしていたものも残念な気持ちになりましたが、打ち合わせ時点で「必要」と話題になっていたものは、打ち合わせの議事録を残す、もしくは要件定義のExcelを更新していれば実現していたものだったので、非常にガッカリしました。普段、議事録研修で「議事録はエビデンスとして・・・」って研修を行っている自分が、議事録で記載漏らしてはイカンです。。。orz

全てを網羅したテストは不可能

開発作業の終盤にユーザテストとして動作確認をしていたのですが、十分にテストを行ったはずが、本番利用が始まったところで、テスト時点では気づかなかったバグやそもそもの考慮漏れが散見されました。テストしていたはずが、お試しになってしまっていたのかなあと反省です。

今後に活かそう

  • 要件の洗い出し方とチェック方法を再検討
  • エビデンスはとにかく残す(議事録を書く、資料を更新する)
  • ユーザテストは開発に関わっていない人にもやってもらう

 

素敵な明日を