はじめに
本記事は、機械系エンジニアとシステムエンジニア双方の経験を持つ私から、それらのエンジニアリング、すなわちモノづくりとサービスづくりの違いを実体験を基にご紹介するものです。
都合上、自己紹介の側面をはらんだ記事となってしまいますが、ご理解いただけますと幸いです。
どのような業界に就職、転職するか検討中のエンジニアの方向けに、製造業およびwebサービス開発現場のお話をできる限り鮮明にお伝えできればと思っています。
自己紹介
株式会社LOKIARでCTOを務めています、熊谷亮と申します。
具体的なお話に入る前の背景知識として、私のキャリアを紹介させていただきます。
機械系エンジニアとしてのキャリア
2018年に機械系の専攻で修士課程を終えたのち、本田技研工業に新卒入社しました。
元々、ASIMOの技術を生かした新たなモビリティ作りがしたいと考え入社しましたが、約半年間の現場研修の後、私の配属先は完成車工場の溶接加工を担う部門に決まりました。
おおよそ60秒に一台のペースで自動車が生産される工場の中で、部品を生産機器にセットしてはボタンを押す、といういわゆるライン作業に１年ほど従事したのち、生産機器のメンテナンスをする保全部門へと異動しました。
ここでは修理が必要になった生産機器の復旧作業や、トラブルを起こさないための日々のメンテナンス業務にあたっていました。３交代という肉体的にも過酷な勤務形態の中、汗とグリスにまみれながら産業用機械のギアを交換したり、切れてしまったケーブルを張り替えたり、亀裂の入った部品を溶接してくっつけたり、まさに現場の手触り感のあるモノづくりを体験させていただきました。スパナすらまともに握ったことがないところからのスタートだったのですが、根気強く面倒を見てくださった諸先輩方に心から感謝しております。
システムエンジニアとしてのキャリア
元々、IT系の仕事もしてみたいと考えていた私は、工場での機械、電気の勉強に一区切りをつけ、web系の開発を行っているスタートアップへ転職しました。開発会社にSES型の常駐をして、様々な事業会社のwebサービスの保守運用に携わりました。転職前はhtml, css, javascriptって何？状態だった私ですが、こちらの現場で修行させていただき、自分で責任を持って0からプロダクトが作れる自信をつけさせていただきました。特に、メガベンチャー～老舗大手企業まで、様々な規模感の事業会社のプロダクトに携われたことは、エンジニアとしての視野の広さを自分に持たせてくれたように思います。開発するプロダクトも、オンプレ型の基幹システムから組み込み、webアプリケーションまで様々でした。
作り方の違い
機械系エンジニアもweb系エンジニアも、一口にはエンジニアリングとまとめられはするものの、双方の作り方へのアプローチは所々異なると感じています。
根本的な発想の違いは「同じものをみんなに作るか、作ったものをみんなで使うか」ではないでしょうか。
ライン生産方式とシステムづくりの違い
当たり前のことですが、100人車を買う人がいれば、車は100台必要です。
従って、モノづくりでは100台の車を同じように作り上げることが求められます。
実際の作業では、（多くの場合は）きちんと決められた手順書があったり、指導をしてくれる先輩がいたりして、そのやり方に徹底的に踏襲して作業を遂行することが求められます。ライン作業において、個人に求められる仕事量はとても小さなレベルまで細分化されており、例えば「フロントガラスの取り付け作業」を一日中絶え間なく繰り返すような工程もあります。
その一方、webサービスは100人買う人がいたとしても、システムは1つあれば100人に提供することができます。（厳密にはオンプレにしたり、サイロ型のアーキテクチャを採用したりして複数似たようなシステムが組みあがることもありますね）
車の例で言うと、システム上に「フロントガラス」は1枚あれば十分です。一度取り付けしたら取り付けをする人はお役御免で、同じ機能が再度作られることはありません。むしろ開発の混乱を避けるために、同じことを繰り返すのは避けるべきとされています（DRY原則）。
こうした価値提供の仕方の違いを背景に、作業者たるエンジニアに求められる能力は大きく変わります。
上述したように、モノづくりのエンジニアには特定の領域に特化した能力を求められます。この場合、自分の専門領域を離れてしまうとある意味、素人同然の状況になってしまうため、異動が発生した際に、苦労している諸先輩方をよく見たように思います。
一方、システムエンジニアには、フロントガラスもタイヤもシートも付けられるし、なんなら今までは内燃機関で走っていた車の中身をモーターに変えてしまう、というような動きができる人が重宝されます。（こう考えると、自動車の整備工場のエンジニアさんなどはシステムエンジニアに近い働き方をされているのではないでしょうか。）
最近web系の業界では、こうした動き方のできるエンジニアのことは「プロダクトエンジニア」と呼称されるようになってきました。弊社でもこのプロダクトエンジニアという言葉を使用して、採用活動をさせて頂いております。
モノづくりに比べると、責任範囲が広い分、たくさん仕事がこなせてしまうため、仕事量の調整や可視化は一つ課題のように思います。極端な話、モノづくりは部品が入ってこなければ仕事はできません。一方プロダクトエンジニアは、では部品から作ろうという動き方ができてしまいます。できることがいくらでもあるので、仕事に終わりは来ません。
工場のメンテナンスとシステムのメンテナンスの違い
ライン生産方式とサービスづくりという観点では上記のような違いがありました。
一方で、モノを生み出す工場は一つのシステムと捉えることもできるでしょう。そう考えると、工場のメンテナンスとシステムのメンテナンスはかなり似通っていそうです。以下では自分の思う相違点をまとめました。
物理的制約による違い
例えば、車両に溶接加工を施す産業用ロボットの大きさは、おおむね1m×1m×2m程度のものが多いです。仮にこのロボットに不具合が起きた場合、周りで作業ができるのはどれだけ環境の良い場所でも、3~4人でしょう。実際の現場では、生産効率を高める都合上、ロボットの設置場所は脚立を立てないと人が触れないような場所のこともめずらしくありませんから、作業者はごく少人数です。
他方システムの運用にはそのような制約がありません。極端な話、エンジニア全員が同じファイルを触って並行して作業をすすめることが物理的にはできます（実際には他者の変更内容との衝突を避けるため、ファイル凍結で特定の人しかいじれないようにしてしまったり、バージョン管理ツールを使用したりすることが多いとは思います）。
障害対応で、開発者総ぞろいで目を皿のようにして、早押しクイズ形式で原因調査を行った経験がある方は、少なくないのではないでしょうか。
また完成車工場はとても広いです。恐らくラインの源流から完成車の出荷口まで、最短で歩いたとしても30分はかかる工場ばかりではないでしょうか。生産機器のメンテナンスには専用の工具や部品が欠かせません。これらを持って大移動を繰り返すのは非効率で、あまり組織設計としては採用されていないようです。
また、完成車工場でのライン停止への緊張感はすさまじいものがあります。というのも、60秒に一台車が作られる、と記載しましたが、これは、もし60秒ラインを止めてしまったら、車一台分の機会損失が発生する、とも言えてしまうからです。システムでも規模に応じて、勝るとも劣らない緊張感が走る現場もあると思いますが、そんな状況の中で不具合が発生して、まずは移動に30分かかります、では話になりません。従って工程上の守備範囲を決めて（例えば溶接、ペイント、プレス、のように）現場近くに常駐するエンジニアを配置することが一般的なように思います。工場では現場に行き、現実を見て、現物を触ることができる人数は限られているのです。
システムの場合は、こうした地理的な事象も問題になりません。インターネットが機能している限り、地球上のどこにいても、皆が同じ事象を即座に観測することができ、開発環境をきちんと整えておけば、誰でも修正対応を進めることができます。
従って、工場ではエンジニア一個人が、全体に対して手を行き届かせることが困難な一方、システムではそれが容易にできるという違いがあります。
環境やコストの制約による違い
工場のメンテナンスはシステムのメンテナンスに比べると、技術的に融通が利かないことが多いように思います。例えば、何かしらの修理や改善を加える際、例えばプログラミングのみで解決するような話であれば、システムでは万が一失敗が発生してしまったときでも、ファイルの変更を元に戻すことで瞬時に変更前の状態に戻すことができます。また低コストで本番に相当する環境の設置が可能なため、基本的にはテストをする環境が容易されており、石橋を叩いて低リスクで変更をリリースすることができます。
一方、工場で似たようなことをやろうとすると、とても苦労します。まず、基本的に本番を丸々再現した検証のできる環境はありません（工場をもう一つ建設するだけの費用が発生します）。従って、変更は全て現場のものを直接いじくるしかありません。
プロダクションコードを直接触る程度の話か、と思われるかもしれませんが、実はこれはもう少しタフな作業です。というのも、改善や修理のために変更を加えてみたものの、見落としや予期せぬ不具合があり、実際に動かしてみたら機器を物理的に壊してしまった、ということが起こり得ます。良かれと思ってした変更が、致命的なトラブルを引き起こしかねないのです。
さらには作業ができる時間も限られています。基本的にこれらの修理・改善作業ができるのは、意図的に工場の稼働を止めている時間（主には平日の深夜か休日）のみです。
時間的制約も厳しい中でリスクの高い行動をとらざるを得ず、失敗も許されない、工場での継続的な改善活動には困難を伴います。
技術的な相違による違い
工場への設備の導入時期や導入業者、導入する要件（どんなことが得意な機器が必要か）、などに応じて、工場では多岐にわたるメーカーの製品が使用されています。例えば産業用ロボットで言うと、Fanucや安川電機のものが有名ですが、これ以外にも大量のメーカーがあり、もしそれらが混在して現場に導入されている場合、エンジニアはそれぞれの技術特性についてまんべんなく知識を得る必要があります。扱う範囲をあまりにも広げてしまうと、一個人では管理しきれない情報量になってしまいますから、工場全体を統括するということはとても難しいように思います。またこれによって管理する部品点数が増えるのも難儀するところです。
これはある程度長く続いている企業ではシステムについても言えることかもしれません。新機能を作る際は新たなアーキテクチャ、フレームワーク、言語で作ろう、を繰り返しながらも、古いシステムのリプレイスにはなかなか投資判断が下りず、エンジニアが苦労している現場もあるのではないでしょうか。
工場ではもう一つ、安全性が求められます。知らないうちに危ないエリアに入ってしまってケガをしてしまった、ということは昨今ではないように構造上組まれてはいますが、システムの開発に比べて身体的な危険が伴うことは言うまでもないでしょう。
まとめ
以上のことから、システムの改修は工場に比較すると、ずいぶん簡単にできるものであると私は捉えています。
弊社では、変化のスピードが加速している世の中でスタートアップとしてより良い価値提供を続けていくためには、まずは作って使ってもらってみて、悪いところが出てしまったら、すぐに直すという開発指針を良しとしていますが、これらの経験はこの判断を後押ししているように思います。
また、プロダクトエンジニア、というエンジニアのあり方に共感しているのも、この経験に由来するところがあります。工場で生産工程に入っていると、顧客と相対することなどまずありえません。自分のこなした仕事に対するフィードバックは上司や同僚から来るものにとどまるので、社会的な意義ややりがいは見出し難いのではないでしょうか。
開発補助ツールや、PaaSの台頭で、細かな専門知識や大量のプログラミングの時間を要せずとも、様々なシステムを組み上げることができるようになってきています。であるならば、より包括的な範囲で、どんな価値提供ができるのか、なぜできないのか、顧客はどう思っているのか、等々、開発と運用の手触り感を両方持って（devOps）、仕事を進める方がエンジニア個人もポジティブに働きながら、より良いサービスが作れるのではないか、と考えています。
おわりに
なんだか、モノづくりのネガティブキャンペーンのように聞こえてしまうかもしれませんが、こうした違いがあるというだけで、それらの違いの良し悪しには一切言及していません。
とはいえ、今回この記事を執筆してみてから、モノづくりの現場に対して、システム開発のノウハウを適用していくことができないものか？とも考え始めました。
弊社では配送管理のプラットフォームを開発していますが、物流も一つのラインと捉えることもできるかもしれません。ともすれば物流の過程にも、システム開発の改善サイクルが落とし込めたり、、？
そんなことを考えながら、引き続き精進して参ります。
弊社では開発にご助力いただける方を募集しています。
まずはカジュアルに情報交換させて頂ければと思いますので、
ぜひ以下からお問い合わせください。
https://www.lokiar.com/contact