SQAの活用
List
SQAの役がプロセス改善の要
ここでは、「センターSQA」（以下、単にSQAと呼びます）の存在が、プロセス改善の要（かなめ）であるという私の考えについて説明します。必ずしも「CMM」で求められているSQAの活動と一致していないと思います。というよりも、私自身はそれをはるかに超えたものを求めているのです。（CMMIでは「PPQA」という呼称に変わっていますが、ここでは「SQA」で通します）
一般には「SQA」はプロジェクトに並行して、事前に取り決めたプロセスを実行しているかどうか、予定した成果物が手抜きなく作られているかどうかをチェック（監査？）するのが仕事と認識されているようです。そこでは、あらかじめ用意されている「チェックリスト」に沿ってチェックすればよいということで、必ずしもソフトウェアの設計や開発の経験を持っていないようです。もちろん、SQAの作業の中にはそうしたチェックリストに沿ってチェックすることも含まれますので、SQA組織の人が全員、ソフトウェアの設計や開発の経験を必要としません。SQAのプロセスに応じて分担すれば良いのですが、プロセスと成果物のチェックは、SQA活動のほんの一部に過ぎません。
もともと、プロジェクトに並行して、プロセスの区切りのところでプロセスと成果物を審査（監査と呼びたくない）するのは、チームのメンバーが、合理的に作られているプロセスを適切に実行していることを保証するために行うのですが、実際には、このプロセスはプロジェクト単位で要求に合うようにテーラリングされています。そこで最初の計画書の審査のところで、せっかく良く考えられた（悪くない）計画だったのですが、従来と比べて変化させたプロセスがあることで、それが実際の場で、事前に想定したように取り組めるかどうか不安があるのでチェックするのです。あるいは、今回のプロジェクトでは納期や機能の要求が厳しく、計画段階で一部の成果物を統合したりしてその納期の要求に対応するように考えたものの、注意しないと納期の強い圧力に負けて必要なプロセスを省きそうだというので、チェックするのです。
最初の計画段階で定義されているプロセスが実際の要求にマッチしておらず、成果物も特定されていないしサイズ見積もりも見当たらない、要件管理プロセスも確立していないような成功する見込みのないプロジェクトに対して、SQAが途中でプロセスと成果物を保証するための審査を行う意味はないのです。というよりも、そのようなプロジェクトを走らせてはいけないのです。
そのような“失敗する計画”しか持たないプロジェクトを事前に止めることができれば、実施が許可されたプロジェクトは、すべてSQAが事前に承認したプロジェクトであり、側面について支援する価値があるプロジェクトということになります。したがって、SQAにはプロジェクトを計画段階で止める権限を持つことが必要になります。失敗するプロジェクトのほとんどは、「計画」の段階で判断できます。そこでもう１ヶ月遅らせて、計画を練り直す方が被害は少ないし、場合によっては納期を含めて要求を実現することもできるのです。
もちろん、プロジェクトの計画段階で制止するには、その根拠と判断力と権限が求められます。ある意味では、プロジェクトを推進するよりも難しい仕事です。でも、成功するプロジェクトは、幾つかの条件を満たしていることが必要です。“頑張って”成功するものではありません。その条件は、実際のプロジェクトで合理的に成功をくり返してきたエンジニアには分かるはずですし、SQAの立場であればいろいろなプロジェクトを見る機会がありすので、その判断の根拠を明確にするための試験をすることは可能です。
このようなスキルをもったエンジニアは、一般には設計現場の長は手放しすことを拒むかもしれません。でも、現場にいれば“そこだけ”の成功しかもたらしません。それよりもSQAの立場に置くことで、全社の成功を誘導できる可能性があるのです。この意味で、SQAに“適任者”を確保することが、プロセス改善の要であり、組織のプロセス能力を引き上げる最重要テーマなのです。
SQAの４つの役割
私は、SQAに以下の「４つの役割」を求めています。
・ミツバチの役割
・ペースメーカーの役割
・ブレーキの役割
・コンサルタントの役割
以下に、これらの４つの役割について簡単に説明します。ミツバチの役割：
SQAは、プロジェクトの計画段階からプロジェクトに関係します。そのプロジェクトで要求されていることに対して、実現するための方法が考えられているかどうかを、計画の段階から見ることができます。一方、SQAは幾つものプロジェクトに並行し、プロセスと成果物を審査してきたなかで、「上手い方法」や「ベストプラクティス」ををたくさん目にしています。つまりSQAは、あちこちの花の「優れた花粉」をポケットにしまい込んでいるのです。
過去のSQA活動の中で手に入った「優れた花粉」の中から今回のプロジェクトに受粉できそうな花粉を、新しい花（プロジェクト）に受粉させるのです。もちろん、単純には受粉しないかも知れませんので、SQAの担当者が、“雌しべ”の形状にあうように調整したり、この花粉の元の持ち主をこのプロジェクトの関係者に引き合わせたり、早い時期にレクチャーをお願いすることもあります。
「ミツバチ」がこうして優れた花粉を配っていくことで、組織の中にこの花粉が行き渡るのです。いわゆる「水平展開」ができるのです。SQAこそ、水平展開を仕掛ける役であり、それはミツバチの役割が機能することが条件でもあるのです。別に言い方をすれば、この「水平展開」は、現場のリーダーでは実現しません。
ペースメーカーの役割：
これは心臓のペースメーカーをイメージしてください。プロセスの改善は、１回のプロジェクトで完成するわけではありません。一つの改善テーマも、１回の取り組みで望ましいレベルに到達するわけではありません。ある程度の効果をあげるレベルには届いたかも知れませんが、まだ望ましいレベルには届いていません。この取り組みのレベルを評価し、勇気を与えることでこのあとのプロジェクトでも継続して取り組む動機を与える必要があります。そうでないと、次回のプロジェクトで新しい取り組みのテーマが持ち上がったことで、今回の取り組みは置き去りに去れてしまいます。
ソフトウェアの開発ではゴールに至までには多くのプロセスが絡んでいます。問題を抱えている組織では、それらのほとんどのプロセスに改善が必要なのです。でも、実際に改善に取り組めるのは、初期のころではせいぜい１回のプロジェクトで２、3テーマです。したがって、こうした取り組みを継続しながら取り組むテーマを少しずつ増やしていく必要があります。
このとき、SQAがプロジェクトに並行することで、こうした取り組みの手を緩めないように励ますことができます。前回の取り組みでも効果が上がったことを感じさせ、まだ目指す頂上は見えない状態でも、「取り組んだ分だけ効果を感じる」ことができれば勇気がでてくるものです。SQAはこの勇気を与えることも重要な役目なのです。計画書を見れば、継続して取り組もうとしているかどうか分かります。
逆にいえば、こうしたペースメーカーの役を確保しなかった組織では、この種の取り組みは時間の経過とともに後退し消えていくはずです。それは、それぞれの組織の過去の事例が証明しているはずです。組織の責任者は、勇気をもってこうしたスキルの高い人をSQAとして確保することです。
ブレーキの役割：
プロジェクトを推進する組織には“ブレーキ”は与えられていません。彼等は“走る”ことしかできません。せいぜい、アクセルを踏む力を緩める程度です。彼等が手にしているハンドルもほとんど機能しません。それがソフトウェアの設計や開発組織の性質でもあります。
そのため、このままでは“まずい”と思っても、自らの意志でブレーキを踏めないのです。本来であれば、少し走るのを止めて、崩れそうになっている荷台の荷物を整理しなおせばよいのですが、ソフトウェアの設計や開発部隊にはそのような行為は許されていません。その結果、この先のちょっとした道路のでこぼこで荷物を崩してしまうのです。落とした荷物を拾い集めながら目的地に付いた時は、納期を５０％以上も遅延しているのです。その中で荷物を完全に崩してしまって立てなおせなくなったときは、プロジェクトは“止まる”のです。
大幅な遅れやそのような形で行き詰まってしまえば、当然大きな損失が生じますし、信用にも傷がつきます。エンジニアのモチベーションも間違いなく悪化しますので、この先のプロジェクトの編成にも支障を来します。つまり、このようなまずい計画のプロジェクトや途中で反れはじめたプロジェクトは“誰か”が一旦停止させなければならないのです。その役をこなせるのはSQAなのです。計画書を審査した結果ひどい時にはそこで制止し、プロジェクトの途中でプロセスと成果物の審査の結果によって制止するのです。通常は、計画の見直しであったり、再見積もりに基づいてリソースの配分を検討し直したりすることで再開できますが、場合によっては「中止」もありえます。
もちろん、SQAにはそれだけの権限を与えなければなりませんが、幸いにも、CMMではSQAの社内組織における位置は、プロジェクトを推進する組織から独立していて、むしろトップと直結する位置に置くことが勧められていますので、これを活用するのです。SQAは売り上げを上げませんが、損失を減らし、信用が傷付くのを防いでブランドを守る重要な役目を負っていますので、この位置にいることは適切なのです。
コンサルタントの役割：
これは、現場の問題を解決するために手助けすることを意味します。プロセス改善ということで、要求仕様の書き方を変えてみたものの、実際に要求仕様を書く段階になって、なかなか思ったように書けません。PFDを使ってプロセスを設計するのも簡単ではありません。レビューだって過去の習慣が邪魔をしますので簡単ではありません。事前にセミナーや説明を聞いただけではうまくいかないのです。
このとき、適切に指導できる人がいれば良いのですが、そのような人が身近なところにいなければ、勝手に解釈したりして本来の形から反れてしまいます。全部終わってから反れているということが分かったのでは、やる気を削いでしまいます。SQAの人は新しい花粉を持ち込んだのですから、そこで雌しべに確実に受粉するように支援しなければなりません。もちろん、SQAが全部支援できなくても、支援できる人を連れてくることでもかまいません。とにかく、SQAに相談すれば対応方法やそのヒントがもらえたりすることが大事なのです。ある意味ではSQAは「駆け込み寺」でもあるのです。その寺に行って、話を聞いて元気になって戻っていくのです。
このようにSQAにコンサルタントの役割を持たせなければ、プロセスの改善も進行しません。水平展開を誘導して組織のプロセス能力を引き上げることも捗りません。
ーーー
上にあげた「４つの役割」には、いわゆる「CMM」の枠から少しははみだしているものがあります。というよりも、CMMの表面の文字を拾っているだけでは、こうした役割は見えないかもしれません。でも、ミツバチの役割は、ベストプラクティスを収集するために必要になりますし、計画書を審査する以上、そのプロジェクトに“優れた花粉”をつけるのは当然です。まずい計画を最初から走らせないことや、承認したプロジェクトであっても途中で当初の計画から大きく反れは次めたプロジェクトにブレーキを掛けるのも当然です。それができないのであれば、計画書の段階で参加する意味はありませんし、“保証”のために途中でプロセスや成果物を「Audit」する意味もありません。このように、CMMを読む角度によって、これらの役割が求められることは見えてきます。決してCMMから外れているわけではないと考えています。
そして現場は「Audit」（だけ）を求めているのではなく、目の前の問題にどのように対応すればよいのか、その方法（解決方法）を求めているのであり、そのための相談相手を求めているのです。「Audit」は、そうして工夫を積み重ねて成功事例を積み上げてきたチームや組織が、CMMというフレームワークの中で自分達はどのような位置にあるのかを確認するためのものです。その意味でも、SQAに「コンサルタント」の機能を持たせることを勧めているのです。
一般には、コンサルタントの役割は「SEPG」の仕事と思われているかも知れません。でも、プロジェクトと最初から接し、プロジェクトと並行して走っているのはSQAです。途中でうまく走れたかどうか、外れた部分の影響を回避するためにこの先のプロセスを修正して対応することを勧める必要があるのですが、プロジェクトの事情を知っているのはSQAです。個別に“問題”を解決するために「SEPG」を呼んで相談しても、うまく機能するものではありません。SQAの中にSEPGの機能を持たせることでこれらの事態に対応できるのです。
SQAがSEのスキルを把握しよう
SEのスキルを引き上げるということで、政府主導でITSSやETSSという基準が制定されたのときっかけに、それぞれの組織でスキルを引き上げるための取り組みや個人の評価に動き出したようです。中には「人事部門」が主導するかたちで動いている組織も見受けられます。このこと自体は基本的には間違った行動ではないのですが、未熟な組織においていきなり「人事部門」が動くことには大きな危険が伴います。
今まで、SEがスキルの向上に取り組まなかった責任の一端は組織にもあって、すべてを個人の責任に帰すことはできません。不十分なスキルを承知で採用したのだし、採用後の初期教育の内容も不十分です。何よりも、実際の業務の中では結果しか問わなかったために、いつまでたっても上手くできる方法やプロセスが身に付かず、毎日の中で勉強する時間も確保できないままに毎日を過ごすことになったのは事実です。結局「知識労働者」のスタイルを身につける機会を持てないまま日々の業務の中に疲弊して埋没しているのです。
そこで、これではいけないと言うことで、スキル標準が作られて、「この役割の人は、ここまでできなければならない」というハードルが設定されるのは良いのですが、それを最初から人事部門が主導することで個人の評価に使われるとこに対する不安が生じます。現実のプロジェクトをこなしながらSEとしてのスキルを引き上げることは簡単な話ではありません。毎晩、土日休日のすべての“持ち時間”を投入しても数年かかります。いや、数年でも必要なスキルの半分しか手に入らないでしょう。そこまでそのスタイルを維持できる人は１０％いるかどうか。もっと、全体のレベルが上がったところで人事部門が動くことはかまわないのですが、動きが早すぎると、多くの人がスキル標準に対して「やり過ごし」の行動を起こす危険が生じます。
人事部門が直接動くことのもう一つの問題は、組織によって現場の事情はさまざまです。個々の企業文化もSEの行動や思考を拘束することがあります。また実際のプロジェクトの事情も単純ではありません。現実問題として、どのグループにはどのようなスキルが優先するかと言うことも、現場によって違っています。現場はつねに変化する「要求」と「納期」のある仕事をしています。そのような事情は人事部門では見えない可能性があるため、画一的な要求を出してしまう可能性があるのです。
そこで私は、現場のSEのスキルはSQAの組織が把握することを勧めています。スキルの判断は少なくとも２段階に分れます。
第１段階・・「知っている」
第２段階・・「それを適切に活用できる」
というレベルです。「知っている」というのは、社内で実施するセミナーなどの出席記録や、外部のセミナーに参加した記録から把握できます。さらには本人の申請も受け入れても良いでしょう。そしてこのようなデータを「センターSQA」の中に集めるのです。問題は「適切に活用できる」というレベルの判定ですが、SQAはプロジェクトを側面から見ています。プロセスの進め方やそこで生成された成果物を審査するのですから、個々の担当者がどのようなスキルを持っているか分かります。また必要なら「活用できる」という評価をもう少し細かく分けることもできるでしょう。
さらに、プロジェクトの終了時点で、プロジェクト・リーダーなどから、今回のプロジェクトの中で、メンバーの誰が「活用できる」レベルに達しているということで「スキル申請」をSQAに提出する方法も取り入れるとよいでしょう。SQAはこの申請に基づいて、実際の作業結果を検証することで申請を判断できます。SQAは、第3者的な立場で実際のプロジェクトに属していません。しかもソフトウェアの開発に十分なスキルをもっていればスキルを評価することができます。
SQAがスキルを把握することのメリットには、プロジェクトの最初に「計画書」を審査する際に、保有するスキルデータを照会することで構成メンバーのスキルを確認することができます。もちろん、事前にプロジェクト・リーダーから予定されているメンバーのスキルの状態を問い合わせることもできますが、現実問題として、いつも“欲しい人”でチームを構成できるとは限りません。SQAが手許にあるスキルデータと照合することで、プロジェクトにおけるスキルの偏りや不足する部分が分かりますので、適切なトレーニング計画をアドバイスすることもできます。
また、SQAは社内のプロジェクトに並行して動いてるのと、全員のスキルデータを持っていることで、不足しているスキルについてトレーニングをコーチできる人がどこにいるか知っています。さらに、普段の対外活動によって外部の情報も持っていますので、社内に適任者がいないテーマについては外から呼ぶこともできます。もちろん、そこにはSQA組織としての独立した予算が必要ですが、SQAが動くことでプロジェクトの予算を使わないで済むのと、他のグループにも声を掛けることでコスト効果を上げることができます。
さらに、SQAが全員のスキルデータを持つことで、組織としてのスキルの偏りや不足するスキルが見えますので、中長期のレンジで組織単位でスキルアップのプランを立てることもできます。また、SQAは常に現場の中で行動していますので、将来的に必要なスキルや新しい技術の動向も見えます。それらの技術が自分達の組織の中でどの程度有効なのかということも、現場のリーダーと一緒に考えることもできますので、新入社員のソフトウェア教育のカリキュラムにも反映させることができます。
ただし、SQA部門がこのような役割をこなすには、プロジェクトを何度も無理なく成功させた経験を持つ人、技術的にスキルの高い人を確保することが大事ですが、逆にいえば、「SQA」という役割を組織のキャリアアップ・プランとして確立することもできます。組織のトップにこの決断ができるかどうかです。
利益を上げる組織
ソフトウェアの設計部門や開発部門は売り上げを上げる組織ですが、そこでのプロセスが不適切な状態のままでは、仕様変更の混乱やバグの頻発でエンジニアは疲弊します。それだけではなく、プログラムの中にはバグが残ったまま客先に提供されたり、製品となって市場にでることになります。その結果、後になって損失が発生するのです。
確かに、売り上げを上げる組織は重要です。でも、その設計部門のプロセスが一向に改善されないために、あとで大きな損失を出しているのです。設計部門の上級のマネージャーは、締日までに製品を出荷することに追われていて、プロセスを改善することのの意味が理解されていなかったり、問題の原因に対する認識がズレていることも少なくありません。そこでは、プロセスの改善に取り掛かれば、今まで以上に工数が増えてしまう、と考えられています。最初に出荷の期日が決められている以上、プロセスの改善よりも納期限を優先するのが当然という論法がまかり通るのです。
そこで行われているプロセスの拙さが、無駄な工数を費やしていることに気付いていないし、気付こうともしていません。なぜなら、このマネージャーも、ソフトウェア設計あがりで、現役時代に何度か状況改善（当時は“プロセス改善”という概念はなかった）しようと試みたのですが、すべて失敗し、結局は元の鞘に収まった経験があるのです。もちろん、失敗の原因は究明されていません。
このようなマネージャーの中には、要求の仕様化やプロセス改善の効果を信じていない人もいます。仕様を書いても、クラス図や構造図を書いても「１行のソースコードも出て来ない」と言う考えから、要求の仕様化や設計のプロセスはそこそこに終えて、少しでも早く実装プロセスに入ろうとします。細かな仕様はソースコードを書きながら織り込んでいけばよいと言う考えです。極端なケースは、テストしながら仕様を足していけば良い、という人もいます。もちろん、この方法では何度もソースコードの書き直しをすることになりますが、その工数は当然の工数という位置づけになっています。したがって、このようなプロセスでは後の工程で仕様の調整などで大きな手戻りが発生しますので、最初から期限を達成することは困難なのです。だからこそ、“余計なこと”に手を出さないのかもしれません。その結果、コーディングに着手するのが早過ぎるのですが、このマネージャーの認識は全く逆で、まだ遅すぎたのだと思っている（思い込んでいる）のです。
こういう状況では何も解決しません。それだけでなく、現場のエンジニアは疲弊し、有能なエンジニアは辞めていくか、思考を停止させてマネージャーの言うことにしたがう“振り”をして、持ち時間を投入して頑張るのです。この“振り”を数年続けると、本当に使い物にならなくなります。もちろん製品にはバグが残っていますので市場で叩かれます。そうなってから慌てて、回収するか、改定版のソフトを用意してダウンロードさせるのですが、ここで大きな損失が発生します。場合によっては、市場から「総スカン」を食らって、ブランドを大きく傷つけることになるのです。多くの場合、このまま出荷しても市場でトラブルが発症することは分かっていたのです。少なくとも、胸を張って市場に出していないのですから。多くの組織には、こうした無謀な行動を止める“仕組み”が無いか、機能していません。それは、この部門こそ、売り上げを上げる組織だからです。
たとえ売り上げを上げる組織だとしても、このような設計部門の暴走を食い止めなければ企業は成り立たなくなります。それが「インターネットの時代」なのです。この設計部門の行動を規制することができるのは「SQA（註１）」しかありません。「SQA」がプロセスを無視したプロジェクトの進行を停止させるのです。私は、「SQA」に「損失の発生を食い止める」あるいは「利益を上げる」という使命を与えることを勧めています。設計部門が売り上げを上げても、その何倍もの損失が発生したのでは無意味です。いや、無意味で済めば良いほうです。場合によってはビジネスの機会を失うことも有り得るのです。
一番望ましい姿は、設計部門と「SQA」が連携することです。「SQA」の人たちは、設計部門の人たちが無駄な工数が発生しないような合理的なプロセスが設計出来るように指導（註２）し、事前のシミュレーションを指導するのです。その上で、実際に事前に考えたプロセスから外れているときは、ブレーキをかけたりハンドルを調整したりするのです。
設計部門には「アクセル」しかなく「ブレーキ」は与えられていません。そのブレーキを「SQA」に与えよというのが私の考え方です。したがって、このブレーキは、アクセルよりも“強い”制動力を持っていなければなりません。これは、日本の多くの組織にとってはとても大きな課題です。でも、時間をかけてでも、こうした制動力を与えられる「SQA」（の組織）を確保する必要があります。
こうした「SQA」との連携によって、当初の売り上げが得られると同時に、損失を最小限に抑えることが出来るのです。この結果、「SQA」は“利益を上げる”組織ということになります。それだけに、「SQA」には信頼のおける優れた人材を確保することが大事なのです。売り上げを上げる組織のマネージャーと対等に向き合わなければなりません。ずさんな計画であれば、計画をストップさせなければなりません。途中でも計画の見直しを求めなければなりません。マネージャーのメンツだけでプロジェクトを走らせるわけには行かないのです。組織の将来を考えると、そこで設計作業に取り掛かる多くのエンジニアに「良い経験」を積ませることも重要なのです。だから、まずい計画であればそれを制止しなければなりません。
トップが、本気でその企業組織を通じて社会に貢献し続けることを考えるのであれば、その姿勢は「SQA」の組織の位置づけや、「SQA」の人選に現れても良い、というのが私の考えです。
註１：CMM!では、PPQAと呼称が変わっていますが、このホームページでは基本的に「ソフトウェア」を対象にしていますので、「SQA」の呼称を使用します。また、CMMのSQAでは、ここに挙げるような役割を与えていません。これは私の従来からの考え方であって、CMMの中の「SQA」が適任ということで提案しているものです。
註２：こうした役割は、CMM的には「SEPG」の分担となるかもしれませんが、プロジェクトに並行して走るのはSQAの方ですので、これくらいの役はSQAで対応すればよい、というのが私の考えです。第一、その後のSQAミーティングでプロセスの遵守をチェックするのですから、最初に指導した人が見た方が効率的です。CMMにこだわる必要はなく、効果の上がる方法を選べばよいと考えています。