人生初の要件定義で感じたあれこれ
はじめに
人生で初めてERPの刷新プロジェクトにアサインされました。プロジェクト自体はまだまだ序盤で要件定義が終わったばかりなのですが、プロジェクトが進んでいくにつれて感じたもやもやとこういう感覚が必要ではないのかと思ったことがあるので、そちらを備忘録という意味も込めてつらつらと記述していこうと思います。
私の現在地
私はこの職場での経験は2年間で、主にデータ基盤の構築などデータ分析の推進を担当してきました。つまり、会社の基幹的な業務、特に今回刷新する会計システム周りの業務に関してはほとんど無知な状態です。ついでに会計的な知識も全くなく、ミーティングで飛び交う用語ですら理解が怪しいレベルです。必要な知識って突然求められますよね。
私に必要だったこと
業務理解
業務の理解が足りてませんでした。ほかのメンバーがベテランであり、業務経験が浅い（特に会計領域）私には多くは求められていないことはPMから伝えられていたのですが、やはりどんな小さいシーンの一つとっても会話する内容の解像度がほかのメンバーと比べて低いです。ミーティングの中で分からない業務が出てきた時にはどういうシーンがあって、どの項目に話をしていたのかを調査・質問することにしていました。理解できたことは多くあったのですが、逆にわからないことが多すぎていくら時間が足りなかったです。
質問力
他メンバーへの質問が足りなかったと上司から指摘されました。私はこのPJの中では一番若手でシステムをよくすることよりも多くのことを吸収することを期待されていました。私の疑問を解消するサイクルは
- わからないことを明示的に書き出す
- 自分なりの方法で調査をする
- 調査した内容を検証する
- それでもわからないことを質問する
以上のサイクルを質問までの道のりとして課していました。しかし、自分なりの方法で調査するところから時間を浪費してしまいました。もちろん自分なりの方法なので時間もかかる上に不十分なことが多いこともありました。多くの疑問が浮かぶ中でこのサイクルで疑問を解消していくことは不可能に近いことでした。足りなかったこととして質問力と書きましたが、私に足りなかったことは質問力ではなく検証力だったのかもしれません。そこに気が付いた時からは2の段階から積極的に質問することでサイクルを回していけるようになりました。
やってて無駄だったなって思ったこと
空中戦の展開
空中戦と書きましたが、これはメモやたたき台が全くない状態で会議を進行することを指しています。ユーザー部門から業務内容のヒアリングをおこなう際にユーザー部門の方が主体で話すシーンが多くありました。このときユーザー部門の方は呼ばれただけなのでなにも用意することはなく白紙の状態で話し始めることがありました。こうなると多くの時間を浪費します。
- 聞いている側は正しくキャッチアップできているのか不明
- 周囲の理解は完全に置いてきぼり
- 思い付きで話す人もいるので業務の構造的な理解が困難
- 後に認識の齟齬が発生しやすい
特に会計などの複雑な話になるときは空中戦のパターンは避けなければなりません。時間をかけた割には決まったことや共有できたことが少ないという事態に陥ってしまいます。どんなに簡単でもいいので自分がなにかを話し始めるときはたたき台になるようなものを用意しようと思いました。聞く側の認知負荷をなるべく下げ、積極的な議論になるような場を作ることが重要だと感じました。
要望の要求
要件を定義している場で要望の要求を聞く回になってしまったことがありました。要望を聞いている中でも現状の業務との比較が出ているので、問題はないシーンもありました。しかし、要望をまとめる回は別に用意されているため、要望を収集する回と要件をまとめる会で別々におこなったほうが議論がクリアになるのではないかと思いました。
まとめ
今回初めて要件定義を経験した私が感じたことをつらつらと書いていきました。要件定義では我々IT部門がベンダーとユーザー部門を繋ぐ役割が重要であると感じました。ベンダーさんは会議の準備をしてくれますが、ユーザー部門は呼ばれただけでお客さん気分で来る方が多かったです。呼ばれただけの会議で結構ハードな質問責めにあって準備不足であるシーンもありました。問題は他にもあったような気がしましたが、いま思いつく限りでは以上のようなことになります。やはり感じたことは何かしらの記録にとっておくことが重要ですね。今後PJは基本設計、開発、データ移行、テスト、本番稼働と進んでいきます。その中で感じたことがあればまたこのような形でまとめて記録として取っていきたいと思います。システム刷新のいい経験になるように頑張ります。
