SIerにおけるソフトウェアテストの考え方

SIerでのソフトウェア開発は基本的にウォーターフォールで行われます。

ソフトウェアのテストは工程の最後にやるものです。

上のような順番で成果物を作っていきます。

テストで問題が見つかったら設計書の修正を行い、レビューを行い、単体テストからやり直します。

そのため、一度手戻りを起こすとものすごく時間がかかります。

Excelに何百と書かれたテスト項目を一つ一つ実施していき、「テスト項目」に「◯」をつけて、テスト結果をスクリーンショットでExcelに貼り付けなければいけないからです。

作業は全て人力で行われます。

作業するのはパートナーと呼ばれる外注先の人たちです。

オフショアのメンバーがやることが多いですね。

そうやって時間をかけてたくさんテストをすれば、バグは完全に潰し込めるようにも見えますが、実際はあとから次々と障害が見つかるものです。

SIerの上流工程を担当する社員は

レビューをちゃんとやれば品質は高まる

と信じているのですが、レビューをやってもバグは出ます。

そしてバグが出るたびにテストをやり直し、スケジュールは遅れていきます。

しかしながら、スケジュールは絶対なので、遅れてきたら「みんなで残業」してカバーします。

そうやってSIerの残業は常態化していきます。

どこかの工程で何かが遅れたら連帯責任で残業するからです。

「連帯責任」というのは、作業範囲が細かく分かれていて、それでいて密に結合しているので、他の誰かがどこかを修正したら、自分の担当範囲でもテストをしなければいけないからです。

こうして、SIerの開発は常に地獄の手作業と、つまらない単純作業と、しんどい残業に追われ続けます。

プロジェクトマネージャーになってもそれは変わりません。

チームメンバーのケツを叩くという意味で、仕事がなくても最後まで残業しますし、そもそもスケジュールが遅れると、その遅れを報告するための資料を多大なる時間をかけて作成します。

進捗の遅れを報告する資料を作るために時間を使い、さらに進捗が遅れていくのです。

文章にするとちょっと笑ってしまいますが、中の人は大真面目です。

そうやって進捗を遅らせて作り上げた資料は偉い人の前で報告され、偉い人が何をするかと言うとただこう聞くだけです。

「どうやってリカバリするの？」

「間に合うの？

「人は足りるの？」

こういうことを聞かれて、ほぼ全員のプロマネはこう答えます。

「残業でカバーします」

頭を使って問題を解決する気がないんですよね。

私はSIerでこういう会話を何度も何度も聞いてきて、いつも「この人達は本当に対症療法ばっかりで、問題の根本原因を取り除こうとしないんだなあ」と思ってきました。

なんでこんな無駄なことをやめようとしないんだろう。

偉い人は何のために報告を聞いているんだろう。

報告を聞くのに解決策を提示しない。

ただ叱責して詰めるだけ。

そもそも、偉い人自身がシステム開発のことは全くわかっていないので、詰問するしかできないんですね。

そういう偉い人の機嫌を取るために莫大な工数とコストをかけているのがSIerの仕事です。

そのコストの原資はお客さんが出してくれているお金なのです。

いい加減こんな無駄なことやってたら顧客に愛想を尽かされてもおかしくないと思うのですが、顧客も顧客でIT何もわからず丸投げしてしまうので、ダメな意味での癒着ができてしまっています。

IT後進国の日本の惨状です。

COBOLで作られた古いシステムを5年かけてJavaで書き直そうとするプロジェクトがありました。

COBOLのスパゲティをJavaのスパゲティに変えていくわけです。

そのプロジェクト担当者の方に

「せっかく書き換えるんだから、テストは書かないんですか？」

と聞いてみました。

担当者は首を傾げて、

「テストを書くって何？」

と聞いてきました。

SIerの意思決定を担うプロマネ層の人達は、テストを自動化するという考えが全く無いし、そもそもテスト駆動開発もユニットテストも何も知らないのです。

膨大なコストをかけてCOBOLをリプレイスするのであれば、その後の生産性を高めるために、というか、安心して開発するためにも絶対にテストコードを書くべきです。

テストコードは仕様書にもなりますし、テストコードを書くことによって曖昧だった仕様が明らかになることもあります。

ですが、SIerのプロジェクトマネージャーの頭の中にあるのは、「今まで通りのやり方」で、人がどれくらい必要なのか、スケジュールは遅れないのか、だけなのです。

そうやって永遠に人間が楽ができず、かといって品質は上がらず、ずっとバグに悩まされ、開発速度は時間が経てば経つほど遅くなっていきます。

SIerでは問題の本質的な部分を解決しようとしないのですが、そもそも解決策が頭の中にないんです。

今まで通り、たくさんの偉い人に仕様書や計画書をレビューしてもらえばソフトウェアの品質は高まる…と信じ切っています。

ソースコードを全く離れたところにあるExcelに書いた仕様書を読んで、何の品質が高まるんですか…

ソフトウェアの開発してるんだから、ソースコードをテストしないとダメでしょ…

ソースコードのテストはユニットテスト、システムテストと分けて、コミットのたびにテストが回るようにするべきでしょ。

「CIを回す」という考え方なんて当然あるわけもなく、ソースコードはコード_yyyymmdd.zipで管理される世界です。

ファイルはバージョン管理されていません。

GitHubを知ってる社員は全体の1割もいません。

なので、PullRequestがマージされるたびにテストを回す、みたいな世界はSIerには存在しません。

導入することもできません。

意思決定する層が高齢化しすぎていて、彼らが現役だった頃、1990年代のソフトウェア開発で知識が止まっているからです。

SIerは本当にもう、腐りきっているように見えます。

勉強すればするほど、SIerのソフトウェア開発のやり方に対する疑問が湧き出てきます。

たくさんの人が必死に考えて積み上げてきたソフトウェア開発のプラクティスを冒涜しているようにも感じます。

何かがあったら札束で殴り、中国人を大量に働かせて人力で対応する…そんなやり方が通用するのはオフショアの開発コストが低いからですが、これから10年続くとは思えません。

また顧客がIT部門を内製化し始めたらそれはそれで、SIerが現在の規模を維持できなくなるでしょう。

だからこそ、SIerはそろそろ本腰を入れて、本気で変わっていかなければいけないのです。

必死に残業して、目の前のプロジェクトに対する危機感・責任感はあるのに、未来に対する危機感が足りないのです。

もしあなたがSIerで働いていて、「会社が変わっていきそう、未来の心配もなく、市場価値を高めていけそう」と感じているなら会社で頑張りましょう。

不安を感じるなら、そして「会社はもう変わらないな」と感じるなら、若いうちに転職活動を始めた方がいいです。

歳を取るとしがらみが増えたり、求められるスキルが高くなったりして、転職しづらくなるからです。

人生で一番若いのはいつ？

そう、「今」ですね。

転職活動を始めるなら、レバテックキャリアで。新たな時代に向けて、新たな一歩を踏み出しましょう。

\ レバテックキャリアに登録する /