Embed Size (px)
Citation preview
2018年10月31日
永松 陽明
経営情報論II
第6回システム構築とテストの重要性
横浜市立大学2018年度後期
2
今日の目次
1. システム構築のねらいと実際2. テストの重要性3. 製品事故とリスクマネジメント
3
システムの構築における目次
1. 出張したら・・・2. どこを改善すべきだろうか？3. システムの設計技法4. プロトタイピングアプローチ5. 作るだけが良いアプローチなのか？6. 主な参考文献7. 課題
4
1. 出張したら・・・
【事例】新入社員の白鳥君は研修のため、愛知の工場に一カ月間実習に行ってきました。戻ってきて最初に行ったのは、愛知の工場への往復の旅費を清算です。下記のフローで出張精算が処理されました。
精算書（word）を作成・印刷 白鳥君
精算書を上司へ提出 白鳥君
内容確認・承認 上 司
Web上で振込処理 経理担当者
精算書を経理部へ提出 上 司
5
2. どこを改善すべきだろうか？①
【事例】新入社員の白鳥君は研修のため、愛知の工場に一カ月間実習に行ってきました。戻ってきて最初に行ったのは、愛知の工場への往復の旅費を清算です。下記のフローで出張精算が処理されました。
精算書（word）を作成・印刷 白鳥君
精算書を上司へ提出 白鳥君
内容確認・承認 上 司
Web上で振込処理 経理担当者
精算書を経理部へ提出 上 司
改善すべき点はあるだろうか？
6
2. どこを改善すべきだろうか？②
■改善すべき点
情報の伝達が、デジタル（word）→アナログ（紙）→デジタル（振込処理）となっている点が非効率。すべての情報伝達をデジタル上で行えば、データの転記漏れなどもなくなり、処理が高速化できると予想。
全てデジタルで情報をやり取りできる「システム」が必要
7
2. どこを改善すべきだろうか？④
以上の事例のように、システムは業務改善や経営問題解決のために構築されます。構築のためには、まず現状を把握し、あるべき姿にする改善案を実施していきます。
時間
レベル
現状
あるべき姿
改善案の実施
8
3. システムの設計技法①
システムを設計する技法の代表例は、システム開発ライフサイクル（SDLC: System Development Life Cycle）。
システム計画
システム分析
システム設計
システム導入・運用
システム保守・管理
出典：宮川編（1994）
9
3. システムの設計技法③
SDLCでは、複雑で多様な規模の開発を進めるために、様々な開発ツールがある。
出典：宮川編（1994）
システム文書化 使われるシステムの開発ツール
システム構成要素とフロー システム・フローチャート、プレゼンテーション・チャート、データ・フロー・ダイヤグラム、文脈図、システム構成要素マトリックス
ユーザ・インターフェース インプット・アウトプットフォームとスクリーン、対話型フロー・ダイアグラム
データの特徴と関係 データ辞書、エンティティ関連図、ファイル・レイアウト・フォーム、格子図
プログラマ支援ツール デシジョン・トリ―とテーブル、構造チャート、疑似コード、プログラム・フローチャート
10
4. プロトタイピングアプローチ①
実際の現場では、ユーザとシステムエンジニア（またはプログラマ）は齟齬のないようにシステム開発を進めたいと思っている。
そのため、システムエンジニアは試作を短い期間で作り、それを基にユーザからニーズを聞き出す「プロトタイピングアプローチ」も採用されている。
11
4. プロトタイピングアプローチ②
出典：宮川編（1994）
プロトタイピングの典型的なステップは下記です。
基本的情報要件の識別
最初のプロトタイプ設計
ユーザの利用・評価（情報要件の精緻化）
改善、機能増幅
ユーザの利用・評価
ユーザ、設計者満足か？
（利用）稼 働
Yes
No
12
5. 作るだけが良いアプローチなのか？①
これまでのケースは、システム導入企業の業務プロセスに合わせてシステムを構築するものであった。
一からシステムを作るのではなく、既成のシステム（ソフト）を導入した方が導入費用が安い。しかし、社内の反発が大きい。なぜだろうか？
13
6. 主な参考文献
（1） 高橋三雄、『ビジネス情報技術』日科技連出版社、1996年。（2） 宮川公男編著、『経営情報システム』中央経済社、1994年。（3） 芦屋広太編著、『情報処理教科書ITパスポート』翔泳社、
2011年。
14
今日の目次
1. システム構築のねらいと実際2. テストの重要性3. 製品事故とリスクマネジメント
15
テストの重要性の目次
1. 試験の合格判定のプログラムミス2. システム開発のフロー3. なぜミスは出るのか？4. 主な参考文献5. 課題
16
1.試験の合格判定のプログラムミス
平成19（2007）年12月末に判明した高卒認定試験では、世界史
Ａで認定ミスが発生。1901名に影響を与えた。
■高校卒業程度認定試験のプログラムミス
17
2. システム開発のフロー
プログラムミスを考える前に、システム開発のフローを確認
■システム開発のフロー
要件定義
外部設計（システム方式設計）
内部設計（ソフトウェア方式設計・ソフトウェア詳細設計）
プログラム実装 単体テスト
結合テスト
システムテスト
運用テスト
18
2.1要件定義と設計の概要
プログラムミスを考える前に、システム開発のフローを確認
■システム開発のフロー
要件定義
外部設計（システム方式設計）
内部設計（ソフトウェア方式設計・ソフトウェア詳細設計）
プログラム実装
19
2.2 テストの概要
プログラムミスを考える前に、システム開発のフローを確認
■システム開発のフロー
単体テスト
結合テスト
システムテスト
運用テスト
20
3. なぜプログラムミスが起こるのだろうか？
テストも多く行われているのになぜミス（バグ）がのこるのだろうか？
システムやソフトが大規模化しているため、テストではバグを取り切れない・・・→見逃してしまう・・・
プログラムをテストするためのもの（PCL: Program
Check List）が網羅的ではない・・・
21
3. なぜプログラムミスが起こるのだろうか？
バグを取り切れない時に、どうすればプログラムのミスは少なくなっていくのだろうか？
設計の段階で、バグを作り込ませない。
バグを作りにくい仕事の仕方（業務プロセス）にすれば減少する。
第5回に行った「業務プロセス」の授業につながる
22
3. 中華料理店がやっていること
中華料理店がやっていること
①お店の運営※食材を仕入れる→注文を受ける→料理を作る→経費を計算する/支払う→※
②料理をつくるチンジャオロースをつくるラーメンをつくる・・・※それぞれ工程は異なる
いろいろな階層でいろいろなこと（業務プロセス）をしている
第5回授業資料
23
4. 業務プロセスの実際 （1）
生産計画業務プロセス①
出所：筒井（2006）
第5回授業資料
24
4. 業務プロセスの実際 （1）
生産計画業務プロセス②
出所：筒井（2006）
第5回授業資料
25
6. よくないプロセス （1）
■中国における原料へのメラミン混入事件 （2008年）
牧場園区（養殖小区）
搾乳ステーション
急増する需要に対応するため
「水」と「メラミン」を添加し、生乳水増し
出所：新川・岡田（2012）、長命（2012）をもとに作成
メーカー直営農場
小規模酪農家など
生乳
乳牛
乳牛
乳牛
乳製品メーカー
汚染粉ミルク水
メラミン
＋
消費者
汚染した粉ミルクの使用により乳幼児死亡
図 メラミン混入事件における汚染された乳製品の流れ
品質管理機能せず
第5回授業資料
26
6. よくないプロセス （3）
ミスなどヒューマンエラーを起こさせる業務プロセスはよくないプロセスである。
第5回授業資料
27
6. よくないプロセス （4）
出所：下田・久邇・永松他（2010）
品質不良の原因を見ると、ヒューマンエラーである「仕組み不備（マニュアル不備）→知らない」や「実行不徹底→やらない」が85%。
図 製品不良発生事例の分析結果
n = 99
第5回授業資料
28
3. なぜプログラムミスが起こるのだろうか？
ではバグを作りにくい業務プロセスとは？
バグを代表とする不良の要因は、ヒューマンエラーが起因。
ヒューマンエラーを防ぐ業務プロセスを導入すれば、改善していく。
29
3.1 ヒューマンエラーの分類と対策
ヒューマンエラーは4つに分類でき、それぞれの対策は以下の表に整理
No. ヒューマンエラーの分類 その対策
1知らない（知識の不足）
標準（ルール）を作る
2できない（スキルの不足）
繰り返し教える（教育訓練の実施）
3やらない（意図的な不遵守）
具体的な事例などを用いてやる必要性を伝える（動機づけ）
4うっかり（意図しないエラー）
誰がやっても間違えないような、間違えたことがわかるような工夫をする（エラープルーフ化）
出典：永松、谷口、中條（2012）
30
3.2 設計時のミス減少への対策
多くの企業は、過去にミス起因の失敗をしている。その失敗を集め、活用
No. ミスの活用例 その内容
1 失敗事例集の作成 失敗の事例を集め、教育資料に利用→「知らない」対策
2過去トラブルリストの作成
失敗事例を整理し、要点をチェックリスト化し、設計途中などで確認→「知らない」「やらない」「うっかり」対策
3 設計ルール化 守らなくてはならないルールに設定→「知らない」「やらない」「うっかり」対策
上記の実践などを行っている企業のソフトウェア品質は高いと推測できる
31
5. 主な参考文献
1. 神奈川県情報サービス産業協会編、『ＳＥハンドブック（第7版）』、神奈川県情報サービス産業協会（2011）。
2. 芦屋広太編著、『ＩＴパスポート2012年版』、翔泳社（2011）。3. 中條武志、『人に起因するトラブル・事故の未然防止とRCA』、日本規格協会（2010）。
4. 永松陽明他、「業務プロセスにおける不具合情報の有効活用の研究」、日本品質管理学会『品質』、Vol. 43, No. 1, （2013）。
32
今日の目次
1. システム構築のねらいと実際2. テストの重要性3. 製品事故とリスクマネジメント
33
製品事故・リスクマネジメントの目次
1. 製品事故の低減
2. リスクマネジメントの重要性
3. 参考文献
34
1.1 最近の製品事故の多発
①最近の製品事故例•リチウムイオン電池からの出火
•ガス瞬間湯沸かし器欠陥による一酸化炭素（CO）中毒事故の多発
•石油温風機の欠陥による一酸化炭素（CO）中毒事故の多発
•シュレッダの事故
•30年以上前に製造された扇風機からの出火
•食品の偽装問題
②いま日本で何が起こっているのか?
（畑村洋太郎,『技術の創造と設計』岩波書店（2006年））
•マニュアル化の弊害
•隙間組織の発生
•見ない・考えない・歩かない
•形骸化した管理
35
1.2 ハインリッヒの法則
1件の重大事故の背景に、29件の軽傷の事故と300件の「ヒヤリ」「ハッと」する体験があるという労災事故に関する法則。1930年代に米国のハインリッヒ氏が発表した。
米国の保険会社に勤務していた安全技師のハーバード・ウイリアム・ハインリッヒ氏は、1930年代に発表した論文の中で、重傷以上の災害が1件起きる背景には、軽傷を伴う災害が29件起きており、さらには危うく惨事になるような「ヒヤリ」「ハッと」するような出来事が300件あるという「1：29：300の法則」を見いだした。
36
1.3 失敗の種類と共有
失敗について『技術の創造と設計』では以下のようにまとめる
•失敗には「許される失敗」と「許されない失敗」がある
「許される失敗」とは、 「創造」するために必然的に起こる失敗
「許されない失敗」は、同じ過ちを何度も繰り返す失敗
•他の人々に失敗をさせないためには、知識として共有させなければならない
•失敗は体験、実感しないと受け入れることが出来ない
•失敗を構造化することによって、失敗は共有できる
出典：畑村洋太郎,『技術の創造と設計』岩波書店（2006年）
37
1.4 失敗を活かす（1）
①タコマ橋
1940年、米国ワシントン州のタコマ橋が崩落。風が作り出す空気の渦によって橋が揺れ動き始め、また橋が揺れ動くことで新たな渦が発生し、その渦が・・・という「自励振動」がおき、それによるねじれに耐え切れなく崩壊。
そして、橋桁のねじれ剛性が高ければ、自励振動が小さく抑えられることがわかり、そこで出てきたのが箱構造桁である。（タコマ橋は板構造桁）
起こしてしまった失敗をそのままにしておけば、ただの失敗である
技術を進歩させた3大失敗（すべての失敗は情報発信された）
38
1.5 失敗を活かす（2）
②戦時標準船の破壊第二次世界大戦が始まるとアメリカは兵員と武器をヨーロッパに大量に輸送するための「戦時標準船」を製作。建造期間短縮のため、鉄板をリベットでとめる方法から溶接に切り替えた。真冬の大西洋を通ると、下図のように戦時標準船は沈んだり欠けたりした。理由は、①鉄は0度の低温になると強靭さがなくなり割れる、②溶接をする際に空気中にあった水素が鉄に溶け込み、溶接部分がもろくなる、③大きなハッチの角が鋭く曲がっていたため応力集中が起こることから。
出典：畑村洋太郎,『技術の創造と設計』岩波書店（2006年）
39
1.9 失敗の必然性
•局所最適が全体最悪をもたらす
組織が拡大するとひとりの人間が理解できる範囲が狭まる。重大事故は、ひとりの人間が一部の事しか見えていないのに、最適解や最大効率を求める。その判断が場合によって重大な結果を及ぼす。
例）JCO臨界事故
放射性物質の処理プロセスでは、少量ずつしか処理してはいけなかった（臨界がおき核分裂連鎖反応が起きるから）。しかし、コスト低減と納期短縮のために大量に処理してしまった。
•時間の経過とともに失敗確率が増大する
時間が経過すると、事故が起きた事柄について無関心になり、注意不足が起きる（一度起きた事故が再び起こる周期は30年といわれている）。
出典：畑村洋太郎,『技術の創造と設計』岩波書店（2006年）
40
1.10 失敗知識の伝達
•失敗情報が孤立している
多くの組織は失敗知識を共有化するために「事故事例集」などを作成。しかし、多くの場合、失敗すると上司に叱られるため、失敗を黙っている。そのためどこにも伝わらず 孤立する。
•失敗情報をわかりやすく表現する必要がある
失敗が表出できても、誰でも理解できる言葉で表現する、絵にする、知りたいと思うような構造にする必要がある。 『技術の創造と設計』では、この一連の必要なことを「失敗情報の知識化」と呼んでいる。
出典：畑村洋太郎,『技術の創造と設計』岩波書店（2006年）
41
1.11 JST失敗データベース
失敗情報をわかりやすく表現したデータベースとして、JST
（科学技術振興機構）による「失敗知識データベース」が整備されていた。畑村教授がリーダとして構築。
出典：JST HP
http://www.sozogaku.com/fkd/
42
1.12 失敗を未然に防ぐ方法
① FTA（Fault Tree Analysis）
②FMEA（Failure Model and Effect Analysis）
③DRBFM（Design Review Based Failure Model）
④ ISO9001
