品質マインド

システム開発では、数多くの人間が携わる。

システムの障害が発生する原因に仕様漏れやロジックミス、テスト漏れがある。

障害が発生した場合、暫定対応の後に、恒久対応、是正処置を行い再発の防止を行うため障害の根本原因を探る。

このとき、障害の根本原因を「人」ではなく「仕組」と捉えるのがQMS(ISO9000)である。

QMS(ISO9000)では、「人」を消し、組織の「仕組」の改善から品質の向上を謳っている。

しかし、いくらガイドラインやチェックリスト、観点のドキュメントを充実したところで、本当に障害は減ったのだろうか。

本当の障害の根本原因を突き詰めれば、どうしても「人」に行き着くのである。

「人」が設計し、「人」が開発し、「人」がテストし、「人」が使う。やはり大事なのは「人」である。

品質向上のためには各人が「品質マインド」を高めることが重要なのではないだろうか。

どれだけ品格のある質の高い人間を育て上げるか。それが企業が人財を育てる上での課題だと思う。

QMS(ISO9000)では、根本の障害原因を「人」ではなく、「仕組」と考える。

レビュールールを決めていなかったから、テストの観点から漏れた。

テストの観点リストがなかったため、テストケースの考慮漏れが発生した。

仕組の問題。……しかし、障害発生時に思うことはないだろうか。

「この人がやったとこか。また、障害発生しちゃったな」

「あの人、テストしないからなあ」

「このあたりのロジックだけ、コーディングルール適当だなあ」

システム開発において、品質改善を考えるうえで、「属人化」の問題ははずせない。

しかし、考えれば考えるほど、「人」の存在は大きく、「人」が原因であるとしか考えられなくなった。

システムの利用者、システムの提案者、システムの開発者、システムの運用者……。

1人が複数の役割を演じることもあるだろう。システムには人の存在がある。

完全に自動化されたシステムであっても、その損益を得る部分に人が結びつく。

システムの開発に携わる人々を役割で掘り下げていけば、プロジェクトの管理者、システムを設計する者、ネットワーク管理者やデータベース設計者などのインフラ環境を構築する者、デザイナ、プログラマ…。 様々な人間が携わっていくこととなる。

また、システム開発に携わる人々を経験年数で掘り下げていけば、ベテラン経験者、そこそこの経験者、新人。

さらに、システム開発に携わる人々をシステムの理解度でいえば、初期開発から従事、途中から従事、今回初めて設計から参加。開発だけ参加。テストだけ参加。

システムとの係わり方が全く同じ人間なんて1人もいない。ましてや、考え方や能力が同じ人間なんて1人もいない。

……とはいえ、そうなると品質基準と言うモノサシなんてつくることが出来ない。

誰がやっても同じ作業を行い、同じ結論になる。これがQMS(ISO9000)の望むべき結果である。

仕組改善を考える上で、「なぜなぜ5回」というものがある。問題の根本原因を探すために、なぜを5回繰り返すのだ。

はじめは、現場に即した観点から考慮を行って行き、最終的には抽象的な作業レベルに落としていく。

【是正処置】仕様変更が発生した場合には、仕様変更票に記述する仕組を作成する。

そして、この是正処置は業務全般に活用できる汎用的なものでなければならない。

抽象化された内容は汎用的に利用できる。しかし、世の中は複雑でより具体的な内容が多く、詳細は「臨機応変な現場での判断」が必要になる。

この「現場の判断」が誤れば、再び障害は発生し、この仕組に例外的な内容を追加することになる。

足りなかった仕組は追加され、さらに仕組は肥大化していく。

そして、品質改善のために本来行うべき作業は次第に圧迫されていく。

仕組を充実することで、誰がやっても同じ結果を作ることのできる環境が構築されていく。

しかし、誰がやっても同じ結果が出る環境があったとしても、時を重ねれば不具合は出てしまうだろう。

同じ結果が出る環境の外で何か変化があった場合に、作り上げた仕組はもろくも崩れ去ってしまう。

同じ結果が出る環境の外の変化は予想以上に多いものである。この世に例外が多いことはシステムの開発者なら容易に理解できることだと思う。世の中は単純ではない。

個人の見解では手順の見える化、ドキュメント化、定型化はメリットがあり、行っていくべきだと思っている。

企業としては、誰がやっても同じ結果が返ってくる仕組みが欲しいのだろう。

安心してその作業を行うことができ、問題が発生することはないのだから。

その企業の品質を全体的にベースアップするためには、QMS(ISO9000)の活動は有効であると思う。

ただ、そのベースアップだけで不具合が全て解決するラインにまでは達していないのが実情である。

そして、注意すべきは「報告しない仕組」ができていくことに気がついていかねばならない。

報告するための作業量と報告後の是正メリットのトレードオフを考えてみて、「報告する仕組」それ自体に疑問を思う者も出てくるのである。 そして、その思いは徐々に大きくなり、わずらわしさを感じ、いつしか組織の中で「報告しない仕組」ができてしまうのである。

適当な仕組、形骸化した仕組を利用したところでそのメリットは少ない。

ここで考えて欲しい。

できる人間は仕組に頼らない人が多くないだろうか。

自分に不安を感じる人間こそ、その仕組に頼ってしまってはいないだろうか。

企業が目をそらしてきた、ごまかしてきた「人」に目を向ける必要があるのではないだろうか。

できる人間には、できる人間が持つ考え方がある。それはできる人間が持つ仕組とも言える。

自分が見てきた狭い世界ではあるが、「キーマン」のいないシステムはなかった。

さすがに、「キーマン」がいなくなっても、対処不能と言うことはなかった。

しかし、その後の不具合や問題の対応レベルは下がっていると思う。

その後の要望対応や改善提案においても影響が出ていると思う。

設計書や手順書を全て見える化できるほど、システムは単純なものではない。

打ち合わせの内容、レビュー中の雑談、障害対応時の考え方や対処、その全ては頭の中の片隅にしか残っていない。

その頭の中の片隅の知識が文章化されることはない。ほぼ読み取り不可能で断片的な記憶だけが残っているだけとなる。

誰が行っても同じ結果を返すためには、全ての手順を明確に記述することである。当たり前のことでも……である。

そして、手順が変わったのなら、手順書を最新の状態に更新する必要がある。

その作業は誰が行うのか。誰もしなかったのであれば、放置されメンテのされていない、誰がいつ作ったかわからない手順書が増えていく。

その手順書はプラスになることも多いだろうが、一方でマイナスを持ち込む危険性が潜んでいる。少なくともその手順書が妥当であるかを判断する確認作業を行う必要がある。

（設計書はない、設計書が古い。……モジュールのソースしか信じられない時が多いもんである。そのソースでさえ、いつのものかわからず信用できないこともあるけど。）

賞味期限……むしろ証実期限のある手順書や設計書は本来は簡素で具体的に書いておくべきである。

そして、当たり前のことは記述されるまでもなく、「人」が理解しておくべきなのである。

ただ、当たり前のことがみんなわからない。（自分も当たり前のことがわからない。）

テスト仕様書や設計書に記述されている内容の確認は当たり前のことである。

品質向上の一歩先のアクション。記述されていない内容まで確認すること。これが1つの品質マインドの実践だと思う。

報告にはテスト仕様書に書かれているテストをすれば十分かもしれない。

このデータを放り込んだらどうなるのか。この方法を試せばエラーが出るかもしれない。

本当に品質を上げようと意識し、取り組む行動こそが品質マインドだと考える。

妥当かどうかもわからない品質保証値に見合ったテスト件数の消化のためのテストで終わるのか、

本当に品質を上げるためのテストで終わるのか、それはテストするユーザの心構え1つである。

品質保証値に見合ったシステムは、作り手からすれば、品質保証を説明しやすいシステムである。

しかし、そのシステムが本当に品質が高く、品格のあるシステムであるかどうかは判断できない。

どれだけ品格のある質の高い人間が携わったかが、そのシステムの品質につながるのでないだろうか。

「人」が設計し、「人」が開発し、「人」がテストし、「人」が使う。やはり大事なのは「人」である。

どれだけ品格のある質の高い人間を育て上げるか。それが企業が人財を育てる上での課題だと思う。

できる人間は、「よいシステムを作る仕組」を知っていて実践している。

できる人間を作る仕組（品質マインドを高める仕組）を作っていくべきではないだろうか。