オフショア子会社で実践したデータを用いた品質管理とその改善の話

 

今回は品質管理に関する話です。

10月31日から約2週間、マメ研所長である私は子会社のロックオンベトナムで、ソフトウェアの品質管理と品質向上という大きな課題に挑んできました。

問題ない範囲で、どのような施策をしてきたか公開したいと思います。

 

「品質を上げる」とはどういうことか?

簡単にロックオンベトナムについて触れておきます。

ロックオンベトナムは2013年12月に設立された若い会社です。(設立時のプレスリリースはこちら

オフショアと聞くと大規模な工場をイメージする人も多いでしょうが、ロックオンベトナムで働いているメンバーは2016年11月現在30人程度と、それほど多くありません。

安かろう・人多かろうという話ではなく、同じロックオンの仲間として海外に置かれた1つの会社というイメージを私は持っています。

 

だからこそ国内のエンジニアと比べて技術面、知識面で伸びて欲しい面が多くあります。目下の課題は「生産性向上」だと個人的に感じていました。

ここで言う「生産性」は付加価値的生産性ではなく、労働的生産性(生産÷労働時間)を指します。

つまり同じ労働時間でありながら、アウトプットの量を多くする、或いは質を高める。特にアウトプットの質です。それが、今回のミッションの1つである「品質向上」でした。

ミッション遂行にあたっては、以下の本を参考にしています。

 

 

ちなみに、最大のミッションは「同じ釜の飯を食うこと」で、現地のベトナム人メンバーと現地飯をたらふく食ってまいりました。

コムガー最高。マムトム最強。

 

ランチ美味いよぉ。 #コムガー #炭水化物の塊

Kentaro Matsumtoさん(@kentaromatsumto)が投稿した写真 –

 

 

時間を何に使っているのか?PJ進行の見える化を図る

まず最初に、一目で見て直感的に現状を把握できるグラフの作成から始めました。

このようなグラフです。デモデータですので、雰囲気が伝われば。

 


 

積み上げ棒グラフは実績稼働時間、これはRedmineのチケットの数字です。折れ線グラフは想定稼働時間、これはWBSの数字です。

データが不完全なので解りづらいかもしれません。ですが、要件定義→設計→テスト設計・開発→試験→不具合修正と、WFに進行していることが一目でわかります。

さらに黒い折れ線が基準線となり、残業が多発しているか、稼働が低下しているか(他タスクに追われてPJに時間が使えていないか)も分かります

データ自体はRedmineのチケットベースなので、新たにデータを入力する必要もありませんし、負荷なく進められます(言い換えれば適当に入力していたら直ぐバレます)。

 

各フェーズにどれくらい時間をかけて進行しているかを可視化することの目的は、決められた時間に、決められた分だけ、決められた人をちゃんとアサインできているか知るためです。

プロジェクトが予定通り進まなくなると(そもそも予定通り進むこと自体が珍しいですが)、必要なプロセスを省いたり、残業で無理してタスクをこなしたリ、力技が発生します。そして、そうした力技の瞬間に不具合がたいてい潜むものです。

そこで、こうして進行時間そのものを見える化しておけば、ちょっと無理が続いているなどのアラートをあげられます。

 

ちなみに夜遅くまで残っているか否かで判断するとなると、PJ以外の時間も考慮する必要があり直感的ではありません

Redmineだと集計が必要だし、WBSだと実績時間の概念を当てはめてグラフ化するのに向いていません。

要件定義、設計、テスト設計でちょうど折り返し地点と考えれば、直感的に見て遅れているかどうかの判断もできます。

日次の朝会で共有するのに向いていると思っています。

 

なぜ予実差は起こるのか?散布図で原因を考える

進捗がわかると、予定と実績の予実差も見えてきます。積み上げ棒と折れ線の差分がそうです。

私はミクロな観点で予実差を把握することに結構拘っています。朝にやると言ったことを何らかの理由で達成できなかったとして、それを責めたいのではなく、何があったのかを知ることを怠ってはならないからです。

それがPJ外のタスクによるものか、単純に作業見積もりが甘かったのか、作業を進めていく中で想定していなかった問題に遭遇したのか、これを把握しないと「予定」時間なんてあってないようなものです。

まずは散布図で予実差を把握します。

 


 

回帰直線を引くと、傾向が出てさらに面白いです。

全てにおいて予実差が無ければ回帰直線は y(作業時間)= x(予定工数)になりますが、当然そうなりません。

今回のサンプルデータだと、8時間以内のタスクであれば予定を実績が上回り、8時間以上のタスクであれば予定を実績が下回る傾向にあるようです。

つまり何をするべきか段取りがついているタスクは見積もりの時間が甘く、1日以上かかるタスクは規模が他に比べて大きいから多めに時間を取る傾向にあることが分かります。

 

見積もりの時間が甘い原因は何なのか?人によるのか、フェーズによるのか…これも確認します。

 


 


 

見てみると、設計フェーズと試験フェーズで予実にバラツキが出ていることが分かります。

結論としては、WBS上のタスク(+それに紐付く時間)を分割してRedmineにチケットを登録する際、紐付く時間をベースに考えているから、でした。

フェーズの後半に進むほど予実差は開いて当然です。

例えば、あるマスタデータ管理機能を修正するとして、WBS上は修正工数に3人日と記載されていたとします。実際に取り掛かる状況になって細かく分割してみると、一覧表示、登録、編集、削除それぞれにヴァリデータの修正を行うことが分かりました。

本来であれば、1つの機能を直すのに1日ぐらいかかるのに、WBSでは3人日と決まってしまっているから÷4して6時間で設定した。という話です。

「ちょっと待って〜ちょっと待って〜お兄さ〜ん」って感じですが、メンバーからしたら「ここで時間を伸ばせばリリースに影響出る」という脅迫概念が強いようで、「最初に立てた計画通りに進むことはないんだ(だから常にバッファを持たせておくんだから、その時間を使いなさい)」という会話を何度も繰り返しました。

最初に立てた計画通りには進まないのだから、フェーズが進むたびにWBSの見直しを行うという考えは受け入れて貰えるのですが、リリース日は動かせないのであるタスクの時間を増やすなら他のタスクの時間を減らさないといけない、という思い込み(?)があるようで、「そのためのバッファじゃねーか!」というツッコミを繰り返しました。

私自身はロックオンベトナムのPJ進行はCCPMに寄せたいのですが、彼らからするとショック過ぎるかもしれません。

話は逸れますが、ゴールドラット博士の本はベトナム語版も出版されているようで、色んな人に勧めてみました。

 

不具合の件数が見つかるほど品質は悪いのか?

細部で気になる点がありつつも、職場の雰囲気も良く(これは凄く大事)、和気藹々と過ごした2週間でした。

品質管理についても、試験フェーズで「信頼度成長曲線」が飛び出るなど、ちゃんとメトリクスして評価したいというニーズが強くあることが分かり、その期待に応えたいなぁと感じた次第です。

一方で、高度な手法に傾倒しても使いこなせないと意味が無いので「アクションに繋がらないメトリクスは意味が無い!」と口を酸っぱく言い続けました。

よくある「So What?」な分析は、職場の雰囲気を悪くします。良い分析は、現状がよく分かり、かつ次に何をすべきか分かる分析だと思います。

 

最後に、最も唸ったメンバーから受けた質問で締めたいと思います。

あるプロジェクトの試験フェーズで、通常の倍以上の不具合を見つけた。これは、今までより品質が悪いと見るべきか?それとも、十分に不具合を見つけたのだから品質が良いと見るべきか?

どちらも「正解」に見えますよね。私も思わず、うーんと唸りました。

冒頭に紹介した本をベースに私は回答しました。

 

まず、開発後に試験を行い不具合を見つけようとするのは、リリース後のバグ発覚を防ぐためです。

そして品質が悪い状態でリリースすると、かなり高い確率でユーザーによって不具合が見つかり、トホホな事態を招きます。

そこでリリース前の試験フェーズで発見した不具合の数、リリース後にバグが見つかったか否かをPJ単位で集計を取ることにします。そして、その結果を箱ひげ図で表現します。

 


 

若干、「リリース後バグあり」の方が不具合の数が多いように見えますね。

そこでこの結果をt検定にかけてみます。

 

dat<-read.csv("demo.csv")
t.test(件数 ~ タイプ,data=dat)
===========================================
	Welch Two Sample t-test

data:  件数 by タイプ
t = 6.8039, df = 37.958, p-value = 4.562e-08
alternative hypothesis: true difference in means is not equal to 0
95 percent confidence interval:
 4.987414 9.212586
sample estimates:
mean in group バグあり mean in group バグなし 
                  22.1                   15.0
===========================================

 

バグありPJとバグなしPJで、試験フェーズで発見した不具合の数は同じとは言えない、という結果になりました。

つまり、適切な回答としては「通常の倍以上の不具合を見つけたのは、今までより品質が悪い兆候」ということになります。

これはデモデータがそういう結果になっているだけなので、実際にPJ単位でデータを計測して、自社なりの見解をまとめる必要があります。

 

まとめ:なぜ品質管理にメトリクス(データ)が大事なのか?

今回、参考させていただた本の冒頭に凄く良いことが書かれているので引用します。

 

責任感の強いプロジェクトリーダーほど問題を自分で解決しようとする傾向が強く、それが裏目に出て事態を悪化させてしまうこともある。このようなことを防ぐために、客観的データにもとづくマネジメントが必要となる。

 

失敗しようとするPMはどこにもいないわけで、責任感が強いほど自分で何とかしようと努力し、なんともならない状況になって初めて降参し、周囲の人間が「燃えてるぞ!」と気付きます

ところが、何とかしようと努力していた時間が長い分、延焼範囲も広く、鎮火に想像以上の時間がかかる―というのは"あるある"です。

データは、調理さえ間違えなければ客観的に可視化を可能にします

データサイエンスとソフトウェア開発及び品質管理って、想像以上に相性は良いのだと思った次第です。