「ソフトウェア工学・演習」での電子ディベート

(注)1年生のゼミナール1のディベートはこちら


 <課題リスト →詳細は後述>
 
 ■2015.6.10 物流管理システム刷新に失敗(日経コンピュータ 2014.12.25)
 ■2014.6.4 ハイブリッド車「プリウス」の電子制御プログラムの不具合
 ■2013.7.10 東証裁判の争点を洗い出す(日経BPの2013.4.1の記事)
 ■2011.6.22 ハイブリッド車「プリウス」の電子制御プログラムの不具合
 ■2008.6 政府の「人事・給与関係業務情報システム」の開発が難航
 ■2007.6 誤発注裁判で見えてきた不具合の真相
 ■2006.6 東証の誤発注事件に関して,開発(設計,プログラミング,テスト)段階で
      仕様の不備に気づくべきではなかったか
 ■2005.12 ジェイコム株誤発注事件に関して,システム構築の観点では,
       現実にありえない注文を受け付けてしまったミスと、
       注文取消しを受け付けないようになっていたミスと、
       どちらの問題をより重大なミスと考えるか。
 ■2005.6 基幹系システム刷新が難航」について,
      本来、要求仕様はどのように決められるべきであったか」
 ■2004.10 オープンソースに対しては知的財産権を無償提供すべき(開放派)か,
      オープンソースであっても知的財産権は保護されるべき(保護派)か
 ■2004.6 Oh-o!Meijiシステムの現在の仕様に関して、利用者の立場から意見を述べよ
 ■2001.12 日本の情報処理技術者に関して、優秀なプログラマの教育を促進すべきか、
      あるいは、パッケージソフトウェアを積極的に利用するべきか、
        情報処理(2001年9月)の以下の2件の解説を教材とする:
         「プログラミングをしないコンピュータ先進国」
         「SEの知恵袋:作りたがーるSE」
 ■2001.6 履修登録システムにおいて、受講者名簿や個人別時間割表は、
      毎回作成する方式と、初回の作成版を保存・保守する方式のどちらがよいか
 ■2000.6 履修登録システムの入力端末は汎用端末と専用端末のいずれがよいか
 ■1998.11.25 西暦2000年問題について
 ■1998.5.27 履修登録システムの入力端末は汎用端末と専用端末のいずれがよいか
 ■1997.10.29 最近のJava言語をめぐるサンとマイクロソフトの争い
 ■1997.4.30 実録 巨大システム全面刷新の成功はユーザ側/メーカ側のいずれの功績か
 ■1996.11.28 エンドユーザ主導のソフトウェア開発の実現可能性
 ■1996.10.17 DVDに関する地域(米国,欧州,日本)ごとの異なる仕様設定の是非
 ■1996.10.3 中華航空機事故におけるソフトウェア開発者の責任の有無


■「ソフトウェア工学演習」 2015.6.10課題

 以下の配布資料を読み,最も関心を抱いた事柄を一つ選んで意見を述べよ.

 ・日経コンピュータ 2014.12.25 物流管理システム刷新に失敗



◆課題回答のグループ分け:87名



・23名:開発側に責任あり

    (引き受けた業務の不履行・・・)

・ 3名:依頼側に責任あり

    (システム完成への意欲・責任感の欠如,上から目線)

・10名:要求分析・仕様変更に問題あり:

・13名:テストに問題あり

    (システムテスト,結合テスト手抜き,単体テスト不十分)

・38名:その他

    (プロジェクト管理,双方の信頼関係・コミュニケーション)

以上


■ソフトウェア工学演習(2014.6.4)(注)2011.6.22の課題と同じ

<課題>

ハイブリッド車「プリウス」の電子制御プログラムの不具合についての

配布資料を読み,下記のいずれかを選択して,自分の意見を述べよ.

 

(a)自動車会社は事故の原因が電子制御プログラムの不具合でないことを証明する義務がある.

(b)自動車会社に事故の原因が電子制御プログラムの不具合でないことの証明を要求するのはやりすぎである.



結果:

A:「証明の義務あり」53票

 安全(人命)にかかわるので当然.会社のためにもなる.

 企業の信頼性にかかわる(信頼性にお金を払っている)

 不具合が発生した以上,確認義務有

 どれだけのテストをしたかの説明責任.

 全力を尽くす姿勢が重要.



B:「証明は過度の要求」26票

 バクのないプログラムは不可能

 すべてのパターンのテストは不可能.エレベータやジェットコースターも同じ.

 フェールセーフ(事故が発生しても安全)になっていればよい.

  (非常ブレーキなどを加えて,安全性を高める)

 証明の義務はないが責任はある=>製造物責任法,再発防止の義務はある.

 第3者にゆだねる

 安全基準を設定すべき(車検などと同様に)





(注)今回の結果(53:26)と2011.6.22の結果(78:54)を比較すると

   「証明の義務あり」が,59%から67%に増加している.

   開発者の立場より利用者の立場で考える学生が増えたということか?


■「ソフトウェア工学演習」(2013.7.10)課題

 配布資料(東証裁判の争点を洗い出す,日経BPの2013.4.1の記事)について,

以下の3項目の争点の各々について,指示するほうに(○)を記入して,その理由をのべよ. 



1. バグは重過失にあたるか?

 (Y)みずほ証券の主張:17票 (N)東京証券取引所の主張:22票

(評)4/10の挙手による調査では{0:19}だったので,

賛成の増加(0%→44%)は,テスト技術の授業が影響と思われる.



2. テストでバグを見つけることはできたか?

 (Y)みずほ証券の主張:19票 (N)東京証券取引所の主張:19票

(評)4/10の挙手による調査では{5:18}だったので,

賛成の増加(22%→50%)は,テスト技術の授業が影響と思われる.



3. ソースコードの変更は設計書に反映すべきか?

 (Y)みずほ証券の主張:31票 (N)東京証券取引所の主張:8票

(評)4/10の挙手による調査では{17:3}だったので, 

賛否に変化なし(81%→79%)は,授業内容ではないので影響なしと思われる.



なお,4/10の最初の授業で,同じ資料を配布したが,挙手で調査のため,数は少ない. 


■ソフトウェア工学演習(2011.6.22)

<課題>

ハイブリッド車「プリウス」の電子制御プログラムの不具合についての

配布資料を読み,下記のいずれかを選択して,自分の意見を述べよ.

 

(a)自動車会社は事故の原因が電子制御プログラムの不具合でないことを証明する義務がある.

(b)自動車会社に事故の原因が電子制御プログラムの不具合でないことの証明を要求するのはやりすぎである.



結果:

A:「証明の義務あり」78票

 安全(人命)にかかわるので当然.会社のためにもなる.

 企業の信頼性にかかわる(信頼性にお金を払っている)

 開発者を信じて命を懸ける気にはならない

 不具合が発生した以上,確認義務有

 論理的な証明は必要

 不具合の確率は低くてもゼロではない.プログラム更新の内容を公開すべき.

 ログを記録して分析すべき

 どれだけのテストをしたかの説明責任.

 全力を尽くす姿勢が重要.

 第3者にゆだねる



B:「証明は過度の要求」54票

 バクのないプログラムは不可能(MSは頻繁に修正している).

 厳しすぎると技術の進歩の妨げ.厳しくしすぎると偽装が発生する.

 すべてのパターンのテストは不可能.エレベータやジェットコースターも同じ.

 フェールセーフ(事故が発生しても安全)になっていればよい.

 証明の義務はないが責任はある=>製造物責任法,再発防止の義務はある.

 ユーザ側が因果関係を証明すべき

 実験結果を公開すればよい.

 第3者にゆだねる

 安全基準を設定すべき

 ソフトウェアの公開は,機密保持が難しい.→ハッカーの対象にもなる

 事故の再現はむつかしいのでは.



●追伸:2014.6.4実施の結果 53:26(2011の時 78:54)


■ソフトウェア工学演習(2008.6)

政府の「人事・給与関係業務情報システム」の開発が難航している記事について:

・本システムの目的:

 *運用費削減(共同利用で,約8億円節約,当初は20億円)

 *業務プロセス改善→処理の効率化(年間1050万時間の処理時間短縮)



本件で最も重大と思われる問題点を1つあげよ.

 A:開発すべきでなかった  

 B:開発計画は妥当だが,開発方法に問題あり



結果:

A:33票

  13: 省庁間の協力関係がなく,仕様決定は無理

  10: もともと無理(複雑さ,規模,期間,カスタマイズ禁止方針,リスク管理など)

  10: 膨大な開発費(これは結果論だが,,,見積もり誤りの面も,,)



B:93票

  15: 省庁間の協力関係がない

  17: 仕様が不十分

   8: カスタマイズ禁止方針は間違い

  36: 詳細設計情報を各省庁(ユーザ)に公開しなかったのは間違い

      (この段階では遅すぎる.クレームに対応できないで,混乱する)

  17: その他(1.に属する意見など)

■第16回:(2007.6)
配布資料:「誤発注裁判で見えてきた不具合の真相」(東証システム,バグが入っていたのは運用テストの公算大)
に関して,システム構築の観点で,以下のどちらの意見か.
 (a) 容認(今回のケースではテスト漏れもやむを得ない.)
 (b) 反対(テスト漏れに技術的な責任がある.)

<結果の単純な集計 ・容認:43名, ・反対:48名>
<技術的責任論では ・容認: 4名, ・反対:11名>

評:
過去の電子ディベートに比べ、再反論が多く,ディベートらしさあり.
立場上,反対のほうが説得力のある意見を主張しやすいことが影響している可能性大.
容認派では、「稀な例外」、「注文取り消しで8000件のテストケース」、「5年半正常稼働」、
「人間に誤りは避けられない」、「バグ皆無は困難」、「IT技術者は株取引の専門家ではない」などの理由多し.
反対派では、技術的な責任とは別に、結果責任に言及したもの多し.
技術的な責任に関しては、「5回の判定のテスト実施可能」、「運用テスト時の再テストの義務」などの理由が多い。

■第15回:(2006.6)
 東証の誤発注事件に関して,システム構築の観点で,「開発者側に法的責任はないとしても,
開発(設計,プログラミング,テスト)段階で,仕様の不備に気づくべきではなかったか」
という技術的責任の有無について

 <結果の単純な集計 ・責任なし:45名, ・責任あり:53名>
 <技術的責任論では ・責任なし: 6名, ・責任あり:26名>

■第14回:(2005.12)
 ジェイコム株誤発注事件に関して,システム構築の観点では,現実にありえない注文を受け付けてしまったミスと、
 注文取消しを受け付けないようになっていたミスと、どちらの問題をより重大なミスと考えるか。

 <結果 事前検証派24名:事後処理派27名>

後日談:
 <1月末の記事では,明らかな異常注文を自動的に排除する機能を4月末までに実現>
 <3月の記事では,上場企業の発行済み株式数の3割を超える注文は受け付けない方針>
 <6月から新規上場株式の注文は、公募価格の4倍から1/4の範囲のみ受けつける>
 <10月27日、みずほ証券は東証に約415億円の損害賠償請求訴訟を地裁に提起>
 <12月15日の第一回口頭弁論(東京地裁)で,東証は「取引所の義務は取引参加者が
  市場に参加できるようにすること。一つひとつの注文を処理する契約上の義務はない」と述べた。>
 <2007年4月、第三回口頭弁論(東京地裁)で,システムの不具合の原因となったプログラムミスの
  内容があきらかになった。結果的には、分岐テストをしていれば防げたはずのミスだった。
  そのミスの誘因は、要求定義、設計段階にもある。>
 <6月8日、第四回口頭弁論(東京地裁)東証側はバグのあったプログラムのソースコード提出せず。>
 <第5回口頭弁論(8月31日、東京地裁)「ソフトウェア開発請負契約書」に、成果物に関する一切の
  権利は、東証による検収後、東証に移転すると定められているので,東証にソースコードなどの
  提出命令を申し立てた。>
 <第6回口頭弁論(11月16日、東京地裁)東証が提出した資料の「第5回総合テスト」の障害件数は
  31件となっているが、別の提出書類には13件と示され、2000年3月発行の「東証だより 3月号」には
  36件と記述してあるという。>
 <第7回口頭弁論(2008年1月18日、東京地方裁判所)裁判長は「訴訟の判断にシステムの詳細な情報は
  必要ない」とした。 前回の障害件数に齟齬については、東証側が準備書面を提出したが、
  「考えられる」「推測される」などの表現が多用され、「抽象的で無責任な主張」(原告)>
 <第8回口頭弁論(2008年3月14日)原告のみずほ証券側は、誤発注の取り消し注文を出したにもかかわらず、
  被告の東証が取り消し処理を行わなかったという「取消処理債務の不履行」に加えて、新たに
  「付合せ中止義務の違反」、「売買停止義務の違反」という2つの主張を追加した「訴え変更申立書」を
  2月25日付で地裁に提出した。付合せ中止義務違反は、明らかな誤発注にもかかわらず、
  東証が付合せ(マッチング)を保留しなかったことが、取引参加者契約に基づく
  善管注意義務(善良なる管理者の注意義務)に反するという主張だ。>
 <第9回口頭弁論(2008年5月9日)原告のみずほ証券側は、被告の東京証券取引所にシステムの
  発注者としての注意義務違反と重過失があったことを改めて主張する準備書面を地裁に提出した。
  みずほ証券側は「東証はシステムの発注者として、業務上の要求を富士通に伝え、
  富士通が開発したプログラムが要求と整合しているかをテストする責任がある」と訴え、
  「誤発注の取り消しができなかったのは東証の重過失だ」と主張した。>
 <東京地裁判決(2009.12.4):売買を停止すべき時点以降の取引により生じた株売却損約150億円は
  東証に7割の責任ありとして、約107億の支払いを東証に命じる判決>

■第13回:(2005.6)
 配布資料「基幹系システム刷新が難航」について,「本来、要求仕様はどのように決められるべきであったか」

 <結果1 営業担当者の意見採用 9名:経理担当者の意見採用 56名>
 <結果2 東京の意見採用 45名:大阪の意見採用 9名>

■第12回:(2004.10)
 「オープンソースに対しては知的財産権を無償提供すべき(開放派)か,
 オープンソースであっても知的財産権は保護されるべき(保護派)か。」

 <結果 開放派 54名:保護派 36名>

■第11回:(2004.6)
 「Oh-o!Meijiシステムの現在の仕様に関して、利用者の立場から意見を述べよ」

■第10回:(2001.12)
 「日本の情報処理技術者に関して、優秀なプログラマの教育を促進すべきか、
 あるいは、パッケージソフトウェアを積極的に利用するべきか」
 情報処理(2001年9月)の以下の2件の解説を教材とする:
 「プログラミングをしないコンピュータ先進国」(宍戸周夫)
 「SEの知恵袋:作りたがーるSE」(妹尾稔/三井一夫)

 <ディベート前のレポート結果 プログラマ育成派 57名 パッケージ積極利用派 34名>
 <ディベート後の投票結果 プログラマ育成派 40名 パッケージ積極利用派 28名>

■第9回:(2001.6)
 「履修登録システムにおいて、受講者名簿や個人別時間割表は、毎回作成する方式と、
 初回の作成版を保存・保守する方式のどちらがよいか」

■第8回:(2000.6)
 「履修登録システムの入力端末は汎用端末と専用端末のいずれがよいか」

(注)最初の7回分(1996 - 1998)は以下に詳細掲載


*** パソコンとインターネットを用いた実験授業(PCプロジェクト) ***

*** 最終報告書, pp.64-69 (1999.3). ***


第1回:「中華航空機事故におけるソフトウェア開発者の責任の有無」(1996.10.3)
第2回:「DVDに関する地域(米国,欧州,日本)ごとの異なる仕様設定の是非」(1996.10.17)
第3回:「エンドユーザ主導のソフトウェア開発の実現可能性」(1996.11.28)
第4回:「実録 巨大システム全面刷新の成功はユーザ側/メーカ側のいずれの功績か」(1997.4.30)
第5回:「最近のJava言語をめぐるサンとマイクロソフトの争いについて」(1997.10.29)
第6回:「履修登録システムの入力端末は汎用端末と専用端末のいずれがよいか」(98.5.27)
第7回:「西暦2000年問題について」(98.11.25)

(1)教員(氏名、所属学部)



  中所 武司  理工学部



(2)担当科目名と参加学生数



  理工学部 情報科学科「ソフトウェア工学」と「ソフトウェア工学演習」

  約100名(主に3年生)



(3)実験のねらい



  日本の社会は、今、歴史的な転換期にある。従来のように技術先進国(米国)の

後追いをしていればよい時代には、”教科書”から知識を吸収して実践、改良して

いく人材が求められていた。しかしながら、これからは、自ら問題を発見して、

それを解決していく独創性が求められている。このような、自ら考え、自ら行動する

人材にもっとも重要なことは、「議論に強くなる」ことであると考える。なぜなら、

議論するためには自分の考えをもち、相手に理解させるだけの論理を構築し、表現する

能力を必要とするからである。

  ところが残念なことには、現在の学生は、小学校以来、授業中に議論するという

文化になれていないため、100人くらいの多人数の授業では、積極的に挙手をして

発言する学生はまれである。しかし、ミニレポートの形で書かせると多くの学生が

自分の意見を書く。

  そこで、インターネットを利用したディベートにより、学生が議論に慣れることを

目的とする。



(4)実験内容



  以下のような方法で、学生同士にディベートさせる。

 (1) まず、課題に対する回答をレポートとして提出させる。

 (2) 対立する2つの意見を代表するグループ(5人ー7人ずつ)を選出し、

     電子掲示版でディベートさせる。(他の人もディベートへの参加は自由とする)

 (3) 適当な時期に、上記のディベータ以外の全員にどちらの意見を支持するか、

     電子掲示版上で1回だけ記名投票(支持理由も記入)させる。

 (4) 最後に教員が見解を述べる。



(5)実験結果



  3年間のプロジェクト期間中に、以下の課題について6回の電子ディベートと

1回の電子レポート&ホームページ掲載を実施した。



 (1) 中華航空機事故におけるソフトウェア開発者の責任の有無

 (2) DVDに関して,意図的に地域(米国,欧州,日本)ごとに異なる仕様を設定する

     ことの是非

 (3) エンドユーザ主導のソフトウェア開発の実現可能性

 (4) 日経コンピュータ97.4.14「特集:実録 巨大システム全面刷新」の成功要因を

     1つだけあげよ.それはユーザ側/メーカ側のいずれの功績か

 (5) 最近のJava言語をめぐるサンとマイクロソフトの争いについて,「標準化」の

     視点から自分の意見を述べよ.

 (6) 履修登録システムの入力端末導入に関して,汎用端末の利用と専用端末の設置の

     いずれかを選択し、その選択理由ものべよ.

 (7) 西暦2000年問題について自分の意見を述べよ.



各課題について、簡単に概要を述べる。


■ 第1回:電子ディベート 



● 課題(1996.10.3)



「中華航空機事故におけるソフトウェア開発者の責任の有無」について述べよ.



[概要] 本事故の1つの原因は,自動操縦プログラムに関係している.副操縦士が

手動で操縦かんを操作中に,誤って「着陸やり直しモード」(自動操縦)を設定.

そのまま,手動で着陸するために操縦かんを押し続けたため,自動操縦装置は機首を

異常に上げてしまった.本ソフトウェアの開発者は,開発時に例外処理の1つとして,

手動操縦操作時の処理を組み込んで置くべきではなかったか.



● 結果



 ディベート後に,多数意見が「責任有り」(支持率61%)から「責任無し」

(支持率64%)に変化し、「責任無し」グループの勝ちとする。一般的な意見

としては,論理的には「責任無し」であるが,人命にかかわることなので心情的には

「責任有り」という印象でした.

  主な論点として、以下の項目をとりあげて、解説した。

 (a) 要求仕様書の通りに作れば責任はない?

 (b) 専門の知識の無いものは口出ししてはいけない?

 (c) システムテストはできるのか?

 (d) 余談:製造物責任法




■ 第2回:電子ディベート 



● 課題(1996.10.17)  



「DVDに関して,意図的に地域(米国,欧州,日本)ごとに異なる仕様を設定する

ことの是非」について述べよ.



[概要] DVD (Digital Video Disk) とそのプレーヤに地域仕様を導入する主な理由は

以下のようなものである(らしい).

 ・米国の映画産業界の経営戦略上,ある地域で売られたDVDを他の地域に持ち込ませ

  ない.(映画の封切りの時期が地域で異なるので,DVD販売時期も異なる)

 ・国ごとに異なる法律があり,ある地域で合法的なDVDが他の地域では非合法の場合

  がある.(例:アダルト向け)



● 結果

  ディベート開始前は「地域仕様:是」支持39名、「地域仕様:非」支持41名で

あったが、終了後は「地域仕様:非」が多数意見(支持率72%)となったので、

「地域仕様:非」グループの勝ちとする。議論としては互角だったように思われるが、

消費者の立場を代弁する「地域仕様:非」のグループの方が共感を得やすかった面が

ある。「地域仕様:非」の方にやや感情的な意見もあったが,消費者の心理状態や

日米問題にまで発展してなかなか面白かった.

  主な論点として、以下の項目をとりあげて、解説した。

 (a) 「地域仕様:是」の主な根拠(地域固有の文化の保護、各国独自の法律の尊重、

    知的所有権の尊重)

 (b) 「地域仕様:非」の主な根拠(海外と国内の区別は時代遅れ、産業保護より普及を

    優先、各人の倫理観に任せるべき)

 (c) ”鶏と卵”の論争?(市場の成長のためには,「消費者の増加」が先か「良い

    商品の開発」が先か)




■ 第3回:電子ディベート 



● 課題(1996.11.28)  



「エンドユーザ主導のソフトウェア開発の実現可能性」について述べよ.



[概要] かつて電話交換手が交換業務を行っていた時代には,電話の需要が増えるに

つれて交換手が不足し,電話の普及が妨げられるという危惧があった.”1億総交換

手”化と皮肉られた時期である.この問題はその後の交換機の自動化によって解決

した.自動車についても専門職としての運転手だけが運転していた時代には,自動車が

増えるにつれて運転手が不足し,自動車の普及が妨げられるという危惧があった.この

問題は”マイカー時代”の到来とともにエンドユーザが自ら運転することで解決した.

 そしてコンピュータの世界では,80年代にプログラマの不足から”1億総プログラマ

化”の危惧が生じた.電話や自動車の場合と異なり,コンピュータの利用には必ず

エンドユーザの利用目的にあったソフトウェアが必要であり,このソフトウェアを

誰が作るかという問題がある.



● 結果



    ディベート開始前は「EU開発は可」支持47名、「EU開発は不可」支持43名で

あったが、終了後は「EU開発は不可」が少数意見(支持率48%)から多数意見

(支持率53%)となったので、「EU開発は不可」グループの優勢勝ちとする。今回は

もともと課題に曖昧な部分があったが,部品、部品組み立て技術、エンドユーザ、

対象とする業務、などに関して興味深い考察があった.

  主な論点として、以下の項目をとりあげて、解説した。

 (a) 「EU開発は可」の主な根拠(部品化、既にゲームソフトを作れるソフトあり、

   学習は可能)

 (b) 「EU開発は不可」の主な根拠(センスと知識が必要、業務は多様、組み立て技術が

    必要、必要な部品をすべては提供不可)

 (c) ”10年後”の論争?




■ 第4回:電子ディベート 



● 課題(1997.4.30)



  日経コンピュータ97.4.14「特集:実録 巨大システム全面刷新」(pp.78-89)

を読んで,成功要因を1つだけあげよ.それはユーザ側/メーカ側のいずれの功績か.



[概要] 完成が危ぶまれた大規模開発が今年(1997年)3月、期限通りに完成した。

それは、クレジット大手のU社が取り組んだ基幹システム全面刷新プロジェクトで

あり、投資額は500億円、開発量はCOBOL換算で540万ステップであった。U社は

当初、自社主導で開発を始めたが、途中でコンピュータメーカのI社とSI(システム

インテグレーション)契約を結んだ。いろいろな困難な問題が発生したが最終的には

うまくいった。



● 結果

  ディベートにより「メーカ側」の得票率が9.2%から17.1%に増加したので、

「メーカ側」グループの善戦という結論。元々の記事がユーザ側の視点で記述されて

いたため、最初のレポートでは「ユーザ側」支持者が圧倒的に多いという結果だった。

ディベートによって「メーカ側」がどの程度巻き返すかに関心があったが、思ったほど

は増えなかった。情報科学科の学生は将来「メーカ側」になる可能性が高いので、心情

的には「メーカ側」支持者が多いと推測していたが、あまり関係なかった。

  主な論点として、以下の項目をとりあげて、解説した。

 (a) 大規模ソフトウェア開発の現状

 (b) ユーザとメーカの役割分担

 (c) ツールの現状




■ 第5回:電子ディベート 



● 課題(1997.10.29)



 最近のJava言語をめぐるサンとマイクロソフトの争いについて,「標準化」の視点

から自分の意見を述べよ.



[概要] 米Sun Microsystems社は,Javaのライセンス契約不履行,商標侵害などで

米Microsoft社を連邦地方裁判所に訴えた。そして、その起訴状と契約内容を公開した。

それに対して、MicrosoftはSunがMicrosoftを提訴した件に関連して,Sun が契約に

違反したとして逆提訴した。合わせて,Sunの訴状についての反論を地方裁判所に提出

したことを発表し,反論内容も公開した。Microsoftは全面対決の構えである。Sunと

Microsoftの争いは泥沼化しつつある。 



[資料]日経BP社が提供するホームページ(http://www2.nikkeibp.co.jp/Java/)の

記事を参考にすること.独自に関連資料を引用してもよい.



● 結果



  最初のレポートでは、「サン支持」28名、「マイクロソフト支持」14名で、

態度保留者が30名(全体の40%)いた。ディベート結果は、単純な投票とみると

「サン支持」グループの得票率71%で圧倒的勝利だが、当初のサン支持の比率67%

と比べると4%アップの程度なので引き分けと見ることもできる。サン支持理由の中

には、マイクロソフトがトップシェアを背景に強引なやり方をしているというやや

感情的な反発も多く見られた.ディベータの議論の中で独自の資料調査に基づくものが

少なかったのがやや残念だった.

  主な論点として、以下の項目をとりあげて、解説した。

 (a) 標準化の視点

 (b) 契約遵守

 (c) 技術力

 (d) 標準化のジレンマ




■ 第6回:電子ディベート 



● 課題(98.5.27)

                                       

  履修登録システムのユーザインタフェース仕様(要求仕様の一部)と関係が深い

入力端末に関して,以下の2案の利点,欠点を考慮して,いずれかを選択し、その

理由ものべよ.

 <A案>汎用端末(パソコン・ワークステーション)の利用.

 <B案>専用端末の設置.



● 結果



  最初のレポートでは「汎用端末」支持62名、「専用端末」支持17名だった。

ディベート結果は、単純な投票とみるとディベータ14名を除いて汎用端末派の得票率

が90%(43/48)で圧倒的勝利となる。一方、投票前の比率に偏りがあるので,投票前

の投票者の比率をディベータ7名ずつ差し引いて計算すると,汎用端末派の得票率は

85%(55/65)であり、投票後に5%アップの程度なので優勢勝ちの程度ともいえる。

議論としては互角だったように思われる.

 支持理由は、汎用端末派ではコスト(24名)、混雑回避(11名)、設置場所問題

(4名)、その他(4名)、専用端末派では、操作性(4名)、安全性(1名)という

分布だった.受講生はエンドユーザの立場で検討すると予想していたので,コストへの

関心が高かったのはやや意外でした.

  主な論点として、以下の項目をとりあげて、解説した。

 (a) コスト vs.  操作性

 (b) 利便性 vs.  安全性




■ 第7回:電子レポート & ホームページ掲載



● 課題(98.11.25)



 西暦2000年問題について自分の意見を述べよ.



[配布資料]朝日新聞朝刊(98.10.17)の4面記事「一からわかる2000年問題」



[提出方法]タイトル、要旨(3行以内)、本文(20行以内)、参考文献を含む

レポートを電子メールで提出。



● 結果



   全体にしっかりした意見が述べられたレポートが多かった。このテーマについても

電子ディベートをやりたかったが、時間の都合で断念した。評価結果は、 A(特に

優れているもの)10件、B(一応、現状調査あるいは自分の意見のあるもの)

47件、C(感想レベルのもの)16件であった。内容は以下の項目に分けてホーム

ページに掲載した。評価結果については、Aレベルの10件についてのみ、タイトル、

要旨、内容(現状調査、問題の明確化、自分の意見)、参考文献についてコメントした

ものを公表した。

 (1) まとめ

 (2) タイトル一覧

 (3) 参考文献一覧

 (4) 要旨一覧

 (5) ベスト10とコメント

 (6) レポート一覧(全メールの公開)

  レポートの書き方についても注意した。タイトルについては、内容を表現していない

「西暦2000年問題について」の類いが20件以上あった。要旨については、「。。。に

ついて書いています」という目次的なものが多かった。参考文献については、延べ

57件で、そのうちインターネットのホームページが39件あった。

  主な論点として、以下の項目をとりあげて、解説した。

 (a) 技術的課題:ソフトウェアの保守技術

 (b) 社会的課題:システムの品質保証

 (c) 歴史的課題:プログラミングパラダイム




(6)実験のまとめ(良い点、悪い点、今後の予定、残された課題等)



  実験授業(電子ディベート)に関するアンケートに対する学生の回答の主な内容は

以下のようなものだった。



<学生の評価>

 ・新鮮で面白い。(ほぼ全員)

 ・いろいろな意見がわかって面白かった.(大多数)

 ・普段はわからない同じ学科の人の考えを知ることができた。

 ・「朝までテレビ」みたいで楽しかった。

 ・話の苦手な人も意見がいいやすい.

 ・インターネットに慣れることができた。

 ・もっと回数を増やしたらよい.



<学生からの要望>

 ・投稿してから掲示されるまでの時間(早くても30分位)が長すぎる.(多数)

 ・反論までに時間差があり、リアルタイム性に欠ける。これでディベート?

 ・ニュースグループ(掲示板)よりもメーリングリストの方がよい.

  (上記の問題解決と購読率向上)

 ・情報処理教室が空いていない.

 ・投稿件数が多くて、まとめて見ると読むのが大変

 ・意見をまとめる司会者がいたほうがいい.

 ・教員も参加すべきである。

 ・外部のシステムエンジニアや他学科の人の意見も聞きたい

 ・発言者が固定化する傾向がある。

 ・代表選手は指名ではなく、希望者にすべきである。

 ・意見が少ない.期間を長くすべき.

 ・自分の意見を述べた人が少ない.

 ・締切近くの投稿が多く,再反論の時間がなかった.



(7)感想



  最後に担当教員(筆者)の感想ですが、面白いという学生側の感想が多く、ほぼ

全員が前向きの評価をしているので、おおむね成功したと思います.

  私の予想外の効果としては,多数の学生が「同じ学科の他の人のいろいろな意見が

聞けてよかった」という感想を述べていることです.現在の教室での授業では教員が

一方的に講義する形式が多いため、3年になっても学生同士は意外と知り合いになって

いないことがわかりました。1,2年の早い段階で仲間意識を持たせられる授業が

必要と考えます.

  一方、問題点として、意見の投稿から掲載までの時間が30分くらいかかるため、

臨場感に欠ける面がある。今後はメーリングリスト方式も試してみたいと思います。



以上


バックホーム