BLOG

結論

「次は要件定義をやりたい」。営業にそう伝えてから半年たっても、案件表に並ぶのは同じ工程の募集ばかり。よく聞く話です。順番が来ない理由は、本人の力量の手前にあります。要件を定義する責任は、発注側にあると考えられているからです。

独立行政法人情報処理推進機構（IPA）が2019年9月12日に公開した「ユーザのための要件定義ガイド 第2版」に、こう書かれています。「システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています」。伝聞の形ですが、業界の共通認識として置かれた一文です。責任の持ち主が発注側なら、こちらが待っていても順番は回ってきません。

では現場で何が作れるのか。相手が決めるための材料です。まだ決まっていない項目を洗い出し、選べる案と判断の材料を並べて、決める人の前に置く。そこまでを書き残したものが、上流の実績として説明できる材料になります。いまの席のまま作れます。

根拠

金額の話から始めます。ただし、その数字が何を測ったものかを先に確かめておく必要があります。

1. 職種によって、年収の中央値は250万円違います

厚生労働省の「IT・デジタル人材の労働市場に関する研究調査事業」調査報告書（令和6年3月）に、職種別・ITスキルレベル別の年収をまとめた表があります。2023年9月に実施したインターネットモニター調査で、2,000人から回答を集めたものです。数字は自己申告の見込み年収で、その中央値が次のとおりです。

• 設計・構築：レベル3が550.0万円（回答258人）／レベル4が635.0万円（288人）
• 企画立案・プロジェクト管理：レベル3が800.0万円（53人）／レベル4が900.0万円（153人）

同じレベル3で、中央値の差は250.0万円。レベル4でも265.0万円あります。スキルレベルの表示が同じでも、職種の区分が変われば相場が違う、ということです。差は職種の側にあります。

2. ただし、この数字は「移れば上がる」とは読めません

読み方に注意が要ります。この表は、いま設計・構築にいる人と、いま企画立案・プロジェクト管理にいる人を、同じ時点で並べた断面です。同じ人が職種を移ったときにいくら上がったかの記録ではありません。別物です。

回答者数の偏りもあります。レベル3の回答は258人と53人。ただしこれはモニター調査の回答構成であって、世の中の席の数を測ったものではありません。求人が多いか少ないかは、ここからは分かりません。

残るのは一点です。技術の等級が同じでも、引き受ける仕事の種類で相場が分かれている。動かす対象は、等級より役割のほうだという手掛かりになります。

3. 責任の所在がはっきりすると、やることも変わります

先ほどのガイドは、副題を「要件定義を成功に導く128の勘どころ」といいます。進め方についても触れています。ITベンダやシステム部門が中心になって要件定義を進める従来のスタイルから、業務部門のユーザが主体的に関与するスタイルへ。そう変わる必要性が増している、という書き方です。

整理するとこうなります。要件定義で決めるのは発注側です。参画するエンジニアの関わり方は、決めることではなく、決める人が判断できる状態を作ること。この線引きを持たないまま「要件定義の経験がほしい」と言うと、面談で何を話せばよいのかが自分でも分からなくなります。線引きが先です。

4. 非機能要求は、238のメトリクスに分解されています

IPAの「非機能要求グレード2018」は、非機能要求を6大項目・34中項目・116小項目・238メトリクスに体系化しています。6大項目は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー。238メトリクスのうち92項目が、重要項目として示されています。細かい体系です。

これだけ細かく分かれている領域が、打ち合わせで全部詰まることはまずありません。機能の仕様が先に決まり、非機能は「今と同じで」のまま流れていきます。そして現行の実測値を手元に持っているのは、運用や保守の現場にいる人です。238のうち自分の担当範囲なら、数字がすぐ出てきます。

5. 現場で作れる材料は、3種類あります

ひとつめは現行の実測値です。ピーク時の同時接続数、バッチの実行時間、直近1年の障害件数と復旧までの時間。目標値として書かれた数字より、いま実際に出ている数字のほうが効きます。新しい要件を決める人は、現行がどうなっているかを知らないまま案を出していることがあります。手元に実測値がなければ、案と現状を突き合わせられません。順番が逆になります。

ふたつめは選べる案と、選ぶための基準。可用性をどこまで上げるか、移行をどの単位で切るか。案を2つか3つ並べ、それぞれで何が増えて何が減るのかを書きます。決めるのは相手です。並べるのは手元でできます。ここまで書いて、相手はようやく判断できる状態になります。

みっつめは影響範囲の切り分け。たとえばセッション保持の方式を変えると、ログイン周りの機能だけでなく、障害時の切り戻し手順や監視の閾値にも波及します。どこまで揺れるのかは、その現場に長くいる人にしか書けません。外から来た人が短時間で埋められる種類の材料ではないため、参画期間の長さがそのまま強みになります。ここは時間が効きます。

3つとも、いまの工程を担当したまま作れます。ただし、誰に何を渡してよいかは契約の形で変わります。資料を出す先と経路は、先に自社の営業に確認してください。

6. 経歴書に効くのは、決まった場面の記録です

「要件定義（一部）」と書かれた経歴書は、読む側からは中身が見えません。面談で聞かれるのは、どの項目について、どんな案を出し、何を基準に決まったのか。この3点が答えられれば、担当工程の欄が設計や構築のままでも、上流の判断に関わった記録として通ります。

工程の名前だけが並んでいると、確認のための質問が増えます。同じ経験でも、書き方で伝わる量が変わります。

7. 役割が変わっても給与が動かないなら、止まっているのは会社側です

ここまでは客先から見た話です。任される範囲が広がり、単価が上がったのに給与が変わらないなら、原因は社内にあります。どこで止まっているかで、打つ手が変わります。単価が本人に開示されるか、上がった分を給与に反映する定めが社内にあるか、その定めを動かす機会が年に何回あるか、そして反映する額を何を見て決めるか。経路は4つに分かれます。切り分けの手順は、別記事単価と給与をつなぐ4つの関門にまとめました。

行動提案

手を動かせる形にします。

いまの案件で、決まっていない項目を書き出す

非機能要求グレードの6大項目を、上から順に当てていきます。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー。「今と同じで」で流れた項目、誰も数字を確かめていない項目に印をつけてください。10個を目安にすると、たいてい手が止まる項目が出てきます。印が材料の候補です。

渡す先があるかを、先に確かめる

材料を作っても、受け取る人がいなければ止まります。仕様が決まっていない項目を誰が決めているのか、その決定の場に参画メンバーは入れるのか、そして決まった内容はどこに残るのか。この3つを、定例の場か自社の営業に聞いてください。「決まったものを実装してもらう」で答えが揃う現場なら、材料を作るより先に、現場を変える相談のほうが早く効きます。

3つ選んで、現行の実測値と選べる案を1枚にまとめる

1枚で足ります。現行の値、案を2つか3つ、それぞれで増えるものと減るもの。決めてもらう場に持っていければ、議事録に自分の名前が残ります。残った議事録が、次の面談で使える記録になります。それが実績です。

そのうえで、役割が動いたあとに金額が動くかどうかは、会社側の経路で決まります。単価が開示されているか。反映の定めがあるか。移ることを考えるなら、移る先でこの2つを先に聞いてください。上流に移るとき、先に動くのは肩書きではありません。順番を動かすのは、決める人の手元に材料が届いたという事実のほうです。