電話
03-5835-2820
平日9:00～18:00
Zoom等オンラインでのご相談も可能です

お盆休みに入る前にTwitterに以下のツイートを投稿しました。

私自身が客先常駐の現場でシステム開発に携わったのはフリーランスの頃なのでもう１０年以上前の話なのですが、当時ステップ数（プログラムの行数）に応じて、これくらいの数のバグが検出されるはずだという基準が設けられている会社やプロジェクトがありました。

このやり方には当時から様々な問題がありナンセンスなやり方だったので、１０年以上も時が経過した現代ではもはや絶滅した手法となっていることだろうと想像していましたが、皆さんからいただいた反応を見ると、どうやら客先常駐の現場では今でも当時と同じ基準が使用されていることも珍しくないということが判明しました。

日進月歩のIT業界において１０年以上前からまるで進歩が無いというのはまるで大昔の化石を発見したかのような驚きですね。（私は化石を発見したことはありませんがｗ）

単に進歩がないというだけにとどまらず、ステップ数によってバグ検出数の基準を設けることに関しては、このIT業界に潜む様々な問題を感じましたので、お盆明け一発目はそのことについて書いてみようと思います。

ステップ数によってバグ検出数の基準を設ける問題点

品質を担保しようとする目的のために一定の基準となる指標をガイドラインとして設けることは悪いことではありません。そういう意味で、当然のことながら基準が設けられていること自体に問題があるということではありません。

しかしながらプログラムのバグというものは決してステップ数（プログラムの行数）に比例するとは限らないことは、プログラマーであれば誰でも理解できることです。

プログラムの読みやすさ（可読性）を向上させればプログラムの品質は向上してバグは少なくなりますが、プログラムの可読性を向上させようとするとステップ数が増えることは当たり前のようにあります。

また将来的な仕様変更や機能拡張のやりやすさ（拡張性）を向上させれば、システム運用開始後のメンテナンスがやりやすくなり、仕様変更が生じた時にも少ない工数で容易に対応できるようになりますが、プログラムの拡張性を向上させようとするとステップ数が増えることは当たり前のようにあります。

またシステム開発で使用されるプログラミング言語やフレームワークには様々なものがありますし、システムの仕様の複雑度によっても必要なテスト数や検出されるバグ数は大きく変わってくることは当たり前のことです。

https://twitter.com/hassy_se/status/895573610189934592

一概にバグ検出数の基準値を設けることなど非常に難しいことですし、そもそも最近のシステム開発では部分的にプログラムのソースコードを自動生成することは頻繁にあり、そのようなツールも多々あるのです。機械的に自動生成されるわけですから、自動生成のツールによって生成されたソースコードにはバグが存在しないと考えることが普通です。

しかしながら、このように自動生成されてバグが検出されるはずがないようなプログラムに対しても、ステップ数によるバグ検出数の基準なるものが押し付けられることが客先常駐の現場では普通にあります。

定められた基準を満たすバグ数に達しないとこのように報告書を書かされることもあります。

こういったことを私自身も１０年以上前のフリーランス時代には行っていたわけですが、客先常駐の開発から離れてかなり時間が経ちましたし、さすがにこんなことは今では行われていないだろうと思っていたら１０年前と全然変わっていないようです。

なぜSI企業はステップ数による基準を設けるのか

ステップ数によるバグ検出数の基準なるものを設けるのは、プロジェクトの元請けとなっているSI企業です。

多重下請構造

多重下請構造

この多重下請け構造の上の方にいる元請け企業は、プロジェクト管理を行うのみでプログラミングを伴うシステム開発業務は行わないことが多いです。技術的なことには一切かかわらずにノータッチであることが多いので、IT企業でシステム開発を行う会社の人間であるにも関わらず、技術的な難しいことはほとんどわからない人達が大勢います。

そうするとプログラムの中身を理解した上でその品質を評価することなどできませんから、技術的なことはよくわからない彼らでもプログラムの品質評価を可能な限り客観的に行えるようにしようとして生み出されてきたものが、「ステップ数によるバグ検出数の基準」なのではないでしょうか。

プログラムの行数が１０００行だったらバグ１件以上、２０００件だったら２件以上出てなければプログラムの試験が適切に行われていない、というような画一的な基準であれば、技術的なノウハウが一切ない人間にも理解することが可能になります。

SI企業の多くの人達はプログラムのことがわからない技術的には素人同然の人達なので、彼らがプログラムを評価しようと考えた時に素人でもわかるような基準が必要なのでしょう。

基準を作る人達と基準を運用する人達の間に距離がありすぎる

専門的なプログラム知識がない人達でも理解できるようにある定められた評価基準を設けたり、どんなメンバー構成でも一定の品質基準が担保されるように基準を設けること自体は悪いことではないと思います。

では客先常駐の現場で運用されているこのような評価基準の何が問題なのかというと、基準を作る人達と基準を運用する人達の間に距離がありすぎることなのだと思います。

客先常駐の現場で運用されている「ステップ数によるバグ検出数の基準」を作るのは元請けとなっているSI企業の偉い人達です。一方でそれを実際に現場で運用するのは下請け企業のエンジニア達になります。

普通は現場で運用されている何かしらのルールが現場の実情に沿わずに問題がある場合は、適宜ルールを改定して現場の実情に合うように改善されていくものです。しかし多重下請けの客先常駐のプロジェクトではそういう訳にはいきません。

現場にいるエンジニアが実情に沿わないからルールの改善が必要だと訴えたところで、訴える先は別の会社の人間になりますし、SI企業は個別のプロジェクトで別の会社の人間が何かを叫んでいたところでそんな声に耳を傾けたりはしないでしょう。

客先常駐でプロジェクト管理のために派遣されているSI企業の人間としても、自分達には何が正しいか判別するだけの技術力はありませんから、そうすると自分が所属する会社から指定されている基準を満たそうと行動することは当然のことと言えます。

例外を認めず現行のルールを遵守しようとするその姿勢は、企業側からすれば優良な社員と見ることができますね。SI企業側の人間として自分の会社の運用基準を遵守しようとしているだけなのですから、何も責められるようないわれはありません。

私も客先常駐のシステム開発を行っていた時は、いくら合理的に説明しても取り合ってもらえないSI企業の人達に対して、こいつらなんて頭が堅いんだと不条理に感じたものですが、彼らの立場からするとルールを守ることの方が正しかったのだと今では思います。現場の彼らが悪いのではなく、多重下請け構造の客先常駐という構造の問題です。

元請けの大手SI企業の人達が技術的なスキルを習得するように方針転換すれば少しは変わるかもしれませんがそうはならないでしょうから、今のこの構造のままでは基準を作る側と運用する側の距離が乖離した状態を解消することは不可能だと思われます。

延々とあまりにも無駄過ぎることが続けられる毎日

プログラミングの実装を担当するエンジニアとしては、どう考えてもテストの必要のないコード、バグが検出されることはないはずのコードというものは存在するのですが、それをいくらSI企業の人達に説明したところで取り合ってもらえないとなると、どうにかして別の方法を考えるしかなくなってしまいます。

プログラマーであれば自動生成されたgetterやsetterにバグが入り込むような余地はないことは全会一致だと思うのですが、SI企業の方達にはその理屈は通用しないことがありますので、その場合は泣きながらバグが出るはずがないソースコードに対して単調な作業を受け入れるしかありません。

しかもステップ数に対して一定のバグが検出されないと通過できませんから、その場合は無駄な報告書を書かされたり、それが嫌だからバグの捏造をすることも行われます。

https://twitter.com/g_ino_plus/status/895552861324550144

これが客先常駐のシステム開発現場で昔から行われていることであり、今となっても改められることもなく続けられていることなのです。必要のないものをわざわざ水増しまで行われているこの現実。こうしたことを改めるだけでも一体どれだけの残業が削減できることか。。

必要な作業による残業ではなく、本来やらなくて良い無駄な作業を行うための残業によって、現場のエンジニアがどれだけ精神的に疲弊することか。。客先常駐の現場はこんな状態ですので働き方改革など夢のまた夢の話です。

無駄を削減するためには企業ごとの役割分担の明確化が必要

以上述べてきたような無駄を無くすためには、企業ごとの役割分担の明確化が必要だと思います。プログラミングを行わないSI企業がプログラムレベルの試験や品質に関して介入してくるからこのようなおかしなことになってしまうのだと思います。

プログラミングを行わない元請け企業であるSI企業は、プログラムレベルの試験などには介入せずに、もっと上位の結合試験等のフェーズだけ行えば良いと思います。プログラムの試験のバグ検出数のような基準を作るのであれば、実際にプログラムを実装している企業が現場の実情に合わせて基準を作るべきです。

そしてこの問題の根っこにあるのは多重下請け構造による偽装請負に問題があることは明らかでしょう。客先常駐で同じ現場で他の会社の人間から指揮命令が当たり前に行われるから、基準を作る人と基準を運用する人が乖離するような問題も起きやすいのです。

企業ごとの役割分担が明確化されていれば一緒の現場で客先常駐の形でシステム開発を行う必要も無いはずです。多重下請け構造による偽装請負、客先常駐の問題を解決することで、IT業界からかなりの無駄が削減され、生産性は飛躍的に向上するのではないでしょうか。

アクシアでは一緒に働くメンバーを募集しています

アクシアは残業ゼロ、完全在宅勤務、有給消化率100％の取り組みを行っている会社です。
裁量を持つ機会が多く、エンジニアとして、ビジネスマンとしての仕事力が高められる環境です。
エンジニア経験者だけでなく、実務未経験者も積極的に採用しています。ポートフォリオや制作物がありましたら、ぜひ拝見させてください。
私たちと一緒に「らしく」働いてみませんか。

アクシアの特徴と経営理念
こんなエンジニアと働きたい
募集要項

「まずは詳細な資料が欲しい」という方は 資料ダウンロードはこちら
米村 歩

米村 歩

株式会社アクシア　代表取締役

株式会社アクシア代表取締役。中堅ソフトウエア、フリーランスを経て株式会社アクシアを設立。２０１２年まではアクシアでも長時間労働が常態化していたが、２０１２年１０月から残業ゼロを継続中。２０１７年３月にはホワイト企業アワードの労働時間削減部門で大賞受賞。

ページ上部へ戻る