SESで実装中心の案件に入っていると、「上流工程に行きたい」と思っても、最初に何をすればいいのかが見えにくいです。
実装経験は少しずつ増えている。
できる作業も増えて、レビューで指摘される回数も減ってきた。
それでも、任される範囲は大きく変わらない。
要件定義や基本設計に関わりたい。
でも、今の現場では詳細設計以降の実装が中心。
職務経歴書にも「製造」「単体テスト」と書くことが多く、設計経験として話せる材料が少ない。
基本設計や要件定義の打ち合わせに入っている人を見ると、「自分はいつそこへ行けるのか」と不安になることもあります。
このまま実装経験だけを積んでいて、上流工程に近づけているのかがわからなくなるからです。
この状態だと、上流工程へ進むには先に上流案件へ移るしかないように感じます。
しかし、最初の一歩としては、いきなり案件を変えるよりも先にやるべきことがあります。
それは、今の実装業務を「設計視点」で整理することです。
実装タスクの中にも、仕様の理解、責務の分け方、影響範囲の確認、レビューでの説明など、設計につながる要素は含まれています。
それをただ作業として流すのではなく、自分の言葉で記録していく。
この記事では、SESエンジニアが上流工程へ進むために、今の現場で最初にやるべきことを整理します。
上流工程へ進む最初の一歩は、案件変更ではなく視点変更
上流工程へ進みたいと考えたとき、多くの人は「上流案件に入らないと経験が積めない」と考えます。
もちろん、要件定義や基本設計を実際に担当できる環境は重要です。
ただ、何も準備しないまま上流案件だけを狙うと、面談や面接で説明に困ります。
- なぜ上流工程へ進みたいのか
- これまでの実装経験をどう設計に活かせるのか
- 仕様や設計について、どのように考えてきたのか
このあたりを話せないと、「上流に興味があります」で止まってしまいます。
だからこそ、最初に変えるべきなのは案件ではなく、今の実装を見る視点です。
実装を「指示されたものを作る作業」としてだけ見るのではなく、「仕様をコードに落とす過程」として見る。
C#/.NETのWebアプリであれば、画面、処理、データのどこに責務を置くかを考える場面があります。
たとえば、入力チェックを画面側だけに置くのか、処理側でも保証するのか。
集計処理を画面表示のためだけに書くのか、Service相当の処理として切り出すのか。
データ取得をその場で直接書くのか、再利用できる形にするのか。
こうした判断は、実装の中にある小さな設計判断です。
まず整理するべき3つの設計視点
最初から大きな設計書を書こうとする必要はありません。
まずは、自分が担当した実装について、次の3つを整理するだけで十分です。
1. なぜその仕様になっているのか
実装するときは、「何を作るか」だけでなく、「なぜその仕様なのか」を確認します。
たとえば、一覧画面に検索条件を追加する場合でも、単に検索項目を増やすだけではありません。
利用者が何を絞り込みたいのか。
検索結果が多すぎて困っているのか。
業務上、特定の状態だけを確認したいのか。
この背景を理解すると、実装の判断が変わります。
入力項目を増やすだけでよいのか、初期表示条件も見直すべきなのか、検索結果の表示項目も足りているのかを考えられるようになります。
上流工程では、仕様の背景を理解する力が求められます。
その練習は、今の実装タスクでも始められます。
2. どの責務をどこに置いたのか
次に整理したいのは、責務の置き場所です。
C#/.NET案件なら、最初は細かいレイヤー名にこだわりすぎなくて構いません。
まずは、UI、処理、データの3つに分けて考えると整理しやすいです。
- UI: 画面表示、入力、ユーザー操作
- 処理: 業務ルール、判断、変換、計算
- データ: 保存、取得、検索条件、永続化
たとえば、画面に表示する文言を組み立てる処理があったとします。
それが単なる見た目の調整ならUI側でよいかもしれません。
一方で、業務ルールに基づいて状態名を決めているなら、処理側に寄せた方が保守しやすい場合があります。
重要なのは、「なんとなくここに書いた」で終わらせないことです。
なぜそこに置いたのか。
将来変更が入ったとき、どこを直せばよい状態にしたかったのか。
この説明ができるようになると、実装経験を設計視点で語れるようになります。
3. 変更時にどこへ影響するのか
上流工程では、仕様変更や追加要望に対して、影響範囲を考える力が必要になります。
これも、実装担当の段階から練習できます。
たとえば、検索条件を1つ追加するだけでも、影響範囲は画面だけとは限りません。
- 画面の入力項目
- 入力値の検証
- 検索処理
- SQLやクエリ条件
- テストケース
- 既存利用者への影響
実装前にこの範囲をざっと書き出すだけでも、設計視点の訓練になります。
さらに、レビューや日報で「この修正では画面、検索処理、テストケースに影響があるため確認しました」と言えると、単なる作業報告よりも一段深い説明になります。
実装経験を設計経験として残すメモの型
設計視点を育てるには、頭の中で考えるだけでは足りません。
後から見返せる形で残すことが大切です。
おすすめは、担当タスクごとに次のようなメモを残すことです。
## 実装タスク
- 何を変更したか:
- なぜ必要だったか:
- 責務の置き場所:
- 影響範囲:
- 確認したこと:
- 次に改善できそうなこと:このメモは、社外に出せる情報だけで書きます。
案件名、顧客名、機密情報、具体的な業務データは書かないようにします。
大事なのは、実装内容だけでなく判断理由を残すことです。
「検索条件を追加した」だけでは、作業内容で終わります。
しかし、「利用者が対象データを絞り込みやすくするため、画面入力、検索処理、テストケースを変更した。業務ルールに関わる判定は処理側に置き、画面側は入力と表示に寄せた」と書けると、設計視点を含んだ経験になります。
この粒度で残しておくと、あとから職務経歴書にも転用しやすくなります。
現場で小さく提案する
設計視点を持ち始めたら、次は現場で小さく提案してみます。
ここで注意したいのは、いきなり大きな設計変更を提案しないことです。
既存システムには、過去の経緯、納期、チームのルールがあります。
外から見て正しそうな設計でも、現場の制約に合わないことがあります。
最初は、影響範囲が小さい改善から始めるのが現実的です。
- 似た処理が増えているので、共通化できるか確認する
- 条件分岐が読みにくいので、意図が伝わる名前にする
- 画面側に寄りすぎている処理を、処理側へ移せないか相談する
- レビュー時に、なぜその場所に実装したかを一言添える
レビューで添える一言は、長い説明でなくて構いません。
たとえば、次のような短い表現です。
- 将来条件追加される可能性を考えて、画面側ではなく処理側へ寄せました
- 入力チェックはUI側だけでなく、処理側でも保証する形にしました
- 影響範囲は画面、検索処理、テストケースにあるため確認しました
この程度でも、単に「実装しました」ではなく、判断理由と確認観点を伝えられます。
このような小さな提案でも、積み重ねると「実装だけでなく、保守性や影響範囲を考えている人」と見られやすくなります。
上流工程へ進むためには、肩書きより先に、任せられる範囲を少しずつ広げることが重要です。
まとめ: 上流工程は、実装の外側を見る習慣から始まる
SESエンジニアが上流工程へ進むために、最初から要件定義や基本設計の案件に入る必要はありません。
まずは、今の実装業務の中で次の3つを整理します。
- なぜその仕様なのか
- どの責務をどこに置いたのか
- 変更時にどこへ影響するのか
この3つを記録していくと、実装経験は単なる作業履歴ではなく、設計視点を含んだキャリア材料になります。
上流工程は、実装の外側を見る習慣から始まります。
今の現場でできることを言語化し、小さく提案し、次の案件や転職で説明できる形にしていきましょう。
そもそも、なぜ実装だけでは物足りないと感じ始めたのか。
その背景を整理したい場合は、前回の記事「SESエンジニアが『実装だけでは物足りない』と感じた理由」もあわせて読むと、今の違和感をキャリアの課題として捉えやすくなります。
コメント