先の大戦により海外などで亡くなったとされる日本人約２４０万人のうち、現在でも約１１２万柱の遺骨が回収されていない。戦後８０年が経過して遺族や当時を知る現地住民が減少する中、遺骨収集を「国の責務」とする政府は２０２９年度までを集中実施期間として回収を急いでいる。
⇧ 年毎の回収率の推移の統計を公開して欲しいところですな...
Wikipediaの情報が正しいとすると、
日本
戦没者の総数
⇧ 厚生労働省は、日本国内の民間人の死者を考慮していないみたいね...
ちなみに、「終戦」と「敗戦」の言葉の使い分けについてが話題となっておりますが、
ですので、ソ連政府、そして現在のロシア政府は意図的に、戦闘終結の日付を「8月15日」ではなく、自らの違法な戦闘と占領を覆い隠すためにも、「第二次世界大戦終結の日」を「9月3日」と制定しており、自らの侵攻と占領を正当化するプロパガンダを行っています。中国も、近年はそのようなロシア政府に迎合しています。この、歴史認識をめぐる中ロの連携は、日本にとってとても重い現実です。
もしも石破総理が、「8月15日」の「終戦」ではなく、「9月2日」の連合国に対する日本の「敗戦」の意味を強調して、その日に歴史談話を発することになれば、それは上記のようなロシアの創る日ソ戦争正当化のための「物語」の正統性を容認することになりかねません。
⇧ 上記の話にあるように、なかなかにややこしい...
Wikipediaの情報が正しいと仮定すると、
日本の降伏（にほんのこうふく）とは、通常、第二次世界大戦（太平洋戦争）末期の日本による、連合国（実質的にはアメリカ合衆国）のポツダム宣言受諾（1945年8月10日）から、玉音放送及び日本軍の戦闘停止（8月15日）、降伏文書署名（9月2日）に至るまでの過程を指す。以下、日本及びその各占領地における経過を説明する。
ポツダム宣言受諾までの経緯
8月15日
正午に天皇はラジオ放送（玉音放送）をもって、日本の全国民と全軍にポツダム宣言受諾と日本の敗戦を表明し、この時点で一部地域を除き、ほぼ全ての日本軍の戦闘行為が停止された。
南樺太、満洲などは沖縄戦同様民間人を巻き込んだ凄惨な地上戦となっていたが、ポツダム宣言受諾の8月15日以降も、第5方面軍による南樺太死守命令等により南樺太や占守島では赤軍との戦闘が続いた。
また満洲では赤軍と国府軍との戦いの中、逃げ遅れた日本人開拓民が混乱の中で生き別れ、後に中国残留孤児問題として残ることとなった。結局赤軍は満洲のみならず、日本領土であった南樺太、北千島、択捉、国後、色丹、歯舞、朝鮮半島北部の全域を完全に支配下に置いた9月5日になってようやく進軍を停止した。
⇧ とあるが、
ポツダム宣言（ポツダムせんげん、英: Potsdam Declaration）は、1945年（昭和20年 ）7月26日にイギリス、 アメリカ合衆国、中華民国の政府首脳の連名において日本に対して発された全13か条で構成される宣言。
正式名称は、日本への降伏要求の最終宣言（にほんへのこうふくようきゅうのさいしゅうせんげん、Proclamation Defining Terms for Japanese Surrender）。宣言を発した各国の名をとって「米英支三国宣言（べいえいちゅうさんごくせんげん）」ともいう。ソビエト連邦は、後から加わり追認した。
概要
1945年（昭和20年）8月14日、日本政府は本宣言の受諾を駐スイスおよびスウェーデンの日本公使館経由で連合国側に通告、この事は翌8月15日に国民にラジオ放送を通じて発表された（玉音放送）。9月2日、東京湾内に停泊する戦艦ミズーリ甲板で日本政府全権の重光葵と大本営（日本軍）全権の梅津美治郎および連合各国代表が、宣言の条項の誠実な履行等を定めた降伏文書（休戦協定）に調印した。これにより、宣言は初めて外交文書として固定された。
⇧ 「ポツダム宣言」の受諾から、「降伏文書調印・即時発効」までにタイムラグがあるので、「終戦」と「敗戦」という「レトリック」を駆使するしか無さそうであるのだが、「敗戦国」の主張がどこまで許容されるのかは分からない...
ただ、
受諾
8月15日正午、日本政府は宣言の受諾と降伏決定をラジオ放送による昭和天皇の肉声を通して国民に発表（玉音放送）。なお、陸海軍に停戦命令が出されたのは8月16日、更に正式に終戦協定及び降伏が調印されたのは9月2日である。
その後も8月中は、国内ではポツダム宣言受諾に反対する右翼団体構成員らによる松江騒擾事件や集団自決事件、陸軍将校等が地方の放送局を占拠する事件が相次いだ。その一方では、ソ連や中国との間で戦闘が継続した。9月2日、日本政府は米戦艦ミズーリの艦上で降伏文書に調印した。降伏文書の最終文節には、バーンズ回答にあった「"subject to"」の内容が盛り込まれ、日本政府はこれを「制限ノ下ニ置カルル」と訳した。その後も各戦線に残存していた日本軍と中国軍・アメリカ軍との小規模の戦闘は続いた。
⇧ 上記の内容が正しいとすると、「9月2日」以降も戦闘が続いていたとあるのだが、「終戦」については、
ところが、20世紀に入ると戦争そのものが国際法における違法行為との解釈が成立するようになったため、却って戦争における国際法上の開戦手続が行われなくなり、終戦も講和条約や平和条約が結ばれない状態のままの休戦協定で定められた停戦状態の継続、すなわち協定に基づく休戦の一般化・恒久化、もしくは当事者一方が相手方に降伏を通告して戦闘状態が終結した状態を指して終戦と呼ぶようになった。
⇧ とあり、解釈が難しい。
そもそも、
『終戦も講和条約や平和条約が結ばれない状態のままの休戦協定で定められた停戦状態の継続、すなわち協定に基づく休戦の一般化・恒久化、もしくは当事者一方が相手方に降伏を通告して戦闘状態が終結した状態を指して終戦と呼ぶようになった。』
⇧「降伏」を通告したとしても、相手方が戦闘行為を続けた場合は、戦闘状態が終結した状態にならないとすると、「終戦」は相手方の匙加減次第になるものな...
日本としては、
日本においては、終戦記念日（しゅうせんきねんび）は1945年8月15日と認識されている。しかしアメリカ合衆国など多くの国々では、一般的に日本が降伏文書に調印した1945年9月に終結したと認識されており、国によって1945年9月2日とする国（アメリカ合衆国など）、9月3日とする国（中華人民共和国など）がある。第二次世界大戦戦勝国にあたるいくつかの国では対日戦勝記念日が祝われる（当該記事も参照）。
⇧ 上記にある感じだと「8月15日」を「終戦」と捉えていますと。
「ポツダム宣言」も定義があって無いようなもので、
「無条件降伏」の当否
→詳細は「無条件降伏」を参照
日本の降伏が「無条件降伏」にあたるかに関して、軍事的意味においてはポツダム宣言受諾が「無条件降伏」にあたることについての異論は見受けられないが、第12条等による記述が明確に条件に該当するかについては異論がある。
ポツダム宣言第12条は「日本国国民の自由に表明せる意思に従い平和的傾向を有し且責任ある政府の樹立」を求めており、バーンズ回答では「日本の最終的な政治形態はポツダム宣言に従い、日本国民の自由に表明する意思によって確立される」となっていた。これは、天皇制問題を日本国民の意思に委ねるという連合国による保証であった。
有馬哲夫は、日本の利益代表国であったスイスに残されている外交文書を分析して、「日本は、『バーンズ条件』の拒否と読める回答についてアメリカ側からなんのコメントもないまま一方的に『終戦』を宣言してしまった」とし、「互いにいいっぱなしで、条件についてはうやむやなまま終わった」と報告している。
またアメリカ政府内でルーズベルトとトルーマンの「無条件降伏」観に違いがあり、トルーマンの対日政策も当初は「条件付無条件降伏論」に立脚しながら占領初期に「条件」の契約性の否認を表明しており、揺れがある。
連合国としてではないが、米国内の通達としてトルーマン大統領からマッカーサー元帥に対し行われた通達において、「われわれと日本との関係は、契約的基礎の上に立つているのではなく、無条件降伏を基礎とするものである。貴官の権限は最高であるから、貴官は、その範囲に関しては日本側からのいかなる異論をも受け付けない」趣旨の指令があり、米国大統領の対日政策の基本認識が示されている。
この通達はトルーマン大統領からマッカーサー連合国最高司令官へのTOP SECRETの文章であり直接日本政府に通告されたものではないが、降伏文書（契約的性質を持つ文書）を交わしたアメリカが実質的にその契約性を否認していた証拠と解する立場もある。
これを受けて、1945年9月3日に連合国軍最高司令官総司令部はトルーマン大統領の布告を受け、「占領下においても日本の主権を認める」としたポツダム宣言を反故にし、「行政・司法・立法の三権を奪い軍政を敷く」という布告を下し、さらに「公用語も英語にする」とした。
これに対して重光外相は、ダグラス・マッカーサー最高司令官に「占領軍による軍政は日本の主権を認めたポツダム宣言を逸脱する」、「ドイツと日本は違う。ドイツは政府が壊滅したが（フレンスブルク政府）日本には政府が存在する」と猛烈に抗議し、布告の即時取り下げを強く要求した。
その結果、連合国軍側は即時に布告の即時取り下げを行い、占領政策は日本政府を通した間接統治となった（連合国軍占領下の日本）。
⇧ 最早、滅茶苦茶である...
昨今の日本の政治の腐敗が止まることを知らない感じになっているのだが、
音楽性
歌詞の転機は少なくとも
- 「雨あがりの夜空に」を書いたとき（当時の事務所には下ネタをオブラートに包まず発言する人物が多く、彼らの影響を受けた）。
- 「サマータイムブルース」を書いたとき（清志郎の父親［当時すでに故人］の誕生日にチェルノブイリ原子力発電所事故が発生したことから反原発の歌詞を書いた）。
- 『COVERS』制作のとき（母親の遺品整理の際にみつけた第二次世界大戦中の恨み言が書かれた日記の内容に強い衝撃を受け、反戦・反体制の歌詞を書くようになる）。
その他のエピソード
国政選挙の投票制度そのものに批判的な考えを述べていた爆笑問題の太田光に「君みたいな影響力のある人が、選挙行くななんて言ったらいけないよ」「政治に無関心なんて言ってると、君の息子なんかが戦争に行っちゃうわけよ」と諭し考えを改めさせた。
⇧ 上記にあるように、「投票制度」を代替するものが出てこない以上、「選挙」に行くしかしかないと。
「投票制度」のデジタル化はして欲しいのだが、
電子投票（でんしとうひょう）とは、票を入れる行為を電子化した投票（方式）のこと、あるいはそのような投票を行うことをいう。投票所における投票で電子機器を用いて行う投票のほか、インターネットなどのコンピュータネットワークを介しての投票などが含まれる。
各国の活用
2002年に電子投票の実験が行われ、2005年の地方議会議員選挙において正式に電子投票が採用された。その後、2007年の国会議員選挙ではインターネットを介した電子投票も実施され、さらには2009年6月の欧州議会議員選挙においてもインターネットを介した電子投票が実施されている。またインターネット投票の危険性として指摘されている投票の強要や買収に対する「安全弁」として、一度電子投票を行った場合でも、投票日の4日前までであれば、投票を変更することも可能となっている。2015年の選挙（投票率：64.2%）では、電子投票で投票した有権者の割合は、投票者の約34%であった。
アメリカ
1974年に最初の直接記録電子投票機（DRE）が採用され，2000年アメリカ合衆国大統領選挙においてそれまで主流だったパンチカード方式による集計誤りが大きな問題となったことから電子投票の普及が大きく進んだが、電子記録は改ざんやハッキングの危険性があることから、2020年アメリカ合衆国大統領選挙においても24%の自治体が採用するに留まる。
インド
1982年のケーララ州選挙以来、国内で設計・製造された電子投票機「EVM」が全土で使用されている。他国の電子投票機とは異なりディスプレイやタッチパネルは使用せず、投票ユニットに表記された候補者および、政党のシンボルマークの横にある物理ボタンを押すことで投票を行う。シンボルマークは非識字者への配慮である。
電子投票機はスタンドアロンのためネットワークを必要とせず、また、アルカリ乾電池によって稼働するため電源も不要となっている。投票内容は投票ユニットにケーブルで接続されたコントロールユニットに電子的に記録されるほか、VVPATによるバックパックが行われる。投票期間は39日間、100万ヶ所の投票所に設置される電子投票機の台数は400万台に及ぶが、開票は1日で終了する。また、選挙区ごとに5台の電子投票機（全体の１～２%）においてVVPATとの照合が行われる。
⇧「セキュリティ」的な観点から、実現が難しいということですかね...
「インド」のように「ネットワーク」を介さない方式なら「セキュリティ」的なリスクは軽減できるかもですが、端末を用意するのが大変そう...
ただ、日本の場合、
⇧ 上記の統計の推移が正しいとするならば、「投票所」の数が「5万ヶ所」ほどになりそうなので、「インド」の「投票所」の数が「100万ヶ所」であることを思えば、導入できなくもない気がする。
1か所の「投票所」に10台の端末を用意したとしても50万台ほどなので、「インド」の400万台に比べれば、「コスト」は抑えられそう。
「改竄」されないことが担保できるならば、「デジタル化」した方が、集計の際のミスとかも無くせる気がしますしな。
実際問題、
⇧ 人手が絡んでくると、集計の正常性が担保できないのよな...
問題は、端末と端末で動作しているソフトウェアが故障した場合でも、「投票内容」が保持されることが担保できるかですかね...
共通フレームとは
「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」の公開している情報によると、
エンタプライズ系事業/ライフサイクルプロセス
ソフトウェア開発に関係する人々が「同じ言葉で話す」ことができるようにする
ソフトウェア開発において、発注者、受注者などの利害関係者間での認識のズレや、取引（主として二者間契約）における作業項目、役割分担等が不明確で取引の適正化がされていない、などの問題が発生しています。
これらの問題の解決策の一つとして、ソフトウェアの構想から開発、運用、保守、廃棄に至るまでのライフサイクルを通じて必要な作業項目、役割等を包括的に規定した共通の枠組みを提供する「共通フレーム」を提供しています。「共通フレーム」はソフトウェアライフサイクルプロセスの国際規格である、 ISO/IEC 12207(JIS X0160)をベースに、日本独自のプロセスを追加したものです。
2013年3月4日に発行した共通フレーム2013は以前の版である「共通フレーム2007第2版」を大きく変更しリニューアルしたものです。
主な特徴として以下があります。
・ベースとなる国際規格をJIS X 0160:2012に変更
・要件定義プロセスに、要件定義の国際規格であるISO/IEC/IEEE 29148のエッセンスを導入
・運用・サービスとシステム開発の連携を考慮した、サービスブロセスの導入
・システム開発とソフトウェア開発の明確な分離
⇧ とあり、日本独自の「ソフトウェア開発」の「標準」のような役割を担っていそうではある。
共通フレームはすべての開発方法論に共通したものらしいが...
「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」の公開している情報によると、
■作成者は
ユーザ企業、ベンダ企業、IPA/SEC、大学、経済産業省からなる開発プロセス共有化部会（2007年10月当時）である。
■ソフトウェア開発方法論との関係は
⇧ とありますと。
「ソフトウェア開発」における「工程」についても、
⇧ 上記にあるように、統一するべきなのだが、実際の「開発プロジェクト」における「ソフトウェア開発」ではカオスな状態となっている...
ちなみに、
⇧ 上記サイト様では、「ソフトウェア開発」の全体の流れを整理してくれている。
とりあえず、
『ウォーターフォール、スパイラル、プロトタイプ、アジャイル系
すべての開発方法論に共通したもの。』
と謳っているのだから、「アジャイル開発」で「スクラム」の開発手法を採用している場合であっても、このあたりを整理すべきな気がするのよね...
ちなみに、
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明 - GIGAZINE
⇧ 上記のような調査結果が出たらしいのだが、然もありなん。
「スクラムガイド」とか見ても具体的な「指針」について言及されていないので、全てにおいて「ファジー」な状態で「開発」を進めることになるため、「開発」の「再現性」が担保できないのよね...
「共通認識」を「可視化」できていないと、「方針」についての「認識齟齬」が発生するので、「工程」と「タスク」は詳細にしておくべきな気がしますけどね...
特に「タスク」についても「工程」のように、「雛型」を定義してしまえば良い気がするんですがね...
「開発プロジェクト」によって「タスク」の過不足が発生するのであれば、「雛型」の定義に手を加えたものを「ドキュメント」として残して「可視化」しておけば、チーム内で「認識共有」ができて「方針」との「乖離」を抑止できると思いますし...
「タスク」の「透明性」を上げるためにも、「タスク」の「雛形」は欲しいところですな...
「開発」に注力させて欲しいのよね...
ちなみに、
感想
アジャイルで成功して名の知れている海外の企業は、そもそもが海外まで進出できるような上澄みなわけで、つまりは高い技術力を持った技術者の集団です。
アジャイルは、そのような連中が集まってこそ極めて高い生産力を発揮できる方法論であり、一般人にはとても扱いきれない技術なのかもしれません。
なにしろ、失敗したら「お前のアジャイルは真のアジャイルじゃない」ですからね。
同じものを見て、聞くことのできる真の仲間にしか真のアジャイルは使いこなせないのでしょう。
⇧ 上記サイト様で、『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』の元記事の「コメント」が紹介されていて、「アジャイル開発」で失敗した場合に、
という便利な言葉で片付けられるって、無責任の極み過ぎるのだが、全くもって「羨まけしからん」としか言いようがない。
とりあえず、「言った言わない」論争の問題もそうなのだが、余計な「工数」はかかるのだが「意図」が残るように「ドキュメント」化しておくのは大事ですな。
ちなみに、海外だと、
- 言ってないことを言ったことにされる
- 言ったことを言ってないことにされる
のようなことが平気で行われるようなので、自分の身を守るためにも「ドキュメント」化して誰もが何時でも認識できるように「可視化」しておくことは必須のような気がする...
「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」とかも「雛形」の「フォーマット」が定まっていないので、チーム内で方針を決める必要があるとは思いますが、「ソフトウェア開発」における「タスク」も同様になってくるのかしらね...
「タスク」がハッキリすれば、
- やるべきタスク
- やらなくてよいタスク
も整理できて「タスク」の「優先順位」とかもチーム内で「相談」しやすくなると思いますしな...
「作業分解構造（WBS：Work Breakdown Structure）」は、「スクラム」では不要と言われることが多いのだが、「作業分解構造（WBS：Work Breakdown Structure）」を用意するしかない気がするんよな...
「作業分解構造（WBS：Work Breakdown Structure）」が無いと「タスク」の抜け漏れが出てくるし、そもそも「スクラム」で代替の「可視化」の方法について言及されていないのよね...
「スクラム」は「透明性」を大事にと言う割には、実現方法については何も提示してくれないのよね...
「ウォーターフォール開発」における「開発ベンダー」依存よりも酷い状況になっている気がするのよね...
と言うのも、「スクラム」は「経験主義」という思想が強いので、「開発チーム」毎に独自色を認めてしまうと、「開発プロジェクト」の「開発チーム」の数だけ差異が生じるので、
組合せ爆発（くみあわせばくはつ、英: combinatorial explosion）は、計算機科学、応用数学、情報工学、人工知能などの分野では、解が組合せ（combination）的な条件で定義される離散最適化問題で、問題の大きさn に対して解の数が指数関数や階乗などのオーダーで急激に大きくなってしまうために、有限時間で解あるいは最適解を発見することが困難になることをいう。
⇧ のようなカオスな状況が生まれるわけだ。
つまり、組み合わせに影響する要因の数として、
「スクラム」の方がよりカオスな状況になりやすい気がする...
いずれの開発手法を導入するにしても「保守・運用」のことを考慮してくれていれば、文句はないのだが、全く考慮されていないのが実情な気がする...
ちなみに、「保守・運用」のことが考慮できていないことによる弊害については、
そもそもなぜそんな高い見積もりがでてしまうのか
純粋に300万円分の工数がかかる場合もあります。最大の理由は影響調査でしょう。この変更によってどのモジュールが影響を受けるのかをシステム全体にわたって調査するのです。そしてもう一つは改修後のシステムテストです。これも規模が大きくなるほど工数がかかります。つまり変更作業そのものは数時間で終わったとしても、その前後に大きな作業がある、という構造になっています。加えて、ドキュメントの保守やら関係部署への連絡やら操作教育やら、既存システムのデータ移行やらが入ってくると、300万円でも足りないかも知れません。
理由はわかった。では諦めるしかないのか？
もう一つの可能性は「調査を支える設計書の不在」です。または設計書はあるが信用できない場合です。設計書が大量の印刷物であれば読む気も起こりません。これがExcelであっても同じです。自由文章で書かれた設計書から影響分析を行うのは大変な労力です。
これらは大規模システム開発の古典的な課題であり、多くの開発者がかかわる以上、不可避なことと考えられていました。しかし本当に解決できないのでしょうか。
超高速開発、でやろうとしていること
この積年の課題に対してソフトウェア工学からの取り組みがなかったわけではありません。対策の一つはサブシステムごとの開発の前に、データ構造の設計を行う、いわゆる「データモデリング・ファースト」です。上の理屈から、データの重複を排除することができれば、おのずと保守工程は軽くなります。そしてもう一つは、設計書の標準化です。ここでいう標準化とは、ルールに基づいた設計書であれば影響分析を自動で行えるというレベルを指します。それをExcelだけで実現するのは難しく、設計書を管理する専用のソフトウェアの存在が求められます。
⇧ 上記サイト様がまとめてくださっています。
「大規模システム」の場合、見積もりが不可能な気がしてきますな...
「銀の弾丸」的なツールが存在しない以上、定期的に「リファクタリング」をして「変更容易性」を高めていかないと、手の施しようが無い状態になるということですな...
ちなみに、「マイクロサービス」化してしまえば、「アプリケーション」の「開発者」視点での「影響調査」は減るかもしれないのだが、
「運用保守性の罠」とは？
クラウドネイティブなシステムへのモダナイゼーションが完了し、無事に本番稼働を果たしたものの、システム状態が把握できない、障害時に原因究明に時間がかかる、問題解析・根本原因究明に必要な情報が得られない例が増えてきました。再発防止に向けた対策立案に必要な情報の迅速な入手が困難などの状態に陥ることを、「運用保守性の罠」と呼びます。
⇧ 上記サイト様によりますと、「障害発生時」の「原因調査」が煩雑になる可能性があるそうな。
「影響調査」、「原因調査」などのタスクは全て「AI」に丸投げしたいところなのですが、「幻覚（ハルシネーション）」の問題が解決されない限りは任せられないからなぁ...
とりあえず、
AIが高度なコードを生成するようになったことで、顧客管理ソフトウェアを手がけるSalesforceのCEOが「AI導入が成功したので今年はエンジニアを雇わない」と発言したり、半導体大手・NVIDIAのCEOが「AIがコードを書くのでもうプログラミングを学ぶ必要はない」と発言したりして物議を醸している一方、AIツール自身はユーザーにプログラミングを学ぶよう提言しています。
AIがすべてのプログラミングコードを生成するようになるので「コーディングを学ぶのは時間の無駄」とReplitのCEOが答える - GIGAZINE
AIによって置き換えられる人間の技能を巡るビジネスリーダーたちの議論に、知識のない人でもプロンプトを入れるだけでアプリを作れるAIを開発したスタートアップ・ReplitのCEOの発言が加わりました。
AIがすべてのプログラミングコードを生成するようになるので「コーディングを学ぶのは時間の無駄」とReplitのCEOが答える - GIGAZINE
生成AIの進化により人間の仕事がAIに置き換えられる事例が増えています。大手テクノロジー企業のMicrosoftでさえ、ソフトウェア製品のコードの30％がAIにより記述されていることを明かしています。しかし、すべてがいい方向に作用しているわけではないようで、2025年春に実施されたMETRの実験により、AIコーディングツールは人間の生産性を低下させていることが明らかになりました。
AIコーディングツールは生産性を19％も低下させているという調査結果、AI出力の評価・手直し・再出力などで無駄な時間が大量発生か - GIGAZINE
⇧ どうすれば「AI」に全てお任せできるのか教えて欲しいですな...
『「AIがコードを書くのでもうプログラミングを学ぶ必要はない」』に至った根拠を示して欲しいのよね...
「頭の中がお花畑」でもない限り、「AI」に全て任せることが不可能だということは誰でも理解できることだと思うので、何故に「プログラミング不要論」に至ったのか純粋に知りたいのよね...
全世界の「開発者」は、「影響調査」、「原因調査」などのタスクを全て「AI」に丸投げできることを「渇望」している気がするので、実現方法を教えて欲しいのよね...
我々は「超能力者（Esper）」では無いので、「可視化」されていない情報については、ファジーな情報を元に推測するしかなく、ファジーな情報を元に推測した結果、正解に辿り着くことはほぼ無いと言っても過言では無いと思われる。
語句
「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」は、
⇧ 上記のような整理をする前に、一般的な「ソフトウェア開発」における「工程」と「タスク」の整理をして欲しいのよね...
「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」の取り組みは「優先順位」付けができていない気がして致し方ない...
そもそも、
⇧ 上記のページで「ソフトウェア開発」という大前提について言及されていないのが謎過ぎるんだが...
とりあえず、
⇧ 上記の名言の通り、どんな「システム」であろうと「ソフトウェア」は必要だと思うのだが、「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」の提唱する「社会・産業のデジタル変革」においては、「ソフトウェア」は不要で「ソフトウェア開発」についての「アーキテクチャ設計」は不要ということなんだろうか？
「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」って、
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）は、日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）。所管官庁は経済産業省。
日本のソフトウェア分野における競争力の総合的な強化を図る。情報処理の促進に関する法律の一部を改正する法律（平成14年法律第144号）により、2004年（平成16年）1月5日に設立され、同法附則第2条第1項の規定により解散した、特別認可法人である情報処理振興事業協会（IPA）の業務等を承継した。
⇧ 上記の理念があると思うのだが、自分たちが公開している情報の棚卸をした方が良い気がしますな...
言い方が悪いかもしれないですが、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ 上記にある通り、適切な「情報」が公開されていないと「技術的負債」を量産するだけになる気がしますしな...
逆に言ったら、適切な「情報」が公開されていれば、「ソフトウェアエンジニア」も自ら学習して「自走」できるようになると思いますしな。
まぁ、頭の良い人たちの考えることはよく分からないのだけど、「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」は、
『日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）。』
と謳うのであれば、「エンジニア」が「自走」できるような仕組みを提供すべきな気がしますけどね...
ちなみに、「チャールズ・ブコウスキー」という「作家」の「作品」の中で、
Full quote: "An intellectual says a simple thing in a hard way; an artist says a hard thing in a simple way."
⇧ 上記の言葉が出てくるのだが、
■「チャールズ・ブコウスキー」という「作家」の「作品」で出てくる言葉
"An intellectual says a simple thing in a hard way; an artist says a hard thing in a simple way." "簡単なことを難しく言うのがインテリであり、難しいことを簡単に表現するのが芸術家。"
⇧ どんな意図を含んでの言葉だったのかは分からないのだが、せっかく「情報」を「共有」するのであれば、誰もが分かり易いようにする方が良い気はする。
マインドの持ちような気もするが、
⇧ 上記の気持ちが無い人たちを皮肉った言葉なのかしらね...
統計が無いから分からないが、
マウンティングとは、人間同士の会話で相手よりも優位だと示そうとする言動や態度。マウントを取る。
当初の定義としては女性同士での上から目線の助言などだが、はっきりとした地位や資産、学歴やキャリア、魅力のような、とりわけ露骨なアピールは、不安などからくる問題行動だとして論じられることが多い。
対処法
マウンティングされた者はストレスを感じる。一方で、聞き手の方に劣等感があり、日常的な些細な会話やSNS投稿から、過剰に「マウンティングだ」と反応してしまうこともある。自分がある話題をマウンティングとして捉えてしまう場合には、社会的な評価基準と距離をとったり、話題を変えたりすることもできる。
⇧ 何となく「インテリ」の方が「マウントを取る」という行動をしがちなイメージという「バイアス」まみれな認識になってしまう...
まぁ、「難しいこと」を「簡単なこと」として説明するには労力がいりますしな...
例えば、スライド1枚の内容を伝えるために、スライド100枚作成する必要になるといったことが起こり得るわけなので...
とりあえず、
同じ業界のBtoBのお客さまならば共通言語があるのでしょうが、BtoCビジネスで、相手が一般ユーザーなのであれば、
「このたび、ご迷惑をおかけしましたのは、私どもでご注文をお受けした際に、手違いがあったことが原因でした。」
と、小学生にも伝わるくらい噛み砕いた言葉を使うことです。
これは別に、相手を子ども扱いしろということが言いたいのではありません。
それくらいわかりやすい言葉を使うことで、相手にとっては「心地よさを覚える」ということです。
仕事ができる人は、なぜとっさに「小学生でもわかる言葉」で説明できるのか？ | 気づかいの壁 | ダイヤモンド・オンライン
あなたがよく使う「業界用語・専門用語・社内用語」は、あらかじめ小学生にも伝わる言葉に翻訳して組織内で共有しておくといいでしょう。
仕事ができる人は、なぜとっさに「小学生でもわかる言葉」で説明できるのか？ | 気づかいの壁 | ダイヤモンド・オンライン
⇧ 上記サイト様にありますように、相手に伝わらないと意味が無いので、ドキュメントなどで略語を使用する際は、注釈などで正式名称を記載すべきですかね...
ちなみに、
⇧ 上記サイト様にありますように「エンジニア」は説明について端折る悪癖があることが多いらしいので誤解を生みやすいのだが、「略称」に対して説明しないことが多いのも、そういった悪癖が影響しているのかもしれませんな...
何となく、「エンジニア」って、
⇧ 自分たちが、「主語」を端折られた際に「認識齟齬」を引き起こす可能性があることが分かっていても、「略称」について「説明」が無いと「認識齟齬」が起きる可能性があるということを考慮できないの謎過ぎるのよね...
面倒くさいかもしれないのだけど、説明を端折ることのメリットよりデメリットの方が大きい気がするので、説明を端折るの止めて欲しいのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
