News2olds：知新 → 温故
一覧　
　　＊＊＊　月刊（？）ウェブログ風の寸評（過去のもの）　＊＊＊ 　　　→　 最新のブログはコチラ


　● 2016.4　宝くじシステムの異常停止は，要求仕様とテストのいずれのミス？
　▼ 2016.4　（続）マイナンバーのシステムの不具合の原因がわからない？
　● 2016.4　番外編：齋藤正男先生の逝去を悼む
　● 2016.3　番外編：Marvin Minsky の逝去を悼む
　▼ 2016.3　差別発言した人工知能の学習モデルは？
　▼ 2016.3　新国立競技場の設計と工費に見る情報システムとの類似性（２）
　▼ 2016.3　マイナンバーのシステムの不具合の原因がわからない？
　● 2016.2　オーバーフローのチェック漏れがなくならない

　▼ 2015.12　番外編：「眠りの深さが世界の意味」とは
　● 2015.12　自動車の自動運転（右折はまだ苦手）に一言
　● 2015.11　「オートメーションサプライズ」について
　▼ 2015.11　番外編：女性プログラマの元祖 Ada Lovelace 生誕200年
　▼ 2015.11　番外編：長崎開催のパグウォッシュ会議閉幕
　● 2015.11　奨学金返済の延滞の有無の判断プログラムのミス
　▼ 2015.10　防災システムのブラウザ依存の不具合を2年間放置
　▼ 2015.10　株の誤発注裁判で最高裁が双方の上告を退ける決定
　▼ 2015.9　メタボ検診： システムのミスで十分活用できず
　● 2015.8　番外編：なつかしのヴィゴツキーが人工知学会誌の学習に関する論文で引用されている
　● 2015.8　新国立競技場の設計と工費に見る情報システムとの類似性
　▼ 2015.7　スルガ銀-IBM裁判で最高裁が上告を棄却
　● 2015.6　オーバーフローのチェック漏れがなくならない
　▼ 2015.6　興味深い次期東証システムの「二者設計」
　▼ 2015.6　次期の東証システムでの誤発注対策
　● 2015.3　日本のソフトウエアは45年を経てどこまで来たのか

　● 2014.12　物流管理システムの構築中止で38億円の損害賠償裁判の原因は？
　▼ 2014.11　“ぼんやり”に潜む謎の脳活動
　▼ 2014.11　結晶性知能と流動性知能　→　学習度と学習エントロピー？（２）
　● 2014.8　番外編：フォン・ノイマンと長崎
　● 2014.8　プログラムミスでの失業手当過払いの責任は発注側か製造側か？
　▼ 2014.8　出版界が縮小の一途（売上高は17年間で35％減）
　● 2014.8　特許庁システム開発中止の後日談
　▼ 2014.7　高額療養費の処理システムで要求定義ミス
　▼ 2014.7　番外編：なつかしのヴィゴツキーが汎用人工知能ＡＧＩで注目されている
　● 2014.6　番外編：なつかしの人工知能
　● 2014.5　企業システムへのアジャイル開発適用時の当たり前
　▼ 2014.5　普及している通信暗号化ソフトのお粗末なプログラミングミス
　▼ 2014.4　全銀協の決済システムの目玉機能の利用ゼロとは？
　▼ 2014.4　豪雪で学校連絡網が機能しなかったバグとは？
　● 2014.3　厚生労働省のナショナルデータベースで要求定義ミス
　● 2014.1　コンピュータが1000万枚の画像から猫を認識したというのはホント？

　● 2013.12　言語処理系における中間語の標準化の夢？
　▼ 2013.12　番外編：（昭和史再訪）「期待される人間像」について
　▼ 2013.11　続：イプシロンロケット試験機打上げ中止の原因
　● 2013.9　イプシロンロケット試験機打上げ中止の原因
　● 2013.9　国交省の予定価格積算システムの不具合の最終責任は？
　▼ 2013.8　株の誤発注裁判で控訴審も第一審と同額賠償の判決！
　▼ 2013.8　番外編：懐かしの磁気テープの需要拡大
　▼ 2013.7　クラウドソーシングでＩＴ技術者の高給化は実現するか？
　● 2013.6　世界に通用するITを育てない罪
　● 2013.4　企業の採用活動開始を12月から４月に遅らせることに
　● 2013.3　気象庁（予報）のスパコンの停止の真の原因は？
　▼ 2013.1　電子行政オープンデータ戦略への期待

　▼ 2012.9　東証-みずほ誤発注裁判でプログラム修正後の構造テストも争点に
　● 2012.8　東証-みずほ誤発注裁判でプログラム修正後の回帰テストが争点に
　● 2012.7　Alan M. Turing 生誕100周年
　▼ 2012.7　パッチ適用プログラムのミスでデータセンタのユーザファイル消去とは
　▼ 2012.6　スルガ銀-IBM裁判の判決（約74億円支払い命令）全容が判明
　▼ 2012.5　IT業界就職人気ランキングにおける「技術力」と「成長性」
　▼ 2012.5　ITのトレンドはOSSが主導　→『地球規模のソフトウェア生産性』
　● 2012.4　分割発注に懲りて，マイナンバーシステムは一括発注とか？
　● 2012.3　番外編：Automata Studies（1956年出版）が今も販売されている
　● 2012.2　特許庁情報システムの開発中断で55億円が無駄とは
　▼ 2012.1 「ワーキングメモリ」という用語が物忘れの説明に使われていた

　● 2011.12　番外編：パグウォッシュ会議を覚えていますか？
　● 2011.11　展示会で，学生お断り？　ＩＴ業界の再考を求む！
　▼ 2011.10　番外編：米アップルの創業者、スティーブ・ジョブズ会長が逝去
　▼ 2011.10　愛媛県と愛知県の電子入札のお粗末なシステム
　▼ 2011.8　都後期高齢者医療広域連合のお粗末なシステム
　● 2011.7　はやぶさの弾丸不発の原因がプログラムミスとは残念！
　● 2011.6　あわや航空機事故（またもや，自動操縦と手動操縦の対立が原因）
　▼ 2011.5 番外編：劇団唐組の東日本大震災お見舞い公演『ひやりん児』
　● 2011.4 みずほ銀行の振込み処理トラブル
　● 2011.4　頭がいいのに「分かる」ことができない新卒たち
　● 2011.3　医師の入力と異なる投薬を指示する電子カルテシステムのバグ
　● 2011.3　引っ越しワンストップサービスの最近の事情
　▼ 2011.3　番外編：大相撲八百長問題に一言
　▼ 2011.2　ＩＴが招く本屋の危機
　▼ 2011.2　トヨタ自動車の電子制御システムにソフトウェア不良は見つからず
　● 2011.1　新幹線システム障害の本当の原因は？
　● 2011.1　経団連の「新卒者の採用選考活動の在り方について」の提言に苦言

　▼ 2010.11 自動車はすでに「情報システム」である！
　▼ 2010.11 浮き彫りになったソフトウェア開発実態の変化と今後の動向
　● 2010.7　新たな情報通信技術戦略は国民本位の電子行政を実現する？
　● 2010.5　「死後１００年は世に出さぬ」遺志を保証（？）する特許
　▼ 2010.2　アクセルよりブレーキを優先させるブレーキオーバーライド
　● 2010.2　トヨタ自動車のＡＢＳの制御プログラムの問題

　▼ 2009.12　東証の誤発注問題の415億円の損害賠償裁判に東京地裁判決
　▼ 2009.11　いつまで繰り返す電子政府の電子申請システムの無駄
　● 2009.8　大学教育の質の保証の３種類の視点
　● 2009.6　「品質が高いプロジェクトは人月単価も高い」という仮説を立証できず
　▼ 2009.6　情報サービス産業の一人当たりの年間売上高
　▼ 2009.5 還暦を迎えたプログラム内蔵方式の実用コンピュータ
　● 2009.3 Barbara.Liskov のチューリング賞受賞を祝う
　● 2009.2 中華航空機事故（264人死亡）の教訓は生かされなかった？
　▼ 2009.1 システム開発プロジェクトの成功率が５年前より上昇！？

　● 2008.8　東証の派生売買システムの障害は限界値テストで防げたはず？
　▼ 2008.5　結晶性知能と流動性知能　→　学習度と学習エントロピー？
　▼ 2008.5　要件定義書に「現行と同一」という記載はありか？
　● 2008.3　４０年近く前に読んだヴィゴツキ−の「思考と言語」が注目されているらしい
　● 2008.3　４０年近く前に読んだノイマンのセルラーオートマトンが注目されているらしい
　▼ 2008.3　産学官連携による高度IT人材育成に死角あり。
　▼ 2008.3　中華航空機墜落事故のエアバス社の製造物責任を認めず（名古屋高裁）
　▼ 2008.1　高校卒業程度認定試験の採点ミスは限界値テスト（？）で防げたはず

　● 2007.11　 IT業界で再々委託全面禁止の動き → 受験生のIT関連学科希望増加
　▼ 2007.11　大幅な追加テストは仕様変更？
　● 2007.8　（続）長崎県庁システムとエンドユーザ主導開発
　▼ 2007.7　（続々）初任給に格差 → イノベーション
　● 2007.7　大規模システムの深刻な障害の多発の原因
　▼ 2007.5　東証の誤発注事故（05.12）は分岐テストで防げたはず
　● 2007.2　Ｊａｖａ言語のオープンソース化

　▼ 2006.12　番外編：唐十郎特別展
　● 2006.9　知財立国（特許査定率）
　▼ 2006.7　人工知能５０周年
　● 2006.5　（続）初任給にスキルによる給与格差 → 大学改革
　▼ 2006.4　e-Japan戦略からIT新改革戦略へ
　● 2006.1　初任給にスキルによる給与格差

　● 2005.11　リファクタリング
　● 2005.9　長崎県庁システム（長崎ITモデル）
　▼ 2005.7　ＭＤＡ，モデル駆動型開発
　● 2005.5　Ｊａｖａ言語１０周年
　▼ 2005.4　ＴＤＤ（テスト駆動型開発）と単体テストツール
　● 2005.3　Ｗｅｂサービス連携
　▼ 2005.2　Ｅｃｌｉｐｓｅ


2016.4
宝くじシステムの異常停止は，要求仕様とテストのいずれのミス？

日経コンピュータ(2016.4.28) 「宝くじの販売データに不整合　新システムが異常終了し抽選できず」
の記事：2/1のナンバーズやロトの抽選開始時刻に宝くじシステムが異常停止した事故について：

＜概要＞
・ある販売店で業務中に入れ替えた新しい発券端末機が発行した通番が、
　すでに当日に従来端末機が発行済みの通番と重複していた。
・本番系と待機系の販売金額や件数のデータ照合で相違を検出し異常終了した．
　　＊待機系は、販売データの通番が重複するとエラー処理していた．
　　＊本番系は、端末機の入れ替えを想定し、同じ通番でも正常処理していた。
・発注側はメーカに、発券端末機の応答速度を上げるために、
　本番系と待機系は同じ実装でなくてもよいと伝えていた
・販売データの通番が重複するテストケースの作成が漏れていた

＜ソフトウェア工学の観点での疑問点＞

★通番の構成要素が不明であるが，
　「ある販売店で数台の発券端末機を業務中に入れ替えた」
　という表現があるので，端末機には固有の識別番号があったはず．
　「同一の販売店からの同じ通番のケースをエラーとして処理」
　という表現があるので，販売店には固有の識別番号があったはず．
　本来は＜販売店識別番号＋端末機識別番号＋通し番号＞を通番とすべきだった．

★要求仕様書または機能仕様書に通番の重複に関する記載の有無は？
★上記の記載があったのに，通番重複のテストケースが作成されなかった？
★構造テスト（ホワイトボックステスト）はしていない？？
　分岐網羅テストを実施していれば，該当部分のテスト未実行が明確になったはず！


2016.4
（続）マイナンバーのシステムの不具合の原因がわからない？

2016.3のブログ 「マイナンバーのシステムの不具合の原因がわからない？」
では，朝日新聞の記事(2016.3.6)を引用したが，
日経コンピュータの記事（2016.4.14） 「マイナンバーカード発行が全国で遅延」
でも，「原因究明が難航、正常化に至らず」の状態が続いているとのこと．
前者の記事では，「最も不具合が多い１台を交換」まで記載されており，
後者の記事では，以下の通り：
・その不具合を分析し，装置間の連携処理プロセスの異常終了多発を突き止め，
　処理プロセスを改良したが，処理遅延は改善されず
・検証に使える本番環境の空き時間がないので，原因究明が難航
・3月末時点でも，問題の再現や改良に手間取っている

★原因究明には，本番環境を使った検証が必要のようだが，
　本番環境の監視とログ分析だけで，処理時間の異常な部分を
　見つけられないのだろうか？？

（参考）
　3/22のＡＮＡシステム障害では，
本番環境相当のテスト環境でスイッチの故障を見つけている．
以下，日経コンピュータの記事（2016/04/12）
「判明、ANAシステム障害の真相」 には，以下の記述がある．

＜引用＞
　監視システムのログなどからDBサーバー、アプリケーションサーバーと
　順に障害を疑い、異常がないと判断した。
　残ったのがインターコネクトのスイッチ「Catalyst 4948E」だった。
　「本番環境と同等の作りにしてあるテスト環境にスイッチを
　持ち込んでテストしたところ、不具合が再現した」（ANA広報）。


2016.4
番外編：齋藤正男先生の逝去を悼む

　私の学生時代（卒業論文，修士論文）にご指導いただいた恩師，
齋藤正男先生（東京大学名誉教授）が３月にご逝去されました．
　　（同窓会の通知）

先生の研究歴の一端は，昨年10月にご自身で執筆された
　　「温故知新か ? 振り返れば迷いの森／齋藤正男」
で，ご覧いただくことができます．

奇しくも２月に亡くなられたMarvin Minskyの著書Perceptrons（1969年）の
翻訳書「パーセプトロン」を1971年に出版されています．

【＊＊＊】
・大学２年の進学希望学科を決める前に，電気系学科の学生相談員の齋藤先生を訪問し，
　「ラジオなどを自分で作った経験がなくても大丈夫でしょうか」と尋ねると
　「そのような経験がないほうがよいと考える教員もいる」と答えていただいて，
　電気系学科を第一希望に決めさせていただいた．
・大学３年の卒業研究の希望研究室を決めるとき，各研究室の募集人員は４名で，
　齋藤先生から電気回路関連２件と生体工学関連２件のテーマが提示され，
　生体工学関連テーマで希望させていただいた．その後，修士課程に進学．
　・・・
　・・・
・最近では，下記の貴重な著書をお送りくださり，
　その一部（★印）は私の授業でも使用させていただいた．

　■「仮想世界は人間を救うか」（2016/1/29）
　■「ハイテクと仮想の世界を生きぬくために」（2015）★
　□「電気回路・システム特論」（2011）
　■「ケータイで人はどうなる」（2009）
　□「電気回路・システム入門」（2006）
　■「制御と学習の人間科学」　（2005）
　■「ＩＴで人はどうなる」　　（2003）

以上


2016.3
番外編：Marvin Minsky の逝去を悼む

　3/28のCommunications of the ACM Digital Editionのメールに，
Marvin Minsky: 1927-2016 のニュースがあり，逝去を知る．

　すぐに思い出すのは，ニューラルネットワークの古典ともいえる
著書「パーセプトロン」と人工知能における知識表現「フレーム」である．
以下の著作物で引用している．

【著書「パーセプトロン」】
・修士論文「思考過程の数学的表現と模擬実験」（March 1971）で引用

【知識表現「フレーム」】
・著書「人工知能」（昭晃堂 (Aug. 1988)）で引用
・著書「ソフトウェア危機とプログラミングパラダイム」（啓学出版 (Aug. 1992)）で引用
・著書「ソフトウェア工学」（朝倉書店 (May 1997)）で引用

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


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

　人工知能を使ったマイクロソフトのチャットボットＴａｙ（テイ）が
ツイッターで差別発言をして、公開から１日足らずで実験中止とのこと。
（参考サイト）
・ 人工知能が差別発言、マイクロソフトが黙らせる
・ 米マイクロソフトの人工知能、ツイッターで差別発言連発

（要点）
・チャットを通じて新しい言葉を覚え、会話能力を身に着ける仕組みだった
・大量の差別的発言を学習した結果、同様の発言を返すようになった

（疑問）
★採用した学習モデルが単純すぎたのではないだろうか？

私が46年前にニューラルネットワークを用いて，
討論学習による思考の発達段階をシミュレーションしたときに
［幼年期／少年期Ｉ／少年期II／青年期／それ以降］の
５種類の学習モデルを設定したが，
今回のケースは下記の少年期Ｉに相当すると思われる．

・少年期I：学校で教えることを無批判に学ぶL3型

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

******（追伸 2016.3.30）************************************

マイクロソフト社の副社長からの謝罪が掲載されていた． 記事

「あるグループによる組織的攻撃がシステムの脆弱性を食い物にした」
結果として差別発言をするようになったとしても，人間社会にもある現象であり，
学習機能が未熟とは言えないのではないだろうか？

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


2016.3
新国立競技場の設計と工費に見る情報システムとの類似性（２）

　新国立競技場の最初の設計が白紙に戻った件について，
2015.8のブログ 「新国立競技場の設計と工費に見る情報システムとの類似性」
で，以下のように述べた：
・「設計」を「要求定義」に置き換えれば，情報システムと類似性あり
・予算と稼働時期が決定の場合，要求仕様決定には工数見積もりが必須

その後，昨年末に2回目のコンペでＡ案が採用された．
関連記事： 「新国立、大成案「工期順守」決め手」

今回の評価では，各委員の持ち点140点のうち， 半分の70点がコスト・工期に割り当てられ，
そのうちの30点が「工期短縮」の評価項目に割り当てられた．
その結果，委員7名の合計点ではＡ案：Ｂ案は610：602と僅差だったが，
「工期短縮」の177：150の27点差が決め手になった．

★情報システム開発への教訓
　情報システムの開発においても，納期遅延と工数超過の常態化を解消するには
2015.8のブログで述べたように，
「要求定義担当と工数見積もり担当の相補的立場での協力体制が不可欠と思われる．」


2016.3
マイナンバーのシステムの不具合の原因がわからない？

朝日新聞の記事(2016.3.6)： 「マイナンバーカード受け取れない　謎のシステム障害頻発」

（要約）
・１月から動き始めたマイナンバー（社会保障・税番号）のシステムで不具合が続き、
　市区町村の窓口でマイナンバーカード（個人番号カード）が受け取れない事例が
　全国で相次いでいる。
・システムを運営する総務省の外郭団体「地方公共団体情報システム機構」によると、
　不具合の原因は分かっておらず、正常化のめども立っていない。
・総務省幹部談：「５社がそれぞれの担当分野をそれぞれのやり方で作っており、
　原因究明に時間がかかっている」

★ソフトウェア工学的観点での疑問点：

総務省幹部の発言
「５社がそれぞれの担当分野をそれぞれのやり方で作っており、
原因究明に時間がかかっている」とは，不可解！

「５社が共同で」開発したソフトウェアの不具合のエラー箇所を特定するには，
分担したサブシステム間のインタフェースは厳密に定義しているはずなので，
エラー検出箇所から逆方向にバックトレースしていけばよい．

■具体的なエラー原因究明手順：
　例えば，入力からエラー検出箇所まで，サブシステムＡ，Ｂ，Ｃ，Ｄ，Ｅが
この順に実行され，エラー検出箇所がサブシステムＥの実行中だったとする．

(1) ＤからＥへ渡されたインタフェースデータをチェック
　→正しければ，サブシステムＥのエラーの可能性大
(2) 間違っていれば，ＣからＤへ渡されたインタフェースデータをチェック
　→正しければ，サブシステムＤのエラーの可能性大
(3) 以下，同様にチェックを進めれば，
　　サブシステムＡ，Ｂ，Ｃ，Ｄ，Ｅのどこにエラー個所が存在するか判明

また，複数サブシステム間で共通データ経由で情報交換している場合は，
共通データの書き込みデータについても同様のチェックをする．

以上の方法は，複数の会社の共同開発の場合も
社内の複数部署の共同開発の場合も
部署内の複数グループの共同開発の場合も同じ．

★５社の各開発担当のサブシステム間のインタフェースは
　明確に文書化されていなかったか？
★そのインタフェースのテストはどのように実施したか？
　テスト時のインタフェース確認の機能を保守用に残していなかったか？
★エラー発生時に確認すべき項目を明記した保守マニュアルがなかったか？
★そもそも、開発時に５社をまとめる統括責任者はいなかった？


2016.2
オーバーフローのチェック漏れがなくならない

日経コンピュータ　2016.1.21号の記事： 「1日に２度ＡＴＭが利用不能に　ソフト不具合と設定不備が重なる」

（要旨）
・2015年11月24日、三重銀行のＡＴＭやインターネットバンキングが、
　1日に２度にわたり利用できなくなるトラブルが発生した。
・最初，ＤＢサーバー２台のうちの1台の内蔵ディスクに故障が発生したため，
　そのサーバーが担うオンライン取引の処理をもう1台のサーバーに切り替えた．
・１台のＤＢサーバーが全ての処理を担った結果、使用するファイル数が上限値を超え、
　ＤＢサーバーの全機能が停止し，2度目のシステムトラブルが生じた。
・上限値は6万5536（2の16乗）に設定されていた．

★ソフトウェア工学的観点での疑問点：
・上限値を設定する仕様ならば，
　上限オーバーフローのチェックをするプログラムの実装は当たり前では？

　詳細な意見は，以下の類似のブログで記述済み：
＜2015.6 オーバーフローのチェック漏れがなくならない＞


2015.12
番外編：「眠りの深さが世界の意味」とは
　
大晦日の日に新聞の社説 「深くねむるために」 に引用されている鶴見俊輔の次の詩が目に留まった：

　　　深くねむるために　世界は　あり
　　　ねむりの深さが　世界の意味だ

50年近く前の自作の詩の一節：
「その価値を問わず／すべてが眠ってしまった世界」
を思い出し、「眠りの深さが世界の意味」の解釈を知りたくてＷｅｂ検索をしてみた。

引用された詩は私の詩でいいたいことと似ているだろうか？ 　→詳細はこちら


2015.12
自動車の自動運転（右折はまだ苦手）に一言
　
最近，自動車の自動運転の記事・ニュースをよく目にするが，
以下の朝日の記事の「右折はまだ苦手」に目が留まった．
「自動運転、遠い道のり　ブレーキ自在、右折はまだ苦手」

1992発行の拙著「ソフトウェア危機とプログラミングパラダイム」
（啓学出版）の中で，自動車自動運転の右折操作を例にとり，
以下の3種類のルール群の実行順序の制御が難しいことを記載した．

　・交通規則に関するルール群
　・運転操作に関するルール群
　・ルート(P→Q)に関するルール群

→ 詳細はこちら


2015.11
「オートメーションサプライズ」について
　
最近，「オートメーションサプライズ」という用語を知った．
機械の動作に関し，その動作の理由を人間が理解できない状態を意味するようだ．

これまで，航空機の操縦における自動と手動の対立の問題を以下のブログで
言及して来たが，「オートメーションサプライズ」の概念は参考になる．
操縦士が，着陸やり直しの自動操縦における航空機の動作を理解していれば，
中華航空機（264人死亡）の事故は防ぐことができたということになる．

★ソフトウェア設計の視点では，
自動操縦中に手動操縦が実施される場合を想定して，
次のようなメッセージを出力する仕様にしておけばよかった．
「現在，着陸やり直しモードで自動操縦しています．
　手動操縦に切り替える場合は，着陸やり直しモードを解除してください」

（過去のブログなど）
・ 1996.10　ソフトウェア工学の授業での電子ディベート：
　　 「中華航空機事故におけるソフトウェア開発者の責任の有無」について

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

・ 2009.2　中華航空機事故（264人死亡）の教訓は生かされなかった？

・ 2011.6 あわや航空機事故（またもや，自動操縦と手動操縦の対立が原因）


2015.11
番外編：女性プログラマの元祖 Ada Lovelace 生誕200年


　ACMの2015.10.29のメールニュースで，Ada Lovelace (1815-1852)の生誕200年祭の 記事 あり．

彼女は，英国の詩人Byronの娘で、計算手順の自動化をもたらした C. Babbage の協力者で、
女性プログラマの元祖ともいわれる。

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


2015.11
番外編：長崎開催のパグウォッシュ会議閉幕

　2015年11月1日-５日に長崎で開催された 第６１回パグウォッシュ会議世界大会 が閉幕した．

この会議については，4年前のブログ（2011.12） 「パグウォッシュ会議を覚えていますか？」 で言及した．

そのブログでは，以下の別ページで学生時代の記憶に言及した
「パグウォッシュ会議を覚えていますか？　→　はい」

その追記になるが，当時（1967年前後），この会議が注目されたのは，
おそらく，前年に以下の関連会議が開催されていたためと思われる．
第三回科学者京都会議声明(1966)

その冒頭で「人類破滅の危険」が述べられている．


2015.11
奨学金返済の延滞の有無の判断プログラムのミス
●日経コンピュータ（2015.10.27）の記事 「日本学生支援機構　5年以上眠っていた不具合が発覚」 によると
（概要）
・日本学生支援機構（JASSO）の個人信用システムは、毎月正しく返済していた
　632名を延滞者として全国銀行個人信用情報センターに通知していた。
・例えば、返還方法に「月賦・半年賦併用」を選択すると、毎月の１万円に加え、
　年２回の賞与月に６万円を返還するが、プログラムミスにより、賞与月以外の月の
　１万円入金に対して賞与月の６万円の未払いが生じたと判断していた。

＜ソフトウェア工学視点での疑問＞
★機能分割の不自然さ：
　記事では、ミスのあった個人信用システムは、既存の奨学金返還データシステム
　と連携しているが、この既存のシステムに延滞情報がなかったのだろうか。
　個人信用システムが新たに基本情報から延滞の有無を判断しているなら
　２つのシステムの機能分担が理解できない！
★受入れテストの疑問：
　JASSOは「支払い方法が多岐にわたっており、レアケースを中心に
　テストしたために、基本的な部分の確認を怠った」とのことなので、
　信じがたいが、受入れテストをさぼったらしい。
★原因分析の疑問
　JASSOは「対外接続に不慣れな部分があったと言わざるを得ない」というが、
　今回のプログラムミスは「対外接続」とは関係ない基本作業のミス！
★開発ベンダーへの疑問
　記事では、システム開発を受注したベンダーの瑕疵担保期間は通常、
　1年なので、検収が終われば開発者責任を逃れられるが、開発ベンダーは
　「今回の件は契約外になるが、社会的インパクトを鑑みて対応に当たった」という。
　しかし、機能仕様に基づいて作成するテストケースが網羅的でなかった疑いがあり、
　ベンダー側のシステムテスト技術レベルも疑問。


2015.10
防災システムのブラウザ依存の不具合を2年間放置
●日経コンピュータ（2015.10.1）の記事 「防災システムの不具合を2年間放置」 によると
（概要）
・大雨による土砂災害の危険が高まったときに、雨量や危険度の情報を
　Webサイトで提供するシステムが，FirefoxやChromeでは利用不可
・奈良県の入札仕様書で『Windows標準ブラウザで閲覧すること』
　と明記され，IE6だけに対応していた．

●産経のＷｅｂの記事（2015.6.18）
「命守る土砂災害情報システムの欠陥放置
　奈良県が認知後２年間　携帯などで閲覧できないのに活用チラシ配布も」
によると
（概要）
・県は2013.8に把握後、住民の命を守るシステムの欠陥を約２年間も放置
・災害時に多くの県民が利用するスマートフォンでも基本的に閲覧不可
・県は、2015.6に欠陥のあるシステム活用のチラシを１万枚作製、約８千枚配布済み

＜ソフトウェア工学視点でのコメント＞
★要求分析プロセスの疑問：
　開発目的と利用方法を考慮すれば，ブラウザが「IE6だけに対応」して
　いればよいはずはない．ユーザ視点の欠如ではないか！
★運用開始後の保守プロセスの疑問：
　＊作りっぱなしで，利用率のチェックはせず，スマホ・タブレットなどの
　　利用環境の変化に対応する担当者はいない？


2015.10
株の誤発注裁判で最高裁が双方の上告を退ける決定
2015.9.3の最高裁の判決について，
■ 日経ＢＰの記事（2015/9/17） ＜みずほ証-東証の誤発注裁判、10年経て終結＞によると，
要点は以下の通り：
(1) みずほ証券が、約415億円の賠償を求めていた裁判の控訴審で、第一審と同じく、東証に約107億円の支払いを命じた高裁の判決が確定

■記事の中に
「東京高裁は判決の中で、売買システムのバグを重過失と認定しなかった。バグが複 数の条件の組み合わせで発現するものだったことに加え、テスト工程を通じてバグを 容易に発見できたかどうか、専門家の意見が分かれたためだ。」
とあるが、すでに、2012.8の下記のブログで述べたとおり、
回帰テストで、分岐に関する網羅テストをしていれば、
未実行の分岐が検出されるので、その前後の処理フローのバグは見つかったはず。

★ＩＴ業界のテスト作業の実態はいかに？
★　→分岐テストの実施率はどの程度だろうか？
★　→保守時の回帰テストは実施しているのだろうか？

（注）「分岐テスト」、「回帰テスト」とは
　拙著「ソフトウェア工学(第３版)」（朝倉書店）7章に記載

■ 私の意見は，過去のブログで述べた通り：
★2013.8　 　株の誤発注裁判で控訴審も第一審と同額賠償の判決！
★2012.9　 　東証-みずほ誤発注裁判でプログラム修正後の構造テストも争点に
★2012.8　 　東証-みずほ誤発注裁判でプログラム修正後の回帰テストが争点に
★2009.12　 東証の誤発注問題の415億円の損害賠償裁判に東京地裁判決
★2008.5　 要件定義書に「現行と同一」という記載はありか？
★2007.5　 東証の誤発注事故（05.12）は分岐テストで防げたはず

■ソフトウェア工学関連の授業での 電子ディベート：
　・2005.12　「非現実的な注文の受付ミスと注文取消し不可のミス」
　・2006.6　「技術的責任の有無」
　・2007.6　「誤発注裁判で見えてきた不具合の真相」
　・2013.7　「東証裁判の争点」

■
（追記：2015.11.17）
日経コンピュータ（2015.11.12） 特集「大損害時代の突破術」によると：
東証の現在稼働中のシステムでは、以下の誤発注の未然防止機能あり：
　・証券会社による、1注文当たりの代金などの任意の上限設定
　・証券会社と東証のシステムの接続の異常切断時、発注済みの未約定注文の自動取消
　・発行株式の5％を超える注文は監視用端末にアラート出力
　・発行株式の30％を超える注文は自動的に受付拒否


2015.9
メタボ検診： システムのミスで十分活用できず

■2015.9.4の午後7時のＮＨＫニュース 「メタボ検診 システムのミスで十分活用でき ず」について。

★2014.3のブログ 「厚生労働省のナショナルデータベースで要求定義ミス」 で取り上げた内容が
　1年半たっても改修されていないとは！

（ニュース内容）
・「メタボ健診」のデータを蓄積して、医療費の抑制につなげようと厚生労働省が整 備したシステムに設計ミスがあり、およそ２０％の人のデータしか活用できない状態 が運用後６年経った今も改修されていないことが会計検査院の調べで分かった。
・この「ナショナルデータベース」システムは厚生労働省がおよそ２８億円をかけて 整備
・７年間に１２００億円余りの補助金投入のメタボ健診の効果の検証にも十分活用で きず。
・厚生労働省は３年前に突合率が低いことを把握したが、原因が分からず改修せず。
　（9/5の朝日新聞の記事では、約2億円かけて改修中とのこと）

★本件は、6年前に話題になった「電子政府の電子申請システムの利用率の悪さ」と 同じような、
　国の税金の無駄使い体質が伺える。
（関連する拙著）
　 「システムの利用率は要求分析の対象では？」、 情報処理学会 ウィンターワークショップ2010・イン・倉敷 論文集、
・概要：
　電子政府の電子申請システムの利用率の悪さが数年前にも今も問題になっている． 利用者視点を忘れ，多額の税金を投入し，電子化実施率を競ってきた結果と言える が，そもそもシステムの利用率予測は要求分析の対象ではないのかという疑問があ る．


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


　人工知能学会誌の2015年7月号の特集「学習科学と学習工学のフロンティア」の中の論文：
「他者からの学びの支援」（pp.469-472）の中で，
５０年近く前に読んだヴィゴツキーの「思考と言語」が引用されている．

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

（注）ヴィゴツキーの名前が目に留まると懐かしくて一言コメントしたくなる． すでに以下のブログで取り上げている．

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

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


2015.8
新国立競技場の設計と工費に見る情報システムとの類似性

新国立競技場の総工費が当初の１３００億円から２５２０億円になった件に関連して，
情報システムとの類似性の観点で以下の記事に注目した．

朝日新聞（2015.7.23） 「新国立、設計者の選び方は　建築家・隈研吾さんに聞く」
（要点）
・他人の設計について，審査段階での工費見積もりは難しい
・フランスのコンペでは，概算見積もりが義務づけられていることが多い
・今後、「設計・施工型」の競争で案が選ばれる可能性が高い。
　設計者と施工者が一体となって提案する方法で、スケジュールやコストがある程度保証される。

（情報システムとの比較）
上記の「設計」を「要求定義」に置き換えれば，情報システムと類似性がある．
2012.6の ブログ と同様に次の拙文を引用するが、
★印のケース１はまさに今回の新国立競技場に当てはまる！

情報処理学会 ウィンターワークショップ（Jan. 2011）で発表した，
「 ソフトウェアの要求分析と工数見積もりに関する考察 」 という論文で以下の指摘をしている．

「ソフトウェアの工数見積もりは要求分析とは別作業として扱われることが多いようであるが，要求仕様と開発工数は密な関係があり，その関連での失敗プロジェクトも多い．要求定義担当と工数見積もり担当の相補的立場での協力体制が不可欠と思われる．」

★「ケース１：要求分析以前に全体の予算と稼働時期が決定の場合：これらは制約条件となり，要求仕様決定にはその後の開発業務の工数見積もりが必須となる．」


2015.7
スルガ銀-IBM裁判で最高裁が上告を棄却

■ 日経ＢＰの記事（2015/7/9）「スルガ銀-IBM裁判で最高裁が上告を棄却」
（要旨）
・勘定系システムの開発中止で、スルガ銀行が日本IBMに約116億円の支払いを求めた裁判
・最高裁判所は2015年7月8日、両社の上告を棄却する決定を下した。
・これにより、日本IBMに約42億円の賠償を命じた東京高等裁判所の判決が確定
（過去の経緯）
・東京地裁は2012年3月、日本IBMが提案した勘定系パッケージの機能検証不足が、
　ＰＭ義務違反に当たるとして、日本IBMに約74億円の支払いを命じる判決
・東京高裁は2013年9月、日本IBMのＰＭ義務違反は、
　パッケージを選定した提案・企画段階ではなく、その後の
　要件定義を経て両社が最終合意書を交わした段階で起きたとして、
　賠償額を約42億円に減額する判決

「スルガ銀-IBM裁判、第二審で賠償額4割減」
　東京高裁は、要件定義によって、当初予定の費用や目標の達成が不可能と判明したのに、
日本IBMが，システムの抜本的な変更、中止を含めた説明や提言、
具体的なリスクの告知を行わないまま最終合意書を結んだことが、義務違反に当たるとした。

東京地裁の判決後の，2012.6のブログで，以下のように述べたが，
要求定義以降のプロジェクトに責任ありならば，理解できる．

スルガ銀-IBM裁判の判決（約74億円支払い命令）全容が判明
★基本的な疑問は，何を開発するかが明確でない要求定義前の段階で，
★開発費と納期が決められていることである．


2015.6
オーバーフローのチェック漏れがなくならない

日経コンピュータ　2015.5.14号の記事：
「システム障害で住民票を発行できず　別システムのデータ更新でDB停止」

（要旨）
・2015年2月19日、埼玉県富士見市の住民記録/国民健康保険システムで障害が発生、
　直接の原因は、ディスク容量を上回るログデータをDBに書き込もうとしたためだ。
　1日当たり平均2ギガバイト程度のログを記録している。
　ディスク容量は100ギガバイトで，システムの仕様上、十分と考えられる容量だった。

★ソフトウェア工学的観点での疑問点：
・ディスクや主記憶の容量が有限である以上，
　書き込み時に上限オーバーフローのチェックをするのは当たり前では？

　拙著「ソフトウェア工学」 では，以下のように記載している：

検査段階での検出をまぬがれてシステム運用中に引き起こされる事故は社会的影響が大きいが，要求分析，設計，製造の各段階での例外的な事象に対する処理の抜けによるものが多い．
・・・
過去の例では，
　某銀行システムに５月の連休直前の預金の引出しが集中し，他行の口座からの引出し取扱件数の許容量を超えた引出しに関して，顧客の口座の残高が減らないという事故や，
　６年間運用されてきた某航空管制システムがたまたまパイロットの異常に長いメッセージを受信してダウンしたために，航空機の離発着に支障が出たとか，
　運用から10年後に当初の予想を超えた端末数が設置されたためにダウンした某オンラインシステムなど，
枚挙にいとまがない．
これらの事故は，すべて，許容範囲を越えた入力に対する例外処理をしておけば，事前に防げたものである．
（引用終わり）

　2011年の東日本大震災の義援金受付口座に関する大手銀行の事故も同様だった． 口座の開設時にその用途を確認せず，振込み数上限を通常の9999件と設定してしまった．そこへ大量の振込みが集中してシステム障害が発生したのだった．

追伸(2015.7.20)：
　 「東京の119番受信障害」 の記事によると， 2015年4月14日に約4時間にわたって続いた東京23区からの119番通報に関するシステム障害は， 「バッファーオーバーフローにより、固定・携帯両方の回線を収容する「119収容パッケージ」全体で回線接続が不可能となった」 とのこと．


2015.6
興味深い次期東証システムの「二者設計」
次期の東証システムについて，
■ 日経ＢＰの記事（2015/5/28）
＜「東京証券取引所 ［戦略］自動発注の“暴走”を止める 市場の安定守る次期arrowhead」＞
によると，以下の通り：
・主要機能の詳細設計工程で，2人の開発者が同じ機能について別々に設計し、
　優れたものを採用する「二者設計」を導入。
・現行システムでも，要件定義の内容がきちんと設計に組み込まれているかの追跡、
　設計段階でテストシナリオを作成しての品質確認、
　第三者機関によるソースコードレビューを実施とのこと。
・「ゼロから始めた前回プロジェクトと単純に比べるわけにはいかないが、
　結合テストでのバグ件数は10分の1に減った」とのこと．

★この二者設計でどちらが優れているかの評価方法に興味あり．
　＊現行システムの上記の３段階の実施項目が評価基準ならば，
　　3段階で検出した不良内容の重大性と数を用いて数値化したのだろうか．
　＊あるいは，設計者の能力を判断したのだろうか．（設計コンテスト？）
　＊設計仕様書はどのように記述されたものだろうか．
　　たとえば，オブジェクト指向設計ならばＵＭＬか，あるいは従来のＤＦＤ＆ＥＲＤとか．
　＊二者設計よりも，「一者設計＋一者レビュー」の方が効果的ではないのだろうか？


2015.6
次期の東証システムでの誤発注対策
次期の東証システムについて，
■ 日経ＢＰの記事（2015/5/28）
＜「東京証券取引所 ［戦略］自動発注の“暴走”を止める 市場の安定守る次期arrowhead」＞
によると，以下の通り：
・現在，受け入れテスト中（本年9月稼働予定）の次期の東証システムでは，
　「市場の安定性確保を最大の目標に掲げている」とのこと．
・現在，プログラムによる自動発注が全体の7割をしめるので，自動発注対策を実施とのこと
　＊証券会社システムとの接続が異常切断した際、未約定の発注済み注文を自動取り消しする
　＊自動発注プログラムの不具合により、証券会社が予期せぬ大量注文をした場合などに
　　指定サーバーからの発注を止める機能があり、
　　既に発注された注文で未約定のものを自動で取り消す機能も備える。
　＊証券会社のサーバーごとに、注文を抑止するしきい値を設定できる機能もあり，
　　1注文当たりの代金あるいは単位時間当たりの注文代金や約定代金などに上限を定められる。
　　（本機能は以下の現行システムの機能の強化）
　　ある銘柄の株式数の30％を超える発注が一度にあった場合、注文を受け付けない。
　　5％を超える場合は、一旦、売買を保留し、発注者に誤発注か否かの確認を取る。

これらの機能は，現在，最高裁で係争中の誤発注事件の教訓であろう．
第一審，第二審とも、誤発注判明後も東証が売買を停止しなかったのは東証の重過失と認定。

■ 私の意見は，過去のブログで述べた通り：
★2013.8　 　株の誤発注裁判で控訴審も第一審と同額賠償の判決！
★2012.9　 　東証-みずほ誤発注裁判でプログラム修正後の構造テストも争点に
★2012.8　 　東証-みずほ誤発注裁判でプログラム修正後の回帰テストが争点に
★2009.12　 東証の誤発注問題の415億円の損害賠償裁判に東京地裁判決
★2008.5　 要件定義書に「現行と同一」という記載はありか？
★2007.5　 東証の誤発注事故（05.12）は分岐テストで防げたはず


2015.3
　日本のソフトウエアは45年を経てどこまで来たのか


　日経ＢＰのITproの記事（2015/02/25） 　 「『日本のソフトウエアは米国をしのぐ』から45年、一体どこまで来たのか」
で，日経ビジネス創刊号（1969年10月号）の記事を引用して， 日本のソフトウェア技術の競争力を論じている．

　1969年といえば，私がプログラミング言語Fortranでニューラルネットワークのシミュレーションをするためにコンピュータを使用しはじめた年である．
　そこで，この機会にソフトウェア技術に関する私の記憶をたどることにした．

　（→ 詳細はこちら）


2014.12
　物流管理システムの構築中止で38億円の損害賠償裁判の原因は？


　日経コンピュータ（2014.12.25）の記事
　「物流管理システム刷新に失敗　38億円の賠償求めベンダー提訴」について：

＜記事概要＞
　・2011年：T社はA社と要件定義・基本設計の契約
　・2012年3月：T社はA社に開発業務を委託（請負契約）
　（→詳細設計と単体テストはほぼ予定通り終了）
　・2013年初め：T社はシステムテストのシナリオ作成の不備を指摘
　
　・2013年5月：A社が正式なプロジェクト中断を申し入れ
　　→その後，A社は以下の設計の問題点をT社に報告
　　「複数機能の連携動作の設計不良」
　　「品目マスターなどの検討不十分」
　　「テストのシナリオが業務フローに基づいていない」
　
　・2014年3月：A社が再設計費用（T社が18億4000万円，A社が7000万円）と
　　　　　　　　統括PMO費用（T社が6億2000万円）を提案
　・2014年8月：T社はプロジェクト体制の解除を決定し，
　　　　　　　　損害賠償を求めて東京地裁に提訴
　
★ソフトウェア工学の観点での疑問点：
　
　・詳細設計からシステムテストまでの工程は請負契約なのに，
　　その開発会社に別途プロジェクト管理費を支払う意味は？
　　もし，発注側の管理業務の委託なら別会社に委託すべきでは？
　・T社がシステムテストの不備を事前に指摘しているが，
　　本来，統括PMO担当部署が指摘すべき事項では？
　　（建前上は，T社は受入れテストをしっかりやればよいはず）
　
　　→●統括PMOのプロジェクト管理の内容は？？
　
　・記事を見る限り，請負業者の開発能力不足に見えるが真相は？


2014.11
　“ぼんやり”に潜む謎の脳活動


　NHK教育テレビ（2014年8月31日）の サイエンスＺＥＲＯの番組「“ぼんやり”に潜む謎の脳活動」について：
内容の一部が私の修士論文の概念に類似。

　・脳の血流量一定　→　修論では、思考エネルギー一定
　・血流量の増減の時系列パターン　→　修論では、思考エネルギーの拡散と集中

番組の内容など、 ＜詳細こちら＞


2014.11
結晶性知能と流動性知能　→　学習度と学習エントロピー？（２）


　 2008.5にも掲載した「結晶性知能と流動性知能」に関する 記事（2014/11/3）
「大人になっても頭は良くなるの？　年とともに低下する知能と上昇する知能がある」

本記事で掲載された図が私の修士論文の概念に類似。
　・結晶性知能　→　学習度
　・流動性知能　→　学習エントロピー

グラフの比較など、 ＜詳細こちら＞

前回（2008.5）のグラフの比較など、 ＜詳細こちら＞


2014.8
番外編：フォン・ノイマンと長崎

　ＮＨＫスペシャル「知られざる衝撃波 "長崎原爆・マッハステムの脅威" 」 （ 2014.8.18放送 ）の中で，
　アメリカがマッハステムの破壊力を事前に計算していたことを示す資料が映し出され，
　その中に草創期のコンピュータ関連で有名な科学者「Dr. von Neumann」の名前があった．

　（→ 詳細はこちら）


2014.8
プログラムミスでの失業手当過払いの責任は発注側か製造側か？

　「失業手当、１日５円過払いか　プログラムにミス」（ 朝日新聞（2104.6.3）の記事 ）に関して
（概要）
・ミスがあったのは、ハローワーク職員が扱うプログラムで，2011年1月から今年3月にかけ、
　約１１００事業所分の産業別の労働者数などの集計が正しくできていなかった。
・そのため、毎月勤労統計の平均給与額をもとに毎年８月に改定する失業手当の支給上限額が、
　11年以降、１日５円高く払われた
・その結果，6/27の関連記事によると，計４万人に約２１５０万円が多く支払われており，
　厚労省はプログラム製造元に負担を求めている，とのこと．

★（疑問）プログラム開発の契約書の内容は？
　発注元の厚生労働省が，集計が正しくできていないミスを受け入れテストで
　見つけられなかったので，発注側に主な責任があるのでは？


2014.8
出版界が縮小の一途（売上高は17年間で35％減）

　「出版界、縮小の一途」（ 朝日新聞（2104.6.10）の記事 ）に関して
（概要）
・昨年の書籍と雑誌の総売上額が、前年比３・４％減の１兆７７１１億円
・最盛期（１９９６年）の６５％の水準
・本離れ、雑誌離れは鮮明
・期待されていた電子書籍も伸びない

★3年半前のブログ 「ＩＴが招く本屋の危機」では，

　「あるいはＩＴ化による本の入手の容易化で 文化の復興となるか！」と
　楽観的視点も述べたが，この問題については，売上高だけでなく，
　ジャンル別の分析，読者層の分析が必要と思われる．


2014.8
特許庁システム開発中止の後日談

　「2012年の特許庁システム開発中止、開発費全額返納のなぜ」（ 日経ＢＰの記事 ）に関して

（概要）
・Ｔ社とＡ社が、2012年に開発を中止した特許庁システムの開発費に利子を加えた約56億円を、同庁に返納

本件は，下記の本ブログ（2012.2）で取り上げている．　　
　　 「特許庁情報システムの開発中断で55億円が無駄とは」
このブログでは，８項目の疑問点を指摘した．

（追加の疑問２件）
★開発費よりプロジェクト管理費のほうが高い？
　記事では、「特許庁は，開発担当のＴ社に2009年度までの4年間で約24億8700万円を、
　　プロジェクト管理担当のＡ社に2011年度までに約29億6400万円支払」とのことである．
以前の記事では，Ｔ社は基本設計から詳細設計までを99億2500万円で落札とのことなので，
一部分支払い済みということは「工事完成基準」ではなく「工事進行基準」採用ということ？
後者の場合、工事進行途中で数回の適切なチェックがあったはずでは？

★契約書の内容は？
　記事では、「特許庁と両社は契約解除をめぐる交渉を始めたが、
　　開発中止に伴う違約金の扱いなどをめぐり、交渉に時間がかかっていた」とのこと．

特許庁は経済産業省のモデル取引・契約書（第一版）に準拠した契約書を作成していたのだろうか？

・情報サービス産業協会のソフトウェア開発委託契約書のモデルが以下のページにある。
　　 ＪＩＳＡ「ソフトウェア開発委託基本モデル契約」のガイドを公表
（引用）
本報告書には、ＪＩＳＡが、経済産業省のモデル取引・契約書（第一版）に準拠して平成２０年５月に策定した「ソフトウェア開発委託基本モデル契約書（平成２０年版）」の逐条解説や本モデル契約に基づいた個別契約のサンプル等を収録している。

2014.7
高額療養費の処理システムで要求定義ミス

日経コンピュータ　2014.7.24号の記事：
「約190万件の国保データに誤りの可能性　不具合あるシステムで2年間処理」

（要旨）
・国保中央会が開発し、国民健康保険団体連合会（連合会）が利用している
　国民健康保険共同電算システムの高額療養費の処理に「世帯誤り」と「資格誤り」あり
・医療費の自己負担額を世帯ごとに毎月合算し、一定額を超えた分を支給する処理において，
　受診した月以降に、親からの独立や結婚などで世帯が変わった被保険者の場合、
　新しい世帯で合算する不具合あり
・国保の被保険者が転職などにより資格を失っても、有資格者の処理をした可能性あり
・2011年5月の稼働開始後から1年間の診療報酬明細書（レセプト）には、
　本システムの仕様上、受診した日付が含まれていない，とのこと

★ソフトウェア工学的観点での疑問点：
・関係者の話では、「要件定義やテストの段階で、こうしたパターンを想定し切れていなかった」との こと
　そのため，システム内のレセプトデータは日付を保存しない仕様にしていたらし い．
　年間の途中で，世帯が変わったり，資格の変更があるという単純な事実に誰も気が 付かなかったとは？？

　→●どのように、要求分析をして，要求定義書を作成して，レビューしたの？？

＜レセプト関連の類似の過去の事例のブログ＞
・2014.3　 厚生労働省のナショナルデータベースで要求定義ミス
　レセプトではIDは「全角」で入力されていたが、
　特定健診では「全角」と「半角」が混在していたため、
　レセプトと特定健診のデータを関連付けできないことが判明．


2014.7
番外編：なつかしのヴィゴツキーが汎用人工知能ＡＧＩで注目されている


　人工知能学会誌の2014年５月号の特集論文： 「人間レベルの汎用人工知能の実現に向けた展望」の中で，
４０年以上前に読んだヴィゴツキーの「思考と言語」が引用されている．
　（懐古趣味にて→ 詳細はこちら）

（注）ヴィゴツキーについては，６年前に以下のブログ（2008.3）でも取り上げた．
　「４０年近く前に読んだヴィゴツキーの「思考と言語」が注目されているらしい。」


2014.6
番外編：なつかしの人工知能

　・朝日新聞の6/7の記事
　　「（ザ・テクノロジー）第２部・ＡＩ編：上　人工知能、米追う中国」
　に関連した昔話
　（懐古趣味にて→ 詳細はこちら）


2014.5
企業システムへのアジャイル開発適用時の当たり前

日経コンピュータ（2014.5.15）の記事： 『アジャイル放棄に未来なし』の中での
「“良いところ取り”の5箇条」に異論はないが，新しい勘所ではないのでは？

＜要点と個別コメント＞
・勘所1 プロジェクト計画：必要最低限の機能を洗い出す
　→全体を俯瞰できる必要最低限の機能とは，いわゆる基本機能だと思うが，
　　基本機能と拡張機能を分けて2段階で開発するのはウォーターフォール型開発でもあり
　　IEEEの要求仕様書の具備すべき特性の一つに，重要度のランク付けがある．

・勘所2 優先順位付け：最も難しい部分を先に
　→最も難しいと予想される部分を見極め、そこから開発に着手するのは，
　　80年代からのプロトタイプ開発と同じ発想では？
　　ユーザインタフェースや性能に関するプロトタイピングがその例．

・勘所3 ドキュメント作成：詳細設計書はパス、概要まで
　→上流工程ではアーキテクチャー設計書や概要設計書は作成するが，
　　詳細設計書は作成しないのは，アジャイル開発特有ともいえるが，
　　高級言語やスクリプト言語でフレームワーク利用の実装形態では当然か．
　　ウォーターフォール型開発でも，プログラミング＆テストで変更が発生しても
　　詳細設計書を変更しないことが多く，保守にも有用ではない状況だったので、
　　詳細設計書の記述レベルはまちまちだった。．

・勘所4 契 約：工夫次第で請負契約も可能
　→明確に成果物を規定しないアジャイル開発では，準委任契約がよく用いられるが，
　　イテレーションの冒頭で実装する機能を決めるので、請負契約の場合もあるのは当然．
　　従来型でも、要求分析は準委任契約で、それ以降は請負契約が多いのでは。

・勘所5 全社展開：数年単位で組織を改善
　→アジャイル開発の支持者を増やすための支援・教育体制が全社展開に必要なのは，
　　新技術の普及のための常道．かつて，1970年代の構造化技法や1990年前後の
　　オブジェクト指向技術の普及も同じだった．

以上


2014.5
普及している通信暗号化ソフトのお粗末なプログラミングミス

日経コンピュータ（2014.5.1）の記事：
『「OpenSSL」に深刻な脆弱性 多数のWebサイトが影響を受ける』 について：

（概要）
・ネットショッピングやネットバンキングなどのWebサイトで使われている通信暗号化ソフト
　「OpenSSL」に深刻な脆弱性（セキュリティ上の欠陥）が見つかった。
・通信相手に64KBまでの任意のデータを送信し，受信したWebサイトがそのデータを
　返送することで、相手の稼働状態を確認する機能がある。
・ところが、このデータサイズをチェックしないため、サイズが1KBでも、64KBだと
　宣言されていると、メモリーから64KB分のデータを返送してしまう。
・この63KB分の余計なデータには、他のユーザーがそのWebサイトとやり取りしている
　データやパスワード、Webサイトの秘密鍵などが含まれている可能性があり，
　秘密鍵を盗まれると、偽サイトを作られたり、暗号通信を解読されたりする恐れがある。

（疑問点）
　以下の５項目のいずれかで防げていたミスと思われる．

★プログラミングに関して：
・受信したデータを作業エリアにコピーする時に実際のデータサイズ分をコピーしていたと
　推測されるが，そのとき把握したサイズを返送時に使用していれば問題なかった．
・異なる処理で共用する作業エリアに関して，特定の処理の使用後に使用エリアのデータを
　クリアしておく必要があった．今回は特に暗号化ソフトの処理なのに．
・そもそも秘密鍵を作業エリアにコピーする必要があったのか？
　復号化実行処理はモジュール化されていなかった？

★機能仕様書に関して：
　本機能の仕様書は，おそらく「64KBまでの任意のデータを送信可」となっており，
送信側は実データサイズとは無関係に宣言サイズを最大値の64KBとしていた可能性がある．
プログラマがこの宣言サイズを実サイズと誤解するような表現になっていたのではないか．

★テストに関して：
　本機能の宣言データサイズと実データサイズに関して，　両者が一致しなければならない
という仕様だった場合は，少なくとも＜と＝と＞の3種類のテストケースを準備する必要があった．

以上


2014.4
全銀協の決済システムの目玉機能の利用ゼロとは？

朝日新聞（2014.4.19）の記事：
「決済システム、過剰投資　全銀協、目玉機能の利用ゼロ」 について：

（概要）
・全国銀行協会は約800億円かけて，2011年に新しい決済システムに切り替えた．
・その目玉機能として，振り込みの際に依頼内容を詳しく通知できるという
　新サービスを導入したが，まったく利用されていない．
・約1400の金融機関は「企業からの要望がない」ので，
　このサービス実施に必要な自分たちのシステムの変更をしていない。
・新サービス開発にソフトウエアだけでも100億円かかった」との指摘もある。

（疑問点）
★要求分析／要求定義に関して：
・各金融機関のシステムが新サービスに対応していないので，利用ゼロは当然．
・各金融機関のシステムを新サービスに対応させないのは摩訶不思議．
・そもそも要求分析段階で，新サービスが要求仕様に含まれた経緯が不明．
・利用ゼロの原因は，以下のいずれであろうか．
　　＊ニーズがない
　　＊各金融機関側がシステム変更の出費を嫌って宣伝しない
・根本的疑問：
　要求機能決定プロセスで，
　ステークホルダー（各銀行，クライアントの企業）のヒアリングはしたのか？
　（改変予算を含めて，約1400の各銀行の意見はきかなかった？）

以上


2014.4
豪雪で学校連絡網が機能しなかったバグとは？

日経コンピュータ（2014.4.17）の記事：
「豪雪で学校連絡網が機能せず　想定超えた処理集中でバグ発現」 について：

（概要）
・本システムは学校法人向けのサービスで，従来の電話連絡網の代わりに、メール，ファクシミリ、
　電話による自動音声で、休校や早退などの伝達事項を生徒の保護者に送信できる。
・今回の大雪ではDBサーバーへの接続数が異常に膨れあがり、同時接続数の上限に達した。
・電話メッセージの大量の送信処理プロセスが、メールなど他の伝達方法より
　長時間DBサーバーを占拠することになった。（電話連絡の比率は3割弱）
・配信処理サーバーのプログラム処理ロジックを修正し、DBサーバーへの
　同時接続数の上限も引き上げる。

（疑問点）
★詳細設計に関して：
　連絡媒体は，メール，ファクシミリ，電話の3種類だが，ＤＢサーバにアクセスして
連絡先の情報を読み出す処理は同じなので，共通化すべきだった．
　個別に開発されたため，電話連絡の処理プログラムだけが，
不必要に長時間ＤＢアクセス権を占有するロジックを実装してしまったのでは？

★テストに関して：
　同時接続数の上限が設定されていたのだから，上限オーバーのテストをしたと思うが，
その時，電話連絡のためのＤＢアクセスが，メールとファックスの連絡のためのアクセスに比べ，
異常に時間がかかることに気が付かなかったか？
　あるいは，上限ぎりぎりでの性能テストはしなかったか？

以上


2014.3
厚生労働省のナショナルデータベースで要求定義ミス

日経コンピュータ　2014.2.20号の記事：
「厚生労働省　約1600万人のメタボ健診データを生かせず 　入力時に全角/半角が混在し、突合不能に」　）

（要旨）
・厚生労働省が2009年4月に研究目的のナショナルデータベースを構築
・病院で受診した際の病名や医療費などを把握できるレセプトのデータと、
　腹囲や喫煙習慣、運動の頻度などが分かる特定健診のデータを組み合わせることで、
　生活習慣病対策などに活用するのが狙いだった。
・レセプトと特定健診のデータは別々の機関が入力し、個人情報保護の観点から
　ハッシュ化したIDで同一人物の両データを関連付けて分析する方法を想定
・ところが，レセプトではIDは「全角」で入力されていたが、
　特定健診では「全角」と「半角」が混在していたため、
　ハッシュ化すると異なるIDが生成されるものがあり、全体の８割以上が
　レセプトと特定健診のデータを関連付けできないことが2013年夏に判明．
・特定健診のデータに関して
　「記号番号の入力については全角と半角のどちらでもいいと定めていた」とのこと
・このプロジェクトの費用は、6億円超（機器：4億4625万円，ＤＢ開発費：7245万円など）

★ソフトウェア工学的観点での疑問点：
・本システムの目的からすると，以下の機能は基本的なもの：
　　＊個人情報（ＩＤ）のハッシュ化
　　＊ハッシュ値を用いたＩＤの照合
　にもかかわらず，2008年11月から開始した開発で，2013年夏まで５年近く，
　上記の単純な不都合に誰も気が付かなかったとは？？

　→●どのように、要求分析をして，要求定義書を作成して，レビューしたの？？

・改修に関して，7245万円で開発したプログラムの改修費用が4000万-5000万円程度とのこと．
　→理解できない．
・対策としては，半角で入力したデータを全角に変換するプログラムを
　ハッシュ化の前に追加するが最も簡単に思われるが，そうしない理由は？？


2014.1
コンピュータが1000万枚の画像から猫を認識したというのはホント？

グーグルが2012年に「コンピュータが猫を認識できるようになった」と発表した件について
（日経コンピュータ　2014.1.9号　 「機械学習革命」　）

（要旨）
・ディープラーニング（画像などの特徴をコンピュータが自ら抽出して、モデルを自 動生成する手法）を適用
・1000台のコンピュータを使って、ニューラルネットワークを構築
・YouTubeの動画の中から無作為に1000万枚の画像を取り出し、
　同社が開発したニューラルネットワーク「Google Brain」に3日間連続して読み込ませた
・大量の画像データの中から、共通する輪郭の構成要素（スパース）を見つけ出した
・このスパースを特徴とする画像モデルを使って、改めて1000万枚の画像を分類
・「猫が写った画像だけ」「人の顔が写った画像だけ」をコンピュータが分類していた
・猫や人だけではなく、2万種類の物体を認識することができた

（コメント）
　４５年前のニューラルネットワークの研究者として，
（→ 研究会1970　 大会1970　 大会1969　 修士論文　 卒業論文　 ）
この成果を評価するために知りたいこと

Ｑ１：1000万枚の画像の中で，2万種類の物体に含まれていた画像の枚数は？
Ｑ２：2万種類の物体の各々に含まれる画像の枚数を多い順に並べるとどうなる？
　　　（ｘ軸を2万種類の物体，ｙ軸を各々に含まれる画像の枚数，としたグラフ）
Ｑ３：「猫が写った画像」と「人の顔が写った画像」は
　　　2万種類の物体の各々に含まれる画像枚数の多い順の中で，何番目だった？
Ｑ４：「猫が写った画像」に含まれた画像はどのようなもので，
　　　猫が写っているにもかかわらず「猫が写った画像」に含まれなかった画像の枚数と内容は？
Ｑ５：以上の回答を踏まえて，人間の認識能力に近いと言えるかどうか？！

★まさか、２万種類に分類されたカテゴリの中に、たまたま、 猫の顔の画像ばかりが含まれるカテゴリがあった、というのではないでしょうね。


2013.12
言語処理系における中間語の標準化の夢？

米国の学会誌 Communications of the ACM（2013.12号）の中に
多種類のプログラミング言語から多種類のターゲットマシン用のオブジェクトコードを
生成するための中間言語の図が掲載されていた．この懐かしい図の略図は以下のようなもの：
（引用文献：Intermediate Representation (by Fred Chow, pp.57-62)）

｛言語１，言語２，・・・｝→　中間語　→｛マシン１，マシン２，・・・｝

本研究に関連して，以下の過去の研究を思い起こす：

（１）多言語モジュラ-プログラミングとその処理系LIGERの概念設計、
　　　情報処理学会第21回大会、287-288(1980). 　＜→発表論文＞　

（２）対象指向型言語をベ-スにした多言語モジュラ-プログラミングの提案、
　　　情報処理学会第31回大会、1E-2,289-290(Oct.1985) 　＜→発表論文＞　

★一番目の論文での「中間語の標準化」（MMP-79）に関する主張：
　＊「各モジュールをその機能に適した言語で効率よく記述でき，理解も容易」
　＊「本システムでは，ストレージとレジスタの割り当て直前のレベルでの標準化」

★二番目の論文での「中間語の標準化」（MMP-85）に関する主張：
　＊「対象指向型言語をＭＭＰのモジュール間関係記述言語として位置付ける」
　＊「モジュール間の実行制御はメッセージ伝送によって行う」
　＊「パラメータメエカニズムは・・・値渡しを基本とする」
　＊「データ型の不一致については，・・・受信側でデモンを起動する」

なお，一番目の論文の「5.2 中間語の標準化」の節では，
「古くは言語処理系の生成部を言語間で共通にするためのＵＮＣＯＬ」に言及しているが，
現在，Wikipediaに 　ＵＮＣＯＬ (UNiversal Computer Oriented Language)のページがある．


2013.12
番外編：（昭和史再訪）「期待される人間像」について

　・最近新聞に掲載された上記タイトルの記事については，思い出話あり．
　（懐古趣味にて→ 詳細はこちら）


2013.11
続：イプシロンロケット試験機打上げ中止の原因
■2013.9の 「イプシロンロケット試験機打上げ中止の原因」の続編

参考資料（ 「イプシロン、ITの全貌」記事，日経コンピュータ2013.11.14）によると，

ロケットのロール角の自動点検プログラムで用いるロール角は，初期値を0度と設定していた．
そして，ロール角の1度以内のずれを許容値とするため，-1度から+1度を正常と判断する処理だった．

しかし，1週間前のリハーサルの時に，この設定値が間違っていることに気が付き，
発射台のロール角が2度の想定なので、１度から３度を正常とするように設定変更した．

発射予定の当日（8/27），実際には，先々月（2013.9）のブログで述べたように
最初の姿勢データが報告される0.07秒前に自動点検プログラムが実行され，
実際の姿勢データが受信されていなかったので，
ロール角の初期値０度を用いて１度から３度の範囲外と判断したため，
姿勢異常と判断して緊急停止したとのこと．

★プログラミングに関する疑問
・もともと受信データに基づいて判断する処理なので，ロール角の初期値０度の設定は不自然．
・むしろ，安全な防衛的プログラミングとしては，以下のようにすべきだったのでは？
　＊初期値は現実にはありえない数値（たとえば，999）としておく．
　＊自動点検処理開始時点で，ロール角が999か否かをチェックする．
　　→999でない場合，本来の処理を続行する．
　　→999の場合，データが受信されていないので，しばらく待って，処理を再実行する．
　　　（さらに、この状態が一定時間続けばエラー処理をする）


2013.9
イプシロンロケット試験機打上げ中止の原因
■イプシロンロケット試験機打上げ中止の原因究明状況について、
　 宇宙航空研究開発機構の報告書（2013/9/4）によると、

＜打上げ中止の経緯＞
↓打上げの19秒前に，地上装置がロケット搭載計算機へ起動信号送信
　（この時，想定外の0.07秒の遅延が発生）
↓地上装置は，ロケット搭載計算機からの姿勢データが送信されないので，
　姿勢異常と判断して打上げ中止．

＜疑問＞
地上装置LCSとロケット搭載計算機OBCの間での交信規則について：
以下のように起動信号送信後，起動完了信号を受け取るようにしておくべきだった．
実際には，★印の処理がなかったので、起動完了を確認しないで姿勢監視処理を開始し、
姿勢データが送信されないので異常事態と判断したようだ．
　　LCS → OBC：起動信号送信
　　LCS ← OBC：★起動完了信号送信
　　LCS → OBC：★姿勢監視開始信号送信
　　LCS ← OBC：姿勢データ送信


2013.9
国交省の予定価格積算システムの不具合の最終責任は？
■「修正プログラムの誤り見落とす　入札時の価格算出にミス」 日経コンピュータの記事（2013/9/5）

・関連記事「プログラムの不具合で積算ミス、JACICを指名停止」(2013.7.19) 日経ＢＰの記事
（抜粋） 国土交通省の各地方整備局など10機関が使用している積算システムの不具合によって、 誤った予定価格を算出。その結果、落札者との契約を解除することになって損害を生じさせたとして、 10機関は同システムの運用管理業務を担当した一般財団法人日本建設情報総合センター（JACIC）を 2カ月間の指名停止とした。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
記事から推測すると，
・プログラム（積算システム）開発：国土交通省からJACICへ委託
・運用管理業務：国土交通省の地方機関（九州地方整備局）が入札実施で， JACIC（2012，2013年度）に発注
・テスト：国土交通省の各地方機関の担当者が実施

＜事故の概要＞
↓積算システムの新機能追加（JACIC）
↓地方機関担当者によるテスト実施（不具合検出）
↓プログラム修正（JACIC）（当該の不具合は修正するが，別のバグを作りこむ）
　　★回帰テスト未実施？
↓地方機関担当者によるテスト実施（新たなバグを検出できず）
　　★受け入れテスト未実施？
↓運用開始（近畿地方整備局は，間違った計算に基づいて，2件の工事契約）
↓関連業者から，積算根拠に関する問い合わせがあり，不具合が発覚
↓2件の契約取り消し（2件で約1000万円の損害賠償）
↓近畿地方整備局はJACICへこの費用を請求、運用管理業務に関して，2か月間の指名停止

＜疑問点＞
★今回の不具合はプログラムミスに基づくもので， 運用管理業務のミスではないのに，なぜ指名停止の処分？
★今回のプログラムの不具合を見つける最終責任は， 十分な受け入れテストをしなかった地方機関担当者では？
★技術的観点では，開発・保守担当としてのJACICは，プログラム修正後，
　修正前に実施していたテストを改めてテスト（回帰テスト）すべきだった．地方機関担当者も同様！
★プログラムの開発・保守の委託と，運用管理業務委託に関して，契約書の内容は？


2013.8
株の誤発注裁判で控訴審も第一審と同額賠償の判決！
2013.7.24の東京高裁の判決について，
■ 日経ＢＰの記事（2013/07/29）
＜「本件バグは重過失とは認められない」---みずほ証-東証判決、どう見る？＞
によると，要点は以下の通り：
(1) みずほ証券が、約415億円の賠償を求めていた裁判の控訴審で、第一審と同じく、東証に約107億円の支払いを命じる判決
(2) 誤発注判明後も東証が売買を停止しなかったことについては、第一審と同じく東証の重過失を認定。過失の割合も東証が7割、みずほ証券が3割と変わらず、賠償金額に変更はなかった。
(3) 本件のバグが重過失に当たるか、つまり「バグの作り込みの回避、発見・修正が容易であったか」を検討した。この件に関して双方が提出した専門家の意見書が「相反するものであり、甲乙つけがたいところである」とし、今回のバグが複数の条件の組み合わせで発生することから、「本件バグの発見等が容易であることを認定することが困難であった」とした。

■ 　 日経ＢＰの記事（2013/08/08）
＜「本件バグは重過失でない」との高裁判断に「妥当」が6割、みずほ証-東証裁判で＞
によると，930人のアンケート調査結果は以下の通り：
・上記(3)のバグについて，「判決は妥当（重過失に当たらない）」が58％，「不当（重過失に当たる）」が27％だった．
・上記(2)の売買を停止しなかったことについては、「妥当（重過失に当たる）」が89％と答えた。

■ 私の「ソフトウェア工学演習」（学部3年）の授業で，
判決の出る前の7/10に学生の意見を調査すると，
・上記(3)のバグについて，「重過失に当たるか？」という質問に対して，
　Yes 17名（44％）：No 22名（56％）で，上記調査とほぼ同じだった．

★本件については，過去にも授業で何度も取り上げている． 　　詳細はこちら

■ 私の意見は，過去のブログで述べた通り：
★2012.9　 　東証-みずほ誤発注裁判でプログラム修正後の構造テストも争点に
★2012.8　 　東証-みずほ誤発注裁判でプログラム修正後の回帰テストが争点に
★2009.12　 東証の誤発注問題の415億円の損害賠償裁判に東京地裁判決
★2008.5　 要件定義書に「現行と同一」という記載はありか？
★2007.5　 東証の誤発注事故（05.12）は分岐テストで防げたはず


2013.8
番外編：懐かしの磁気テープの需要拡大
日経コンピュータ2013.7.25号「特集　磁気テープ、まさかの復権」 　記事
（要約）
・データ保存手段として、既に過去の遺物と思われていた「磁気テープ」の生産量が急回復
・ここ数年で急速に大容量化し、主に海外で需要が伸びている
・復権の背景には日本のメーカーによる技術革新（高密度化）がある
・クラウドやビッグデータでも活用が進む

　・私は、1970年代にプログラミングに磁気テープを使用していた！
　・詳細な思い出話は、懐古趣味にて→ 詳細はこちら


2013.7
クラウドソーシングでＩＴ技術者の高給化は実現するか？

★22年前に予測した「情報処理技術者の自由業化シナリオ」の時代が到来！？
　後に記載する文献で，以下のような意見を述べた：

・建築士などの専門家と同じように個人の能力に応じた収入を得られるように自由業化する
・ユーザは，お金さえ払えば，優秀な技術者が作る良質のソフトウェアをタイムリーに入手できる

■関連記事
・日経コンピュータ（2013.6.13）
『「クラウドソーシング」が拓く　ITエンジニアの新しい生き方』 　デジタル版
（概要）
　システム開発の発注者とITエンジニアをWebサイト上でマッチングする「クラウドソーシング」の活用が広がっている。営業力がなくても仕事を受注できるため、独立したITエンジニアの活躍の場となりつつある。システム開発の短期化、小規模化の動きもこれを後押しする。

★情報処理技術者の自由業化という意味では，22年前の予測が実現したといえる．
　しかし，1991年の予測では，高給化が実現するはずだったが，そうではないようだ．

＜拙著の引用文献と引用箇所＞

・エンドユ−ザコンピ−ティング −ソフトウエア危機回避のシナリオ−、 情報処理, 32, 8, 950-960 (Aug. 1991)
　　　　　　解説論文のPDFファイル
★引用箇所
　「３．危機回避のシナリオ」の
　「3.2　解決へのシナリオ案」の
　「（３）「情報処理技術者の自由業化」シナリオ」

・ソフトウエア危機とプログラミングパラダイム、 　ー”わかりやすさ”の追求ー、 　啓学出版 (Aug. 1992)
　　　　　　単行本のPDFファイル
★引用箇所
　「第3章　危機回避のシナリオ」の
　「3.6　情報処理技術者の自由業化シナリオ」


2013.6
世界に通用するITを育てない罪

日経コンピュータ（2013.5.30）の下記の論説に私も一言
　「極言暴論：世界に通用するITを育てない罪」 　デジタル版
（要約）
・日本のIT企業は，市場創造という本来の意味でのマーケティングが本当に苦手だ．
・最新トレンド，画期的な製品・サービス，デファクトスタンダードは全て海の向こうからやって来る．
・日本のIT企業の顧客は，個別要求ばかりで，最新の技術を盛り込んだ製品・サービスをなかなか買ってくれないから，言われるがままにシステムを作る受託開発型のビジネスに依存し続けざるを得なかった．
・ユーザ企業が，世界に通用する製品・サービス（ＩＴ企業）を育てられなかった．

本論には同意する点が多いので，拙著から私の意見を引用したい．

■ソフトウエア危機とプログラミングパラダイム、啓学出版 (Aug. 1992) 　＜抜粋＞

「12.2.3 パーセプショントランスファー」
　日米のハイテク技術比較で５年先、１０年先も米国がリードしている分野として、医療、宇宙航空と共にソフトウエアが挙げられているが、ソフトウエア危機の問題は、一つの国の産業の問題としてではなく、いまや地球規模の問題として解決していかなければならない。
　この分野のブレークスルー技術を生み出すためには、ソフトウエア科学、ソフトウエア工学、ソフトウエア産業、エンドユーザの協力が必須となろう。しばしばテクノロジートランスファ（技術移転）の難しさが指摘されるが、その前にお互いのパーセプションギャップ（問題認識の溝）を解消することが重要であり、テクノロジートランスファとは逆方向のパーセプショントランスファ（問題認識の移転）が鍵となるように思われる。

（注）このパーセプショントランスファーは，以下の拙文で用いた用語
　What makes software tools successful?, IEEE Software, 10, 5, 63-65(Sep. 1993) ＰＤＦファイル

■巻頭言：ＣＳーｌｉｆｅ，コンピュ-タソフトウェア(日本ソフトウェア科学会)，11, 6, pp.1-2 (Nov. 1994) 　ＰＤＦファイル
　（抜粋）
　"Computer Society vs. Computer Society"は,一方のCSは情報社会または市場を意味し,もう1つは本学会を含めたコンピュータ関連学会または業界を指す.“CS supports CS."といえば,どちらがどちらになるだろうか.プロ野球界では「投手が打者を育て,打者が投手を育てる」と言われる.われわれの“業界"も「未来学やってるつもりが考古学」とならないように,エンドユーザの視点に立つという気持ちを忘れないでいたいものである.

（注）この論説は，下記の拙著のあとがきにも掲載している．
　ソフトウェア工学 ーオープンシステムとパラダイムシフトー，朝倉書店(May 1997).


2013.4
企業の採用活動開始を12月から４月に遅らせることに

４月上旬に，2015年春採用者への企業の採用活動を現在の12月から4月に遅らせる案を
文部科学省大臣から経済界へ要請し，当初，慎重姿勢の経団連も容認姿勢に転じた．
「学生のため」とのことだが，「企業のため」ではないの？？

2016年卒（現在の大学２年生）の学生から
「大学３年生の３月」開始を経済界側も受け入れ。 4/19の関連記事

＜賛成意見＞
・大学３年生が学業に専念できる
・採用活動が効率化
・経団連加盟1300社中830社（64％）が賛成

＜反対意見＞
・学生の企業研究に支障
・学生一人あたりの就職試験を受ける企業数減
・抜け駆けが横行（有名無実化）
・外資系に学生を取られる
・中小企業の採用活動に支障
・就職情報会社の全国195社の調査結果：反対43％，賛成25％

■人材育成の上流・下流の視点について、以下の過去のブログを引用したい。

・2011.1 　経団連の「新卒者の採用選考活動の在り方について」の提言に苦言

★残念ながら企業側には，学生の就職活動の早期化と長期化が自分たちの問題という認識（危機意識）がない．

・2009.8 　大学教育の質の保証の３種類の視点

★人材育成の下流に位置する企業の採用方針が上流の教育方針に大きな影響を与えるべきである．


2013.3
気象庁（予報）のスパコンの停止の真の原因は？

日経コンピュータ（2013.3.7）の記事
「気象庁　予報支えるスパコンが12時間停止　冷却設備の誤った設定を見逃す」

＜記事概要＞
■事故の流れ
1.スパコン緊急停止の数十秒前に冷却装置の制御システムでリセット動作発生．
2.その初期化プロセスで，冷却装置の停止コマンドを送信
3.温度急上昇を検知してスパコンは緊急停止（2013.2.4午後8時48分）
4.スパコン停止の原因を究明し，12時間後に再起動．

■関連事項
5.スパコンは外部から冷却水を取り込む水冷方式
6.冷却装置は建物の空調とスパコンの冷却を兼ねている
7.冷却装置の制御システムの初期化プロセスは、
　夜間は「停止」の命令を送る設定になっていた
8.空調設備の調達時の仕様書に，トラブル発生時を想定した要件記載なし

★問題点
・上記8項に関し，冷却装置の24時間運転という重要事項が，
　スパコン発注部署（気象庁）から建物＆設備発注部署（国土交通省）経由で
　施設担当業者に伝わっていなかったとは！
・上記3項に関し，温度上昇検知より早く，冷却水取込み停止の時点で警告可では？

★本件は，制御システムのソフトウェア要求仕様漏れの例？


2013.1
電子行政オープンデータ戦略への期待

12年前のe-Japan以降，費用対効果が疑わしい政策が多いが，Gov2.0 との関連で，一言．

■2012.7.4　（国内で関心が高まったきっかけ）
高度情報通信ネットワーク社会推進戦略本部（第５７回） 議事次第
□資料１：新たな情報通信技術戦略　工程表（改訂案）
（抜粋）
「国民本位の電子行政の実現」の一環として「オープンガバメント等の確立」のため
今後（2012 年度、2013 年度）「行政機関が保有する情報の活用」に取り組む．
・「電子行政オープンデータ戦略」に基づき公共データ活用の推進と環境整備を実施。
・データ流通・連携のための共通API の開発・国際標準化
□資料２-２：電子行政オープンデータ戦略（案）
（抜粋）
基本原則4項目のうちの2項目：
・機械判読可能な形式で公開すること
・営利目的、非営利目的を問わず活用を促進すること
　↓
　★この考えは，以下のコンセプトに近い
　↓
■2009.9.4　（Ｇｏｖ2.0とは）
ティム・オライリー：ガバメント2.0 政府はプラットフォームになるべきだ 翻訳版
（原本）Gov 2.0: It's All About The Platform 原本
（抜粋）
・5年前にWeb 2.0という用語を作ったオライリーがガバメント2.0というコンセプトを提唱
・ある分野で決定的な勝者になったのはすべてプラットフォーム企業
・連邦政府のdata.govサイトは、市民が積極的に利用できるウェブサービスを提供
・政府は、民間がさまざまなサービスを開発して提供するためのメカニズムそのものを
　提供するようになったら？　つまり、政府がプラットフォームになったら？
　↓
　★以下の文献がわかりやすい
　↓
■2012.9　（米国の状況）
米国連邦政府のオープンデータ戦略（和田恭：ニューヨークだより） 参照
（抜粋）
・オバマ大統領はDigital Governmentを発表(2012.5.23)、オープンデータの取組みを加速
　（情報を材料として取り扱い，利用者に最も使いやすい形で提示）
・オープンガバメントの3つの基本原則（透明性、市民参加、官民との連携）に基づく
　オープンデータへの取り組みの例：Data.Govなど多数
　↓
　★私の関心歴
　↓
・Ｗｅｂサービス連携（マッシュアップ）：下記文献以降
　→絶えざる変化に対応するエンドユーザ主導のサービス連携、産学戦略的ソフトウェア
　　研究フォーラム、ソフトウェアサービス技術シンポジウム資料集、8-1/2 (Apr.2001).
・電子政府・電子自治体アプリのエンドユーザ主導開発：下記文献以降
　→電子自治体向けフォームベースシステムと検索・記入・提出用ポータルサイトの構築法、
　　情報処理学会 第６５回全国大会 特別トラック(10)「e-Japanの進展」講演論文集
　　分冊５、pp.5575-5578 （Mar. 2003）
・ガバメント2.0：下記文献以降
　→類似Webサービス提供サイト間連携の実現方式に関する考察 , 情報処理学会
　　ソフトウェア工学研究会要求工学ワーキンググループ ワークショップ (Oct. 2011).
　　　　ガバメント2.0関連スライド抜粋


2012.9
東証-みずほ誤発注裁判でプログラム修正後の構造テストも争点に

日経ＢＰの記事 「COBOLのソースコードが法廷に、みずほ証券ー東証、株誤発注裁判で新展開」の概要
・みずほ証券は複数の鑑定人に依頼して、東証が提出したソースコードを解析
・「テストを行えばバグは容易に発見できた」などの意見書を2012年7月までに提出
・特定の条件下で誤発注を取り消せなくなるバグに関して，
　「処理フローがこの修正部に到達するような条件でテストを行うだけで、
　容易にバグを発見できたはずだ」と反論

この構造テストについても，私の5年前（2007.5）のブログ
「東証の誤発注事故（05.12）は分岐テストで防げたはず」で言及している．

（抜粋）　｛構造テスト（ホワイトボックステスト）技術の観点｝
（抜粋）　注文取消しに関して、８０００件のテストケースがあったが、
（抜粋）分岐テストの網羅率測定はしていなかった。
（抜粋）今回のプログラムミスは、
（抜粋）分岐判定条件が常に偽になるものなので、網羅率測定をしていれば、
（抜粋）条件が真になるテストケースが抜けていることがわかったはず。


2012.8
東証-みずほ誤発注裁判でプログラム修正後の回帰テストが争点に

日経ＢＰの記事 「東証-みずほ誤発注裁判、高裁でバグ混入の経緯判明」の概要
　誤発注を取り消せないバグに関するみずほ証券側の控訴審での意見書：
・2000年に運用テストで見つかった障害対応でソースコードを3カ所修正したが、
　1カ所の修正が不適切だった。
・回帰テストをすればこのバグを容易に発見できたはず。

この回帰テストについては，私の5年前（2007.5）のブログ　
「東証の誤発注事故（05.12）は分岐テストで防げたはず」で言及している．

（抜粋）運用テストで見つかった欠陥の修正のために条件分岐を追加したのならば，
（抜粋）そのテストデータを追加作成してテスト実行するのは当たり前だし，
（抜粋）他への影響がないことを確認するための再テスト（回帰テスト）も必要のはず。


2012.7
Alan M. Turing 生誕100周年

今年の６月、Alan M. Turing 生誕100周年とのこと。
　　・ACMのチューリング生誕100周年のページ　 →参考

で，思いだすのは学生時代に学んだ「万能チューリングマシン」のこと。
　　・Universal Turing machine　 →参考

大学院のＭ１の時の下記の輪講レポートでは、 ３種類のセルラーオートマトンについて紹介したが， いずれも万能チューリングマシンと自己増殖機械に言及していた．

　　・「学習機械について（１）：Cellular Automataの場合」 →参考ページ　 →PDFファイル


2012.7
パッチ適用プログラムのミスでデータセンタのユーザファイル消去とは

データセンターの障害で，顧客企業のデータを一括消去するミスが発生した事故に関して，
プログラミング＆テストの観点で疑問がある．
　　 資料１：大規模障害の概要と原因について（中間報告）2012年6月25日
　　 資料２：日経コンピュータ（2012.7.19）「国内DCで大規模障害が続発」

上記中間報告には，パッチ適用プログラムの検証手順として， 検証環境で動作確認を実施したが、その時，当該メンテナンス対象サーバー群のみ確認し、対象サーバー以外に影響が及んだことの確認をしなかったことが原因の一つに挙げられている．しかし，

★条件を判別し「該当しなければパッチは適用しない」処理は 一般には「if〜 then〜」形式になるので，条件が偽の時は何もしないので 何もしていないことをテストで確認する必要はない．

★今回は「該当しなければファイルを一括消去する」処理が実行されたので 「if〜 then〜 else〜」形式だったと思われる．なぜelse句が記述されたのか疑問であるが，もし，それが不要なコードならば，通常はソースコードレビューで発見できたはず．（プログラミング言語にもよるが，ソースコードを見てみたいものだ）

（以下は参考意見）
通常，システムテスト（統合テスト）以降のプログラム修正では，
意図通りバグがなくなっていることの確認のほかに，
意図していないバグを作りこんでいないことの確認が必要になる．
これはregression testingといわれるもので，原則としては， これまで確認済みのテストケースに関して再テストを実施しなければならない．
（これは，脆弱性対策のためのパッチを提供する側で実施しているはず）

しかし，今回はアプリケーションのソースプログラムの修正作業ではなく， パッチ作業の一括処理プログラムだった。 パッチの内容が正しいか否かのテストではregression testingが関係するが， パッチ作業が正しいか否かのテストでは，パッチの対象外のものをすべて チェックするというのは実施しなくても不思議はない．

なぜ「if〜 then〜 else〜」形式だったのか，あるいは パッチ処理のような特に慎重を要する処理プログラムのソースコードレビューを どのように実行したのか，が大いなる疑問である．

■■■追記（2012.8.1）■■■
　　 　追加資料１（日経ＢＰ記事） 　　　 　追加資料２（調査報告書）

★追加の疑問１：
　システム変更の担当者は社内マニュアルに従わず、自作の「更新プログラム」を利用してシステム変更を行っていたとのこと。

★しかし、そのマニュアルの内容は？
　マニュアル通りやればミスは防げるようになっていたのか？
　修正プログラムの作成方法が指示されている？？
　複数担当者によるチェックあるいはレビュープロセスは義務付けられているのか？？
　（上長がレビューするとは考えにくいが）

・報告書記載の以下のマニュアルの手順では不明：
　1. 更新プログラム作成し，検証環境で実行
　2. 上長による一部分（先行ユーザのサーバ）への許可
　3. 一部分の実行で問題なければ，本番（全体）実行
　4. なお，・・・

★追加疑問２：
　創業以来サーバー単体でのデータ消失の経験が無かったので，データの消失を想定したマニュアルや手順書を作成していなかったとのこと．
　報告書では，「オープンソフトウェアである復元プログラム」をその機能を確認しないまま適用したとある．

★しかし、データのバックアップ機能があるのに，データ復元のマニュアル・手順書はないって，本当？？

2012.6
スルガ銀-IBM裁判の判決（約74億円支払い命令）全容が判明

日経BPの記事「 スルガ銀-IBM裁判の判決全容が判明 」によると，
開発側がパッケージ使用のリスクを事前に 十分に検証しなかったことが失敗の原因とされたようだ．

日経BPの記事に掲載された「 着手してからの経緯 」によると，
2004年9月の時点で，新システムを95億円で開発するとした基本合意書を交わし，要 求定義開始し，
2005年９月の時点で，新システムを約９０億円で開発し，2008年1月に稼働させるという最終合意書を交わしている．パッケージのフィット＆ギャップ分析を含め， 要求定義（３回実施）が難航したらしい．

2008年３月の訴訟以後，本裁判の経緯を見守ってきたが，
2012年３月の判決の妥当性についてはさておき，
★基本的な疑問は， 何を開発するかが明確でない要求定義前の段階で，
★開発費と納期が決められていることである．

昨年の情報処理学会 ウィンターワークショップで，学会発表した，
「 ソフトウェアの要求分析と工数見積もりに関する考察 」
という論文で以下の指摘をしている．

「ソフトウェアの工数見積もりは要求分析とは別作業として扱われることが多いようであるが，要求仕様と開発工数は密な関係があり，その関連での失敗プロジェクトも多い．要求定義担当と工数見積もり担当の相補的立場での協力体制が不可欠と思われる．」

★「ケース１：要求分析以前に全体の予算と稼働時期が決定の場合：これらは制約条件となり，要求仕様決定にはその後の開発業務の工数見積もりが必須となる．」

今回の事件は，プロ同士の間でのトラブルなので，ロジカルには説明できない理由が存在すると思われるが，，，，

＜要件定義に関する追記：日経コンピュータ2012.6.7から＞
1回目の要件定義は，現行システムベースで2004.9に開始，2005末までに納入予定だった．
2回目の要件定義は，パッケージベースで
3回目の要件定義は，パッケージ開発側社員を交えたフィット＆ギャップ分析を実施．


2012.5
IT業界就職人気ランキングにおける「技術力」と「成長性」

日経コンピュータ（2012.4.26）「IT業界就職人気ランキング」記事で
言及されていない視点（コメント） 資料

・「理系か文系か、運動部系か文化系かで学生を分けた人気ランキング」について：
　まず、理系と文系の人気企業トップ１０では7社が重複しているが、部活動が運動部系か文化系かでは重複企業がないので興味深い。そこで、各々のトップ１０の企業が，「志望理由別ランキング」の15項目の志望理由の各々のトップ５に含まれるか否かを調べた．
　そして，「運動部系か文化系か」のいずれかのトップ１０の企業が2社以上多く含まれる項目をリストアップすると、以下のようになった．

＊部活が運動部系の学生の人気企業が多く含まれる項目
　３：０　技術力がある　

＊部活が文化系の学生の人気企業が多く含まれる多い項目
　１：３　成長性が高い
　０：４　製品・サービスの内容がわかりやすい
　１：３　実力があれば若いうちから活躍できる
　１：３　社風・居心地が良い

★部活が運動部系の学生は「技術力」を重視するのは当然かな．

　さらに，「志望理由別ランキング」の調査で，有効回答者数1499人中何人が回答したかという回答率に注目すると，「会社の魅力」カテゴリーでは、
　☆「技術力」、「安定」、「経営者・ビジョン」を約半数が選択しているのに対して、
　★「成長性」を選択した学生が約１/３と少ないのは意外。


2012.5
ITのトレンドはOSSが主導　→『地球規模のソフトウェア生産性』

日経コンピュータ（2012.4.26）の特集「主役交代」で下記の説明あり：
・オープンソースソフトウエア（OSS）と商用ソフトの立場が逆転し、
　ITのトレンドはOSSが主導する流れが“普通”になった。
・具体例（Javaの機能拡張）：
　2006年のJava SE 5 からOSSのJavaフレームワークの機能を積極的に取り込んでいる。

★下記の 拙著で指摘した 『地球規模のソフトウェア生産性』 としてのオープン化の流れの必然的結果ではなかろうか：

引用：ソフトウェア工学 ーオープンシステムとパラダイムシフトー、朝倉書店 (May 1997).

第3章3.4節「標準化シナリオ」から抜粋：
　「1990年代のオープンシステム・・・従来のように類似のソフトウェアが数多く開発されて限られた数のユーザに利用されるという人的資源の無駄使いの時代は終り，質の高い標準品を多数のユーザが利用するという 地球規模のソフトウェア生産性 を実現する時代になっている．」


2012.4
分割発注に懲りて，マイナンバーシステムは一括発注とか？

　日経BPガバメントテクノロジーの記事（2012/04/13）
　 マイナンバー番号制度のシステム費用はおいくら？ によると，

　8分野のサブシステムからなるが，分割発注ではなく，一括発注と決めているらしい．その理由は，最近，次期特許庁基幹系システムと次期年金システムが分割発注で失敗したためとのこと．

・次期特許庁基幹系システム
　12.2の過去ブログ　 特許庁情報システムの開発中断で55億円が無駄とは　 で言及したが，８分割した発注方式で失敗した．

・次期年金システム
　日経コンピュータ（2012/03/15）の記事　 「年金システム開発が1年以上停滞 受注企業がギブアップ、違約金を払う」　 によると，開発中の基本設計の一部分の補完工程を3社に分割発注したところ，そのうちの1社が開発の継続は難しいとギブアップしたとのこと．

★素朴な疑問

　分割発注でのシステム構築の失敗が続いたから今度は一括発注という発想は単純すぎないか． 失敗の真の原因を明確にしてその対策をとるのでなければ，税金の無駄使いはなくならない．

・次期特許庁基幹系システムの失敗は技術力よりもコスト重視の評価基準で入札を実施し，技術力に問題のある企業が安値受注をしたからでは．

・次期年金システムもほぼ同様では．

・大規模システムの複雑さに関する技術課題を克服する原則は「分割統治」であり，1社に発注するか数社に分割発注するかにかかわらず，お互いができるだけ疎な関係になるようなサブシステムに分割するのが基本であり，そのようなシステム構成にしておかなければ運用後の保守も難しくなる．

・サブシステム間のインタフェースをできるだけ疎にする努力は，本来，1社内の部署間で決定するよりも異なる企業間で決定するほうがより厳密に実施されるという視点もあるのでは．１社内の部署間では無理が通って道理が引っ込む危惧もある．

★少し古い話になるが，
　2005.9の過去ブログ 　長崎県庁システム（長崎ITモデル）　 では，予算額500万円以下に分割して発注する方式でコスト半減を実現している．

　2007.8のブログ 　 （続）長崎県庁システムとエンドユーザ主導開発　 でも，再度言及．


2012.3
Automata Studies（1956年出版）が今も販売されている

　・Ｔ先生の送別会で、60年代の人工知能の話が弾む。
　・懐かしいAutomata Studies（1956年出版）の本の話 　（懐古趣味にて→ 詳細はこちら）


2012.2
特許庁情報システムの開発中断で55億円が無駄とは

　1月に開発を中断した特許庁情報システムで，55億円が無駄になったらしい．
　　・参考１： 技術検証報告書　フォローアップ結果とりまとめ
　　・参考２：日経コンピュータ 2012.2.2号 「特許庁 基幹系システムの刷新を中止」

＜経緯＞
　・2004.10：現行の最適化計画を策定
　・2006.11：入札（Ｔ社が約99億円で落札）
　・2009.10：稼働時期を2年延期決定（→2014.1）
　・2010.8 ：特許庁情報システムに関する調査委員会の調査報告書
　・2012.1 ：特許庁情報システムに関する技術検証委員会の技術検証報告書（上記の参考１）

■報告書を読んでの疑問

★設計書の共通化とは？（p.3）
　2011.4に開発規模削減のために設計書の共通化（設計書の共通・類似要素の管理を行う作業で，残件を含む設計書の構造を変更するもの）の必要性が認識されたが，実施されていないとのこと．内容を推測できないが，設計変更という意味だろうか？　あるいはソースコードの共通化ということか？

★開発規模の見積もり（p.3）
　開発業者から2010.12に約60Ｍステップ（現行システムは約23Ｍステップ）との見積もりがあり，さらに設計書の共通化で31Ｍステップに削減可能との案が出たが，信用されなかったとのこと．他社より50億円安く落札した時点での見積もりは？

★役割分担の途中変更の提案（p.4）
開発業者は他社が開発したユーザアプリケーション（ＵＡ）の受け入れテストをすることになっていたが，期間短縮のために2011.3にこのテストをＵＡ開発業者に変更したいと提案とのこと．これでは受け入れテストにはならない． また，プロジェクト管理支援業者のＡ社は，最終稼働責任をＵＡ開発業者に変更すべきと提案とのことだが，テストする側とテストされる側が途中で逆転するようなプロジェクト管理がある？

★プロジェクト憲章は未完成（p.4）
　この時点でプロジェクト憲章（プロジェクトの目的、実施体制・役割分担、スケジュール等につき関係者で合意した文書）の策定ができていないとすると，プロジェクト管理支援業者に支払う30億円はどのような業務に対する対価？

★技術面の問題（p.7）
　「既存のシステム構造の根本的な見直しを伴う記録原本一元化を中心とした新規のシステムアーキテクチャを採用したこと」が問題？　ではないと思う．システムアーキテクチャの内容をぜひ知りたい．

★構造面の問題（p.7）
　「多岐にわたる業務を対象とした複雑かつ大規模なシステムであることとがあいまって、本プロジェクトは、技術的難易度が高い」とあるが，だからこそ「新規のシステムアーキテクチャを採用」したのでは？　大規模化に伴う複雑さを軽減する技術はすでに存在すると思う．

★上流工程の問題（p.7）
　「業務要件を「業務要件確認書」として定義することとされていたが、現在に至るまで完成に至っていない」とは！　これでプロジェクト管理支援業者は30億円もらえるの？

★調達面の問題（p.8）
　「受注者の調達手続において、このような能力を有する事業者を選定するプロセスに問題があった」のはその通り．P.12の技術点・価格点配点の見直しの項では，「調達案件の内容等によっては、現行の入札方式（総合評価落札方式（加算方式））において、原則として１：１とされている技術点と価格点の配分を柔軟に設定する措置についても、考慮する余地が十分にある」もその通り．

■2009.1のブログ 「システム開発プロジェクトの成功率が５年前より上昇！？」 で，
　「品質は見えないがコストはかかる」
という当たり前の認識をユーザは持つべきである， と述べたことと同じ．

■■追伸（2012.3に追記）■■■■■■
私のスクラップ帳から以下の関連記事が見つかった

◎「特許庁が分割発注で立て直し　新基幹系の稼働はさらに２年延期」日経コンピュータ2009.11.25
・稼働時期を2012.1から2014.1に延期
・2008.10にも１年延期
・「システム設計を落札したＴ社の技術者は、特許庁の業務知識が足りなかった」
　　　　（疑問）→？なぜそのまま続行した？？

◎「”野心的な”システム構想が頓挫　133億円投じるも稼働のメド立たず」日経コンピュータ2009.8.19
・システム刷新の狙いは、業務の最適化と維持コストの削減
・Ｎ，Ｈ，Ｔの３社が応札。Ｔ社が技術点で１６０点以上劣ったが、入札額が５０億円低くて落札。
・プロジェクト管理支援業者Ａ社は、2007.4から４年間で３３億円あまりの随意契約。
　プロジェクトの遅れと問題点を指摘したが、最終権限は特許庁にあるので、結果的に意味をなさなかった。
　　　　（疑問）→？３３億円が無駄遣いだった？？

2012.1
「ワーキングメモリ」という用語が物忘れの説明に使われていた

　1/16のテレビ番組のあさいち「物忘れよ　さようなら」で、 物忘れは、脳の「ワーキングメモリ」の記憶能力の衰えというような わかりやすい説明がなされていた。

私は、1980年代の人工知能ブームのときの知識として、 プロダクションシステム（ルールベースシステム）で用いられる 「ワーキングメモリ」を思い出し、懐かしくて注意を引いた。

私の学生時代には、長期記憶と区別して、一時的な記憶を短期記憶と呼んでいた。
★（例）私の修士論文「思考過程の数学的表現と模擬実験」の4.1節
　第四章 思考モデルTMの再検討
　4.1節　「記憶・・・「短期記憶行列」・・・」（p.142から） 　 詳細はこちら

また私の以下の著書の中でもプロダクションシステムのワーキングメモリについては説明している。

★拙著：ソフトウェア工学（第２版）、朝倉書店 (Mar.2004). 　 詳細はこちら
　15.　エンドユーザ指向のプログラミング
　　15.3　知識ベースシステム
　　15.3.2　プロダクションシステム　→自動車自動運転
　　　図15.6　　プロダクションシステムの基本構造

★拙著：「ソフトウエア危機とプログラミングパラダイム」、啓学出版（ 1992発行 ） 　 詳細はこちら
　第９章　人工知能
　　9.2　プロダクションシステム
　　9.2.3　推論方式
　　　図9.4　プロダクションシステムの基本構造 p.148の図

★プロダクションシステムの中でワーキングメモリは ルールの実行を導く条件に含まれる状態データの記憶エリアで、 「認知→行動」サイクルの認知の部分に対応するので、 物忘れの説明と概念的には同じといえる。
（用語として、どちらの分野のほうが早かったかは不明）

＜最初の著書からのテキスト抜粋＞
　「推論エンジンは，ワーキングメモリの状態を観察し，プロダクションメモリの中に条件部を満足するルールがあれば，それを実行するとともに，その実行結果をワーキングメモリに反映するという一連の動作を繰り返す．この推論過程は，図15.7に示すようなもので，認知ー行動サイクルと呼ばれる人間の認知モデルに対応している．すなわち，人間の思考過程を認知と行動の繰り返し作用ととらえ，図15.7における照合と実行を繰り返すものである．照合の後の競合解消は，実行可能なルールが複数あった場合に，どれを優先して実行するかを決めるものである．」


2011.12
番外編：パグウォッシュ会議を覚えていますか？

　情報処理学会の会誌「情報処理」の１月号（66-67ページ）に
「パグウォッシュ会議を覚えていますか？ 」という記事がある。

　→「はい、覚えています」　（懐古趣味にて→ 詳細はこちら）


2011.11
展示会で，学生お断り？　ＩＴ業界の再考を求む！

　当研究室では，ほとんどのゼミ生がＩＴ分野に就職するため， 以前からコンピュータ関連の展示会（ソフトウェア開発環境展， クラウドコンピューティングＥＸＰＯ）への参加を薦めていた． 数年前から招待状に「商談のため，学生はお断り」と記載される ようになったが，事実上，入場を断られることはなかった．
　ところが10月末の展示会で数人の学生が入場を断られてしまった． 学生（1年後のユーザ）を締め出す理由は？
　学生がＩＴ分野への就職前にその分野の先進製品を学ぶことを ＩＴ業界が歓迎しない理由がわからない！

　大学では，高校生向けのオープンキャンパスに力を入れているが， 訪問者は高校3年生に限らず，最近は高校2年生や1年生も増えている． もちろん「受験生以外はお断り」ではなく，むしろ大歓迎である．

　ＩＴ業界の再考を求む！


2011.10
番外編：米アップルの創業者、スティーブ・ジョブズ会長が逝去

　スティーブ・ジョブズ会長が10月5日に逝去 　関連記事１ 、 関連記事２

　Macの想い出については、　（懐古趣味にて→ 詳細はこちら）


2011.10
愛媛県と愛知県の電子入札のお粗末なシステム
　
＜概要＞
　日経コンピュータ（2011.10.13）の記事「電子入札の最低価格が丸見えに」によると，

・入札通知書の画面に最低価格は表示されないが，画面上の「保存」ボタンでダウンロードしたＸＭＬファイルを表示すると非公開のはずの最低価格が表示されるエラーが見つかった．

・愛媛県では，4年間で約8500件（約355億円），愛知県では，5年間で8192件（1365億円）に使用．

・Ｎ社が開発した愛媛県のシステムもＦ社が開発した愛知県のシステムも，国土交通省の外郭団体である日本建設情報総合センターのコアシステムをカスタマイズして開発

［疑問１］
　愛媛県の担当者談「ダウンロード機能があるとは知らなかった」とのことだが，コアシステムのカスタマイズといえども9000万円弱の発注なので，要求仕様書は作成したのでは？　事後確認もしていない？！
［疑問２］
　愛媛県の担当者談「受け入れテストを実施して検収印を押した我々に責任がある」とのことだが，この室長は受け入れテストの仕様書を事後確認したのだろうか．画面の保存ボタンを押して，保存内容を確認するというテスト項目がなかったとは考えられない．
［疑問３］
　Ｆ社は広報ＩＲ室談「設計に甘さがあった」とのことだが，設計ミスが事実なら，要求仕様には正しい仕様が明記されていた？　そして愛知県の担当者はその要求仕様書に基づくまともな受け入れテストをしなかった
［疑問４］
　画面の保存ボタンを押して保存ファイルを開けば素人にもわかるバグを４、５年間にわたり，誰も気づかなかった？？


2011.8
都後期高齢者医療広域連合のお粗末なシステム
　
＜概要＞ 朝日新聞の記事　「療養費支給額「３兆円」　都広域連合がケタ違いのミス」によると、

・療養費の通知書１万８７９通について、職員がパソコン操作を誤り、実際の支給額より数十億倍も高い額が誤記された書面を送付

・たとえば、支給額欄には１３桁の数字を入れることになっているが、１３５１円を支給する場合も千の位の「１」の前にゼロを９個入力しなければならないのに入力し忘れ、データ処理の過程で千の位の「１」が消えてゼロが後ろに１０個加えられた

・支給の日付も「８月」の場合「０８」と入力すべきなのにゼロを入力し忘れたため「８０月」と記載された例が多い

・ただし、誤記された人にも実際は正しい額が支給されている

［疑問１］
　1万通の手作業入力で，先頭に「０」を打ち込ませるようなユーザインタフェースだったとは！
［疑問２］
　しかも金額欄が全く必要のない13ケタという設計になっていたとは！
［疑問３］
　さらに「３兆円」や「８０月」のエラーチェック処理がないとは！
［疑問４］
　本来「実際は正しい額が支給されている」なら、もともとそのデータを参照すればよいはず。
［疑問５］
　「データ処理の過程で千の位の「１」が消えて」というのはプログラムミス？

★ 類似の記事がほかにもあった。
「４兆９７００億円支給？　２３市町医療広域連合が誤通知」（2011年1月18日）

・県後期高齢者医療広域連合（広島市中区）は、医療給付費の相続手続きに関する通知書計６６２通で、実際の支給予定額よりおよそ１億から９０億倍も高い額を誤って記入し、発送

・データを印刷する際のプログラムにミスがあったという。同連合では今回から業者に依頼してプログラムを変更したが、その際、業者に変更内容を正しく伝えていなかったために、桁違いの金額で処理されたと説明

［疑問６］
　プログラムミスと要求ミスとは異なる。プログラムミスという言い方をすべきでない。
［疑問７］
　まともな受け入れテストをしていれば，非常識な出力を事前に検出できたはず！

★検索中にたまたま本システムの関連ページを発見。

＜全国老人医療・国民健康保険主管課（部）長及び後期高齢者医療 広域連合事務局長会議資料（平成１９年２月１９日）＞

・厚生労働省が「後期高齢者医療制度 広域連合電算処理システム」を開発して、全国に配布した模様。

・システム仕様書、システム業務フローなどがＰＤＦファイルで掲載されているが、ページ数が多いので、この分析は今回はパス。


2011.7
はやぶさの弾丸不発の原因がプログラムミスとは残念！
　
　小惑星探査機「はやぶさ」による小惑星イトカワでのサンプル採取のための弾丸の不発の原因がプログラムミスであったという記事が日経コンピュータ（2011.1.20）に掲載されている．

＜概要＞
・2005.11.20に最初のサンプル採取を試みたとき，着陸動作中に障害物を検知して弾丸発射しなかった．
・その後，着陸用プログラムとパラメータ設定を変更したが，このときにバグを作りこんだ．
・2005.11.26の２回目の着陸は成功したが，プログラムミスで弾丸発射しなかった．

＜バグの概要＞
・「姿勢が水平になったら，１１７番の命令を実行する」という設定になっていた．
・ところが，１１７番は「安全装置を有効にする」という内容であったため，弾丸発射せず．

＜担当者の反省：「テストが甘かった」＞
・個々の装置単位で担当者をわけ，各自が担当の装置を確認する体制が問題だった．
・シミュレータで点火装置を対象外にしていたので，シミュレーションによる動作確認でミスを検出できず．

★コメント
　弾丸不発の原因が不十分なソフトウェアテストだったのは誠に残念．
・単体テストはしたが，結合テスト（インタフェースチェック）はしなかったようだ．
・グループによるソースプログラムのコードレビューもしていなかったと思われる．
・シミュレーションテストでは，最終結果だけチェックして，実行トレースの確認はしなかったようだ．
　（シミュレーション実行された命令を人間にわかりやすく表示するツールが欲しかった）

→当研究室の参考文献 「モデリング&シミュレーション技法」
情報処理学会，ウインターワークショップ イン 恵那 論文集，シンポジウムシリーズ Vol.98, No.1, 27-28, 1998.1.


2011.6
あわや航空機事故（またもや，自動操縦と手動操縦の対立が原因）
　
　北海道・奥尻島で４日、北海道エアシステム（ＨＡＣ）のプロペラ機（乗員乗客１３人）が地表から約３０メートルまで異常接近し、対地接近警報装置（ＧＰＷＳ）が作動したトラブルについて，

朝日新聞の記事によると、
　「機長は悪天候のために奥尻空港の手前約１．５キロ（高度約１８０メートル）で着陸を断念し、上昇に転じようとした。上昇するためには、飛行姿勢指示器の設定高度を約１８０メートルから約１２２０メートルに切り替える必要があったが、機長は同社の調査に「設定を忘れた可能性がある」と説明しているという。この機種は設定高度が低いままだと、操縦桿（かん）を引いても機首が下がる方向に力が働きがちだという。同機は上昇に向けてエンジンの出力を上げていたため、加速して急降下したとみられる。」

★システム設計の視点では，飛行姿勢指示器の設定高度にともなう低空飛行維持の自動操縦と 手動による上昇操縦が対立した状態に陥ったことになる．これは，このブログで過去に取り上げた 以下の事故の繰り返しではないか．

少なくとも，自動操縦指示後に，それと矛盾する手動操縦操作が行われたときは、 すぐ強い警告をするようなシステム設計にしておくべきだった．

・ 2009.2　中華航空機事故（264人死亡）の教訓は生かされなかった？

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


2011.5
番外編：劇団唐組の東日本大震災お見舞い公演『ひやりん児』

　・唐十郎氏率いる「劇団唐組」の東日本大震災お見舞い公演 『ひやりん児』
　・明治大学駿河台キャンパス「陽だまり広場」にて開催
　・36年ぶりに唐十郎の芝居を観る． 　（懐古趣味にて→ 詳細はこちら）


2011.4
みずほ銀行の振込み処理トラブル

　2002年4月に約一か月続いたみずほ銀行のトラブルはまだ記憶に新しいが， 今回も3/14に始まった振込み処理がらみのトラブルは2週間以上続き，月末に解消したようだ．
＜参考サイト＞ 朝日新聞 日経BP

★概要
　東日本大震災（3/11 2:46pm）の義援金受付口座の開設時にその用途を確認せず， 振込み数上限を通常の9999件と設定してしまった．そこへ大量の振込みが集中し， 3/15朝までに夜間バッチ処理が終了せず，振込み停止やATM停止が発生． 多くの会社の給与振込時期でもあったが， 3/19-21の3連休でも回復できないばかりか，未入金や二重入金が発生． 3/28に金融庁は立ち入り検査と行政処分を示唆．

★二重入金の実例：
　私の給与が3/18と3/22に振り込まれ，3/25に3/22の振込み分が引き出され ている．
→ 給料二重振込みの記録

★素朴な疑問
　上限を設定しながら上限を超えた入力を受け付けない処理ができないのはなぜ？？


◆2002年のトラブルに関して、
　拙著： ソフトウェア工学（第２版）、朝倉書店 (Mar.2004)からの抜粋

＜2.5節 インタフェースの問題＞
　「2002年春に発生した某銀行オンラインシステムのトラブルの遠因は，合併前の3銀行のシステムが独自仕様で構築されていたことである．そのため，合併後の連携処理部分でインタフェース不良が発生して大きな事故となってしまった．」

＜あとがき＞
　「現在の技術では，人間はプログラムの開発時に設計ミスをするし，検査ではテスト漏れによりそのミスを見逃してしまうというヒューマンファクタの問題が残されており，ソフトウェア危機は果てしなく続くようにみえる．前世紀末の西暦2000年問題も新世紀初頭（2002年4月）の某銀行の情報システム障害も危機的状況を思わせるには十分であったが，ソフトウェア革命はまだ達成されてはいない．」


2011.4
頭がいいのに「分かる」ことができない新卒たち
　
情報処理学会の会誌に企業での新人教育に関する下記の解説記事が掲載されている．

「企業の教育現場からの報告 - 頭がいいのに「分かる」ことができない新卒たち」，
情報処理， Vol.52 No.3，361-364（著者：槙島和紀 (シスコシステムズ)） 学会のページ

以下，抜粋：
・技術知識の学習能力の高さに比較して，そのアウトプットスキルが低い
・根本的な問題はアウトプットスキルではなくインプットスキルだった
・知識を「覚えて」はいても「分かる」ことができていない
・知識の応用が利かずアウトプットに活かすことができない
・「分かる」ための対策その１：知識の関連性を考える
　　＊覚えた知識を他の人に分かりやすく説明する
・「分かる」ための対策その２：まともな議論をする
　　＊異なるアイデアを持ち寄って議論することでより深く「分かる」
・今の学校に不足しているもの
　　＊「分かる」ための教育ができていない

記事の内容は的を射ているだけに耳の痛い話である．
私の研究室では，「議論に強くなろう」をモットーにしてきた．（以下，関連資料）
が，覚える授業に慣れてきた学生が急に変われるわけではない．
著者も指摘するように小学校からの教育を変える必要がある．
「ゆとり教育」はネーミングの失敗で「考えさせる教育」と呼ぶべきだったのでは？

「議論自由：議論を楽しく」　2002年の学部案内の記事

「議論自由」の看板


2011.3
医師の入力と異なる投薬を指示する電子カルテシステムのバグ
　
　日経コンピュータ2011.3.3号（p.106-p.107）の記事によると，
　全国32の医療機関で使用されている電子カルテシステムのバグのために， 医師の入力と異なる薬剤を注射したり，投与する事故が3か所以上の医療機関で発生したとのこと．

記事の情報に基づいて３つの疑問を指摘したい．

★＜その１＞
記事によると：
・11/4に医師から当該病院の安全管理部に「指示した覚えのない薬剤注射が記録されている」という報告があったが，不具合を発見できず．
・12/16に再び「投薬した覚えのない薬剤が記録されている」という報告でシステムを使用中止し，メーカへ連絡．

？疑問：
メーカのホームページによると本システムはしっかりログをとっているようだ． 今回の事象は重要度・緊急度がかなり高いと思われるが，最初の報告の時に 安全管理部はそのログをしっかり確認したのだろうか？？

★＜その２＞
記事の中のバグに関連する記載：
「バグは，医師の投薬指示を誤った情報としてDBに書き込むというもの」
「このバグで不具合が発生した4件では，システムが自動的にその患者の過去の投薬履歴から薬剤を選び，投薬指示を出した」
「このバグは，薬剤を選んで治療計画に登録する操作と，その登録内容を投薬指示として発行する操作を，数秒から数十秒の間に続けて実施すると表面化」
「不具合事例の操作履歴を調べると，操作間隔が１-２秒だった」

？疑問：
プログラムの不具合の内容が明確には説明されていない．そこで，推測するに， 薬剤の選択操作終了後にその薬剤をバッファかDBに登録することになっており， 次の投薬指示操作ではその登録された内容を参照することになっていたが， これらの処理は逐次処理ではなく，並行処理されていたため， 両者の操作が素早く実施されると，登録処理完了前に参照処理が実行され， その結果，しかるべきデータがないというエラーが検知され， そのエラー処理が「前回と同じ投薬指示」となっていたのであろうか？

もし，この推測通りならば，薬剤選択のない投薬指示に対して， 「前回と同じ＊＊＊の投薬でよいですね」という確認画面を表示すべきだったと思う．

★＜その３＞
記事の中のメーカ側の話：
「ごく短時間に操作が行われることはまれであり，そうした可能性は設計時点では想定できなかった」

？疑問：
「設計時点では想定できなかった」かもしれないが， テスト工程で作成したテスト項目（テストケース）からも漏れたのはなぜ？
特に並行処理として実装したのならタイミングのテストは不可欠のはず！


2011.3
引っ越しワンストップサービスの最近の事情
　
　「引っ越し手続き　一発OK」の記事（朝日2011.2.23？）について：
　引っ越しワンストップサービスは， 90年代に話題になったものだが，日本でも実用化しているようだ．

・東京電力の「引越れんらく帳」（ 関連サイト） は， 2002.1に開始され，電気・ガス・水道などの引越に関する手続きで何度も同じことを入力する手間が省け、NHK、クレジットカード、損害保険等々、主要な企業の住所変更などにも対応，とのこと．

・大阪ガス・関西電力などの「関西引越し手続きサービス」（ 関連サイト ）は， 2005.1に開始され，2006.10には上記の引越れんらく帳と相互連携しているとのこと（ 　 関連資料、 関西手続きワンストップ協議会 ）．
・ただ，認知度は低く，年間利用者は５万人弱とのこと．

・検索すると，総務省や経済産業省の実証実験が見つかる．以下は一例．
＊総務省： 2008年度推進事業
＊経産省： 実証実験計画（2009.2） 引越手続ワンストップサービス検討会、 リンク先募集

★本サービスには1993年の引っ越し経験以来関心があり、1999年の引っ越しの時の住所変更５３件の方法を 2001.3に学会発表した 「絶えざる変化に対応するエンドユーザ主導型アプリケーション開発技法」 の中で引用した。以下は抜粋：

　「 ＩＴ革命が流行語になっている一方で、転居に伴う新住所、氏名、電話番号などの記入を数十回繰り返し、その大半は郵送または窓口への訪問による提出を伴っているのが現状である。」と問題提起している．

★引っ越しによる住所変更のワンストップサービスについては，９０年代にすでに米国郵政公社で実施されていたと思う．「1997年に改訂された」と記録のある米国政府のWINGS（Web Interactive Network of Government Services）のページのプリントでは，住所変更のワンストップサービスが掲載されている．今見ると， http://www.wings.usps.gov/ はなくなっている．


2011.3
番外編：大相撲八百長問題に一言
　
日本の国技だけあって，誰もが一言いいたくなるのは仕方がありませんね． 記事の例

八百長相撲で私が思い出すのは昭和33年の横綱千代の山と横綱鏡里の対戦．

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


2011.2
ＩＴが招く本屋の危機
　
　「米書店、消滅の危機　チェーン２位倒産の衝撃」の記事について： （ 関連ページ ）

　米国で約６７０店を抱える第２位の書店チェーンが倒産した． 1971年に創業、2005年には１２００店を超えたが， その後はアマゾンのネット販売が広がるにつれて下降線をたどった． 米書店協会に加盟する独立系の書店数は1993年の約４３００店から約１４００店に減った。 日本の書店数も2000年の２万１６５４店から2010年に１万５３１４店に減った。

　1992年発行の拙著 「ソフトウェア危機とプログラミングパラダイム」 では以下のように「本屋の危機」に言及した．
　「エンドユーザコンピューティングの進展と共にパソコンを中心としてそのソフトウェアの本が急増している。これらの本が本屋の売場をどんどん占領しはじめている。これは、 本屋の危機、 出版業界の危機にとどまらず、 文化の危機と言えなくもない。」

　1990年頃，本屋のスペースをソフトウェアのマニュアル本が浸食していく状況を 危惧したものだが，２０年前に予測したＩＴがもたらす本屋の危機は杞憂に終わった． そのわけは，以下のようなことではないだろうか．
　・ソフトウェアの操作性が向上し，マニュアルを読む必要がなくなった．
　・インターネットの普及で操作に関する情報を簡単に検索して入手できる．
すなわち，ＩＴの進化がＩＴによる本屋の危機を救ったといえる．

　しかし，今回の本屋の危機は様子が異なり，インターネットでの書籍販売の普及というＩＴの進化が本屋の存在価値そのものを減じている． さらに今後の展開として，電子書籍の普及が本屋のみならず，出版社の危機をも予感させる．

　今回の「ＩＴが招く本屋の危機」は深刻のようだが， さて，本屋の減少が 文化の危機を招くか？、 あるいはＩＴ化による本の入手の容易化で 文化の復興となるか！


2011.2
トヨタ自動車の電子制御システムにソフトウェア不良は見つからず
　
　急加速を引き起こすような電子制御システムの欠陥の有無について，昨年初めに米国で大問題となったが，米運輸省と米航空宇宙局（NASA）は2月８日、約10カ月に及ぶ調査の結果、欠陥は見当たらなかったとの最終報告書をまとめた。 （ NASAの関連ページ）

　30人の専門家が10か月かけて28万行のＣ言語プログラムを解析したことに興味があり，NASAレポートを概観してみた．（1人月でおよそ1000行チェック）

★NASAレポート（6.7節　ソフトウェア分析：p.139-p.151）

・電子制御システムは，ANCI C言語で記述されている．
・ソフトウェアデータは２か所に保存し，利用時に照合してデータ破壊の有無をチェック．

・エンジン制御ソフトウェアの調査は，コードパスや変数に関し，以下の４カテゴリを対象：
　　＊コード不良
　　＊アルゴリズムの欠陥（設計論理）
　　＊タスク干渉（実行条件，データ破壊）：タイミングや非同期処理の問題など
　　＊不十分な誤り防御：想定外のソフトウェア状態など

・以下の静的ソースコード解析ツールを使用した：
　　＊Coverity：コードの誤りや疑わしいコードパターンの検出など
　　＊CodeSoner：複数の手続きにまたがるコード分析など
　　＊Uno：よくある３種類のコードミス
　　（初期設定なしの変数，NILポインタ参照，配列添え字の限界オーバー）

・SPINツール（SPIN，Awarm）を用いたソフトウェア論理モデル検査を実施．
・MATLABモデルを用いたソフトウェアアルゴリズム設計解析を実施．
　ツール（MATLAB，Simulink，Stateflow，SystemTest，aiT）を使用．

★結論：UA(Unintended Acceleration)を引き起こすソフトウェア不良は見つからなかった．

★哀しいかな，これだけの労力をかけても「不良がない」とは言えない． 拙著「ソフトウェア工学」でも引用しているが，「テストは誤りの存在を示すことはできるが，誤りのないことは示せない」というE.W.Dijkstraのことばを思い起こしてしまう．


2011.1
新幹線システム障害の本当の原因は？
　
　東北、上越など５つの新幹線が17日、一時全線ストップしたＪＲ東日本の運行システム障害について、ＪＲ東は18日、雪の影響でダイヤを一度に変えた結果、システムの処理能力を超えたことが原因だったと発表した。（ 関連記事１、 関連記事２）

★ポイント故障発生後のシステム処理（UMLのユースケース表記）
１．業務担当は，指定した列車を各駅に停止させるようシステムに指示
２．システムは，ダイヤ変更を計算
３．システムは，後続列車についてデータ変更が必要な箇所をチェック
４．システムは，ダイヤとデータ変更が必要な箇所をパソコンに表示
５．業務担当は，この表示に基づき、データを変更
６．システムは，ダイヤ変更を完了

★システム障害の直接的原因
・上記ステップ４で，変更箇所の表示件数は最大600件だったため，
　600件を超えた時点ですべての表示が消えた．
・業務担当は能力に限界があることを知らなかったので，
　処理能力の上限に達しないよう操作を制限しなかった．
・新幹線の運行数は、システム導入時の95年の１日230本から現在の320本に増え、
　08年にシステムを更新したが、処理能力は導入当時のままとした．

★担当常務は「（容量が）足りると考えていたが、設計上の配慮不足だった」と陳謝した．

★★私見
　本来は，（容量が）足りると考えても，上限がある以上，上限に達したことを検知して警告メッセージを表示する処理を入れておくべきだった．（プログラミングの基本）

★★★類似の事故は15年前にもあった．
　1995.12.15にＪＲグループのみどりの窓口の端末の約4分の1が約7時間正常に動作しなかった． 原因は，新型の端末の増設に関連して端末管理プログラムが扱う端末台数を1800台から2200台に変更したことによる．実は，10年前に作成したプログラムでは，端末数2047台までしか正常に端末管理エリアのメモリ確保ができない処理になっていた．
　この事故も今回同様，上限がある以上，上限に達したことを検知して警告メッセージを表示する処理を入れておくべきだった．


2011.1
経団連の「新卒者の採用選考活動の在り方について」の提言に苦言
　
　日本経団連は最近「新卒者の採用選考活動の在り方について 」(2011年1月12日)を公表した．（ 参照ページ）

★残念ながら企業側には，学生の就職活動の早期化と長期化が自分たちの問題という認識（危機意識）がない．

　社会全体の観点で人材育成のプロセス（上流→中流→下流）をとらえると， 高校までの教育を上流，大学教育を中流，入社後の社員教育を下流とみることができる． その場合，就活の早期化・長期化は，下流工程の担当が中流工程の後半を無視して， 中流工程の中ほどから下流工程へのバイパスを作っているようなものである． このバイパスの影響は当然下流工程でかぶることになるという意味において， 企業側の自滅行為といえるのではないだろうか．

　次に提言に具体的にコメントしたい．
「具体的な見直しの内容」の「広報活動と選考活動開始の期日」に関して，

★選考活動を４月１日以降とする現状において， 広報活動を12月１日開始とする理由が不明確． なぜ期末試験の終わる２月以降ではだめなのかわからない．

★12月１日以前は個人情報の取得を行わないとするが， それ以降の広報活動では個人情報取得を認めている． しかし，これではこの個人情報が選考活動に流用される可能性は高い． この個人情報を広報活動の連絡以外には使用しないなどの宣言が必要であろう．

「学生に対するメッセージ」に関して，
★「エントリーシートや面接対策など、選考受験上のテクニックの習得などに走るのではなく」 とあるが，企業が選考方法を改めるのが先ではないだろうか．

「大学に対するメッセージ」に関して，
★「将来の目標を描き、広い視野と長期的な視点を持つことを促進するキャリア教育に努めることを求めたい」とあるが，これも企業が選考方法を改めるのが先ではないだろうか．


2010.11
自動車はすでに「情報システム」である！
　
　「大規模システム化した自動車の安全性向上策 -プリウス・ブレーキのリコール問題考察からの提言-」（情報システム学会企画委員会「社会への提言」検討チーム）が公開されている．（ 参照ページ）

　本件については２月のブログ（下記参照）で取り上げた．
＜トヨタ自動車のＡＢＳの制御プログラムの問題＞
　このブログでは，「1月の新車から変更していたというが，変更の内容を知りたい」， 「設計ミスだったのか？　あるいは実機テストの手抜きか？」という疑問を呈した．

　この提言は2月に私の提示した疑問の回答になっている．

　変更内容は，以前の方式に戻したという単純なもの．以前の方式では，ABSは個別車輪制御，回生ブレーキは両輪同時制御なので，ABS制御が必要になったときは回生ブレーキをやめ，油圧ポンプを稼働して制動力を補っていた．新方式では，油圧ポンプ稼働時の騒音を避け，ブレーキペダルの力を利用して制動力を補う方式にしたため，切り替え時間に空走感が発生したとのこと．

　設計ミスか否かについては，安全性よりも快適性を重視した意図的な設計なので，設計ミスとは言えないようだ．ただ，運転者の空走感からくる不安感への説明が不十分だった．

　実機テストの手抜きの有無については，ABSが本来目的としている制御機能については十分な実機テストを実施したようだが，低速走行での速度低減のテストが不十分だったようだ．本提言では，情報システムと同様に，システムを変更したときに変更部分のテストのみならず，変更しない部分が意図に反して変更されていないかを確認する回帰テストを進言している．情報システム分野では常識で私の授業でも教えている．

　また，自動車産業の関係者に対して，自動車はすでに「情報システム」であるという意識変革を求めている．一般的に最新の自動車は数十個のマイクロコンピュータを搭載し，そのソフトウェアは1,000万ステートメントを超えているらしい．


2010.11
浮き彫りになったソフトウェア開発実態の変化と今後の動向
　
　情報サービス産業協会発行のJISA会報（2010.10）に久々にアンケート調査(2010.3-4)の結果「情報サービス産業における技術動向調査2009調査報告 -浮き彫りになったソフトウェア開発実態の変化と今後の動向- 」が掲載された．数年前まで毎年実施されていた調査結果をソフトウェア工学の授業で活用していたが，最近掲載されなくなっていた． → より詳しい資料

　授業関連では，開発プロセスは依然としてウォーターフォール型が７割超だが，従業員1000人以下の数社の企業でスパイラル・インクリメンタル型が多いのは開発規模と関係がありそう．また，開発言語ではJavaが30％超でトップなのは，Webアプリケーションの増加を意味するのでは．

　プロジェクト管理面では，コスト遵守プロジェクト比率は78.0%，納期遵守プロジェクト比率は89.6%といずれも改善されているされているが，回答率はアンケート回答数のうちの60％弱で調査対象の7％程度と低い．メーカの立場上やむを得ないか．

　QCDの目標遵守率の前年比での改善状況については，日銀短観風に「改善-悪化」でみると納期遵守率（31%-5%=26%），品質遵守率（34%-5%=29%）に対し，コスト遵守率（33%-20%=13%）の改善度が低いのは，一般の景気状況を反映している．全体としての改善要因はプロジェクト計画，見積・契約，要求・要件定義が上位を占めている．

＜関連する過去のブログ＞
▼ 2009.1 システム開発プロジェクトの成功率が５年前より上昇！？ 　→ 参照


2010.7
新たな情報通信技術戦略は国民本位の電子行政を実現する？
　
5/11に高度情報通信ネットワーク社会推進戦略本部（ＩＴ戦略本部）から 「新たな情報通信技術戦略」，6/22にその工程表が公表された． 　→　記事詳細

2001年の e-Japan戦略でめざした「ゆとりと豊かさを実感できる国民生活」の成果に疑問があり，その反省を踏まえて，2006年にIT新改革戦略で「いつでも、どこでも、誰でもITの恩恵を実感できる社会の実現」を目指したが，昨秋には電子申請システムの利用率の悪さが問題となった．
（参考）
　→ 以前のブログ「2009.11　いつまで繰り返す電子政府の電子申請システムの無駄 」
　→ 関連する拙文「システムの利用率は要求分析の対象では？」（Jan. 2010）

今回の新たな戦略は果たして３度目の正直となるであろうか？
公表文書に出現する関連用語の頻度を以下に示す．数字は新たな情報通信技術戦略（18頁）での出現頻度，カッコ内はその工程表（69頁）での出現頻度
　★電子行政 11（44）
　★利便性　　6（18）
　★電子化　　5（15）
　★利用頻度　1（ 3）
　★利用率　　0（ 0）

残念ながら利用率に言及した文言なし．類似用語の利用頻度についても「利用頻度の高い行政サービスのオンライン利用の実現」という文脈で使用されており，利用率を数値目標にはしていない．またまた利用率の低いシステムが開発される可能性は残されているが，これが杞憂に終わることを望む．

・数値目標として，「国民の５０％以上が，サービスを利用することを可能とする」とあるが， これは利用率ではなく，利用可能な状態にするという従来と類似の目標であろう．

・今後の検討事項として，施策の導入前後に費用対効果の徹底検証を行うとあるが， その検証は前回の施策に対して行い，今回は事前検証を徹底すべきではないか．


2010.5
「死後１００年は世に出さぬ」遺志を保証（？）する特許
　
今週「マーク・トウェイン自伝、一世紀の封印解かれ今秋刊」という 興味深い記事あり． 　→　記事詳細

「トム・ソーヤーの冒険」の作家マーク・トウェイン(1835-1910)が生前に残していた自伝は「少なくとも死後１００年は世に出さぬよう」という本人の遺志を守り、保管されてきた。
とはいっても，自伝を部分的に引用したものは出版されているとのこと。

そこで，このような遺志を完全に実施するためには， 当方の以下の「タイムロックメッセージ」特許が有効！
とはいっても，暗号が100年間破られない保証はないけれど？ (^^;;

　→ 詳細 （タイムロックメッセージの公平な公開）


2010.2
アクセルよりブレーキを優先させるブレーキオーバーライド
　
　 　2/13にトヨタは、米国でのアクセルとブレーキに関するトラブルに関連して，安全対策強化のため、ブレーキとアクセルを同時に踏んだ場合にブレーキを優先する仕組みを大半の車種に導入する考えも表明した。ドイツ車にはほぼ完備されているとのこと．

　これまで「電子制御システムは意図しない加速の原因ではない」と答えるとともに，フロアマットにアクセルペダルが引っかかったり、アクセルペダルそのものが戻りにくくなったりする場合があるとして、米国でリコールを実施している。

［コメント］
　 ・名古屋空港で９４年に起きた中華航空機墜落事故の原因の一つとして，自動操縦システムの稼働中に手動操縦も可能な設計になっていたことがあり， 相反する機能が同時に有効になる設計という点で類似性がある．詳細は下記リンク参照：

　＊ １年前のブログ：中華航空機事故（264人死亡）の教訓は生かされなかった？
　＊ ２年前のブログ：中華航空機墜落事故のエアバス社の製造物責任を認めず
　＊ ソフトウェア工学演習の授業での電子ディベート（1997.6）

［筆者の専門分野に関連づけた話］
　オブジェクト指向プログラミングにもオーバーライド機能がある．スーパークラスのメソッドをサブクラスで再定義して，最初のメソッドの機能を変更できる．もし，電子制御システムがオブジェクト指向プログラミングで作成されていたら，メソッドのオーバーライド機能を用いて容易にブレーキオーバーライド機能を実現できるはずだが。

2010.2
トヨタ自動車のＡＢＳの制御プログラムの問題
　
　 　2/9にリコールの届け出 がされたが，「制御プログラムが不適切」だった本当の原因を知りたい．

［要点］
　 ・ＡＢＳ作動時，運転者の予測より制動停止距離が伸びる可能性あり． 国交省のリコールのページ

［トヨタの対応］
　 ・3日に問題発覚．4日には品質保証担当常務会見．運転者の感覚と車の動きが少しずれている程度と説明．5日に社長会見．お詫び．9日にリコール届出

［コメント］
　 ・ソフトウェア工学の授業で1997年の外車のＡＢＳのプログラムミスで制動距離が伸びる記事（1997.9.12）を取り上げたことがある． 国交省のリコールのページ

その時は製造物責任法（ＰＬ法，1995年施行）との関連で，プログラムミスの重大性について説明した． （著書の「製造物責任」部分抜粋） 　組み込みソフトウェアの場合は，製造プロセスの過失の有無にかかわらず，製造物責任法（PL法）の対象になる．

　 　私の興味はＡＢＳ制御プログラム．1月の新車から変更していたというが，変更の内容を知りたい．変更前の設定は時速20ｋｍでＡＢＳが作動した場合，「通常のＡＢＳより0.06秒長い0.46秒の空走感を感じ、制動距離も0.7ｍ長くなる」とのこと．これは「滑らかで静かに止まる設計」とのことだか，設計ミスだったのか？　あるいは実機テストの手抜きか？


2009.12
東証の誤発注問題の415億円の損害賠償裁判に東京地裁判決


　 2005年に株の取引で誤った発注をしたみずほ証券が、注文を取り消せずに巨額の損失を被ったのは東京証券取引所のシステム不備などが原因だとして、東証に約４１５億円の損害賠償を求めた訴訟で、東京地裁は12/4に約１０７億の支払いを東証に命じる判決を言い渡した。

［要点］
・売買を停止すべき時点以降の取引により生じた株売却損約１５０億円は東証に7割の責任

・不具合のある不完全なシステムの提供については，不具合の発見が容易との証拠がなく，重過失には当たらないと判断

［両者の対応］
東証は12/14に控訴せずとしたが，みずほ証券が12/18の控訴決定で．12/22に控訴決定

［コメント］
・サービス提供者の運用上の過失に責任が発生するという判断には異論なし．

・ソフトの不具合に重過失なしとの判断は疑問．取消機能が存在し，かつその機能にエラーがあっても責任なしとは！

・「不具合の発見が容易との証拠がない」という判断は甘くないか？
　以下の過去のブログを参照してほしい：
　→「2007.5　東証の誤発注事故（05.12）は分岐テストで防げたはず」
　→「2008.5　要件定義書に「現行と同一」という記載はありか？」

・組み込みソフトウェアの場合は，製造プロセスの過失の有無にかかわらず，製造物責任法（PL法）の対象になる．

・私の授業でも３回 →電子ディベート　を実施し，以下の結果：
　＊1回目(05.12)：入力チェックミスよりも取消処理エラーの方が重大ミス
　＊2回目(06.6)：開発者に法的責任はなくても技術的責任あり
　＊3回目(07.6)：テスト漏れに関して，技術的責任あり


2009.11
いつまで繰り返す電子政府の電子申請システムの無駄
　
11月8日の朝日新聞の一面トップの記事「国の電子申請 非効率」．いわく，
・官庁にある64システムで，全申請手続き14,327件中の92％にあたる13,129件が電子申請可能となっているが，その利用率は34％．
・総申請数に占める電子申請の割合（利用率）10％未満が，３割．
・利用率１％未満は，２割弱．
・開発費総額993億円．08年度運用経費226億円．
・利用者視点を忘れ，多額の税金を投入し，電子化実施率を競ってきた．

これは今に始まった話ではない！　
以下の論文や過去のブログ「2006.4 e-Japan戦略からIT新改革戦略へ」でも言及している．

・2003年3月の電子自治体向けフォームベースシステムに関する学会発表から抜粋：
　「中央官庁主体の電子政府に関しては、昨年度と今年度に１兆円近い政府予算が投入されながら、昨年末には、理念なしに多額の予算が使われ、電子政府は税金の無駄遣いという批判があり、予算の大幅削減を検討中とのことである。」

３年半前のブログでは
「→ 利用者の視点に立つのは、当たり前のようで、けっこう難しいようだ」
とやさしい表現で結んだが，今回は以下のように言いたい．

→ITの専門家が参加していながら，まともな「要求分析」が行われていないのではないか．


2009.8
大学教育の質の保証の３種類の視点
　
「多様化の時代の大学教育は」（朝日朝刊8/10）の記事：
シンポジウム「質保証の全体像を探る」（7/25　国立教育政策研究所主催　朝日新聞社共催）の報告に関して．

反論したくなる意見が多い中で， 小方直幸氏（広島大学）の「成果を誰の視点からとらえるのかが難しい．学生の主観は基本的に大事．一番難しいのは，政府として満足のいく学習成果はあるのか，規定できるのか．」という発言に同感．

大学教育の質の保証の視点として，少なくとも以下の３種類があるのではないか．
　・学生の視点：教育プロセス（カリキュラム，教員）の質の保証
　・企業の視点：プロダクト（個々の卒業生の社会人基礎力，学士力）の質の保証
　・政府の視点：国家百年の計（時代のニーズを先取りした教育政策）の質の保証

この中では後の項目ほど難しいと思われる．

また，天野郁夫氏（東大名誉教授）の基調講演の後半での「教育の過程や大学の評価に大きな影響力を持つという点で，企業の採用や人事政策もまた重要な，第五の質保証装置としてあげられるべきかもしれない．」という意見については，積極的に肯定したい．人材育成の下流に位置する企業の採用方針が上流の教育方針に大きな影響を与えるべきである．

これは，2007.7のブログ （続々）初任給に格差 → イノベーション で取り上げている．


2009.6
「品質が高いプロジェクトは人月単価も高い」という仮説を立証できず
　
(社)日本情報システム・ユーザー協会の「ソフトウェアメトリックス調査2009」の結果概要が 日経コンピュータ2009年6月24日号「特集 “実績” で語ろう」で紹介されている．そのなかで， 「品質が高いプロジェクトは人月単価も高い」という仮説を立てて分析したが，欠陥率と単価の 間に明確な相関はなかったらしい．

各アプリケーションの開発難易度にも依存するので厳密な分析が必要だが， ソフトウェア開発は個人やチームの能力への依存度が高い分野なので， 「単価を上げれば品質も上がる」のが定説になるべきと考える．

2009.1のブログ　「システム開発プロジェクトの成功率が５年前より上昇！？」 で，
「品質は見えないがコストはかかる」という当たり前の認識をユーザは持つべきである，
と述べたことと同じ．


2009.6
情報サービス産業の一人当たりの年間売上高
　
なお，上記の同じ記事の中で、ちなみに人月単価の平均は１１４万円ということで，
これでは，年間の一人当たりの売上高は「１３６８万円」となる．

経済産業省の「「平成19年特定サービス産業実態調査」の調査結果（確報）」によると
http://www.meti.go.jp/statistics/tyo/tokusabizi/result-2/h19.html

・ソフトウェア業務の従事者数　５０万１８０７人
・ソフトウェア業務の年間売上高　１０兆２９７５億円
・従事者１人当たり　２０５２万円

売上高を従業員数で割ったこの数字（２０５２万円）とはだいぶ開きがあるが，
人件費以外の費用が含まれるものと思われる．


2009.5
還暦を迎えたプログラム内蔵方式の実用コンピュータ
　
　米国のコンピュータ関連学会ＡＣＭのメールニュースによると、５月６日は記念すべき日
1949年5月6日　最初のプログラム内蔵方式の実用コンピュータＥＤＳAC稼働
　　↓　＜＜それから６０年＞＞
2009年5月6日　クラウドコンピューティング（プログラム「無いぞう」方式）の時代に
　　　　　　　　　　（こちらは筆者のおやじギャグ、念のため）

　詳細は以下のサイト参照：
　　 http://www.computerhistory.org/tdih/?setdate=6/5/2009
May 6, 1949 British Computer EDSAC Performs First Calculation.

ついでに、情報処理学会のコンピュータ博物館から関連記述を引用：

　　 http://museum.ipsj.or.jp/computer/dawn/history.html
　米国のペンシルバニア大では弾道計算を主目的として真空管18,000本を使用したコンピュータの ENIAC（Electronic Numerical Integrator and Computer）が1946年に開発された． これが世界最初のコンピュータ（電子計算機）とされているが， プログラムは外部制御方式で内蔵方式ではなかった．1949年にはプログラム内蔵方式としては 初めての電子計算機EDSAC（Electronic Delay Storage and Calculator）が英国ケンブリッジ大学で開発され， 以降はこの方式の計算機が次々と開発された．

　　 http://museum.ipsj.or.jp/computer/os/history.html
　1946年にペンシルバニア大学で開発された最初のコンピュータENIACではプログラムは配線で与えられた． 1949年にケンブリッジ大学のモーリス・ウイルクスにより開発された 世界最初のプログラム内蔵式コンピュータEDSACは，記号を用いて記述されたプログラムを読み込み 機械語に変換しながら記憶装置に貯えるための初期入力ルーチン（イニシャルオーダ）を備えていた．


2009.3
Barbara.Liskov のチューリング賞受賞を祝う
　
　３月１１日付けのACM TechNewsによると，２００８年度のチューリング賞は， MITのBarbara Liskov 教授に与えられるとのこと．
　　 http://www.acm.org:80/membership/turing-award2008

　すぐに思い出すのは，本格的な抽象データ型の定義機能を導入した言語CLU． 1980年前後の論文では彼女の論文をよく引用させてもらった．
　私の学位論文「段階的詳細化とデータ抽象化を支援する言語SPLの処理系と環境に関する研究 (1984.6.14)」では以下の４件を引用している． ACM SIGPLANとCACMの論文は、今も当時のコピーを持っている．
・Programming with abstract data types, ACM SIGPLAN Notices (Apr. 1974).
・Abstraction mechanism in CLU, Comm. ACM (Aug. 1977).
・An introduction to formal specifications of data abstractions,
　 in Current trends in programming methodology I, Prntice-Hall (1977).
・CLU reference manual, MIT Press (Oct. 1979).

　また、私の著書「ソフトウエア危機とプログラミングパラダイム（1992）」では， 「5.4 データ抽象化技法」の「5.4.2 CLUの例」で詳しく紹介している． １９８３年に研究室を訪問したが、不在で博士課程の学生が対応。


2009.2
中華航空機事故（264人死亡）の教訓は生かされなかった？
　
　2/19の朝日新聞の記事によると，
米ニューヨーク州バファローでボンバルディア機が墜落して５０人が死亡した事故の 原因として、パイロットによる操縦ミス説が浮上している。 事故機が空港に近づいた際、速度が落ちて自動失速警報装置が作動。 速度を回復するために自動操縦装置が機首を下げようとしたところ、 操縦士が逆に機首を上げる操作をしたため、墜落を招いた可能性が考えられるという。

　これが事実なら，中華航空機事故の場合と同じである．
１年前のブログ（2008.3）で述べたように，名古屋高裁は， メーカーの製造物責任を認めなかったが，この事故の後も 「自動操縦システムの稼働中に手動操縦も可能な設計」になっていたとは！

　再び「システム設計上のミスであると同時に、 そのミスを認識した後の運用上のミスが大きい」と言わざるを得ない．


2009.1
システム開発プロジェクトの成功率が５年前より上昇！？
　
　日経コンピュータのプロジェクト実態調査（2008.12.1号）によると、 ５年前の調査に比べて、品質、コスト、納期をすべて順守したシステム開発プロジェクト成功率が、２６．７％から３１．１％に上昇したとのこと。以下に、４項目の数値の変化を示す。

・プロジェクトの成功率：　２６．７％　→　３１．１％ 　（４．４％上昇）
　　　・品質の順守率： 　４６．４％　→　５１．９％ 　（５．５％上昇）
　　　・コストの順守率： 　７６．２％　→　６３．２％ 　（　１３％下降）
　　　・納期の順守率： 　５４．９％　→　５４．６％ 　（ほぼ同じ）

　記事内の分析結果はちょっとわかりにくいが、私の分析は以下の通り。
　成功率を上昇させるには、品質、コスト、納期のすべてを順守する必要があるので、 順守率の高いコストを犠牲にして、順守率の低い品質に注力した結果であると考えられる。 例えば、テスト工程の担当者の数を増やせば、コストは上昇するが、品質も上昇する。 問題は、品質の上昇のためのコスト上昇分をユーザ側が負担したか、 あるいは開発者側が負担したか、である。前者ならば○、後者ならば×。

　下記の講演で述べたように、開発者側の不満としてあげられる
「品質は見えないがコストは見える」のでユーザがコストにばかりこだわることに対して、
「品質は見えないがコストはかかる」という当たり前の認識をユーザは持つべきである。

　　「ソフトウェア工学：４０年目の現実」（基調講演），
　　情報処理学会 ソフトウェアエンジニアリングシンポジウム2007


2008.8
東証の派生売買システムの障害は限界値テストで防げたはず？
　
　日経ＢＰ社（http://itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/）によると、
7月22日午前に発生した派生売買システムの障害は、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分確保するべきところを、1銘柄当たり4バイトとしてしまったため、89銘柄以上の板情報の問い合わせが同時に発生すると、作業用メモリーが足りなくなり、情報配信システムがダウンしたらしい。

以下は疑問点
　・作業用エリアのオーバーフローのチェックコードがなかった？
　・開発側のシステムテストと発注側の受け入れテストのいずれにも
　　限界値のテストケースが抜けていた？
　・今回は要求仕様／機能仕様で定義した上限の 28000 個のデータの
　　テストケースを用意すべきだった。
　・しかし「板情報の問い合わせがあるのは通常数100銘柄程度」（東証広報）
　　だったのならば、28000銘柄分の作業エリアを用意するという要求も不自然。
　・たとえば、1000銘柄分を用意して、オーバーフローのチェックもするのが
　　自然とおもわれるのだが、、、
　・要求仕様と機能仕様は、本当はどうなっていたのかな？


2008.5
結晶性知能と流動性知能　→　学習度と学習エントロピー？


　 偶然、放送大学の番組で見た「結晶性知能と流動性知能」のグラフに驚き。
私の修士論文の概念に類似。
　・結晶性知能　→　学習度
　・流動性知能　→　学習エントロピー

グラフの比較など、 ＜詳細こちら＞


2008.5
要件定義書に「現行と同一」という記載はありか？


　 日経コンピュータの2008.5.1号に、みずほ証券ｖｓ東証裁判に関する記事が掲載されている。 要件定義書に「現行と同一」という記載があり、発注者側が要求定義に関して 責務を果たしたか否かについて、１年前から双方が有識者の意見書提出を 繰り返しているとのこと。

記事では言及されていないが、私の意見は、単に「現行と同一」という表現の可否が 問題ではなく、この表現に対応する現行システムの要件定義（稼動後の変更を含む）の 有無が問題。もし、対応する具体的な要件定義があれば問題ないが、もし、なければ、 「現行と同一」の要件に関して、開発側のシステムテストや発注側の受け入れテストで テストデータをどのように作成したのか疑問。

本事件に関しては、2007.5に このページ（東証の誤発注事故）で取り上げた。
また、私の授業でも３回 電子ディベートを実施。


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

　人工知能学会誌の2008年1月号の論文： 「加藤浩：もう一つの教育評価」によると、 ４０年近く前に読んだヴィゴツキ−の「思考と言語」が注目されているらしい。

　本論文によれば、「１９８０年代にカリフォルニア大学サンディエゴ校のM.Coleが自著で紹介したことが再評価のきっかけとなったといわれている」ということで、この文献の引用も１９８６年出版の英語版である。本人は１９３４年に３７歳で亡くなっているので、私の読んだ日本語の翻訳が出版された１９６２年ごろには、日本ではすでに再評価されていたことになる。私も、修士論文の研究で、１９７０年には、再（？）評価していたのだが … (^^;;

　当時の私の 電子通信学会 オ-トマトン研究会 資料（1970） では、数少ない参考文献（２件）の一つがこの本だった！

　2001年に新読書社から新訳版が出ている。明治大学の図書館に最初の明治図書の上下２セットがあるのを見つけたときも感激したが、 修士論文では、「内言」、「自己中心言語」などに注目 してモデル化した。


2008.3
４０年近く前に読んだノイマンのセルラーオートマトンが注目されているらしい。

　IEEE Computer の2008年1月号の論文： An Assessment of Integrated Digital Cellular Automata Architectures、 によると、 ４０年近く前に読んだノイマンのセルラーオートマトンが注目されているらしい。

　当時の私の 輪講資料（1969） では「現在あるような素子で実現した場合には、経済的問題があり、またコンピュータとしても幼稚なものになるので、この分野が工学として確定するためには、新しい素子を必要とするようである」と記載しているが、この「新しい素子」の時代がきたらしい。

追伸１：
　1994年からセルラーオートマトンに関する 国際会議 ACRI が開催され、今年で８回目らしい。

追伸２：
　1996年に多細胞動物で”不老不死”のクラゲ（ベニクラゲ）発見の論文発表があったらしい．
　最近のテレビ番組で自己再生シーンを見たが，これは，私の 輪講資料（1969） で
「自己増殖について・・・、あらかじめのプログラムにしたがって、正確なコピーを作る能力であって、・・・、全体が破壊していく前にコピーを作って、死を免れるようなこと・・・、システムの永久性がある。」に相当するのでは！？


2008.3
産学官連携による高度IT人材育成に死角あり

　情報処理学会の会誌「情報処理」2008年2月号に、 昨年10月に開催されたイベントの報告 「産学官連携による高度IT人材育成の現状と展望」が掲載されている。

　各方面で人材育成の先進的な取り組みがなされているが、学生の視点が弱いのが気になる。 アンケート調査から抜粋した４５項目の中では、以下の２項目が注目される。
　　・学生個人の価値が可視化され、評価されることが活性化につながる
　　・大学で訓練された学生に対する適正な処遇と連動させる必要がある

　私の意見では、昨年夏の講演「ソフトウェア工学：４０年目の現実」での ３つの話題の一つである「人材育成の上流工程の現実」で述べたように、 学生の動機づけ、すなわち「教えたい授業」から「学びたい授業」への移行が、 前提条件として必須である。そもそも、高校生がIT業界に魅力を感じなければ、 全ての努力が水泡に帰すことになる。

　そのためには、IT企業がまず以下の努力をすべきであると思われる。
　　・技術（者）重視のメッセージ発信
　　・先端産業のメッセージ発信

　その具体案に興味のある方は、 講演のプレゼン資料 の７ページ目（スライドの３７−４０枚目）を参照してください。(^^;;


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

　・朝日新聞（2/28）によると，名古屋高裁は，名古屋空港で９４年に起きた中華航空機墜落事故でエアバス社の製造物責任を認めなかった一審・名古屋地裁判決を支持し、控訴を棄却した。

　・事故は、事故機が自動操縦と手動操縦の相反する操縦で、極めて不安定で危険な状態（アウト・オブ・トリム）に陥ったことが原因とされた。

　・裁判長は、事故機の自動操縦が、操縦士が手動操縦をしていても解除されないシステムで、機体の危険な状態を知らせる警報がなかったことについて「操縦士は操縦かんの重さで危険な状態に気付く」とした一審の認定を支持。

　・本件は，私の授業「ソフトウェア工学」（３年）での 第１回電子ディベート（1996.10.3）で， 「中華航空機事故におけるソフトウェア開発者の責任の有無」 というテーマとして取り上げた． 結果は、多数意見が、ディベート前の「責任有り」（支持率６１％）から ディベート後の「責任無し」（支持率６４％）に変化し、「責任無し」グループの勝ちとなった。 ＊＊今回の判決と同じ！！＊＊

　・・・　私は当初からエアバス社の責任は重いという立場。システム設計上のミスであると同時に、そのミスを認識した後の運用上のミスが大きい。すなわち、事故の１年近く前にエアバス社は今回の不具合に気がついて、プログラムの修正の必要性を各航空会社に通知したが、単なる推奨レベルとし、緊急性を強調しなかった。少なくともこの時点で、不具合の内容を全パイロットへ周知徹底するように要請すべきだった。
　先の電子ディベートの解説では、「製造物責任法」についても言及した。


2008.1
高校卒業程度認定試験の採点ミスは限界値テスト（？）で防げたはず
　
・記事「高卒認定試験、０５年度から採点ミス」（朝日新聞07.12.28）によると、
　「・・・不具合があったのはマークシート方式の採点プログラム。大検から移行した際、世界史Ａの一部の問題を自動的に採点から排除する誤った仕様となり、１００点満点で、０６、０７年度は最大６点、０５年度は最大１２点の得点が反映されなくなった。・・・」とある。
　その後、「文部科学省は１日、０５年度からの６回の試験で、計８０人を誤って不合格としていた、と発表した。」（朝日新聞08.1.2）とのこと。

｛機能テスト（ブラックボックステスト）技術の観点｝
・網羅的なテストケースの作成方法に問題あり。
・常識的に考えて、基本的なテストケースに、満点の答案と零点の答案を含めておけば、 今回の場合は、「満点の答案のテストケース」でプログラムミスは見つかったはず。
・開発側のテストと文科省側の受け入れテストの両方から「満点の答案のテストケース」が抜けていた？！

｛後日談｝
　日経コンピュータ（2008.7.15）によると、テスト環境下で満点のテストはしていたらしい。
　「システム開発を請け負ったベンダーが本番環境だけパラメータ設定を誤った」らしい。
　とすれば、テスト環境と本番環境でパラメータの設定方法が異なるということ？
　ならば、パラメータの設定方法（手順）や確認手順はどうなっていた？？

2007.11
IT業界で再々委託全面禁止の動き　→　受験生のIT関連学科希望増加
　
　日経コンピュータの2007.11.12号に「IBMの再々委託全面禁止で、揺れる国内ベンダー」 という記事が掲載されている。利益構造の透明化を重視する米本社の意向で、 パートナー企業に対して、再委託はよいが、再々委託（３次請負）は禁止とのこと。

　「風が吹けば」じゃないが、以下のシナリオを期待したい。

◆再々委託禁止　→ ITベンダーの内製化率促進
　→ 選別受注 （注：これが重要！） 　→ 利益率アップ 　→ SE優遇
　→ SE職のイメージアップ 　→ 受験生のIT関連学科希望増加

以下は好ましくないシナリオ

◆再々委託禁止 　→ ITベンダーの内製化率促進
　→ 受注拡大＆SE職種での採用人数増加 　→ 平均的SEのスキル低下
　→ 労働集約型産業への回帰 　→ SE職のイメージダウン 　→ 受験生のIT離れ

2007.11
大幅な追加テストは仕様変更？
　
　日経コンピュータの2007.11.12号に「追加テストは仕様変更」という記事が掲載されている。

　ユーザ側から開発側に大幅な追加テスト（並行本番テストと外部システムとの接続テスト） を要求し、一括請負契約の範囲内なので費用負担は開発側とした。 開発側は大幅な追加テストは仕様変更に当たるので追加費用負担を要求した。 結局、約２００億円の費用は折半になった。

　ここで、素朴な疑問：

・ユーザ側は、受け入れテストとして独自に追加テストを実施すればよいのでは？
・開発側は、品質に自信ありなら、予定通りのシステムテストを実施し、 あとは拒否して、受け入れテストでの実施を要求すればよいのでは。

　現在の開発方法では、最終的な品質保証はテストによらざるを得ないが、 開発側がシステムテストを実施し、ユーザ側が受け入れテストを実施する という建前が実は有名無実？
　要求定義、開発、受入テスト・運用をそれぞれ別会社に発注すればよい？
　（先発、中継ぎ、抑えの分業？ 球界ではこれはスマイルカーブでは！）

2007.8
（続）長崎県庁システムとエンドユーザ主導開発
　
２年前に取り上げた下記の長崎県庁の話が、「IT調達改革の星」という見出しで、
朝日新聞（7/27）で、大きく取り上げられた。主な内容は、大企業への割高な発注を減らして、
地場企業への発注を増やし、地場企業育成と、経費節減を実現、というもの。

我々の主張する「エンドユーザ主導開発」は、少し観点が異なり、以下のような趣旨である。
・2001年3月の学会発表
　 「絶えざる変化に対応するエンドユーザ主導型アプリケーション開発技法」から引用

「開発費の面だけでなく、サービスの変化に迅速に対応するという面からも業務の専門家が
自らの業務を自ら自動化するのためのエンドユーザ主導型アプリケーション開発技術が必要」

長崎県庁システム（長崎ITモデル）（2005.9）

・長崎県庁では「職員が詳細仕様作成」（日経コンピュータ05.7.25号）
　職員が画面設計と業務要件を決定後、詳細仕様書に基づき入札実施

・名古屋銀行でも「融資部が業務システムの全画面を自ら開発」
　（日経コンピュータ05.3.7号）

・明大中研創立(1993)以来の看板「エンドユーザ主導開発」の実現例として注目
　wwHwwプロジェクト（ＵＩ駆動型開発）に類似


2007.7
（続々）初任給に格差 → イノベーション
　
　日本経団連の夏季フォーラム（７月２６日）初日は教育問題を議論。御手洗会長は、学生を成績や論文で評価し、入社から給料に格差をつける仕組みの導入を提案した。採用の改革について「平等に採用して会社では年功序列。競争の原理からほど遠く、イノベーション（革新）は生まれない。社会正義を平等から公平に変え、それに沿った学校教育、採用試験、給料体系にしないといけない」と呼びかけた。（朝日 7/27）

「（続）初任給にスキルによる給与格差 → 大学改革」（2006.05）
　某IT企業は2006年4月入社の新卒社員５１名のうち、 入社時のスキルや知識が高いと判断した２名の年収を上乗せ（150万円、125万円）した。 （日経コンピュータ 06.5.15号）
　→→→ 月給２０万円と３０万円の差は大きい。
　情報系の学生の向学心に火が付けば、大学の授業がおもしろくなる！
　以下のシナリオは私の持論（大学改革の早道）：
　　↓「企業が学生に質の高いスキルを要求（初任給に差）」
　　↓「学生が教員に質の高い授業を要求」
　　↓「学生と教員の間に緊張感」
　　↓「学生が教員（大学）を育て、教員（大学）が学生を育てる」
　　　（これも双方向授業！？）

「初任給にスキルによる給与格差」（2006.01）
　某IT企業は2007年4月入社の新卒社員から、入社時の評価試験で一定のスキルを有すると判断した場合、月３万円〜５万円を月収に上乗せするそうである。 （日経コンピュータ 06.1.23号）

　かつて、情報処理学会の 解説論文（1991年8月号 pp.950-960）に記載した以下の内容がやっと現実になるかもしれない。情報系の学生の向学心にも火が付くかも。(^^)
　　↓「この業務は個々の技術者の能力差が大きい」
　　↓「個人の能力に応じた収入を得られる」
　　↓「多くの人々が優秀な情報処理技術者になるために、自らすすんで努力をする」
　　↓「お金さえ払えば、優秀な技術者が作る良質のソフトウェアをタイムリに入手できる。」


2007.7
大規模システムの深刻な障害の多発の原因
　
・緊急座談会「テストで障害は解決しない」（日経コンピュータ 07.7.9号）に、 F、H、I、N社の「ベテランマネジャが語る現場の実態」 が掲載された。 大規模システムの深刻な障害の多発の原因 が分析されている。

　いくつかの分析に対する私のコメントは以下の通り（→の部分）：

・十分なテストの困難性
　特定の条件が重なったときに顕在化するロジックミスをテストで検出するのは難しい。 システムが複雑化しており、障害をテストだけで取り除くのは不可能。 品質は上流工程から作りこむべき。

　→ テストできないものは工業製品にあらず。プログラミングはまだまだアートの世界？

・机上レビューの不十分性
　以前の机上レビュー重視にかわって、作ってから検証すればよいという傾向あり。今は簡単にプログラムを作成できるので、ロジックの検証作業が甘くなっている。画面に表示された範囲のチェックで全体が確認できているのか。

　→ ７０年代のアセンブリ言語のプログラマとしては同意。ラインプリンタで出力したソースリストや１６進ダンプを机上でじっくり見ていた時代とは様変わりで、ちょっとソースをいじってはすぐ実行してみるスタイルでは、木を見て森を見ずか！

・ドキュメント不備
　本来、大規模システムのプログラムとドキュメントは同じ水準でなければならないのに、不十分なドキュメントでプログラムを作成。

　→ 大規模システムにアジャイル開発は似合わない！

・品質よりコスト重視 　品質を度外視したコスト削減要求が増加。品質は見えないが、コストは見える。 テスト作業の不足による外注した単体プログラムの質の低下が見られる。 品質レビューやリスク管理の形骸化。

　→ IT業界のデフレスパイラル？？

・要件定義の困難性 　ユーザ企業の発注部署がIT部門から業務部門に変わってきて、業務要件からシステム仕様への翻訳段階で 誤解が生じやすくなっている。

　→ システムアナリスト不在？　しかし、業務部門が開発に直接関与するのはよい傾向では！

・アーキテクト不足 　種々のコンポーネントを組み合わせて開発するオープン系システムでは、 IT技術者が専業化・分業化しており、技術的に全体を見る人が不在。

　→ アーキテクチャに関する技術の進歩／変化が早すぎて、人材育成のキャリアパスを確立できない？　 （プロジェクトマネージャの育成のようには時間をとれない）

・不特定ユーザ向けシステムの使用性の予測困難性 　システム開発前にユーザの使い方を予測しきれない。

　→ 「予期せぬ出来事を予期する」パラドックスの世界か？

拙文「知の現在： なぜコンピュータは間違えるか？， 思索の樹海，明治大学，pp.41-46, 1998.4」では、以下のように締めくくったが：

「人間は予期せぬ出来事を予期できるか？」という逆説的命題を乗り越えて、 新しいパラダイムが確立する日まで、コンピュータは人間が教えたように間違うということを 忘れてはならない。


2007.5
東証の誤発注事故（05.12）は分岐テストで防げたはず
　
・記事「誤発注裁判で見えてきた不具合の真相」（日経コンピュータ 07.4.30号）に、 システムの不具合の原因となったプログラムミスの説明がある。（原告がソースコード提出を要請）
　私の分析結果は以下の通り：

・テストの問題

　｛構造テスト（ホワイトボックステスト）技術の観点｝
　注文取消しに関して、８０００件のテストケースがあったが、 分岐テストの網羅率測定はしていなかった。 今回のプログラムミスは、分岐判定条件が常に偽になるものなので、 網羅率測定をしていれば、条件が真になるテストケースが 抜けていることがわかったはず。

　｛機能テスト（ブラックボックステスト）技術の観点｝
　今回の判定条件が注文取消しに関する要求仕様に含まれていたのならば、 網羅的なテストケースの作成方法に問題あり。

　｛再テスト（回帰テスト）の観点｝
　運用テストで見つかった欠陥の修正のために条件分岐を追加したのならば，そのテストデータを追加作成してテスト実行するのは当たり前だし，他への影響がないことを確認するための再テスト（回帰テスト）も必要のはず。

・設計の問題
　分岐判定条件の評価に必要な情報の入手先のＤＢの選択を間違えたということは、 設計において、アプリケーションからアクセスするＤＢ情報の 書き込みや削除の詳細情報が明記されていなかったか、 あるいは、アプリケーション開発担当者が設計時にそれを見落としたことになる。

・業務分析の問題
　事故後の修正段階で開発者側から分岐判定処理そのものの削除が提案されている。 要求定義段階で、不必要に細かい処理手順が記述されていたということか。


2007.2
Ｊａｖａ言語のオープンソース化
　
・JavaはGNU General Public Licenseバージョン2（GPLv2）ライセンスのもとで
　→　フリーソフトウェア化
・私の授業での10年前の 電子ディベートも今は昔。
　→　第５回：「最近のJava言語をめぐるサンとマイクロソフトの争いについて」（1997.10）

・技術雑誌 JavaWorld も最新号（２月号）が最終号（役割を終えたとか）
　→　「Javaの技術的な成熟度」and/or「上流工程（要求分析や設計）志向」

・余談：ＧＰＬの推進者 Richard Stallman の講演を１年前に拝聴
　→　サンセバスチャンの国際会議（06.1）にて
・余談の余談：下記の拙著にて、Richard StallmanのEmacsを２頁紹介している！
　→　プログラミングツ-ル、昭晃堂 (Apr. 1989)(「4.3.2 画面エディタ」に記載)


2006.12
番外編：唐十郎 特別展
　
・２００６年１１月〜１２月、明治大学リバティタワーにて。 　
・１９６２年、彼は、明治大学文学部卒業（演劇学専攻）だった！ 　
・１９７５年頃、状況劇場、紅テント時代に何度か演劇を見たことがあり、感慨深い。 　
　　　（懐古趣味にて→ 詳細はこちら）


2006.09
知財立国（特許査定率）
■
「２１世紀型知的財産戦略の深化に向けて」という副題のついた
　　2006年9月の特許庁レポートによると、

・特許査定率＝特許査定件数／最終処分件数は、５０％前後。
　　　　　　　（審査請求したもののうちで特許になった割合）
・2004年の特許出願数１位（約17000件）の松下電器産業で、46.7%、
　２位（約11000件）のキャノンで、51.6%．

・私の場合（独力で出したものに関して）：３勝３敗（５０％）で、まずまず。
　　　　　 → 特許リスト
　ただし、特許利用率は全体では５０％弱であるが、私の特許はまだ０％。 (^^;;


2006.07
人工知能５０周年

◆
・1956：50年前の夏，人工知能の研究がスタート
　　　"Dartmouth Summer Research Project on Artificial Intelligence" 開催．

◆「ＡＩと私：ショートストーリー」◆
・1968：学習機能を研究テーマとする（ 学会発表(1) 　調査報告）
・1970：思考モデルとシミュレータの開発（ 学会発表(2) 　 学会発表(3)）
　　　＊＊1971-1982：この間，ソフトウェア工学の研究へシフト＊＊
・1983-1986：知識処理言語の開発（→the 10th WCC (1986.9)などで発表）
・1986-1988：エキスパ-トシステム構築ツ-ルの開発
　　　　　　（→情報処理学会(1987.10)などで発表、学会論文）
・1988：共著「人工知能」（昭晃堂）発行
・1990：学会論文
・1992：著書「ソフトウエア危機とプログラミングパラダイム」（啓学出版）発行
　　　＊＊この後，ソフトウェア工学の研究へリターン＊＊
◆
　ただし、上記著書で述べた知的クローン（Intelligent Clone）、即ち、「自分がやりたいことをやってくれる」究極のソフトウェアの研究は ＩＣ プロジェクト として継続中。


2006.5
（続）初任給にスキルによる給与格差 → 大学改革
　
　某IT企業は2006年4月入社の新卒社員５１名のうち、 入社時のスキルや知識が高いと判断した２名の年収を上乗せ（150万円、125万円）した。 （日経コンピュータ 06.5.15号）
　→→→ 月給２０万円と３０万円の差は大きい。
　情報系の学生の向学心に火が付けば、大学の授業がおもしろくなる！
　以下のシナリオは私の持論（大学改革の早道）：
　　↓「企業が学生に質の高いスキルを要求（初任給に差）」
　　↓「学生が教員に質の高い授業を要求」
　　↓「学生と教員の間に緊張感」
　　↓「学生が教員（大学）を育て、教員（大学）が学生を育てる」
　　　（これも双方向授業！？）

「初任給にスキルによる給与格差」（2006.01）
　某IT企業は2007年4月入社の新卒社員から、入社時の評価試験で一定のスキルを有すると判断した場合、月３万円〜５万円を月収に上乗せするそうである。 （日経コンピュータ 06.1.23号）

　かつて、情報処理学会の 解説論文（1991年8月号 pp.950-960）に記載した以下の内容がやっと現実になるかもしれない。情報系の学生の向学心にも火が付くかも。(^^)
　　↓「この業務は個々の技術者の能力差が大きい」
　　↓「個人の能力に応じた収入を得られる」
　　↓「多くの人々が優秀な情報処理技術者になるために、自らすすんで努力をする」
　　↓「お金さえ払えば、優秀な技術者が作る良質のソフトウェアをタイムリに入手できる。」


2006.04
e-Japan戦略からIT新改革戦略へ
　
・2001年の e-Japan戦略から５年が過ぎた．「ゆとりと豊かさを実感できる国民生活」に注目していたが、成果に疑問などの批判もある．

・2006年にIT新改革戦略「いつでも、どこでも、誰でもITの恩恵を実感できる社会の実現」が発表された．

・当研究室では、1994年からCS-life（Computer-Supported Life：コンピュータによる豊かな生活の実現）をモットーに研究をしてきた．

・1994年11月のコンピュータソフトウェアの 巻頭言「CS-life」から抜粋：
　「生産者中心の視点から利用者中心の視点への転換が必要」
　「仕事の効率化よりも生活を豊かにすることにもっと知恵を絞ってはどうか」
　「身近なところからはじめて本質に迫るというアプローチが必要」

・1994年3月の 電子申請の研究に関する学会発表から抜粋：
　「すべての日常的仕事はコンピュータが代行すべき」
　「業務の専門家が自らの業務を自らコンピュータ化できるような技術が必要」
　「急速な老齢化社会の到来と若年労働者の減少への対応」

・2003年3月の電子自治体向けフォームベースシステムに関する学会発表から抜粋：
　「中央官庁では重複開発、地方自治体では手つかずの状態という正反対の現象が生じたが、システムの個別開発という点では共通している」

→ 利用者の視点に立つのは、当たり前のようで、けっこう難しいようだ。


2006.1
初任給にスキルによる給与格差

　
　某IT企業は2007年4月入社の新卒社員から、入社時の評価試験で一定のスキルを有すると判断した場合、月３万円〜５万円を月収に上乗せするそうである。 （日経コンピュータ 06.1.23号）

　かつて、情報処理学会の 解説論文（1991年8月号 pp.950-960）に記載した以下の内容がやっと現実になるかもしれない。情報系の学生の向学心にも火が付くかも。(^^)
　　↓「この業務は個々の技術者の能力差が大きい」
　　↓「個人の能力に応じた収入を得られる」
　　↓「多くの人々が優秀な情報処理技術者になるために、自らすすんで努力をする」
　　↓「お金さえ払えば、優秀な技術者が作る良質のソフトウェアをタイムリに入手できる。」


2005.11
リファクタリング
　
・今のリファクタリング → 昔のリストラクチャリング？

・1970年代：スパゲティプログラムから構造化プログラムへ
　最近のテスト駆動型開発（TDD）では、インクリメンタルなコード作成で
　プログラム構造が複雑になると、リファクタリングで構造化するとか。

・ソース変換技術：1970年代のsource-to-source変換
　当時、厳密な仕様から効率的なプログラムを生成する技術としても扱われた。
　（再帰的表現をループに変換とか）
　変換規則が多すぎると，適切なものを検索するのが困難になる。
　変換規則が基本的なものに限定されると，スキルが要求される。

・我々も２段階プログラミング（構造化→最適化）を提唱　(^^;;
　（ 学会発表：UJCC78, IFIP80，IFIP83）
　ソースコード変換ツールCROPS開発（プログラムの構造化と最適化）
　CROPS : Conversational Restructuring, Optimizing and Partitioning System


2005.9
長崎県庁システム（長崎ITモデル）
　
・長崎県庁では「職員が詳細仕様作成」（日経コンピュータ05.7.25号）
　職員が画面設計と業務要件を決定後、詳細仕様書に基づき入札実施

・名古屋銀行でも「融資部が業務システムの全画面を自ら開発」
　（日経コンピュータ05.3.7号）

・明大中研創立(1993)以来の看板「エンドユーザ主導開発」の実現例として注目
　wwHwwプロジェクト（ＵＩ駆動型開発）に類似


2005.7
ＭＤＡ，モデル駆動型開発
　
・MDA : model driven architecture
　UMLで記述したモデルからプログラムを自動生成

　→ 明大中研の M-base プロジェクト（1995.5 学会発表）の下記特徴と類似
　・モデリング重視とプログラム自動生成
　・モデリング＆シミュレーションでソフトウェア開発終了
　・ドメインモデル≡計算モデル
　・分析≡設計≡プログラミング


2005.5
Ｊａｖａ言語１０周年
　
・１０年前：Networld+Interop*95（1995年7月19-21日、幕張メッセ）で、
　「Java言語環境」（A White Paper）入手　＜写真＞

・明大中研では、公式言語を C++ から Java 言語に変更；　以下は初期のJava作品：
　　＊簡易対話ツールV-Saloon（ 仮想サロン）（ 1996.9 学会発表）
　　＊ビジュアルモデリングツール M-base：＜Java大賞97　技術部門予選通過＞


2005.4
ＴＤＤ（テスト駆動型開発）と単体テストツール
　
　関連する解説記事への疑問：
・ブラックボックステスト（機能テスト）だけではロジックのテストは不十分
・ホワイトボックステスト（構造テスト）もＣ０（全文実行）カバレッジでは不十分

・単体テストツール（Jtestなど）の特徴といわれるテスト工程の自動化について：
　我々も開発経験あり！（単体テスト自動化ツールHITS開発、実用化）
　HITS : Highly Interactive Testing-and-debugging System
　／テスト環境模擬機能／テスト手続き言語／　
　→1983年に学会発表（ NCC'83、 情報処理学会解説 1983.7）


2005.3
Ｗｅｂサービス連携
　
◆Ｗｅｂサービス連携と明大中研の M-base プロジェクトの関係
・M-base のコンポーネント組み合わせのモデリング法の技術課題の解決
　　＊コンポーネントモデルの設定：Ｗｅｂサービスにより一般化
　　＊新規コンポーネント開発：エンドユーザが外部仕様を決定可能

◆Ｗｅｂサービスと明大中研の wwHww プロジェクトの関係
・wwHww の受付窓口インタフェースは、サービス授受のメタファー

◆プロジェクトＭに統合


2005.2
Ｅｃｌｉｐｓｅ
　
・Javaアプリケーション開発用の統合開発環境：プラグインで機能追加可能

・我々の言語適応型プログラミング環境 PERFECT のサンドウィッチ型アーキテクチャ：
　フロントエンドの対話処理系とバックエンドのプログラム解析系の間に
　ツール群をはさみこむ概念と類似（？） （1983年に 学会発表：IFIP83）
　PERFECT : Programming EnviRonment For Editing, Compiling and Testing