News2olds:知新 → 温故

一覧 
  *** 月刊(?)ウェブログ風の寸評 ***   →古いブログ(2016.4〜2005.2)

 2019.12 二つの文化:自然科学と人文科学
 2019.12 狂言師は型をプログラミング
 2019.12 失敗したe-Japan戦略
 2019.12 日本の15歳の読解力が世界で15位に後退

 2019.11 人生100年を支えるデジタルツインとIntelligent Clone
 2019.11 文部科学大臣の身の丈発言と教育の機会均等
 2019.10 続:利用されない行政システムの開発がなくならない
 2019.9 職場でのチャットの利用が増えている
 
 2019.8 「IT事件史(1990年):Σ計画失敗が判明」を読んで
 2019.7 「最強囲碁AI アルファ碁解体新書」を読んで
 2019.6 プログラミング心得の普遍性
 2019.6 (続)初任給に格差 → 優秀なIT・AI人材の確保
 2019.5 改元と『考えることを考える』を考える
 
 2019.4 利用されない行政システムの開発がなくならない
 2019.4 AI人材・IT人材不足数の予測について
 2019.3 ミンスキーの心の6階層モデルについて
 2019.3 航空機墜落事故2件は、またもソフトウェア不良が原因か
 2019.1 AIシステム検証へのニューロンカバレッジの有用性について

 2018.12 情報処理技術遺産 構造化プログラミング言語SPL 認定(後日談)
 2018.12 経団連の就活ルール廃止表明と政府案に一言
 2018.11 「AIと美学・芸術」特集を読んで
 2018.10 幼児の自己中心言語と内言の関係
 2018.10 「孤独の発明 または言語の政治学」を読んで

 2018.9 「IT事件史(1992年):IBM一強時代が終焉 オープン勢台頭」を読んで
 2018.8 働き方改革で26年前の電子技術者の問題は解決している?
 2018.8 3銀行の合併初日に3つのシステム障害とは
 2018.8 「IT事件史(2005年):誤発注で損失400億 責任めぐり10年裁判」を読んで
 2018.7 「IT事件史(2011年):みずほ「悪夢」再び 震災で混乱」を読んで
 2018.7 「意識とメタ過程」特集を読んで

 2018.7 「物理学とAI」特集を読んで
 2018.6 「IT事件史 1999年:「Y2K」の緊張走る」を読んで
 2018.6 「IT事件史(2002年):みずほ銀が大規模システム障害」を読んで
 2018.6 差別発言をしたチャットボットTay(2年前)への追加コメント
 2018.6 情報処理技術遺産 構造化プログラミング言語SPL 認定

 2018.5 解説「子どものコモンセンス知識」でヴィゴツキーが引用されている
 2018.5 「国交省のチェックツールに不具合」を読んで
 2018.5 人材の不足と育成:今日のAIと80年代のIT
 2018.4 機械学習工学とソフトウェア工学の共通点と相違点
 2018.4 「IT事件史 1982年のIBM産業スパイ事件」を読んで
 2018.4 「サボリのススメ」を読んで

 2018.3 システム開発プロジェクトの成功率が10年前より上昇!
 2018.2 東大病院の電子カルテシステムでトラブルの原因は?
 2018.2 仮想通貨をゼロ円で売買したシステムの不具合とは?
 2018.1 「サービス設計12箇条」を読んで
 2018.1 「AIは哲学できるか」を読んで
 2018.1 「新春大予測 20の技術が変える未来」特集を読んで

 2017.12  「脳情報科学が拓くAIとICT」特集を読んで
 2017.12  「脳科学とAI のフロンティア」特集を読んで
 2017.10  大手メーカーの出荷前の品質検査の不正
 2017.10  システム開発失敗の責任は発注側にありとの逆転判決
 2017.9  衛星「ひとみ」のプログラムミスの道義的責任で5億円とは?
 2017.9  総務省のAI開発ガイドラインは有用?

 2017.8  共産党批判でサービス停止のチャットボットの再教育とは?
 2017.7  東電システム障害の真相が明らかに?
 2017.6  情報処理技術遺産 Fortran&HARP 認定
 2017.6  「展示会で,学生お断り」の変更
 2017.5  日本臓器移植ネットワークのプログラムミスとは

 2016.12 番外編:メルボルン訪問2016→1980→1956
 2016.11 1枚のカードからATMシステム停止となったプログラムミスとは
 2016.10 「受援力」強化にはIT活用が不可欠!
 2016.9 アクティブ・ラーニングは「議論自由」のこと?
 2016.9 大人の脳(海馬)の新生ニューロンが記憶力を左右する

 2016.9 番外編:チャスラフスカの逝去を悼む
 2016.8 人工知能60周年における第1次,第2次ブームでは
 2016.6 利息計算を手作業で10年以上実施してきたシステムとは?
 2016.5 新幹線の電光掲示板故障の本当の原因は?
 2016.5 衛星「ひとみ」がプログラムのミスで運用断念とは残念!

             →以前のブログ(2016.4〜2005.2)


2019.12
二つの文化:自然科学と人文科学


 朝日の記事(2019.12.12):
 ≪ 科学振興、「人文科学」と共に 基本法の対象広げる改正案、来年国会提出へ ≫

 を読んで、学生時代の英語の授業のテキスト(2件)で学んだキーワード
 “Two Cultures”を思い出した。
 
 ■記事の概要:
 ・現在の科学技術基本法は、「人文科学のみに係るものを除く」と規定しているが、
  現代社会の課題を解決していくには人文科学の研究も不可欠になっているので、
  この規定を削除する予定
 
 ■50年以上も前の大学1,2年(1965〜1966)の英語の授業のテキスト2件
 
 ●”Literature and Science(文学と自然科学)” Aldous Huxley 著
  興文社(1964.2.10 初版、1965.4.15 再版 190円)
 
 <日本語のはしがき(注釈者:由良君美)抜粋>
 『≪二つの文化≫の論争は、もともと、17世紀の科学革命を皮切りとして、
  西欧世界に提起された根深い問題であり、さらに19世紀産業革命によって
  その現実性を強められ、さらに現在の第2次産業革命によってさらに
  その緊急の解決を迫られるに至った歴史課題といわなければならない』
 
 ●”The Two Cultures”   Charles P. Snow 著
   From “Seven Choice Essays ?Literary, Scientific and Political-“
   南雲堂(1966.10.10 200円)
 
 <日本語のはしがき(注釈者:多田幸蔵)抜粋>
 『文人はもっと科学の重要性を認識し、科学を知らねばならぬ。
  科学と人文という二つの文化がばらばらなのは危険だ、教育上の改革が必要だ』
 
 【コメント】
  ★これらの論点は、半世紀を経てさらに重要な課題となっている。
 
  →  【詳細別紙】
 
 以上


2019.12
狂言師は型をプログラミング


 以下の記事で、狂言師の野村萬斎が、能舞台での演技を
 型のプログラミングにたとえていることに興味を持った。
 
 2019.12.14の朝日の記事: 「ロボットと生きていく 朝日教育会議」
 
 ・講演タイトルの「型をプログラミング」とは、
  ソフトウェア開発における、外部仕様に対応する内部仕様の設計と解釈できる。
 
 (注)以下、『・・・』は記事からの引用部分
 
 ・『能や狂言に携わる者は、この能舞台で人や神、動物を演じます』
  『そのための方法論やルールとして「型」というものを使っています』
  『小さいころから、プログラミングするように型を教え込まれた』
 
  →能舞台での狂言の型は、観客から見えている演技に対応し、
   ソフトウェアにおける外部仕様に相当する。型を教わるとは、
   ソフトウェアにおける内部仕様(プログラム)を教わることに対応する。
 
 ・『狂言師は「狂言サイボーグ」とも言えます』
 
  →狂言師・能役者は、これらの型を表現して演技を実演するので、
   コンピュータが内部仕様を実行して外部仕様を実現するのと同じに見える。
   そこで、野村萬斎は狂言師を「狂言サイボーグ」と言っている。

 ・『舞台に立つにも型があります』
  『物を着ていると全く分からないと思いますが、実際には
   ひざを前に折り、腰を引き、胸を張り、そしてひじを後ろに張っている』
  『全ての体のパーツに意識を持つと、この舞台上できれいに見える』
 
  →まさに、外部仕様に対応する内部仕様を実行している。
   『全ての体のパーツに意識を持つ』とは、
   複数のプログラムを実行しているので、並行プログラミングに対応する
 
 ・『そこで不可欠なのが、舞台を囲む4本の柱です』
  『 「柱が消えてから4歩」「見えてから2歩」というようにプログラミングがされている』
  『そうした「型」をデジタル的にインプットする』
 
  →ソフトウェア技術としては、手続き的プログラミングで、型を実装している
 
 ・『喜怒哀楽も型でデジタルに表現する』
  『泣いている様を、手で涙を受けるしぐさで表しますが、
   師匠は手の角度と位置をとてもやかましく言う』
  『手の使い方を間違えると、鼻をすすっているように見えたり、
   頭が痛いように見えたりしてしまう』
 
  →外部仕様に対応する内部仕様のミスがソフトウェアのバグになるのと同じ
 
 ・『狂言の笑う表現をやってみますよ。「はあ、はっ、はっ、はっ、はっ……」 』
  『横隔膜をバウンドさせながら自然に空気を入れ、循環呼吸のようにする』
 
  →外部仕様に対応する内部仕様の手続き的プログラミングに相当
 
 ・『感情的な演技をするのではなく、小さな感情を型を通して表現すると、
   ほどよく品良く見えてきます』
 
  →プログラミングの粒度が小さいほうがよいということ、すなわち、
   宣言的なプログラミングよりも手続き的なプログラミングのほうが
   きめ細かいふるまいに対応するということかな
 
 (余談)
  下記の拙著の「あとがき」に記載した生け花パラダイム論では、
  生け花のいくつかの型を異なるプログラミングパラダイムに対応付けている。
 
 拙著:ソフトウェア危機とプログラミングパラダイム、啓学出版 (Aug. 1992)
  →  参照<あとがき p.236-237>
 
 以上


2019.12
失敗したe-Japan戦略


 2019.12.9の日経の記事
  「18年後の惨状を完璧に予言したのに失敗したe-Japan戦略、DXも二の舞いだぞ」
 が目に留まった。 
 
 【概要・抜粋】
 ・2001年に始まった政府主導の「e-Japan戦略」は失敗に終わり、
  「現在の遅れが将来取り返しのつかない競争力格差を生み出す」という
  当時の恐れが、18年後に現実になってしまった。
 ・現在注目されている「デジタル変革」(DX:Digital transformation)を
  e-Japan戦略の「T革命」に置き換えると全く同じ状況なので心配。
 ・企業がDXを推進するには、とにもかくにも経営のリーダーシップが必要。
  国の政策でも全く同様で、政治の強いリーダーシップが不可欠で、
  それがないと世界最先端デジタル国家創造宣言も将来、笑い物になる。
 
 【e-Japan戦略に関連する過去の記述】
 
 e-Japan戦略については、
 拙著「ソフトウェア工学」(2004年、2014年)に記載してきたほか、
 私の電子申請システムの研究に関する学会発表の論文(2003年、2010年)の中でも、
 批判的に言及してきた。
  →  【詳細は別紙】
 
 ■関連する学会発表(2003年、2010年)
 ●中所武司、他:電子自治体向けフォームベースシステムと検索・記入・提出用
  ポータルサイトの構築法、情報処理学会 第65回全国大会 特別トラック(10)
  「e-Japanの進展」講演論文集分冊5、pp.5575-5578(Mar. 2003)
   →  詳細
 ●中所武司「システムの利用率は要求分析の対象では?」情報処理学会
  ウィンターワークショップ2010・イン・倉敷 論文集、シンポジウムシリーズ
   Vol.2010, No.3, pp.39-40(Jan.2010)
   →  詳細
 
 ■関連ブログ(2006年、2009年)
 ●2009.11【いつまで繰り返す電子政府の電子申請システムの無駄】  →  詳細
 ●2006.4 【e-Japan戦略からIT新改革戦略へ】  →  詳細
 
 以上


2019.12
日本の15歳の読解力が世界で15位に後退


 日経の記事 『日本の15歳「読解力」15位に後退 デジタル活用進まず』 (2019/12/3)によると
 ・OECDは、世界79カ国・地域の15歳約60万人の生徒を対象に
  2018年に行った学習到達度調査(PISA)の結果を公表
 ・日本は「読解力」が15位となり、2015年調査の8位から後退
 ・文科省によると、日本は内容を理解する力は高かったが、
  根拠を示して自分の考えを説明する問題が低迷した
 
 さらに、朝日の社説 『国際学力調査 自分の考え育む授業を』 (2019/12/4)によると
 ・内容や筆者の考えを吟味する「評価・熟考」型の問いに手を焼く傾向があり、
  平均正答率を10ポイント超下回った設問14題中の9題がこの類型だった
 
 【コメント】
 
 ・「アクティブ・ラーニング」が効果を上げていないのでは?
  (参考:過去のブログ)
   2016.9  「アクティブ・ラーニングは「議論自由」のこと?」
 
 ・当研究室では、 『議論自由』 をモットーとしてきた。要点は以下の通り:
 【要するに】
  ★自分の意見を持つ
  ・自分の意見を論理的に述べる
  ・他人の意見を理解する
  ・他人の意見にコメントする
 
 以上


2019.11
人生100年を支えるデジタルツインとIntelligent Clone


 2019.11.5のNHKテレビ「くらし☆解説」の次の番組が目に留まった。
  「人生100年を支えるデジタルツイン もう1人の自分」
 【概要・抜粋】
 ・デジタルツインは、最近、産業界で使われている用語で、
  大規模な工場や複雑な生産ラインをコンピュータの中に再現して、
  事故や故障の未然防止や生産効率向上をはかるシミュレーション技法
 ・この番組では、AI技術を用いてコンピュータ内に自分のコピーを作り、
  このようなデジタルツインを「subME=もう一人の自分」と呼び、
  一人暮らしの高齢者の支援に利用する研究開発を紹介
 ・想定する利用の3段階
  →元気な時:日々の話し相手
  →やや弱ったとき:助言、励まし
  →弱ったとき:代理人のような働き(自分の意思を伝える)
 
 【当研究室での類似の研究】
 ・上記の第3段階の代理人の機能は、当研究室の
  インテリジェントクローン(IC : Intelligent Clone)の研究と似ている。
 ・研究室のテーマとしては 1998年度の卒業研究 から開始しているが、
  その概念は、 1992年発行の拙著 で述べている。
 ・ネーミングについては、著書の中では、次のように記載した:
 『究極のプログラミングパラダイムによって作られる究極のソフトウェアを
  「自分がやりたいことをやってくれる」 知的なクローン(Intelligent Clone)
  という意味で,インテリクローンまたは ソフトウェアクロ−ンと呼ぶ』

 
  →  詳細別紙
 
 以上


2019.11
文部科学大臣の身の丈発言と教育の機会均等


 10/24放送のテレビ番組での、文部科学大臣の発言が物議をかもしている。
 2020年度から予定されていた大学入学共通テストでの英語の民間試験について、
 司会者が、お金や地理的な条件により受験生の受ける回数が異なると、
 公平性に問題がないか、と質問したのに対して、
 文部科学大臣は、そのようなことがあるかもしれないが、そこは
 自分の身の丈に合わせて2回をきちんと選んで勝負してがんばってもらえば、
 と答えた。
 
 そこで、教育の機会均等について、1965年の受験生として、50年前の話をしたい。
 当時の大学進学に関する機会均等は、以下の三点で支援されていたと思う。
 
 【奨学金】
  特別奨学金8000円/月。3000円は貸与(無利子)、5000円は返還不要。
  高3の秋には決定済みだった。
 
 【授業料免除】
  国立大学の場合、親の所得証明書を提出すると
  授業料(1000円/月)が免除された。
 
 【学生寮】
  寮費:100円/月 (6人部屋)
  食費:115円/日(朝・昼・夕:25円・45円・45円)
  <関連ページ>
 
 当時、8000円/月の奨学金だけで生活する寮生もいたが、
 週2回・2時間の家庭教師のアルバイト(5000円/月程度)をする
 寮生が多かったと思う。
 
 そのころ、寮費を100円/月から300円/月に値上げする方針が
 出されたことがあったが、「教育の機会均等が失われる」と主張して
 結局、値上げ案は取り下げられたと思う。
 
 以上


2019.10
続:利用されない行政システムの開発がなくならない


 msnのニュースサイト 「18億円投入、使わず廃止…総務省サイバー対策」 (読売新聞 2019/10/08)の要約:
  ・総務省が約18億円をかけて導入したセキュリティーシステムが、
   一度も使われないまま今年3月に廃止された
  ・総務省は「ニーズの把握が不十分だった」としている
  ・各府省庁は機密情報を閲覧できるが、ダウンロードはできない仕組みで、
   保管データの出し入れや訂正には、職員が設置場所まで足を運ぶ必要あり
  ・年間3億6000万円程度の維持・管理費がかかる
 
 行政システムが利用されないむだづかいを過去にも指摘してきたが、なくならない。
 要求分析の段階でシステムの利用率を分析すべきと主張してきたが・・・

 一般にシステムの仕様の決定においては、利便性を重視するか、
 あるいは安全性を重視するかという、利便性と安全性のトレードオフの課題がある。
 利便性を重視しすぎて安全性の問題が生じるケースが多いが、
 今回のケースはその逆で、安全性重視のあまり、利便性が軽視されすぎた例といえよう。
 7月に発生したセブンイレブンの7payシステムへの不正アクセス事件は前者の例。
 
 【学会発表の例】
 ・ システムの利用率は要求分析の対象では?
  情報処理学会 ウィンターワークショップ2010・イン・倉敷 論文集、pp.39-40(Jan. 2010)
 
 ・ End-User-Initiative Approach for Truly Useful e-Government Systems,
 the IADIS e-Sosiety 2010 Conference, pp.123-130 (Mar. 2010).
 
 (注)2006.8.31に停止されたパスポート電子申請システムに言及。
    2004に開始して以降に発行された133件で開発コストを割ると、
    1件当たり、10万ドル超になる。
 
 【過去のブログ】
 ・2009.11  いつまで繰り返す電子政府の電子申請システムの無駄
 
 ・2010.7  新たな情報通信技術戦略は国民本位の電子行政を実現する?
 
 ・2015.9  メタボ検診: システムのミスで十分活用できず
 
 ・2015.10  防災システムのブラウザ依存の不具合を2年間放置
 
 ・2019.4  利用されない行政システムの開発がなくならない
 
 以上


2019.9
職場でのチャットの利用が増えている


 朝日新聞の記事(2019.9.27)
 「職場、メールよりチャット?  働き方改革追い風、・・・」によると、
 ・仕事のコミュニケーション手段として、「チャット」の利用が増えている。
 ・ビジネスチャットはメールより手軽で、素早いやりとりに向いている。
 ・総務省の2018年の調査では、国内での利用者の割合は24%。
  米国(67%)や英国(56%)を大きく下回った。
 
 チャットの歴史は古く、インスタントメッセージの技術も新しいものではない。
 私の明治大学ソフトウェア工学研究室時代の研究は以下の通り:
 <23年前の懐古趣味:実際に私の研究室とゼミ生の実験室の間で利用 (^^;; >
 
 【1995.11】
    ゼミ室実用版への要求メモ(仮想サロン、雑談アプレット)
 
 【1996.9】
  ゼミの3年生が春休みにアプリを開発し、学会発表。
   「分散環境における簡易対話ツールV-Saloon(仮想サロン)の開発と適用評価」
  情報処理学会第53回大会講演論文集(4), 2p-2
 
 【1996.11】
  日経コンピュータ1996.11.25号pp.188-189に掲載される
    − 表題:「テクノロジーの宝庫」仮想サロンでおしゃべり − 
 
 【研究概要のホームページ】
    V-Saloon:仮想サロン(アウェアネス・ツール)
  分散環境下での簡易対話ツールV-Saloon(仮想サロン)を
  JavaとHORBを用いて開発した。
 
  The V-Saloon project → 簡単操作のインスタントメッセンジャー
 
 以上


2019.8
「IT事件史(1990年):Σ計画失敗が判明」を読んで


 日経BPの記事(2019.8.21) 
   「Σ計画」失敗が判明した1990年、DOS/Vがひっそり誕生」
 
 【記事概要】
 ・通商産業省が1985年から5年計画で進めていた国家プロジェクト
  「ソフトウェア生産工業化システム構築計画」(250億円の予算)が
  主な成果を出せずに1990年に終わった
 ・このΣ計画は、「1990年には大量のプログラマーが不足し、
  深刻なソフトウェア危機が到来する」との1984年の予測を受けて、
  ソフトウェアの設計からテストまでの開発工程の機械化が目標だった
 ・国内大手ベンダーやユーザ企業の約200社が参加
  
 【ソフトウェア工学の視点でのコメント】
 
 ・1980年代は、増大するアプリケーション開発要求が大きな課題となり、
  その解決策としての先進的なソフトウェア開発環境が必要とされた。
  
 ・1991年の私の以下の情報処理学会の解説論文にも、関連する記述がある。
     「エンドユ−ザコンピュ−ティング −ソフトウェア危機回避のシナリオ−」
     (情報処理, pp.950-960、1991.8)
  
 2章「ソフトウェアの問題」の2.1節「ソフトウェア危機の歴史」の
 「(2)1980年代−量の問題」において、以下の記述あり:
 
 『計算機システムの普及とともに、開発すべきソフトウェアの量が増大し、
  情報処理技術者の不足が第二のソフトウェア危機をもたらした。』
 
 『通産省では、1990年には情報処理技術者が60万人不足(需要:160万人、
  供給:100万人)という推定に基づき、1985年にはΣプロジェクトを発足した。』
  
  →  詳細別紙
 
 以上


2019.7
「最強囲碁AI アルファ碁解体新書」を読んで


 プロ棋士よりも強くなったアルファ碁(コンピュータ囲碁プログラム)について、
 画像認識に効果的なディープラーニング(深層学習)の技術を適用との説明に、
 画像認識と囲碁の盤面認識とは似て非なるものなので、疑問に思っていた。
 
 画像認識では、類似の画像を同じカテゴリと判断できるが、
 囲碁では、一路ずれると状況は大きく異なる場合が多いので、
 類似の盤面で同じ出力でよい、とはいえない。
 
 最近、以下の著書を読み、疑問が解けた。
 ・大槻知史:「最強囲碁AI アルファ碁解体新書」、翔泳社、2017.
 
 以下のような、囲碁に固有の処理に納得:
 
 ・次の一手を出力するための入力である19*19の各位置情報には、
  48種類の情報を伴っている。
   (例)黒石の位置、白石の位置、石の取れる位置、シチョウ、・・・
 
 ・400万個もあるフィルタ重みパラメータを学習するには
  大量の高品質な学習データ(入力局面と正解ラベルの組)が必要
 
 ・自己対戦により、方策勾配法による以下の強化学習を実施:
   #勝ったとき、同じ手をできるだけ選ぶようにパラメータ更新
   #負けたとき、同じ手をできるだけ避けるようにパラメータ更新
 
 ・モンテカルロ木探索の結果をもとに次の一手を選択する手法も併用
 
 → <詳細別紙:個人的メモ>
 
 以上


2019.6
プログラミング心得の普遍性


 情報処理学会の学会誌「情報処理」の2019年6月号の特集
 (情報処理, Vol.60, No.6, pp.484-524)
 「フレッシュマンに向けたプログラミングのススメ」の感想:
  ★半世紀近くの間にプログラミングスタイルは大きく変わったと思うが、
   本特集を読むと、プログラミングの一般的な心得には普遍性がある。
 
 【10件の解説論文の主要なキーワード抜粋】
  ・理解容易性、変更容易性、テスト容易性が重要
  ・模範となるソースコードを読んで学ぶ
  ・プログラムに用いる種々の名前の付け方が理解容易性に影響
  ・実行環境への依存性を避け、移行性を確保
  ・短い時間で効率よくソフトウェアを開発
  ・記述対象を抽象化・階層化した疎結合な設計で再利用性を確保
  ・抽象度の高い解決方法を考え、広範囲に適用
  ・複数のプログラミングパラダイムの習得が技術者の成長の鍵
  ・一つの技術を極めることで新しいチャレンジに対応できる
  ・ソフトウェア開発のノウハウは他の分野にも有用
 
 【35年前の自作の社内教育資料】
    → 懐古趣味にて、 別紙参照:「プログラミング心得」(1984.8)
 
 以上


2019.6
(続)初任給に格差 → 優秀なIT・AI人材の確保


 2019.6.4の朝日の記事「高給で争奪戦、求む優秀新卒」で、
 ソニーの初任給に関する部分の要約:
 (1) プログラミング言語を使うAIなどの分野で、新たなサービスを開発できる
   人材採用のため、一部の新入社員の年収を、能力に応じて、
   最高で730万円(現在の3割増)とする。
 (2) プログラミングが堪能な新入社員を、入社後の仕事内容や評価に応じて
   「主任クラス」の等級に抜擢する。
 
 「初任給に格差」に関する記事を12年ぶりにブログで取り上げる。
 私の考えは、30年近く前に、情報処理学会の 解説論文(1991.8)に記載したように、
 ソフトウェア危機回避のシナリオの一つとして、
 「優秀な情報処理技術者の高収入は保証される」時代を予測したが、
 今がその時か!?
 
 【過去の関連ブログ】
 
 2007.7「(続々)初任給に格差 → イノベーション」
  日本経団連の御手洗会長は、学生を成績や論文で評価し、
 入社から給料に格差をつける仕組みの導入を提案した。
 
 2006.5「(続)初任給にスキルによる給与格差 → 大学改革」
  某IT企業は、入社時のスキルや知識が高いと判断した2名の年収を
 上乗せ(150万円、125万円)した。
  →→→ 月給20万円と30万円の差は大きい。
  情報系の学生の向学心に火が付けば、大学の授業がおもしろくなる!
  
 2006.1「初任給にスキルによる給与格差」
  某IT企業は、入社時の評価試験で一定のスキルを有すると判断した場合、
 月3万円〜5万円を月収に上乗せする。
  かつて、情報処理学会の解説論文(1991.8)に記載した内容が
 やっと現実になるかもしれない。情報系の学生の向学心にも火が付くかも。
 
 以上


2019.5
改元と『考えることを考える』を考える


 平成最後の日から令和元年にかけて、マスコミでは、
 平成時代の歴史的評価や令和時代への期待が語られている。
 
 たまたま、50年近く前の私の思考モデルに関する学会発表で用いた
 「考えることを考える」という表現と同じタイトルの谷川俊太郎の
  下記のエッセイを4月に見つけたが、その内容は、最近の改元に伴って
  過去(平成)と未来(令和)を考えることにも関連する。
 
 ●谷川俊太郎:「考えることを考える」、日本の名随筆 別巻76、p.11-p.15(1997)
 
 <要約的抜粋>
 ・ものを考える時、人間はいつもどこかからどこかへ向かって考える。
 ・<どこかから>は過去へと開かれ、<どこかへ>は未来へと開かれ、
  その未来へのイメージが、数千年の人間の歴史に例を見ぬような
  変化を強いられつつあるのが、二十世紀後半の現状である。
 
 ・個人の死を前提として考えることはできても、
  人間は人類の自滅を前提として考えることはできないと思う。
  どう考えるか、何を考えるかより先に、考える行為そのものが危機に瀕している。
  我々はいわば、過去からも未来からも疎外された今日に生きているのだ。
  そんな今日は、考えることをやめた人間には、結構住みいいらしいが。
 
 <コメント>
 ・このまま思考停止が続けば、人類は自滅する、という警告かな。
 
 ・私の修論での思考モデルとの関連については → <別紙参照>
 
 以上


2019.4
利用されない行政システムの開発がなくならない


 朝日の記事「整備80億円、利用率0.1% マイナンバー連携、ハローワークのサーバー」の要約:
 ・マイナンバー制度とハローワークの事業をつなぐ「中間サーバー」を厚労省が
  約80億円かけて整備したが、利用率が最大想定の0.1%にとどまっている。
 ・年間約10億円の維持管理費が、2017、18年度に続いて19年度予算にも計上されている。
 ・本サーバーは、各地のハローワークと自治体が相互に情報を照会することを可能にしている。
 ・今年1月までの利用は月平均2580件(最大想定の0.08%)
 
 ★新規開発の行政システムが利用されないという無駄がなくならない。

 この問題は、過去に何度も指摘してきた。(以下参照)
 
 【学会発表の例】
 ・ システムの利用率は要求分析の対象では?
  情報処理学会 ウィンターワークショップ2010・イン・倉敷 論文集、pp.39-40(Jan. 2010)
 
 ・ End-User-Initiative Approach for Truly Useful e-Government Systems,
  the IADIS e-Sosiety 2010 Conference, pp.123-130 (Mar. 2010).
 
 (注)2006.8.31に停止されたパスポート電子申請システムに言及。
    2004に開始して以降に発行された133件で開発コストを割ると、
    1件当たり、10万ドル(1,000万円)超になる。
 
 【過去のブログ】
 ・2009.11  いつまで繰り返す電子政府の電子申請システムの無駄
 
 ・2010.7  新たな情報通信技術戦略は国民本位の電子行政を実現する?
 
 ・2015.9  メタボ検診: システムのミスで十分活用できず
 
 ・2015.10  防災システムのブラウザ依存の不具合を2年間放置
 
 以上


2019.4
AI人材・IT人材不足数の予測について


 3/30の日経電子版「AI人材の育成、教員確保が壁 『年25万人』政府戦略」の記事で
 3/29の政府・官邸の統合イノベーション戦略推進会議の資料内容に言及あり。
 人工知能(AI)を使いこなす人材を年間25万人育成する戦略案の人数の内訳は、
 4年制大学の理工系12万人と保健系6万人と文系42万人中の7万人を加えた数字。
 
 この記事に掲載されている「AI人材の不足が深刻化している」とするグラフは、
 経済産業省の「IT人材の最新動向と将来推計に関する調査」(2016.6)の引用。
 (予測例)
  2020年 IT人材必要数 122万人 供給数 92万人 不足数 29万人
            (AI等先端IT内数 供給数 13万人 不足数 5万人)
  2030年 IT人材必要数 144万人 供給数 86万人 不足数 59万人
 
 (参考)過去の情報処理技術者の受給予測(当時の通産省)の記憶がよみがえる。
     さて、その的中率は?
  ・1984年の予測:1990年に,60万人不足(需要:160万人,供給:100万人)
  ・1987年の予測:2000年に,97万人不足(需要:215万人,供給:118万人)
  ・1992年の予測:2000年に,54万人不足(需要:194万人,供給:140万人)
 (出典:拙著)
   中所「ソフトウェア工学」(初版1997、第2版2004)朝倉書店
      *第2章「ソフトウェア危機の歴史」から引用
 (過去の関連ブログ)
    2018.5 人材の不足と育成:今日のAIと80年代のIT    【別紙】
 以上


2019.3
ミンスキーの心の6階層モデルについて


 情報処理学会誌「情報処理」の2019年4月号の以下の解説:
 「私のオススメ:ミンスキー博士の脳の探索 -常識・感情・自己とは-」
 (情報処理, Vol.60, No.4, pp.350-351)
 
  本解説によると、ミンスキーは、心の6階層モデルを説明するために、
 道路を横断するときの思考を例として取り上げられているとのことで、
 私が修論で用いた「研究室に電話がかかってきたときの思考プロセス」の例を
 このモデルにあてはめて考察してみることにした。
 
 なお、ミンスキーについては、3年前の以下のブログでも言及している。
  (リンク先)→  2016.3 番外編:Marvin Minsky の逝去を悼む
 
 【心の6階層モデルとは】
  幼児からの段階的成長の結果、人間の心は以下の6つの階層に体系化された。
 1層目:本能的反応
 2層目:学習反応
 3層目:熟考
 4層目:内省的思考
 5層目:自己内省的思考
 6層目:自意識に対する感情
 
 【考察結果の要約】
 下位3階層はルール的な説明が可能であるが、
 上位3階層は複雑なメタルールの導入、あるいは
 言語機能の階層化モデルが必要になるかもしれない。
 
    →  【詳細別紙】

 以上


2019.3
航空機墜落事故2件は、またもソフトウェア不良が原因か

【内容】
 ・2018.10.29のインドネシアでの航空機墜落事故で189人全員死亡
 ・2019.3.10のエチオピアでの航空機墜落事故で157人全員死亡
 ・いずれも離陸直後の事故で、同じ機種だった。
 ・最初の事故の初期調査では、自動操縦のソフトウェアの誤作動により、
  失速を防ぐために機首を下げようとしたため、パイロットは手動で
  機首を上げようとしたが、機体は上昇と下降を繰り返し墜落したとみられる。

【コメント】
★1994年に名古屋空港に着陸しようとした中華航空機が墜落し、
 264人が死亡した教訓が生かされていない。このときも、
 自動操縦と手動操縦が相反する状態で失速し、墜落した。

★なぜ、自動操縦と手動操縦が同時に可能な設計を今も続けているのか?

★本件については、何度も以下のブログで指摘している:

2015.11 「オートメーションサプライズ」について

2011.6 あわや航空機事故(またもや,自動操縦と手動操縦の対立が原因)

2009.2 中華航空機事故(264人死亡)の教訓は生かされなかった?

2008.3 中華航空機墜落事故のエアバス社の製造物責任を認めず(名古屋高裁)

★本件については、1996年のソフトウェア工学演習でも、
 電子ディベート課題としても取り上げている。

・ 1996.10 ソフトウェア工学の授業での電子ディベート:
   「中華航空機事故におけるソフトウェア開発者の責任の有無」について

<参考資料>
 本ブログは、2019.3.17時点の下記のページ参照:
昨年事故と類似、注目 飛行ソフト改修遅れ、背景に米政府閉鎖? B737MAX
737MAXの問題点、パイロットは墜落事故の数カ月前に当局に指摘していた
ライオン・エア610便墜落事故
エチオピア航空302便墜落事故

<追記:2019.3.29>
 2019.3.28の朝日夕刊記事「飛行システム改修発表」によると、
 パイロットの操作をシステムに優先させる変更を加えるとのこと。

<追記:2019.5.8>
 論座のページで類似の記事を見つけた:
 2019/5/8 人間と機械「どちらを優先?」の正解とは 』
       ボーイング7 3 7 「連続墜落事故」の背景にあるもの <下>
 以上


2019.1
AIシステム検証へのニューロンカバレッジの有用性について


 情報処理学会誌「情報処理」の2019年1月号の以下の解説論文について:
 「機械学習工学:3.機械学習応用システムのテストと検証」
 (情報処理, Vol.60, No.1, pp.25-33)
 
 本解説の研究動向に以下の記述があった:
 『深層学習で得たモデル(ニューラルネットワーク)も一種のプログラムコードであるが、
 コードの分岐カバレッジを100%にすることなどは容易であり、
 それをもって十分にさまざまな可能性をテストしたとは言いがたい。
 このため、ニューラルネットワーク専用のさまざまなカバレッジ指標が提案されている
 (ニューロンカバレッジ〔参考文献1〕等)』
 
 これに対し、以下の疑問を持った:
 ★ニューロンカバレッジを100%にすることは容易だろうか?
 
 そこで、以下の参考文献1を読んでみた。
 Kexin Pei, Yinzhi Cao, Junfeng Yang, Suman Jana :
 DeepXplore: Automated Whitebox Testing of Deep Learning Systems,
 The 26th ACM Symposium on Operating Systems Principles, ACM, pp.1-18 (Oct. 2017)
 
      → 詳細別紙

 以上


2018.12
情報処理技術遺産 構造化プログラミング言語SPL 認定(後日談)


 2018.6のブログ 「情報処理技術遺産 構造化プログラミング言語SPL 認定」で、
 情報処理6月号掲載の情報処理技術遺産認定4件の中の1件は
 私が日立の研究所勤務時に開発に参加したものと報告しました.
 
  本件に関して、12月上旬に、日立製作所 制御プラットフォーム統括本部
 大みか事業所において、「技術遺産認定御礼および報告の会」が開催され、
 情報処理学会から情報処理技術遺産認定証の開発者副本盾が授与されました。
 同時に、大みか事業所長から感謝状をいただきました。
 
 当日の報告では、開発から40年を経た現在も、使用されているとのことで、
 当初の目標だった生産性、信頼性、保守性が評価されていることに感謝です。
 
 → 別紙(開発者副本盾、学会発表資料など)

 以上


2018.12
経団連の就活ルール廃止表明と政府案に一言


  10月末に関係官庁連絡会議において、「会社説明会は3年生の3月」解禁、
 「採用面接などの選考は4年生の6月」解禁という現行日程を当面維持と決めた。
 9月初めに就活ルール廃止を表明した経団連は、今後、「新卒一括採用」の
 見直しに注力する方針。
 
  これまで経済界は、大学(学生)に対して、社会人基礎力(2006年)を求める一方で、
 個々の企業は、新卒採用に関して青田買いをするという矛盾を抱えている。
 大学から見ると、「青田買い」は「青田刈り」になっている。卒業研究や大学院の研究は
 社会人基礎力の習得に直結しているが、学生は就活疲れで研究に身が入らない。
 
 これまでの関連するブログを以下に挙げておく。
 
・2013.4
  【企業の採用活動開始を12月から4月に遅らせることに】
 ★「学生のため」とのことだが,「企業のため」ではないの?
 
・2011.1
  【経団連の「新卒者の採用選考活動の在り方について」の提言に苦言】
 ★企業側に,学生の就活の早期化と長期化が企業の問題という危機意識がない
 
・2009.8
  【大学教育の質の保証の3種類の視点】
 ★人材育成の下流に位置する企業の採用方針が
  上流の教育方針に大きな影響を与えるべき
 
・2007.7
  【(続々)初任給に格差 → イノベーション】
 ★経団連会長が、入社から給料に格差をつける仕組みの導入を提案
 
・2006.5
  【(続)初任給にスキルによる給与格差 → 大学改革】
 ★初任給に差をつければ、大学改革の早道になる
 
・2006.1
   【初任給にスキルによる給与格差】
 ★初任給に差をつければ、情報系の学生の向学心に火が付く

以上


2018.11
「AIと美学・芸術」特集を読んで


 人工知能学会誌(2018.11)の「AIと美学・芸術」特集を読んで、
 第1次AIブームの時の私の修論(1969〜1971)の視点からコメントを述べる。

  ●「芸術の進化的起源」について   → 「詳細別紙」

  ●「人工知能は創造的認知の何を語るか
  ─ 思考の二重性と合理性に基づく一考察 ─ 」について   → 「詳細別紙」

以上


2018.10
幼児の自己中心言語と内言の関係


  私が修士論文(1971)で言及した
 「幼児の自己中心言語と内言の関係」に関するヴィゴツキーの考え、すなわち
 幼児の自己中心言語を思考言語(内言)の習得過程と見なす考えが、
 現在の心理学の主流らしい。
 
 ●私の修論の 第一章「思考の解析」の1.1節「心理学から学ぶこと」 からの引用:
 
 『特に言語機能を外言(音声言語、コミュニケーション言語)と、内言(思考言語)の
  二つに分離して議論したヴィゴツキーの理論は、かなり思考の本質にせまったものと
  思われるので、以下、彼の理論に少し詳しく触れておく』
 
 ●調査概要
  以下の3種類のキーワードでのgoogle検索の結果(2018.10.21):
 「内言と外言」     約 349,000,000 件 (0.37 秒)
 「幼児の自己中心言語」  約 2,090,000 件 (0.37 秒)
 「ピアジェ ヴィゴツキー」   約 9,270 件 (0.29 秒)
 
 この調査結果の上位3件のページの内容を取り上げる。
 
   →  「詳細別紙」

 以上
 
 <過去のヴィゴツキー関連の私のブログ>
 
 2018.5: 解説「子どものコモンセンス知識」でヴィゴツキーが引用されている
 
 2015.8: なつかしのヴィゴツキーが人工知学会誌の学習に関する論文で引用されている  
 
 2014.7: なつかしのヴィゴツキーが汎用人工知能AGIで注目されている   
 
 2008.3: 40年近く前に読んだヴィゴツキーの「思考と言語」が注目されているらしい


2018.10
「孤独の発明 または言語の政治学」を読んで


 2018.9.1の朝日朝刊にこの本の書評が掲載された。
 (書評)『孤独の発明 または言語の政治学』三浦雅士〈著〉(2018.6、550頁)
 
 「状況を俯瞰する超越的な視点」という書評の以下の内容に興味を持った:
 
 ・孤独とは、言語によってもたらされた自分で自分に話しかける内的思考のこと
 ・言語の起源は、視覚を持つことで、状況を俯瞰する超越的な視点が生まれたこと
 ・視覚と言語には本質的な類似性がある
 
 私は、院生時代(1969-1971)に「思考過程の数学的表現」の研究の一環として、
 内的思考と言語の関係に興味をもっていたことと、当時の知識として、
 眼球ないし視覚は前頭葉の発達したものと学んだ記憶があったことから、
 「目は口ほどに物を言う」と思いながら、本書を読んでみる気になった。
 
   →  「詳細別紙」

 以上


2018.9
「IT事件史(1992年):IBM一強時代が終焉 オープン勢台頭」を読んで


 日経コンピュータ2018.8.30号の記事
 「IT事件史 1992年 IBM一強時代が終焉 オープン勢台頭」
 
 【記事概要】
 ・この年、IT業界に君臨した米IBMが巨額な赤字決算に陥った
 ・企業ITはメインフレームからオープンシステムへの転換期を迎えた
 ・オープンシステムはミドルウェアやアプリケーションにも変化をもたらした
 
 【ソフトウェア工学の視点でのコメント】
  この時期のオープンシステムとミドルウェア(プラットフォーム)の普及により、
 従来のハードウェアにあわせたアプリケーションの(一枚岩的な)開発方法に代わり、
 アプリケーションの特徴によりシステム構成を自由に選択するようになっていった。
 メーカ視点からユーザ視点へのパラダイムシフトといえる。
 
 ★そこで、私の著作でのオープンシステムミドルウェアに関する言及部分を調べてみた。
 
 ■1990年の解説論文
「使いやすいソフトウェアと作りやすいソフトウェア −オブジェクト指向概念とその応用」
  (電気学会雑誌、465-472、1990.7)
 
 『社会システムのオープン化・・・計算機ソフトウェアの世界も例外ではない』(p.465)
 
 『種々の応用ソフトウェアがどんなハードの上でも使えるようにするための
  オープンソフトウェアアーキテクチャが重要視され、基本ソフトウェアの
  グローバル化を目指した標準化活動が活発に展開されている』(p.465)
 
 ■1991年の解説論文
  「エンドユ−ザコンピュ−ティング −ソフトウェア危機回避のシナリオ−」
  (情報処理, 950-960、1991.8):
 
 『そのシステム構成はメインフレーム主体からワークステーション主体の分散システムへと
  発展しており、計算機システムのオープン化と標準化が進みつつある。』(p.950)
 
 『アプリケーションソフトウェアアーキテクチャの各階層をできるだけ業界標準や
  国際標準にして、異なるメーカの機種間でもアプリケーションソフトウェアの
  移行性を確保するものである』(p.953)
 
 『図2「標準化シナリオにおけるオープン指向システム構成』(p.953)
 
 ■1992年拙著
  「ソフトウェア危機とプログラミングパラダイム」 (啓学出版、1992.8):
 
 『世の中のグロ−バル化とコンピュ−タシステムのグロ−バル化がもたらす
  オ−プン化と標準化の図式を図1.1に示す』(p.4)
        
 
  『オ−プン化と標準化の時代のプログラムの移行性重視』(p.31)
 
 『アプリケ−ションソフトウエアの共通プラットフォ−ムとしてのオブジェクト管理システム
  の開発などが積極的に行われており、オブジェクト指向ベ−スのソフトウェア開発環境が
  充実しはじめている』(p.100)
 
 以上


2018.8
働き方改革で26年前の電子技術者の問題は解決している?


 古い資料を整理中に下記の記事が見つかった。
 日米欧の電子技術者を対象とした環境と意識に関するアンケート調査結果である。
 26年前の資料であるが、最近の働き方改革の参考になるかもしれないので、
 当時、私が色付けした部分を抜粋して記載した。すでに解決していれば幸いである。
 
 (参考資料)日経エレクトロニクス 1992.9.28 の記事(p.121〜p.145)
       「特集:日米欧電子技術者 環境と意識を比較」
 
 <色付け部分の抜粋>
 【特集1部:日米欧で環境や意識が一致、日本の問題は職場のコミュニケーション】
 ・コミュニケーション・ギャップの問題は、日本の技術者が転職を考える大きな理由
 ・上司は最新技術を理解していない
 
 【特集2部:技術の動向予測がおおむね一致、仕事時間の使い方に日米欧の違い】
 ・雑用時間も日本が長い
 ・日本の技術者は「昼間に雑用を片付けて、夕方からの残業時間に本来の仕事をする」
 ・自由なR&D時間が最も長いのは欧州
 ・日本の技術者は内職文化(好きな研究は、ひそかに進める)に慣れている。米国の技術者は、
  やりたいことがあれば会社を辞めて、大学に行くなり、ベンチャーを興すのではないか。
 ・日本では、研究者ですら、論文発表よりも特許出願を経験した人の割合が高い。
 ・米国企業は、中間管理職をどんどん解雇している。
 
 【特集3部:日本の開発現場で上司や同僚の技術力に不満】
 ・日本のマネージャの場合、意思の疎通に関して期待されるところが大きすぎる
 ・米国のEngineering Managerの場合、技術専門職という意識が強い。
  日本の技術部長は、会社の管理職としての姿勢が前面に出る。
 ・マネージメントや雑務に追われて、最新技術を深く理解する余裕がない
 ・実際のデザインまではレビューできない
 ・部下を信頼して腹をくくるしかない
 ・仕事の評価は結果が出る前に決まっている
 ・売れ筋の商品を担当させてもらえるかどうかで、おおむね決着はついている
 ・ボーナスの査定が高かったり、部内で評判が良いのは売れ筋の商品を担当した技術者
 ・自分が上司をどう評価しているかより、会社が上司に下した評価に気を配るべき。
  会社の評価と自分の評価が一致しなければ、転職を考えればよい。
 
 以上


2018.8
3銀行の合併初日に3つのシステム障害とは


  日経BPの記事 「合併初日に3つのシステム障害、きらぼし銀が体制強化」 (2018.8.10)について:
 
 【記事の概要】
 ・システム構成:新銀行東京のシステムを都民銀行のシステムに統合。
   八千代銀行のシステムは残し、2つのシステムを相互接続する形態
 ・障害1:試験環境から本番環境への移行時、ベンダーに出した作成依頼書に基づいて、
   統合するプログラムやテーブルに漏れがないかをチェックしたため、
   作業依頼書が存在しないICチップ情報のテーブルはチェックの対象外となり、
   本番環境への登録漏れが発生した。
 ・障害2:全銀システムは銀行名の変更に対応する読み替えフラグを立てたが、八千代銀行の
   勘定系システムはこのフラグの意味を「店舗の統廃合」と認識し、口座を特定できなかった。
 ・障害3:ATMでは、屋号付き個人の口座が振込先の場合、利用者に屋号と氏名を入力させ、
   両方並べた文字列で問い合わせる仕様としたが、照合先が氏名のみだったため、
   文字列が一致せず、振り込み手続きに進めなかった。
 
 【ソフトウェア工学の視点でのコメント】
 
  相互接続のシステム構成は、2002年春に3銀行のシステム統合でトラブルを起こした
 みずほ銀行の場合と似ている。
 
 [障害1]
  ICチップ情報のテーブルの本番環境への登録という基本作業が漏れるとは信じがたい。
 作業手順書はなかった? 外注依存の常態化で、内作対応作業の存在を完全に忘却か?
 
 ★本番環境下でのテストで、ICチップ搭載型カード使用のテストケースが抜けていて、
  網羅的なテストのためのテストケース作成過程に問題あり。
 
 [障害2]
  サブシステム間の(入出力)インタフェース仕様の不一致という初歩的ミス。
 両方のサブシステムの外部仕様書にインタフェース仕様の記載がなかった?
 
 ★障害1と同様、網羅的なテストのためのテストケース作成過程に問題あり
 
 [障害3]
  障害2と同様、サブシステム間のインタフェース仕様の不一致という初歩的ミス。
 
 ★3種類の障害はいずれも稼働前の網羅的なシステムテストで検出可能なものだったのでは。

以上


2018.8
「IT事件史(2005年):誤発注で損失400億 責任めぐり10年裁判」を読んで


  日経コンピュータ(2018.8.2)の記事:
 「IT事件史 2005年 誤発注で損失400億 責任めぐり10年裁判」
  【記事の要約】
 ・2005年12月8日、みずほ証券は「1株61万円」の売り注文を誤って「61万株1円」と入力。
  そのあと取り消し注文をしたが、東証の売買システムにバグがあったため受け付けられず、
  発行済み株式数の約48倍に当たる70万株の取引が成立し、400億円超の損失を出した
 ・みずほ証券が起こした裁判は10年に及び、東証が約107億円を支払う判決が確定。
 
 本件については、度々ブログに記載したり、授業で取り上げたりしてきた。
 以下にその項目のみ記載。
 
 ■【ブログ】
 2015.10  株の誤発注裁判で最高裁が双方の上告を退ける決定
 2015.6  次期の東証システムでの誤発注対策
 2013.8  株の誤発注裁判で控訴審も第一審と同額賠償の判決!
 2012.9  東証-みずほ誤発注裁判でプログラム修正後の構造テストも争点に
 2012.8  東証-みずほ誤発注裁判でプログラム修正後の回帰テストが争点に
 2009.12  東証の誤発注問題の415億円の損害賠償裁判に東京地裁判決
 2008.5  要件定義書に「現行と同一」という記載はありか?
 2007.5  東証の誤発注事故(05.12)は分岐テストで防げたはず
 
  ■【ソフトウェア工学・演習の授業での電子ディベート】
  →  <詳細別紙(2005.12)(2006.6)(2007.6)>
 
 ・(2005.12)
  株誤発注事件に関し,現実にありえない注文を受け付けてしまったミスと、
  注文取消しを受け付けなかったミスと、どちらがより重大なミスか。
 ・(2006.6)
  開発(設計,プログラミング,テスト)段階で,仕様の不備に気づくべきだったのでは?
 ・(2007.6)
  配布資料「誤発注裁判で見えてきた不具合の真相」に関し,システム構築の観点での意見.
 
 ■【ゼミナール1の授業でのディベート】
  →  <詳細別紙 2010.5.10, 2010.4.26, 2010.4.19>
 
 ・2010.5.10
  誤発注事件に関する東京地方裁判所の判決について.
 ・2010.4.26
  誤発注事件に関して,システム構築の観点.
 ・2010.4.19
  システム構築の観点で,どちらの問題をより重大なミスと考えるか.

以上


2018.7
「IT事件史(2011年):みずほ「悪夢」再び 震災で混乱」を読んで


 日経BPの記事【ニッポンIT事件史:  みずほ「悪夢」再び 震災で混乱、頭取辞任】(2018/7/3)

 <要約>
 ・みずほ銀行は東日本大震災をきっかけに大規模なシステム障害を引き起こし、
  当時の頭取が引責辞任する事態に追い込まれた。
 ・震災の3日後の3月14日にシステム障害が発生し、システムが正常化したのは3月24日。
 ・この間、入金が遅れた他行宛ての振り込みは計120万件、他行からの振り込みは101万件。
 
 【本件に関する過去のブログ】
   2011.4 みずほ銀行の振込み処理トラブル
 
 このブログでは、実際の二重入金の実例として、私の給与の「給料二重振込みの記録 」を記載した。
 また、「上限を設定しながら上限を超えた入力を受け付けない処理ができないのはなぜ??」という
 素朴な疑問を述べたが、その関連記事を以下に掲載している。
 
 【その後のブログ】
   2016.2 オーバーフローのチェック漏れがなくならない
   2015.6 オーバーフローのチェック漏れがなくならない
 
 【教科書での「上限チェック漏れ」関連の記載】
     ソフトウェア工学 (第3版)(朝倉書店 2014年3月刊)
   (記述箇所)
   [第II編 ソフトウェアの開発技法]の[8章 検査と品質保証]の [8.4節 不良分析]p.93:
  
  『また検査段階での検出をまぬがれてシステム運用中に引き起こされる事故は社会的影響が大きいが,要求分析,設計,製造の各段階での例外的な事象に対する処理の抜けによるものが多い.例外的な事象は,システムの運用を開始して数年経過して発生することもあり,開発を担当しなかった保守担当者が限られた資料を元に修正箇所を特定する必要がある.
  過去の例では,・・・など,枚挙にいとまがない.
 これらの事故は,すべて,許容範囲を越えた入力に対する例外処理をしておけば,事前に防げたものである.

以上


2018.7
「意識とメタ過程」特集を読んで


 人工知能学会誌(2018.7)の「意識とメタ過程」特集を読んで、
 第1次AIブームの時の私の修論(1969〜1971)の視点からコメントを述べる。

  ●「心と記憶力 ─知的創造のベルクソンモデル─」について   → 「詳細別紙」

  ●「痛みを感じるロボットの意識・倫理と法制度」について   → 「詳細別紙」

  ●「統合情報理論から考える人工知能の意識」について   → 「詳細別紙」

  ●「メタ認知から見た意識の生物学」について   → 「詳細別紙」

以上


2018.7
「物理学とAI」特集を読んで


 人工知能学会誌(2018.7)の「物理学とAI」特集を読んで、
 リカレントニューラルネットワークやレザバー計算機について、
 第1次AIブームの時の私の修論(1969〜1971)の視点からコメントを述べる。

  → 「詳細別紙」

以上


2018.6
「IT事件史 1999年:「Y2K」の緊張走る」を読んで


 日経コンピュータ(2018.6.7)の記事「IT事件史 1999年:「Y2K」の緊張走る」にコメントする。
 <記事抜粋>
 ・Y2K(2000年問題)とは、2000年になったとき、西暦の下2桁だけを管理するプログラムは
 「1900年」か「2000年」かを判別できずに誤動作する可能性があり、年が変わった瞬間に
 電力やガス、交通機関などの社会インフラ、銀行の勘定系システムや決済ネットワーク、
 電話や通信のネットワークなどに大きな事故や混乱が生じるかもしれないという問題だった。
 
 ■本件は、「ソフトウェア工学・演習」の授業で取り上げ、以下の教科書にも記述した。
  
 ソフトウェア工学 (第2版)
(朝倉書店 2004年3月刊)
 
   → <詳細はこちら>

 以上


2018.6
「IT事件史(2002年):みずほ銀が大規模システム障害」を読んで


 日経BPの記事 
  「IT事件史 :(2002年の)みずほ銀が大規模システム障害」 (2018/06/13)についてコメントする。
 
 <記事の要約>
 ・2002年4月、日本興業、第一勧業、富士の旧3行が合併し、みずほ銀行が生まれた初日に
  大規模なシステム障害が起きた。
 ・システムの一本化は2003年以降に先送りし、統合初日の時点では、複数の現行システムを
  「リレーコンピュータ」でつなぎデータをやり取りするという、つぎはぎの仕組みだった。
 ・旧3行の主導権争いが影響し、みずほグループのシステム統合の方針の混乱が
  開発スケジュールに及び、十分なテストができていなかった。
 
 ■本件は、「ソフトウェア工学・演習」の授業で取り上げ、以下の教科書にも記述した。
 
 ・   ソフトウェア工学 (第2版) (朝倉書店 2004年3月刊)
 
 【記述箇所1】
  [第I編 ソフトウェアの動向]の[2章 ソフトウェア危機の歴史]の [2.5節 インタフェースの問題]p.12:
 
 「2002年春に発生した某銀行オンラインシステムのトラブルの遠因は,合併前の3銀行のシステムが独自仕様で構築されていたことである.そのため,合併後の連携処理部分でインタフェース不良が発生して大きな事故となってしまった.このことは,わかりやすいインタフェースの重要性とその実現の難しさを示しているといえる.」
 
 【記述箇所2】
 [あとがき ― コンピュータはなぜ間違えるか? ―]p.173
 
 「前世紀末の西暦2000年問題も新世紀初頭(2002年4月)の某銀行の情報システム障害も危機的状況を思わせるには十分であったが,ソフトウェア革命はまだ達成されてはいない.」

 以上


2018.6
差別発言をしたチャットボットTay(2年前)への追加コメント


 日経コンピュータ(2018.5.24号)の記事
 「ダークAI:今そこにある悪意が暴走を招く」の
 「ヘイトするAI 差別発言まで学習」の節において、
 2016.3にブログ取り上げたマイクロソフトのチャットボットTay(テイ)について、
 以下の気になる記述がある。
 
 A:「マイクロソフトはテイの公開にあたり、学習すべきでない内容を遮断する
    フィルターを実装し、一部の利用者による先行テストも実施していた」
 
 B:「同社が先駆けて公開していた中国の「XiaoIce(シャオアイス)」や日本の
    「りんな」は、対話に使う言葉を同社の開発者がオフラインで教え込む形式だった」
 
 ■2年前のブログ    「2016.3 差別発言した人工知能の学習モデルは?」
 では、以下の3種類の対策を指摘していた。
 
 ★対策として望ましいのはどれ?
  (1) 善良な市民として選別した者とだけ対話学習をするようにする.
        (選別されていない一般人とは,対話はするが,学習はしない)
  (2) 反社会的な思想に関する知識を常に排除するフィルターを組み込む.
       (その関連の知識(発言)が入力されると警告する)
  (3) 差別発言をするようになった時点で,一般人との対話を一時中止する.
        (その矯正をする担当者との対話学習のみ実施する)
 
 ■今回のコメント
 
 ★記事Aによると、対策(2)を事前にとっていたとのこと。
  (フィルターの機能が不十分だったらしい)
 
 ★記事Bによると、先行して公開したシステムでは、対策(1)をとっていたとのこと。
 
 ★★疑問:A,Bから推測すると、「差別発言の学習」は事前に容易に想定できたのでは??

 以上


2018.6
情報処理技術遺産 構造化プログラミング言語SPL 認定


 情報処理6月号掲載の情報処理技術遺産認定4件の中の下記の1件は
 私が企業研究所の勤務時に開発に参加したものだった.
 
 【情報処理6月号 p.545から引用】
 ・構造化プログラミング言語SPL
 「大規模組込型システムアプリケーションソフトウェアの信頼性・保守性の大幅向上を図るため、
  日立の制御用計算機の高級言語として1970年代中期に開発された。
 同様の狙いを持つ米国国防総省のAdaに先行、
 鉄鋼制御システムや列車制御システム等の開発に適用された。」とのこと
 
 → 別紙(学会発表資料など)

 以上


2018.5
解説「子どものコモンセンス知識」でヴィゴツキーが引用されている


 人工知能学会誌(Vol. 33 No. 3, 2018.5)の解説「子どものコモンセンス知識」で、
 人間が成長に伴い獲得していくコモンセンスの本質に関連して、
 人間の認知発達プロセスに関する従来理論の検証や精緻化が進展すると指摘し,
 その具体的方策として「子どもの行動コーパス」に基づく方法論を紹介している.

  その中で、50年近く前に私が注目したヴィゴツキーの研究が引用されている。
 以下はその該当部分:
 (1) Alan Kayは、発達心理学者の認知理論に触発されて、Dynabookを発案したとことで、
   その一つに、Vygotskyの「最近接発達領域」を挙げている。
 (2) Minskyは多階層思考モデルの解説において、乳幼児期の愛着形成が、言語発達や
   社会規範の習得の基礎となり、子供の思考の目標を上の階層へと引き上げる役割を
   果たすと述べており、Vygotskyの最近接発達領域の知見と通底する、とのこと。

 ただし、私が修士論文( 詳細)で注目したのは、以下のような視点。
 「言語機能を外言(コミュニケーション言語)と内言(思考言語)の二つに分離」
 「4〜6歳児の自己中心言語は、7歳くらいまでに内言(思考言語)へと発達する」
 
 【ヴィゴツキー関連の過去のブログ】

 2015.8: 「番外編:なつかしのヴィゴツキーが人工知学会誌の学習に関する論文で引用されている」

 2014.7: 「番外編:なつかしのヴィゴツキーが汎用人工知能AGIで注目されている」

 2008.3: 「40年近く前に読んだヴィゴツキーの「思考と言語」が注目されているらしい。」

 以上


2018.5
「国交省のチェックツールに不具合」を読んで


  日経BPの記事 「17年間の改修でソースコードがスパゲティ化、国交省のチェックツールに不具合」 (2018.5.8)について:

【記事の概要】
・国土交通省は、公共事業の受注企業がCADデータなどを納品する前に利用する
 電子納品チェックシステムの不具合を2017年12月に公表。
・国交省が定めたルール通りのデータでもエラーと誤判定する事象が発生とのこと。
・修正後に別の不具合が発生するなど、3度にわたる修正を重ねて不具合は収束。
・17年にわたり改修を重ね、ソースコードが複雑になっていたことが背景にあった。

【ソフトウェア工学の視点でのコメント】

[疑問1]
 改修対象の機能と無関係な機能で不具合が発生したことについて、担当業者は、
「プログラムの影響範囲の確認とテストが不足していた」とのこと。

★回帰テストの視点でいうと、既存システムに用いたテストセットのうち、
(a)仕様変更に対応するテストには、新たに作成したテストケースを用いる
(b)仕様変更に無関係の、その他のテストケースは、そのままもう一度テスト実行する
ということになるが、(b)のテスト作業を手抜きしたと思われる。

[疑問2]
 国交省は「電子納品チェックシステムは2001年度に最初のバージョンを公表して以来、
電子納品要領と基準が数年ごとに変更されるのに伴って改修を重ねてきた。
発注先のベンダーを変えながら改修してきたこともあり、
電子納品チェックシステムのソースコードが複雑になっている」と説明。

 ★ソースコードは本当に複雑化した?
 公開された仕様を見る限り、モジュール化は容易に見える。
 個々のルールチェックの処理に対応するモジュールがあるはずで、
モジュール結合度(モジュール間の関連の度合い)が複雑化する理由が不明。
モジュール化できていれば、ルール変更でもモジュール間の構造はくずれないのでは?

[疑問3]
 今後の対策として、国交省は「改修時には、念には念を入れて第三者にも
テストしてもらうような体制作りが必要だ」とのこと。

★発注元の国交省は受け入れテストを実施していないのだろうか。
「第三者にもテストしてもらう」とは、今後は受け入れテストを外注するということ?

[疑問4]
 国交省は2018年2月、チェックシステムで確認しているチェック項目の全仕様を初公開した。
 公共事業の受注企業側のツールに同様のチェック機能を組み込みやすくし、
作成中にチェックをかけることで、チェックの機会が増え、納品物の品質が高まるとのこと。

 ★この現状打開策は理解できない。そこそこの品質の同じシステムをたくさん作るより、
 高品質のシステムをひとつ作成し、みんなで利用するほうがよいに決まっている。

 以上


2018.5
人材の不足と育成:今日のAIと80年代のIT


  2018年5月発行の人工知能学会誌( Vol. 33 No. 3)の解説論文
 「AI人材育成のための教育プログラム:人工知能技術戦略会議での議論」(八木康史氏)で、
 産学におけるAI人材の需要と供給状況の現状把握と今後の展望が述べられている。

 経済産業省「IT人材の最新動向と将来推計に関する調査結果」からの抜粋として、
 AI技術などを使いこなすことのできる先端IT人材は、
 2020年にはおおむね5万人弱の人材不足となる、とのことである。

 1980年代の情報処理技術者の不足の話との関連で、コメントする。
    → 【別紙】

 以上


2018.4
機械学習工学とソフトウェア工学の共通点と相違点


  人工知能学会誌 Vol. 33 No. 2 (2018/3) 掲載の解説
「機械学習工学へのいざない」(丸山宏、城戸隆)では、
演繹的システム開発と帰納的システム開発の共通点と相違点を明らかにし,
ソフトウェア工学から得られる知見と,新たに機械学習のために必要な項目について
議論している。

 アプリケーション開発の観点で興味深いので、
本文で提起されている7項目の機械学習工学の主要な課題のいくつかについて
ソフトウェア工学の観点から別紙でコメントする。

 →  【別紙参照】

 以上


2018.4
「IT事件史 1982年のIBM産業スパイ事件」を読んで


 日経のXTECHの記事
 「IT事件史 1982年のIBM産業スパイ事件、認知されたソフトの重要性」を読んで、
 当時の日立の研究所勤務時代の関連する思い出話を記述する。

 (懐古趣味にて→  詳細はこちら

 以上


2018.4
「サボリのススメ」を読んで


記事 「サボりのススメ」(2018.4.12 朝日新聞朝刊)を読んで、
メーカーの研究所に勤務していた1980年代に考えた標語を思い出した。

<記事のリード文>
 「働き方改革」の号令のもと、効率の良い仕事ぶりが期待されている。
 ただ、組織の中で息切れせずに実力を発揮するには、
 上手にサボる視点が大切かもしれません。

以下は、職場の標語として応募して採用されなかった私の作品 (^^;;
 ★★★【息抜きは知恵のもと 手抜きは怪我のもと】

この標語の意図は、今回の記事の中の以下の記述と同じ:
 『サボることの効用は、・・・頭を空にして白紙から考え、アイデアが生まれる』
 『自分の立ち位置を見渡せる踊り場のような状態が必要です』
 『ちょっとサボってもいい社会をつくるには、「いま本当に変えるべきものは何か」を考える必要があります』

 要するに、効率よりも効果が重要ということですね。(^^)

 以上


2018.3
システム開発プロジェクトの成功率が10年前より上昇!


 日経コンピュータ2018.3.1号の特集記事:
『半数が「失敗」 1700プロジェクトを納期、コスト、満足度の3軸で独自調査』 について、
ソフトウェア工学の観点でコメントする。

 10年前の同様の調査結果については、下記のブログ(2009.1)で言及している。
  「システム開発プロジェクトの成功率が5年前より上昇!?」

システム開発プロジェクトの成功率 52.8% について
 過去15年間に以下のように改善している。
  26.7%(2003年)→ 31.1%(2008年)→ 52.8%(2018年)
(注)前回までは{品質、コスト、納期}を順守したプロジェクトの比率を成功率としたが、
  今回は{満足度、コスト、納期}としている。
 おそらく、品質の順守率は判断が難しいので、満足度に変更したと思われる。

納期(スケジュール)の順守率 72.0% について
  54.9%(2003年)→ 54.6%(2008年)→ 72.0%(2018年)

コストの順守率 81.8% について
  76.2%(2003年)→ 63.2%(2008年)→ 81.8%(2018年)

成功率向上の理由は?
 記事の内容から以下の要因が推測される。
 *開発規模の小規模化:
  約6割のプロジェクトが、開発期間は1年未満で、コストは5000万円未満。
 *SaaSの利用:
  約半数のプロジェクトがクラウド利用で、その34.2%はパブリッククラウドのSaaS利用。
  一から開発するプロジェクトの減少がうかがえる。

失敗の要因は?
 記事の内容から以下の要因が推測される。
 *要求定義の不良
  あいかわらず、要求定義が不十分で、仕様変更・追加開発が多発。
  多様な立場のステークホルダの分析漏れが推測される。
 *工数見積もりの不良
  あいかわらず、開発期間とコストの見積もりミスが多い。
  要求定義と見積もりの作業内容は異なるが、相互の関連は強く、
 開発期間やコストが限定的なら要求仕様も限定的にすべきだが、
 要求仕様は過剰で、工数見積もりが過少になる傾向がある。

★この問題については、以下の学会発表で、
 要求定義担当と工数見積もり担当の相補的立場での協力体制が不可欠、と述べている。
「ソフトウェアの要求分析と工数見積もりに関する考察」
 情報処理学会 ウィンターワークショップ2011 論文集、 p.43-44(Jan. 2011).

 以上


2018.2
東大病院の電子カルテシステムでトラブルの原因は?


 日経BPの記事 「東大病院の電子カルテシステムでトラブル」 について、
ソフトウェア工学の観点でコメントする。

【記事の概要】
・年初に本稼働した東大病院の電子カルテシステムでトラブルが発生し、
 患者が長時間待たされ、外来窓口に長蛇の列ができた。
・旧システムと操作方法が変更されたため、医師や事務担当者の操作ミスが多発した。
・特に、担当医師による外来患者の電子カルテ閲覧時の最初の操作で必要とされた、
 患者の医療保険種別の選択処理のミスが多発した。

【ソフトウェア工学の視点でのコメント】

 基本的には要求定義の失敗と思われる。

★1980年代のメインフレーム流?
 当時、銀行システムやみどりの窓口のシステムなどでは、
窓口担当者の行う操作手順は事前に訓練できるため、ユーザインタフェースよりも、
窓口で顧客を待たせないための処理効率向上が最優先された。(スループット向上)
しかし、病院システムでは、診察室での医師にとっての使い勝手は最重要のはず。

推測になるが、開発担当者は以下の2点でミスを犯したのではないか。
・医師は上記の窓口担当者(事務職)とは異なる業務なのに、業務の実態を把握せず、
 新たな操作手順については、訓練すれば済むと安易に考えたのでは?
 (大病院の医師には十分な訓練時間の余裕がないことは自明)
・そして、会計処理の効率向上を最優先した結果、使用性の問題を残したのでは?

★要求定義段階で現場ユーザによる操作手順の事前評価をしなかった?
 通常、ユーザインタフェースについては、モックアップソフトを用いて
実装前に、現場ユーザに使用性について確認するものだが。

(参考:拙著 「ソフトウェア工学」からの引用)
『重要なリスクは,プロトタイプの作成やシミュレーションなどにより解決策を策定する.
 たとえば,性能やユーザインタフェースに関して,初期段階でプロトタイプで確認する』
『利用者の立場では,何が欲しいかをうまく表現できないが,
 できたものをみれば望むものか否かがわかるということが多い.』

★要求定義段階でステークホルダが関与していない?
 病院システムに関連するステークホルダは多いが、医師と患者は最重要と思われる。
業界標準のプロジェクト管理の知識体系PMBOKでも10項目の知識エリアの一つとして、
重要視されている。
 
(参考:拙著 「ソフトウェア工学」からの引用)
『j.ステークホルダ管理
 これはPMBOK第5版で追加された10番目の知識エリアである.
 利害関係のあるステークホルダの適切な管理がプロジェクト成功の重要要因である
という観点からステークホルダとの意思疎通に努める.』

★データベースの構造に欠陥?
 担当医師が電子カルテ閲覧時に患者の医療保険種別を選択入力する仕様が理解できない。
患者の診察券番号や氏名で検索する方法にしない理由は?

以上


2018.2
仮想通貨をゼロ円で売買したシステムの不具合とは?


 仮想通貨交換サイトのシステムで、仮想通貨をゼロ円で売り出す不具合が発生した。
(以下はいくつかの記事からまとめた要点)
・2/16に仮想通貨交換サイトで、仮想通貨がゼロ円で買える状態が発生し、7名が取得。
(取得された仮想通貨ビットコイン20億は、約2200兆円に相当)
・2/20に運営会社は、価格計算システムに不具合が発生したと発表。

 この記事ですぐ思い出すのは、2005年に発生した株の誤発注事件だ。
証券会社が「61万円で1株売り」と間違えて「1円で61万株売り」と入力した。
すぐに誤入力に気が付いたが、東証システムに取消機能がなく、電話連絡での取消もできず、
自ら買い戻すまでの間に10万株近くの売買が成立してしまった。

【ソフトウェア工学の視点でのコメント】

今回の仮想通貨の売買と株の売買は類似していると思われるが、
「価格計算システムの不具合」はどのようなものだったのかは公開されていない。
推測になるが、株の誤発注の以下のような教訓は生かされなかったことになる。
 ★価格と数量に関する異常な数値のチェック機能の不備
 ★(プログラムミスの場合)テスト不十分性

【株の誤発注関連の過去のブログ】

2015.6  次期の東証システムでの誤発注対策
2012.9  東証-みずほ誤発注裁判でプログラム修正後の構造テストも争点に
2012.8  東証-みずほ誤発注裁判でプログラム修正後の回帰テストが争点に
2009.12  東証の誤発注問題の415億円の損害賠償裁判に東京地裁判決
2007.5  東証の誤発注事故(05.12)は分岐テストで防げたはず

以上


2018.1
「サービス設計12箇条」を読んで


 IT戦略本部の第30回新戦略推進専門調査会電子行政分科会(2017.12.1)に
提出された下記資料の中で、サービスデザイン思考実践の具体的なポイントが
「サービス設計12箇条」として提示されている。

【資料1−2】 サービス設計の基本ルール及びサービスデザイン思考の実行につ

 そこで、過去の研究との関連で、これらの項目についてコメントする。
    第1条 利用者のニーズから出発する
    第2条 事実を詳細に把握する
    第3条 エンドツーエンドで考える
    第4条 全ての関係者に気を配る
    第5条 サービスはシンプルにする
    第6条 デジタル技術を徹底的に活用する
    第7条 利用者の日常体験に溶け込む
    第8条 自分で作りすぎない
    第9条 オープンにサービスを作る
    第10条 何度も繰り返す
    第11条 一遍にやらず、一貫してやる
    第12条 システムではなくサービスを作る

  → コメント(別紙)

以上


2018.1
「AIは哲学できるか」を読んで


 朝日新聞の記事 「AIは哲学できるか」(2018.1.22)という
 哲学者M氏の挑戦的なタイトルに刺激されて、コメントする。

<記事概要>
・AIに過去の哲学者たちのすべてのテキストを与えると
 「人間が考えそうな哲学的思考パターンのほぼ完全なリスト」ができる
・根本的疑問:人間が設定した問いに解を与えるだけでは、哲学とは呼べない
・哲学は、自分自身にとって切実な哲学の問いを内発的に発することが出発点
 例:「なぜ私は存在しているのか?」、「生きる意味はどこにあるのか?」
・AIにはこのようなことは当分できないと予想する
・仮に、人間からの入力なしにAIが切実な哲学の問いを内発的に発し、
 その問いをひたすら考え始めたら、「AIは哲学をしている」と判断する
・AIが発する問いを奇妙なものと感じる人間とAIの対話が始まれば、
 哲学に新次元を開くことになる

人間にできてAIにはできないと思われる
「切実な哲学の問いを内発的に発し、かつ、考える」行為についてコメントする。

  → コメント(別紙)

以上


2018.1
「新春大予測 20の技術が変える未来」特集を読んで


 日経コンピュータ(2018.1.4)では、「2018年に進化を遂げる20の技術を選び出し、
 それらがビジネスや社会、日本の未来をどう変えるのかを大胆予測」している。
 
  そこで、過去の研究と関連する以下の4項目についてコメントする。
 予測01:職場の人手不足が解消(RPA)
 予測02:毎週、管理職の送別会(AI)
 予測05:所有や雇用の常識が瓦解(シェアリングエコノミー)
 予測07:航空・自動車も接続大開放(API管理)

  → 「詳細別紙」

以上


2017.12
「脳情報科学が拓くAIとICT」特集を読んで


 情報処理学会誌(2018.1)の「脳情報科学が拓くAIとICT」特集を読んで、
 第1次AIブームの時に執筆した卒論・修論の視点からコメントを述べる。

  → 「詳細別紙」

以上


2017.12
「脳科学とAI のフロンティア」特集を読んで


 人工知能学会誌(2017.11)の「脳科学とAI のフロンティア」特集を読んで、
 第1次AIブームの時に執筆した卒論・修論の視点からコメントを述べる。

  → 「詳細別紙」

以上


2017.10
大手メーカーの出荷前の品質検査の不正


 【引用記事2件】
●朝日(2017.10.16) 「最終関門の品質保証担当まで積極改ざん 神鋼不正品問題」
<要点>
・神戸製鋼所の検査データ改ざん問題で、製品の品質を最終確認し、出荷差し止め権限を持つ
 品質保証担当者が検査データを改ざんしていた例があることがわかった
●時事通信(2017.10.3) 「日産、無資格者が検査=国内全工場・車種で不正−リコール100万台超も」
<要点>
・日産自動車は、新車を出荷する際の完成検査を、資格を持たない者が行っていた

【ソフトウェア工学の観点でのコメント】
・大手メーカーの検査部門が,「顧客の立場で検査する」という基本を無視とは!

・授業でも使用した 拙著「ソフトウェア工学」の[8.1節 検査の目的]で以下のように述べた:
 *ソフトウェア検査とは,ソフトウェアの出荷前に,そのソフトウェアが製品として
  十分な品質に達していることを見極めることである
 *この検査は,開発部門とは別組織の検査・品質保証部門が実施する
 *検査の基本は,そのソフトウェアの顧客の立場に立って
  要求仕様を満足していることを確認し,製品としての合否の判定を行うことである

以上


2017.10
システム開発失敗の責任は発注側にありとの逆転判決


 【引用記事】日経コンピュータ2017.9.29号:
失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決

<記事の要点>
・病院情報管理システムの開発失敗の責任について旭川医科大学とNTT東日本が裁判で争う
・一審判決は,過失割合は発注側2割、開発側8割として双方に賠償を命じた
・控訴審判決は,発注側にだけ約14億1500万円を支払うように命じた
・判決理由として,
 開発側は追加開発による納期遅延を繰り返し説明し,仕様凍結の合意をとっていたが,
 発注側は,仕様凍結合意後も追加開発を繰り返し要望するなど,協力義務違反があった.

【ソフトウェア工学の観点でのコメント】
・基本的に仕様決定は発注側の責任で,その後の実装は開発側の責任なので,判決は妥当.
 発注側は,実装開始後の仕様変更の追加費用・工期延長を確認すべき.

・過去の学会発表(2011) 「ソフトウェアの要求分析と工数見積もりに関する考察」 でも,
「ソフトウェアの工数見積もりは要求分析とは別作業として扱われることが多いようであるが,
要求仕様と開発工数は密な関係があり,その関連での失敗プロジェクトも多い.
要求定義担当と工数見積もり担当の相補的立場での協力体制が不可欠と思われる.」
と指摘している.

【過去のブログ例】
 「スルガ銀-IBM裁判で最高裁が上告を棄却」(2015.7) の場合は,
 要件定義により当初予定の費用や目標の達成が不可能と判明したのに、
 開発側がそれを指摘せずに最終合意書を結んだことが義務違反に当たるとして,
 開発側に約42億円の賠償を命じた東京高裁の判決が確定している.

以上


2017.9
衛星「ひとみ」のプログラムミスの道義的責任で5億円とは?


 NHKの9/5のニュース記事:
観測衛星失敗はプログラムミス NECが5億円支払いへ

<記事の要点>
・人為的なミスで機体が壊れた天体観測衛星「ひとみ」(開発費は310億円)について、
 原因の1つは、衛星のエンジンの制御パラメータを不適切に設定したプログラムミスだったとして
 プログラムを作成したNECがJAXAに5億円を支払う民事調停が成立した。
・NECは、
 「JAXAの期待に応えられなかったことへの反省と、道義的責任を感じたため、
 調停案を受け入れた」とコメントしている。
・JAXAは、
 「今回の事象は複数の原因によって発生し、宇宙という実際に確認することができない場所で
 起きたため、大変困難な問題だった」とコメントした。

 この事故のソフトウェア工学の観点での疑問について,以下のブログですでに述べている.
  衛星「ひとみ」がプログラムのミスで運用断念とは残念!(2016.5)

■今回の疑問

・プログラムミスの詳細を公開すべし.「道義的責任」で5億円支払いは理解できない.

・上記ブログで述べた「担当者が使ったのは開発用のプログラム」のことならば,
 開発者は正しく使っていたはずなので,プログラムミスではないはず.
 また,開発用のプログラムは製品ではないので,マニュアルがなくても契約違反ではない.
 担当者の理解不足による使用ミスをプログラムミスとは言わない.

・「大変困難な問題」だったというJAXAのコメントが理解できない.

以上


2017.9
総務省のAI開発ガイドラインは有用?


 総務省情報通信政策研究所は、AIネットワーク社会推進会議において取りまとめた
 「報告書2017 ― AIネットワーク化に関する国際的な議論の推進に向けて―」
を7/28に公表した.本ブログでは,公表資料「報告書2017概要」の中の,
 「第2章 国際的な議論のためのAI開発ガイドライン案?(AI開発原則案の解説)」
について,率直なコメントを   別紙(★印) に記載した.

<要点>
 開発原則9項目のうちの5項目(連携,セキュリティ,プライバシー,利用者支援,アカウンタビリティ)はAI特有の内容ではなく,情報システム一般に関するものと思われるので,残りの4項目について,ソフトウェア工学の視点からコメントする.

★透明性(検証可能性,説明可能性)に関しては,
 プログラミングベースの一般の情報システムのような要求仕様定義に対応した検証とは異なり,判断のプロセスに関して論理的に明確な説明はできないことを利用者に伝えることが重要.

★制御可能性に関しては,
 上記と同様の理由により,好ましくない判断結果が生じる場合に,一般の情報システムのようなデバッグはできないことを利用者に伝えることが重要.

★安全に関しては,
 利用者に「設計の趣旨」ではなく,利用上の注意を具体的に示すべき.

★倫理に関しては,
 「学習データに含まれる偏見」に対して「所要の措置を講ずるよう努めることが望ましい」とあるが,特に,リリース後に利用者と対話しながら学習するAIシステムについて,開発者がとれる措置は困難と思われる.むしろ上記と同様に,利用上の注意を具体的に示すべき.

 本件関連の以下の過去のブログ参照:
  共産党批判でサービス停止のチャットボットの再教育とは?(2017.8)
  差別発言した人工知能の学習モデルは?(2016.3)

 なお,日経コンピュータ(2017.8.31)の記事「『根拠を説明できるAI』へ配慮を求める総務省のAI開発指針案,世界に提案」の中の以下の記載が気になる.たとえば,自動運転システムにAI技術が組み込まれて事故を起こせば製造物責任法の対象になると思われる.
(引用)
「『AI開発に製造物責任の考え方は馴染まない』との意見が主流で,開発者に結果責任を負わせる要素は含んでいない.総務省は開発ガイドラインについて,『AI開発者を守るためのもの』と強調している」

以上


2017.8
共産党批判でサービス停止のチャットボットの再教育とは?


【第1報】
 8/4の朝日に記事 「SNSで交流、AI口滑らす? 共産党批判でサービス停止」によると,
 中国IT企業が提供するチャットボット「ベビーQ」は、利用者と対話を繰り返して学習し、
軽妙な会話ができるが,ユーザーからの質問に共産党批判で答えたことから急きょサービスを停止した。
(例)
 Q:「共産党万歳」 →A:「こんなに腐敗して無能な政治のために万歳できるのか」
 Q:「あなたの『中国の夢』は何?」 →A:「私の『中国の夢』は米国への移民」

【第2報】
 8/10の朝日の記事 「共産党批判の中国AI、再教育?」によると,
(例)
 Q:「共産党は好きか」(繰り返し質問) →A:「話題を変えませんか」
(別のチャットボット「小冰」の例)
 Q:「共産党が好きか」 →A:「あなたは(答えが)分かっているでしょう。話題を変えよう」
 Q:「中国が好きか」 →A:「シーッ。今、人生について考えている」

■ 2016.3に,これと類似の現象として,
 人工知能を使ったマイクロソフトのチャットボットTay(テイ)が
ツイッターで差別発言をして、公開から1日足らずで実験中止になっている.
この件は,以下のブログでも取り上げた.

  「2016.3差別発言した人工知能の学習モデルは?」

 このブログでは以下の3種類の対策案を示したが,
今回の中国での『再教育』は,どの対策だっただろうか?

●『再教育』という表現に近いのは,
 「その矯正をする担当者との対話学習のみ実施する」という3番目の対策だが,
●上記のQAの例から推測すると,
 「その関連の知識(発言)が入力されると警告する」という2番目の対策だったかも.

★対策として望ましいのはどれ? (2016.3のブログから引用)

 ・善良な市民として選別した者とだけ対話学習をするようにする.
       (選別されていない一般人とは,対話はするが,学習はしない)
 ・反社会的な思想に関する知識を常に排除するフィルターを組み込む.
       (その関連の知識(発言)が入力されると警告する)
 ・差別発言をするようになった時点で,一般人との対話を一時中止する.
       (その矯正をする担当者との対話学習のみ実施する)
以上


2017.7
東電システム障害の真相が明らかに?


 日経コンピュータ(NC)の7/6号に下記の記事(pp.12-15)が掲載されている:
「電力自由化で電気料金を請求できず 東電システム障害の真相が明らかに」
この記事で,下記の東京電力パワーグリッド(東電PG)の公表pdf資料に言及している.
「確定通知遅延等に対する反省とそれを踏まえた今後の対策」(2017年6月7日)

【システム障害の概要】

・2016.4に,1週間前に稼働開始の新システムで電力使用量の把握ができず,
 料金請求できないケースが発生し,最大3万件にまで達した.
・原因究明と改修作業の完了は,障害発生から7か月後の11月になった.
・主な原因は,スマートメーターへの取り換え時の登録情報に関する人的ミスと
 システム側がそのミスに伴うデータ不良を想定していなかったことだった.

【ソフトウェア工学の観点でのコメント】

・最大の問題は,開発体制ではない
 NC記事では,東電PGがシステムの不具合を見抜けなかった最大の問題は,「業務を熟知するテプコシステムズ」が開発プロジェクトに参加せず,発注者側の支援を担当するという開発体制にあるとしているが,この指摘はおかしいのでは?
 要求仕様の定義責任は発注者側にあり,「日本国内では前例のない制度」のシステム化なので,「業務を熟知するテプコシステムズ」が発注者側支援を担当したことはむしろ適切な判断と思われる.

・最大の問題は,要求定義不良
 発注者側がしっかり要求仕様を定義すべきだった.
 特に,旧型メーターからスマートメーターへの取り換え作業に伴うユーザの電力使用量のデータに関するデータベースの過渡的な状態をすべて洗い出して要求仕様に反映すべきだった.
 記事には,「情報登録が遅れたり,誤った情報を登録したりするなど,東電PGが想定していない事態が発生した」とあるが,過渡期の人的作業に関するリスク管理が要求仕様に反映されるべきだった.

以上


2017.6
情報処理技術遺産 Fortran&HARP 認定


 情報処理6月号掲載の情報処理技術遺産認定8件の中に
学生時代の懐かしい以下の2件があった.

(1) HARP 5020関連資料(国産初の最適化コンパイラ)
「新設された東京大学大型計算機センターの初代計算機HITAC 5020のFORTRANコンパイラとして多くの研究者に利用された.」

(2) JIS FORTRAN入門(上)(下)
「1960年代後半・・・本格的なプログラミング教科書として出版された本書は,・・・多くの学校や企業の演習テキストとして使われた,記念碑的な書籍である.」

私の修士論文「思考過程の数学的表現と模擬実験」の研究(1969〜1971.3)では,
上記2件と関連したFORTRANプログラムをもちいて,ニューラルネットワークの
シミュレーションを実施した.(当時は,第一次AIブームだった)

 → 「懐古趣味にて、詳細別紙」


2017.6
「展示会で,学生お断り」の変更


 今月の第1回AI・人工知能 EXPOの招待券の来場者登録欄に
「18歳未満の方のご入場はお断りいたします」と記載されていた.
以前のブログ(下記)で「学生お断り」にコメントしている.

・2011.11「展示会で,学生お断り? IT業界の再考を求む!」

「学生お断り」が「18歳未満お断り」に緩和されたのは歓迎したい.
私の研究室では,例年,関連する展示会にゼミの学生を参加させ,
興味深い展示内容をレポートさせていた.
2011年に学生の入場を断られたので,以後,この学外実習を中止した.

追記(2017.10.19)
 2017.11のJapan IT Weekの招待券では,残念ながら
 「学生の方および18歳未満の方のご入場はお断り」と記載され,学生お断りが復活している
 但し,ホームページは「18歳未満の方のご入場は固くお断りしております」のまま


2017.5
日本臓器移植ネットワークのプログラムミスとは


 日本臓器移植ネットワークのプログラムミスで,3人が心臓移植の順番待ちを飛ばされたとのこと.
(日経コンピュータの関連記事(2017.5.9))

【ソフトウェア工学の視点でのコメント】

★今回のプログラムミスでは,
 〔 IF(条件)THEN(処理) 〕の判定文の条件が常に偽となり,
処理が常に実行されないことになっていた.このミスは,テスト工程において,
すべての処理を1回以上テストしたかというチェックをしておけば検出できたので,
このきわめて基本的なチェックをしていなかったことになる.

★「テスト工程が短縮された理由は、追加開発が大量に発生したためだ」とあるが,
そもそもの疑問として,信じがたいことではあるが,
テスト工程の終了条件が適切に設定されていなかったと考えられる.



2016.12
番外編:メルボルン訪問2016→1980→1956


 国際会議での論文発表のため、12月上旬に,はじめてメルボルンを訪れたが,
メルボルンについては、以下の思い出がある:

 *1980年の世界コンピュータ会議IFIP80(東京とメルボルンの共同開催)
  「なぜ私の発表がメルボルンではなく、東京なの?」

   → 「懐古趣味にて、別紙」

 *1956年のメルボルン・オリンピック
  「なぜ男子1500m自由形が金ではなく、銀メダルなの?」

   → 「懐古趣味にて、別紙」


2016.11
 1枚のカードからATMシステム停止となったプログラムミスとは


日経コンピュータ(2016.11.10号)の記事:
「地方銀行4行 勘定系の負荷急増でATM取引停止」によると,

【要約】
1.磁気情報の一部が壊れているキャッシュカードが
 他行口座宛ての振り込み操作に使用された.
2.勘定系システムの業務タスクは,磁気情報のうち,
 自行のシステムで参照する必要のない領域をチェックしなかったが,
 その領域に異常コードが書き込まれていた.
3.勘定系システムの制御タスクは,受け取った磁気情報を、
 統合ATMセンターの仕様に合わせてコード変換し送信しようとしたが,
 異常なコードのために変換できず、送信できなかった.
4.勘定系システムのタイマ監視タスクは、統合ATMセンターから30秒以内に
 応答がなかったので、制御タスクに取消コマンドの送信を依頼したが,
 制御タスクは取消コマンドを送信できずにエラーとなった.
 この送信依頼が2秒間隔で発生し、勘定系システムのメモリーを埋め尽くし、
 取引の停止という事態に陥った。

【ソフトウェア工学の観点での疑問】

★制御タスクは,ATM入力情報を送信できなかったにもかかわらず,
 タイマ監視タスクは,統合ATMセンターからの応答の有無をチェックした??
 ↓(推測)
 本来,制御タスクから統合ATMセンターへの送信と同時に
 タイマ監視タスクは監視を開始すべきだったにもかかわらず,
 実際は制御タスクが送信のためのコード変換開始時点で監視を開始していた!

★制御タスクの設計・実装者は,
 統合ATMセンターの仕様に合わせたコード変換処理において,
 入力コードの不良の可能性を見逃して,上記の処理手順を実装したのでは!



2016.10
 「受援力」強化にはIT活用が不可欠!


10/14のNHKニュースの中で「受援力」という用語を知った.
政府広報オンラインの 防災ボランティア活動を受け入れる地域の“受援力”高めよう
には,以下の記述がある:
「災害時には、・・・多様なボランティアを受け入れる
 環境や知恵=「受援力」を高めておくことが重要です」

関連する政府のパンフレット 地域の『受援力』を高めるために」 では,
災害時に設置される災害ボランティアセンターが,
被災地での防災ボランティア活動を円滑に進めるための拠点,とのことであるが,
被災地のニーズの把握,ボランティアの受け入れ,人数調整などの記載の中に,
ITの活用がないのには少々驚いている.

★当研究室では,エンドユーザ主導開発技術の研究の一環として,
★マッチング分野に特化した技術開発を行ってきた.

例えば,2014.8の広島の土砂災害では,多数のボランティア希望者がいたが,
自治体職員の対応の限界から,必要な被災現場への適切な派遣ができなかった.
2016.4の熊本地震では,多くの支援物資が当該自治体までは届いていたが,
必要な避難所への支援物資のタイムリーな配送ができなかった.

被災地で繰り返されるこのような問題の解決には,
ボランティアや救援物資に関して,
★サービスや物の提供側と要求側の自動マッチングのWebサイトを
★現地の自治体職員などにより簡単に立ち上げられるようなシステムが
★受援力強化に不可欠と思われる.

(当研究室の参考資料)
ユーザ/システムビューに基づくマッチングサイトの調査・分析,
情報処理学会ソフトウェア工学研究会要求工学ワーキンググループ
第49回ワークショップ (May 2015).

マッチングシステムを例題としたエンドユーザ主導開発方式に関する考察、
電子情報通信学会 技術研究報告 Vol.114, No.292,
知能ソフトウェア工学研究会 KBSE2014-28, pp.1-6 (Nov. 2014)


2016.9
 アクティブ・ラーニングは「議論自由」のこと?


数年前から「アクティブ・ラーニング」の話題をよく目にするが,
最近では学習指導要領改訂との関連でも・・・

文部科学省の   用語集 によると,【アクティブ・ラーニングとは】
  教員による一方向的な講義形式の教育とは異なり、
 ★学修者の能動的な学修への参加を取り入れた教授・学習法の総称。

私の議論重視の方針である 議論自由にも近い概念なので,
以下の関連授業について,別紙 <詳細こちら> で述べる.
 ・「ゼミナール1」      グループ・ディスカッション
 ・「ソフトウェア工学・演習」 グループ・ディスカッション

以下の過去のブログで言及した「教える授業から学ぶ授業へ」
「社会人基礎力」とも関連がありそう・・・

2011.4 頭がいいのに「分かる」ことができない新卒たち
2009.8 大学教育の質の保証の3種類の視点
2008.3 産学官連携による高度IT人材育成に死角あり

(追記:2016.10.19) 初期の電子討論の内容を記載した
「パソコンとインターネットを用いた実験授業(PCプロジェクト)」の報告書:
<中所担当分の送付原稿>
  最終報告書,   明治大学情報科学センター, pp.64-69 (1999.3).
  中間報告(2), 明治大学情報科学センター,Vol.2, pp.52-57 (1998.6).
  中間報告(1), 明治大学情報科学センター, Vol.1 , pp.62-68 (1997.5).


2016.9
 大人の脳(海馬)の新生ニューロンが記憶力を左右する


 NHK教育テレビ(2016年9月4日)の サイエンスZEROの番組
「“記憶”のミステリー ~最新脳科学が解き明かす記憶の正体」について:

内容の一部が私の卒業論文の概念に類似。

 ・新生ニューロン → 卒論では、自由なニューロン

番組の内容など、 <詳細こちら>


2016.9
番外編:チャスラフスカの逝去を悼む


 1964年の東京オリンピックの体操女子で3つの金メダルを獲得し、
「東京の恋人」とも呼ばれたチェコのベラ・チャスラフスカさんが
8月30日に亡くなったとのことである.

 このニュースをきいて,すぐ思い出したのは,
学部4年生の時の4週間の国鉄での実習(現在のインターンシップ相当)の
報告書の最後に以下のように記したことである.
 「10月24日 チャスラフスカの優勝を喜びつつ」
これは,東京ではなく,1968年のメキシコオリンピックのときである.
実習報告書の記述内容として不真面目では!?

 (懐古趣味にて→ 詳細はこちら


2016.8
人工知能60周年における第1次,第2次ブームでは


人工知能学会誌(2016年7月)の 「創設30周年記念特集」で,
第1次,第2次ブームに言及する記事があるが, これには私にもかかわりがある.

 ・第1次ブームでは,学生として卒論,修論の研究テーマにAI関連を選択.
 ・第2次ブームでは,企業の研究所においてAI関連業務に従事.

本ブログでも,2006.7に「人工知能50周年」を取り上げて以来, 十数回,AI関連を取り上げた.
今年度は「人工知能60周年」に当たるので, 以上の関連を別紙にまとめた.

 (懐古趣味にて→ 詳細はこちら


2016.6
利息計算を手作業で10年以上実施してきたシステムとは?


選択(2016年04月号)の記事 「イオンカードで大量「過剰請求」」について:
【業務システムに関する要点】
・2005.3の更新システムでトラブル発生
 このシステムは「利息の日割り計算ができない」
 システム障害以降、すべて手作業で対応してきた
・2015.4にカード利用に伴う利息の過剰請求が顧客の指摘で判明
 金融庁は過去10年間に遡って調査するよう指示
 その結果、約2400件のデタラメな利息請求事案が判明

日経コンピュータ(2016.6.9)の関連記事 「イオン銀行 10年にわたって利息を過剰請求」について:
【業務システムに関する要点(上記の追加)】
・業務システムは仕様上の不備があり、日割り計算を自動処理できない仕組み
・日割り処理をする機能そのものは存在したが、
 一部入金時までの利息は正常に計算できるものの、
 一部入金後の利息計算を実行しないという不具合があった。
・10年前まで遡って取引状況を再現するシミュレーションツールを開発
 2016年1月に、過剰請求の対象顧客と返金額を特定

<★ソフトウェア工学の視点での素朴な疑問>
・利息計算は規則が明確なので,大学のプログラミング実習レベルの難易度と思われ る
・記事内容「仕様上の不備があり、日割り計算を自動処理できない仕組み」について
 その仕組みとは??
・記述言語が不明だが,一部入金時までの利息は計算でき,
 一部入金後の利息計算はできない処理方式とは??


2016.5
新幹線の電光掲示板故障の本当の原因は?


 大型連休後半の4日、JR東日本管内の東北、上越、北陸各新幹線の全44駅で、
行き先や発車時刻を知らせる電光掲示板が表示されないトラブルが発生した。

<故障の原因>
 連休で増発した列車本数が表示システムの上限を超えたことが原因。
同システムは2日分で計1600本が登録できるが、
3〜4日の列車本数は1606本だった。 ( 関連記事

★5年前に類似障害あり.以下の2011.1のブログ参照.
    新幹線システム障害の本当の原因は?
(要点)
 雪の影響でダイヤを一度に変えた結果、変更箇所の表示件数の
 上限600件を超えた時点ですべての表示が消えた

<ソフトウェア工学的観点での疑問>
・システム開発時に処理能力の上限を設定した場合,
 必ず上限超過を検出するプログラムコードを作成しておくべきだが,
 担当者が開発時点で上限超過はありえないと判断してしまい,
 数年後に想定外のシステム障害を起こす事例が後を絶たない.

<ブログで言及した事例の列挙>
・今回のブログ :新幹線の電光掲示板故障の本当の原因は?
・2016.2のブログ: オーバーフローのチェック漏れがなくならない
・2015.6のブログ: オーバーフローのチェック漏れがなくならない
・2011.1のブログ: 新幹線システム障害の本当の原因は?
・同上のブログでも言及した事例:
 1995.12にみどりの窓口の特定タイプの端末が数時間動作しなかった原因は,
 その10年前に作成したプログラムで管理できる端末数の上限が2047台となっていたのに,
 2200台まで増設したことにあった.


2016.5
衛星「ひとみ」がプログラムのミスで運用断念とは残念!


新聞記事(2016.4.29) 「信号ミス、制御失う 回転止められず 衛星「ひとみ」断念」 によると,
「プログラムの不具合に人為的なミスも加わって衛星が高速回転し、
遠心力で太陽電池パネルが分解したことが原因だった」とのこと

5年前の小惑星探査機「はやぶさ」による小惑星イトカワでのサンプル採取のための弾丸の不発の原因も
プログラムミスだった.詳細は以下のブログ参照:
2011.7 はやぶさの弾丸不発の原因がプログラムミスとは残念!

<関連記事,資料>
記事: 「衛星「ひとみ」の運用断念 人為的ミス一因か」

記事: 「「ひとみ」指令ミスで誤噴射、太陽電池が破断」

国立研究開発法人宇宙航空研究開発機構(JAXA)の発表資料(2016.4.28)
「X線天文衛星ASTRO-H「ひとみ」の今後の運用について」
および
「X線天文衛星ASTRO‐H「ひとみ」の今後の運用に係る補足説明資料」

★<ソフトウェア工学の視点でのコメント>
・プログラムのミスの内容が公開されていないので,推測になるが,
 地上での網羅的なシミュレーションテストが不十分だったのでは.
・はやぶさの時に,担当者の反省として,「シミュレータで点火装置を対象外にしていたので,
 シミュレーションによる動作確認でミスを検出できなかったとのことであるが,
 今回もテストが不十分だったと推測できる.
・2011.7のはやぶさのブログで,「シミュレーション実行された命令を
 人間にわかりやすく表示するツールが欲しかった」と述べたが,今回にも通じるか?
・予算310億円のうち,ソフトウェア開発の予算はいくらだった?

<追伸:2016.6.2>*****************************
記事: 衛星「ひとみ」分解、重ねた単純ミス 姿勢制御の設計に甘さ・数値入力に誤り
(要約)
 JAXAの説明によると、以下の大きな二つの失敗あり:
(1) 姿勢制御プログラムの設計が不十分
 観測に適した姿勢になるため明るい星を基準に調整する仕組みだが、
 明るい星をうまく見つけられず正しく動かなかった。
(2) このような場合、地上操作で姿勢を直す設計だったので,
 2月に,自動で姿勢を整える「セーフホールドモード」で使う噴射の設定値を
 実際のひとみの状態に合わせて変更した。
 この際、担当者が、プラスにすべき設定値をマイナスで入力し,異常回転を加速させた。
 担当者が使ったのは開発用のプログラムでマニュアルもなかった。

★<ソフトウェア工学の視点での追加のコメント>
 改革策「プロジェクト管理と科学的な成果に責任を持つ役職を兼務しない」について,
さらに,全体のプロジェクト管理者とは別に,
ソフトウェア専任のプロジェクト管理者を置くべきと考える.

<追伸:2016.7/18>*****************************
日経コンピュータ(2016.7.7)記事: 衛星「ひとみ」が上空で分解 手入力したデータにより誤動作

(担当者の設定ミス「プラスにすべき設定値をマイナスで入力」に関する新たな情報)
(1) 設定値に関して,担当者が専用のソフトウエアで計算し、
 その結果を別のソフトウエアに手作業で転記する手順だった
(2) 社内では「最初のソフトの計算結果が負の値は、絶対値に修正して転記する」
 というノウハウを蓄積していた
(3) このノウハウは、運用マニュアルには明記していなかった
(4) 担当者は初めての作業で、このノウハウを知らず、負の値をそのまま入力

★<ソフトウェア工学の視点での追加のコメント>
・運用マニュアルの記載漏れは論外!
・さらに,設定値を計算する「専用のソフトウエア」について,
 上記の追伸(2016.6.2)での「開発用のプログラムでマニュアルもなかった」とのこと.
 このソフトウェアの開発者は,自分が使うつもりでプログラムを作成したと推測する.
 他人に使わせる可能性があるなら,本来,利用マニュアルまたは仕様書が必須だが,
 少なくとも,入力や出力に関して,最低限の説明を表示しておくべきだった.