News2olds:知新 → 温故

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

 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)

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

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