「要件定義から参画できます」と書かれた求人に応募して、書類の段階で止まる。経歴書の担当工程の欄に書けるのは実装とテストで、上流の経験はない。

上流に入るには上流の経験が要る、という循環の中にいると感じたことはありませんか。

この循環は、上流工程という言葉が「難しい工程」を指していると理解している限り解けません。上流は難易度の階段ではなく、意思決定を引き受ける範囲につけられた名前だからです。順番に整理していきます。

目次

上流の定義

まず、言葉の指す範囲が現場ごとに違うことに注意が必要です。ここを揃えないまま求人を比較すると、応募先の選び方そのものがずれます。

【1】求人票の「上流」は同じ意味ではない

要件定義から含めて上流と呼ぶ会社もあれば、基本設計以降を上流と呼ぶ会社もあります。工程の呼び方も統一されておらず、基本設計を外部設計、詳細設計を内部設計と呼ぶ現場があります。

同じ「設計」という語が、指している作業も決定の重さも違う状態で使われている。求人票の「上流工程あり」という一行だけで応募先を絞ると、入社後に想定と違う工程に就くことがあります。

面談では「要件定義はどの部署が担当していますか」「設計のどこまでを開発チームが決めていますか」と聞くほうが、工程名の確認より早く輪郭が出ます。

【2】工程ごとに決めている対象が違う

工程の違いは作業の難易度ではなく、決めている対象の違いとして整理できます。

上の工程ほど、決めた内容を後から覆したときの影響が広くなります。上流工程が重いと言われるのは、作業量ではなく、取り消しにくい決定を含むためです。

【3】「設計書を書いた」が上流経験と限らない

ここで評価のずれが起きます。詳細設計書を書いた経験があっても、選考で上流経験として扱われないことがある。

書いた人と決めた人が別だからです。決まった仕様を文書の形式に落とす作業と、仕様そのものを決める作業は、同じ「設計」という言葉の中に混ざっています。

上流は決定の工程

では、上流で実際に決めているものは何か。ここが分かると、必要な経験の中身も変わってきます。

【1】決めるのは機能だけではない

要件定義で決まるのは、機能の一覧だけではありません。応答時間や同時接続数といった非機能の条件、データの保持期間、締め日や締め時刻といった業務上の制約。

さらに、作らないものを決める作業があります。今回の範囲に入れない機能、次期に回す機能、手作業で運用する部分。予算と期間が有限である以上、要件定義の実体の多くは、落とすものを決める作業になります。

「全部作る」で通るなら決定は要りません。決定が必要になるのは、どれかを諦める必要があるときです。

【2】決定には情報を集める作業が伴う

何を落とすかを決めるには、落としたときに誰が困るかを知る必要があります。そのため上流の仕事は、打ち合わせで発言することより、条件を集めて確定させる作業のほうが分量として多くなります。

現行の業務がどう回っているか、例外処理が月に何件あるか、その処理を誰が引き取っているか。こうした情報は仕様書には書かれておらず、聞き取りと実データの確認でしか出てきません。

集めた条件が足りないまま決めると、後工程で仕様変更として戻ってきます。上流の巧拙は、判断の速さではなく、決める前に条件をどこまで確定させたかに表れます。

【3】技術力と決定力は別の軸

この整理から導かれることが一つあります。技術力を上げれば上流に行けるとは限らない、ということです。

実装の速度や設計の綺麗さは、詳細設計から下の工程で評価される軸です。上流で問われるのは、条件を集めて、影響を見積もって、落とす対象を決められるかどうかになります。

二つは重なる部分もありますが、同じものではありません。技術の勉強を続けているのに上流に近づかない、という感覚があるとすれば、伸ばしている軸と要求されている軸がずれている可能性があります。

誰が決めているのか

もう一つ、本人の努力とは別の要因があります。決定権の所在です。

【1】決定は発注した側に残りやすい

システムの仕様を最終的に決めるのは、そのシステムで業務を回す側です。開発を外部に委託していても、何を作るかの決定は発注者の側に残ることが一般的です。

この構造があるため、受託する側の工程は、決定済みの条件を受け取った状態から始まります。階層が下がるほど、届いた時点で決まっている範囲が広くなる。

多重下請けの構造と担当工程の関係は、別の記事で詳しく整理しています（SES・受託開発・自社開発の違いを整理する）

【2】同じ工程名でも決定の量が違う

同じ「基本設計を担当」でも、条件を集めて決めた基本設計と、決まった条件を文書化した基本設計があります。工程名は同じで、経験の中身は別物です。

選考で見られているのは後者の区別のほうです。だから工程名だけを並べた経歴書は、決定を含む仕事をしてきた人にとっても不利に働きます。

【3】経歴の問題ではなく配置の問題

上流に入れない理由が、本人の経験ではなく配置にある場合、勉強を足しても状況は変わりません。決定権のある位置に移るまでは、決定を含む仕事が回ってこないためです。

ここを切り分けないまま「自分の実力不足だ」と結論づけると、対処の方向が合わなくなります。

下流にもある決定

一方で、決定を含む仕事がまったく無いわけではありません。テストや改修の中にも、決定は発生しています。

【1】影響範囲の見積もりは決定である

既存機能を直すとき、どこまで直すか、どこまで検証するかは、誰かが決めています。呼び出し元をどこまで辿るか、影響のある帳票をどこまで確認するか。

この線引きは仕様書には書かれていません。担当者が条件を集めて決めている。これは規模こそ小さくても、上流で行われている作業と同じ構造を持っています。

【2】仕様の矛盾に気づくのは要件側の仕事

テスト工程で「仕様書どおりに作ると、この条件のときに処理が二重になる」と気づく場面があります。これは検証作業の結果ですが、指摘の中身は要件の不備です。

矛盾を見つけて、どちらを正とすべきかを整理して上げた経験は、要件定義の経験がない人でも持っていることがあります。気づいた事実だけでなく、どう整理して誰に上げたかまでが、書ける材料になります。

【3】非機能の問題は下流で先に現れる

処理時間、同時実行、データ量の増加。非機能の条件が甘いことは、性能試験や本番運用の段階ではじめて表面化します。

その場で条件を測り、どこまでなら耐えられるかを確認した経験は、非機能要件を決める側の材料そのものです。上流の経験が無い、と感じている人の多くは、上流で使う材料を下流で扱っています。

書類選考における経験の示し方

材料があっても、工程名で書くと損をします。書き方を変える必要があります。

【1】工程ではなく決定の単位で書く

× 結合テスト、障害対応、既存機能の改修を担当。

○ 既存機能の改修を担当。変更が他機能に波及する可能性があったため、呼び出し元と関連帳票を洗い出したうえで、修正範囲を当該機能と月次帳票の2点に限定する方針を提案。レビューを経て実装した。

工程名は配属で決まりますが、どこで線を引いたかは本人の情報です。

【2】仕様を決めた根拠を一行入れる

× 性能試験を担当し、改善を行った。

○ 性能試験を担当。夜間バッチの処理時間が運用の締め時刻に収まらない見込みだったため、処理件数の増加傾向から限界点を算出し、分割実行への変更を提案した。

何を見て決めたかが入ると、同じ作業をした他の人と区別がつきます。結論だけを書くと、判断したのか指示されたのかが読み取れません。

【3】経験していないことは書かない

書き方を変えることと、実態を広げることは別です。決まった仕様を文書化しただけの作業を「要件定義を担当」と書くと、面接の深掘りで齟齬が出ます。

なお、ここに挙げた書き換え例は文章の型を示すためのもので、実際に担当した内容に合わせて書き直す前提のものです。事実と異なる記述は、選考でも入社後の配属でも問題になります。

上流に近づけない条件

ここまでの整理が効かない場面もあります。

【1】要件が工程経験そのものを指定しているとき

募集要件に「要件定義の経験3年以上」と書かれている場合、書き方の工夫では埋まりません。要件が工程そのものを条件にしているためです。

この場合に必要なのは、その工程に入れる場所へ移ることになります。ただし移る先は転職先とは限りません。所属会社の中で、一次請けの案件や自社サービス側の部署に配置が変わる余地がないか、先に確認するほうが早い場合があります。

【2】上流が合わないこともある

上流工程は、決めた内容の結果を引き受ける仕事です。仕様を落とした判断が後で問題になれば、その説明も担当することになります。

作る対象が明確な状態で、実装の質を上げることに時間を使いたい人にとって、この配分は負担になります。調整と合意形成に時間が割かれ、手を動かす時間は減る。上流に移った結果、仕事の満足度が下がる人もいます。

【3】上流以外にも軸はある

工程を上る以外に、扱う対象を深くする方向があります。特定の業務ドメインに詳しくなる、性能や可用性といった非機能の領域を専門にする、テスト設計や品質保証を軸にする。

どの軸も、決定を含む仕事につながっています。上流工程は評価される軸の一つであって、唯一の軸ではありません。 工程を上げること自体が目的になっていないかは、動く前に一度確認する価値があります。

まとめ

・上流工程は難易度の階段ではなく、取り消しにくい決定を引き受ける範囲を指す

・「上流」の指す工程は会社ごとに違う。求人票の表記ではなく、どの部署が何を決めているかで確認する

・要件定義の実体は、作らないものを決める作業と、決める前に条件を確定させる作業にある

・決定権は発注した側に残りやすく、階層が下がるほど決定済みの条件が届く。上流に入れない理由が配置側にある場合がある

・テスト・改修工程の中にも決定はある。影響範囲の線引き、仕様の矛盾の整理、非機能の限界の確認がそれにあたる

・要件が工程経験を指定している場合は書き方の問題ではない。転職の前に、所属会社での配置変更の余地を確認する