ソフトウェアエンジニアが労働について情報発信するブログ

ブラック労働からホワイト労働まで経験したソフトウェアエンジニアが世の中にとって役立つことを情報発信していく。

ソフトウェア開発を簡単そうに語る人は注意が必要

当ブログではアフィリエイト広告を利用しています

「ソフトウェア開発」は色々と苦労することが多いのだが、なぜか簡単に捉えられてしまうことが多い。熟練者ほどその難しさを知っており、あまり熟練していない人ほど簡単と考える傾向がある。

そのため、本来高い能力を発揮しているにもかかわらず、周囲にそのパフォーマンスの高さを理解できる人がいないことで正当に評価されることが無く、困っているソフトウェアエンジニアは少なくないのだろうと思われる。

また、「ソフトウェア開発」が簡単と周囲から思われていることと、自分自身が苦労している状況から、真面目な人ほど「自分はまだまだスキル不足である」と思い込み、自信ややりがいを見失っているソフトウェアエンジニアもいるのではないだろうか?

逆に「ソフトウェア開発」を甘く見ている人は、この記事を読んでそうではないことをインプットしていただきたい。そして、「ソフトウェア」が創出する価値を知り、「ソフトウェアエンジニア」の活躍が正当に評価される社会にすべきではないだろうか。


1. プログラムコードを全て一人で理解することなど不可能である

ソフトウェア開発は難しい。ソフトウェアは抽象的で目に見えないものであり、未経験の人にはわからない世界である。一方、経験者であっても一つの製品・システム(自動車、家電、医療、FA、・・・)のなかの一つのサブシステムのプログラムコードでも数十万行もあるなど、一人の人間がすべてを理解することなど到底不可能なレベルである。

また、ソフトウェア開発を大きく二つに分けると「新規開発」と「派生開発」がある。世の中のソフトウェア開発の95%以上は「派生開発」と言われており、「新規開発」を一度も経験したことがないソフトウェア技術者も珍しくない。

ここでは「派生開発」について言及していく。「派生開発」とはベースとなる製品のソフトウェアを元に変更や改良を重ね、新たな製品のソフトウェアを開発するスタイルのことである。一般にソフトウェア開発は、開発に使用するプログラミング言語に関する知識のみならず、要求仕様を理解しなければならない他、組み込みシステムであれば使用するマイコン等デバイスに関する知識、ネットワークシステムであればネットワークやセキュリティに関する知識が必要である。これに加えて派生開発の場合は、ベースとなる製品のソフトウェアの解析が必要である。特に追加変更による影響度の調査、変化点と合わせて他に変更すべき箇所がないか、既存の処理に影響がないかといった点の検証に工数を要するため、新規開発よりも難しい場合がある

2. 設計資料があるからと言って開発が円滑に進むとは限らない

「設計書や資料が十分にあるから短いスケジュールで簡単にできる」と考えている人がいるが、一部は正しい。プログラムのソースコードしかない状態と比べると、ソフトウェアの概要を把握でき、それ元に詳細の理解が深まるという点では、その通りだろう。

しかし、設計書や資料のボリュームが多いと、インプットする量も多く、対象のシステムを短い時間で深く理解することが難しい。必要な箇所や知りたい箇所がすぐに見つからないことがある。

設計資料が作成された当時のプロジェクトが、スケジュールに余裕がなく資料が雑なものであったり、誤記があったり、資料間の矛盾に遭遇した場合の解決に、何が正しいのかを判断するために時間を要することもある。

資料の精度や粒度によっては、製品やシステムの仕様をある程度わかっている人や、その製品の開発に慣れている人が見ると、より詳細を思い出すことができる。しかし、初めてプロジェクトに参加した人や不慣れな人がそれを見ても理解できるとは限らないどころか、理解に時間がかかるケースが大半だ。

目的に沿った設計資料でなければならないし、ソフトウェアの細部まで全てが設計資料に記載されているとは限らない。

ベース製品開発時の状況がブラック労働だったならば、その時に作成した設計書やソースコードの精度はあまり良いものではない可能性が高い。ベース製品の設計書を作成した時に後にどのような変更が入るかそのときは予想できないし、その設計書がどこまで配慮されたものなのかは、ばらつきがある。また、スケジュールに余裕がない時に、とにかく動くソフトウェアを作成することを優先し、設計書や仕様書の更新が後手後手になって最悪漏れることはよくあることだ。

実際過去にあった事例としては、設計書や資料は十分にあるからと言って

  • 「簡単にできるはず!」
  • 「なぜそんなにかかるのですか?」

と短いスケジュールでの完成をしつこく要求してくる顧客がいる。詐欺商法の手口と全く同じである。
o08usyu7231.hatenablog.com

一方、依頼者側のスキル不足もある。例えば、デバイスの変更する変更案件の際に、デバイスアクセスのインターフェイスを変更するだけと認識していたが、実際によく調べるとデバイスアクセス周辺の状態遷移図を全て見直さなければいけないこともあった。

3. ソフトウェアの「移植」は簡単とは限らない

ソフトウェア開発の中には「移植」というものが存在する。「移植」とは、他の製品で既に使用されているソフトウェアを現在開発中のソフトウェアへ流用することを言う。このような移植の際にも「移植するだけ」とか 「持ってくるだけ」とかいかにも簡単そうに言う要求元がいる。

実際にはプログラムコードをそのまま「移植」できる場合もあれば、そうでない場合もある。「移植」の見本とした製品ではそのプログラムコードで問題なかったとしても、移植先の製品では同じプログラムコードでは問題が出るケースもある。

「横展開」という言葉も同じである。要求仕様の「横展開」なのか、ソフトウェア設計の「横展開」なのか、この二つを比べても全く異なる。依頼元は要求仕様の「横展開」と認識していても、ベースのソフトウェアの設計が異なるプログラムコードはそのまま「横展開」というわけにはいかない場合もある。

4. 優良企業ほどリスクに備えており姿勢が謙虚である

これらのことをよく理解していない要求元の感覚でスケジュールを作成すると、必要な工数に対して大幅に不足する形となり、十分な設計検証が行われず成果物の品質が低下する恐れや、ソフトウェア開発技術者における労働環境の悪化が懸念される。
o08usyu7231.hatenablog.com

実際これまでの私の経験では、ソフトウェアを簡単だと考えている依頼元から受けた案件は、高い確率で過重労働になりやすい。(多重下請け構造丸投げが当たり前の体質であるプロジェクトが特に該当する。) 一方で優良企業においては、ソフトウェアを変更することに対するリスクに敏感であり、とても姿勢が謙虚である。後者のほうがソフトウェアのプロフェッショナルであるという印象を受ける。

ソフトウェア開発の簡単だと語る人は、その人が慣れた製品や馴染みのあるソースコードを長年扱ってきた感覚を、全てのケースに適用しているだけかもしれない。一見技術力が高そうに感じられるが、実際そのようなことは皆無であった。また開発中のトラブルが多い企業ほどトラブルやリスクを想定していない。テクニカルスキルが高くても、マネジメントが未熟である可能性が高い。

ソフトウェア開発を簡単そうに語る人は、技術力があるのではなくソフトウェア開発の素人であるか、マネジメントが未熟だと疑ってみる必要がある。

転職ドラフトは年収UP率93.8% / 平均年収UP額126万円と圧倒的な年収UP率を誇るエンジニア向け転職サービスです。審査に通過した優良IT/Web系企業約150社が参加しており、企業がダイレクトスカウトを行うため、質の高いマッチングにより、前述のような高い年収UP率を実現しています。「現年収を元に内定年収が決まる」ことは一般の転職エージェントにありがちですが、こちらは現年収非公開で転職が可能であり、スカウト時点で内定年収を提示いただけるため、求職者にとってありがたく、効率の良い転職活動が可能となります。年収アップを目指したい方は、是非ご検討されてはいかがでしょうか?




今の時代、製品やシステムに「価値」を提供するのは「ソフトウェア」である。「ハードウェア」もなくてはならないが、「ソフトウェア」が主流になりつつある。これが世界標準である。日本は元々製造業が強かった背景から「ハードウェア」にこそ価値があり、「IT」「ソフトウェア」は業務効率化のためのツール程度であると軽視してきた。この結果、日本の製造業は世界から遅れを取っているのである。

× 「ソフトウェア」は「ハードウェア」のおまけである
〇 「ソフトウェア」が「ハードウェア」を動かし価値を提供する

これからは発想の転換が必要だ。世界標準は既に進んでいる。以下の書籍を参考にしてほしい。