IoT化の「落とし穴」とは何か？というテーマで、年末受けたインタビューにて、日経テクノロジーオンラインに記事が掲載されました。

それでは、FMEAを実施する際の注意点や問題点には、どのようなものがあるでしょうか？

FMEA（Failure Mode and Effect Analysis）は、種々の特徴がある。まず、なぜ効果的かについて説明したい。

FMEA（Failure Mode and Effect Analysis）は、品質問題の未然防止を図るなどの目的で実施されることが多いが、その種類を認識して活用すると効果的である。特に、下記の④の開発プロセスにも応用可能であることは、あまり知られていない。

　組込みソフトウェア開発に「なぜなぜ分析」を有効に活用するためには、以下が重要となる。

　組込みソフトウェア開発に「なぜなぜ分析」を適用したものの、成果に結びつかない理由は、なぜなのだろうか？

　発生した問題の本質的な原因を特定し、再発防止策を導き出すための「なぜなぜ分析」は、特に組込みソフトウェア開発では効果的である。

ソフトウェア開発においては、外部委託の進め方がキーポイントになる場合が多い。外注の活用、管理においてコンサルティングする機会も多いが、まずは下記の６ポイントでアセスメント（評価）を実施する。

　FMEA（Failure Mode and Effect Analysis）という品質改善などの利用される手法がある。この手法は、ハードウェアの品質改善としては確立されているが、ソフトウェアの品質改善に真に利用できているとは言いがたい状況です。

プロセスという言葉は、開発を実施しているとかなり頻繁に耳にする。いわゆる開発プロセスである。

先日、ある企業の顧問の方が、開発プロセスの標準化は本当に必要なのかという疑問があった。

今年、IPA（情報処理推進機構）SECから共通フレーム２０１３が発行された。

日本のものづくり産業の競争力低下が叫ばれて久しい。ではいったい、日本のものづくり産業はどのように変革していけばよいだろうか？

超上流工程という言葉がかなり浸透してきたが、３月に独立行政法人　情報処理推進機構（IPA)のソフトウェア・エンジニアリング・センター（SEC）から公開された資料に「高品質のための超上流工程における企業の課題・取組み事例集」というものがある。

昨日（3/14)、株式会社サートプロ主催の第３回　組込みソフトウェア 品質改善セミナー 「プロジェクトマネジメント計画書 作成 基礎編　ESMR研修講座」の講師を実施させていただきました。

３月1４日（木）に実施予定の品質改善（プロジェクト計画作成）セミナーの話の続きです。

パートナー企業であります　株式会社サートプロ　主催の品質改善（プロジェクト計画作成）セミナーの講師を実施致致します。

独立行政法人　情報処理推進機構（IPA)のソフトウェア・エンジニアリング・センター（SEC）が発行している品質改善関連の書籍は多数ある。

本日は、ESMG（組込みソフトウェア向け プロジェクト計画立案トレーニングガイド）について記載します。

独立行政法人　情報処理推進機構（IPA)のソフトウェア・エンジニアリング・センター（SEC）が発行している書籍で、ESｘRシリーズというものがある。

テストは、開発管理上も、品質改善においても重要である。

　続いて、開発プロセスの記載事項である。基本は、開発を進める上での必要項目、手順、留意事項などを記載すれば良い。

　開発管理のシリーズでブログを書いていたが、ある意味一番重要な開発プロセスの話が後になった。開発プロセスというとピンとこない方も多いかもしれないが、開発手順書と考えた方がわかりやすいかもしれない。

　前回の非機能要求の続きである。実際に非機能要求はどのように纏めるのがよいのだろうか？　正解があるわけではないが、私は下記の方法を推奨している。

　前回の続きであるが、機能性の要求は曖昧性などを含むことも多いが、項目が最初から抜けてしまうことは少ない。機能が無ければ、全く製品として成り立たなくなるからだ。

　一方、非機能項目は忘れがちということもあるが、要求仕様書にどのように表現・記載していいかわからないという相談も多い。

要求仕様定義がレベルが低いと、品質に影響するばかりでなく戻り作業が多くなるなどの弊害が発生する。また、最近は要求仕様定義がますます重要視されている。

　前回、開発V字モデルにて開発工程を記載した。その中で””要求仕様定義”と”方式設計”という工程（フェーズ）があると書いたが、この工程の切り分けは非常に単純そうに見えて、うまくいっていない場合が多い。

DFSS（Design for Six Sigma）セミナーを実施いたしました。今まで単独でDFSSを使用した組込みソフトウェアの品質改善のコンサルティングを実施してきましたが、今後はパートナー企業とタッグを組み、進めていきます。

　ソフトウェア開発ではデザインレビューが重要なことは言うまでもない。しかし、下記のようなレビュー体制により、心理的な要素も加わりレビューがうまくいかない例も多い。

　DFSS（Design for Six Sigma）によるソフトウェアの品質改善の続きです。前回のブログでは、DFSSでの品質改善は失敗することが多いと言いましたが、その理由は以下です。

　DFSSは、部分最適や現場レベルの改善では無く、トップダウンによる改革だからです。すなわち、DFSSでの改革は経営レベルの戦略をスタート地点として、組織改革を伴う従来のやり方を根本的に改革します。

　実際に企業様へコンサルタントに入ると、経営トップレベルと進め方をディスカッションし、方向性を決定します。その内容に基づき、改革に着手しますが、実際の現場レベルでは

変更の大きさに抵抗する勢力が必ず存在します。この担当者レベルの説得もコンサルタントの業務の一部と考えていますが、現場レベルでは現状で問題無いと考える担当者も多く、変更の不安もあり、なかなか進まないことも多いです。

　ここはコンサルタントの権限では限界があることもあり、経営トップと共同でなんとか

現場の説得となりますが、表面上は納得したとしても、心の底から納得できていないと大きな改革は逆に中途半端な状況になります。

　以上が、DFSSによる改革の失敗に典型パターンです。DFSSについては、もう少し後日記載します。

　ソフトウェアの品質の改善手法は数多くありますが、コンサランスでは品質改善をDFSS（Design for Six Sigma）により実施することが多いです。勿論、レビュー手法の改善、評価方法の修正など単独の内容でのコンサルティングも実施しますが、その効果を最大限引き出すことができるのがDFSS（Design for Six Sigma）と考えています。

　一方、DFSS（Design for Six Sigma）でのコンサルティングは失敗することも多くなります。それは何故か？　また、後日ブログで。。。。

　　DFSSへのリンク