News2olds:知新 → 温故

一覧 
  *** 月刊(?)ウェブログ風の寸評 ***

 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)

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
機械学習工学とソフトウェア工学の共通点と相違点


  【別紙参照】

 以上


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開発ガイドライン案◆複腺紐発原則案の解説)」
について,率直なコメントを   別紙(★印) に記載した.

<要点>
 開発原則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)での「開発用のプログラムでマニュアルもなかった」とのこと.
 このソフトウェアの開発者は,自分が使うつもりでプログラムを作成したと推測する.
 他人に使わせる可能性があるなら,本来,利用マニュアルまたは仕様書が必須だが,
 少なくとも,入力や出力に関して,最低限の説明を表示しておくべきだった.