職業訓練
https://qiita.com/kaizen_nagoya/items/95368b63fa21d64271ec
Programmer, Day 14
https://qiita.com/kaizen_nagoya/items/a6bca7f86a0348264adf
C言語(C++)が必要な人と必要ない人
https://qiita.com/kaizen_nagoya/items/2afe9e846b55b24cb6f1
C言語を習得する３つの方法
https://qiita.com/kaizen_nagoya/items/84cab0888c193bba429b
Programmer, Day 16
MCP入門 〜面倒なことはAIエージェントにやらせよう〜 を聞きながら
https://qiita.com/kaizen_nagoya/items/54b648c838fae8d57e38
職業訓練（IT) オープンソースとユーザビリティ教育。構造化とUMLを使って。
https://qiita.com/kaizen_nagoya/items/c41988c2f8ce1b61a08a
名古屋Reject会議 ふたたび
https://qiita.com/kaizen_nagoya/items/d35d2de4a35abb797126
Qiita Tech Festa 2025 自己記事一覧
https://qiita.com/kaizen_nagoya/items/83f7b7d9609d6789dc3a
<この項は書きかけです。順次追記します。>
This article is not completed. I will add some words and/or centences in order.
Este artículo no está completo. Agregaré algunas palabras en orden.
MISRA C
MISRA C まとめ #include
https://qiita.com/kaizen_nagoya/items/f1a79a7cbd281607c7c9
Misra Example Suite at docker コンパイル完了までの道のり。docker(154) error(56)
https://qiita.com/kaizen_nagoya/items/71f04a0204d5a1114577
一つづつMISRAが作成した直したソースは別に解説します。
docker(201) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(1) D_04_03.c
https://qiita.com/kaizen_nagoya/items/780be9109348340e20e0
docker(202) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(2) R_02_02.c
https://qiita.com/kaizen_nagoya/items/496869b87dd3d29cea8b
docker(203) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(3) R_05_03.c
https://qiita.com/kaizen_nagoya/items/cb0d1da183f4f1e9e59d
docker(204) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(4) R_07_04.c
https://qiita.com/kaizen_nagoya/items/73b9f16638273a74d807
docker(205) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(5) R_08_04.c
https://qiita.com/kaizen_nagoya/items/c753db14cc95a9303fa5
docker(206) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(6) R_09_0x.c
https://qiita.com/kaizen_nagoya/items/8ad38c8728440688255c
docker(207) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(7) R_10_0x.c
https://qiita.com/kaizen_nagoya/items/05dd6f6c14aeafbe3e71
docker(208) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(8) R_11_0x.c
https://qiita.com/kaizen_nagoya/items/9962647a1b510825fa6e
docker(209) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(9) R_13_0x.c
https://qiita.com/kaizen_nagoya/items/dcd2de1267e3c3449536
docker(210) gcc(gnu), clang(llvm)コンパイルエラー・警告比較(10) R_14_0x.c
https://qiita.com/kaizen_nagoya/items/772f49486e7cca1dbeb9
gcc(gnu), clang(llvm)コンパイルエラー・警告比較(12) R_17_03.c, docker(165) error(50) https://qiita.com/kaizen_nagoya/items/f85e29050b99ea1c2538
Day 15
構造化
program はじめてのC/C++ 構造化プログラミング
https://qiita.com/kaizen_nagoya/items/918148868c2afc1810d4
p.198
その他＝＞時間
verification 検証
valiadtion 妥当性確認
SOTIF
システムが「どのように動くのか」という視点は分析段階では考えない
どのように動いているかが、何の本質。 －＞プラズマ、流体力学。
p.202
1 機能要求は「ユーザにとって意味があること」から抽出する
SOTIF ISO 21448:2022
Road vehicles — Safety of the intended functionality
https://www.iso.org/standard/77490.html
2 言語化されないイベントを探す（暗黙的な要求の発見）
状態遷移図、刻時図、時系列図を描くのも言語化していない行事を図示しちゃう
3 イベントリストにはエフェクト（結果）も含めよう
event = 入力なら、出力= effet
4 非機能要求は分離して管理する
5 要求のタイミングを把握してリアルタイム性を確保する
状態遷移図、刻時図、時系列図を描くのリアルタイム性を設計する方法の一つ。
6 用語の意味合いを統一して情報共有する
用語を定義しても、意味は視点によって真逆になる可能性がある。
統一するというよりは、相互に相手の視点では意味が違うことを確認することが大事。
すべてのソースコードを含む情報を共有していれば、意味が違っても、最終的なソースコードは一つ。ただし、目的ごとに、枝分かれした製品を出荷することはある。
7 人の認知の限界を意識して「7±2単位」に分割する
認知の限界は、人間だけではなく、生物に広げて把握するとモデル化が容易かも。
8 制御フローは「最後の手段」：構造化された機能設計を優先する
構造化設計の道具として、状態遷移図、刻時図、時系列図を描き、制御フローは書かないかも。
9 入力が多い場合はディシジョンテーブルを使う
表形式はぬけもれを減らす手段
10 状態遷移図などで状態やモードの整理をする
表形式はぬけもれを減らす手段
11 「WHY」で目的を見極めることで「HOW」への過剰なフォーカスを避ける
なぜかは、なぜなぜ分析だけでなく、FTA, FMEA, HAZOPなどの手法も使い、１１次元程度を考察するといいかも。
12 分析デモは「良い加減なレベル」で止める
バランス。
良い加減：自分のためのprogramを書いてみて、妥当性確認。必要な投入時間と実現している機能のバランス。
13 モジュールは「単一の責務（機能）」を持つようにする
ＵＮＩＸ、Ｃ言語の精神、Ｃ言語の原則が身についていれば大丈夫。
14 詳細設計では外部インターフェースをカプセル化する
カプセル化するだけでなく、データ中心設計、アルゴリズム、時間測定が大事。
人間工学の観点（格言7）「7±2の単位に分割」など、認知心理学の知見をシステム設計に応用している。
一歩踏み外して、猫中心設計、鳥中心設計も、、、
猫中心設計
https://qiita.com/kaizen_nagoya/items/d409c1185df30f660adc
猫中心設計から鳥中心設計へ
https://qiita.com/kaizen_nagoya/items/e1fef758607c14c00abf
WHY志向の分析（格言11）技術者が陥りがちな「HOWに偏る設計」を防ぐためのアプローチが明確に言語化されていて、非常に実践的。
リアルタイム性や非同期イベントの扱い（格言2、5）組込み系やリアルタイムシステムに通じる考え方が多く、応用範囲の広さがうかがえる。
分析デモの深さについての判断（格言12）どこまでやれば「ちょうど良い」かを言語化しているのは貴重です。これは新人教育やプロジェクトマネジメントにも役立つと思う。
P.206
バランスの良いシステム形状を作ろう
エンジニアのやる気が大事。給料、製品の品質とバランスしているか。
手戻りと洗練化の違いを意識しよう
アーキテクトしか評価できないかも。
何が手戻りで、何が洗練化なのかは最初に決まっているわけじゃない。
技術者はいろいろやってみて考えればいい。
設計と実装を同期させよう
図からソースコードを自動生成したり、
ソースコードから図または仕様書を自動生成すれば自動で同期する。
レビューで品質改善活動を可視化しよう
必要な能力のある人を集めないと、単なるお見合いになっていたり、
打合せ会合になっていることを見かけるかも。
能力のある人が、能力のある手法と、能力のある道具を使えば、手戻りを防げる可能性は大かも。
見直しは、企画時点、見積もり時点で簡便な設計をしながら、分析、レビューをするとよい。
設計の最終段階に入ってからの見直しはありえない。
可視化の方向性は、アーキテクトが決めないと意味がないかも。
欠陥の混入から検出までの遅延時間を最短にしよう
Github, Gitlab, Bitbucket などのgit, markdown, dockerなどの仮想環境対応システムで同時並行試験を自動化する時間を最短時間としよう。
DevOps <- Software defined audio, software defined radio, software defined network(ing), software defined vehicle.
原因分析して再発防止に努めよう
誰が、どういう分析をすれば、再発防止ができるかが大事。
FMEA, FTA, HAZOPなどの手法を利用し、
空間と時間の質と量、上限と下限の８事象は確認し、最低で１１次元空間で分析し、再発防止を自動化できるとよいかも。
レビュー1時間、テスト・バグ解析・修正・再検証8時間
必要な能力のある人を集めないと、単なるお見合いになっていたり、
打合せ会合になっていることを見かけるかも。
能力のある人が、能力のある手法と、能力のある道具を使えば、手戻りを防げる可能性は大かも。
欠陥と原因だけではなく、良いところも横展開しよう
作業の仕方よりも、情報交換の仕組みができていることの方が大事かも。
作業の仕方を定義するよりも、情報交換の仕組みをうまく組み合わせよう。
github, gitlab, bitbucketを情報交換の仕組みの中核に位置づけよう。
クラウド上で開発と運用を同時にして、並列処理を実行するのに、ハードウェアの購入手続きをせずに実現する。
P.214
デジジョンテーブル
例：p.102
YとNの発生確率（ある条件下での使用の場合）を書くようにお願いする。
上に優先順位の高いもの、下にいくにつれて低いものを並べる。
同じグループに属するものは、隣接して書く場合がある。 社会科学的視点
同じ処理で扱えるものを並べることはある。 プログラマ視点
社会科学系だとあたりまえに書く。
制御系でも、入力の種類が多い場合には、書く。表形式は、抜け漏れを減らすことができる。
P102 すべてが２値ならば、表５．１６のようにブール式で表すこともできます。
すべてが３値の場合でも、テーブルは有用。
論理回路は、YとNとunkownの３値を想定している。
表のdon't careは、Unkownでもいいことを示している。
P214
event, イベント, 行事
event driven
event 無視
event list
guideline on making event list
process on making event list
finalize on event list
notation on event list
making an event list
review an event list
inspection
inspection report
inspection improvement
brief inspection
output on inspection
process on inspection
input on inspection
specification on interface
walkthrough
effect
起こりえない
off sheat
on sheat
hierarchy 階層 level, class, architecture
・Hierarchical structure 階層構造
scope on developing system
issue log
coupling level
couple
How to use 活用方法
capsule
matured technology, legacy technology 枯れた技術
function pointer table
point of view
completed
functional specification
functional cohelence
function division
functional requirement
covalent bond 共有結合
Localization 局所化
偶発的コヒージョン
組み合わせコントロール
embedded software
main domain on embedded software
feature on emebdded software
cloneing
defect 欠陥
coupling 結合度
decision table
result on cause analysis
structuring method 構造化手法