製造業の品質管理の背後にあるSDCAという考え方をソフトウェア開発に適用できるのか

製造業の品質管理を調べてみて、その背後には、「SDCA」という考え方があるのではないか、と考えてみた。
ロジカルでないラフなメモ書き。

【参考】
日常管理 - エクセルＱＣ館

PDCAサイクルとSDCAサイクル【品質改善と維持管理の考え方】

mame1

「当社の業務改善サイクルは『SDCA』」 トステム 佐藤方厚 執行役員IT推進統轄部統轄部長 | 日経 xTECH（クロステック）

【1】製造業の品質管理では、「標準化（Standard）」という言葉が頻繁に使われる。
彼らの意図としては、定型化できる作業、皆が知るべき技術ノウハウは標準マニュアルで整備して、安定した状態（品質）にすべき、という考え方がある。

たとえば、工場で大量生産するネジを作る時、不良品がたくさんできて歩溜まりが低いと、製造原価が高くなってしまう。
製造作業が不安定であると、製品の品質のブレが大きくなってしまうからだ。
つまり、管理図で言えば、UCLやLCLを超えた製品が多くなり、品質不良として出荷できなくなることを意味する。

そこで、ベストプラクティスを標準化という名の下に作業マニュアルにしてしまい、作業員はその作業マニュアルに従って作業すれば、安定した品質となり、歩溜まりが向上する、という方向へ持っていく。

その考え方をプロセスとして定めると、SDCA（標準→Do→Check→Action）という流れになる。
まずは標準を守って、そこから実施して評価し、是正対策を取って、標準を更新していく、という流れ。
つまり、PDCAサイクルで品質統制を行う発想だ。

このプロセスは、量産品を作るメーカーだけでなく、チェーン展開するサービス業や飲食店などにも適用しやすい。
どこに言っても同じサービスや料理の味を低価格でそこそこの品質で提供する、というやり方が向いているからだ。
たとえば、大量のアルバイトや社員を雇ったサービス業として、コンビニ、小売業、航空機内の客室乗務員、ホテルのオペレータとか。

また、個人経営の飲食店であっても、毎日提供する料理の品質を安定させることができれば、原価低減でき、利益を安定的に確保しやすくなる。

【2】しかし、昨今の時代の流れの中で、特にソフトウェア開発では、SDCAの考え方は向いていないと思う。

たとえば、業務ルールを策定したり、技術ノウハウを共有したい、と考えるWF型開発に偏ったプロジェクトリーダーは、Excelドキュメントでそれらをまとめて、共有ファイルサーバーに置いて、メールで告知して共有しようとする。
しかし、その内容はすぐに忘れられて、同じようなことを何度も繰り返す。

あるいは、社内の標準プロセスを定めて、設計書テンプレートのExcelドキュメントを作り、すべての案件に適用しようとするが、受託開発から保守案件、実費請求の要件定義案件まで多種多様なPJがあると、一つの標準では当てはまらない。
結局、数多くのカスタマイズによる派生ドキュメントが発生し、標準からどんどん離れていってしまう。

組込みソフトウェア開発のプロセス改善の違和感: プログラマの思索

【3】では、なぜ、ソフトウェア開発では標準化という考え方が上手くいかないのだろうか？

僕の考えでは2つあると直感的に思う。

【3－1】一つは、ソフトウェア開発は、組織能力よりも、個人のパフォーマンスに依存する度合いが強い事があると思う。

ソフトウェア開発では、システムの技術ノウハウや設計ノウハウは人に付いて回る。
たとえば、受託開発したシステムを本番リリース後、大量の派遣・委託のプログラマが抜けると、システムに関する知見もチームから失われ、保守コストがどんどん大きくなる、という事例はよく見かける。
そのために、数多くの設計ドキュメント、ノウハウを書いたExcelドキュメントを大量に残すけれど、結局役立たない。
システムは保守するたびにどんどん変化していくので、それらドキュメントも古くなり陳腐化してしまう。

また、新しい技術の知見も人に付いて回る。
ドキュメントを読むよりも、その人に聞いたり、レクチャを受けた方が速い。

「現場から始めるアジャイルの技術プラクティス」資料が素晴らしい～技術は人やチームに残る: プログラマの思索

すなわち、標準化しようとしても、形式知化できない部分があるし、暗黙知の部分の方が大きすぎる。
ゆえに、ソフトウェア開発の生産性は個人の能力に依存する度合いが大きく、それを組織で維持ししていくのは非常に難しい。
よって、個人のパフォーマンスを最大限に発揮できるような環境や組織体制を整備する方向へ持っていくべき、というのが最近の時代の流れなのだろう。

たとえば、議論しやすい場を設けてお菓子を用意する、プログラマが座る椅子を高価なものにする、最新のPCやサーバーを用意する、などのファシリティ（資産）が重要な理由は、個人のパフォーマンスを発揮できる環境づくり、という意味もあるのだろう。

そして、アジャイル開発がプログラマに好まれる理由の一つは、アジャイル開発は組織駆動ではなく、個人のパフォーマンス駆動であり、人重視のプロセスでやり抜く、という点にあるのだろう。

だから、人を大切にすることで、システム開発で得られた知見をチームに残す、という発想につながるのではないか。

アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

【3－2】もう一つは、Excelドキュメントと相性が悪い点もあるように思う。

技術革新が速いので、Excelドキュメントに書いても、陳腐化してしまう。
Excelドキュメントの賞味期限が短すぎるのだ。

そして、Excelドキュメントは履歴管理しにくいし、検索しにくい。
日付の入ったファイル名のExcelが増殖し、最新の内容がどこにあるのか、作った人も分からなくなる時もある。

そこで、技術ノウハウはWikiに書いて残す、という手法もある。
もちろん、Wikiの内容も陳腐化してしまう可能性は高いが、Webで公開されていれば、他の人が気づいて更新することもできる。
全文検索エンジンによって、有用な情報だけ探す、ということもできる。

標準化した情報がすぐに陳腐化してしまうなら、その内容を即座に更新できたり、それらを即座に共有できたりする基盤があれば、ある程度は解決できるはずだ。
この辺りの内容は、一つのテーマとして、ずっと考えている。

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

静的ジェネレータを使ってExcelマニュアルをWeb公開するアイデア: プログラマの思索

【4】SDCAという考え方が合わない場面が増えているのは、定形業務のビジネスモデルが最近は儲かりにくい、という点にもあるのだろう。
「Software is eating the world」という流れでは、定形業務や低賃金労働は全てソフトウェア化できるし、ソフトウェア化されたビジネスは、限界費用ゼロまでコストが徹底的に低くなる。
すると、人間の手でSDCAサイクルを回して品質管理をやっていく、という悠長なやり方は通用しにくくなるのではないか。

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career

ソフトウェアが世界を変えている – うめのんブログ

この辺りも整理してみる。