自然言語で仕様を書くのやめよう。「言葉にすれば」「嘘に染まる」水谷啓二・ダンシングオールナイト（もんたよしのり）

仕様を自然言語で書くのやめませんか。「言葉にすれば」「嘘に染まる」水谷啓二・ダンシングオールナイト　もんたよしのり

https://qiita.com/kaizen_nagoya/items/dd6ee74818f1a1a1c918

改訂版です。　


自然言語処理で陥る罠。仮説（149）

https://qiita.com/kaizen_nagoya/items/71093310ffc5324f15ff


<この項は書きかけです。順次追記します。>


# 仕様または設計

仕様または設計を自然言語で書くのやめませんか。

言葉があいまいかどうかが問題なのではありません。
誰がそれを読むかで意味が変わることに気がついていないふりをするのは止めましょう。
計算機が読んで意味が変わる可能性が少ない、仕様記述言語か、プログラミング言語で書けばいいじゃないでしょう。

仕様記述言語で書いても、プログラミング言語で書いても、OSが変わったり、周辺装置の速さが変わると振る舞いは変わることがあります。OSが変化しても、周辺装置の速さが変わっても、その変化を引数などで対応できるような設計を作ることがいくつかの事業で目標だったような気がします。



# 言葉

言葉にすれば、意味が通じると思い込んでいる人がいるかもしれない。

「言葉にすれば、嘘に染まる」と思っている人がいるかもしれない。

二人の間で、言葉は通じない。

プログラミング言語は、どんな思い込みがあろうが、コンパイルエラーになるか、暴走するか、ある場合はうまく動いていて別の場合はうまく動かなくなるなど、思い込みとは、ちょっと独立的な反応をしてくれる。

言葉にすれば、嘘に染まると思ってる人は、どうするか。

## 統計　

統計の嘘。仮説（127）

https://qiita.com/kaizen_nagoya/items/63b48ecf258a3471c51b

プログラマにも読んでほしい「QC検定にも役立つ！QCべからず集」

https://qiita.com/kaizen_nagoya/items/d8ada7b7fceafe2e5f0e

# 踊る
歌にあるとおり、踊ってれば言葉はいらない。嘘もつかない。

https://www.youtube.com/watch?v=DZpI_WPKjho

水谷啓二・作詞、もんたよしのり・作曲
もんた＆ブラザーズ・歌

水谷啓二
https://www.uta-net.com/lyricist/33777/

言語化する前に踊るか、言語化してから踊るかは、その人の好み。
言語化せずに踊ってもいい。tiktokで、踊りが流行るのは嬉しい。
ジャズダンスを習っていたことがある。

言語化せずに踊りで伝えられることはたくさんある気がする。
言語化しても、踊りながら伝えれば、伝わることがあるかもしれない。

「踊る阿呆に見る阿呆。同じ阿呆なら踊らにゃ損、損」

阿波踊り・掛け声まとめ（字幕付き）

https://www.youtube.com/watch?v=G5RyjkRus5k

IT分野では、踊りを振る舞い(behavior)と読み換えるとよい。
振る舞いには、状態遷移(state machine)、時系列(sequence), 刻時(timing), 利用事例(use case)などがある。

### 絵、写真・動画

絵、写真、動画で伝えることも大切かもしれない。

プログラマが知っているとよい色使い(JIS安全色)

https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35

設計(design)は、図を書くこと。programも図を書くという語源。
設計で書いたプログラム以外の図はprogramに変換できるのが通例。
Matlab/Simlinkも、UMLもprogramに変換できる。

図を使って分析・設計すればこんなに簡単。安全（１１）

https://qiita.com/kaizen_nagoya/items/6347eb55b2812d745549

UMLモデリングの本質、児玉 公信

https://qiita.com/kaizen_nagoya/items/bc6ac386af27530eb78a

USE Case図で顧客の社長の顔写真を貼る手法

https://qiita.com/kaizen_nagoya/items/84ec2775059fbf2c50a4


踊り(behavior)には、例えば、製造業における人の操作を機械学習して自動化することも含むとよい。

製造業における機械学習

https://qiita.com/kaizen_nagoya/items/fbe846de16f74bea1d6f

# 音楽
踊るには、なんらかの音楽があることが前提かもしれない。
言葉で伝えるのではなく、音楽で伝えるのは大事。

文字ではなく、音。音符。

プログラムは音楽だ (A program is a music.) 仮説（54）

https://qiita.com/kaizen_nagoya/items/33c9f33581e6886f8ad8


# 自然言語
言葉は、発話者の言語空間と聞き手の言語空間の対応づけにもとづく、確率過程として考えることができます。
発話者と聞き手の間で、意味が通じる確率はすごく低いというのが経験則です。

大事なことは３回言うという経験則があります。
最初に聞いた時の印象と、
２度目に聞いた時の理解と、
３度目に聞いた時の納得感がすごく違うことがしばしばあるからです。

学生におしえてもらい、違和感のあるところだけ補足するという教育方法をとっているのは、
自分の言葉で話すのではなく、教わる側の言葉でやりとりをしたいたいめかもしれませんm。

新人(学生)を指導するよりも新人(学生)に指導してもらった方が効率的。仮説（139）

https://qiita.com/kaizen_nagoya/items/db993b1536055029f7c8

データサイエンティストの気づき!「勉強して仕事に役立てない人。大嫌い!!」『それ自分かも?』ってなった!!!

https://qiita.com/kaizen_nagoya/items/d85830d58d8dd7f71d07

# 仕様記述言語・設計記述言語
発注される方がプログラミング言語、仕様記述言語を書かれないのであれば、代筆料金をいただいて、代わりに書かせていただければいいのではないでしょうか。

算譜(program)が計画(plane),設計(design)である３つの理由

https://qiita.com/kaizen_nagoya/items/34daa0403eaca5e8b5a6

自然言語認識に依存したソフトウェア開発をやめれば、生産性は倍くらいにあがるかもしれない。「言葉にすれば」「嘘に染まる」ことを知っていても、仕事で言語化することの利点だけを強調する人がいるのには違和感を感じる。お互いに意思が通じてないことを隠すのが大人だというのはありだと思う。

プログラミング言語、仕様記述言語で書いても、場合によっては命名規則などで嘘がつけるかもしれないし、隠し事ができるかもしれない。
嘘、隠し事がシステムに与える影響について、別にまとめたい。

国際規格をバベルの塔にしないための努力であるISO のOSIはどうなったでしょうか。
整合性のある体系を作ろうとして、仕様記述言語も駆使しようとして、大きくなりすぎて、いつ何が動くか現実界が見当たらなくなってしまったのでしょうか。

仕様記述言語で書けばいいという問題でもないこともわかっています。
現実的な時間以内に実行が終わるのでなければ意味がない。
静的な仕様を議論するのではなく、動的な仕様が暴走したり、破綻したりしないような静的な宣言とうまく組み合わせて現実界を提案していくことが大事なのかもしれません。

# あとがき

この記事は、ABC予想に関する調べごとに始まり、不完全性定理の復習をしようとしたことに始まります。ABC予想に関する調べ物はあまり進んでいませ。不完全性定理の調べ方は少しわかりました。

ABC予想と不完全性定理の数学的な範囲と科学分類

https://qiita.com/kaizen_nagoya/items/380c72e3038f290d57ff

望月新一　ABC予想論文を読む 。新人にお勧めの基本動作。pdftotext処理編

https://qiita.com/kaizen_nagoya/items/edc7857de19fe2d70bf6

## フローチャート

PCでプログラムを打つんだから、紙カードでプログラム組んでいた時に必要だった「フローチャートを書くのをやめませんか。」といって４０年が経過した。３０年くらい経った10年前から、フローチャートを書けという人が劇的に減った。紙カードでプログラムを組んでいた世代が退職したからかもしれない。

自分がプログラミングを習いに行っていた頃は、紙カードで教えてもらった。その頃には、プログラミング可能な関数電卓が出始めていて、並列して関数電卓でもプログラミングを習った。そして1978年に、初めてPCでプログラムを入力した。機械語で書いたプログラムをBASICでCALLするようなたぐいのもの。もう、フローチャートは要らない。紙カードをぶちゃけて、並べ直したり、紙カードで入力してアルゴリズムが間違っていたら、翌日しか作業できないということはなくなったのだ。フローチャート的なプログラミングである構造的なプログラミングはアセンブラのマクロでもできるかもしれない。フローチャート的な記述をプログラムに変換することもできれば、プログラムからフローハートを生成することもできる。別にフローチャートは要らなくなった。

仕様記述言語は何がいいかってことになるのだろう。
フェリカではVDMを利用されたようだ。もう１０年以上昔の話。

「@kazuo_reve ソフトウェア品質管理研究会（SQiP研究会）に参加して」を拝読して

https://qiita.com/kaizen_nagoya/items/25b8c01419d3ad06e05a

AUTOSARの仕様をEvent-Bで記述しようとした人がいるように聞いたことがあるような気がした。成功していないのか、内部製品に応用しただけで対外的に公開していないのかもしれない。

# ダンシングオールナイト

同じ言葉（歌詞）であって、同じ曲であっても、歌う人、編曲する人、伴奏する人の思いによって、伝わる幅、広さ、高さ、深さ、周波数が違うかもしれない。

踊りがあるか、ないかでも違う可能性がある。
踊りから何が伝わるかを分析するとよい。

# 踊り
映像作品は踊りがあると嬉しい。dancing all nightなら。

## 嘘
ダンシングオールナイトの歌の嘘はなんだろう。
人によって違う。女性か男性かで違うかもしれない。

候補１
>この店で最後の夜をどちらからともなくそう決めて

一方の主張を鵜呑みにしてはいけない。両者に確認してみないと。
また、一緒の場所にいるのがあらかじめ期間が限定していたかもしれない。
一方は初めから決めていたかもしれない。
どちらからともなくそう決めたというのは、強者による圧迫の可能性は高い。

候補２
>危なげな恋としらず

無自覚か、自覚していたかは別にして、
言語的以外の感覚では「しらず」というのは嘘かもしれない。

候補３
>無邪気に

邪気があるかどうかは、邪気の分類、範囲による。
邪気がないことを証明するのはほぼ不可能。嘘かもしれない。

## 立場

### 性別
女性が、女性視点で歌う。
女性が、男性視点で歌う。
男性が、男性視点で歌う。
男性が、女性視点で歌う。
４種類の歌い方があるかもしれない。

恋が、同性の場合と異性の場合という場合分けができるかもしれない。

男性の楽曲を、歌詞を変更したとはいえ、
オリジナルを超えた女性歌手といえば、

#135 「ガールズ・ジャスト・ワナ・ハヴ・ファン」シンディ・ローパー

https://bs.tbs.co.jp/songtosoul/onair/onair_135.html

### 母語

日本語Nativeの人が日本語で歌う。
日本語non Nativeの人が日本語で歌う。
中国語、韓国語に翻訳して歌う。

いくつかの例をYoutubeから引いて見る。

## Youtube

## which cover are you  favorite?

1. Nancy Wang
ダンシングオールナイト 台湾語版カバー　「但是又何奈」　王曉雲

https://www.youtube.com/watch?v=EcSm2fa3lok

2.Mariko Takahashi
高橋真梨子 / ダンシング・オールナイト 

https://www.youtube.com/watch?v=dB6Y7GXBIDk

3.계은숙 
ダンシング･オールナイト　ケイ･ウンスク

https://www.youtube.com/watch?v=eofvm6Hj8a4

4.Vicky-trang 
ヴィッキー・チャン　ダンシング・オールナイト

https://www.youtube.com/watch?v=HshOFbhc8RQ


<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Which &quot;Dancing All night” cover is your favorite ? URLs are in my comment. <a href="https://t.co/uZ77QedV3a">https://t.co/uZ77QedV3a</a></p>&mdash; wocs2017 (@wocs2017) <a href="https://twitter.com/wocs2017/status/1533016060810895360?ref_src=twsrc%5Etfw">June 4, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

# Advent Calendar 2022

今年企画した４つのAdvent Calendarと、それぞれの記事一つをご紹介します。

AUTOSAR Advent Calendar 2022

https://qiita.com/advent-calendar/2022/autosar

AUTOSAR References to ISO, IEC, ITU, IEEE, RFC and SEA etc.

https://qiita.com/kaizen_nagoya/items/d7d252211e10a79516df

Automotive Handbook Advent Calendar 2022

https://qiita.com/advent-calendar/2022/automotivehandbook

Basic principles, ボッシュ自動車handbook(英語)11版まとめ<2>

https://qiita.com/kaizen_nagoya/items/24a1ba5da3d09b2a95d1


2022 いいねをいただいた記事ランキング(O.K.版) Advent Calendar 2022

https://qiita.com/advent-calendar/2022/goods

2022年１月下旬　いいねをいただいた記事　16

https://qiita.com/kaizen_nagoya/items/0ee589a8edaeab24fd2a

AdCale(O.K.) Advent Calendar 2022

https://qiita.com/advent-calendar/2022/adventcalendar2022

「会議は15分未満」に。小耳にはさんだ話。

https://qiita.com/kaizen_nagoya/items/510c47c5d1e8d03145db

AdvencCalendar2022 報告

https://qiita.com/kaizen_nagoya/items/5b4b99cb9ad571f4094b


誤差の評価が苦手（専門分野以外）

https://qiita.com/kaizen_nagoya/items/cc3a50827b24ab80985f



 ＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞


# 文書履歴
ver. 0.01  20221212

### 最後までおよみいただきありがとうございました。

いいね、フォローをお願いします。