非ＩＴ企業でＩＴエンジニアをしていると、ときどき孤独感にさいなまれることがある。これは極論を言うと、エンジニアの宿命ではあるのであるが、それが時に相手の思惑に反して、知らない間に別の思考が働き、ついつい本題とは違うところで妙なモチベーションが上がって、ついつい余計なことをしてしまう。
この記事では、その経験と葛藤について書いてみたい。

保守とAI開発の狭間で

私はITエンジニアとして、あるシステムの保守を任されている。

システム保守を依頼されると、私は自然と効率化を考えてしまう。「保守マニュアルをAIに学習させて、保守計画書を自動生成できないだろうか」と考え始める。気がつくと、肝心の保守作業を差し置いて、保守AI開発に没頭している自分がいる。

しかし、保守を進めるには保守計画書が必要で、その作成には難解なコードと仕様の解読が必要不可欠だ。一方、保守を依頼した管理者（システム部門だがエンジニアではない）にとって、関心があるのは保守の完了だけ。私が作ろうとしている保守AIの開発は「余計な作業」としか映らず、保守が進まないことへの不満が募っているのを感じる。

ノーコード開発での迷走

別のプロジェクトでは、あるシステムをノーコードツールで開発した。本来であれば、ツールの使い心地をユーザーに聞いて、その機能を拡充させるべきだった。

しかし気がつけば、私は自動テストやデリバリー部分、設計ドキュメントの自動生成など、ツールとは直接関係のない開発環境の構築に集中していた。結果として作られたものは、ユーザーが望む内容がツールに反映されていないどころか、保守の引き継ぎ時には開発環境という別ツールも保守対象として引き継がなければならなくなってしまった。

開発環境の整備は、ユーザーにとって見えない、理解もされない、ただのエンジニアの自己満足な成果物としか映っていない。

理解されない成果物

二つの例を示したが、やはり最も辛く感じるのは、非ＩＴエンジニアには二次成果物には何の価値も見出されず、単なる自己満足の余計なものとして映ってしまう（そもそも、その使い方でさえ必要性がないのであるから、なおさら当然ではあるが）

非エンジニアの視点

二次成果物は「余計なもの」として映る
本来の目的（保守や機能開発）から外れた無駄な作業
進捗の遅れの原因としか見えない

エンジニアの視点

二次成果物は将来の開発効率を上げる重要な資産
他システムでも再利用可能な価値ある技術資産
チーム全体の生産性向上につながる投資

エンジニアの孤独

この理解されない価値観の違いが、深い孤独を生む。

技術的な成果を共有できる相手の不在
価値ある成果が理解されない虚しさ
「一人で勝手に作り込んでいる」という誤解
喜びを分かち合える仲間の不在

変化への道筋

この状況を少しずつ改善するため、私は以下のアプローチを試み始めている：

小さな成功を積み重ねる
- まず本来の業務で信頼を獲得
- 効率化による具体的な成果を示す
- 段階的に技術的な改善を導入
「翻訳者」になる
- 技術的な価値を業務的な価値に翻訳
- 具体的な数字で効果を示す
- ユーザー目線での説明を心がける
仲間を作る

結びに：希望の光

確かに、非IT企業のエンジニアとして働くことには深い孤独が伴う。しかし、この葛藤の中にこそ、私たち独自の価値がある気がしている。
技術への情熱を持ちながら、業務への理解も深められる私たち。実は、この二面性にこそ価値があるのかもしれない。技術と業務の橋渡しができる。実務に即した技術選択ができる。そして何より、両者の視点を理解できるからこそ、段階的な改善を実現できる。
完璧なバランスを見つけることは難しい。しかし、一歩一歩、理解者を増やしながら、技術と業務の架け橋となっていく。それが、非IT企業のエンジニアとしての私の役割なのかもしれない。