詳細仕様より業務仕様？

昨日はマーケティング系システムの効果検証プログラムのレビューをしていた

正直、週数日しかいない案件なのでどういう背景でどういう仕様になったプログラムなのか、も良くわからずのレビューということもあり、

詳細設計やコード、テスト結果を見る前に概要設計から埋めていった

見ていると、この項目、集計件数を入れたいはずなのに初期値から変わってないな、とか

実行日単位で複数レコードあるはずなのに集計が最新日しかできてないな、とか

負に落ちない点があり、PMに確認したところ設計の考慮漏れ、バグだった、ということが5,6点あった

そのPMも自分で設計レビューしているはずなのに気づかないのも大概だけど、

そもそもどういう業務に使うものでどんなデータがあるのか、という大枠から見ていないと見つからないようなバグだった

自分が数年前までそうだったけど、どうしても詳細設計やプログラムに拘って業務が見えてなかったり、そもそもデータの中身を知らなかったりもする

SIerは協力会社の方に手を動かすのは任せて…という話はあるが、業務とプログラムの橋渡しという点を強化していけば、存在価値があるのかな、と思う6年目社員

（ただ目の前の業務だけをやる先輩たちを見ながら…）

でも、その気づきのきっかけは協力会社メンバの若手の子の、「ここが良くわからないんですけど…」という質問がきっかけなので、どうかその気づきを大切にしてほしいと伝えた

自分は何が見つけたとか、やり切ったとかの時は人を褒めるようにしてる

逆に、ミスった人も責めずに、改善ポイントが見つかったからこれが分かってよかったね、と伝える

綺麗事だよなとは思いつつ、みんながこういう考え方になるように言い続けるし、それで世界が変わればいいななんておもう

昨日も楽しかった

P.S

テーブル定義書はあるけどテーブルの役割や項目の意味書いてないとか、テーブル間の関係性＝ER図が無かったり、という案件が比較的多いんだけど、

業務的観点、データの中身を意識したアプローチがやりにくいからやめてほしい…

あとCRUD図が無いとこかも、このデータどのプログラムが書き込んでんの？が分からないので是非やめてほしい