【SE】上流工程って?要件定義がプロジェクトの明暗を分ける!

【SE】上流工程って?要件定義がプロジェクトの明暗を分ける! SE
こんな人に こんなことを!

・SEの上流工程の仕事に興味がある人へ!
・駆け出しSE、就活生、転職希望者向け!
・上流工程と要件定義の重要性を知ろう!

駆け出しSE
駆け出しSE

開発中心にこなしてきて5年目。そろそろ上流工程を経験したい!要件定義をしてみたい!
どんなことするのか教えて下さい。あと失敗したくないので、抑えるポイントを…

こんにちは!たけしです。

金融SE歴12年。
それ以外の5年間も証券会社本体にいて、ユーザーとして上流工程に関わりました。

今回は、長年やってきた、上流工程、要件定義の徹底解説を。

長文なので、前置きはこれくらいで早速開始!

【関連記事】社内SEへの就職について、完全ナビを用意しております。合わせてお読み下さい!

【関連記事】SEのキャリアプラン策定ガイドをご用意しております。合わせてお読み下さい!

SEの業務のうち「上流工程」とは?~下流工程との違い~

システム開発プロジェクトは、このような流れで進める。大きく「上流工程」「下流工程」の2つに分けて。基本的には上から順番に。

<上流工程>
①要件定義
②プロジェクト計画
③設計

<下流工程>
④開発
⑤テスト
⑥納品

この①~⑥の1つずつを「工程」と呼ぶ。
前半の①~③が、「上流工程」。
後半の④~⑥が、「下流工程」

簡単に言うと違いはこう。

「上流工程」:
何を作るのかを決める工程
「下流工程」:

上流工程で決めたものをひたすら作る工程

プロジェクト全体の期間は短くて2月。
長いと1年以上、2、3年になることも。

「工程」は、会社によって呼び方、分け方が微妙に違う。でも、上の呼び方で通じないことはない…

この記事は上流工程、要件定義が中心。全工程のSEの仕事内容について、詳しく知りたい方。こちらの記事をどうぞ!
SEの仕事の流れとキャリアパスを解説~就活生向け!~

SEは上流工程・要件定義がなぜ重要?

ビル建設に例えると…

・上流工程は、大規模ビルの構想・設計と同じ
・要件定義は、ビルを何に使うか、マーケティング戦略と同じ

大規模開発ほど上流工程が重要になる。

ここでミスがあると、何億、何十億というお金が無駄になる。

よくシステム開発の例えで、「ビルの建設」が持ち出される。
今回はそれにならって説明する。

上流工程の最初の「要件定義」だけで、これらが全て詰まっている。


・完成外観図の作成
・立地や集客戦略の策定
・オフィスビルにするか
・賃貸マンションにするか
・商業施設にするか
・賃貸料やテナント料の設定

・入居者、企業への事前営業
・収益計画の策定

・建設コストの回収計画の策定

失敗したらどうなるか、1つでも忘れたらどうなるか。容易に想像できるはず・・・

要件定義は、建設業界に例えると、不動産デベロッパーの仕事。三菱地所とか三井不動産。

もう十分かもしれないけど。。
さらに、その次の「プロジェクト計画」「設計」。同じく、ビル建設を例に挙げると・・・

「プロジェクト計画」
発注建設業者の選定
・資材の調達計画の策定
・全体コスト計画の策定
・建設詳細スケジュールの策定
「設計」
・地盤設計、配管設計
・デザイン設計
・耐震対策
・各フロア、各部屋の見取り図作成
・建設設計図の作成

建設業界に例えると、「プロジェクト計画」は、大手ゼネコンの仕事。
「設計」は、その子会社、下請けの仕事。

要件定義をミスると最悪の事態に…

ちゃんと決めないで、建設作業に入った時にどうなるか・・・

・下流工程で、致命的な問題が見つかると、上流工程をやり直す事態に
・要件定義に失敗すると最初からやり直す以外の選択はない

・最悪、開発中断も大いにあり得る

初めに説明した開発の工程は、①から⑥まで、順番に進む。前の工程に大きな問題がなければ…

でも、作っている最中に前の工程のミスが発覚する。

「テスト」で「開発」のミスを見つけるならまだまし。

最悪なのは、「テスト」「納品」の工程で、上流工程の致命的な問題が発覚すること。

工程を戻ってやり直しになることもある。作ったものの全部、一部が無駄になることもある。

一部の機能の「設計」に問題がある場合もまだまし。そこだけやり直して、ユーザーと点検すればいい。

最悪なのが「要件定義」に致命的なミスがあった場合。特にユーザーとの認識相違!

例えば、「テスト」の段階で数か月振りにユーザーに加わってもらう。
そこで、こんなことを言われた場合。

「え??これ10Fまで全部オフィスフロアじゃん。1Fには飲食店を入れる予定なんだけど・・・」

まあ、ビル建設ではこんなことあり得ないけど。実際に建物を作るし、各段階で施工主のチェックを受けるし。

でも、システム開発では全然ある。
プログラムというユーザーに見えないものを作るから。

最終段階で、目に見えるサイトができて、見てもらう。そこで、初めて「あれがない」なんてことは。普通。

あと、要件定義は、一部ミスするだけならまし。やらない場合もある。

大規模開発で全くやらないことはないけど、一部漏れる場合が。

では次に、要件定義で決めることを説明。

要件定義のSEの仕事とは?決めること!

「構築するシステムに求めること、
 実現することを決める仕事」

一言でいうとこう。。

全然イメージわかないはずなので。
この章ではこの3つの疑問に答える形で、理解を深めたい。

疑問1:誰が主体で進めるの?
疑問2:なにを決めるの?
疑問3:なにを作るの?

疑問1:誰が主体で進めるの?

・ユーザー部署やお客さまと協同で進める
・対等な関係を築き、半分ずつ分担できればベスト!

でもやっぱりそこは、システム開発プロジェクト。ユーザーは何をどうやって決めるか分からないことも。

というか決めることが多すぎる。。

やっぱり、SEが主導して決めていく。

疑問2:なにを決めるの?

✔システムを作る目的
✔システムに求めること
✔システムを使う人
✔システムをいつから使うか
✔システムを作る効果

これらに対して、なぜ?をもう一段だけ、掘り下げてみる。

以下のポイントを漏れなく、網羅的にユーザーと合意することが重要!

✔システムを作る目的

・収益を拡大したい
 →新商品を販売したい
 →新サービスを開始したい
・コストを削減したい
 →人件費を削減したい
 →印刷費、郵送費削減したい
・リスクを低減したい
 →オペレーションリスク?
 →セキュリティリスク?
・制度・法律を守らないといけない
 →社内の制度?
 →国が定める制度・法律?

✔システムに求めること

・対象とする業務、変える業務
 →廃止する業務、新しく行いたい業務
 →改善したい業務、廃止したい紙
 →変えない業務も明確に
・インプットしたいこと

 →画面で入力したい
 →ファイルで一括アップロードしたい
・アウトプットしたいこと

 →画面で見たい
 →Excelで操作したい
 →PDFで保管したい
・自動化したいこと

 →登録、計算、抽出、マッチング…
・利用したい環境

 →WEB、モバイル、タブレット…

✔システムを使う人

・社内の人間
 →特定の部署?
 →全社員?
 →人数は?頻度は?
・外部のお客さま
 →限られた取引先のみ?
 →広く個人にも開放?
 →最大利用者数、利用頻度は?
・あるいはその両方

✔システムをいつから使うか

・時期が明確に定まっている
 →お客さまに広告・宣伝済
 →制度・法律の施行日が決まってる
・絶対的な期限はないが急いでいる
 →同業他社がサービス開始済
 →毎年多額のコストが発生している
 →リスクが顕在化して事故が発生
・正直いつでも、できればやりたいレベル

✔システムを作る効果

・見込める収益
 →月間、何件の販売・成約を見込む?
 →年間、いくらの収益になる?
・見込めるコスト削減
 →月間、何人、何時間の削減を見込む?
 →何件の印刷費・郵便費を削減?
 →年間、いくらのコスト削減に?
・見込めるリスク削減
 →月間、何件の事故を防止できる?
 →年間、想定される防止被害額は?
システム投資額を何年で回収できる?

疑問3:なにを作るの?

主に、これらの資料を作成。

・要件定義書
・新旧業務フロー対比図
・投資対効果評価シート

要件定義書に全て纏めてもいい。
わたしの場合は、少し性質が異なるので、2つを外出ししてた。
要件定義書の別紙にしてもいい。

・要件定義書

これまで説明した決めるべきことを全て文章に纏める。基本的にはSEが主導して。

後から、ユーザーと認識相違が発生することを防ぐこと。これが一番の目的!

SEが書いた場合でも、時間をとってもらい。
説明し、合意を記録に残す。

ユーザの意思が色濃く出るところは書いてもらうのもいい。

ただ、注意しないといけないのは、ユーザーのドキュメント力とシステム知識。見定めて判断すること。

文章を書くことがほとんどないユーザーもいる。普通に書き間違えることもある。書けないこともある。システム用語を誤って使うこともある。

・新旧業務フロー対比図

図が中心になるので、要件定義書とは分けていた。資料の媒体、わたしはExcelを選択。

このようなことをフロー図に整理。
現状とシステム導入後を対比させる形式で。

・業務の登場人物
→社内の部署、社外の取引先、お客さま、システム
・業務のイベント
→「予約」→「成約」「配送」「精算」

システム導入の前後でどこがどう変わるか明記するのがポイント。さらにユーザーから引出した要件は協調して明記!

設計段階で作成することもある。
でも、この段階で、概要レベルでもいいので整理すべき!

業務全体を整理する過程でユーザから要件が引き出せるから。

・投資対効果評価シート

これはユーザー主体で作ってもらう必要がある。できれば独力で。。

例えば、システムを導入する効果が「収益拡大」の場合。

・新サービス・商品のコンセプト
・潜在需要がある根拠
・売上見込み、具体的な数値目標
・売上見込みの計算根拠

逆に、SEが勝手に作ることはできない。

「要件定義」で必要なSEのスキルは?

・業務知識:
 ユーザーとの意思疎通に必要
・提案スキル:

 技術・業務両方での提案
・ドキュメンテーションスキル:

 ユーザーが分かる言葉で

当たり前かもしれないけど。
要件定義特有の要素がある。
1つずつ簡単に説明。

「業務知識」:
ユーザーとの意思疎通に必要

要件定義は、ユーザーの考えを引出す必要がある。

最低限、ユーザーと会話することができる業務知識が必要。

ユーザが基本的な専門用語、業務用語を使う度に。。「その意味教えて下さい」って聞いてたら。

当たり前だけど、嫌がられる。
信頼されない。
良好な関係は築けない。

そして、業務フローを共に組み立て、共に見直す必要が。基本的な流れも知らずに、できるわけがない。

ただし、当然業務に一番詳しいのはユーザー。
時に分からないことを質問するのは全然あり。

「提案スキル」:
技術・業務両方での提案

まずは技術的な提案。

これがSEの醍醐味だし、ユーザには絶対出せないアイデアがある。

それには、幅広い技術の選択肢を持ち合わせておく必要がある。

ユーザーは、SEに、こう言われた時。
「それはシステムでは無理ですね」
専門家に言われたなら、と諦める。

単なるSEの無知により、ビジネスチャンスを失ったかもしれない。

もちろん、「それならこうすればできます!」も大事。でも同じくらい大事なのが。。

「できますが、コストがかかりすぎるのでこうしませんか?」

あるいは、

「今回はシステム化せずに、Excelでやりませんか?」

と言える勇気も大事。

ユーザーの利益、損しないことを第一に考える姿勢が大事。

「ドキュメンテーションスキル」:
ユーザーが分かる言葉で

SEにとって、重要なスキルとよく言われる。

でも、他の工程で求められるのと少し違う。

要件定義で、作成するドキュメントは、ユーザーと合意できないと意味がない。

ユーザーが理解できないと意味がない。

例えば設計書は、開発者が理解できる専門用語を使えばいい。
プログラミングを間違いないよう、とにかく正確に詳しく書けばいい。

でも、要件定義書は違う。

ユーザーが理解できる言葉で書かないといけない。システム専門用語はなるべく排除。

そして、細かすぎても長すぎてもダメ。
細かすぎて、ちゃんと確認してなかったと、後から言われる。あんな長文読んでないよとも。。

バランスが大事。
後から修正してほしいこと、必ず言われる。
根幹となる部分で言われないことが大事。

細かいことの割り切りも必要。

「上流工程」「要件定義」ができる会社は?

じゃあ、どんな会社にいけば、その仕事ができるかを最後に。

間違いなくできる会社!
社内SEとユーザー系SIer

ただし、規模が小さい会社の社内SEは、注意が必要。

運用中心の場合がある。
問い合わせ対応、ヘルプデスクになってる場合も。

あとは、システムというより、ツールの開発かも。その場合、この記事に書いたことを初めに全部決める必要がない。

大企業子会社のユーザー系SIerは間違いなくできる。
わたしが仕事をしてたのもそう。

だって、大企業の複雑な業務、規模が大きいシステムの専門システム会社だから。

チャンスがある会社!
→メーカー系SIer、コンサル系

大企業から単独受注するプロジェクトもある。
でも、大企業の場合はシステム部が存在する。

システム部員の指示のもと活動する立場かも。
主導権は握れないかもしれない。

難しい会社!
→独立系SIer、ソフトウェア開発会社

2次請け、3次請けになることが多いので難しい。小いさい会社から案件を単独受注することもあるかも。

でもその場合、この記事に書いたような、網羅的な要件定義は、必要ない。

では、以上となります。

他にもSEのスキルやキャリアに関する記事。
いくつか揃えてますので、よろしければどうぞ!

【関連記事】社内SEへの就職について、完全ナビを用意しております。合わせてお読み下さい!

【関連記事】SEのキャリアプラン策定ガイドをご用意しております。合わせてお読み下さい!

– END –

コメント

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