ソースコードレビューなど、設計審査(design review)は製造業、IT業界でも重要です。

いくつかの手法や、進め方があります。

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などがオープンソースでできてきた時に、９割くらいの時間がネットだけで対面での会議は、少数のコアチームだけで実施していたような気がします。

組織によって対面の割合が１割から５割くらいまではいろいろあると思いますが、５割を超えた時点で無駄だと思うとよいというのが経験則です。

課題(issue)

ネットでやっていると、課題(issue)の上げすぎ、重複、矛盾を取るのが一つの課題になります。

LinuxのkernelソースのMailing Listなどでは、Alan Coxが仕切ってくれていて、日本のmailing listでは相手にしてもらえないような意見も、きちんとひろって課題として認識してもらえたことがあります。

課題を上げだすと切りがない面があり、どのような制約条件下のものだけ対応することにしても、大きいものと小さいものが混在したりします。

仮説・検証(96) open な issue がどんどん溜まる現象を解決するために
https://qiita.com/kaizen_nagoya/items/efe22d9a23ad2e9934d6

能力

製造業では、どの製品、どの技術を検討する場合には、誰か誰か誰かの入った設計審査が必要だとすることがある。

IT業界でも、言語、OS、アプリの種類などで、その技術について、社内で最高の人を割りあてていることもある。

その際、指摘だけするか、解決策の案を１つから３つ提示するかなどのやり方がある。

指摘だけするのは、審査担当の時間が超過密な場合である。
解決策の候補は、他の担当でも出せるような場合にそうすることがある。

解決策の例を１つだけ示すのはお勧めできない。
それに依存したり、制約だと思ってなぞる場合が横行する可能性があるからである。

２つ示す場合は、えいやで選ぶことがある。３つ示す場合は、採用の根拠を示すとよい。

設計審査担当が超絶な人がいない場合には、納期、品質、費用の３人に分けて、それぞれの視点だけの意見をだすようにする方法もある。

　質問票(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