算譜(program)は、一人で書いていると思い込みや、勘違いでとんでもない穴が生じていることがある。静的検査、動的検査、証明などの道具を用いても、思い込みや勘違いのうち、根本的なところは抜けていることがある。
目的(purpose):
20180228 小寺浩司さんの助言に基づき追記く
一人で仕事をしていると、うまく行っているか不安になってストレスが溜まってくる。その溜まったストレスを、先輩や専門家、あるいは新人の純粋な目で見ると、なんだそこを直せばスッキリするんだと、ストレスを解消させることがReviewの目的です。
成果(outcome):
20180228 小寺浩司さんの助言に基づき追記
ストレスが解消するため、担当者のやる気が倍増し、作業効率が良くなる。
ソフトウェアの見直しに必要な志向、技能、技法、手順を考え、それらに優先順位をつけて上位7つを記載する。
p.s.
ソフトウェア設計・開発で、仕様書、設計書を日本語で書いている人たちがいるらしい。また、それらの文書の見直し(review)で、わいがや、顔見せ、憂さ晴らし、息抜きをしている人たちがいるらしい。
1 関係する技術について技能・経験のある人に参加してもらう
これが一番大事。どの技術については誰の意見をもらわないと駄目みたいな習慣があればよい。組織内に誰もいなければ、組織外からの参加を要請できる習慣も大事。
よく見落としがちなのが材料。新しい材料を使っていれば、重さ、硬さ、動作、防水・防塵・耐熱、耐用年数など違うことがいっぱいあるのに、何のパラメータを変えれば充分かの専門的な知見、試験結果の評価ができていないと、大きな失敗をするかもしれない。
仮説(73)プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69
2 問題解決の意志
問題を解決するソフトウェアを設計・開発する場合に、必要となるのは、問題を解決するためのプログラムを書く人の強い意志(やる気)が大事。問題を解決するつもりがない人の説明を何時間聞いても無駄。解決したい問題の大きさと、その解決するための意志があれば、オンラインで内容を検討したり、集まって検討会をするのは無駄。
問題を解決する意志がない人がいても、集まって、わいがややって、なんとか組織として解決したいという管理者の方がいるのかもしれません。確かに、時間とお金があれば、わいがやの中から、解決策が生まれる可能性はあるでしょう。
最悪なのは、問題を解決する意思がなく、見直しの方法や手段、情報を伝達する意思があるかどうかを問題にする人。問題を解決する意思のない人に、情報を伝達しても、足を引っ張るだけで協力しない人になぜ情報を伝達する必要があるのだろう。
報連相がうまくいかない場合があるのは、報告しても、連絡しても、相談しても、足を引っ張る人がいれば台無しだということを自覚されているのだろうか。
仮説(40)報連相 再考
https://qiita.com/kaizen_nagoya/items/013f2779bd2beba720b7
3 ソースコードまたは図で評価
どんな難問題も、大規模案件も、その問題の核心を解決する論理は簡単かもしれません。逆に、難問題であればあるほど、大規模案件であればあるほど、核心を解決する論理が単純でなければ、プログラムの構造(architecture)が複雑になり、試験・検証が膨大になり、莫大な経費がかかるかもしれません。
最初の段階で確信の問題を解決するプログラムを書いてみて、そのソースコードを評価する集まりを開いておけば、大規模・長期的・大人数の設計・開発でも、問題を解決する意志を集中させることができるかもしれない。
問題を解決するには、ソースコードばかりでなく、状態遷移図、時系列図、刻時図、利用事例図などUMLで定義している振る舞い図が適しているかもしれない。これらの振る舞い図は、容易にソースコードに変換できるあるいは、仕様記述から生成できるかもしれないため、図から入るのが正解な案件は多数ある。
UMLではなくSYSMLを使えばよい場合もあったり、DSL(Domain Specification Language)で書いた方がいい場合もある。ソースコードではなく仕様記述言語で書いて、ソースコードを生成する場合もある。どの段階で、どの仕様を見直すとよいかのよい習慣を生み出そう。
実物による実演、動画、写真で良い場合もあるし、模擬試験を行っても良い。
ソースコードに全体の構造、動作の説明が書いてあるか、リンクしていないソースコードは読みません。
図を使って分析・設計すればこんなに簡単。安全(11), 図(11) https://qiita.com/kaizen_nagoya/items/6347eb55b2812d745549
設計 図(12) 表はいつ(when)書く、何を(what)書く、どうやって(how)書く。 仮説(71) https://qiita.com/kaizen_nagoya/items/7fddfa5d8bfb5a947db8
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で分析すれば、想定外の検出方法をプログラミングしやすいという利点があります。
大小・類部は空間、早遅・前後は時間、
大小・早遅は量、類部・前後は質
大早類前は上限、小遅部後は下限
と8個の概念で、空間と時間の質と量の上限と下限を確認することになる。
大・小、類・部、早・遅、前・後はそれぞれ対称。
無は設計・利用の意図と存在において対称、
逆は方向が対称。
対称ではないのはその他だけ。つまり、世界を三次元および存在と方向において対称な概念を確認する。
想定外の調べかたは簡単。
無は調べた値がゼロかNull。
逆は、方向ベクトルにマイナスをつける。
大は>
小は<
類は集合演算。C言語で書くと工夫が要る。
部も集合演算。ただし、要素が一部であるかどうかを確認するだけで良い。
遅早は、時間の比較。前後は順番の比較。
工夫が要るのは、類と他である。これは、プログラムをしないで、類と他が発送しづらいこととも関係がある。この2つは無限の可能性がある。HAZOPは発散する可能性は、この2つの範囲を決められないことによる。
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 見直し対象をソフトウェアで検査する
ソースコード、図、英語で書いたものは、ソフトウェアでまず検査する。検査しても見つからない課題だけ人間が考える。
よくソフトウェアで検査すれば5分でわかることを、何人もの人間が集まって1時間も2時間もかけて議論していることがある。検査するプログラムが書けない人たちなのだろうか。
ソースコードをbeautifier等の整形の道具で、タブやコメントの形式など揃えると良い。各自、自己流の書き方をしても、reviewの際は、この道具で検査し、この道具で整形するというやり方が定着していると良い。新しい言語の場合には、自分たちで道具を作る場合もある。
仮説(163)生産縮小、規模縮小、人員縮小時には自動化道具を増強
https://qiita.com/kaizen_nagoya/items/8df1dc7d3a5c7869d3c2
7 時間を区切る
会合は、30分、1時間に区切っている組織がある。その組織の人間の質、量、問題の質、量によって30分がいいか1時間がいいかが決まることがある。厄介な難事件は、3人の班に分けて、2時間かけて3回回すとよい場合もある。問題の複雑度、対応する人の能力、分布に応じて、仕立てる(tailoring)と良い。
4人以上が集まって、2時間以上かける会合なら、最初の15分、HAZOPを実施すると良い。そこに集まった人の興味、能力、意志がわかり、無駄な説明を省くことができたことがある。
仮説(122)分析と設計
https://qiita.com/kaizen_nagoya/items/d7341c407026af61f216
参考文献(reference)
役に立つデザインレビュー―ソフトウェアにおける考え方と戦略 (実践ソフトウェア開発工学シリーズ),堀内純孝,日科技連出版社, 1992,ISBN 978-4817161093
https://www.amazon.co.jp/dp/4817161094
@e99h2121 育児していたからこそエンジニアのお仕事に役立ったこと10選
https://qiita.com/e99h2121/items/db7e54c111ffcd3c3957
@e99h2121「女性こそエンジニアになるべきだ?」デブサミウーマン登壇記録
https://qiita.com/e99h2121/items/7c69be1b2c2f305f6a4c
@kazuo_reve 新人の方によく展開している有益な情報
https://qiita.com/kazuo_reve/items/d1a3f0ee48e24bba38f1
@kazuo_reve 私が効果を確認した「小川メソッド」
https://qiita.com/kazuo_reve/items/a3ea1d9171deeccc04da
@torifukukaiou 私のAdvent Calendar 2022 ーー はじめたきっかけ、1月のふりかえり、今後の展望
https://qiita.com/torifukukaiou/items/891db4e40a7f6194af56
自己参照(self reference)
プログラマの「日報、週報、月報、年報」考。仮説(73)
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69
権利と義務の前に。仮説(147)
https://qiita.com/kaizen_nagoya/items/47d4e992d0fd340403fd
国際規格のNormative Reference
https://qiita.com/kaizen_nagoya/items/b94b6055997119ac2d9a
凡人網(ordinary person network: Bonjin mou)をつくる
https://qiita.com/kaizen_nagoya/items/c8e2af61f344761c41be
与件解析(data analysis)入門
https://qiita.com/kaizen_nagoya/items/d9474c3bdb8ea0029bee
プログラマにも読んでほしい「QC検定にも役立つ!QCべからず集」
https://qiita.com/kaizen_nagoya/items/d8ada7b7fceafe2e5f0e
関連資料
' @kazuo_reve 私が効果を確認した「小川メソッド」
https://qiita.com/kazuo_reve/items/a3ea1d9171deeccc04da
' @kazuo_reve 新人の方によく展開している有益な情報
https://qiita.com/kazuo_reve/items/d1a3f0ee48e24bba38f1
' @kazuo_reve Vモデルについて勘違いしていたと思ったこと
https://qiita.com/kazuo_reve/items/46fddb094563bd9b2e1e
自己記事一覧
プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945
逆も真:社会人が最初に確かめるとよいこと。OSEK(69)、Ethernet(59)
https://qiita.com/kaizen_nagoya/items/39afe4a728a31b903ddc
「何を」よりも「誰を」。10年後のために今見習いたい人たち
https://qiita.com/kaizen_nagoya/items/8045978b16eb49d572b2
Qiitaの記事に3段階または5段階で到達するための方法
https://qiita.com/kaizen_nagoya/items/6e9298296852325adc5e
物理記事 上位100
https://qiita.com/kaizen_nagoya/items/66e90fe31fbe3facc6ff
量子(0) 計算機, 量子力学
https://qiita.com/kaizen_nagoya/items/1cd954cb0eed92879fd4
数学関連記事100
https://qiita.com/kaizen_nagoya/items/d8dadb49a6397e854c6d
統計(0)一覧
https://qiita.com/kaizen_nagoya/items/80d3b221807e53e88aba
図(0) state, sequence and timing. UML and お絵描き
https://qiita.com/kaizen_nagoya/items/60440a882146aeee9e8f
品質一覧
https://qiita.com/kaizen_nagoya/items/2b99b8e9db6d94b2e971
言語・文学記事 100
https://qiita.com/kaizen_nagoya/items/42d58d5ef7fb53c407d6
医工連携関連記事一覧
https://qiita.com/kaizen_nagoya/items/6ab51c12ba51bc260a82
自動車 記事 100
https://qiita.com/kaizen_nagoya/items/f7f0b9ab36569ad409c5
通信記事100
https://qiita.com/kaizen_nagoya/items/1d67de5e1cd207b05ef7
日本語(0)一欄
https://qiita.com/kaizen_nagoya/items/7498dcfa3a9ba7fd1e68
英語(0) 一覧
https://qiita.com/kaizen_nagoya/items/680e3f5cbf9430486c7d
転職(0)一覧
https://qiita.com/kaizen_nagoya/items/f77520d378d33451d6fe
仮説(0)一覧(目標100現在40)
https://qiita.com/kaizen_nagoya/items/f000506fe1837b3590df
音楽 一覧(0)
https://qiita.com/kaizen_nagoya/items/b6e5f42bbfe3bbe40f5d
「@kazuo_reve 新人の方によく展開している有益な情報」確認一覧
https://qiita.com/kaizen_nagoya/items/b9380888d1e5a042646b
Qiita(0)Qiita関連記事一覧(自分)
https://qiita.com/kaizen_nagoya/items/58db5fbf036b28e9dfa6
鉄道(0)鉄道のシステム考察はてっちゃんがてつだってくれる
https://qiita.com/kaizen_nagoya/items/26bda595f341a27901a0
安全(0)安全工学シンポジウムに向けて: 21
https://qiita.com/kaizen_nagoya/items/c5d78f3def8195cb2409
一覧の一覧( The directory of directories of mine.) Qiita(100)
https://qiita.com/kaizen_nagoya/items/7eb0e006543886138f39
Ethernet 記事一覧 Ethernet(0)
https://qiita.com/kaizen_nagoya/items/88d35e99f74aefc98794
Wireshark 一覧 wireshark(0)、Ethernet(48)
https://qiita.com/kaizen_nagoya/items/fbed841f61875c4731d0
線網(Wi-Fi)空中線(antenna)(0) 記事一覧(118/300目標)
https://qiita.com/kaizen_nagoya/items/5e5464ac2b24bd4cd001
OSEK OS設計の基礎 OSEK(100)
https://qiita.com/kaizen_nagoya/items/7528a22a14242d2d58a3
Error一覧 error(0)
https://qiita.com/kaizen_nagoya/items/48b6cbc8d68eae2c42b8
++ Support(0)
https://qiita.com/kaizen_nagoya/items/8720d26f762369a80514
Coding(0) Rules, C, Secure, MISRA and so on
https://qiita.com/kaizen_nagoya/items/400725644a8a0e90fbb0
coding (101) 一覧を作成し始めた。omake:最近のQiitaで表示しない5つの事象
https://qiita.com/kaizen_nagoya/items/20667f09f19598aedb68
プログラマによる、プログラマのための、統計(0)と確率のプログラミングとその後
https://qiita.com/kaizen_nagoya/items/6e9897eb641268766909
なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2
言語処理100本ノックをdockerで。python覚えるのに最適。:10+12
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4
プログラムちょい替え(0)一覧:4件
https://qiita.com/kaizen_nagoya/items/296d87ef4bfd516bc394
Python(0)記事をまとめたい。
https://qiita.com/kaizen_nagoya/items/088c57d70ab6904ebb53
官公庁・学校・公的団体(NPOを含む)システムの課題、官(0)
https://qiita.com/kaizen_nagoya/items/04ee6eaf7ec13d3af4c3
「はじめての」シリーズ ベクタージャパン
https://qiita.com/kaizen_nagoya/items/2e41634f6e21a3cf74eb
AUTOSAR(0)Qiita記事一覧, OSEK(75)
https://qiita.com/kaizen_nagoya/items/89c07961b59a8754c869
プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945
LaTeX(0) 一覧
https://qiita.com/kaizen_nagoya/items/e3f7dafacab58c499792
自動制御、制御工学一覧(0)
https://qiita.com/kaizen_nagoya/items/7767a4e19a6ae1479e6b
Rust(0) 一覧
https://qiita.com/kaizen_nagoya/items/5e8bb080ba6ca0281927
100以上いいねをいただいた記事16選
https://qiita.com/kaizen_nagoya/items/f8d958d9084ffbd15d2a
小川清最終講義、最終講義(再)計画, Ethernet(100) 英語(100) 安全(100)
https://qiita.com/kaizen_nagoya/items/e2df642e3951e35e6a53
<この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。>
This article is an individual impression based on the individual's experience. It has nothing to do with the organization or business to which I currently belong.
文書履歴(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 上位7改定 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.