ISO9001をシステム開発に適用し続けることの弊害
何かと認証を取るのが好きというか、認証を取っていることを求めるクライアントが一定数存在する。個人情報の絡みもあり、契約前にセキュリティのチェックリストにISO27001の認証やプライバシーマークの認証取得の有無などがある。こうした認証を求めるのは、委託元に委託先に求める要求事項を見抜ける力量が怪しいとからではないかと思うこともある。認証自体が本来第三者が要求事項を保証する仕組みだから間違いではないのであるが。
ISO9001という認証があり、90年代から広まった感がある。今ではすっかり聞かないが業務プロセスに定着しているからかもしれない。事業の稼ぐ業務品質を組織として標準プロセスを設計し、ISO9001の要求事項に適合させることで品質を保つということをやってきた。
ところで、プロジェクト内での教育という考え方がある。要員を調達し、技能が不足しているのであれば、プロジェクト内の予算と時間を使って要員に不足しているスキルを身に付けさせ、必要とする要員に仕立てるというものだ。
＊＊＊
ISO9001の認証を取り、システム開発に適用していると規格に『7.2 力量』で『必ず、必要な力量を備えるだけの措置を取り』とあるので、プロジェクトで必要とするスキルを持っていないエンジニアをかき集めたとしても、（リスクが増えるばかりで何１つ良いことはないのに）プロジェクトに必要な力量を備えるだけの研修をやったことにすればISO的にはなんら不適合はない（そもそも組織が規格を理解し、それでいいと規程化すれば認証上は問題ない）。
これが形ばかりで残っていると、プロジェクトを第三者目線で見る立場のロールの人たちはリスクマネジメントの観点で全くの役立たずの存在でしかない。
ISO9001:2015の注記の最後に『力量を備えた人の採用』などと改定で補記されているくらいだから問題だと感づいてはいるのかもしれない。
＊＊＊
話を戻しすと、現場のマネージャ業をしていれば（していなくても）、プロジェクト内教育のバカバカしさはよくわかると思う。社員でしかも若手エンジニアを入れるのであれば、育成の観点があるので対策はするだろうが、調達する場合はそうしたプロジェクト内教育という考え方は適切かどうかといえば、プロジェクトの開発スピードにあっていない、古い考え方でしかない。
まあ、業務特性として作業の工程や手順が定められ、その通りにやることを身に付けられれば誰しも同じアウトプットできるのであれば、その考え方はありなのだろうが、システム開発にはその考え方は無理筋である。
