システムやソフトウェア不具合が発生すると、市場、取引先、関係者、様々な方面へ迷惑をかけ、社会的な信用を落としかねない。その意味ではしっかりと、体制、プロセス、仕組み、技術的課題に目を向け、発生原因、流出原因、再発防止策を検討し、実践していかなければならない。ここまでは、システム開発企業なら普通に教わる話である。
この記事では、ソフトウェア不具合再発防止を労務面からアプローチした実例について述べたいと思う。
当たり前のことだが、なかなかできていないことなので、該当する開発現場は参考にして、改善につなげてほしいと思う。
1.不具合再発防止は開発技術・プロセスに関することを求められるが根本的でない
ソフトウェアの不具合が発生すると、発生原因、流出原因、再発防止を検討する。社内でも対外的にもこれらを明確にする。
ソフトウェアの不具合はさまざまな要因によって発生する。ソフトウェア開発組織内部の問題として一般的に以下のようなものが挙げられる。
- 技術力不足
- コミュニケーション不足
- 要求仕様の理解不足
- 変更による影響の検証漏れ
- 不十分なプロセス
- 開発体制・しくみ
一方、ソフトウェア不具合が発生したシステム開発プロジェクトには、当然前述したような要因もあるのだが、外的要因を含め、開発現場ではコントロールできない労務面の問題もある。
後者のように、外的要因によるしわ寄せを受け、ソフトウェア開発組織が逼迫し、ソフトウェアエンジニアが疲弊し、パフォーマンスを削り取られた結果、スケジュール遅延やソフトウェア不具合といった、目に見える形となって表面化する。しかし、よくある残念な実態は、この表面化した最終結果が叩かれるのである。本来、是正しなければいけないのは、表面化した最終結果に至る「前段」であるべきなのにである。
ソフトウェアの不具合再発防止ではこの「前段」に触れられることはない。労務面をはじめとする「前段」に触れようものなら、「言い訳」と叩かれ、根性論で抑え込もうとするケースが多く、労務面を軽視している実態が浮き彫りになっている。この状況を「業界では当たり前！」と、洗脳され感覚が麻痺し思考停止た人間が、足を引っ張るにまで至っている。
これに反するようなことが私の若い頃にとある開発現場で起きた。再発防止に労務問題の是正を挙げ、長期的には良かったという話である。
2.不具合再発防止に思い切って労務問題の是正を挙げた
話の一連の流れを時系列順に見ていこう。
- 開発プロジェクトの現場はスケジュールに全く余裕が無く、過重労働の温床でほぼ毎日終電帰りの超絶ブラックであり、開発中のソフトウェアに不具合が多発していた。
- あるとき自身が混入したあるソフトウェア不具合が発見され、埋め込み時期を調査した結果、過去の徹夜作業で変更した部分であることが判明した。
- そのプロジェクトのリーダーから再発防止を求められた。その不具合は自身にとっても、なぜこのような誤りをしたのかよくわからなかったし、徹夜などせず正常なコンディションで作業していれば、おそらく発生するはずのない不具合内容だった。このことから、自分の意向を重視し社内用の複数の報告書に『徹夜は厳禁！』と記載した。
- リーダーや先輩メンバーからは「こんなことを書くものではない！」と指導を受けたが、私が反論してモメることになった。また、当時周囲の人たちの間ではこの出来事がかなり問題視されたらしい。
- それでも自身で『徹夜は厳禁！』を徹底し実行に移した。以降『徹夜』はせず、最悪でも終電帰りに留めた。これまで再発防止といえば、リーダーや先輩メンバーが示し、私がこれに従う受動的なものだったが、この『徹夜は厳禁！』は自分が必要と思って発信した能動的な再発防止である。逆に言えば、私が社会人になって自らの意思で提示した再発防止はこれが初めてである。
- 実際に『徹夜は厳禁！』を実行に移した結果、これだけでも不具合の件数は大幅に減った。低レベルながら目に見える進歩である。
- それでも発生した不具合に対しては、再発防止に『徹夜は厳禁！』は使えない。よって、おのずとこれ以外の再発防止を検討するようになる。
- 仕様解釈、プロセス、設計観点、テストケース、その他諸々、原因を深く分析する。
- その結果、更に不具合の件数が減る。
- 減少した不具合に対してさらに深く分析する。その結果、さらに不具合の件数が減る。以降この繰り返しである。このような好循環に入ることができた。
- 以降何年もかけて品質が向上し、その開発現場では不具合が皆無になった。あくまで私個人レベルの話である。
3.成功したポイントは根本への言及と地道なアクション
この話の成功ポイントは２つある。
- 不具合多発の状況で、目先に囚われず、根本に触れた点。
- 不具合が少なくなる過程で、それでも発生する不具合に対して更に深く分析するといった、次へのアクションに繋げている点。
話の前半は一見言い訳のように受け取れる。しかし、あらゆることの土台であるとも言える。いくら技術力を高めようが、いくらプロセスを改善しようが、疲労がたまっている状態では生産性が低下するのは当たり前である。労働時間と労働生産性の関係については、いまさらいうまでもないだろう。そもそも「努力」「気合」「根性」だけで乗り切れるものではない。
生物学的な話になるのだが、人間は朝起きて13時間が経過すると「酒酔い運転」並みに作業効率が落ちると言われている。医学的に証明されているそうだ。どの業界にも言えることだが、残業代を支払っているまともな企業は、夜遅くまで残業して「作業効率の落ちた人間」に「割増賃金」を払っているのである。経営の観点から考え直した方が良いだろう。
また、話の後半にあるように、『徹夜は厳禁！』だけで終わらない点が重要である。円滑な開発を阻害する要因を地道に一つずつ取り除くことを繰り返している。何も特別なことをしたわけでも、一発逆転を狙ったわけではもなく、単純な取り組みの継続である。
おそらく『徹夜は厳禁！』を問題視したリーダーや先輩メンバーから言われたことを素直に受け取っていれば、その何年も先に実現した「不具合皆無」には至っていなかったかもしれない。また、そのような人たちと同じレベルの人材程度に成長が留まっていたかも知れない。もう、「努力」「気合」「根性」だけで乗り切る時代ではないのだ。
4.当たり前のように「前段」に着目できる組織へ
不思議なことに下記２つの対照的な見解も見られた。
- 不具合発生当事者部門の関係者は「徹夜を言い訳にするな！」と根性論を押し付ける。
- 当該プロジェクトに携わってない第３者は「徹夜させる側の問題やろ！」と前段に着目する。
立場によって見方が変わってくるのだろうか？
前者はブラックな現場でよくある話である。不具合の再発防止に労務面の問題を挙げるのはいけないと言っているようである。その不具合に特化した技術的観点、プロセスに着目してほしいようだ。「徹夜が原因」は、洗脳され感覚が麻痺した人間、もしくはこのような人間が集まった旧態依然の体質の組織にとっては都合が悪く、言ってはいけないことなのかもしれない。
当該開発現場では話の一連の流れの冒頭に記載した通り、ソフトウェア不具合が多発している状況にある。個別の不具合に一つ一つに着目して深く分析していくこともあり得なくはないが、多発している不具合に共通することや、開発状況全般といった高い視点でアプローチすることが、長期的には解決が早いと言える。労働環境はその一例である。
現場の末端の担当者が言いにくいことだからこそ、管理監督する立場の人間が、今回のような労務問題に向き合うべきであり、「言い訳」として片付けるのではなく、当たり前のように「前段」に着目できてほしい。
o08usyu7231.hatenablog.com
逆に「前段」に着目できない組織は、この先脱落するしかない。
人事・労務・総務部門が「労務管理」の重要性を発信する企業は少なからずあるのだが、開発現場は目先のプロジェクト、スケジュールに圧倒され、なかなか「労務管理」まで行き届かないことが多い。しかし、人材の流動性が高まる現代、「労務管理」をおろそかにすることのリスクは高まりつつあり、杜撰な労務管理を理由に優秀な人材が流出すると企業にとってますます痛手であることを考えると、本記事のタイトルの答えはおのずとわかるだろう。
ソフトウェア不具合再発防止に労務問題の改善は有効だ！
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
