********************************************************************** セッションS1-c 分科会１ テーマ：実践！なぜなぜ分析 コーディネータ: 佐藤洋介(デンソー) 日時：8/30 20:30-22:30 参加人数：約50人 ********************************************************************** 要旨： 不具合を出していまったときの分析方法や対策方法について 演習を通して学ぶ。 内容： ・参加者を９つの班に分ける ・参加者個人でマインドマップを書く。 ・書いたマインドマップを使用して自己紹介を行い。班のメンバーの価値観を知る。 ・スライドによる講義 ・演習課題の提示。班内で議論して原因と対策をまとめる。 ・グループごとに発表。講評。 内容（時系列） S:不具合を出さないようにするのがよいが、それでも出てしまった不具合をどのように 分析するのか？ 20:35 自己紹介の後、班分けと席移動 20:42 マインドマップによる分析。マインドマップを個人で書く。 (スライドの内容） マインドマップとは -英国のトニー・ブザンが開発した絵と言葉によって思考プロセスを 書き溜めていく発想法（ノート術） -通常の箇条書きのメモと違って、ビジュアルに、かつ印象的にメモを 取ることができる。 活用法 -要求獲得、ユースケース導出 -議事録、メモ -プレゼンテーション骨子 -自己紹介 20:47 マインドマップを行う意義について説明。チームメイトがどのような価値観や 課題意識を持っているのか わかっていないと意見がぶつかるから。 20:50 班内でマインドマップの見せ合い。自己紹介タイム。自分のやっていることや 業務などの情報の交換。 21:05 班内での自己紹介終了。スライドによる説明開始。 21:25 演習「深堀してみよう！②｜を班内で深堀してスライドのようにやる。 --深堀してみよう！②の内容-- 【発生問題】J社が３月１８日のダイヤ改正から東海道新幹線の東京ー新大阪間に 導入した新型の自動列車制御装置 （デジタルATC）にプログラムミスがあり、列車の非常停止や遅れなどのトラブルが １９件、相次いだ。 【原因】デジタルATCの車両側コンピュータには一気に大量の情報を処理する想定の プログラム設定がなされておらず、処理能力が追いつかずに列車を非常停止 させてしまうケースがある。 １問目はSSEST1,2でやった。３問目はソフトの知識が必要なため止め。 班内で分析して発表。最終的に参加者全員の分析としてまとめる。 S:質問がある場合は講師がJR東海の社員になりきって質問に答える。 どんどん質問してほしいとのこと。 S:問題は２つある -１つめプログラムミスがある。 -２つめ処理能力が追いつかないこと。 22:05 ビールの補充 22:08 発表タイム （以下は発言の要旨、Tはチームの発表者。Sは講師。Pは質問者） S:どこに何故をしたのか？原因と対策を発表してください。 １つめのチーム T1：なぜ処理能力が追いつかなかったのか？ハードウェアを想定できるプロセスが なかった。作り込みがなかった。 なぜ発見できなかったのか？CPUやハードウェアの能力を作り込みの段階でレビューする。 テストではスタックの容量などをチェックする。 S：人が確実に働くための動作の視点を織り込むといい。 ２つめのチーム T2：処理能力が追いつかず。なぜ想定のプログラムがなかったのか？ テストが不十分ではないのか？テスト設計するときに要求の分析にモレがあったと考える。 なぜ要求のモレがあったのか？J社の社員にきいたところ性能的な要求を出す文化が なかったようなので、がんばってほしい。 S:エンタープライズ系の人が入ってレベルが下がる。企業間インターフェースで決めて おくことが必要。 そもそも運用はどのようになっていたのか深堀するとよい。 ３つめのチーム T3：プログラム設定はロジックではなくパラメータである。パラメータを正しく 設定したら起きなかった。 流出原因はN社から受けとってなぜJ社は検証しなかったのか？ダイヤ改正による テストデータをなぜ作ることができなかったのか。対策は議論が及ばなかった。 S:対策は徹夜部屋で。なぜテスト項目がなかったということと企業間インタフェース できめておくということは同値である。 フェイスtoフェイスでの企業間のあれは複雑性が増したことによって崩れてきてる。 論理的手法には形式的手法は効果的であると考える。 P:最終顧客に対する環境を理解してテスト項目があれば企業間インターフェースが なくてもバグは出ないのではないのか。 S:企業の付加価値として。日本の強みは阿吽の呼吸やみんなでがんばろう！ という感じである。 以降インターフェース議論。 S:付加価値をつけないと価格競争に巻き込まれる。 ４つめのチーム T4：２あつある。１つめはなぜ処理能力に対するテストがなかったのか。 なぜ処理能力が低いというのを想定しなかったのか。 なぜデータをJ社はN社に渡さなかったのか。わたさなかったのはデータの重要性を 理解していなかった。 トラブルが１９件。なぜ最初のトラブルの時点でもどさなかったのか。 ここまで放置していたのか？ トラブルはよくあるものどと思っていた。システムに対する理解が足りなかった。 なぜシステムに対する理解が足らなかったのか。結論として正常動作異常動作を徹底する。 S:システムの実環境はいくらやっても足りない。トライ＆エラーが多い。 実環境は重要である。設備としての観点。受注側の理解不足。 システムとして立ちいちや、品質特性をどのように使っていくか？ ５つめのチーム T5：19件続いたことを不具合と定義。処理が足らなかった。なぜ足りなかったのか。 処理能力の想定がなかった。 なぜ処理能力の想定がなかったのか。実際のデータではとらえることがあったのか、 そういったルールがあったのか？ 改善として処理能力を使用に盛り込む。実際のダイヤのデータを公開する。 付加テストを甘く見積もっていた。 実環境も考えてテストする。なぜ多く続いたのかは時間が足りずまとめ切れなかった。 S:キーワード３つ。実データ、否定（これってほんとにただしいのと疑うこと）。 お客様からの要求を斜めにみて否定してみる。 企業間でもななめにみて否定してみて確かめてみる。サプライヤーとOEMの関係を 切りすぎた。報告するタイミングが重要。 ほうれんそう。 ６つめのチーム T6：大量の情報を処理することの想定外が問題。開発側が新しいダイヤのデータを 知らなかった。 ２番目のなぜは非機能要求をおろそかにしていた。開発側が納期に重視するあまり、 非機能要求をおろそかにした。 J社はダイヤ改正と新システム導入を一緒にしたのが問題。コストを重視した結果では ないのか。対策として開発側は非機能要件をもっと洗い出すべきだった。 S:納期は重要で。納期が足りないときのリスクを顧客にどう説明するのか？ダイヤと 新システムの導入を一緒にしたのは問題。 リスクの評価。作る側に実データを渡さないとダメ。ここも非常に重要なポイント。 ７つめのチーム T7：ひとつめのなぜ。処理能力の問題。なぜ処理能力が足りなかったのか。 プログラムのミスである。 なぜテストを通過してしまったのか。テストが不十分であった。ちゃんとした ダイヤのデータでテストしなかった。 なぜ実際のデータでテストしなかったのか。時間が足りなかった。テスト工程が 圧迫されて十分な時間がとれなかった。 対策としてスケジュール管理の強化。実際のダイヤに即したデータでテストの実施。 S:実際のデータと実環境が重要。ソフト屋は知識屋であった。大規模複雑化によって ソフト屋がカバーできなくなったのではないのか。 ８つめのチーム T8：結論がでなかった。ポジションを明確にした。開発に近い方で問題の分析。 処理能力不足はなぜ。 作り込みができなかった。設計仕様に非機能要件がなかった。抜けてた理由として 性能項目がなかった。 暗黙の知識であってドキュメントができない。しかも量が多量なので暗黙の知識を どうように扱うか？ S:暗黙の知識は組織のポリシーである。アーキテクチャに効いてくる。経営視点から どういった品質特性がいいのか。 ９つめのチーム T9：プログラムミスによって19件。なぜ19件もおきたのか。データの見積もりを しなかった。なぜ見積もりしなかったのか。 なぜ非機能要件やチェックがないのか。非機能要件がすっぽりぬけていた。 対策として教育によって非機能要件として盛り込む。仕様として限界値が抜けていた。 なぜ抜けていたのか。レビューがないのではないのか。 なぜレビューがないのか。ルールがなかった。チェックしていく文化を創っていく。 S;教育の観点に注視したのはいいこと。しかし、徹底することは難しい。 限界値チェックがないところが多い。 22:51 まとめのスライド説明 S:SSESTやSWESTの目的は草の根のネットワークをつくることにある。名刺交換してない ひとは名刺交換して、（名刺交換）された方は徹夜部屋へ。