派生開発カンファレンス2019参加レポート（４）

プロセス分析表によるプロセス改善方法の最適化の提案

（株）デンソー
岡 和道さま、古畑 慶次さま

 

～目次～

 

 

 

 

背景

業務内容　

将来の自動運転に向けたセンサ群と制御システム
カメラセンサを用いたステアリング制御
（安全利便機能）
白線と周辺物体の認識

 

開発手法　

モデルベース開発
　・V時モデルでは開発サイクルのスパンが長い
　・統合テストとシステムテストをモデル上で実施
　・実車まで利用してシステムテストを実施
　（お客さんの試乗も可能）

 

メリット

　・先にモデルをFIXできる
　・AutoCode（コードの自動生成）で開発
　・開発後、ソフトウェア検証、テストを実施

現在実施されている内容のレベルの高さに圧倒された。
モデルベースでここまで実現できていてさらに課題解決を行おうとしていることに驚いた。

課題

高速シミュレーション罠（デメリット）　
モデルへ不具合が混入した場合
　→　モデルを修正すると不具合はすぐに解消できる
　　　が、不具合の混入原因への考察が見逃される
　　→　根本対処に至らない

　　　→　開発規模が増大した場合、同様の不具合が多発する

理由　

  • 根本原因の対策検討に時間がかかる
  • 対策自体に時間がかかる
  • 根本原因の特定には経験とスキルが必要
  • 全体を俯瞰した対策になりにくい
    （自分の得意分野で対処しようとしてしまう）

 

背景の時点でも感じたが、課題 として扱っている内容のレベルが高い。基盤技術がしっかりしているからこそできる議論なのだと思う。
根本原因については、有識者ならば経験や知識、勘でまかなってしまう部分だと思うが、有識者基準の方法ではプロセス化することができない。すごく良い着想だと感じた。


対策

原因箇所特定の容易化　

PFDを活用し、開発プロセスを表現する地図作成
　→　発生した不具合から原因まで
　　　地図を利用して不具合事象を出発点とし、
　　　原因にいたるまでのルートをたどる
　　→　その途中に混入原因となるプロセスがある

 

対策の容易化　

原因箇所の対策候補を探索し大きさ（効果）を比較するソナーを用意する
→　対策の全方位探索を実施し、効果の大小で対策を選択する

　→　問題と原因、対策をプロセス分析表に記載

　　→　ある程度不具合が溜まったところで、
 　　　　対策の選定を行う。

 

  • 対策候補の内容を表形式で並べることで、容易に比較できるようにする。
  • 不具合が複数発生した場合、同じ対策で複数の不具合を同時に対処できる対策が見つかる
  • 不具合を多発させている箇所等が浮彫になる
  • 根本対処にパワーを割く

 

 

作業プロセスを論理的に捉えて、入力/作業/出力というPFDの構成要素に該当するとという考え方に基づいていることに、なるほどな～と納得してしまった。デバッグ作業のプロセス版といった感じなのだと思う。実行パスの中に、必ず混入原因となる処理（プロセス）が存在する。あたりまえのようで、普段ついつい見逃してしまっているところなのだと思った。

不具合が発生した場合、ついつい処置をしたい衝動に駆られてしまうが、根本原因を特定して対処するため不具合を蓄積する。そして、プロセス分析表を利用して、不具合を俯瞰して見る。一見して淡々と分析しているようで、新しい考え方がたくさん含まれている。
まず、不具合を蓄積すること。そして、根本原因を対処すること。根本原因を対処すること自体に目新しさを感じた。不断だと、不具合が発生するとその不具合単品から根本原因を探し出そうとしてしまう。その時、有効な対処となるかは、エンジニアの知識と勘に依存しているように思う。つまり、的確かもしれないが誤る可能性もある。PFDのみを用いて問題となるプロセスを特定するだけでも不十分だと思う。複合的な原因からなる事象の場合、対処箇所が複数となるからだ。その点、不具合を蓄積して分析することで、関連するプロセスを俯瞰して見ることができるようになると思う。そして関連する原因プロセスの存在にも気付けるようになるのではないだろうか。
過去の事象等もプロセス分析表に盛り込めると、もっと見えてくるものが増えるように感じた。

 

応用　

  • 今回の手法はモデルに依存しないため、一般的な開発にも適用可能
  • プロセス全体の最適化への活用も可能
  • プロセスのレイアウト/変更・追加の検討

 

今回ご紹介いただいた内容は、 プロセス自体の評価や見直しにも有効であり、「ハザードマップ」という言葉がすごくしっくりきた。
プロジェクトを進める上でもソフトウェアにおいても、今後重要なツールになってくるように感じた。今後、ハザードマップの再利用も考慮できるようになると、資産化につながるように思った。

Q&A

Q:プロセスがきれいに可視化できてるが現実問題もっと複雑では？
　A:PFDで表現可能
　　作業自体はすべて入力をプロセスで出力に変える
　　(要求が不明瞭ならば明瞭化するプロセスとして定義できる)

Q:対策によるデメリット等の検討はどこで実施するのか
　A:プロセス分析表から有効な対策を選定する際に
　　DRの形でメリット・デメリットのトレードオフを
　　実施

Q:対策による悪影響についての考慮は？
　A:デメリットとしてプロセス分析表から対策を
　　選ぶ際に考慮する

Q:プロセス分析表から対策を選択する場合、
　得意分野での対策を選ばないようにする工夫は？
　A:DRの形をとる

Q:全方位探索は大変そうだが、
　何に対しての全方位なのか
　A:PFD上での問題となったプロセスの入出力の線

Q:実施するタイミングは？

　A:ある程度不具合がたまったタイミング

Q:プロジェクトが変わるとPDFも変化するのでは？
　A:派生開発ならばPFDにも類似性がでるはず
　　過去の情報（ハザードマップ）を参考にしながら
　　変更したプロセスは追加して蓄積していく

Q:不具合の根本原因が要求検討や要求分析の場合、
　どう扱うのか？
　A:要求の時点で不具合が入りこむことはある
　　頻発する場合は、提案という形で理由等を要求に
　　盛り込んでもらえるようにお願いする
　（上流に関するPFDの構築材料をふやしてもらう）
Q:ベテランの人は勘と経験で対処してしまうと思うが
　どのように対応したのか？
　A:最初はみんなやりたがらない
　　初期は登壇者が一人で実施
　　効果がでてくるとみんな理解して参加し始めた