レビュアーによる後出しジャンケン
Summer498.icon
知ってるなら最初から言ってほしいよなsta.icon
無知なまま試行錯誤してさ、形式的なレビューをわざわざセッティングしてさ、そこでボロクソ言われるわけよ
いや人格攻撃と勘違いするとかじゃなくて、知ってることをこんな大掛かりで遠回りなやり方で指摘されるのがなんていうかもったいなく感じるsta.icon 興味深い問題👀
大概教えるべきことが膨大すぎて、逐一教えたほうが良いってなるんやろうなぁ
これを解決する方法として分厚いマニュアル作って、「まずこれ読め」ﾄﾞｶｯ!、ってのが考えられる
多数派の人はこの方法を嫌うとSummer498.iconは予想する
ゴツいマニュアルを読むことを嫌う人は多いだろうなぁ
一方でsta.iconはこの方法を好みそうとSummer498.iconは予想する
Summer498.iconは「検索できる場所に情報を置いとけ」と思うので、この方法に似たものを好む
これもあるsta.icon
「膨大な情報は既にある」「誰でも読める」はできてて、どちらかと言えばその先の「膨大な情報を頭に入れて上手い設計ができる」という応用で詰まっているsta.icon
あるいは応用についても情報化すべきってことなのかもしれない
「膨大な情報を頭に入れて上手い設計ができる」という応用まで行くと習うより慣れろの段階に見えるSummer498.icon
言語化したとて煩雑になりそう
ソフトウェア設計論を習ってると、煩雑さが凄いもん
それと同じ様になりそう
だと思うsta.icon
だからこそ最初に慣れた人につくってほしさsta.icon
井戸端の何処かに書いた気がするが（探し出せない）、自分が新しいチームに入るときに、チームメンバーに説明してもらうか、ある程度独学で調べた内容を自分がまとめて、チームメンバーに説明したあとに、理解の甘いところをチームメンバーに指摘してもらうか、みたいな話を思い出したinajob.icon
指摘が遅いことによる手戻り vs 良いレビューができる人を専有することによる機会損失 の天秤の問題のように見える
+1sta.icon
良いレビューができる人を専有できないことで発生する手戻りは仕組みの問題なので、工数に入れておきたい
別の問題として、習熟して慣れると言語化しにくくなるとか、言語化しにくいけど繰り返しで体得する技能とかありそうSummer498.icon
プログラム関連だと何でも言語化できそうな気になるけど
「膨大な情報を頭に入れて上手い設計ができる」という応用を言語化するのは、相当な言語化力が要る可能性
叩き台を作るケースだと、サーどんどん叩いてください！みたいな意識になることもあるかもinajob.icon
レビューされる側が叩き台と思ってなくて、レビューする側が叩き台的にコメントするとこういう気持ちになりそう
「最初から言ってほしい」この気持ちは分かるけれど、叩き台があることで指摘すべき内容が想起しやすくなる効果は大きいと思うkidooom.icon
でもレビューを受けた側が攻撃されたと思われるのであれば、言い方に問題があるのかなー
そのたたき台をレビュアー（になるような詳しい人）がつくってくれると嬉しいなぁ、とsta.icon
レビュアーがつくったたたき台1を、僕らが叩いてたたき台2をつくって、このたたき台2をレビュアーに見てもらうとか
僕らがつくったたたき台1をレビュアーが叩く、よりも早く質がよくなるのではないかなと