ソフトウェア開発のほとんどは派生開発であり、新規開発は入社後一度も経験していないエンジニアも少なくない。
派生開発ではベースとなる製品があり、これに機能追加や機能変更、不具合修正をソフトウェアによって実現することで新製品を世に出すわけだが、避けて通れないのはソースコード解析である。
このソースコード解析は、その製品についての知見が無い人にとっては大変な作業であるにもかかわらず、これを外注に安い金額で丸投げするケースもある。
この記事では、ソースコード解析を主な作業とするプロジェクトの例をいくつか挙げ、解析に必要なスキルと、発注元企業の資質の見抜き方について紹介する。
1.ソースコード解析を外注に発注するのは自社にソースコード解析ができるエンジニアがいない証拠
ソースコード解析を中心とする案件を、私はいくつか受注したことがある。ソースコードの解析というのは、簡単なものではない。いくらソースコードに使用している言語に精通していても、そもそもどのような製品で、どこで何の処理をしているかを正確にとらえるのは極めて困難なものである。また、仕様書や設計書には表れない隠れた仕様、隠れた要求、定数設定で一部の処理が無効化されている、複数の潜在不具合が偶然調和し製品の挙動に現れていないケースなど、背景を知らないエンジニアが対応するには、ただならぬ労力を必要とする。
本来、メーカーが世に出している製品（システム）のソフトウェアは、そのメーカーの社員が理解しているべきである。解析するにもメーカーの社員が行うべきであるし、それくらいの高度な技術を持ったソフトウェアエンジニアをメーカー企業が保有しておくべきなのである。
しかし、そのようなエンジニアを保有していない企業はSIer等外注企業の支援のもと進めていくしかないのだが、「外注に丸投げしていれば完璧にやってくれる」と勘違いした発注元がいるから困ったものだ。
しかも、ソースコードの解析の難しさを知らない発注元にとっては、ソースコード解析を「定型業務」「流れ作業」のように捉え、発注先の高い技術力を正しく評価することなく、多大な恩恵を受けているにも関わらず、そのことを認識しないまま発注が進められたりするのである。
ソースコード解析を外注に発注するのは、多くの場合自社にソースコード解析ができるエンジニアがいない証拠である。発注先の支援を受けながら共同作業で進めるならまだしも、発注先に「定型業務」のように丸投げし、できて当たり前と考えるのはもってのほかであることを、発注元・発注先共に知っておくべきである。
2.ソースコード解析の丸投げを受託した事例
ソースコード解析の丸投げを受託した事例を３点紹介する。
<<事例１>> 特殊用途向けシステム再構築のほぼすべてを丸投げ
ある下請けIT企業Ａ社は大手メーカーＢ社から、旧システムの老朽化に伴い、新システムを再構築するプロジェクトを受注した。このシステムは特殊用途向けのものであり、一般消費者が使用するものではない。そのため、いくら他のシステム開発で多大な実績を残しているエンジニアでも、本システムへの深い理解が無い人にとっては、かなり難度が高いものである。
旧システムは構築された時期がかなり古く特殊なプログラム言語Ｌで記述されている。これを解析し、Ｂ社標準の記法に従った詳細設計書（ブロック図）に変換し、最終的には現在組み込みシステムで多く使用されている「Ｃ言語」でプログラミングを行うものだ。
プログラム言語Ｌの有識者は、Ａ社にもＢ社にもいない。旧システムの有識者はＢ社内のプロジェクトメンバーにはおらず、Ｂ社独自のルールで記述された簡易設計書をＢ社内の別事業所から入手した程度である。完全無知見の中でプロジェクトがスタートする。
Ａ社エンジニアはプログラム言語Ｌを勉強し、旧システムに関するプログラムコードとＢ社独自のルールで記載された簡易設計書のみを頼りに解析をはじめた。Ａ社エンジニアとしては訳のわからないプログラム言語から、Ｂ社標準の記法に従った詳細設計書（ブロック図）を起こすのは、ある意味記号の置き換えと言っても過言ではない徒労な作業をこなしていった。
本プロジェクトではＡ社とＢ社は委任契約であるが、実態は完全な丸投げとなる。プロジェクト期間中も完成のイメージや目途がなかなか立たず、Ａ社エンジニアにとってはプロジェクトの計画の妥当性を疑うことが度々あった。更に、旧システムのプログラム解析中も、更にシステム構成の追加調査等、作業が増加した。しかし、Ａ社のエンジニアの中の優秀な人材が活躍し、残業・休日出勤・一時的なリソース追加により完成させた。
Ａ社の管理職、Ｂ社の窓口担当は、このプロジェクトがどれほど困難なものであるかを理解しておらず、「解析して詳細設計書（ブロック図）を順次起こしていく流れ作業」といったイメージで、特に感謝やねぎらいの言葉も見当たらなかった。Ｂ社の窓口担当においては、Ａ社エンジニアに対して度々高圧的な態度が見られた。
<<事例２>> 市場品質問題の原因究明に向けた共同作業
ある下請けIT企業Ｃ社は製品メーカーＤ社から、現在市場に流通している製品のソースコードを解析し、設計書を作成し納品するプロジェクトを受注した。本製品は現在組み込みシステムで多く使用されている「Ｃ言語」でプログラミングされており、製品の構成や振る舞いを記載した簡易の仕様書、その製品に内蔵している基板の回路図も併せて入手した。
このソースコードはＣ社とは異なるＤ社の外注先が作成したものであり、Ｄ社にソースコードを解析できるエンジニアが退職して不在となったため、Ｃ社に解析を依頼することとなった。このプロジェクトの本来の目的は、当該製品で稀に発生する不具合事象の原因究明であった。その前段として当該製品の設計書が存在しなかったため、ソースコードを解析して設計書を立ち上げようというのである。
Ｃ社ではエンジニア１人でこのプロジェクトを進めた。Ｄ社はＣ社とは異なる外注先が作成したソースコードの解析をＣ社に発注しているため、本当に順調に解析が進んでいるか心配そうに気を使う場面があった。
また、すべてのソースコードを解析することは依頼元のＤ社も事実上不可能とわかっており、ある程度解析が進めば、本来の目的である市場で発生している不具合原因究明に向けて、関連が深い部分を重点的に解析していくという形で、調査結果により適宜以降の調査の方向性を両社で合意しながら進めていった。
不具合原因究明は難航するも、元々契約内容であったＣ社からＤ社への設計書の納品は不備なく行われた。トラブルの発生もなく、Ｃ社のエンジニアはＤ社から感謝の言葉を受けた。
<<事例３>> 製品知識が無くても新技術対応に専念できる体制作り
あるメーカー企業Ｅ社の新製品開発プロジェクトにおいて、複数のサブシステム同士で新しい通信技術を導入する必要が生じた。本プロジェクトでは既存のメンバーではリソース面、スキル面ともに不足しており、新たにIT企業のＦ社からエンジニアを派遣した。更に新しい通信技術の導入については、Ｇ社より通信ドライバソフトウェアを購入し、製品に組み込むことにした。
Ｅ社のプロジェクトリーダーは、Ｆ社からの派遣エンジニアに、Ｇ社製通信ドライバソフトウェアの解析と、開発中の新製品への組み込み（通信ドライバソフトウェアの改造を含む）を依頼した。
Ｆ社の派遣エンジニアは新製品の製品知識については乏しいが、過去に様々な開発プロジェクトでの実績を持つ。Ｅ社は、新しい通信技術の導入以外の製品開発についてはＥ社のメンバーで行い、新しい通信技術の導入を派遣エンジニアが専念する開発体制とした。すなわち、派遣エンジニアは製品固有の知識が乏しくても、このプロジェクトに十分参画できるのである。
以降、このプロジェクトは新しい通信技術の導入を含め、無事完了した。Ｇ社製通信ドライバソフトウェアのソースコード解析を含めた新しい通信技術の導入は、ほぼ派遣エンジニアへの丸投げとなったが、派遣エンジニアが保有する技術力により順調に進捗し、Ｅ社の中で高く評価された。
3.ソースコード解析の丸投げを受託した事例に対する評価
ソースコード解析の丸投げを受託した事例３点に対し、それぞれの依頼側に対する評価について述べる。
ちなみに、この３事例とも丸投げされたソースコードを解析したエンジニアはいずれも同一人物である。
また、言うまでもなく、ソースコード解析を依頼する側の資質、あるべき姿勢として、最も悪いのは<<事例１>>、最も良いのは<<事例３>>である。
<<事例１>> 特殊用途向けシステム再構築のほぼすべてを丸投げ
そもそも、Ｂ社独自の旧システムから機械的な置き換えで事足りるものなら、外注に発注するという選択肢はある。しかし、このプロジェクトは下請に丸投げするような案件ではない。
まず、発注元のＢ社は旧システムの分かる人材に協力を得る、Ｂ社内のエンジニアがしっかり理解を深めるといったことが必要である。その上で、発注先をコントロールし再構築を進めること、Ａ社がプログラム言語Ｌの解析に専念できるような「前段」を整えることが必要である。
仮にそれが困難でどうしても丸投げせざるを得ない状況ならば、更なる長期期間の確保、更なる高い開発費の支払い、Ａ社エンジニアに対する敬意が求められる。
にも関わらず、丸投げ、圧力をもってのコントロール等、発注元であるＢ社担当者の未熟ぶりが散見された。
Ｂ社担当者は、Ｂ社上司より、
- 「予算の使い過ぎ！」
- 「なんでもかんでもＡ社に丸投げするな！」
- 「お前ができる作業はお前がやれ！」
とお叱りを受けている。ごもっともだ。
Ｂ社だけではない。このプロジェクトを受注したＡ社管理職にも問題がある。
Ａ社管理職は、このプロジェクトの新規性や難度を理解しておらず、受注時に設定したプロジェクトの期間が適切であるか否かをどのように見極めたのか全く根拠がなく疑問だ。Ｂ社から要求を受けるがまま言いなりだったかもしれない。プロジェクトにおける作業についても、あたかも「順次解析作業を進めていく」くらいの感覚でしかないようだ。初めて扱う製品のソースコード解析とは想像以上に難しく、高いスキルが必要なのである。技術力がある人間こそ、その大変さが分かるはずなのに、Ａ社エンジニアの苦労を分からず、努力や成果を軽視している。また、管理職自らが作業をしているわけではないにもかかわらず、あたかも中身を簡単そうに語る点が、対象業務を甘く見ていると感じられる。
このようなＡ社管理職の姿勢は、エンジニアがいくら頑張っても何も報われず、Ａ社エンジニアのモチベーションを下げている要因になっている。エンジニアの苦労を分からず、モチベーションを下げている点から、Ａ社管理職は（例え自分自身の技術力は高くても）マネジメントが未熟であることは確実だ。労力を使い果たす割には報われず、成長にもつながらず、顧客であるＢ社要求をの言いなりになり、売上達成のためだけに受注するといった安易さが、Ａ社エンジニアのキャリアを左右することとなる。
<<事例２>> 市場品質問題の原因究明に向けた共同作業
私自身を含め多くの方が疑問に持つと思うのだが、Ｄ社製品の市場不具合が発生していることから、ソフトウェアの不具合原因究明はソフトウェアの作成元、即ちＣ社と異なるＤ社の外注先が行なうのが一般的である。
このソフトウェア作成元の外注先は、Ｄ社と取引がなくなったのか、潰れてしまったのかは不明であるが、他社が市場不具合を埋め込んだソースコードをＣ社が解析するとなると、Ｃ社エンジニアとしては非常に気の毒だろう。
Ｄ社はＣ社に対してその点気を使っているようであり、Ｃ社に無理な要求はせず、ソースコードの解析依頼こそ丸投げであるものの、現実的な範囲で段階的に調査を進め、不具合原因究明に向けての進め方を議論し、Ｃ社・Ｄ社共同で進めていった点については好感が持てる。
しかし、前章の文中にもあるようにＤ社からソースコードを解析できるエンジニアが退職し、不在になってしまったことは深刻な問題であり、Ｄ社として危機感を持つべき課題でもある。
<<事例３>> 製品知識が無くても新技術対応に専念できる体制作り
この事例はＥ社の開発要員（リソース）の不足を、Ｇ社製通信ドライバソフトウェアの購入と、Ｆ社からの派遣エンジニアによるソースコード解析および組み込みによって賄ったものである。
新しい通信技術を導入したことについては、ほぼ派遣エンジニアに丸投げになったものの、Ｅ社社員は「丸投げをしている（イレギュラーである）」との認識を持っており、Ｆ社派遣エンジニアが保有するスキル以外に、Ｆ社派遣エンジニアの作業に関して十分な工数を確保したことと、新しい通信技術の導入の部分に専念させる作業配分を行ったことが、このプロジェクトの成功への鍵であろう。
Ｅ社は製品開発に当たりソフトウェアの作成を可能な限りＥ社メンバーで行っている。ソフトウェア開発の難しさを分かっており、新しい通信技術を導入に対しては本プロジェクト内でも重点項目として管理するなど手厚い進め方を計画していた。その中でＦ社派遣エンジニアが難なく業務をこなしたことが、Ｅ社の中でインパクトが大きかったのだろう。
新しい通信技術の導入、購入したドライバソフトの解析には、高いスキルが求められることを、Ｅ社はしっかりとわかっていたのである。
4.メーカー企業はソフトウェアエンジニアを保有し、高い報酬を用意すべき
これまで事例を述べてきたように、ソフトウェアのソースコード解析には高いスキルが求められるのである。解析作業をする人にとって不慣れな製品となると、その難度はより一層増すこととなり、多大な労力を要する。これを外注へ丸投げする際は、その進め方について慎重に検討する必要がある。
ソースコード解析による製品仕様のスペックアウトを外注に依頼する場合、発注側が主体となり共同作業で行い、受注側はソースコード解析に専念できる体制を作ることが求められる。「定型作業」「流れ作業」のような簡単なものではない。
「発注先はソフトウェア解析のプロだから丸投げすれば完璧にやってくれる」という感覚は危険だ。何の「プロ」であるかを正しく認識し上で、「対象製品のプロ」「対象システムのプロ」と「ソフトウェア開発のプロ」「ソースコード解析のプロ」が協調し、初めて対象のプロジェクトが円滑に進むのである。
ましてや、高いスキルを必要とするソースコード解析を、下請け企業に安い賃金で発注するなど、発注元がリスクを抱えることになるとともに、発注元の恥であると考えるべきである。
更に重要なことは、発注元は本来自社でソフトウェアエンジニアを確保しておき、製品のソフトウェアを自社内で理解しておくべきである。
「ソフトウェア・ファースト」の考え方にもあるとおり、これからはソフトウェアが製品の中心であり、ソフトウェアが事業活動の主流の時代である。日本はこれまでモノ・ハードウェア中心の開発で、IT・ソフトウェアはそのおまけ程度のものとして、軽視されていた。これが、日本の製造業にとって海外から大きく遅れを取った理由である。その典型の一つとして、ソフトウェアのソースコード解析を外注に丸投げすることが行われていると言えよう。
更に、ソフトウェア及びソフトウェアエンジニアを軽視せず、それなりに高い報酬にしないと、優秀なソフトウェアエンジニアの確保は困難になる。高いスキルが求められる割には、賃金が安い、努力が報われない、そんな企業に優秀な人材は集まらない。
そのような時代であるため、本記事の事例を参考に、ソースコード解析丸投げに限らず、高いスキルを保有しながら粗悪な扱いを受け、報われない優秀なエンジニア、及び粗悪な条件でソースコード解析の丸投げを受けたにもかかわらず見事に成し遂げた実績のあるエンジニアは、もっと良い環境を求めて転職することを視野に入れても良いのではないだろうか。
入学から卒業まで受講生に専属の講師が付き、一人一人の目的に合わせたオーダーメイドカリキュラムに対応するのみならず、転職、就職、案件獲得までサポート！
オンラインが基本であるため地方在住の方でも安心して受講いただけます。あなたの人生を変える一歩を踏み出してみませんか！
