スーパーバイザーをしながら、同時に開発を続ける──これは思っていたよりも何倍も難しかった。私は一時期、150人規模を統括する現場の中心にいた。業務の管理、クライアントとのやり取り、社内対応、改善施策、そして開発業務。全部を並行して回していた。

その中で、何度もこう思った。

「技術業務をやる時間がない」
「現場の方が優先される」
「誰かの質問に答えることが、いつの間にか日常になっている」

それでも私は、開発者としての自分を手放さなかった。その理由と、そこに注ぎ込んできた情熱を、ここに記しておこうと思う。

🔄 開発の時間は“スキマでしかない”

現場にいると、1日がほぼ埋まってしまう。

その隙間で、Botの改善やスクリプトの修正、帳票テンプレの更新、フォーム設計の改良──全部をやっていた。

空いている時間に触る、じゃない。**空いていない時間に“捻じ込む”**のが、あの頃の開発だった。

実際、リーダーに社内エスカ教育等を行い3か月ほどかかりテスト工程まで進むことができたがかかりすぎな部類だとは今でも思う。

🧠 開発者としての判断基準は常にあった

「今、何を作るべきか」「どう作るべきか」「作らない方がいいかも」──この判断は、業務の合間でも常にしていた。

意識していたのは、次のような設計思想：

業務の混沌の中でも、「これは設計する意味があるか？」「これを作ることで現場は変わるか？」という問いが私の軸になっていた。

以下は、私が開発者として現場で仕掛けてきたことの一部。

技術が誰かの手間を減らすこと。それだけでなく、誰かが“安心して動ける状態”をつくること。それを目指してコードを書き続けていた。

私は、「便利だけど誰も使えない」仕組みには価値を感じなかった。

そうじゃなくて、“誰でも気軽に使える”技術に価値があると思っていた。

だから、コメントを書く。設計書を添える。マニュアルを作る。Botの画面にヒントを表示する。処理ボタンの名前を「ここを押すと完了します」にする──そういう小さな工夫が、使われる技術を生み出す。

開発者だからこそ、“使われ方”に責任を持ちたかった。

開発に使う時間は限られていた。資料の締切、質問の対応、現場のトラブル、優先順位が変わる──そんな日々の中で、

「この改善、誰も気づいてないな…」
「せっかく作っても、使われてないな」
「今は対応に集中すべきかな」

と、モチベーションが落ちかけたこともある。

でも、あとから「あの機能、助かりました」「あれがあるだけで業務がラクです」と言われたとき、自分の中で何かが報われた。

コードの先に“誰かの変化”があること。それが私にとって、技術の価値そのものだった。

開発者という肩書は、現場ではあまり表に出ない。スーパーバイザーとしての立場、業務の判断者としての役割、そっちのほうが目に付きやすい。

それでも私は、“設計者としての自分”を手放したくなかった。

技術者としての自分は、現場を“動かす力の供給者”だと思っていた。そしてあの頃、私は技術を使って、現場の人が“止まらないで済むようにする”ために、設計し続けていた。

それが、開発者としての私だった。

📘 次回：
第11回（蛇足）｜マネジメントが“余裕”をくれる日は来るのか？
── 楽にはならない。でも、心の持ち方を変えた日。私が見つけた「設計の余白」