「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ
ソフテックもISO9001認証取得に動き出すことになりました。そして、私がその担当責任者に任命されました。
そこで、今回のメルマガでは、なぜISO9001認証取得に動き出すことになったのか、ISO認証取得への道のりでぶつかった関門について書いていきたいと思います。
(こんな風に書くとすでに認証取得したかのようですが、まだまだ道半ばといったところです)
ソフテックがISO9001認証取得に取り組む理由はただ一つ、「品質向上」です。
ソフテックでは、たとえば次のような問題があり、ソフトの品質向上に悩んできました。
どれもしばしば耳にすることでした。
数年使って古くなったら、仕様も含めて一から新しく作り直してしまうようなソフトであったとしたなら、大きな問題にはならないと思います。しかし、ソフテックのお客様は長期間(5年、10年あたりまえのように)、時には細かなバージョンアップを行いつつ当社のソフトを利用してくださいます。
5年や10年も経ってしまっては、プロジェクトを管理していた者や、ソフトを実際に作成していた担当者でさえも、仕様を思い出すのは困難です。細かい部分までと言ったらほぼ不可能です。
ましてや関わっていた者達が退職していたとしたら、仕様書無しではソースから仕様を解読していくしか手段が無くなってしまいます。
こうしたことからソフテックでは、「このままでは品質を保つことができなくなってしまう」という強い危機感を感じるようになったのです。
これを避ける方法は簡単です。仕様書を作ればいいのです。仕様変更に対して仕様変更管理票と言ったような文書を作成して記録を残せばいいのです。テスト項目書の体裁を決め、正式な文書として結果を残すようにすればいいのです。
これらの対処方法は、わざわざお金をかけてISO認証取得をせずとも、本来実施できることです。しかし、ただ担当者に「お客様が納品物としていらないとおっしゃっても、仕様書は必ず作るように」「お客様に納品しないとしても、テスト項目および結果はきちんと文書で残すように」と指示しても、納期や赤字と黒字の境界線が目の前に迫ってしまうと、なかなか実施できなくなってしまいます。指示する側としても強く言えなくなってしまうのが人情です。そこで、「品質向上」、「文書作成の徹底」を目的として、ISO9001認証取得計画が動き出すことになったのです。
私としては営業効果目的ではないところがなんともソフテックらしいと感じています。
ISO9001認証取得を計画・実行した全ての企業の担当者に同意していただけるかと思いますが、なんと言っても第一の関門はISO規約※1の解読と解釈でしょう。(解釈という表現を使いますと「?」といった表情をされる方もいらっしゃいますが、解釈という表現がぴったりと来るのです)
日本語に翻訳されていますから、もちろん読むことはできるのです。読むことは出来るのですが、書いてある意味はすんなりと頭に入ってきませんし、「じゃあ、具体的に何をやればいいのだろう?」というのがイメージしにくいのです。これはISO規約の中でも書かれていますが、業種や製品にとらわれずに当てはめることができるように汎用的な書き方にしているためと理解しています。
具体的に実施する事柄がイメージできないのも問題ですが、それ以前に「ISO規約がなにを求めているか?」がきちんと理解できていなければお話になりません。
ウェブサイトを回り、本屋を見て回ってもなかなか「これだ!」という物を見つけられないでいましたが、ISO規約を口語訳した物を掲載しているウェブサイトを見つけ、ようやっと第一関門を突破することができました。
第一の関門を突破する鍵となった口語訳されたものは、基のISO規約より、かなり文章のボリュームがアップされており、読むのに時間もかかりましたが、読み進めていくに従って、どれだけ多くの文書を作らなければいけないんだろう?という不安に取り憑かれてしまいました。
ISOの本を探すと、建設業や製造業の物は多々見つかるのですが、ソフトハウスを対象としたものは非常に少ないです。そのうちの一冊を入手したので、さっそく目を通してみました。会社の体制が違うことにより違和感はありますが、ソフトハウスを対象としているだけあって見慣れた言葉がよく出てきます。すでにISO9001認証取得した会社が実際に使用している品質マニュアルについての本ですので、「この本と同じ事すればISO認証は取れる」と分かり、勇気100倍です。
しかし、この本に習ってソフテックの品質マニュアルを作成していったところ、この本が第二の関門として立ちふさがって来たのです。
確かに出てくる言葉は馴染みのあるものが多いのですが、たとえばソフテックには営業部門はありません、品質管理部門もありません、営業部門、品質管理部門、技術部門の間で承認しあい、これをレビューや検証の代わりにすると言ってもソフテックではやりようがありません。また、この本を書いたソフトハウスはOA系の仕事をしているようで、FA系を中心としているソフテックとでは微妙にかみ合わない箇所がぽろぽろと見つかります。
OA系とFA系の差はともかく、体制の差はいかんともしがたいものです。
便宜上でいいから、営業部門、品質管理部門を作ってしまおうという案も出たのですが、実態は3部門の部門長が兼任されているという状態では、部門長間での承認は意味をなさず、ただISO認証取得のためだけの作業となってしまいます。ISO認証取得そのものが目的ではなく、「品質向上」、「文書作成の徹底」の手段としてISO認証取得を行おうというソフテックの目的と一致しなくなってしまいます。
また、ISO規約の項番毎に書かれているのではなく、各種規定や手続きなどを行えばISO規約はすべて網羅できているという作りのため、ソフテックの業務体制に沿って必要の無い規定や手続きを削除していくと、実はISO規約で求められている箇所まで削除してしまっていたりします。
そして、もうひとつ気になるのが、品質マニュアルがどんどん分厚くなっていくことです。
図を多用し、ISO規約の項番順でなく、業務の流れになるように書かれているため、わかりやすくはなっているのですが、かなりの分量です。作成している本人でさえ読みたくなくなってくるような・・・
そこで、審査をお願いしようとしている審査会社に相談したところ、「分かりやすくても分量の多い物は読まれない傾向にある」「細かく規定してしまうと、規定を守ろうとしようとするがために仕事が円滑に回らなくなる危険がある」と不安的中なお言葉。
読んでもらえない、業務も円滑に回らなくなってしまう品質マニュアルを長い時間かけ、さんざん悩み、考えながら作成しても全く意味がありません。作成すべき記録文書や、記録文書に記録する項目などは本を参考にしつつ、品質マニュアルの書き方自体はISO規約に肉付けして行く書き方に大幅に方向転換することにしました。
すでに作成した物を考えると、即決という訳にもいきませんでしたが、これにより第二関門を突破となったのです。
今回のメルマガで出てくる関門はどちらも品質マニュアル作成に際しての物です。しかし、本当の大関門は運用開始してから発生すると予想しています。内部監査実施やマネジメントレビューに際しても色々と出てきそうです。ついついISO認証取得のしやすさや、運用の簡易化に目が行ってしまいそうになる時もありますが、「品質向上」、「文書作成の徹底」を目的としたISO認証取得であることを肝に銘じて品質マニュアル策定を進めています。
図など一切なしの文字のみ、しかも長いメルマガとなってしまいましたが、ここまでおつきあいいただきありがとうございました。
(S.T.)
関連ページへのリンク
関連するソフテックだより