見出し画像

品質を以って差別化できる企業が一番強い

Takashi Suda / かんた

世の中にあふれているニーズ…需要量が一定であると仮定して、そのなかでのIT企業の成長を考えた時、当然その１つに

　『差別化戦略』

が頭をよぎる人も多いと思います。

でもそれを単純な技術力（テクノロジー）による差別化で達成できると考えるとだいたい失敗する。よほど突出していないとまず無理。ほんの一握りだけ。

少なくともＢ２Ｂのソフトウェア開発を生業とする企業の場合、社会に存在する需要が一定である以上、そこから世の中にたくさん存在するＩＴ企業の受注合戦となるわけで、その争いに勝って受注率…仕事の分配率の向上を考えないといけない。この大前提に立った時、

ＩＴ企業は顧客に対し

　「純粋な技術力」をアピールして受注しようとするか

顧客は

　「最新の技術」が使えると聞いて信用するのか

という観点がごっそり抜けている気がします。確かに顧客のニーズを満たすうえで最新技術を駆使しなければならないケースもあるので、そういった領域の顧客開拓を視野に入れているのであれば「技術」という観点も悪くないかもしれません。

ですが、そんな企業はごくわずかです。

また存在しても、潤沢な開発資金はそうそうないはずです。あるとしたら相当な大企業が顧客となるケースだけでしょう。またその大企業が製造業を生業としていたら最新技術の早期利用なんて（品質的にも）怖くて、おそらくＰｏＣのような小規模開発が中心となっているのではないでしょうか。大量生産してしまってから事後が起きて、リコールなんてことになったら事業の存続にも影響を及ぼしますしね。

少なくとも私が発注側の経営者だったらそうすると思います。

決して技術力を侮っているわけではなくて、それ以前に"絶対的に必要とする観点"があるからです。その観点の条件を満たすことないまま他の部分が優れていても、それを以って

　「当社は他社と比べて差別化できる強みがあります！」

と言われても琴線には響きません。「それで？御社の提案を真に受けたとして、それでその技術に品質上の問題があった時、あなたがた自らの提案に責任を負えるのですか？」と聞くかもしれません。

本当に差別化するなら

そう、先にも言った"絶対的に必要とする観点"とはすなわち「品質」のことを指します。

品質は、ビジネスにおいて言い換えれば「信用」です。これまで積み上げてきた結果、成果が提供する「信用するための基準」と言ってもいいでしょう。顧客側の需要を満たすうえで必要な技術を駆使し、製品やサービスを提供する…というのはもちろんですが、それは

　品質に裏付けされた製品やサービス

であることが大前提なのです。

Ｂ２Ｂであればなおさらです。相手も企業です。提供した製品やサービスは事業の中で活用されることになります。そう、私たちＩＴ企業が提供する製品やサービスで「売上」「利益」「経費」などをコントロールするわけです。年間何百万、何千万、何億という数字に影響を与えることになるでしょう。

だからこそ、軽微か軽微でないかに関わらず「粗悪な品質」の製品やサービスを世に送り出すことはタブーとされています。

Ｂ２ＢのＩＴは社会的な責任が非常に重いのです。
（だからこそやりがいもあるわけですけど）

ゆえに

　品質

において他社を圧倒する優位性を築けないと、何をやっても差別化戦略は有効に機能しません。少なくとも私はそう思っています。

たとえばコンペで複数社に提案依頼をお願いしている状況だとします。一応、依頼する以上はどの企業も「実現可能な技術力を持っている」ことが前提で選出しています。この時点でよほどのことが無い限り技術的な差別化は不可能です。すると、あとは

　「価格」
　「ニーズの実現度」
　「提案の実現性」そして
　「信用」

です。「この企業に任せると不安」「口コミでも評判悪いし」…と思わせないためには

　「トラブルを起こさない」
　「品質の悪いものを世に出さない」

基本この２点です。さらに落としこめば

　「要件が確定するまでの（コミュニケーションへの）安心感」
　「マネジメントへの安心感」
　「品質への安心感」

で優位性が決まると言っても過言ではありません。
「ホントにー」と思うかもしれませんが、逆を考えてみればわかることです。この３つのうち１つでも不信感があったら、その会社にあなたは注文したいと思いますか？何千万、何億という会社の予算を託されて、責任を持って選択することが可能ですか？

つまり、この３点を伸ばし、他社を圧倒する評価を常に受け続けていれば、否応なくコンペでも頭一つ抜ける評価を受けることになります。

　「あの会社だったら安心だ」
　「以前、お願いした時は超安心できましたよ」
　「あの会社が納めたものって、その後問題が起きたという話を聞かない」

そんな口コミが広がれば他社の良し悪しに関係なく、常に優位となることでしょう。逆に、技術力の高い／低いってお客さまにとって口コミにするような内容となると思いますか？

　・できるだけ高品質／高効率となる開発プロセスの構築
　・開発プロセスを最適に運用する高水準のマネジメント
　・そしてそれらを駆使した結果、自信を以って保証する品質

この３点に重点的に注力した企業こそが、少なくともＢ２Ｂのソフトウェア開発市場において、もっとも差別化を図れるのではないでしょうか。


品質を第一義にしない方法もある

もちろん純粋な力のみで差別化を図り、急激に成長した企業もそこそこありますね。ＧＡＦＡＭなどもそうですが、そこまでモンスターでないにしても国内にだって色々あります。そう言った企業はとにかく従来の慣習を気にせず、優秀な人材の発掘やそういった優秀な人材の抜擢に対して非常にフットワークが軽い体質を持ちます。少しでも古い体質を持つ企業ではなかなか実行できることではありませんし、参考にもなりません。

たとえば知識が豊富で優秀な人材でも、多くの企業では実績や業績寄与などがなければなかなか昇格…に踏み切れませんよね。「とにかくやらせてみせよう」「ダメだったらまた別のポジションを考えればいいし」とはなりません。

あるいは「他の古株の人たちとうまくやっていけるか心配」と考えてしまうかもしれません。「上手くやっていけるメンバーだけで構成させ、結果に結びつけよう」とは考えないのです。

ですので、特殊な企業は参考にならないと考えておいていいのではないでしょうか。

私の知る面白いところで、「人」の提供率の高さで優位性を持つ企業というのがありました。決して派遣専門と言うわけではなく、準委任や請負もします。少なくとも私が知るその企業はあまりプライムで請けていない感じがしますけど、でもプライムでの受注がゼロと言うわけでもない…なんかこう「何でも屋」みたいな感じですが、とにかく

　「急に要員が大量に必要になった！」

と言われて、多くのＩＴ企業が「そんなに人を遊ばせてないよ…」と言って尻込みするところ、その企業だけは20人でも50人でもかき集めてチームを構成できてしまう…という点で、他社と差別化を図っていました。

当然、技術力は中堅クラスです。ですが、市場のニーズの大半は最新技術を必要としていません。技術力が平均的であっても成立する業務の方が圧倒的に多いのです。そのため技術領域に得手不得手がなければ、とにかく様々なところに参画していくので、そこで得た実績・ノウハウを用いてさらに他の注文を受けやすくして拡大していくスタイルでした。アレはアレでアリだと思いますが、傍から見ると『従業者への負担』が気になるところなので、それで成立するなら、相当なエンゲージメントの向上努力を行っているのかもしれませんね。


品質を第一義にした差別化戦略

さて少し脱線してしまいましたが、とりわけ業界１位と言えるくらい突出した差別化を検討できないのであれば、同業のコンペ対象となるくらいの同レベル他社に対し、私は先ほどもお伝えしたように「プロセス」「マネジメント」またそれらを含めたうえでの「品質」によって差別化を図ることを推奨します。

特に、このソフトウェア開発の業界において

　「ソフトウェア品質」
　「製品品質」⇔「利用時の品質」

を正しく理解している人というのはエンジニアにも、管理職層にも、経営層にも決して多くありません。多少知識があってもしょせんは受け売り程度できちんと理解している人というのはなかなかいないのです。当然、それらを駆使して品質を保証する具体的な方法論も知りませんし、それらを駆使した結果、お客さまに証明する術にも長けていません。

私がこれまで見てきた企業では、企業内に１～２人いたかどうか…。
私がこれまで所属してきた企業では、私くらいしかいませんでした。

だからまず品質についてまともに会話できる人がいなかったんです。

以前までも私の隣でお客さまに品質の説明をしているエンジニアやプロジェクトマネージャー、あるいは中間管理職の人たちをたびたび見てきましたが、どれ１つ取っても「証明」になっていませんでした（同じ立場側にいるからお客さまの前で「え、それおかしくね？」とは口が裂けても言えないんですけど）。

どこかでググった程度のモノマネはできていたかも知れませんが、それらを用いている当の本人たちが「それで証明ができる」とは思っておらず、なんとなく使っているだけなんです。当然、ＩＴリテラシー…というかソフトウェア開発のリテラシーを持たないお客さま側も同じかそれ以下なわけですから、なんとなーく騙されてはくれます。

まぁこればかりはお客さま側にも疑問を持ってくれる人がいないので、どうしようもないんですけどね…。わかっていない者同士が、わかろうとしないままに、お互いわかっていないことを隠して話を進めている様は滑稽にしか見えません。

でも、それでは結局リリース後、サービス開始後に障害が生じないとは限らず、実際に障害が出るケースだって多々起きていました。


たとえば「バグ密度」

たとえば品質について報告する際によく見かけるのがテスト工程において「不良（バグ）密度」を用いて評価するケース。同じＩＴ業界にいる人ならば１度は見たことがあるかも知れません。

どこかで拾ってきた「バグ密度」の指標値をもとに、テスト結果の実績値が「倍半分の範囲内にあるから品質としては大丈夫です！」と言っているシーンを数多く見てきました。ここだけの話、私はそれを聞くたびに「あー…この人もこの程度かー」と思ってました。

　「 比較する指標値を今回のプロジェクトで用いると判断した根拠は？」

考えても見てください。IPAにせよ、JUASにせよ、それらの蒐集している情報の元ネタとなったプロジェクトの規模や複雑度、採用している言語やアーキテクチャ、そしてそこに従事するエンジニアのレベル、人数、チームの複雑度やコミュニケーションレベル、etc.…すべてが参考に値する条件を満たしているのでしょうか。

たとえばプロジェクトやチーム、PMの個性によってプログラムの複雑度というのは大きく変わってきます。プログラムの複雑度が変われば、そこに要するテストケースの数も大きく変わってきます。わかりやすいところで「共通化」をとても推進しているチームと、個人主義的でまったく共通化を行わずそれぞれが独自に作成しているチームではまったく異なる結果となるでしょう。まぁこの場合は規模に差が出るので、テストケースが増加するのは誰でもわかりますけど。

では、次のような場合はどうでしょう。

画像1

これ、実はどちらもまったく同じロジックなのですが、プログラム上ではどちらで記述することも可能なのはプログラミング経験者の方であればご存じだと思います。当然ながらテストケースの数も同じになります。

これは「より簡単に書きたい」というエンジニアの要望等によって'70～'80年代に様々な書き方の自由度が加えられた当時のC言語の名残りによるものですが…でもこれ、よく見てください。

左のケースの場合、テストケースをみなさんなら何件（何パターン）思い描きますか？そして右のケースなら何件のテストケースを思い描くでしょうか。

もしこれにズレが生じた時、テスト密度やバグ密度は当然変わってきますよね。この程度のちょっとしたことでズレが生じます。プログラム量にして10行もない程度の基礎制御文だけで…です。

これが100Kstep（10万行）、1Mstep（100万行）の規模になってくると、どの程度の開きになってしまうのでしょう。

はい、では改めて確認しますが、

IPAやJUASが集計し、統計分析している元となったプロジェクトたちは私たちが実際に開発しているプロジェクトにとって指標値としていい根拠は何ですか？

参考値にするのは良いと思います。あくまで参考ですから。

ですが、あたかもそれが答えであるかのように奉って、その答えと比較したからと言って「だから品質として問題ない」と言い切れる話の筋道がどこにもありません。それって要するに

「IPAがそう言ってました。
　IPAがいうことは絶対なんです
　だから、IPAの出した数字に近似しているので大丈夫なんです。
　IPAを疑うんですか？
　仮にそれで問題があってもIPAのせいです。私たちは知りませんよ。」

と言っているのと同義なことに当の本人たちが気づいていません。
わかりやすくいえば

　他責

なんです。そしてこれがこれまで見てきた多くのＩＴ企業の実態だったりします。


品質分析も何のためにしているのやら

自らが作り上げたソフトウェアやシステムの品質保証を行うにあたって、この「テスト密度」や「バグ密度」という点に限った話で言うと、私はこれらをもとにした分析や論理も

　クソくらえ

だと思っています。自分たちの作成物なのですから、自分たちの条件や状況に合わせた保証をすればいいだけです。こと「テストケース」に限って言えばそれぞれのテスト粒度のなかで『テストケースのカバレッジ』を取ることがまず必須ではないでしょうか。

要するに、

　「組み合わせ数分は網羅しなさい」

というだけのことです。同値分割や境界値分析の考え方によって単項目レベルのケースパターンを絞り込みつつ、複数項目の組み合わせに対しては直交表やAll-pairを用いて保証可能な必要最低限の組み合わせを考えていけばいいわけです。

そもそも「テスト」自体の品質は

　・テストケースの網羅度合い（抜け漏れの有無）
　・テスト手順の正確性（誤りの有無）
　・テストに用いるデータ（誤りの有無）

によって決まります。逆に言えば上記以外の理由で発生した「バグ」というのはそれ以前の工程で作りこんだものであって、決してテストの品質がどうこうという話ではありません。

つまり、当該テスト工程の品質を保証するには

　・テストケースが保証するために必要な分を網羅しているか
　・テスト手順に誤りはなかったか
　・テストデータはテストケースを保証できる値であったか

が証明されていればそれ以外は必要ないわけです。バグの発生密度ではテスト自体の品質を保証することができません。どんなにバグが発生しても「以前の工程ではこのような作りこみをしていました」という報告にしかならないからです。

もちろんバグに対する対策結果、その確認については整理し、報告する必要はあります。そのままにしておくわけにはいきませんからね。ですがそこでもバグ密度は関係ありません。修正する箇所を特定し是正するだけです。仮にバグの内容や要因に偏りがあったとしても関係ありません。

よく分析などで

　「〇〇機能にバグが集中した」
　「担当◇◇の作成したものにバグが散見された」

などと報告し、その点をもう一度チェックしなおす…ということをしているプロジェクトを見かけますがこれもナンセンスです。まったくの無意味。

よく考えてください。
この報告は何が問題だと言っているのでしょう。

　「〇〇機能にバグが集中した」
　　　　||
　「〇〇機能の実装時にバグを作りこむ機会が多かった」

　「担当◇◇の作成したものにバグが散見された」
　　　　||
　「担当◇◇の作成時にバグを作りこむ機会が多かった」

と言っているだけですよね。別にテスト自体に問題があったわけでも、テストケースに不備があったわけでもありません。もし仮に品質を保証できるだけの必要なテストケースがすべて洗い出されていて、すべて実施されていれば、そのテストを以って

　「すべてのバグは洗い出された（これ以上はない）」

ということになりませんか？
もしここで「さらにチェックします」という判断を行えば、それは

　「テストケースの洗い出しに不備があり、保証するに至りませんでした」

と言っているようなものです。そんなテストケースの洗い出し方しかできなかったチームが、そんなテストケースの洗い出し方しかできない原因も特定しないままに追加でテストケースを考えるにあたって、本当に抜け漏れなくテストケースを抽出することが可能なのでしょうか。あるいはそれをどうやってお客さまに説明するというのでしょう。

テストケースが漏れていたのであれば、追加するのも良いと思います。

ですが、そうでなかったのなら「発見」し「是正」した時点で完了にしかなりません。それ以上無意味な分析は必要ないのです。もし、それでも分析の必要があるとしたらそれは

　『再発防止』

すなわち、次プロジェクト以降に活かすための情報にしかなりません。過去に撒き戻ってもう一度やり直すものではないのです。

このあたりは完全に製造業の考え方ですよね。量産のラインで問題があれば、たしかに分析して次のラインで再発させないよう取り組むのもアリだと思います。ですが、ソフトウェア開発においては（アジャイルでもない限り）「もう一度やり直す」はないので、プロジェクト自体にとっては分析に求めるものがなにも無いのです。

ただし、当該プロジェクトのなかでレビューやテストなど不備・不足があった場合は別です。分析するまでもなく、原因特定ができた時点で

　「どのタイミングのチェックで発見しておくべきだったか？」

がわかると思いますが、それが当該工程で発見すべきものならむしろテストケースが優秀だったというだけでそれ以上なにも必要ありません。しかし、前工程までのどこかで発見すべきであった場合は、チェック機能が有効に機能していなかったということであり、当該工程のチェック観点に含まれていなければそのまま次の工程に持ち越してしまうかもしれない危険性をはらみます。

この場合だけは遡って、同質の機能や処理等に不備がないか、類似で見直し、不備があれば対策を施し、それまでのチェックやテストをし直す必要があります。

逆に言えば「追加でやり直す」のはそれ以外に必要ありません。

品質を保証するのはそれだけで十分なはずです。

どこかの権威をもつ誰かが言ったなんてのは、その言葉自体に信憑性があるってだけで、その言葉を利用して実施したプロジェクトの信憑性をあげてくれるものではありません。

インプットとしての「開発プロセス」定義
プロセスとして「マネジメント」による開発プロセスの実現
アウトプットとして「製品/サービスの質」の保証

画像2

この３点にできれば注力し、そうすることで余計な問題を撲滅し、無駄な冗長コストを下げ、利益率や従業員のエンゲージメントを高めていきたい…そのために残りのビジネス人生がある…とさえ思っています。

まぁそんな考え方を従業員に徹底して伝えることができるようになるまでにフツーに定年して引退してそうですけど。CQOみたいな立場になれば、また変わってくるのかしら。

いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。