はじめに

こんにちはロンです。
弊社のブログでは、プロジェクトで直面した技術的課題へのアプローチやキャッチアップの記録が多く公開されています。ただ、製造業の「現場目線」で学んだこと、苦労したことを綴った記事は意外と少ないと思っています。

現在、製造現場の新事業立ち上げ案件に参画している私だからこそ書ける話があるのではないか。そう考え、このテーマを選びました。

エンジニア3年目の壁

「製造業は楽しい」とタイトルに掲げましたが、実際のところ大変なことの方が圧倒的に多いです。
私はド文系出身でエンジニア3年目。そもそものドメイン知識が浅いという現実があります。具体的に何が今までで大変だったのか、振り返ってみます。

キャッチアップの苦労

製造業のドメイン知識がほぼゼロの状態で、今のプロジェクトに飛び込みました。
1つ前のプロジェクトも製造業でしたが、業務内容はAWSを使った大規模データ利活用基盤の構築。データウェアハウスに蓄積されたデータをレポート用にETL処理する業務で、製造業の細かな知識は正直不要でした。

ところが今回は違います。実装に始まり、設計、顧客折衝に至るまで業務範囲が広く、ドメイン知識は必須です。

そこで私が取り組んだのは、とにかくブログと本を読みまくることでした。
まずは書籍で全体像を掴む。当たり前のことかもしれませんが、これが確実に力になりました。
ちなみに私がおすすめする本は、エンジニアが学ぶシリーズの「生産管理システム」「在庫管理システム」です。MRP、MESといった用語の説明や関係性など全体像がわかりやすくまとめられていて理解にすごく助かりました。

もう一つ、正直に言えば運も良かったと感じます。
上司との距離が近いプロジェクトだったこと、何を聞いても嫌な顔一つせずに教えてくれる製造業への知識が深い先輩がいたこと。この環境には本当に助けられました。

現場での立ち回りの難しさ

製造現場で感じた難しさは、「誰の責任か」がはっきりしない場面が多いことです。
業務の責任、データの責任が曖昧なまま進んでいることが少なくありません。

典型的なのは、現場での温度差です。
上の人はシステム化を推進したい。でも現場の人は、やり慣れたやり方を変えたくない。
「その業務は○○課にやっていただきたい」という声が出てくるのも、あるあるだと思います。やり慣れていない仕事が増えるのだから自然なことです。

それでも、「変えることで後々あなたにもメリットがある」ということを、いかにわかりやすく伝え、腹落ちしてもらうか。
ドメイン知識も弱く、今までコンサル的な業務をしてこなかった私には、この「伝える力」「ドキュメンテーション力」が最初は本当に難しく感じました。

それでも製造業が楽しい理由

大変なことばかり書きましたが、タイトル通り楽しいことも確かにあります。

一番大きな理由は、実際に工場に行き、現場を見た上で同じ目線に立ち、「どうすればもっと楽になるか」「どこを変えるべきか」を一緒に考え、それを自分の手で実装していくことに、強いやりがいを感じているからです。

これまで携わってきた案件は、不特定多数のユーザーを想定したシステムが中心でした。
もちろんそれも価値のある仕事ですが、今は目の前にいる人の業務が少しでも良くなることを目的に改善を積み重ね、その反応がダイレクトに見られる仕事に楽しさを感じています。

この距離の近さこそが、製造業の現場で働くエンジニアならではの面白さだと感じています。

作れることと、使われることの違い

最近、Xでこのような趣旨のポストを見かけました。
「AI時代、良いプロダクトは機能の良し悪しではなく、“合意の設計”で決まる。作ることは簡単になったが、使われ続ける状態を作るのは別の話だ」という内容です。

これを読んで、今の製造業プロジェクトの経験と強く重なりました。
改善依頼を受けた際、ローコードツールを使っていたり、既存システムがあることから、技術的には「それ、作れますよね」という話は自然と出てきます。

ただ、その次に必ず立ち止まるのが、

• 誰が使うのか？
• いつの業務で使うのか？
• 今の業務フローにどう組み込まれるのか？

という問いでした。

現場では、このような合意が取れないことで止まるケースが非常に多いと、個人的に感じています。

だからこそ、まずは小さく作り、実際の業務イメージに落とし込んでもらい、一緒に考えることが重要だと考えています。
良いプロダクトとは、機能が多いものではなく、関係者が納得した上で「使われ続ける状態」を作れているもの。確かにその通りだなと感じています。

「コードは道具」という再認識

今回のプロジェクトは前述の通りローコードツールを使っているため、正直なところ最初は苦戦しました。
コードを書いて価値を出すエンジニアだった自分が、なかなか自分の色を出せず、もどかしさを感じていたからです。

まずは目の前にあるプレゼンなどの顧客折衝をきちんとこなそうと、資料を読み漁り、自分事として理解することに注力しました。
結果としてプレゼン力を褒められる場面が増え、社内では「プレゼンの櫻田」と呼ばれるほどには、自分の強みを発揮できるようになってきました。

この経験を通じて、コードはあくまでも課題を解くための道具であって、目的ではないことを改めて強く実感しました。

まとめ

今まで踏み込めていなかった上流業務に携わり、日々楽しさを感じています。

コードは目的ではなく、課題を解くための道具。
本質的な問題を見極め、シンプルで保守性の高いソリューションを提供する。そのために業務フローに立ち返り、現場の方と同じ目線に立ち、価値あるシステムを届けていく。

これが今、すごく楽しいです。