品質とコストのはなし

皆さん、こんにちは。

8月に入ってからの連続の雨記録…鬱陶しいですよね…。
まぁ、暑いのもイヤなんですけど、今週半ばくらいからは、天気が良く、気温も上がるらしいので、これから夏を満喫なのかなぁ…と。

さて、今回は、品質とコストのはなしです。

ソフトウェア開発での原価って?

まずは、コストのお話を…。
ソフトウェア開発企業に限らず、企業が経済活動を行う上で管理すべき要素として売上原価利益の3つがあるわけですが、その3つの要素の間には、以下のような式が成り立ちますよね。

売上 - 原価 = 利益

売上よりも原価が高ければ、利益はマイナスになりますし、逆に原価が低ければ、利益はプラスになります。で、営利企業としては、利益をプラスにしなきゃいけないので、この利益を増やすためにどうすりゃいいの?と皆さん頭を悩ますことになりますが、売上を増やすか、原価(コスト)を減らすしかないよねってことになります。
売上を増やすことは、まぁ、頑張り次第ではあるものの、ここでは、一定の売上があるものとしましょう。で、その売上が製品(ソフトウェア含む)である場合、これは、お客さまとの間での交渉次第となるので、色んな状況の変化に左右されちゃうので、結構難しい…。
だけど、原価を減らすのは、自分たちの努力次第でどうにかなりそうなんで、原価を減らす(下げる)ことを考えることが多いですよね。

この原価についてですが、もうちょいかみ砕くと、直接費である労務費、外注費、経費の他に、間接費である間接労務費(各プロジェクト開発に直接関与しない人件費や間接部門の人件費のことね)や共通費(家賃とか、水道光熱費とかね)なんかがある訳ですが、ソフトウェア開発の場合には、圧倒的に労務費や外注費といった人件費が、原価の多くを占めることが多いと思います。

作る人、作らない人

ソフトウェア開発では、この人件費(ちょっと間接費は除いて考えると)、ざっくり分けて、作る人作らない人の2通りの人たちが存在している訳ですが、ここで、テストエンジニアなど品質を確認する人たちは、どちらに当てはめるかってはなしです。

通常のソフトウェア開発プロジェクトでのチーム構成としては、こんな感じが多いと思います。(あくまで一例ね、規模によっても全然違いますし、こんな規模なんて稀だよというもの多いので)

この中で、少なくともマネージャやリーダー(色のついている人たち)は、一般的には、管理する人という位置づけで、作らない人であり、プログラマは、作る人になりますよね。もちろん、マネージャやリーダーでも、プレイングマネージャとしてプログラマを兼ねている場合などには、作る人ですけどね。
この「作る」、「作らない」という言葉に対する主語は、成果物(納品物)であるプログラムを指しています。

ということで、問題のテストエンジニアをどちらに含めるのか…。

ここをちゃんと考えていきましょう。

生産性も気になる訳ですよ

結論に行く前に、原価を下げるために、生産性の話になることも多いと思いますが、この生産性とは、三省堂大辞林 第三版では、以下のように定義されています。

生産のために投入される労働・資本などの生産要素が生産に貢献する程度。
生産量を生産要素の投入量で割った値で表す。

例えば、100のものを作るとして、1人で100を作ることが出来れば、生産性は100であり、2人で作れば、生産性は50と、一人当たりの生産性には、2倍の差があることになります。つまり、生産性が上がるということは、生産量が増えることになりますので、必然的に原価を下げることに繋がるという意味で、この生産性を重視することになります。

ソフトウェア開発の現場における作る人に対しては、もの(プログラム)を作っているので、生産性を上げるということが分かりやすいのですが、作らない人は、ものを作るわけではないので「生産性がない」と思われがちです。ところが、作らない人たちにも、当然のことながらやるべき役割があります(役割については、ここでは書かないですけどね…)。しかも、その役割の人たちがいることによって、作る人の生産性を高めることに寄与しているはずです(というか、寄与せずに邪魔するだけの作らない人は要らない人かと…)。

では、テストエンジニアはどうでしょう?
テストエンジニアとしての成果物としては、テスト(試験)仕様書やテスト(試験)結果報告書などが挙げられ、そのための作業として、テスト仕様を考えたり、テスト環境を構築したり、テストを実施したり、バグを見つけたり、それを報告したりと役割としてやるべき作業はたくさんありますが、その見つかったバグを修正すること自体は、テストエンジニアの作業ではありません。このため、最終的な成果物であるプログラムを作る人ではないということになりますよね。

でも、よーく考えてみて欲しいのです。

ここで品質についても考えてみる

ISO9000(JIS Q 9000)(品質マネジメントシステム―基本及び用語)では、品質を、以下のように定義しています。

本来備わっている特性の集まりが、要求事項を満たす程度
注記1 用語“品質”は悪い、良い、優れたなどの形容と共に使われることがある
注記2 “本来備わっている”とは、“付与された“とは異なり、そのものが存在している限り持っている特性を意味する

この定義の中には、特性と要求事項という用語が使われていますが、これらの用語の意味は、以下のとおりです。

用語内容
特性そのものを識別するための性質
要求事項明示されている、通常、暗黙のうちに了解されている若しくは義務として要求されているニーズ又は期待

この定義の中には、「何を」と「誰の」いうのがありませんが、これは、それぞれ「製品やサービス」、「(基本的には)利用者(ユーザー、顧客)」と考えるべきでしょう。
要するに、品質とは、

製品やサービスを使う利用者が、その製品やサービスに対して持っているニーズや期待に応える程度

のことと言えるのではないかと…。

何で品質の話をしたかというと、ソフトウェア開発において作り出す製品(ソフトウェア)の中には、そもそも、この品質が含まれていなければいけないということなんです。当然のことながら、製品によっての程度の差こそあれ、利用者は、この品質も含めて製品として認識しているので、ソフトウェアの品質を確保する必要があるということなのです。

品質は、製品の一部である

ということは、十分に認識してほしいなぁ…と思っている次第です。

テストエンジニアはどうなのよ?

で、テストエンジニアの話に戻ると…。

前述したとおり、テストエンジニアは、作る人ではありません。
作る人ではないのですが、製品(ソフトウェア)に必ず必要とされる品質を確保するための元になる作業を行う人です。このため、ソフトウェアを作るためには、必ず必要な人であることは認識しておく必要があります。もちろん、このテストエンジニアと同等の作業を開発エンジニアが行うこともあり得ます。しかし、規模によっては、この兼務は出来ないものも当然のことながら存在しています。通常、開発エンジニアが行うテストの範囲としては、単体テスト(一部、結合テスト)といった感じ。全体を通した結合テストや総合テストといった、よりユーザーに近い視点における試験は、なかなか行うことは出来ません。なので、担当する範囲も異なることから、見つけきれないバグが流出してしまう可能性は必ずあるからです(もちろん、規模によりです)。

で、よくプロジェクトの予算が取れないから、作らない人を削減しようという話を聞くことがあります。
しかし、本当に不要なのかは、よーーーく考えてみて欲しいのです。
その製品は、どの程度の品質がないといけないのかは重要な要素であり、そこを十分に検討した上で、削減をして欲しいと思っています。

さらには、品質を確保するという作業は、プロジェクト単位ではあるものの、会社としての取組みだとも思っています。

何故かというと、プロジェクトに張り付けた予算の組み立て方では、どうしても人員を削減せざると得ない場合があると思うんですが、会社の戦略的に、予算が少ない中でも、絶対的に失敗が出来ないプロジェクトや顧客との関係性から多少無理をしてでも品質を高める必要があるプロジェクトなども存在しているはずで、その場合に、プロジェクト単位では、人員を割り当てることが出来ないこともあります。このため、テストエンジニアを始めとする品質保証部隊やテストチームなどは、全社的な視点で予算を割り振ることを検討しても良いのではないかと思っています。

品質向上とコスト削減の両立って

よく製品やサービスを消費者の視点で見た場合、一般的に、品質が高いものは価格も高く、反対に品質が低いものは価格も安い傾向にあります(あくまでも一般的な話ね)。これを企業側から見ると、品質を高めると、原価(コスト)が上がり、逆に品質を下げれば、コストは下がるということになります。

製品やサービスを良くするためにはコストがかかるので、そのコストを削ろうとすると製品やサービスの質も落ちざるを得ない…。多くの経営者やプロジェクトマネージャなど、製品やサービスを提供している人たちは、この品質とコストのトレードオフの関係に悩んでいるといっても過言ではないでしょう。
が、「利用者に見つからなければいいじゃん!」という意識が働くことで、安易なコストカットに走ることはないでしょうかね?

品質を維持や改善するためのコストのことを品質コストと呼びます。で、その品質コストを適切に管理手法として、品質コストマネジメントなるものがあります。この品質コストマネジメントは、利用者にとって価値を有する部分には重点的にコストをかけ、一方で、利用者にとって価値をもたらさない部分のコストは大胆に削減していくことによって、品質向上とコスト削減の両立を目指すものです。

品質コストマネジメントで、管理される品質コストは以下の4種類に分けられています。

予防コスト品質上の欠陥が発生するのを早い段階から防止するための原価
(例:品質管理、工程管理、品質計画、トレーニングなど)
評価コスト製品や部品の品質を評価して品質レベルを維持するための原価
(例:ソフトウェアテスト、出荷前テスト、受入試験など)
内部失敗コスト品質問題が製品出荷前に発見された場合の処理に関する損失
(例:再テスト(修正含む)、材料(資材)調達など)
外部失敗コスト品質問題が市場で発生した場合の対応や処理に関する損失
(例:クレーム処理、製品回収・リコール、不買運動など)

まぁ、品質コストマネジメントの話は、別途、ブログに書きたいと思いますが、とりあえずは、これらの品質コストに対し、どこまで何をやるのか…それを考えていかなきゃいけないって話ですね。

ちなみになんですが、有名なジム・コリンズさんのビジョナリー・カンパニーでは、以下のような言葉が出てきます。

「ORの抑圧」をはねのけ、「ANDの才能」を活かす

膨大な企業データから、時代を超えて繁栄し続ける偉大な会社は、ANDの才能を持つことが分かっているらしい。品質とコストといった異なる目的を、同時に実現するために行動している企業は、持続成長しているって話です。また、ORの抑圧が、企業活動の中で横行していくと、あまり良い会社にはなっていないといった研究結果が出ているとのこと。つまり、品質の維持・向上を図りながら、相反する何かを獲得すること(あるいは、しようと目標を掲げて取り組んでいること)が、重要な競争優位の要素であると考えることが出来るかも知れないですね。

ということで、有名なジム・コリンズさんのビジョナリー・カンパニーは、こちらです。これは、第1巻で、第4巻まであります。

第1巻~第4巻+特別版のセット販売のもあるのね…。

関連記事

  1. ただいま診断中

    健康診断は受けましょうね

  2. ベトナムでのソフトウェア開発

  3. 改正個人情報保護法をあらためておさらいしとくPart1

  4. 視点のはなし

  5. テストとゴミ拾いのはなし

  6. 人生ゲーム風ルーレット

    PowerPointで人生ゲーム風ルーレットを作った話

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。