ソースコードレビューなど、設計審査(design review)は製造業、IT業界でも重要です。
Reviewerの能力
製造業とIT業界で大きな違いを感じるのは、Reviewerの能力の管理形態です。
製造業では、どの製品、どの技術を検討する場合には、誰と、誰と、誰の入った設計審査が必要だとすることがある。
IT業界でも、言語、OS、アプリの種類などで、その技術について、社内で最高の人を割りあてていることもある。
設計審査担当が超絶な人がいない場合には、納期、品質、費用の３人に分けて、それぞれの視点だけの意見をだすようにする方法もある。
IT業界でも、この人が見てなきゃ、出荷しちゃだめって、能力のある人を関門にしている場合があります。
その際に、なぜ、その人が見なきゃだめかの根拠を明示的に示していないことがあるような気がします。
オープンソース事業では、コードを書いた人の名前が残っており、こういうコードを書く人にはみてもらわなきゃってなって、根拠がわかりやすい。
ソースコードに人名を書かない事業だと、なんであの人がReviewerするのかってならないでしょうか。ちゃんとソースコードには人名を書くようにしましょう。
データを作った人、試験をした人、Reviewをした人も名前を刻みましょう。
静的検査・統計、整形
ソースコードレビューの前にしておくとよいこと。仮説（35）
レビューする前に、特定の道具で整形し、静的検査します。
ついでに、統計も取れば、作業の無駄が省けることがあります。
一番のおすすめは、単語の頻度表です。
一度しか現れない単語のうち、定義だけして使っていない変数、定数は、静的検査の道具（checker)で検査できます。それ以外に一度しか現れない単語が、注釈(comment)の用語であれば問題ないでしょう。その言語の予約語でも問題ないでしょう。
１文字だけ違う変数、定数は、checkerで検査できる場合があります。
２文字間違えるとチェッカで検査できないかもしれません。
checkerで対応できないところを、単語出現頻度表で確認するかもしれません。
レビュー方法
レビューにはいくつかの手法や、進め方があります。
IEC 61160:2005 Design review
https://webstore.iec.ch/publication/4707
IEC 61025:2006 Fault tree analysis (FTA)
https://webstore.iec.ch/publication/4311
EC 62502:2010 Analysis techniques for dependability - Event tree analysis (ETA)
https://webstore.iec.ch/publication/7131
IEC 60812:2018 Failure modes and effects analysis (FMEA and FMECA)
https://webstore.iec.ch/publication/23262
IEC 62740:2015 Root cause analysis (RCA)
https://webstore.iec.ch/publication/21810
IEC 61882:2016 RLV Hazard and operability studies (HAZOP studies) - Application guide
https://webstore.iec.ch/publication/24314
IEC 60300-3-1:2003
Dependability management - Part 3-1: Application guide - Analysis techniques for dependability - Guide on methodology
https://webstore.iec.ch/publication/1294
ディペンダビリティ管理－第３－１部：適用の指針－ディペンダビリティ解析手法の指針
https://kikakurui.com/c5/C5750-3-1-2006-01.html
JISK0050 化学分析方法通則
https://www.kikakurui.com/k0/K0050-2019-01.html
JISK0126 流れ分析通則
http://kikakurui.com/k0/K0126-2019-01.html
JISK0129 熱分析通則
https://kikakurui.com/k0/K0129-2005-01.html
これらをすべて知っていないと、ソースコードレビューができないという訳ではありません。
これらの知見があれば、システムが発熱したり、発火したりして結果として動かなくなるということを防ぐことができるという感じかなって思います。
IECの分析手法は、過去トラ(trouble data base)などを整理して体系的に利用するための手法であるとともに、これまで起こらなかった事象を効率的に予測するための手法です。どれか一つ知っていてもいいです。なぜなぜ分析といっているのは、これらの手法をできればすべてうまく使ってやると効率的だという経験則があります。一つの手法だけに偏った分析をしていると、予測事象空間も偏る可能性があります。
Reviewの勧め方
github, Markdownの利用（記録）
Githubをはじめとして、例えば文書はMarkdownで記載してWiki形式で整理します。
代替方法として表で管理することも可能ですが、10000件くらいを超えた時点で表よりはMarkdownで分類した一覧でかつ、全文検索できるのがよいでしょう。
対面とネットの均衡（検討）
Reviewというと、集まって、わいわいがやがややって意思一致すること（わいがや）だという仕事の仕方をされている組織があるとお聞きしたことがあります。
製造業の工程のように、どこかが少しでも止まると全体に影響を与えるような仕事の仕方をしている場合は「わいがや」も有効かもしれません。
ソースコードのように、よい設計であれば、部分ごとに試験をして、並列で作っていくことができる場合には、わいがやは必ずしも有効ではないというのが経験則です。
ネットでコンパイラやエディタ、OSなどがオープンソースでできてきた時に、９割くらいの時間がネットだけで対面での会議は、少数のコアチームだけで実施していたような気がします。
組織によって対面の割合が１割から５割くらいまではいろいろあると思いますが、５割を超えた時点で無駄だと思うとよいというのが経験則です。
指摘・改善案
指摘だけをした方がいいという流派があることは存じ上げています。
今時、静的検査の道具(checker)でも、改善候補を挙げる機能がついていることがあるかもしれない。
その際、指摘だけするか、解決策の案を１つから３つ提示するかなどのやり方がある。
指摘だけするのは、審査担当の時間が超過密な場合である。
解決策の候補は、他の担当でも出せるような場合にそうすることがある。
解決策の例を１つだけ示すのはお勧めできない。
それに依存したり、制約だと思ってなぞる場合が横行する可能性があるからである。
２つ示す場合は、えいやで選ぶことがある。３つ示す場合は、採用の根拠を示すとよい。
課題(issue)
ネットでやっていると、課題(issue)の上げすぎ、重複、矛盾を取るのが一つの課題になります。
LinuxのkernelソースのMailing Listなどでは、Alan Coxが仕切ってくれていて、日本のmailing listでは相手にしてもらえないような意見も、きちんとひろって課題として認識してもらえたことがあります。
課題を上げだすと切りがない面があり、どのような制約条件下のものだけ対応することにしても、大きいものと小さいものが混在したりします。
仮説・(96) open な issue がどんどん溜まる現象を解決するために
https://qiita.com/kaizen_nagoya/items/efe22d9a23ad2e9934d6
質問票(questionnaire)
人の話にいちいち無駄な質問か、誤字の指摘か文句をつけて無駄な時間を費やす。
その場で何も言わずに、陰口をついたり上につまらないことをチクる。
解決策を一つに限定し、押し付ける。
指摘だけして解決策を聞いても言わない。
参考資料(reference)
私達のレビュー技法（リーディング技法）
自己参照
プログラマが英語で報告・質問する時のいくつかの事例・方法
https://qiita.com/kaizen_nagoya/items/9cf2ba858e52e9795b67
プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69
bitbucket/github/gitlab連携環境構築（中）悪戦苦闘
https://qiita.com/kaizen_nagoya/items/87352fe88ceed2c1732d
IT系勉強会をすべて当たりにする方法
https://qiita.com/kaizen_nagoya/items/9f001a79ab4162220406
文書履歴
ver. 0.01 初稿 20201212
ver. 0.02 @kazuo_reve 私達のレビュー技法（リーディング技法） 参照にともない、整形・静的検査・単語頻度表 加筆 20220531
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.