開発プロセスを管理することでしか、ソフトウェアの品質は管理できない

ネットでフラフラしていたら、偶然良い記事を見つけたのでリンクしておく。
特に主張は無し。
ラフなメモ。

【参考１】Embedded Software Manufactory: ISO 26262との向き合い方 (21) 安全について理解を深める

【1-1】「開発プロセスを管理することでしか、ソフトウェアの品質は管理できない」という文言にしびれた。
ああ、そうなのか。
自分がRedmineにハマっている理由は、たぶん、Redmineを通じて開発プロセスをモニタリングすることで、ソフトウェアプロダクトの品質・コスト・納期を調整しようと暗黙的に行っていたから、と思う。

でも、プロセスアプローチの発想は、アジャイル開発とは異なる。
アジャイル開発は、プロセス重視ではない。
では、その部分はどう解釈するべきか？

（引用開始）
しかし、何もしないで放っておく訳にはいかないので、ソフトウェア開発プロセスによるアプローチを定義することになる。これは現在のところ、どの業務ドメインでも同じようだ。開発プロセスを管理することでしか、ソフトウェアの品質は管理できないというのが、ソフトウェア品質論の定説となっている。（『ソフトウェア品質論の歴史的推移』を参照されたし）
（引用終了）

【1-2】IT業界では、新しい技術や設計思想は、熱意を持った人がエバンジェリストとして普及させる必要がある、という経験則があるのだろう。
「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」の最初にも「エバンジェリスト」があったなあ、と気づく。

（引用開始）
そして今では、安全とは何かについての考えが深まっていない人々に対して、どうすれば安全の概念についての考えを深めることができるのかを伝えることが自分の責務だと考えるようになった。
（中略）
Microsoft の社員の肩書きで Evangelist（エバンジェリスト：伝道者）というのを見たことがあるだろう。上に書いた役目は Journalist とか、Consultant ではなく、Evangelist が一番ぴったりくるかもしれないと思っている。
宗教じゃないから伝道という言葉はあまり好きではないが、人間はコンピュータのように常に論理的とは限らないから、熱意を持って伝えないと伝わらない。自然科学ではない、ソフトウェアに対する考え方は、説明ではなく伝道でないと伝わらないことを Microsoft はよく分かっているから、その道のエキスパートに Evangelist を名乗らせているのだと思う。（洗脳者のような胡散臭い感じもするが・・・）
（引用終了）

【参考２】Embedded Software Manufactory: ソフトウェア品質論の歴史的推移

（引用開始）
「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
「良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるのがプラグマティズム的品質論。
「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である
（中略）
この新しい品質論は、グローバル化経済において、究極の品質論のように見える。
「民主主義的原理に基づく品質論」
「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。
「民主主義原理に基づく品質論」はソフトウェア品質評価法に代表される観念的品質論とCS運動における顧客満足に基づく品質改善を基礎とするリバタリアニズム的品質論を融合するものになる。
（引用終了）

製造業の品質管理技法は、いわゆる古典的な統計的品質管理が発端らしい。
つまり、量産品のバラツキを統計的手法によって原因分析して解決し、不良率を減らす。
日本が得意。

一方、プラグマティズム的品質論は、「良いプロセスが実践されているからこそ、良い品質が生み出される」と考える」。
この発想を元に、プロセスを国際規格として定めて、トップダウン・アプローチで形式知として実現したものが、ISOなどの各種規格。
今の日本は、このやり方がグローバル・スタンダードになったために、すごく苦労している。

さらに、「民主主義的原理に基づく品質論」はマーケティング３．０または、アジャイル開発を連想させる。

しかし、日本の品質管理でも、製品ライフサイクルによって、狩野モデルにある「魅力的品質」から「一元的品質」「当たり前品質」へ品質が変化する、ということも既に指摘されていた。
この辺りの整合性はどう取るのか？

【参考３】Embedded Software Manufactory: 機能安全の意味がわかった(IEC61508とISO26262の最新情報）

最近よく聞く「機能安全」とは、安全装置が保証する安全に関する機能、という思想があるわけか。
そうならば、すごく理解しやすい。
最近は、IPAも組込安全規格に関して、盛んに研究しているしね。

（引用開始）
機能安全の説明でよく踏切の例が挙げられる。踏切ではなく高架橋を作ることによって通行者の安全を確保するのが本質安全で、踏切という安全装置によって安全を確保するのが機能安全。
（中略）
機能安全の規格は安全装置によって安全を確保する狭義の Safety という意味合いが強いということがこの記事を読んでよく分かった。本質安全に対する安全装置による安全（=機能安全）と考えると非常にすっきりする。
そして、安全は安全装置の設置という狭い考えではなく、システム全体を踏まえた包括的な安全性の実現を考える必要がある。
（引用終了）

【参考４】Embedded Software Manufactory: ISO 26262との向き合い方 (6) 機能安全のマネジメント2

【4-1】現代のソフトウェア開発では、ITS、SCM、CIツールの３つが使われるのは当たり前。
その効果は、変更管理や構成管理がツールで制御できるようになったこと。
今後の課題は、要件管理である、という主張。

（引用開始）
変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。
（中略）
構成管理や変更管理が日本でも受け入れられているのは、 構成管理や変更管理がボトムアップの開発にも十分に役立つからである。同じように要件管理ツールも普及すると思ったら大間違いだと自分は思っている。（構成管理や変更管理のボトムアップでの組織への浸透については『リコールを起こさないソフトウェアのつくり方』の二章にやり方も含めて詳しく書いた。）
（引用終了）

【4-2】日本発祥の開発プロセスであるXDDPは、特に派生開発で有効。
その理由は、日本人に合うボトムアップ・アプローチによる変更管理をコントロールできるから。

（引用開始）
日本では問題が分かったときの修正のスピードが速い。デグレードはゼロとは言えないが、とんでもない見落としは少ない。それは、品質を心配する意識： Awareness: Worrying about Quality の力ではないかと思っている。（これうまくいかず品質に悪影響を与えるケースが増えており、変更の影響を分析、管理しながら変更を実装していく XDDP という取り組みが今話題になっている。）
（引用終了）

【4-3】安全が確保されている証拠、機能安全の規格を満たしている証拠として、トレーサビリティマトリクスがある。
そのトレーサビリティマトリクスを作成・維持するために、要件管理ツールの存在意義がある、という主張。

（引用開始）
その状態を回避し、ユーザーの期待（安全は当たり前に確保されているはず）に答えるには、安全に対する要求と、その実現方法、実現の結果（証拠）を常にトレースが取れるようにしておく必要がある。そのトレースのセットがトレーサビリティマトリックスとなる。
要件管理ツールはこのトレーサビリティマトリックスを保持するための助けとなる。
（引用終了）

【参考５】Embedded Software Manufactory: ISO 26262との向き合い方 (1) 最初に読んで欲しいこと

著者がISO 26262 にこだわっている理由を経験談を元に書かれている。
「「自分はキチンとやっていたが、組織的な品質システムとして実施されたものではない」という状態」だったから、米国での製品販売が止められた。
著者は、当初、理由が分からなかった。
きちんとやっているのに、なぜ差し止められるのか。

しかし、後に著者は理解する。
「個人が自分の考えで実施している検証は品質マネジメントに基づいたものではないローカルルールで行われものであるため認められないのだ。」
つまり、世界標準のやり方でないと通用しない世界がある。
その背後には、プロセスアプローチ、プラグマティズム的品質論の考え方がある。