カテゴリー
エンジニアキャリア システム開発全般

ハードウェア開発とソフトウェア開発の違い

私は大学院と機械系の専攻をしていて大学院を卒業した後、最初のキャリアとして2年半、家電メーカーで機械設計エンジニアとして働いていました。

その後、2度の転職を経てWeb エンジニアになった後、独立して今に至ります。家電メーカーの機械設計エンジニアとWeb エンジニアについて、どちらもエンジニアという括りですが、ハードウェアのエンジニアとソフトウェアのエンジニアでは業務は全く異なります。本記事ではその違いについて書こうと思います。

機構設計というのは家電や自動車などの製品の機械部品を設計する仕事です。製品のデザインを決める外装や、内部構造を決める金属やプラスチック製の部品、またコードなどの付属品を決めます。2次元や3次元のCAD(3Dモデルを作成したり、2次元図面を作成するソフトウェア) を用いて、要件を満たす部品の構造や形状、素材や加工方法などを設計していました。

一方、プログラマーやシステムエンジニアは、ソフトウェアを開発する仕事です。要件定義によって決定した仕様をもとに設計を行い、設計された機能をプログラミングによって実装します。

私の経験をもとに体験したハードウェア開発とソフトウェア開発の違いを表にまとめてみました。

ハードウェア開発とソフトウェア開発業務の違い

ハードウェア開発ソフトウェア開発
1実際に形がある(物理的な制約を受ける)物理的な制約がほとんどない
2製造物にばらつきがある実行環境で差はあるが、ばらつきは少ない
3デリバリーが必要で、リードタイムが長いデリバリーはネット経由
4さまざまな規格があり、準拠する必要がある規格は存在するが、ハードウェアほど多くない
5法律的な制約がより厳しい法律的な制約は少ない
6技術革新のスピードは比較的緩やか技術革新のスピードが非常に早い
1.実際に形がある(物理的な制約を受ける)

アプリやWebサイトなど、ソフトウェアの場合は形がありません。基本的に作成したものは、スマートフォンやパソコンのディスプレイに表示されたり、それらコンピュータの内部で電気信号として動作します。

しかしハードウェアの開発では、最終的な成果物として実際に質量をもち、形状をともなったモノがつくられます。実際に形があるモノは、サイズ、重量、形状、素材などによって様々な物理的制約をうけます。

サイズや重量が大きければ、移動が困難になるし、設置・保管場所にもより広い場所が求められます。形状によって、壊れやすさや持ちやすさが変わるし、怪我をしないように鋭利な部分が無いようにする必要があります。素材によって、腐食や劣化を防ぐ考慮も必要です。

ソフトウェアの場合は、ディスプレイのような表示装置のサイズやキーボードやタッチパネルのような入力装置の制約はあるものの、ハードウェアに比べて物理的な制約は非常に少ないです。置き場所の心配や腐食する心配をする必要はありません。

2.製造物にばらつきがある

あるソフトウェアを配布した場合、実行環境、スペックの高いスマートフォンと低いスマートフォンでの実行によって、性能に差がでるもののプログラムの内部は配布されたすべてで同じになります。

しかしハードウェアの場合、大量生産された製品は見た目が同じであっても、すべての製品が少しずつ差異があります。設計上は同一になっていても、実際に製造された製品を構成する各部品には、わずかに仕上がりの形状や品質にばらつき生じてしまうからです。そのため、ハードウェアの設計では、ばらつきをコントロールしたり、一定のばらつきが存在しても製品が問題を起こさないように考慮する必要があります。

3.デリバリー(配達)が必要で、リードタイム(納期)が長い

インターネットが普及した現在において、ソフトウェアの配布はネット経由でダウンロードさせることが簡単にできます。

ハードウェアの場合は、部品の調達→生産会社、部門での組立・製造→自社への納品→ユーザーへの配送、というデリバリーが常に発生します。製品に不具合があり、返品や交換の対応をする際にはユーザーから自社への送付という逆のながれも生じ、その度に大きな発送・受領の大きな手間が必要になります。

4.さまざまな規格がある

ハードウェアの設計の際には、様々な規格へ準拠する必要があります。JISのような工業規格があり、自社で決めている規格や、BtoBで納品先がある場合その納品の規格に従うことも必要です。それなりの規模の会社になると必ず技術的規格もっています。規格に従うことで、汎用的な部品や設備の使用が可能になったり、発注先や納品先などの取引先とのやりとりにかかる時間や手間を削減することができます。

5.法律的な規制がより厳しい。業界的な自主規制もある。

また、国や自治体によって定められた環境負荷物質やリサイクル、電源や電波法など。国外に輸出する場合には、輸出先の法律による規制もあります。

また特許で守られている技術もあるため、新しい機能や形状を試みる場合には、他社の特許を侵害する可能性がないか調査する必要があります。逆に、他社の特許にふれず新規性や進歩性があるものについては、それに関する特許を出願することもあります。

6.技術革新のスピードが緩やか

ハードウェアの開発では、ここまでで記載してきたような多くの制約が存在するため、技術革新のスピードは緩やかだと言えます。ネジについて誰よりも詳しいこの道30年の職人的社員みたいな人が重宝されたりします。

ソフトウェア開発だと、一時もてはやされた最新技術が2~3年で陳腐化してしまうことは、当然のようにおきますし、あらゆるソフトウェアはアップデートされていくので10年以上用いられるそのまま使える技術のほうが稀です。

制約が多い難しさ、少ない難しさ

ハードウェアの開発は制約が非常に多いです。なにか物を開発する場合、それら多くの制約を把握して、制約を回避しなければなりません。またどの工程においても費用や時間がかかるため、失敗に対する許容度が低く、慎重に工程を進めてゆく必要があります。自動車のリコールのニュースは度たび目にすることがありますが、担当エンジニアの青ざめる顔が思い浮かび、身につまされる思いがします、、。

ソフトウェアの開発は、ハードウェアのような制約が少ないですが、制約が少ないことによる困難も数多く存在します。ソフトウェアは見た目から、内部の構造を知ることはできません。シンプルなソフトウェアに見えても、内部的に非常に複雑な動きをしている可能性もあります。

自由度の高さ故に常に新しい技術が登場し、一度獲得した知識やスキルもすぐに陳腐化してしまう可能性があります。また一度開発したソフトウェアも、コンピューターの性能向上や新技術登場や周辺技術の進歩、に合わせて更新してゆかなければなりません。

本質的な部分の考え方は同じ

求められるスキルや使用する技術の点では、全く異なるハードウェアとソフトウェアのエンジニアですが、より本質的な部分での考え方は共通していると思っています。課題や目的に対して、課題解決や目的の達成に必要な要件を導き出し、それを出来るだけシンプルに技術を用いて実現することです。ソフトウェアとハードウェアの開発の違いはその、その時にあるルールや制約がソフトウェアに起因するものなのか、ハードウェアに起因するものなのかにということです。

カテゴリー
システム開発全般 プログラミング

プログラミングにおけるエントロピー増大について

エントロピー増大の法則とは

エントロピー増大の法則というのは熱力学から導入された考え方で、物事の煩雑さが常に大きくなるという法則です。ブラックのコーヒーにミルクを入れるとかき混ぜなくても、自然と混じりあっていくように、ミルクとコーヒーという独立した状態からお互いが混じり合う無秩序状態になってきます。

一度煩雑性が増した物事を元に戻すためには、外からエネルギーを加えることが必要になります。コーヒーの例で言えば混ざったコーヒーからミルクとコーヒーの成分を分離するためには濾過したり、水分を蒸発させて分離させるような処理が必要になるでしょう。

プログラミングにおけるエントロピー増大の法則とは

プログラムのソースコードも、コード量が増えるににつれ、どんどん煩雑になりエントロピーが増大した状態になります。メンバーが増えて様々なコードの書き方の癖が入り混じるようになったり、後から追加された機能によってそれまで維持していたコーディングルールを守れなくなったり。

煩雑さが増すにつれて、ソースコードに修正するために必要なコストが増えていきます。新機能追加のソースコードを書き加えるときに、他の部分に及ぼす影響を把握するための確認の手間が増えたり、全体の整合性をとるために行う検討時間(設計工数)が増えるからです。

こうして、プロジェクトが進むにつれた新たな機能追加・改善に必要な時間的コストが増えてゆき、進捗が悪くなってゆきます。

エントロピーを下げるアクション

設計工程で、コーディング規約を決めたり、フレームワークを採用したり、実装時にコードレビューを行うのは、プログラミングにおけるエントロピーの増大を抑制するための手段だと言えます。開発が進むにつれて、進捗が悪くなるプロジェクトはこのあたりの設計を疎かにしていることが多いです。

一度複雑性が上がってしまったソースコードを修正して複雑性を下げるためには多大な労力が必要です。影響範囲を考慮しながら散らばったコードを整理し、機能でまとめ、抽象化したり具体化したり、、。エントロピーを下げるために行うエネルギーの注入作業が、リファクタリングです。

リファクタリングには、技術的な困難と共に、経営的・政治的な困難もつきまといます。リファクタリングでは、機能が追加されたり改善されたりはしないため、技術的なバックグラウンドを持たない発注者や経営者に、その作業の必要性を理解してもらうことが難しいからです。

そのため、設計工程で採用するフレームワークを検討し、コーディング規約やレビューのルールを決めるのは非常に重要です。リファクタリングの必要性・重要性をプロジェクトオーナーに伝え、初期段階からプロジェクト責任者に伝え、実行計画を予め盛り込んでおくことも有効だと思います。

カテゴリー
システム開発全般 プログラミング

プログラミングと英語

プログラマーやエンジニアにどのくらい英語が必要かというのはよく聞かれる質問です。

プログラマに必要じゃないという回答は見たことがないし、当然私も英語は必要という考えですがその理由は二つあります。

第一に、これが一般的にもよく言われるこだと思うのですが、プログラミングを行っていて不明点が出てきた時はGoogle検索で解決方法を調べますが、その時に英文の記事しか検索結果にでてこないことがよくあるということです。幸いにして、日本語の検索でも大抵の解決方法は誰かが解決方法を書き、ネットで公開してくれています。

しかし、バージョンに依存するような頻度の少ない問題や、最近バージョンアップした言語やライブラリなどの情報は、日本語で検索できないこともあります。その場合は、英語で疑問点を調べなくてはなりません。

とは言っても、そのような英語の文章は大抵シンプルで、関連するプログラムが付記されているので理解するのは難しくない場合が多いです。

ただ、英語に苦手意識が強いと、その文章を読む作業も苦痛になるし、英語で調べたら簡単に見つかる解決策を、日本語で探そうとしてより時間がかかってしまうこともあります。この点において多少の英語力というのは必要だと思います。

もう一点、個人的にはこちらのほうがエンジニアがある程度英語に習熟しておいた方が良いと思う理由です。それはプログラミング言語は基本的に英語・アルファベットで書くことを前提に作られているということです。

作成したプログラムは、その後の修正・改善のために他のチームメンバーや自分でも読み返します。そのため時間が経ってから自分でプログラムを読んだとき、また他人が読んだときに、理解しやすいプログラムを書くことが必要です。

英語圏の達人プログラマーが書くプログラミングの教科書的な本には、普通の文章として読めるようなプログラムを書きなさいというようなことが書かれています。例えば、ファイルの上から下に実際に処理される順序でプログラムを書くこと、関数や変数に実際の処理に沿った命名をすること、単数形・複数形や動詞・名詞の違い、それらのルールを統一をする(規約に沿う)ことなど。

実際の開発現場でも、 実際の機能と異なる命名をされた関数名や変数名があるプログラムを読むと、理解するのにより多くの時間を費やしてしまうことがよくあります。

英語圏以外のプログラマにとってこのようなことに対して注意を払うためには、基本的な英語の文章作成力、読解力を養っておく必要があると感じます。

ちなみにアルファベットを使って、ローマ字表記で関数名・変数名を指定してプログラムを書くことは可能です。実際にローマ字表記でプログラミングを行うプログラマもいるのですが、英語に訳せない日本語や固有名詞に使用する以外で、ローマ字表記を使用することを私はお薦めしません。

・英語表記で書かれたプログラミング言語の予約語や、フレームワークのプログラムと異なる表記体系が混在してしまう
・日本語(ローマ字表記)には複数形がない
・ローマ字表記は表記ゆれを起こしがち
   例) Hensuu←→Hensu, Henshu←→Hensyu, O Sadaharu←→Oh Sadaharu

よって、プログラミングを行うために英語力は必要か?ということに対しては

・疑問点・不明点をググるために英語は必要
・読み易いプログラムを書くために英語の単語力・文章作成力・読解力が必要
・日本人のみの開発現場では、リスニング・英会話力は不要

だと考えています。