算譜(program)は、一人で書いていると思い込みや、勘違いでとんでもない穴が生じていることがある。静的検査、動的検査、証明などの道具を用いても、思い込みや勘違いのうち、根本的なところは抜けていることがある。
目的(purpose):
20180228 小寺浩司さんの助言に基づき追記
一人で仕事をしていると、うまく行っているか不安になってストレスが溜まってくる。その溜まったストレスを、先輩や専門家、あるいは新人の純粋な目で見ると、なんだそこを直せばスッキリするんだと、ストレスを解消させることがReviewの目的です。
成果(outcome):
20180228 小寺浩司さんの助言に基づき追記
ストレスが解消するため、担当者のやる気が倍増し、作業効率が良くなる。
ソフトウェアの見直しに必要な志向、技能、技法、手順を考え、それらに優先順位をつけて上位７つを記載する。
p.s.
ソフトウェア設計・開発で、仕様書、設計書を日本語で書いている人たちがいるらしい。また、それらの文書の見直し(review)で、わいがや、顔見せ、憂さ晴らし、息抜きをしている人たちがいるらしい。
1 関係する技術について技能・経験のある人に参加してもらう
これが一番大事。どの技術については誰の意見をもらわないと駄目みたいな習慣があればよい。組織内に誰もいなければ、組織外からの参加を要請できる習慣も大事。
よく見落としがちなのが材料。新しい材料を使っていれば、重さ、硬さ、動作、防水・防塵・耐熱、耐用年数など違うことがいっぱいあるのに、何のパラメータを変えれば充分かの専門的な知見、試験結果の評価ができていないと、大きな失敗をするかもしれない。
仮説・検証(73)プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69
2 問題解決の意志
問題を解決するソフトウェアを設計・開発する場合に、必要となるのは、問題を解決するためのプログラムを書く人の強い意志（やる気）が大事。問題を解決するつもりがない人の説明を何時間聞いても無駄。解決したい問題の大きさと、その解決するための意志があれば、オンラインで内容を検討したり、集まって検討会をするのは無駄。
問題を解決する意志がない人がいても、集まって、わいがややって、なんとか組織として解決したいという管理者の方がいるのかもしれません。確かに、時間とお金があれば、わいがやの中から、解決策が生まれる可能性はあるでしょう。
最悪なのは、問題を解決する意思がなく、見直しの方法や手段、情報を伝達する意思があるかどうかを問題にする人。問題を解決する意思のない人に、情報を伝達しても、足を引っ張るだけで協力しない人になぜ情報を伝達する必要があるのだろう。
報連相がうまくいかない場合があるのは、報告しても、連絡しても、相談しても、足を引っ張る人がいれば台無しだということを自覚されているのだろうか。
仮説・検証（40）報連相 再考
3 ソースコードまたは図で評価
どんな難問題も、大規模案件も、その問題の核心を解決する論理は簡単かもしれません。逆に、難問題であればあるほど、大規模案件であればあるほど、核心を解決する論理が単純でなければ、プログラムの構造(architecture)が複雑になり、試験・検証が膨大になり、莫大な経費がかかるかもしれません。
最初の段階で確信の問題を解決するプログラムを書いてみて、そのソースコードを評価する集まりを開いておけば、大規模・長期的・大人数の設計・開発でも、問題を解決する意志を集中させることができるかもしれない。
問題を解決するには、ソースコードばかりでなく、状態遷移図、時系列図、刻時図、利用事例図などUMLで定義している振る舞い図が適しているかもしれない。これらの振る舞い図は、容易にソースコードに変換できるあるいは、仕様記述から生成できるかもしれないため、図から入るのが正解な案件は多数ある。
UMLではなくSYSMLを使えばよい場合もあったり、DSL(Domain Specification Language)で書いた方がいい場合もある。ソースコードではなく仕様記述言語で書いて、ソースコードを生成する場合もある。どの段階で、どの仕様を見直すとよいかのよい習慣を生み出そう。
実物による実演、動画、写真で良い場合もあるし、模擬試験を行っても良い。
ソースコードに全体の構造、動作の説明が書いてあるか、リンクしていないソースコードは読みません。
20180211追記
自分のソースコードに全体の構造、動作の説明が書いてなかった。
追記しました。紺屋の白袴
https://researchmap.jp/jovqfzcc8-1797580/#_1797580
// 1 General
// 1.0 filename: Te_td_accum2.cpp
// ver 0.1, 9(Mon), Oct, 2017
// 1.1 purpose
// Functional testing, multiple compiler benchmarks and understanding of Template source code
// 1.2 mechanism
// Add code for output of the result of processing to fragment of code on the book.
// This mechanism came from The C puzzle book. https://www.amazon.com//dp/0201604612/
// 1.3 Outcome
// Functionality: Easy to process the function.
// Confirmability: Easy to output the result of processing.
// Comparability: Could compare the compiler differences.
#include <iostream>
#include <string>
#include <cstdlib>
// 2 original examples and/or notes:
// (c) Copyright 2003 "C++ Templates - The Complete Guide" by Pearson Education, Inc. David Vandevoorde, and Nicolai M. Josuttis. All rights reserved.
// http://www.josuttis.com/tmplbook/
仮説・検証（51）公開算譜は機敏だ(open source is agile)GitHub and docker
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e
4 HAZOP
HAZOPは、想定外を洗い出すための手法で、プログラミングと親和性の高い手法です。HAZOPで分析すれば、想定外の検出方法をプログラミングしやすいという利点があります。
大小・類部は空間、早遅・前後は時間、
大小・早遅は量、類部・前後は質
大早類前は上限、小遅部後は下限
と８個の概念で、空間と時間の質と量の上限と下限を確認することになる。
大・小、類・部、早・遅、前・後はそれぞれ対称。
無は設計・利用の意図と存在において対称、
逆は方向が対称。
対称ではないのはその他だけ。つまり、世界を三次元および存在と方向において対称な概念を確認する。
想定外の調べかたは簡単。
無は調べた値がゼロかNull。
逆は、方向ベクトルにマイナスをつける。
大は＞
小は＜
類は集合演算。C言語で書くと工夫が要る。
部も集合演算。ただし、要素が一部であるかどうかを確認するだけで良い。
遅早は、時間の比較。前後は順番の比較。
工夫が要るのは、類と他である。これは、プログラムをしないで、類と他が発送しづらいこととも関係がある。この２つは無限の可能性がある。HAZOPは発散する可能性は、この２つの範囲を決められないことによる。
Hazop Safety and Security at Fukui 201
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-at-fukui-201712
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-at-fukui-201722
HAZOP, Safety and Security with records, SWEST at Gero Gifu pref. Japan
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-with-records-swest-at-gero-gifu-pref-japan
HAZOP, FMEA and FTA for risk assessment.
https://www.slideshare.net/kaizenjapan/hazopogawa2015
効率的なHAZOPの進め方
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446
5 ソースコード、図、英語以外は対象にしない
ソースコードと図は、相互に変換できる場合がある。先に、ソースコードを見た方が良いか、図から始めると良いかは、その問題の複雑度や、構造の把握ができて要るかどうかによる。
構造が把握できていない場合は、その構造を確認できるプログラムを書いて試験すると良い。プログラムを書かずに問題が解決したり、問題が解けるのなら、プログラムがそもそもいらない問題かもしれない。
英語(1) プログラマが知っているとよい英単語の語源
https://qiita.com/kaizen_nagoya/items/9de6d47c47e2c211222b
英語(2) まぎらわしい、間違えやすい、行き違いの多い略号worst 10(候補24)
https://qiita.com/kaizen_nagoya/items/0bff5dbb72208053489b
英語(3) 仮説・検証(88)用語の衝突(用語・用例募集中)
https://qiita.com/kaizen_nagoya/items/6a8eb7ffaa45eeb16624
英語(22) 物と事 変数名、関数名に役立つ英語・語幹・語源 30余
https://qiita.com/kaizen_nagoya/items/5f66b632ca589bb09707
6 見直し対象をソフトウェアで検査する
ソースコード、図、英語で書いたものは、ソフトウェアでまず検査する。検査しても見つからない課題だけ人間が考える。
よくソフトウェアで検査すれば５分でわかることを、何人もの人間が集まって１時間も２時間もかけて議論していることがある。検査するプログラムが書けない人たちなのだろうか。
ソースコードをbeautifier等の整形の道具で、タブやコメントの形式など揃えると良い。各自、自己流の書き方をしても、reviewの際は、この道具で検査し、この道具で整形するというやり方が定着していると良い。新しい言語の場合には、自分たちで道具を作る場合もある。
仮説・検証（163）生産縮小、規模縮小、人員縮小時には自動化道具を増強
https://qiita.com/kaizen_nagoya/items/8df1dc7d3a5c7869d3c2
#7 時間を区切る
会合は、30分、1時間に区切っている組織がある。その組織の人間の質、量、問題の質、量によって30分がいいか１時間がいいかが決まることがある。厄介な難事件は、３人の班に分けて、２時間かけて３回回すとよい場合もある。問題の複雑度、対応する人の能力、分布に応じて、仕立てる(tailoring)と良い。
４人以上が集まって、２時間以上かける会合なら、最初の１５分、HAZOPを実施すると良い。そこに集まった人の興味、能力、意志がわかり、無駄な説明を省くことができたことがある。
仮説・検証（122）分析と設計
https://qiita.com/kaizen_nagoya/items/d7341c407026af61f216
#参考文献(reference)
役に立つデザインレビュー―ソフトウェアにおける考え方と戦略 (実践ソフトウェア開発工学シリーズ),堀内純孝,日科技連出版社, 1992,ISBN 978-4817161093
https://www.amazon.co.jp/dp/4817161094
@e99h2121 育児していたからこそエンジニアのお仕事に役立ったこと10選
@e99h2121「女性こそエンジニアになるべきだ？」デブサミウーマン登壇記録
@kazuo_reve 新人の方によく展開している有益な情報
@kazuo_reve 私が効果を確認した「小川メソッド」
@torifukukaiou 私のAdvent Calendar 2022 ーー はじめたきっかけ、1月のふりかえり、今後の展望
自己参照(self reference)
プログラマの「日報、週報、月報、年報」考。仮説(73)
権利と義務の前に。仮説（147）
国際規格のNormative Reference
凡人網(ordinary person network: Bonjin mou)をつくる
与件解析(data analysis)入門
プログラマにも読んでほしい「QC検定にも役立つ！QCべからず集」
文書履歴(document history)
ver. 1 https://researchmap.jp/jofizy29u-50024/#_50024
https://researchmap.jp/blogs/blog_entries/view/78772/890e709d32ee2cc42858475b38bfcb09 2018/01/17
ver. 2 Qiita 初稿20180117
ver. 2.1 上位７改定 20180228
ver. 2.2 表現補正・参考資料追記 20200301
ver. 2.3 表現補正・参考資料追記 20220220
ver. 2.31 ありがとう追記 20230513
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.