0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

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

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

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

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


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

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

  • エスカレーション対応:80件/日(平均5分)
  • 業務質問:50件/日(平均20分)
  • 書類確認・提出対応:常時
  • クライアント折衝・報告作成
  • 業務進捗管理・スタッフ育成
  • 各種会議・調整

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

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

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


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

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

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

項目 設計視点
属人性排除 誰が使っても同じ動きをするUI・ロジック
再利用性 モジュール化・関数化で業務横断的に活用
メンテ性 何かあってもすぐ直せる構造。エラーハンドリング重視
説明可能性 他人に説明して納得される設計。記録とコメントの徹底
成長余白 今使えるだけでなく、来月も来年も使えるような設計

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


🛠 開発者としてやり続けたこと

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

🔸 ログ入力のUI設計(HTML+CSS)

  • 誰でもすぐに使えて、ミスが起きないUI
  • 選択式・記入誘導型のフォームで、記録品質向上
  • “現場が触りたくなるUI”を目指して設計

🔸 集計シートへの転換(Googleスプレッドシート)

  • ローカル処理の属人性からの脱却
  • チームで“見える数字”を持つことで、判断を素早く
  • ダッシュボード設計で「数字を話せる現場」へ

🔸 帳票自動化(VBA)

  • データ抽出〜フォーマット整形〜PDF出力までを一発化
  • 作るより“見る”ことに集中できる構造へ
  • エラー処理・保存ルール・リネームなど“細かい気遣い”の実装

🔸 Bot設計(Python)

  • FAQ回答+判断補助の役割を担わせる
  • DB連携による「誰かが一度答えた履歴」を再利用できる設計
  • Botが“質問を誘導する存在”になるようUX調整

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


📦 「誰でも使える技術」にこだわった理由

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

  • 現場の人が“触れない”
  • 更新のたびに“設計者が呼ばれる”
  • 説明するたびに“手間がかかる”

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

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

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


🔄 挫折しかけたこともあった

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

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

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

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

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


✍️ 結び:“やってない暇がなかった”それでもやっていた理由

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

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

  • 現場の混乱を整えるため
  • 人の判断を支えるため
  • チームの信頼を形にするため

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

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


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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?