SESエンジニアが「実装だけでは物足りない」と感じた理由

実装そのものは嫌いではなかった

私は現在、SESとしてC#/.NETを用いたWindowsアプリケーション開発を行っています。
これまで詳細設計〜実装を中心に担当してきました。

実装そのものは嫌いではありませんでした。

画面を作ることも、機能を実装することも、エラーを解消することも楽しかったですし、自分が書いたコードで実際に機能が動く瞬間にはやりがいを感じていました。

特に、ユーザー操作とシステムの動きが密接に関わるアプリケーション開発では、「システムを作っている感覚」が強く、面白さを感じていました。

一方で、開発を続ける中で、少しずつ別のことを考える時間が増えていきました。


違和感を持ち始めたきっかけ

最初は、渡された仕様を実装することが仕事だと思っていました。

ただ、開発を続けていると、

「この仕様は、なぜこうなっているんだろう?」

と思うことが増えていきました。

例えば、

  • なぜこの制御が必要なのか
  • なぜこの画面遷移なのか
  • なぜこの責務分割なのか

などです。

最初は単なる疑問でしたが、徐々に、

「仕様の背景を理解しないと、正しく実装できない」

と感じるようになりました。

コードを書くことよりも、
“なぜその仕様が必要なのか” を理解することの方が重要だと思う場面が増えていったのです。


「なぜこの仕様なのか」が気になるようになった

特に大きかったのは、仕様の“目的”を考えるようになったことです。

以前、ある操作中に特定の機能を制限する対応を行ったことがありました。

最初は「特定の操作だけを禁止する仕様」だと思っていました。

ただ実際には、別の操作によってもユーザーが見ている状態が変化してしまうことに気付きました。

つまり、本当に守りたいものは、

「特定操作を禁止すること」

ではなく、

「ユーザーが認識している状態を変化させないこと」

なのではないかと考えるようになりました。

その結果、関連する別操作についても制御対象に含めるべきではないかと提案し、仕様の見直しにつながりました。

この経験から、

「仕様書に書いてあることをそのまま実装する」

だけではなく、

「仕様の目的は何か」

を考えることの重要性を強く感じました。


実装より「どう作るか」を考える時間が増えた

開発を続ける中で、実装内容そのものより、

  • 将来変更しやすいか
  • 責務が整理されているか
  • 保守しやすい構造になっているか

を気にすることが増えていきました。

例えば、ある機能では、
1つの状態フラグが複数の意味を持っている実装になっていました。

当初は問題なく動いていましたが、新仕様追加によって責務が曖昧になり始め、このまま機能追加を続けると条件分岐が複雑化していく危険性を感じました。

そこで、状態管理の責務を分離した方がよいのではないかと考え、設計変更を提案しました。

もちろん影響範囲は広くなります。

ただ、それでも、

「今整理しておかないと、後でさらに苦しくなる」

と感じたためです。

この頃から、

「どう実装するか」

よりも、

「どういう構造で作るべきか」

を考える時間が増えていきました。


実務で感じたこと

実務では、コードを書く力だけでは解決できない場面が多くあります。

例えば、

  • 仕様同士が衝突している
  • ドキュメントごとに内容が違う
  • 将来拡張で破綻しそう
  • 一時的には動くが保守性が低い

などです。

実際、実装前に仕様の矛盾へ気付き、確認を行ったことで手戻りを防げたこともありました。

また、終盤で大きな仕様変更が入った際には、チーム全体で整合性を保ちながら実装を進める必要がありました。

その中で、

  • どこを共通化するか
  • どの順番で実装するか
  • どうすれば影響を最小化できるか

を考える機会が増えました。

その経験を通して、

「開発は単にコードを書く作業ではない」

と感じるようになりました。


実装だけでは届かない領域があると感じた

開発を続ける中で、徐々に、

「もっと早い段階から関わりたい」

と思うようになりました。

なぜなら、実装段階では既に前提が決まっていることが多いからです。

もちろん実装の工夫で改善できる部分もあります。

ただ、

  • なぜその仕様にするのか
  • どんな運用を想定するのか
  • 何を優先するのか

といった部分は、より上流で決まります。

私は、実装を通して、
そうした “判断” の重要性に興味を持つようになりました。


今後やりたいこと

今後は、

  • 実装力
  • 設計力
  • 仕様理解
  • 保守性への視点

をさらに伸ばしながら、

「どう作るべきか」

を考えられるエンジニアになりたいと考えています。

また、単に上流工程という言葉に憧れているわけではなく、

  • なぜその仕様なのか
  • なぜその設計なのか

を説明できる立場になりたいと思っています。

そのために、現在も個人開発や設計の勉強を続けています。


このブログで発信していくこと

このブログでは、

  • 実装者から設計・上流へ進む過程
  • C#/.NET開発
  • 個人開発
  • 転職・キャリア戦略
  • 設計意図や責務分離の考え方

などを発信していきます。

特に、

「実装はできる。でも、このままでいいのか不安」

と感じているエンジニアにとって、
少しでも参考になる情報を残せればと思っています。

コメント

タイトルとURLをコピーしました