今回は上流工程について学んでみました!
プロジェクトに入って見よう見まねでやったり、過去に参画したプロジェクトを元に動くことが多かったので今回Udemyの講座を受けて体系的に学んでみました!
体験してみた講座は以下です。
【入門】システム要件定義と基本設計（実践ワークで理解する上流工程の進め方）
目次
この記事で伝えたいこと
初めて要件定義など上流工程をする人に対して、流れを掴んでもらいたいです。
そしてよくある失敗に関しては、自分がプロジェクトに関わる中でも、「うわー、それあるわ」って感じの失敗ばかりだったので注意してもらえればと思います!
もっと知りたくなったら、Udemyの講座で学んでみてください! 非常によかったです!
上流工程とは
必要性
まず、上流工程とはどんなことをするのか、言語化をすると以下のような作業をします
- 上流の目的はbizとdevの共通認識をとるフェーズ
- 要件定義のゴールはdevにbizがやりたいことが伝わる
- 基本設計のゴールはbizにdevがどんなシステムを作るのかが伝わる
- bizは基本設計で要件定義を見直す(最後のチェックなので)
- devは画面サンプルとかを利用して早めにdevに共有すると良い
要件定義の段階でシステム開発の目的をしっかり認識合わせをするために非常に重要な工程となっています!
要件定義
要件定義は、bizからdevに相談をするフェーズでポイントはbizとdevの相互理解です
そのため、次のフローで進めてみましょう!
- 要望
- 要求
- 検討
- 提案
- 要件
この辺り大体は自分の頭の中でもあったけどこれがいいんだなぁと改めて感じますね。
では、もう少し詳しく各フローの進め方を知っていきましょう！
要望フェーズ
やること
bizが現状とゴールを把握して、どんなシステムが欲しいのかを考える(基本的にbiz内で完了する作業)
明確にすること
- 現状の洗い出し
- 業務プロセス
- 現状の問題点
- ゴール設定
- 現状とゴールのギャップを分析
- 解決するべき課題の洗い出し
- ヒアリング
- 現場、ユーザに何を求めるか
ポイントは何を目的としているのか、達成したいゴールをはっきりさせることです!
よくある失敗
システム開発の認識合わせが必要。何を解決したいのか?ゴールを定義してから進めるようにしましょう。
じゃないと、関係部署からあれも作って、これも作って!ってなるから要注意!
関係部署から「えー、協力したのに反映してないの?」みたいなことが起こりうるので気をつけましょうね
自分が関わるプロジェクトでもとりあえずこれ作りたい!みたいな形で進むことが多いのでまずゴールを設定して進むようにしましょう。
「bizとしては、ゴールは決まっているじゃん。やってよ」となることが多いような気がするのですが、dev側からするとそれだけだと…ってなりがち
なのでできるだけ要望フェーズの時にしっかり要求フェーズに向けて言語化できていると良いかと思います
要求フェーズ
bizで集めた情報をブラッシュアップして、devに相談するフェーズ
求められること
- 開発目的のブラッシュアップ
- 何を達成すればゴールか決める(数字で明確に)
- 達成条件は何か
- SMARTの法則に沿って
- 業務フロー整理
- 登場人物、使用するシステム、タスクの流れを整理
- 「アクティビティ図、業務フロー」←で検索
- システムに実装したいことを言語化する
- 機能一覧
- 非機能要件(非機能要求グレード2018を参考に)
PMの仕事として、devとbizの話合いには立場の違いからくる意見の相違があるので意見を一つにまとめる必要があります
よくある失敗
- 社内要望をただ集計した資料にしない
- どんな課題を解決したいのかをはっきりする
- プロジェクトの達成条件を明確に決める
devとしてはここでしっかり検討に必要な判断材料を揃える必要があります。
bizサイドはそのプロジェクト以外にもやることが多くて、「もう言ったでしょ、進めて!はいどうぞ!」って疎かになることもあったりするので、この要求フェーズではしっかりdev側が検討できる情報をまとめられるようにしておきましょう
検討フェーズ
エンジニア目線で実現性を検討
- 本当に必要なのか
- 大替案はないか
要求を精査する
要求を精査して開発する機能を削ることが多そう
- 要求されている文言の定義をはっきりさせる
- 例: 新着一覧機能が要求されていたら新着の定義を確認するなど
- 重要な機能だけにして、欲しい機能は後からリリースさせるなど
- 要求に対してできないことがあれば、大替案を出す
- 追加提案もやりたい
よくある失敗
ビジネス側の意見でそのまま作っても欲しいものができません
本当にこの要求で大丈夫なのかを検討する必要があります
完成した時にbiz側から以下のような意見が出てきちゃうので要注意!
- 作っている時に違和感なかった?なんで作った?
- これ使いにくいよ…
自分の過去の現場でも、bizに言われてそのまま作っちゃうなんてことたくさんありました。
これってbizから、「あれ?なんか違うクネ?」っていわれるのはエンジニアにとってもめっちゃ辛いですよね。なのでbizが言っていることが全て正しいわけではないのです!
僕が思うのには、「やりたいこと」っていうのは変わらないので、それをどのようにして叶えるのか?というのがdev側の仕事でもあると思います。
そのため、やりたいこととはなにか?ゴールは何か?というのを意識するようにすると良いかもです!
結局はプロジェクトの成功がbiz側の最終目標なのでそれに向けてシステムを開発するだけなんです!
↑けどそれが難しいんだけどなあ…
提案フェーズ
やること
ここでは要求フェーズで出てきた案に対してのフィードバック(修正)であったり代替え案などを出しつつ、どんなシステムにするのか話合うことになっています。
後は実際に作る機能は何か?などをしっかり話合うことも大切です。ここでは作る機能も大切ですが、作らない機能は何かというのもしっかり話し合いましょう!
自分も経験があるのですが、これを作りましょう!というのは簡単なのですが、これは作りません、後回しにします。というのは後からトラブルになりやすいです。
そのため、「後回しにする、作らない」となった部分に関しては、なぜその対応を取ったのか?というのも絶対に残しておくようにしましょう。
エンジニアとして注意する点としては、できるできないの話をするのではなく、どうしたらその問題は解決できるのか?というのを意識しましょう。
自分もそうなのですが、どうしてもそれはできない、できる。みたいな話をしてしまいがちなのでどうしたらできるのか?という考え方をしてみましょう
よくある失敗
ビジネス側は後からでもできると思ってしまうことです。これってエンジニアからするとめっちゃ困ることで、ちゃんと決めてよ!決めないと開発できないよ、後戻りしちゃうよ!
って思うわけですよね。なのでできるだけその後からというのを防ぐには、以下のような対応をしてみると少しでも防げるかと思います
→基本設計の最初の段階で画面サンプル作って決定
→開発リリースをずらして複数リリースに分けてみる。(最初に巨大なリリースしない)
言語化されていない、潜在的欲求が後から出てくるのは当たり前なのでエンジニアとしてはそれをできるだけ早いフェーズで防ぐ必要があります。
防ぐためにも早めに布石を打ってできるだけ手戻りを防ぎましょう。
要件フェーズ
bizとdevのゴールで共通約束を明確にする
必要なもの
- 機能一覧
- 開発の順番
- やらないと決めたこと
- 業務フローの最新版
- 要求フェーズと要件フェーズの時にはupdateがあると思うので
- 簡単な画面イメージがあると尚更良し
よくある失敗
要件定義が机上の空論になる
もともののユーザニーズから離れちゃう
必ず業務フローに落とし込んで最終チェックするのが必要
まとめ
以上が要件定義フェーズのまとめとなります。
Udemyの講座を受けると一番驚いたのは、「よくある失敗」としてまとめてくださっていることをことごとく大変な現場ではやっているということです。
どの現場でも大体困ることというのは同じことが多いので、その現場に合わせてどのように解決していくのかが非常に大切になってくるかと思いました!
もっとツヨツヨになりたいなあ…
