********************************************************************** セッションS1-c 分科会１テーマ：実践！なぜなぜ分析コーディネータ: 佐藤洋介(デンソー) 日時：8/30 20:30-22:30 参加人数：約50人 ********************************************************************** S氏：普通の分科会では不具合を作りこまないように抑えることを議論するが、今回は流出してしまった不具合をどのように扱うかについて議論していきます。グループワークですので、まずチーム分けをします。 ------------------ 20:35 座っていた席によるグループワーク分け(5人ずつくらい9チームに) ------------------ S氏：まず自己紹介をします。昔は携帯電話のコンテンツを作っていました。現在は車載のソフトウェアプラットフォームの開発に携わっています。ソフトウェアプラットフォームとは各社共通のデバイス部分にあたります。では、皆さんにマインドマップを使って、本セミナーに関する要求を書いてもらいます。(20:40〜20:48) −考え込まないで、思いつくままに書いていい。 −これからのグループワークに向けて、チームのメンバーの価値観を理解し、衝突を防ぐための作業。・チームのメンバーとマインドマップを使って情報交換・自己紹介タイム(20:48〜21:00) -自己紹介が終わったら発表者１名と議事録を取る人を準備。 -新入社員歓迎会などでやると盛り上がるので是非どうぞ！！ -------------------------- マインドマップとは・英国のトニー・ブザンが開発した絵と言葉によって思考プロセスを書きとめていく発想法。・通常の箇条書きのメモと違って、ビジュアルにかつ印象的にメモをとることができる。活用法・要求獲得・ユースケース導出・議事録、メモ・プレゼンテーション骨子作成・自己紹介 ------------------------------------ S氏：ここまでがオリエンテーションです。品質の作りこみ技術の重要性について品質保証の現状は −異なるドメイン間での制御が増えていて大規模・複雑化 −製品のサイクルが短くなっている．→テストが甘くなっている。　　今まではテストによって不具合発見してきた。　　これからは分析・設計での不具合発見をしなければいけない。・ハードウェアと共同開発。メカに重点がいってしまい、ソフトがおろそかになりがちである。後工程で不具合が見つかるほど重大化する。不具合の多くはコミュニケーション不足によって起こっている。・不具合を出さないためには　　・ドキュメンテーション -分析・設計の過程をドキュメントとして適切に表現する技術 -分析・設計過程をドキュメントを書かないとソースコードの情報しか残らない　　　　-ドキュメントとしてどのように成果物を残すかが重要になってくる -わかりやすさが一番重要！！教育コストの無駄をはぶく　　・レビュー不具合を含んだ成果部を作ることを未然に防止するために内容を確認しあうこと。ウォークスルーとインスペクションの２種類ある。　　　　・ウォークスルー -成果物の製作所が自主的に行うレビュー -仲間内の卓上でバックのようなイメージ -公式な記録をとらず、フランクな形で内容の検討 -開発者同士で行う・インスペクション -不具合の発見のみを目的とした、責任者が主催し会議形式 -調整役による運営、参加者の役割を明確化、不具合データの収集。 -工程移行判定時など、プロセス内での組織的に行われる。 -責任者が同席ウォークスルーとインスペクションの使い分けが重要になり、間違えると自己満足に終わってしまう。・流出不具合のフィードバック　　・それでも不具合がでてしまう。不具合の原因を深堀し、再発防止をプロセスフィードバックさせる必要がある。不具合の原因は、作りこみ原因、流出原因の２つの側面から分析する。　　-作りこみ原因：なぜ不具合が混入したのか？　　-流出原因：なぜ不具合がテストを通過してしまったか？・なぜなぜ分析とは豊田生産方式の大野さんが提案している経験則からなぜを５回以上繰り返し本質的な原因を見つける方法。５回やれば真因にぶつかるといわれている。　　-本質的な原因を見つけ、再発防止策を打たなければならない。　　-表面的な原因に対する再発防止策を打っても、まったく見当違いなことをしているだけで、不具合が再発してしまう。今回は時間の都合上３回で、やってもらいますどうやって不掘るか？具体的事例をつかって考えましょう。 7月24日Ｊ社の不具合について。原因：外注の人が作業時の安全ロックピンを挿入したまま、出荷してしまう。対策：①作業指示書を改定し、安全ロックピンが抜けていることを確認するように記載。　　　②重要周知事項として、すべての整備関係者に周知。　　　③委託管理先の徹底。周知や徹底といっても具体的なものが見えてこない。周知や徹底という言葉が具体的に何をするのかというのを深堀してほしい。なぜ挿入されたままだったのか？（作りこみ原因） →作業完了時の確認漏れ→なぜ →作業指示書に記載がない→なぜ →重要周知事項に対する知識がなかった（真因）（流出原因） →担当者任せでクロスチェック体制がなかった→なぜ →委託業者のスキルを考慮せず、社員で行っていたときと同様の運用ルールをそのまま使用→なぜ →業務委託のルールがそもそもなかった（真因）対策：・既存業務の外注へ委託する場合の運用ルールの策定・就業前の人材育成システムの構築今回の演習：発生問題を最低なぜを３回まで深堀し、原因・対策を考える。配布資料のＪ社のトラブルから考えて見ましょう。トラブルの発生原因から深堀し、なぜを３回以上繰り返し、トラブルの真因を考えてください。プロセスとしてルール化できる対策にしてください。 -------------------------------------- 自習開始（21:20〜22:05） --------------------------------------- 【発生問題】Ｊ社のダイヤ改正から導入した新型の装置にプログラムミスがあり、列車の非常停止や遅れのトラブルが19件相次いだ。【原因】車両側の新型装置には一気に大量の情報を処理する想定のプログラム設定がなされておらず、処理能力が追いつかず列車を非常停止させてしまうケースがある。・チーム１処理能力が追いつかなかった　→なぜ→ ＨＷの能力が想定できるプロセスがない　→なぜ→ （作りこみ原因）作りこめてない　（真因）（流出原因）過負荷試験をしていない（真因）対策：作りこみの段階でのレビューをするべきスタックの使用量のテストなどのテストをするべき質問・コメント: Q：過負荷試験とは異常がでるまでか、それとも想定量の数倍というレベルで行うのか？ A：数倍のことを考えている。 Q：それでは不具合がでる限界がわからない。 S氏：人が確実に働くための対策がほしかったが、ＨＷとソフトと両方のコメントがあってよかった。・チーム２想定のプログラム設定がされていなかったか　→なぜ→ テストが不十分　→なぜ→ テスト設計で要求の漏れがあった　→なぜ→ J社によると性能的な要求を出す文化がなく外部からもらっていた（真因）対策： J社ががんばるべきコメント: S氏：会社間のインターフェースの部分が重要になってくる。組み込みはエンタープライズの参入により相対的にスキルレベルが低下している。企業間のインターフェースで決めておくことを決めておく。運用の部分を深掘るといい。・チーム３ロジックではなくパラメータ設定。パラメータがまちがっていた。　→なぜ→ （流出原因） N社からプログラムを受け取ったJ社が気づかなかった　→なぜ→ パラメータに関するテストが不十分。一時的な過負荷状態をテストデータとしてつくれない　→なぜ→ 議論はまだで時間終了コメント: S氏：視点が広くてよい。企業間のインターフェースが出てくる。今まで日本の企業は信用関係で成り立っていたが、大規模・複雑化してきたので見直したほうがいい。論理的な正しさに形式手法を入れると強力になっていくと思う。 Q1:最終顧客の状況を想定してテストをすればよいのではないか。そうすれば企業間インターフェースは必要ないのでは？ S氏:企業のプラスの付加価値というのはなにか？付加価値がインターフェースにならないか？ Q1:インターフェースを付加価値ではなく、想定テストを付加価値とすればよいのではないか S氏:ヨーロッパでは論理的なところで仕様を決めているが、日本ではそのまま移植はできない。ヨーロッパは法的な規制により日本製品の流入を規制しようとしているが、日本の強みは阿吽の呼吸・信頼関係。しかし信頼関係に依存しすぎるのも問題。 Q2:システム会社も最終顧客のニーズまで全部カバーできるのだろうか？目指すのはよいがどこまでできるのか？ S氏:そこが付加価値。言われたままの仕様では価格競争に巻き込まれていく。だから、シェアを守るためにも付加価値というのは重要になる。 Q2:で、どこまでできるのか？ S氏：それはそうですね。 Q3:企業間インターフェースの話が出ているが、企業内でも同様ではないのか？ S氏：そのとおりです。・チーム４処理能力のテストが行われなかったか　→なぜ→ 処理が多すぎる場合は想定しなかった　→なぜ→ J社がデータを公開していなかった　→なぜ→ N社とJ社が実際のデータの重要性の認識不足（真因）対策：なるべく実環境でテストを行う。運用面: トラブルが１９件起こった　→なぜ頻発を防げなかったのか　→なぜ→ バグとして正しく認識していなかった　→なぜ→ 監視している人がシステムに対する理解が足りなかった　→なぜ→ その人へのシステムの教育が足りなかった（真因）対策：正常動作、異常動作の教育を徹底する。コメント： S氏：システムの実環境のテストが重要である。組み込みはトライアンドエラーの部分が多いので、実環境でのテストは重要。システムの理解の話は受注側に足りない。受注側が周辺環境も把握すべき。システムとして理解して、頼まれたモジュールがどういう品質特性で作っていくかというのが重要になってくる。・チーム５トラブルの頻発　→なぜ→ 処理能力が追いつかなかった　→なぜ→ 要求仕様の想定不足　→なぜ→ ①実データの公開での性能目標が想定されていない ②規定するルールがなかった対策: 要求に対する仕様目標を定義する。実データのテストをする。運用側: トラブルが１９件もあったこと　→なぜ→ 報告手段がなかった　→なぜ→ 事故にはなってない　コメント： S氏：仕様を斜めにみることから発見できることもある。書いてあることがほんとに正しいとは限らない。お客様からの仕様を斜めにみることで両方ハッピーになれることもある。斜めにみることによって自分の味を出していく。企業間の責任関係を明確にしすぎている。報告のタイミングが重要。・チーム６大量のデータ処理を想定外としていた　→なぜ→ システム側が新しいダイヤをしらなかった　→なぜ→ 信頼性の部分の非機能要求を満たしていなかったのではないか　→なぜ→ 納期を守るため非機能要求をおろそかにしていた（真因）ダイヤの改正と新システムの導入が一緒　→なぜ→ リスクよりもコストを重要視した対策：システム側はユーザからの要求だけでなく、非機能要求の分析も必要。コメント： S氏：納期の問題。納期を守れないと品質特性のどこが失われるかを明確にすることができるのか？初期段階での品質目標が大事。リスクヘッジが重要。作るほうに実環境の情報を提供しないと、うまくいかない。・チーム７処理能力が追いつかない　→なぜ→ プログラムミスがあった　→なぜ→ ミスがテストを通った　→なぜ→ 実際のダイヤに即したテストが不十分　→なぜ→ 開発の時間が足りなかった。テスト工程が圧迫された　→なぜ→ 開発にかける時間が十分でなかった（真因）対策：スケジュール管理を十分におこなう。遅れが出た時点でなんらかの対策を行う。実際のダイヤに即したテストを行う。コメント： S氏：最近、こういう問題でシステムエンジニアリングが注目されている。今までソフトとシステムは分かれていたが、論理の世界という意味ではソフトとシステムは対して変わらない。それが大規模化・複雑化によってカバーしきれず問題化している。・チーム８問題点は正しいと仮定。改革的な立場という前提。処理能力がおいつかない　→なぜ→　作りこみがたりなかった　→なぜ→ 設計仕様が不十分。非機能要求が不十分　→なぜ→ 顧客からの情報が不十分　→なぜ→ 暗黙の知識となっている。（真因）暗黙の知識は量が大量で、ドキュメントにできないのではないか。ドキュメントにできないことをどうやって対策するのか？コメント： S氏：何をよりどころとして品質目標をあげるのか。ということで明日のセッションに続けてください。・チーム９（作りこみ原因）トラブルが続出　→なぜ→ 見積もりをしなかった　→なぜ→ 非機能要求のチェックがなかった　→なぜ→ 非機能要求の教育が足りなかった（真因）対策: 非機能要求の教育を徹底させる。（流出原因）テストを通過　→なぜ→ レビューがなかったのではないか　→なぜ→ レビューのルールがなかったのではないか　→なぜ→ 対策: レビューのルールを作り対策を行うコメント： S氏：教育という視点は良い。徹底というのは難しい。マイルストーンができるまで具体化すべき。制御屋さんに境界条件の知識などが抜けていることがある。 ------------------------------------------------ S氏：再発防止対策の５視点再発防止作には５つの視点がある。今日のコメントはこの５視点に基づいてコメントしています。人・物・設備・物の流れの仕組み・作業の流れのしくみという５大要素がある。それの本来あるべき姿が、人が確実に働く・良い部品がそろっている・設備、治具が確実に動く、物が円滑に流れる仕組みができている・うまい作業の流れができているという視点でものづくりの条件を安定的に確保しようとする方法。５ゲン主義入門という本があるので是非読んでみてください。社長の机は現場に置け、物事の本質は現場にあるというおもしろいことをいっている著者が書いています。まとめソフトウェアの品質は、品質の作りこみと不具合の検出の両面で抑える。 SWESTのねらいは草の根的なネットワークの形成なので、名刺交換がまだの人は名刺交換を、それが終わったら徹夜部屋で議論してください。それではありがとうございました。