資格・スキル / スキル
要件定義｜各課ヒアリングの経験をそのまま職務にする
各課から話を聞き、仕様にまとめるという作業を経験してきた方がいらっしゃいます。
これは、要件定義と呼ばれる職務です。
この記事では、対応と、示し方を扱います。
要件と検査は、対になっています
地方自治法第234条の2第1項です。
> 普通地方公共団体が工事若しくは製造その他についての請負契約又は物件の買入れその他の契約を締結した場合においては、当該普通地方公共団体の職員は、政令の定めるところにより、契約の適正な履行を確保するため又はその受ける給付の完了の確認（略）をするため必要な監督又は検査をしなければならない。
監督又は検査をしなければならない、と定められています。
そして、検査をするためには、「何をもって完了とするか」が決まっていなければなりません。
つまり、仕様（要件）は、検査できる形で書かれている必要があるということです。
これが、要件定義の中心にある考え方です。
「良いものを作ってほしい」では、検査ができません。
行政の契約では、この規律の中で仕様を書いてきたはずです。
要件定義とは何をする職務か
| 工程 | 内容 |
|---|---|
| ① 現状を把握する | いまの業務がどう回っているか |
| ② 関係者から聞く | 各部署、利用者、管理者 |
| ③ 要望を整理する | 重複、矛盾、優先順位 |
| ④ 要件にする | 検査できる形の記述に |
| ⑤ 合意を取る | 関係者と、決裁 |
| ⑥ 引き渡す | 設計・開発、または調達へ |
②と③が、庁内ヒアリングの経験そのものです。
④が、行政の仕様書の作成で身についている部分です。
行政で身についていること
| 経験 | 要件定義での使いどころ |
|---|---|
| ① 各課からの聞き取り | 利用者の要望の収集 |
| ② 要望の調整 | 矛盾する要望の整理 |
| ③ 仕様書の作成 | 要件の記述 |
| ④ 根拠の確認 | 法令・規程との整合 |
| ⑤ 検査の観点 | 完了の条件の設定 |
| ⑥ 決裁の取得 | 合意の形成と記録 |
⑤が、最も価値がある部分です。
「どうなったら完了か」を先に決めるという習慣は、民間でも不足していることがあります。
曖昧なまま進めて、後から追加の作業が生じる。
この場面は、どの業界でも起きています。
要件を書くときの注意
| 避けたい書き方 | 置き換え |
|---|---|
| 使いやすくする | ◯◯の操作を◯手順以内で行える |
| 迅速に処理する | ◯件を◯分以内に処理できる |
| 分かりやすい表示 | ◯◯の項目を一覧で表示する |
| 柔軟に対応する | ◯◯の場合に◯◯の処理を行う |
| 十分な保守 | ◯◯の時間帯に対応する |
左の列は、検査ができません。
右の列は、確認の方法が決まります。
この置き換えが、要件定義の技術です。
行政の仕様書を書いてきた方は、この感覚を持っています。
書き方の例
悪い例
> システムの導入にあたり、各課へのヒアリングを担当しました。
良い例
> ◯◯システムの更改にあたり、関係する◯課・◯名から業務の状況を聞き取り。現行の帳票◯種類を棚卸しし、◯種類に統合。重複する要望と矛盾する要望を整理し、優先順位を付けて◯件の要件にまとめた。完了の確認の方法を要件ごとに定め、検査の項目として仕様書に記載。
「相手の数」「棚卸し」「整理」「完了の条件」が入っています。
基本の型は公務員の職務経歴書｜民間で読まれる形にする基本に整理しています。
どの転職先で効くか
| 領域 | 使いどころ |
|---|---|
| ① 自治体向けのシステム | 業務と制度の両方が分かる |
| ② 導入の支援 | 要件の整理、合意の形成 |
| ③ 業務の改善の支援 | 現状の把握、工程の分解 |
| ④ 社内の情報システム | 各部署の要望の整理 |
| ⑤ 調達・発注の支援 | 仕様の作成 |
①について。
自治体向けのシステムでは、制度の要件と業務の運用の両方を踏まえる必要があります。
法令の改正で処理が変わる、様式が条例で定まっている、決裁の流れが規程で決まっている。
これらを踏まえて要件を書ける人は、外から入った人には多くありません。
探し方は公務員経験が活きる求人の探し方に整理しています。
面接で聞かれやすいこと
| 質問の趣旨 | 用意しておくこと |
|---|---|
| 聞き取りの相手と数 | 課、人数、期間 |
| 矛盾する要望の扱い | 3件、整理の仕方 |
| 完了の条件の決め方 | 検査の観点 |
| 合意の取り方 | 誰に、どの順で |
| 後から生じた変更 | 手続と、影響の評価 |
3行目です。
「どうなったら完了とするか」をどう決めたかは、要件定義の力として見られます。
なお、特定の事案が分かる説明は避けてください。
守秘の義務は、退職した後も続きます。
経験の言い換えから相談することもできます。
学ぶ前に考えること
| 確認すること | 内容 |
|---|---|
| ① すでにある経験 | ヒアリング、仕様の作成、検査 |
| ② 足りない部分 | 記法、工程の表現、ツール |
| ③ 応募したい求人の条件 | 開発の経験が必須か |
| ④ 期限 | 応募の時期までに間に合うか |
③で分かれます。
開発の経験が必須の求人では、要件定義だけでは難しいことがあります。
一方、「業務側の経験」「利用者の立場での要件の整理」を求める求人では、該当します。
求人票の応募条件を確認してください。
なお、資格や講座を取れば転職できる、という関係にはありません。
何を聞き、どう整理し、どう決めたかが、評価の対象です。
よくある失敗
1. 「ヒアリングを担当」で止める
整理と決定まで書いてください。
2. 矛盾する要望の扱いを書かない
中核の作業です。
3. 完了の条件に触れない
検査できる形が要件です。
4. 相手の数を書かない
範囲が伝わりません。
5. 棚卸しの結果を書かない
◯種類を◯種類にと数で書いてください。
6. 開発の経験がないことを理由に諦める
業務側の経験を求める求人があります。
7. 制度の理解に触れない
自治体向けでは要件になります。
8. 講座を受ければ進めると考える
どう整理し決めたかが評価の対象です。
まとめ
- 地方自治法第234条の2第1項は、契約の適正な履行の確保と給付の完了の確認のため、必要な監督又は検査をしなければならないとしています
- 検査をするには、「何をもって完了とするか」が決まっている必要があります。要件は、検査できる形で書くものです
- 要件定義の工程は、①現状 ②聞き取り ③整理 ④要件化 ⑤合意 ⑥引き渡しです
- ②③は庁内ヒアリングの経験そのもの、④は仕様書の作成で身についています
- 「使いやすくする」を「◯手順以内で行える」に置き換えるのが技術です
- 矛盾する要望を整理した経験を書いてください
- 聞く力と、範囲を絞る判断は別です。両方に触れてください
行政が相手の求人もまとまっています。行政が相手の求人を見てみる。
よくある質問
システムの担当ではありませんでした
書けます。要件定義は、システムに限りません。業務の委託、施設の整備、イベントの運営、制度の改正でも、同じ作業をしています。「何を求めるかを決め、検査できる形に書き、合意を取る」。この動作が要件定義です。書き方は、「◯◯の委託にあたり、関係する◯課から業務の状況を聞き取り、仕様書に◯件の要件として記載。履行の確認の方法を要件ごとに設定」という形です。分野を問わず、同じ構造です。扱いは契約書の読み方｜自治体の契約実務との差にも整理しています。
要件の書き方の作法を学ぶ必要はありますか
会社によって記法が違います。入社後に合わせる部分が多いため、応募の前に体系的に学ぶ必要は高くありません。優先すべきは、すでにある経験の整理です。何を聞き、どう整理し、どう完了の条件を決めたか。これが書けていれば、記法は後から覚えられます。なお、業務フローの書き方は、要件定義の前段として役立ちます。扱いは別の記事で整理します。応募の時期が近い場合は、書類の作成を優先してください。
「利用者の立場」と「作る側」のどちらで応募しますか
求人票の仕事内容で判断してください。「業務の要件を整理する」「顧客との折衝」「導入の支援」と書かれていれば、利用者側の経験が活きます。一方、「設計」「開発」「実装」が中心であれば、技術の経験が要件になることがあります。なお、自治体向けのシステムの会社では、業務側の担当と、技術側の担当が分かれていることが一般的です。業務側の職種を探してください。職種名は会社によって異なるため、仕事内容の欄で探すのが確実です。読み方は求人票の読み方｜どこを見れば実態が分かるかに整理しています。