第2回は、ソフトウェア品質技術者について書く前に、ソフトウェア技術者に原稿を割いてしまった。ソフトウェア開発技術者としてスタートし、プロジェクト内で様々な問題に直面し、問題が品質に関連することが多いということに気がついたとすれば、あなたは、ソフトウェア品質技術者としての一歩を踏み出したことになるが、こういうケースの人はまだ良い。意識を持たないままにソフトウェア品質技術者の仲間入りをしてしまった場合から考えてみよう。

第1回で述べた色々な形態の組織の中で、典型的な最初の2つの組織形態に配属された、ソフトウェア製品またはお客様向けのシステム開発でのソフトウェアの品質保証に直接携わる新入り（新人とは限らない）メンバがどのように成長していくかについて考えてみたい。

1. 社内第3者検証型組織の場合

この組織では、全く開発経験の無いメンバが組織に入ってくることは、新人社員以外には、まず考えられない。途中入社や人事異動組のように経験も意識もあるメンバは特に問題は無いので、新入社員をどう育成していくかが最大の課題であろう。

ここでは、開発チームと品質保証チームが一緒になってプロジェクトを組んでいる。開発チームは、自分たちなりの開発作業の中で、開発標準、チェックリスト、内部レビュー、コーディング規約、デバッグなど品質を考えつつ作業を行っている。品質保証チームは、各工程で、公式レビュー、品質チームとしてのテスト、評価を実施する。

新入社員なら、品質保証担当として配属される前に、社内での基礎的な教育訓練は受け、部門内での必要な説明も受けているだろう。しかし、ソフトウェア開発の経験はなく、お客様とも接したことがなく、ソフトウェアを作成する訓練があっても、せいぜい演習プログラム程度だろう。実際の仕事は、先輩社員と組んで、経験を積んで行くことになる。しかし、ソフトウェア品質技術者のお手本が身近にあることは大変望ましいことである。しかし、一番問題なのは、お客様向けソフトウェアの開発経験が全く無いという点である。開発部門に預かってもらって開発の修行をするか、部門内で開発ツールや管理ツールなどの開発を経験させるなど、ソフトウェア作成を身を以って体験しておくことが必要である。

開発部門が開発した設計文書の検査をする、設計文書からテスト項目を検討、実施し、結果の評価を自ら行うのが彼らの仕事である。実践の中で、少しの失敗を積み重ねながら経験を積んでいくのが一般的だろう。部内での定期的な研修が必要であるが、彼らを鍛えてくれるのは、逆に開発部門の厳しい目である。開発部門と品質保証部門が組織的に独立していると、常に軋轢がある。最終的にはお客様に品質を保証する役目を負っているので、お客様からの目も厳しいのは当然である。

私作る人、私チェックする人というように簡単に分けられるものだろうか。開発技術者から見ると、業務的な背景も知らずにレビューなんか出来るか、客観的なテストだといっているが、使われ方を知っているのは開発側だ。自分たちがテストをするのが一番良いのだ。お客様の前に出すソフトウェアを作ったことも無い品質技術者にとやかく言われたくない、などというところから対立関係が生まれる事もある。いっそのこと会社が異なれば、会社対会社の契約上の問題と割り切ることが出来るが、社内の組織間の対立は、兄弟喧嘩の様相を持っているので、深刻になる。品質の知識、技術を持たないソフトウェア開発技術者は困りものだし、開発技術、対象業務のことを理解できていないソフトウェア品質技術者も困りものである。こういう人たちが出会うと対立関係しか生まれない。これでは、良いソフトウェアを生み出すことは出来ないだろう。

同種のソフトウェアの品質保証を担当することで、使われ方、業務にも精通できるようになることが望まれる。

2. プロジェクト内検証型組織の場合

この組織では、ソフトウェア品質技術者に関する新人問題は大きくはない。新人は、品質関連部門ではなく、まずはソフトウェア開発の仕事から始める。開発の仕事の中で品質の重要性に気づかせることは必要である。小さなグループでソフトウェアを開発し、自分でテストし、自分で評価するから、品質に関する知識・技術力も必須項目である。しかし、開発すること、すなわち、業務知識やプログラミング技術、プログラミングの面白さだけに傾くと、品質面がおろそかになる傾向がある。技術･業務偏重になってしまう。開発者は、自分が作ったソフトウェアにはバグなどは無いと思い込む。内部者だけでレビューを実施すると、長い間積み重ねた蓄積がありすぎて、このグループでの常識のようなものが邪魔をして、意外に間違いが発見しにくい。そのためには、同種プロジェクトまたは、類似プロジェクト経験のあるメンバを入れたレビューを行った方がよい。これで、当たり前と思った間違いを気づかせてもらえれば大変な収穫である。したがって、開発のグループリーダが、品質の重要性をつねに云い続けることが必要である。納期優先を強く云っていると、品質を忘れてしまう。

1つ1つのプロジェクトが比較的大きく、同種プロジェクトがない場合には、特に、自分たちのプロジェクトは他に類を見ず特別であるという思いに駆られやすい。業務的にはそういう面はあるだろうが、それでも、同じようなパターンの処理があるはずである。

この組織での品質グループの仕事は、プロジェクト内の品質目標を立て、開発担当者に品質を意識した仕事をさせること、異常な状況、問題事象をはやめに発見し対策することである。これには、開発経験が豊富で、各開発チームのことを良く理解できている人が行うと効果がある。しかし、そういう人がいれば、設計・開発グループで直積的な仕事をして欲しいほど、手不足なことが多い。よくあるケースでは、開発グループでうまくいかなかった人を当てている企業も多い。開発グループでうまく行かなかったとしても、少なくとも品質に問題意識を持っていてほしい。

プロジェクト内の品質グループの仕事は、プロジェクトマネージャの品質マネジメントの仕事を代行していると考えたほうがよい。もし、数人の小さなプロジェクトなら、品質に関しても（もちろん納期、コストも）PMが自ら目を光らせていなければならないのは当然である。品質担当は、開発の品質計画、レビューのマネジメントすなわち、計画･実施状況チェック・再レビュー・修正確認・評価まで、各開発フェーズでのテストマネジメントとして計画・準備・実施状況チェック・評価などを指揮する。最終的には、サービス開始可能かどうかをPMが最終判断する助けをする。

3. ソフトウェア品質技術者の育成

これまでに、2つの組織のスタイルについて述べてきたが、さらに、ソフトウェア品質技術者が大きく伸びるには何が必要だろうか？

必要なことは、自分がどういう位置にいるかを理解し、不足するところを補うことである。“己の足らざるを知る”とでもいえばよいだろう。そのために行うべきことは、これまでの経験をいかに生かすか、特に、品質問題原因分析、失敗の分析をしておくと良いだろう。また、自ら考えたことを、論文にまとめる癖をつけ、社内だけでなく、社外でも発表をすると自分の頭の整理が出来る。また、社外講師を頼まれるようになれば、本物である。さらには、本を書くという道もあるだろう。

また、このソフトウェア技術の世界には、“銀の弾丸はない”という言葉は、正しいと思っている。例えば、“新しい手法で生産性を2倍に上げた”というようなおいしい話にすぐ飛びついてはいけない。なぜ、そのやり方に妥当性はあるか？適用領域は？何か犠牲にしていることはないか？といったことを考えることが出来るようになってほしい。

下記に、自分をレベルアップさせる道について、小生が考えつくものを列挙しておいた。

1. ① 自分で勉強：自らへの投資
   1. 書物、雑誌からの勉強　QCツール、確率・統計など、専門雑誌
   2. 社内研修受講
   3. 社外セミナ参加
   4. 学会への参加
2. ② 世の中と自社との比較
   1. 社外の勉強会参加
   2. 学会、研究会･シンポジュウム出席
   3. 検定試験
3. ③ 他社との交流
   1. 外部講師による社内セミナの企画
   2. 先進企業の研究
4. ④ 論文にまとめる、本を書く
   1. 外部講師による社内セミナの企画
   2. 先進企業の研究
5. ⑤ 社内研修、外部セミナの講師を務める
   1. 社内研修や外部セミナの講師の話が来たら、少々自信が無くとも断ってはいけない。
   2. 人様に話をすることは、自分の経験、頭を整理するのに良い機会である。
6. ⑥ 他人（部下）から吸収
   1. ある程度年齢を重ねると、新しい技術を自ら試すことは難しい。
   2. 部下に勉強またはチャレンジさせて判断する。基本的な事を理解していれば、新しいことにも対応できる。
7. ⑦ 勘を養う
   1. KKD（勘と経験と度胸）だけではこまるが、実はKKDは必要である。むしろ、KKDだけではいけないというべきである。