今日Xでこんなことを呟いてみた
個々のロボットに対して技術的観点からのレビューしかできず業務観点で質の高いレビューができなくなってきたとき、頑張って業務理解する時間を確保すべきかどうか。
— いろはまる@RPAエンジニアCEO (@irohamaruRabbit) 2024年2月1日
まぁ1日でレビュー終わらせようとせずに数日時間もらって、業務/技術観点でのレビュー日を分けるとかして工夫するしかないかなぁ
ここ数ヶ月、開発メンバーにも業務理解と最適化、RPA化ができるよう、僕がしゃしゃり出るのをちょっと控えている。もちろん僕が完璧にそれらができるというわけではないし、むしろ僕をどんどん超えてほしいと思っている。
各メンバーが自走してくれるのは本当に助かってるんだけど、その一方でRPA化を進めようとしている業務に対する理解については、業務ユーザーと開発メンバーの直のやり取りがある分、どうしても置いてきぼりになりがちだ。
ユーザーが残してくれている業務マニュアル、RPA主担当者がまとめた要件定義書、メンバーが作った設計書、そして今までの数年間で蓄えた社内システムへの知見をもとに、どうにかして最適な設計を頭でイメージし、設計レビューや実装レビュー、テストケースレビューをやっている。
RPA化の案件が少ないうちはこれで回るんだけど、開発メンバーが育ってくると1メンバーで1案件こなせるようになってきて、いくつかの開発案件が並行して進んでいく。
そうなるとそれぞれの開発案件で扱っている業務について、いくつかのドキュメントと過去の知見をもとに、要件を理解する作業に追われることになる。
力の入れどころを見極めないと死ぬと思った僕は、各案件ごとにポイントになる箇所（仕様上ネックになりそうな要件、技術的な課題が出てきそうな部分）以外は開発メンバーに品質の担保をお任せするスタイルにしたのである。
その代わり、本番検証期間を長めにとり、開発メンバーとユーザーが綿密にやり取りしながら、仕様変更/追加対応やらバグFixやらを超高速で対応する。本番検証期間ですべての不備を吸収する作戦だ。
これはこれで何とかうまく回っている。最適かどうかはともかく
が、PMの僕は本番稼働しているロボットの業務内容について完全には知らないし、保守も開発メンバーにお任せすることも多い。（保守については専任メンバーを採用したため、今後はそのメンバーに移管予定）
うーん、なーんか気持ち悪い。。。
これ、本番で万が一ロボットが変な動きをして業務上めっちゃインパクトのある事故が起きた場合、責任とれるかな？
いや、PMなら責任取れよって話なんだけど、責任とるならリリース前にしっかり業務や仕様理解して、レビューもきっちりやって、PMが品質に太鼓判を押して、それからリリースしないと責任が取れないんじゃ…と。
責任って言葉が独り歩きしているような気もするが、責任とるために品質担保しようと思ったら、やっぱり各案件ごとに要件を理解する作業に追われることになる。この作業は結局しっかりやるしかないのか、と。
開発案件を受けて、PMがスケジュール引いて、開発メンバーに作ってもらって、実装の内容はPMはあんまり知らない。何か不具合起きたらメンバー対応してね。責任はPMが取る。
果たしてこれでいいのだろうか。
『よう分からんけど障害起きたからPMが責任取るわい！メンバーは悪くないんじゃ！（…でも作ったのはメンバーなんやけどな…）』
一見立派なPMに見えるけど、何にも知らないものに対して責任負うのってどうなんやろ。PMって何すればいいんやろ？w
