開発プロセスを軽量化するには

　車載システム開発への要求はIATF 16949やAutomotive SPICEといった品質マネージメントシステムに加え、ISO 26262による機能安全、ISO/PAS 21448 SOTIF、そしてISO/SAE 21434 サイバーセキュリティと確実に増えています。要求事項に比例して「開発プロセスが重い」というご相談をよく受けます。「開発プロセスが重い」とは具体的にはどのような状態でしょうか。例えば、あるお客様のところではプロジェクト計画、安全計画そしてサイバーセキュリティ計画を異なるチームが独自に検討し、重複した内容の計画書が3つ作られていました。また別のお客様は、既存の設計書とは別に機能安全用の設計書、さらにサイバーセキュリティ設計書が関連なく追加されていました。

　なぜ開発プロセスが重くなるのでしょうか。監査やアセスメント、認証をパスするために、規格の要求事項を一行たりとも漏らすことなく反映することだけが目標になっていないでしょうか。そこには新たな受注や事業の継続を考えると、失敗が許されない監査やアセスメント、認証が不合格となるリスクを可能な限り回避したい状況があります。そのような状況でベースとなる品質マネージメントシステムを踏まえず、機能安全やサイバーセキュリティの活動や成果物が無条件に追加されたとき、開発のいたるところにムリ・ムダ・ムラが生まれます。

　過去に、開発コストの年間30%削減を目標とするお客様からプロセス改善の依頼を受けました。最初にプロジェクトの状況を確認すると、プロジェクトの規模に対して開発プロセスが重いことは感覚的に明らかでした。まずプロジェクトで実施された活動、作成された成果物を列挙し、関係性を図示しました。図示による見える化でプロセスに出てこない活動や成果物が見つかります。さらに分析を進めると、支流が多く活動の順序関係がわかりづらい複雑な作業の流れも見えてきました。

　図示した活動の流れを関係者と眺め、改善の可能性がありそうな活動や成果物に対して改善の指針ECRSの原則（日本経営工学会編（2002）「生産管理用語辞典」日本規格協会より抜粋）を活用しました。「なくせないか？（Eliminate）」、「一緒にできないか？（Combine）」、「順序の変更はできないか？（Rearrange）」、「単純にできないか？（Simplify）」を判断します。その結果、必ずしも必要とはいえない活動や成果物、重複やタイミングが早いまたは遅い活動、肥大化したテンプレートの存在が明らかになります。具体的には、同じ内容にもかかわらず品質マネージメント向けと規格対応向けに作り直す2種類の報告書、プロセス資産の不足を補う担当者独自の設計文書、成果物の完成を確認するチェックリストでやっと出てくる設計の注意点、人によって順序が異なる作業の流れに改善のメスを入れました。お客様とこのような改善アプローチを定期的に繰り返し、1年後には開発コストの30%削減を達成します。

　規格要求への適合だけに焦点を当てて構築された開発プロセスは重く、理にかなっていない開発の流れはその不備を補う新たな活動や成果物を生み出します。このような事態を回避するには、開発全体の見える化と分析による最適化が必要不可欠です。今回の事例は小規模なプロジェクトのため手描きの図で全体を把握できました。
　しかし、プロジェクトの規模が大きい場合や適用プロジェクトの数が増える場合、実施した活動や作業成果物の関係性を手描きで図示することは困難です。このような場合には、規模に関わらずプロジェクト管理ツールや構成管理ツール、不具合管理ツールなどのログからプロセスの適用状況を見える化し、問題や課題の原因を探索するプロセスマイニングというアプローチを活用することが可能です。

　プロセスマイニング手法の概要、ログデータを活用してプロセスの健康診断を実施する流れ（活動の見える化、多面的なデータ分析）についてデモを交えて、下記セミナーで解説します。
プロセスマイニング無償セミナーの申し込みページ(https://biz3.co.jp/publictraining_category/processmining)

　最後に、事業環境が目まぐるしく変わる中で開発現場のその役割の重要性と負荷は高まるばかりです。だからこそ規格への適合とともに開発全体の最適化に取り組み、付加価値を生み出す開発プロセスの構築を再考してみてはいかがでしょうか。

2021/5/26 西門 克郎