未分類

次女の大学の卒業式に出席してきました。

I attended my younger daughter's university graduation ceremony.

中学の入学式以来、約10年ぶりに娘の学校行事に出席することになりました。これが娘に関わる最後のイベントとなるため、きっちり年休を取得して臨みました。

It was the first time in ten years that I participated in one of her school events—since her junior high school entrance ceremony, to be exact. Since this would be the final event in her student life, I took a day off from work to be there.

卒業生は約3000人。保護者は大学内の別教室(10教室以上が開放されていた)に分かれ、リモートで式を視聴する形式でした。複数のカメラ映像が指令室の判断でスムーズに切り替わり、セリフも字幕で表示されるなど、そのシステム運用の効率の良さには感心しました。

With nearly 3,000 graduates, parents were directed to remote classrooms (more than ten open rooms) to watch the ceremony via livestream. The video feed was smoothly directed from a control room with multiple camera angles, included speech subtitles, and operated effectively. I was genuinely impressed by how well the system was run.

ですが、

However,

―― 学長、主賓、OB代表らによるスピーチの内容が、実に退屈だった

"The speeches by the university president, the guest of honor, and the alumni representative were disappointingly dull."

私は今回の卒業式で、なにか“ネタ”になるような話を拾えるかと期待していたので、正直ガッカリしました。

I had hoped to pick up a good story from the ceremony, so I was honestly disappointed.

もしかすると、この大学には「退屈なスピーチをする」という“伝統的な様式美”のようなものがあるのだろうか?と思い、娘に尋ねてみたところ、「そんな話は聞いたことがない」と一蹴されました。

I even wondered if this university had a “traditional aesthetic” that required speakers to give deliberately dull speeches. But when I asked my daughter, she said she'd never heard of such a thing.

もちろん、以下のような名スピーチ級を求めているわけではありません。とはいえ、それに“追いつこうとする努力”くらいは見せてもらいたいものです。

Of course, I wasn’t expecting anything on the level of this famous speech. Still, I would have liked to see at least some effort to reach that level.

卒業生も保護者も、公の場で他の人のスピーチを批判することは難しいです(私も、誰かを特定するような記述は避けている)。とはいえ、せっかく人前で話すのであれば、「あの人のスピーチは覚えている」と言ってもらえるくらいのインパクトは残してほしいものです。

For graduates and their families, it’s hard to criticize these kinds of speakers in public openly (and I’ve made sure not to write anything that would identify anyone specifically). That said, if you’re going to give a speech at a major event like an entrance or graduation ceremony, I’d like you to deliver something memorable that makes people say, “I remember that speech.”

この私が、年度末の多忙な時期に、まる一日年休を使って出席したのですから、「出席して良かった」と思えるくらいの内容は期待していました。

I attended this event on an entire day off during a hectic end-of-fiscal-year period, so I expected content that would at least make me feel it was worth it.

ですので、正直に言えば、がっかりしたという気持ちを抑えきれません。

Honestly, I was disappointed.

-----

まあ、我が国の「偉い人」のスピーチについては、これまでも述べてきた通りです。

As I’ve mentioned, the speeches of Japan’s so-called “important people” have often left much to be desired.

今後も期待できないかもしれませんが。

I doubt that will change any time soon.

―― 私には、書きたいこと/言いたいことが沢山あるからです

未分類

旧統一教会に対する解散請求に対して、東京地裁が請求を認める判決をしました。これに対して、旧統一教会は「誤った法解釈による命令である」との抗弁をしています。旧統一教会の主張を簡潔に纒めて下さい。

旧統一教会(世界平和統一家庭連合)は、東京地裁の解散命令について、以下のように主張しています:

  • 判決は宗教法人法の「法令に違反する著しい行為」の解釈を誤っており、信教の自由を侵害するものだ。

  • 信者による不適切な勧誘や献金があったとしても、法人全体としての責任や組織的関与は認められない。

  • 解散命令は信教の自由に対する不当な介入であり、違憲の可能性がある。

このように旧統一教会は、判決の法解釈に誤りがあると主張し、組織的な違法性を否定しています。

この旧統一教会の抗弁に対する、裁判所の判断根拠を一覧表にして記述して下さい


■ 旧統一教会の抗弁と東京地裁の判断対照表

旧統一教会の抗弁内容 裁判所の判断根拠・反論
1. 法令違反に該当しない。組織的関与はない。 長期間にわたって全国規模で多数の信者が同様の手法(霊感商法、献金強要等)を用いていた事実を認定。これらは法人の統制のもとで行われたと判断。
2. 信者個人の行為であり、法人としての違法性はない。 個人の行為としては説明できない統一的な行動パターンやマニュアル、指導体制の存在を証拠として認定。法人としての「組織的違法性」があると判断。
3. 信教の自由の侵害であり違憲の可能性がある。 解散命令は「信教の自由」自体を否定するものではなく、社会秩序を守るための必要かつ合理的な制限であり、憲法の枠内で適法と判断。
4. 被害の評価が恣意的・一部事例に偏っている。 被害は長期かつ多数にわたり、経済的・精神的に深刻な影響があったと認定。特定の事例に限らず、多数の供述・証拠から総体として判断。
5. 改善の取り組み(ガイドライン整備など)を行ってきた。 形式的な改善策であり、実効性が不十分。ガイドライン後も被害が続いている事例が確認されており、抜本的な改善と認められない。
6. 政治的圧力が背景にある。手続きが公平でない。 本件の判断は、収集された多数の証拠と証言、法的評価に基づくものであり、外部の政治的影響や世論とは無関係に、司法として独立して行われたと明言。

東京地裁は、違法行為の反復・継続性、組織的関与の有無、被害の深刻性などから、宗教法人法第81条1号の要件(「法令に違反する著しい行為」)を満たすと認定し、解散命令を相当としました。

未分類

なるほど、なるほど、 ―― 「侍タイムスリッパー」を見た感想です。

Amazon Primeに、昨日から来ているのを見ました。

多分、ここから始まる地獄の半年の最後の休憩時間と考えて、部屋の暗くして、嫁さんと二人でリビングのテレビでソファーで観賞しました。

-----

今、宣伝用のページを見ているのですけど、『ああ、ここには書かれていないんだ』と分かりました。

私の記憶している限り、2回、驚かされるストーリー展開(転換)があります(ネタバレになるので書きませんが)。

自信をもって、お勧めできる映画です。

少なくとも、単なる「笑い」の映画ではなく、私には、本当に、真剣に、真面目に、『良い映画』でした。

未分類

「その着せ替え人形は恋をする」を読了して、コスプレという文化と技術とコスプレに傾倒する人たちの熱意とかを知ることができました。このようにコミックによって、サブカルそのものを理解できなくても、サブカルを『分かったような気にはなれる』と思いました。
サブカルに限らず、このような表現文化に関するマンガ、その他のメディアについて、ピックアックして頂き、その文化と技術と傾倒する人たちの熱意について、一覧で纒めて頂きたいです。

承知しました。以下に、先ほどの表現文化系に加えて「スポーツ」を描いたマンガを含めた一覧をアップデートしました。野球・サッカーはそれぞれ1作品のみに絞り、あまり知られていない競技(相撲・アーチェリー・スケートなど)を中心にピックアップしています。


表現文化・スポーツを描いたマンガ・メディア一覧

(文化・技術・情熱に注目)

作品名 扱っている文化/競技 技術的要素 登場人物たちの熱意・姿勢
その着せ替え人形は恋をする コスプレ、衣装制作 裁縫、メイク、造形、ウィッグ 創作を通じた自分らしさの追求と他者尊重
アクタージュ act-age 演技、舞台・映画 感情表現、演技法、舞台理解 自己内面と演技を繋げる研ぎ澄まされた集中
映像研には手を出すな! アニメ制作 絵コンテ、演出設計、世界観構築 想像力を具現化することへの純粋な渇望
重版出来! 出版・編集 取材、企画力、マンガ制作進行 マンガという文化を世に届ける使命感
げんしけん オタク文化全般 同人誌、イベント、考察 サブカルに対する深い知識と共有の喜び
バクマン。 マンガ制作 ネーム、作画、プロ意識 少年の夢を現実にするための試行錯誤と覚悟
ちはやふる 競技かるた 和歌暗記、反射、心理戦 伝統文化を「勝負」に昇華させる集中力
ランウェイで笑って モデル・服飾 ファッション構成、表現力 身体的ハードルを越える努力と夢への執念
ボールルームへようこそ 社交ダンス ステップ技術、ペアの呼吸、審査基準 表現と競技の融合を極める覚悟
火ノ丸相撲 相撲 組み手、体重コントロール、精神修行 小兵が巨漢に挑む意志と日本文化の継承
弓道士魂 弓玄(きゅうげん) 弓道 射法八節、集中、姿勢の美しさ 無心の精神と精度への執念
スピナマラダ! アイスホッケー スケート技術、パス、戦術 東北を舞台にした熱血かつ泥臭い成長劇
ノーコン・キッド 卓球 サーブ、ラリー、台上技術 地味な競技に魂を燃やす高校生たちの青春
BAMBOO BLADE 剣道 構え、打突、間合い チームとの絆と勝利への葛藤
あさひなぐ 薙刀 構え、打突、礼節 女子ならではの精神的・技術的成長物語
群青にサイレン 野球 バッテリー、心理戦 心の葛藤を抱えながらも頂点を目指す兄弟
DAYS サッカー ドリブル、連携、気持ち 才能よりも“努力”で這い上がる物語
銀盤カレイドスコープ フィギュアスケート ジャンプ、表現力、演技構成点 表現と技術の両立に悩む選手の成長譚
ツルモク独身寮 家具職人 木工加工、設計、美的センス 若者たちの手仕事への矜持と熱意(番外的だが技術職マンガとして)

ご覧のとおり、スポーツといっても「競技」だけでなく、「表現」や「精神性」が求められるものが多く、文化と地続きです。相撲や弓道、薙刀のような日本伝統の身体文化にも熱い想いが描かれています。

今回の私の質問の意図は、「サブカルであれマイナーなスポーツであれ、それを知ろうという行動を起こすことなく、批判しているヤツは『バカ』と断言して良い」、ということです。

未分類

VSCodeでC言語のインデントをGo言語のようにTABキーで自動的に整える方法を説明します。

1. C/C++拡張機能をインストール

まず、MicrosoftのC/C++拡張機能がインストールされているか確認してください。

  • VSCodeの「拡張機能」 (Ctrl+Shift+X) で「C/C++」を検索
  • ms-vscode.cpptools をインストール

2. settings.json を作成

.vscode フォルダの中に settings.json を作成します。

方法1: VSCodeのGUIを使う

  1. .vscode フォルダ内で 右クリック → 新しいファイル
  2. ファイル名を settings.json にする

3. settings.json に設定を追加

作成した settings.json を開いて、以下の内容を記述します。

{
  "editor.formatOnType": true,  // セミコロンや波括弧入力時に自動フォーマット
  "editor.formatOnSave": true,  // 保存時に自動フォーマット
  "editor.tabSize": 4,          // タブ幅を4に設定
  "editor.insertSpaces": false,  // タブをスペースに変換しない
  "C_Cpp.clang_format_fallbackStyle": "Google", 
  "C_Cpp.clang_format_style": "{ BasedOnStyle: Google, IndentWidth: 4, UseTab: Always }"
}

4. Emacsキーバインドを使いつつTABの動作を変更

Emacsのキーバインドを保持したままTABの動作だけ修正したい場合、keybindings.json でTABキーの挙動を変更できます。

設定方法

  1. Ctrl+Shift+P「Preferences: Open Keyboard Shortcuts (JSON)」 を検索
  2. keybindings.json を開く
  3. 以下の設定を追加:
    [
      {
        "key": "tab",
        "command": "editor.action.reindentlines",
        "when": "editorTextFocus"
      }
    ]
    
    

    これで、私の環境の方では何とか動いたようです。

[.vscode/c_cpp_properties.json]

{
	"configurations": [
		{
			"name": "Win32",
			"includePath": [
				"${workspaceFolder}/**",
				"C:/msys64/mingw64/include"
			],
			"defines": [
				"_DEBUG",
				"UNICODE",
				"_UNICODE"
			],
			"windowsSdkVersion": "10.0.22621.0",
			"compilerPath": "C:/msys64/mingw64/bin/gcc.exe",
			"cStandard": "c17",
			"cppStandard": "c++17",
			"intelliSenseMode": "windows-gcc-x64"
		}
	],
	"version": 4
}

[.vscode/launch.json]

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cデバッグ (MinGW64)",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "gdb を有効化",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe"
        }
    ]
}

[.vscode/settings.json]

{
	"editor.formatOnType": true, // セミコロンや波括弧入力時に自動フォーマット
	"editor.formatOnSave": true, // 保存時に自動フォーマット
	"editor.tabSize": 4, // タブ幅を4に設定
	"editor.insertSpaces": false, // タブをスペースに変換しない
	"C_Cpp.clang_format_fallbackStyle": "Google",
	"C_Cpp.clang_format_style": "{ BasedOnStyle: Google, IndentWidth: 4, UseTab: Always }"
}

[.vscode/tasks.json]

{
	"version": "2.0.0",
	"tasks": [
		{
			"label": "Cコンパイル (MinGW64)",
			"type": "shell",
			"command": "C:/msys64/mingw64/bin/gcc",
			"args": [
				"-g",
				"${file}",
				"-o",
				"${fileDirname}/${fileBasenameNoExtension}.exe"
			],
			"group": {
				"kind": "build",
				"isDefault": true
			},
			"problemMatcher": [
				"$gcc"
			],
			"detail": "MSYS2 MinGW64 の GCC を使用して C をコンパイル"
		}
	]
}

作成したCファイルをアクティブにし、Ctrl + Shift + B を押してビルドタスクを実行したあと、vscodeのデバッグができるようです。

未分類

SILって何だろう


本ページは、 SILに関するコラム(その1) と、 SILに関するコラム(その2) に対してのご批判と、その後のご指導を頂いた、 「真っ赤なレモン @_red_lemon 」さん から頂いたSILに関する有益なご意見を、 可能な限り変更を加えず、掲載したものです。

今回、このような形で、「真っ赤なレモン @_red_lemon 」さんのご意見を 掲載させて頂くに至ったのは、

 

  • 「真っ赤なレモン @_red_lemon 」さん のSILのご解説が、恐しく分かりやすいこと
  • SILに関する基本的な概念を説明する書籍が、現時点において絶無であること
  • 今後の製造業のグローバル対応を考えた時、このご解説の内容は、技術者の皆さんにとって、素晴しく役に立つであろうこと

という理由に因ります。

この度、「真っ赤なレモン @_red_lemon 」さん のご許諾を頂き、この文章を公開 させて頂くことにしました。

なお、本文に関する文責は、全て、この文章を編集した江端智一に帰するものと致します。

2012年11月11日(日) 江端智一

 


Q SILってなんですか?

 

A SILとは、機械の信頼性に関する指標で、平均故障間隔(MTBF:Mean Time Between Failures)という考え方を使います。

簡単に言うと、

「昨日クーラーが壊れたので、今修理してもらった。次はいつ故障しそう?」

「そうだねえ、大体5年後かなぁ」

と言えば、この場合のMTBFは、5年=43800時間 となります。

SILとは、このMTBFで、その装置やシステムの信頼性を示す指標です。ざっくりこんな感じです。

・SIL0:MTBFが10年未満

・SIL1:MTBFが10年以上~100年未満

・SIL2:MTBFが100年以上~1000年未満

・SIL3:MTBFが1000年以上~1万年未満

・SIL4:MTBFが1万年以上~10万年未満

まず、SIL0(シルゼロ)、SIL1(シルワン)、SIL2(シルツー)……という分け方をしているのは、昼定食を「人件費と材料費が1647円の定食」というのを、単に「梅定食」と呼んでいるのと同じことで、単にこうしたほうが、理解と管理がラクというだけのことです。

 

Q SIL1やSIL2というのは分かります。SIL3,SIL4などというものがあるのは何故 ですか。これは、巨大事故発生時の被害者数の期待値と考えれば良いのですか。

 

A SILは製品の期待値がSIL2になるようにするための道具だ、と言ってよいです。

江端さんがコラムで書いている、

>「SIL2の私(原発、電車、旅客機)は、あんたの人生において、1度だけは、あんたを殺すかもしれないよ」ということです。

も、

>つまり、「人を殺すことを前提とした安全」の概念が含まれていると考えれば、SILを理解できるわけです。

も、全くそのとおりです。大局としては間違っていません。

では、私が気になったのはどこか。次の部分です。

>SIL3(MTBF:1000年~1万年未満)やSIL4(MTBF:1万年~10万年)がなぜ必要なのだろう? という疑問が残ります。その答えは「期待値」です。

この考え方の筋道は、的外れです。

SIL3やSIL4が必要な理由は、次の考え方からです。

 


「壊れない」製品を作ることは、できない。(←ここはあきらめている)

そこはあきらめないと、話が先に進まない。

現実を見て物事を前に進められる我々工学の世界の住人は、 理屈にこだわって何もできない人たちよりも、ずっとマシ!

では、どれくらいの頻度の故障だったら、世間は納得してくれるだろうか?



まあ、製品のSILがSIL2だったら、世間は納得してくれるんじゃね?

受容されるんじゃね?

(これは、まさにALARA。納得できるかどうかを厳密に突き詰めることはできない。  人それぞれの価値観の相違があるため、泥沼になる)



それはともかく、最近は部品の集積度が上がった。

「部品の集積度が高い製品」ほど、壊れる確率は高くなっちゃうよね。 どの部品が壊れるか分からないし、製品を使って100年もかかる試験が できるわけないよね。



部品単体なら、加速試験ができるんじゃね?

それに、部品単体のMTBFをすごーく長くしておけば、 製品での試験をしなくてもいいじゃん!

「そ、それだ!」



部品単体のMTBFをどれくらいにすれば、製品の試験をしなくてすむんだろう?

自動車の部品が、約1万個。そのうち、壊れたら安全性に関わる部品は 100個くらい。この100個が壊れなければ安全性には問題ない。

他の部品が壊れても、保証修理でタダで修理すれば済む話だし。

とすると・・・この100個の部品をSIL4(MTBF:1万年~10万年)に できれば、自動車じたいは、ざっと計算してSIL2(MTBF:100年~1000年)だ!



というワケで、部品メーカーのみなさん。SIL4の部品を我が社に納入してください。



部品メーカー「ええ~~!」


どんどんグダグダになっていきましたが、これが真相です。

部品の段階でのSILをSIL4まで上げておくと、 ほとんどの製品(全部品が約1万個、そのうち安全に関わる部品が約100個の製品)で、 ほぼSIL2が達成できます。そのために、SIL4が必要。

安全に関わる部品がもっと少ない場合は、SIL3で足ります。

製品メーカーは、部品代に高いお金を払うかもしれませんが、ラクをします。

なお、SILをいう考え方を自動車業界が強く推進している背景には、 電子部品が自動車に多数使用されるようになった、ということがあります。

電子部品は、機械に比べて部品の集積度が非常に高い。

それまでは自動車の部品を「できるだけ細かいレベルに分けて」数えても、 1万個程度でしたが、電子部品が使われるようになった途端に2~3万個に増えました。 (抵抗1個でもバラして4個と数えるような、極端な数え方ですけれど。)

SILは、「部品の集積度が高い製品」を前提とした考え方から生まれています。

 

Q SILがあって嬉しいことって何ですか?

 

A リスクを抽出し(想定し)、その個々のリスクレベルを全て「社会的に受容できる程度まで低減する」ことです。

これはISOに規定されていることです。

ISOの制定は欧州が主導しており、欧州の考え方の根底には「モノは壊れる。 人は間違える」があります。だから、考え方は「故障をゼロにする」のではな く、「モノは壊れる。人は間違える。それで発生するリスクを含めて、受容で きるレベルまでリスクを低減する。受容できるレベルまで低減されたリスクは、 社会が受け入れるべき」となり、現実的に安全性を確保していこうとしていま す。

つまりは、「社会に受容してもらう」=「人々に納得してもらう。納得させる」 ことも、メーカーにとっては重要になります。

どうやって人々に納得してもらうか。

モノをベースに、客観的な理解を得ようとする取り組みが、SILのような考え 方を導入する動機の一部分としてあります。

通常のメーカーはそうやって、なんとかお客さまや社会に納得してもらえるよ うに努力をしています。

しかし、この考え方には弱点もありました。

例えば、原発の場合、モノを変えずに人を納得させようとしました。

「中長時間の全電源喪失を考えなくて良い理由を作文して下さい」などといった、 モノや実態を見ずに口先だけで人を納得させようとする姑息なやり口をしました。

そして、作文能力の高い人が多かったのでしょう。 優秀な作文がたくさんできたでしょう。

人々は納得させられてしまいました。モノは何も変わっていないのに。 [事故が発生する頻度]は非常に低いものの、ゼロではありません。 それを、ゼロだと思わせ、想定外ということにしました。

 

Q SILが基準としている「物差し」は何ですか。

 

A 人命です。

「SILで想定している『故障』とは、人命に関わるような故障のみを指している」 ということは、知っておかなければなりません。

極端に言うと、

「『安全に停止できるような故障』なら、1年に何回起こってもかまわない」

ということです。

(もちろん、お客さまからクレームが来ないようにしなければなりませんので、  『安全に停止できるような故障』も減らそうとはします。)

 

Q 「SIL4」と言葉で言うのは簡単ですが、1万年以上故障しない部品なんて、 一体、どうやって実現するのですか?

 

A 基本的には電子部品のSIL4などは部品の多重化で達成します。

大雑把に書くと

Aという部品をSIL4にするためには Aの機能を達成する部品を作ります。aとします。

aを試験すると、SIL2でした。

(aの試験は、実際に時間をかけたり、加速試験をしたり、様々な方法で調べます。) aを2個(a1とa2と呼ぶ)、論理的に並列に(or回路、でしたっけ?)組み合わせて、 部品Aとします。

Aはa1とa2の両方が壊れないかぎり正常に機能しますので、

SIL2 × SIL2 = (100年に1回) × (100年に1回) = (10000年に1回) = SIL4

です。 掛け算って素晴らしい。or回路って素晴らしい。

ただこれは、電子部品のような小さい部品だから多重化が可能なのです。

機械部品(歯車とか)では、こうはいきません。

ただしジレンマもあります。

SILには、故障検知という考え方が、どこまでもつきまといます。

SIL2の部品であっても、その部品が故障したことを検知でき、故障検知するこ とで「製品を安全に停止できる」手段があるのならば、「人命に関わるような 故障」には至らないとできます。

できますが、そのためには故障検知するための部品を追加しなければなりませ ん。

そして、故障検知する部品は、たいていはセンサー、電気部品です。

はて?部品の数は減らしたいのに、安全のために部品を増やすとは?では、そ のセンサーが故障したらどうなるのか?センサーの故障を検知するセンサーも 必要?じゃあ、センサーの故障を検知するセンサーが故障したらどうなる の?・・・以下、延々と続きます。

結果として、故障を検知するセンサー部品は、SIL4にせざるをえないことが多 いです。

センサーがSIL4であれば、[SIL4のセンサー]と[SIL2の部品]を論理的に直列に 組み合わせることで(and回路にすることで)、「製品を安全に停止できる」 道は切り開けます。

ただし、センサーという部品が増えるということ自体の解決にはなりません。

なお、どうしてもSIL4の部品を論理的に直列に10個組み合わせた部品を使わな ければならない場合もあり、その場合は組み合わせた部品のSILはSIL3に下がっ てしまいます。

([SIL4]+[SIL4]+・・・+[SIL4]=[SIL4]×10=[SIL3])

そういう事情を勘案した上で、「SIL4の部品を論理的に直列に10個組み合わせ た部品」にはSIL3を割り振ってあげるという措置も必要になってきます。

 

Q ソフトウェアSILというのが、まったくチンプンカンプンです。 「ソフトウェアが1万年故障しない」という概念を、どうやって導き出すので すか?

 

A 天が導き出します。

製品の場合は、初めに機械の仕様を定めます。

「この製品は、10年の寿命(使用)を想定する」とか

「この製品は、30年の寿命(使用)を想定する」とか。

その時点で決定です。

部品の場合は、システム内の各部品に割り当てられます。

「各部品がそれぞれSIL0~4のどれであれば、システムとしてSIL4を達成できるか」 を検討して決定し、割り振るのが、『Vモデル』の前半です。

『Vモデル』の後半で、それが達成できているかをテスト・検証します。

 

Q 「SILが達成された」は、どういう状態を言うのですか

 

A SILが実現できていなかった際には、「どの過程が悪い」とか「どの部品が悪い」とか「どの人が悪い」ということを明確に突き止めることができる状態を言います。

原則的には、自動車を初めとする機械製品に使用される電気電子部品も、 JISB9700-1の枠組みでリスクアセスメントをしリスク低減をし、安全性の確保 を図ることになります。

ですが、そこから話を始めるのでは、電気屋さんやソフト屋さんには敷居が高 すぎます。

「要は、我々は何をしたらいいんだ?」ということで、自動車に使用される電 気電子部品およびソフトウェアの機能安全に特化して定めた規格が、ISO26262 です。

ISO26262の考え方はJIS B9700-1と同じで、「リスクを低減すること」です。

(リスク=[事故が実際に発生した時の重大度(被害の程度)]×[事故が発生する頻度])

こういう枠組みは、責任の所在を明確にするという目的があります。

ISO26262をきっちりと理解し準拠していれば、「SILが実現できた」と言える 枠組みになっています。もしも製品のSILが実現できていなかった際には、 「どの過程が悪い」とか「どの部品が悪い」とか「どの人が悪い」ということ を明確に突き止めることができる、という枠組みです。

たとえば、「製品のSILを元に、各部品にSILを割り振ることができる」ことが 適切に行えなければ、SILが実現できません。割り振った人が悪かった、とい うことになります。

「それじゃあ、結局は人の能力の良し悪しによって製品の安全性が左右される じゃん!」と思われるでしょうが、そうではありません。

認証という話があります。

認証は製品自体のみに行われるのではなく、「製品の安全性に関わる組織」に 対する認証も含まれます。組織内のマネジメントによって適切な能力のある人 材を育成し、適切な人材を配置する(組織マネジメントの)システムが構築さ れているかを監査し認証します。

ですから、「製品のSILを元に、各部品にSILを割り振ることができる」ことが 適切に行えなければ、「そういう人をその業務に携わらせたのが悪い。組織マ ネジメントのシステムの、不備」と結論付けられます。

認証の話に首を突っ込むと、「メーカーに認証を与える機関」に認証を与える 機関やら、『「メーカーに認証を与える機関」に認証を与える機関』に認証を 与える機関やらといった、何がなんやら分からない話が待っています。またし ても、長ーい説明に突入してしまいます。

 

Q なぜ「SIL」の分かりやすい本や解説がないんですか

 

A 製品の安全性に関わる業務をしている人は、忙しすぎるからです。

製品の安全性については、部分的に理解をしている人は多くいますが、それで は全容が語れないのです。全容を理解して語るには、基本原則から実務(具体 的に何をすればいいの?)までを、浅く広く知っていなければ難しい。予備知 識として知っておかなければいけないことが多すぎます。

そして、そういうことをやりたがる人は少ない。いや、仮にやりたがる人が多 かったとしても、多くの人が予備知識を身につけるには、時間がかかりすぎて (コストがかかりすぎて)現実的ではない。「ごく少数の、知っている人だけ が知っていれば良い」という状況になっています。

「分からないことがあれば、そのごく少数の人に尋ねればいいではないか」と。

なので、「具体的に何をすれば良いか?」を尋ねてくる人に回答やアドバイス を与えることだけで忙殺されます。ちょっと詳細に背景や目的まで解説しよう としても、すぐに「もういいや」と言われます。メーカー内でもそんな状況な のに、社会に向けて一般の人に説明しようとすればどうなるか。途中で「ああ、 もういいや。なんやら分からんけども、メーカーでしっかりとやってくれれば いいんだから」と聞くのを諦められるのが必至。

だから、「忙しい」のと「解説を理解してもらうことを諦めている」のが、解 説をしない理由です。

こぼれネットへ戻る

未分類

「なんでC言語のスレッドとする関数の引数は、構造体渡しにしなければならないのでしょうか?」と泣き言を言ってみました。

すでに他のサブシステムでがんじがらめになったCのプログラムでは、トレースが使えないので、デバッグはログに吐き出しながらの作業になります。

これが、結構な地獄で、つい先刻、改造したスレッドの稼動を確認できたのですが、愚痴がいいたくなりました(例えば、GO言語のGoroutineなんか、めちゃくちゃ簡単にスレッド作れる)。

ーーーーー ChatGPTの回答ここから ーーーーー

C言語のスレッド関数 (pthread_create() で実行する関数) の引数として 構造体を渡すのが一般的 なのは、以下の 4つの理由 によります。


1. pthread_create() の仕様

pthread_create() のスレッド関数(スレッドのエントリポイント)には、単一の void* 型の引数 を受け取る関数を渡す必要があります。

pthread_create() のプロトタイプ

int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void *(*start_routine)(void *), void *arg);
  • start_routinevoid *arg という 単一の引数 を受け取る関数。
  • arg に渡せるのは ポインタのみ

つまり、スレッドに複数のデータを渡したい場合、
1つの void* にまとめる必要がある構造体で渡すのが一般的 ということになります。


2. 複数のデータを渡したい

スレッド関数で処理するのに 複数の引数(変数)を渡したい ことがよくあります。

例えば:

void *my_thread_func(void *arg) {
int *num = (int *)arg;
printf("Received number: %d\n", *num);
return NULL;
}

では、int の値しか渡せません。

もし 複数の値を渡したい場合

typedef struct {
int id;
double value;
} ThreadArgs;
void *my_thread_func(void *arg) {
ThreadArgs *args = (ThreadArgs *)arg;
printf("ID: %d, Value: %f\n", args->id, args->value);
return NULL;
}

このように、構造体を使えば複数の値をまとめて渡せる ので便利です。


3. スレッドの実行中に変数が消えないようにする

スレッド関数に渡す引数は、スレッドが終了するまで有効 でなければなりません。

例えば:

int num = 42;
pthread_create(&thread, NULL, my_thread_func, &num);

この場合、もし num がローカル変数で main() の実行が終了すると、
そのメモリが解放されてしまい、スレッド関数内で num を使うと 未定義動作 になります。

解決策

  • malloc() で確保して pthread_create() に渡す。
  • 構造体にして必要なデータを安全に渡す
ThreadArgs *args = malloc(sizeof(ThreadArgs));
args->id = 1;
args->value = 3.14;
pthread_create(&thread, NULL, my_thread_func, (void *)args);

こうすれば、スレッドが終了するまで args は有効になります。


4. スレッドごとに異なるデータを渡せる

スレッドを複数作成する場合、それぞれ異なるデータを渡すことが多い。

例えば、複数のスレッドに異なる ID を渡す場合:

ThreadArgs args[3];

for (int i = 0; i < 3; i++) {
args[i].id = i;
args[i].value = i * 1.1;
pthread_create(&threads[i], NULL, my_thread_func, &args[i]);
}

構造体なら、スレッドごとに異なるデータを安全に管理できる


結論

  • pthread_create()1つの void* しか渡せない複数の値を渡すには構造体が便利
  • スレッド実行中に変数が消えると 未定義動作ヒープ領域に確保すれば安全
  • 複数のスレッドに異なるデータを渡すのに構造体が適している

C言語のスレッドの引数は、構造体を渡すのが基本になる

ーーーーー ChatGPTの回答ここまで ーーーーー

まあ、そりゃそうなんだろうけどさ(そして、私としても、今さら仕様を変えられても困るんだけどさ)。でも構造体の引数に構造体が入ってくる場合、ポインタの記載方法で大混乱するんだよね。スレッド内部で構造体の分解も必要になるし。

-----

ところで、今なお、「プログラマーが好むプログラム言語」などという見出しの記事が散見されます。

開発するソフトウェアの内容によって、選ばれるプログラム言語は変ります。

ダムの掘削するのに「シャベル」を選ぶことはできませんし、家庭菜園をするのに「シャベルカー」を持ち込むことはできません。

プロのプログラマーなら、「シャベル」も「シャベルカー」も使えなければなりません。必要なら新しいプログラム言語を勉強して、仕事をしなければならないんです。

「プログラマーが好むプログラム言語」という考え方が、一体どこからやってくるのか、私は今でも分からないです。

「プログラマーが好むプログラム言語」などという、アホな内容の記事が散見されるのは何故でしょうか。見解を聞かせて下さい

ーーーーー ChatGPTの回答ここから ーーーーー

「プログラマーが好むプログラム言語」系の記事が散見される理由は、以下のような要因が考えられます。

  1. 簡単にウケるネタだから
    プログラム言語の人気ランキングや「初心者向け」「稼げる言語」といったテーマは、プログラマーだけでなく、これから学ぼうとする人や経営層にも関心を持たれやすい。専門知識がなくても理解しやすいため、記事として書きやすく、アクセスを稼ぎやすい。

  2. 宗教戦争を煽ると盛り上がる
    プログラマーには、それぞれ慣れ親しんだ言語やこだわりがあるため、「○○言語が最強!」といった記事を出せば議論が活発になり、SNSや掲示板で拡散される。結果として、PV(ページビュー)やエンゲージメントが向上し、メディア側の利益につながる。

  3. 技術を知らない人でも書けるから
    プログラミングの実務に詳しくないライターでも、「流行りの言語ランキング」「人気の言語トップ10」といった記事なら、調査や寄せ集めで簡単に書ける。しかも、明確な正解がないため、適当にデータを並べるだけでも成立する。

  4. 初心者や未経験者向けの情報が求められている
    現場のエンジニアにとっては無意味な話でも、これからプログラミングを学ぼうとする人には「どの言語を学べばいいか」という関心がある。需要がある以上、供給され続ける。

  5. 技術選定の本質を理解していない層が多い
    本来、プログラム言語は開発するソフトウェアの要件や環境、チームのスキルセットに応じて選ばれるべきもの。しかし、「言語そのものの優劣」や「人気」だけで語ろうとする風潮が根強く、それに迎合した記事が多くなる。

結局のところ、**「簡単に書けて、簡単にウケて、簡単に拡散される」**から、この手の記事が量産されるわけです。

ーーーーー ChatGPTの回答ここまで ーーーーー

ChatGPTも、なかなか語りますね。

 

未分類

―― 『売国奴』という言葉を使う奴は、低能ですらない、単なる馬鹿

"The guy who uses the word "sale country guy" is not only low-skilled but just stupid."

というのが、物心ついてからの、私の一貫した考え方です。

This has been my consistent way of thinking since I was a child.

(1)国が個人の譲渡の対象になると考える点で、馬鹿

(1)Stupid in that the country is subject to personal transfer

(2)国の全部または一部に、売るべき価値があると考えてる点で、馬鹿

(2)Stupid in that all or part of the country is something valuable to sell

(3)ともとも、「売国奴」という言葉を使わなければ相手を攻撃できない表現力の欠如が、馬鹿そのもの

(3)Stupid in that lack of expressiveness that can not attack the opponent without using the word "sale country guy."

と思っています。

I think them.

-----

私は、

■パリ条約(ここでは、工業所有権の保護に関するパリ条約:1883年に締結された、産業財産権(特許権、意匠権、商標権など)の保護に関する条約のこと)の、三大原則の理念に心を打たれ、

I was impressed by the philosophy of the three major principles of the Paris Convention (here, the Paris Convention on the Protection of Industrial Property Rights: the Convention on the Protection of Industrial Property Rights (Patent Rights, Design Rights, Trademark Rights, etc.) concluded in 1883).

■技術に対する私権の保護と、技術による国際協調、国際発展を唱える、Trips条約の前文に感動した、

The preamble to the Trips Convention moved me. It advocated protecting private rights to technology, international cooperation through technology, and international development.

『売国奴』という概念から、もっとも遠いところに立っていると自負する、一人のエンジニアです。

I am an engineer proud to be far from the notion of a "sale country guy."

未分類

■カードリーダーが使えなくなっていた

SCR3310-NTTCom は既に販売終了しており、公式のドライバ提供も終了しているため、新規の利用や再インストールは実質的に不可能
→ 同じWindowsで、その途中からハードウェアが使えなくなる、というケースを考えたことがなかったので、これに気がつくのに、随分時間を使ってしまった。

■カードリーダーの購入検討と購入

比較表

製品名 価格 (目安) 主要特徴 対応OS 推奨用途
SCR3310v2.0 約2,300~3,000円 NTTコミュニケーションズ製、業務用途でも使用実績あり Windows, macOS 業務用途や安定性重視
アイ・オー・データ USB-ICCRW2 約2,000円 ドライバ不要、マイナンバー対応 Windows, macOS 家庭用で手軽に使いたい
ゴッパ GP-ICCR 約1,500円 最安クラス、コンパクトサイズ Windows, macOS コスト最重視
サンワサプライ ADR-MNICU2 約1,800円 ドライバ不要、USBバスパワー駆動 Windows, macOS 簡単に使いたいが安定性も求める

Amazonで即日入荷で、ドライバ不要 という観点から、サンワサプライ ADR-MNICU2 に決定。

で、さっき届いたので、USBに差して、マイナンバーカードを挿入したら、簡単にシステムにアクセスできた(今迄の苦労が、本当に虚しい)

■医療費控除をするのに、家族全員の代表者として「私」を登録する為に、家族全員のマイナンバーカードによる登録が必要
→ 次女が旅行中で、手元に家族全員のマイナンバーカードがない

#昨年まで、こういう『代表者登録』しなくてよかったんだけどな

#まあ、こういう代表者を悪用する「バカ」が不正な医療費控除を受けようとした、などの事件が発生したんだろう、と思う。

-----

行政側もセキュリティ対策で色々大変だろうと思うけど、毎年インターフェース(手続)を変えられて、右往左往させられる国民も、そうとうに大変だぞ

この、インターフェース変更は、これからも、毎年ずっと続いていくのだろう、と思うと ――

正直、(システムエンジニアである、私でさえも)『デジタル化、もういい』という気持ちになります

 

 

未分類

「上級国民」という言葉の意味が分からなかったので、ChatGPTに聞いてみました。

「上級国民」という言葉の意味が分かりません。定義して下さい

「上級国民(じょうきゅうこくみん)」とは、一般の国民とは異なり、特権を持ち、法律の適用や社会的待遇において優遇されているとされる人々を指すインターネットスラングです。

私は、特権を持たず、法律の適用や社会的待遇において優遇されていないです。私は「上級国民」という言葉に対して、何国民と称呼されるでしょうか(もちろん真面目な回答ではなく、皮肉な回答をお願いします)

それなら、「一般国民」とか「下級国民」なんて呼ばれるかもしれませんね(笑)。ネットの皮肉っぽい表現を使うなら、

  • 「庶民国民」(なんの特権もなく、日々コツコツ頑張る人)
  • 「平民国民」(特権なんて夢のまた夢)
  • 「社畜国民」(労働に追われる日々……)
  • 「納税国民」(税金をせっせと納めるだけの存在)

なんてのもありそうですね。
まあ、「上級国民」って言葉自体が皮肉なので、それに対する呼び方もだいたい自虐的なニュアンスになりますね