見出し画像

Quality oriented approach

Takashi Suda / かんた

やっぱりプロジェクトマネジメントは

　「品質」

を軸にして実施した方が断然いいです。
まぁ企業経営的なマネジメントも同じだと思いますけど。

もちろん「品質」を軸にするからと言って「スケジュール」や「コスト」を
度外視していいというわけではありません。そういう極端な発想しかできないようではまともなマネジメントなどできるはずもありません。

Ｑ(品質)Ｃ(コスト)Ｄ(期日)はどれか１つを満たせばいいというものではなく、常にバランスよく高い水準を満たす必要があるものです。これはＱＣＤすべてをバランスよく満たすことを前提としたうえで、それでも軸にするべき『優先度』についての話になります。

ではなぜ「品質」を最優先にするべきかというと、トラブルを起こすプロジェクトってとことんその要因を突き詰めていくと

・製品やサービスの質が低い
・コミュニケーションの質が低い
・プロセスの質が低い
・マネジメント質が低い

結局、このどれかに必ず該当するするからです。要するに、既存のマネジメントが測定しにくい「品質」というだけでこの要素をおろそかにし過ぎているのが問題なだけなのです。

かと言って「一般的に」「なんとなく」「それが正しいかどうかもよくわからずに」「どこかのエライ人が言っていたから」という理由だけで、品質上の基準値（テスト密度やバグ密度）を定めればそれでいいか？というと、これも大きな誤りです。

少なくとも『品質を保証する』という目的は絶対に果たせません。

考えても見てください。
というか考えたことがありますか？

仮にバグ密度が

　どこかから引用した基準値の上下限内に収まっている

というだけで、その製品やソフトウェアの品質が高いとする根拠になるでしょうか。

たとえば上限10件、下限5件だとして、「たまたま」「運よく」「理由は特にないけど」バグ密度が7件だったとして、その対策さえ済ませてしまえばそれは本当に『他にバグが残っていないほど品質が最高の状態にある』と言えるものなのでしょうか？

画像1

一般的にはこんなマトリクスを使って、どのゾーンにあると品質が低い可能性があるとか、高い可能性があるとかアタリをつけるのでしょう。理屈としては間違っていないと思いますが、それは「前提条件」が一致していればの話です。

もう少しわかりやすく言いましょうか。

「テストケースに抜け漏れがない」かどうかの検証も行わないままに、ただどこからか拾ってきた基準値と近似であれば、それが品質の証明根拠になるのでしょうか。というか、論理的に筋道が立っていないんですけど、それで誰を納得させたいのでしょうか。

①IPAやJUASではアンケートの統計上、基準値は「上限10件、下限5件」
②しかしIPAやJUASが対象としたアンケートのプロジェクト特性と
　自分たちのプロジェクト特性が一致しているかどうかは知らない
③テストの精度が高いかどうかは検証できていない
　(レビューはしたし指摘は反映したけど、網羅性は不明)
④その結果、バグ密度が基準値内に収まった

はい。どこに論理的な筋道があるというのでしょう？

…でこんな話をすると、

　「だってみんなそうしてる」
　「今までそれでやってきた」

と、ますます論理性のない幼稚な言い訳が始まります。というか完全に他責ですね。どんなに優れたマトリクスを使っていても、そこに割り当てた基準値が当該プロジェクトに対して「適用してもよい」かどうかをちゃんと判断していないですよね。

たとえば「基準値を示唆するプログラム言語と同じなら適用する」なんて判断をするプロジェクトをよく見かけます。でも、それは同じ作り方をしていれば数字が似通る、というだけの話です。みなさんのプロジェクトは基準値を定義したプロジェクトと同じ作り方をしているのでしょうか。

たとえば１関数（メソッド）の中の複雑度（例：ネストの数）が１のものと５のものでまったく同じテスト密度、バグ密度の基準値が適用できるのでしょうか。

画像2

たとえば上記はとても初歩的な条件分岐処理ですが、これは３つともまったく同じ処理を意味します。ソフトウェア開発の現場では、このレベルにまでなってくるとルールでどう記述するか定めていないことでしょう。すると、エンジニア一人ひとりの個人的な好み…好き嫌いで選択することになります。

この３つのケースはシンプルな内容ではありますが、複雑度も違えば、バグの混入のしやすさも違いますし、３ケース目のように一瞬コード量が多く見えても、目的別に共通化を図った場合は再利用性が高い処理だった場合などであれば規模は縮小されますし、共通部品については１度確認できればどこで何度使われようとも品質は変わらなくなります。結合レベルであれば本来コードの行ではなく実行の行数に対してバグ密度を測定しないと正確な測定ができないものですが、仮にそうした場合であっても共通化を多く図られていればバグの密度はグッと下がることになるでしょう。

そう、どれ一つとっても「作り方」１つでさえ少しずつバグの発生の仕方や傾向は変わってくるということです。

正直、こんな数字に頼る必要性が私にはわかりません。

どーせ一つひとつの障害ごとに解析を行い、原因を特定し、バグそのものを是正し、影響範囲を特定し、影響範囲を含めた再テストを行い、さらには類似見直しの要否を判定し、必要に応じて類似見直しを実施するわけですから発生するごとにバグ１件ごとの品質は保証しきるはずです。

もし仮に「テストケース」が品質を保証できるだけの論理的な網羅を行えていれば、分析をして「この辺が弱そう…」みたいな再テストを実施する必要がないはずです。だってあらかじめ洗い出しているテストケースがすべて消化され、バグがすべて解決された時には、

　・テストは全て網羅した
　・その網羅したテストケースの範囲内においてバグはすべて解消した

ことが証明されるからです。

そう、品質を保証するために本当に必要なことは「不安だから」「心配だから」となんとなくで分析することではなく、「テストケースをどのように網羅すべきか」を考えることにあります。むしろそれを徹底しないまま、定量的品質管理に頼るのは

　「なんかよくわかんないけど、不安な所だけ再テストします」
　（あってるかどうかはよくわかりません）
　（それ以外は数値的にたまたまでも問題が無ければ再テストしません）

と言っているにすぎないのです。
それってものすごく不誠実ではありませんか。

私はこの「品質」のあり方を真面目に考えようとしない、世の中の多くのマネジメントにいつも辟易しています。だって、そのせいで何十というトラブルプロジェクトに巻き込まれているんですから。

しかも、無駄にプライドが高いから何を指摘しても一切耳を傾けようとしない…。傾けるのは私が「プロジェクトマネージャー」という肩書きで立て直しに入った時だけです。既存のプロジェクトマネージャーをそのままに支援という形で入ると、まず100%耳を傾けません。

ですが、彼らのマネジメントではどうにもならないからトラブルまで発展していたり、トラブルを収束できなかったりするわけですから、いい加減変なプライドでこちらの人生まで無暗に巻き込まないで欲しいものです。

相手がどんな立場で、どんな役職だろうが関係ありません。

役職や立場で仕事ができるなら世話無いですし、役職や立場でプロジェクトが好転しないのは、目の前に起きているトラブルを見ればわかることでしょう。プライドで飯が食えるわけではないのです


スケジュールもコストも目標を達成する必要があるけど、それは「品質」を保証するプロセスをしっかり提示したうえで行うべきものです。

　プロセス → マネジメント → 製品・サービス

それぞれの質は、100点満点からの減算方式で考えるべきものです。基本は100点で納めなければならないものを、他のことに注力して疎かになればなるほど点数は低下します。

なのに企業もマネージャーも、品質を保証するプロセスを定める前にスケジュールやコストの話を進めるからいつもおざなりになってしまいます。

現場も軽視が進む。
そんな現場から叩き上げで昇進した人が管理職、経営層となっていく。

だから、企業ひっくるめて誰も「品質」を軸としたマネジメントができないし、それ以前に論理的に品質を保証する方法をしらない。知らなくても規模が小さければそこそこ作れるし、仮に中規模程度のプロジェクトなら、あの手この手を使ってお客さまから予算をせしめればなんとなーくプラス収支で完了させるし、それをみて企業は高い評価を下すからまた品質が疎かになっていく…。

そのようなマネジメントを続けると個々人にそこそこ高い技術力が身についていたとしても、組織としてはまともな開発プロセス、まともなマネジメントも知らないままで、結果

　見積りで騙すスキル
　品質で誤魔化すスキル

ばかりが高くなっていきます。

たしかにお客さまが納得しさえすれば、それが騙したものであっても、誤魔化したものであっても、契約は結べますし、検収はあげられますし、結果売上や利益を作ることはできるかも知れません。

でも、そんな企業…どこがいいんですか？

って思いませんか？

やってることは悪徳業者ですよ。

結果、「保証」や「証明」ができるエンジニアやマネージャーというのはものすごく少なくなるわけです。ソフトウェア開発業界全体を見渡しても、ちゃんとできる人なんて一握りではないでしょうか。

私自身も、

プロセス、マネジメント、製品やサービスに対し
品質を軸に計画を立て、そうすることの重要性やメリットを顧客に伝え
そのうえで正しくご納得いただき
さらに品質を中心に据えていながらも様々なやりくりによって
非常に効率的で生産性の高いプロセスを構築し、
メンバーや顧客の負担を最低限にするマネジメント

ができる人なんてホント、片手で数えられる程度しか見たことがありません。やろうと努力してる人は両手くらいで収まるでしょうか。

それくらい、この世の中には正しく「品質」をマネジメントできている人はいないのではないでしょうか。

まぁでも世の中のニーズとしてそういったマネジメントによってトラブルを無くす活動や起きたトラブルを早期に解決する方法が求められていない以上、どうしようもないんですけどね(:3_ヽ)_

　「替わりに解決して！」

と言われたことはこれまで多々ありますけど、

　「解決する方法を教えて！」
　「解決する仕組みを組織に徹底させて！」

と言われたことは残念ながらないんですよね。
それくらいニーズが無いってことなんです。

もったいない。

年間に発生するトラブルや焦げ付くプロジェクトを10%減らすだけで家を数軒建てられるくらいの利益が増えるんですよ。大規模なプロジェクトだったら豪邸建てられるくらいの金額がそのまま純利益になります。

たとえば利益予測5000万（売上にすると５億くらい？）のプロジェクトがトラブルによって１億の赤字を出しました！って場合、その差は-1.5億ってことですよね。それが丸々無くなるってことですよ。

「騙す」「誤魔化す」マネジメントが主流すぎて、そうする仕組みを構築するマネジメント手法が駆逐されるのはすごく勿体ない気がします。

世界中でトラブルを起こさなければ、年間いったいいくらのお金が幸せな使われ方をするのでしょうね…。

いいなと思ったら応援しよう！

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