要件定義入門講座#01 要件定義の全体像・要件定義が難しい理由【システム開発】

00:17:54
https://www.youtube.com/watch?v=HNBQKYB4ie0

Ringkasan

TLDRこのビデオでは要件定義についての基本的な概念と、その難しさの理由について説明しています。要件定義とは、システム開発の初期段階で行われるシステム化の範囲や要件を決定するフェーズであり、プロジェクトの成功を左右する重要な要素です。要件定義が難しい理由として、顧客のニーズを完全には理解できず、結果として要件漏れが発生することが挙げられています。また、異なる立場の関係者間で目的意識がずれることが、認識の問題を生む一因ともされています。ビデオでは要件定義のプロセスを3つのステップ(業務要件の検討、システム要件の検討、実行計画の策定)に分け、その詳細を解説しています。また、目的意識のズレを防ぐために視覚的なツールを用意し、コミュニケーションを図ることが重要とされています。

Takeaways

  • 📝 要件定義はシステム開発の初期段階で非常に重要
  • 💡 顧客のニーズを完全に理解することが難しい
  • 🚀 プロジェクト成功の鍵は初期の要件定義にある
  • 🔍 異なる立場間での目的意識のズレに注意
  • 📊 視覚的ツールを活用してコミュニケーションを円滑に
  • 🧩 タスクは業務要件、システム要件、実行計画の3ステップで進行
  • 🗣️ お客様との合意形成が重要
  • 📅 長期間のプロジェクトでは要件が変わる可能性あり
  • 🔨 実装は顧客ニーズを反映する必要がある
  • 📈 コストと時間の管理が不可欠

Garis waktu

  • 00:00:00 - 00:05:00

    要件定義の概要とシステム開発の流れについて説明があり、要件定義とはシステム化の範囲や要件を決定するフェーズであると説明されます。具体的には、要件をもとにシステムのレイアウトや機能を設計し、それに基づいてプログラムを開発、テストし、最終的に本番環境へ移行する流れです。このプロセスの中で最も重要な部分である要件定義について、さらに詳しく解説することがこの講座の目的です。

  • 00:05:00 - 00:10:00

    要件定義が難しい理由として、顧客の潜在的な要求を引き出す必要があること、そして顧客自身が要件を詳細に把握していないことが挙げられます。また、プロジェクトが長期間に及ぶため、途中で顧客の要望が変わることもあります。さらに、違う立場の関係者間で目的意識が異なることが要件定義を複雑にし、システム要件が明確に伝わらず、結果として使いづらいシステムが出来上がることがあります。これを防ぐためには、要件定義のフェーズでしっかりとコミュニケーションを図り、一致する見解を得ることが求められます。

  • 00:10:00 - 00:17:54

    要件定義のプロセスは主に3つのステップに分かれます。1つ目は、業務要件を検討し、システム化の目的と範囲を明確にするフェーズ。2つ目は、業務要件を基にしてシステム要件を考慮するフェーズで、これにより直接的にシステムの設計を進めます。3つ目は、このシステム要件を実現するための実行計画を立てるフェーズで、プロジェクトのスケジュールや必要なリソースを決定します。また、ドキュメント化や共通認識の形成などの重要性についても触れ、視覚的かつ効果的なコミュニケーションの必要性が強調されました。

Peta Pikiran

Mind Map

Pertanyaan yang Sering Diajukan

  • 要件定義とは何ですか?

    システム化の範囲や要件を決定するフェーズです。

  • なぜ要件定義が難しいのですか?

    顧客のニーズを正確に汲み取れず、要件漏れが発生することが多いためです。

  • 要件定義の重要性とは?

    要件定義がうまくいかないと、開発後に多くの問題が発生する可能性があるため重要です。

  • 要件定義の目的は何ですか?

    システムを構築する目的を明確にし、プロジェクトの成功を確実にするためです。

  • 要件定義のステップは?

    業務要件の検討、システム要件の検討、実行計画の策定の3ステップに分かれます。

  • なぜ顧客のニーズ把握が難しいのですか?

    顧客自身も気付いていないニーズがあり、状況に応じて変わることがあるからです。

  • 要件定義の成功に重要な要素は?

    顧客の要望を正確に汲み取ることと、明確なコミュニケーションです。

  • 要件定義で避けるべきことは?

    あいまいな要件定義や、目的意識の異なるチーム間での認識のズレです。

  • プロジェクトの失敗要因は?

    顧客の要件と開発者の理解の違いや目的意識の違いです。

Lihat lebih banyak ringkasan video

Dapatkan akses instan ke ringkasan video YouTube gratis yang didukung oleh AI!
Teks
ja
Gulir Otomatis:
  • 00:00:01
    皆さんこんにちは一駒です今回は要件定義入門講座
  • 00:00:05
    ということで予見的が難しい理由と要件定義の流れについて解説をしていきます
  • 00:00:11
    チェーンとしてはこのような形で最初に要件定義の概要についてお話をした後に難しい
  • 00:00:16
    とされる理由を解説して最後に要件定義の流れですとか正確性についてお話をしていき
  • 00:00:21
    ます
  • 00:00:23
    最初自己紹介ですが私の経歴このようになっております興味ある方は自己紹介動画も
  • 00:00:28
    ありますのでそちらもご参照ください
  • 00:00:31
    へこのチャンネルではですねシステム開発ですとか言って局から3キャリアに関数情報
  • 00:00:36
    発信をしておりますので興味ある方は是非者の登録の方もよろしくお願い致します
  • 00:00:41
    で早速要件定義の概要についてご説明していきます
  • 00:00:45
    要件定義とはシステム化の範囲システムの要件
  • 00:00:48
    こちらを決定するフェーズとなります
  • 00:00:51
    システム開発の流れとしましては要件定義から始まって会まず回開発の計画ですとか
  • 00:00:57
    スコープ
  • 00:00:59
    もしかも使用する製品とかを秘めていきますここで決めた要件をもとにどのように
  • 00:01:04
    システム化していくかっていうところを画面のレイアウトであったり機能一覧とか
  • 00:01:09
    あとは無視しても全体像みたいなところを設計していく基本設計があります日基本設定
  • 00:01:13
    の内容型より
  • 00:01:15
    プログラムに近い形式で書きます詳細設計があったりそういった
  • 00:01:19
    設計をもとにプログラムを作成したり作ったプログラムが正しく動作するかプログラム
  • 00:01:24
    単体でテストをして複数のプログラムをつなげて一連の流れで検証する切望ですとが
  • 00:01:29
    あったり
  • 00:01:31
    他のシステムと連携させて検証するシステムゼストがあってそれらの品質確認が終わっ
  • 00:01:37
    たら本番移行するというような画になっています
  • 00:01:40
    で今回はですねここの要件定義中をもうちょっと負荷ボっていきたいというふうに思い
  • 00:01:44
    ます
  • 00:01:46
    でシステム開発の全体像を学びたい方はですね概要欄から
  • 00:01:49
    へこちらの入門講座の方もありますのでぜひご視聴ください
  • 00:01:55
    ではへ改めて要件的ではどういうものかというところになりますが
  • 00:01:59
    えシステムを開発する目的を深掘りしてどのような構成スケジュールでシステムを構築
  • 00:02:04
    していくかこれを考えるフェーズとなります
  • 00:02:07
    まあ家づくりいうかと言いますと間取りを決めたりするフェーズかなとで違ったり
  • 00:02:10
    間取り決めるフェイスかなというふうに思います
  • 00:02:13
    例えばですね不動産会社の人が中共の購入を考えてる人に対して
  • 00:02:19
    例えばとの地域に住みたいですかとか一から距離どれぐらいが希望ありますかとか
  • 00:02:24
    周辺施設例えばスーパーなどの周辺施設で何か希望ありますかっていうことを聞いたり
  • 00:02:29
    ですとかあとはですね将来的にこう同居する人数が増えそうですかっていうところ
  • 00:02:33
    here
  • 00:02:33
    リングして立地であったりとか
  • 00:02:36
    部屋の大きさというところを引き出していきます
  • 00:02:40
    このようにですねえベンダー側がユーザー企業側に色々とまぁしてもを投げかけて
  • 00:02:45
    ニーズを引き出すそういうフェーズになっています
  • 00:02:50
    ですの要件定義をやる上で要求都8県の違いというのがまあよく出てくるんですけど
  • 00:02:54
    要求というのは何とかしたいというものになります
  • 00:02:57
    たとえば先ほどの例でいいあのいやの例で言いますと駅から近いほうがいいっていう
  • 00:03:01
    ような要求
  • 00:03:03
    何がにしたいっていう容疑9要望があった場合それを実現するための手段として
  • 00:03:08
    じゃあ例えば過去10分以内の会
  • 00:03:11
    リッチの不動産を見つけましょうですとか
  • 00:03:14
    岐阜クォーク冥福を収納したいという要求に対してじゃあ6帖のウォークイン
  • 00:03:18
    クローゼット有しましょうみたいな形で要求実現している手段を考えるのが要件という
  • 00:03:22
    か形になります
  • 00:03:24
    ですねえユーザーの方をもうこういうふうに顕在化している
  • 00:03:28
    分かっている要求というものがあるんですけど
  • 00:03:31
    表に出てきてない顕在化したら要求というものを存在します
  • 00:03:35
    でこういったものを質問を通じて引き出すというところが
  • 00:03:38
    ベンダー側の腕のみせどころかなというふうに思います
  • 00:03:42
    続いて要件定義が大変だと言われる理由について解説をしていきます
  • 00:03:47
    市政の開発において航空機が遅延するような過半数が要件定義が問題だと言われてい
  • 00:03:51
    ます
  • 00:03:52
    具体的には結構あのニーズですねこれを汲み取れ
  • 00:03:56
    汲み取りきれなくて結果として要件が漏れてしまっていた
  • 00:03:59
    で赤字ですとかあとは要件自体がちょっと曖昧になってしまっていて見積もった時より
  • 00:04:04
    も開発規模が増えてしまったと
  • 00:04:07
    見積もりよりも開発企業が増えてしまったということが挙げられます
  • 00:04:10
    で顧客のニーズというものは本人も気づいていなかったりあとは香り安いものでもあり
  • 00:04:14
    ます
  • 00:04:15
    システム開発というのは結構長期間にわたる
  • 00:04:18
    プロジェクトですので中にもベストまあ2年3年といったも複数年にわたるものもあり
  • 00:04:23
    ます
  • 00:04:23
    そうした間に会社の方針が変わってしまって顧客が求めるものが変わってしまうという
  • 00:04:28
    ものも十分考えられます
  • 00:04:31
    またですね実際にこうユーザーテストみたいな形で実際に動くものを触っていると気が
  • 00:04:36
    つくこともありますので開発の終盤
  • 00:04:39
    プログラム床システムとかを作った後にお客さんに確認してもらっている段階でこれ
  • 00:04:43
    やっぱ違うよという形で指摘されることもあります
  • 00:04:46
    こういうふうにですねえっと本人も気づいてないっていうところがあったりとか
  • 00:04:50
    まあその時の状況によって両県が変わってしまって結果としてええまあ問題になり
  • 00:04:55
    やすいというところが挙げられます
  • 00:04:57
    概してですねあの私が今まで経験してきた中で一番課題だったなっていうところが目的
  • 00:05:02
    意識の違いというところがありますここの意識の違いを認識しないまま言語で
  • 00:05:07
    コミュニケーションしてもなかなか好意思疎通が取れないと
  • 00:05:10
    有限な所がありません
  • 00:05:13
    ですねさっきのあの目的意識というところなんですけど具体的にどういうふうに目的
  • 00:05:16
    意識が違うのかっていうところを立場に立ちばわけでちょっと見ていきたいとおもい
  • 00:05:20
    ます
  • 00:05:22
    まずですね経営者経営者はまあコストの削減も救わ売上の像がこれを見込んで it の
  • 00:05:27
    投資というものを行います
  • 00:05:30
    て続いてビジネス部門の担当者ですねえこの人はですねまぁ自分の担当業務を楽にし
  • 00:05:35
    たりですとか
  • 00:05:35
    上司からの命令があったからそれに従ってやってるとかそういう形でシステムをつくっ
  • 00:05:40
    ていこうと思います
  • 00:05:42
    で情報システム部門の方はですねもちろんビジネス要件を言われた通り守るっていう
  • 00:05:47
    ところはもちろんなんですけど自分たちもシステム保守運用する立場なので運用が楽に
  • 00:05:52
    したいというような思惑があると思います
  • 00:05:55
    で最後ベンダーですねベンダーとしてはあの残業時間ですねえ残業時間を少なくして
  • 00:06:00
    まー
  • 00:06:00
    比較的楽にしても構築したいなというところがあると思いますので
  • 00:06:04
    例えば前例にあてはめてまぁ何ですかね自社のテンプレートみたいなものに当て込んで
  • 00:06:10
    業務を支えてもらうようにするとかそういうふうにですね
  • 00:06:13
    あのビジネス要件を極力簡単にシステム化できるようにちょっと書いていきたいなって
  • 00:06:18
    いうような思いがあると思います
  • 00:06:21
    deko
  • 00:06:22
    経営者の方は割りと漠然とした思いを持っていてまぁ小房サバゲーとか売上増加って
  • 00:06:26
    いう漠然とした思いを持っていて
  • 00:06:29
    ベンダー側ですねこっちになるほどへデュードが細かくへ具体的な目的というか
  • 00:06:34
    目線が細くなるかなというふうに思います
  • 00:06:38
    で結構ですね頻繁にやり取りするのが情報システム部門とベンダーなのでここですね
  • 00:06:42
    近い場所で考えがちでなかなか高コストの削減とか売上のどうかというところまで意識
  • 00:06:47
    がいかないことが多いかなと思います
  • 00:06:49
    こういう風が目的意識の乖離によってビジネス部門川で考えている
  • 00:06:54
  • 00:06:55
    そのシステムを使い方っていうところが
  • 00:06:59
    控除されないシステムを作ってしまって結果として使われな可能
  • 00:07:02
    システムが出来上がってしまうということがありません
  • 00:07:06
    こちらもう一個ですねえ要件敵が大変だと言われる理由というところをちょっと具体的
  • 00:07:11
  • 00:07:11
    英霊を交えながら解説していきたいとおもいますこちらはまあその要件定義が大変だっ
  • 00:07:16
    ていうところを風刺した風刺 f 4がになります
  • 00:07:20
    まずですね左上ここが顧客が5 a 顧客が説明した要件を表しているようになります
  • 00:07:27
    まあこれを見る限り妹えっと木の枝にひもを2本たらしていたが3枚並んでる
  • 00:07:33
    ちょっとブランコなのかなとは思いつつもブランコにしてはちょっと
  • 00:07:36
    いたが多すぎる期の過剰なんじゃないかなというふうに思いますよ
  • 00:07:39
    実際をですね
  • 00:07:40
    あの右下を見てみると木の枝に1本日もたらしてそこに対応をくくりつけるというよう
  • 00:07:46
    な形で
  • 00:07:47
    まあ校木の枝から食べたいうがあったらいいのかなというようなところなんですけど
  • 00:07:51
    顧客もですねご本当に必要だったもののをうまく言葉で自分の言葉で説明できないと
  • 00:07:56
    いうようなケースがありますまあこれは顧客がの問題ではあるんですけど
  • 00:08:00
    ベンダーがですね色々質問して
  • 00:08:03
    こっちに近づけていくっていうことが出来ればあのそのベンダーは非常に後悔際価値が
  • 00:08:08
    あるた海へベンダーと言えるんじゃないかなというふうに思います
  • 00:08:12
    でまたですね顧客の要件を聞いてプロジェクトリーダーが理解したものはこちらになり
  • 00:08:17
    ません
  • 00:08:18
    ブランこっちょブランコなんですけど昨日ミケのところにいたがあるのでこう前後に
  • 00:08:23
    触れることができないですよね行ったり来たりすることができないと
  • 00:08:27
    要するにこう実現できないようなブランコのブランコという機能を実現できないような
  • 00:08:32
    設定になってしまっているというようなところが挙げられますでこれをくみ取って
  • 00:08:36
    アナリストの人は行ったり来たりできるようにしなきゃ
  • 00:08:38
    言えばいけないから高機能幹を切り取って
  • 00:08:42
    で行ったり来たりするようにするというがへ
  • 00:08:46
    仕様をデザインしていますと
  • 00:08:48
    でまぁ木の幹を切り取ってしまっているので木が倒れないようにですねこれにこう補強
  • 00:08:53
    するって言うな
  • 00:08:54
    なかなか難解な仕様を設計していますね
  • 00:08:59
    えっとさすがにこういう設計はできないのでこれを見たプログラマーの人が昨日機に
  • 00:09:04
    日本の柄ひもを垂らしていたを1本ポスト
  • 00:09:09
    言葉だけで見ると近しいんですけど全然ブランコとは程遠いような実装をしてしまうと
  • 00:09:13
    こういうふうにビンゴゲームもあっていいとかなかなか伝わらないっていうところが
  • 00:09:16
    挙げられます
  • 00:09:18
    またですね一方あの開発チームとは別に営業メールとは思うんですけど営業の人はこう
  • 00:09:23
    絵に描いた餅へ過剰の売り込みをしてこんなに立派なものいらないのにこんなに
  • 00:09:27
    素晴らしいんですよみたいな感じでこうちょっと持って表現してしまってここの表現ぽ
  • 00:09:32
    実際できたものが違うじゃないかって言う形で問題になることも結構あります
  • 00:09:37
    また別のプロジェクトの処理というところでもう何もないですね何もない状態なんです
  • 00:09:41
    けどこういうふうにですね様々な仕様変更
  • 00:09:44
    まあこの開発チームの中の仕様変更があるためへドキュメント化ですねえと追いつか
  • 00:09:49
    ないということが往々にしてあります
  • 00:09:51
    そのためへとプロジェクトが終わった時に正しい使用を表して設計書がないということ
  • 00:09:56
    が結構ある
  • 00:09:57
    のでへこれもなかなか風刺して面白い絵だなというふうに思います
  • 00:10:03
    えっと最後ですねえっを実装された運用っていうところなんですけどあのまあこういう
  • 00:10:07
    ふうに色々と
  • 00:10:08
    仕様の変更があったため予算と化膿菌を間に合わせるためにはもうこのでしかない
  • 00:10:12
    みたいな形で最小限も実装し日酔い
  • 00:10:15
    できなかったというようなこところを風刺しています当社の
  • 00:10:19
    えっとへと合わせると
  • 00:10:21
    日本一もがされているとここだけしか会ってないという本当に意味のない実装になって
  • 00:10:25
    しまっていると
  • 00:10:26
    って一方ですねあの口数はかなりかかっているので
  • 00:10:30
    ジェットコースターでも作ったんじゃないかぐらい膨大な金額を請求されたりもします
  • 00:10:34
    ちょっと契約の形態によってはそんなことはないんですけど
  • 00:10:37
    あの小泉ですね時間かかったからその分が辛いという形で請求されるということも結構
  • 00:10:42
    あります
  • 00:10:44
    でまぁなんだかんだで実装されたシステムではあるんですけど運用の中で
  • 00:10:49
    こうバーガー的に回収してしまって結果的に企業全部きっかり取るというような修正を
  • 00:10:55
    してしまったというのを表してもがこちらがあります
  • 00:10:57
    まあ様々なパッチワーク的に回収をすると結果的に本来の目的とは帰りしたシステムに
  • 00:11:03
    なってしまって結果台無しになってしまうということが結構あります
  • 00:11:06
    例えば目的を見失わない見失わないように
  • 00:11:09
    マネジメントすることが非常に重要なんじゃないかなというふうに思います
  • 00:11:14
    ってことでちょっとまとめますとええまあお客さん側ですねいう大企業がが要件を伝え
  • 00:11:19
    られなかったっていうところはもちろんあるんですけどもそれと同じくらいですねあー
  • 00:11:24
    開発者の方も正しく汲み取れないというところがありますがまあなかなかこう目的意識
  • 00:11:28
    が違う人同士が
  • 00:11:30
    言葉でコミュニケーションを取るので認識の齟齬が生まれるっていうところ
  • 00:11:34
    ある程度は仕方ないかなと思うんですけどそれがひどすぎるとこんな感じで悲惨な
  • 00:11:38
    プロジェクトになってしまいますよというえ
  • 00:11:40
    解説となります
  • 00:11:43
    っていうわけでですねえと要件定義が大変な理由について解説をしてきましたか
  • 00:11:47
    では8どういう風にしたらエ
  • 00:11:50
    先ほどのまあ要件定義の認識の底っていうところを極力埋められるのかっていうところ
  • 00:11:54
    を解説していきたいとおもいます
  • 00:11:56
    マツダですね要件定義というのは大きく分けて3つのステップに分けられるかなと思い
  • 00:12:00
    ます
  • 00:12:01
    一つ目が業務要件を検討するフェーズ2つめがそれらを受けてシステム要件を検討する
  • 00:12:05
    フェーズ
  • 00:12:06
    3つ目がへ
  • 00:12:08
    ここで決めというシステム要件を満たすシステムを構築するためにどのような付じゅう
  • 00:12:12
    じゅうでへどのような
  • 00:12:14
    へ人員体制でプロジェクトを進めていくかというものを開設したものになります
  • 00:12:20
    業務用権というのはなんでその要件を上げているのかっていうところをヒアリングし
  • 00:12:23
    テーマに目線を合わせるフェーズですね
  • 00:12:26
    システム要件というのが業務要件とか現場の課題を解決へするためにどういう風な
  • 00:12:31
    システムをつくっていくのかっていうのは設計のフェーズですね
  • 00:12:34
    で最後にへシステム工事に係る a コストですが時間
  • 00:12:38
    っていうところ3つ持って計画を立てていくというところをやります
  • 00:12:42
    ここですねえと要件や目的を確認して現場を確認してその間のギャップですね
  • 00:12:48
    つまりは課題っていうところを把握するというところでなんでシステムが必要なん
  • 00:12:52
    だろうとか
  • 00:12:53
    このシステムを導入導入することで何を8期待してるのかっていうところをお客さん
  • 00:12:58
    からヒアリングをしながら
  • 00:13:00
    目線を合わせるフェーズになります
  • 00:13:02
    で目線がある程度あってきたらですねじゃあその課題を解決するためにどういうことを
  • 00:13:06
    実現していきましょうっていうことをまあいろいろ課題の解決策を考えてその中でも
  • 00:13:11
    システム化するものをピックアップしていくというフェーズになります
  • 00:13:16
    8ここでした妙見堂いうシステムを作っていくかっていうところが決まってきたら実行
  • 00:13:21
    計画を立てていきます
  • 00:13:23
    でじゃあ具体的にどういう成果物を作っていくのかというところなんですけど最初の8
  • 00:13:27
    業務要件の確認のフェーズに関しては
  • 00:13:30
    システム化の方針具体的なもシステム化の範囲であったり目的と書きたいせいか
  • 00:13:35
    あとはまあ制約条件みたいなところ
  • 00:13:38
    書いていきますまた化第一弾ということでまぁ解決すべき課題って何があるんだろうと
  • 00:13:42
  • 00:13:43
    まあその解決方法って何かあるんだろうみたいなところを整理したまあ課題一覧みたい
  • 00:13:47
    なものを準備します
  • 00:13:48
    他にもですね会社によっていろいろ必要なドキュメントリーはあると思いますので
  • 00:13:53
    ええまあそれに準拠した成果物を作っていただければいいかなと思います
  • 00:13:57
    でここでも課題の把握まで終わったら続いてのステップで必要なものが業務フロー図と
  • 00:14:02
    システム拠点一覧になります
  • 00:14:03
    業務フロー図っていうのは業務の流れを表した模式図になりますこれはですねあの古い
  • 00:14:09
    現場の業務フロー図と新しいシステムを組み込んだとの新しい業務フロー図
  • 00:14:15
    両方作る必要があるかなと思います神経を対比させ
  • 00:14:17
    えとこが変わったのかっていうところ分かりやすく明示してあげることが必要かなと
  • 00:14:22
    思います
  • 00:14:23
    私してみよう県一覧に関してはへ
  • 00:14:26
    今回のプロジェクトで
  • 00:14:29
    どこをシステム化するのかというところ別居した
  • 00:14:32
    そういう中欄になりますシステムが具体的な内容ですね
  • 00:14:35
    をまとめたものになりますここまで市のほかにもあの必要なときもあると思いますので
  • 00:14:40
    そちらはあの会社の方針に準拠していただければいいのかなと思いますでまあ最後実行
  • 00:14:44
    計画というところで態勢だったりコストあたり好き中こういうところを埋めて提案しに
  • 00:14:48
    持っていくと
  • 00:14:49
  • 00:14:50
    いうような中になるかなと思います
  • 00:14:51
    [音楽]
  • 00:14:53
    でこの人としてやっぱ黒ですねえっと業務要件の把握のところは法華講巻き込むという
  • 00:14:58
    ところで情報システム部門だけではなくてビジネス部門であったり
  • 00:15:02
    あのほんと一次情報を取るようにその業務を実際に担当している人を呼ぶようにする
  • 00:15:07
    ことが重要かなと思います
  • 00:15:10
    個々の業務フローとかシステム要件に関しては目に見えるものを作って共通認識を醸成
  • 00:15:14
    することが重要かなと思います
  • 00:15:16
    ものによってはドキュメントにきちんとお客さんの承認をもらって進めていくっていう
  • 00:15:21
    ことが重要なんじゃないかなと思います
  • 00:15:23
    業務フローとか沈む41なんてドキュメントでもそうですしうち月の議事録っていう
  • 00:15:27
    ところもあの
  • 00:15:29
    ドキュメントとしてを
  • 00:15:30
    客様省にもらう必要があるかなと思います
  • 00:15:33
    ということでへと最後にまとめとなりますが要件定義は難しいというところでユーザー
  • 00:15:38
    企業とベンチャー企業の目的意識が異なるというところがその一番の要因なんじゃない
  • 00:15:42
    かなと思いますやはりですねあの言葉ガチでのコミュニケーションとが非常に難しいの
  • 00:15:47
    で出来るだけ
  • 00:15:48
    京都かを使って視覚的にですねコミュニケーションが取れるようにした方がいいかなと
  • 00:15:52
    いうふうに思います
  • 00:15:54
    私の要件定義は業務要件ですがシステム要件を決めたりあとはまあ実行計画を決めると
  • 00:15:59
    いう形で3つのフェーズに大きく分けることができるかなと思います
  • 00:16:02
    業務要件に関してはなんでその予言を開けているのかっていうところをヒアリングして
  • 00:16:06
    その後ろにある意図とか目的っていうところを聞き出すというところが a 重要な
  • 00:16:09
    ミッションとなります
  • 00:16:11
    システム要件を絵に関してはですね業務要件ですとか現場の課題を解決するためにどう
  • 00:16:16
    いったシステムを作ればいいのかっていうところへ機能を洗い出していくフェーズに
  • 00:16:21
    なりますここはお客さんとの合意っていうところが非常に重要になりますのでここは
  • 00:16:26
    ですねえ図表と隠しながら
  • 00:16:29
    専門用語を極力使わずにお客さんと今日はコミュニケーションをとることが重要かなと
  • 00:16:33
    思いますでは誰ですね式重リングのところに関してはシステム構築にかかるコストです
  • 00:16:39
    か時間あとはまあそういったものを3つ持って計画とか
  • 00:16:42
    全体のスケジュールというところを決めていきますこういう風にしてですねえ要件って
  • 00:16:47
    言うというところを進めていっていただければいい
  • 00:16:49
    かなと思います
  • 00:16:50
    干支次回以降です猫の一つ一つ業務要件をどういうふうにへ聞き出していくのかでし
  • 00:16:55
    たりシステム要件をどういうふうに気がしていくのか
  • 00:16:57
    スケジュール見積もりをどういうふうにやっていくのかというところ a
  • 00:17:01
    越工業として動画を作っていこうと思いますのでぜひチャンネル登録の方もよろしくお
  • 00:17:06
    願いします
  • 00:17:07
    またですねえとこちらの講義に関しては amazon の方で電車
  • 00:17:10
    それでもへ販売しておりますのでもし興味がある方文字でも読みたいという方は概要欄
  • 00:17:15
    の方から見て頂ければと思います
  • 00:17:18
    amazon の駅んどらーに見れるとに登録されているかが無料で思いますのでぜひ
  • 00:17:23
    この機会に一度ですね無料で試して頂ければと思います
  • 00:17:28
    ってことで8最後までご視聴いただきありがとうございましたこの動画気に入って
  • 00:17:32
    いただけましたら高評価宜しくお願い致します
  • 00:17:34
    ご紹介いただきますと私もどうかを作る励みになりますのでぜひ宜しくお願いします私
  • 00:17:40
    はこのチャンネルではシステム開発に関するノウハウであったり it 企業の
  • 00:17:44
    ケ嶺に関する情報発信をしていますのでぜひ興味ある方はチャンネル登録の方も
  • 00:17:48
    をよろしくお願い致しますそれでは最後までご視聴いただきありがとうございました
  • 00:17:52
    失礼致します
Tags
  • 要件定義
  • システム開発
  • プロジェクト管理
  • ニーズ把握
  • コミュニケーション
  • プロジェクト失敗
  • 異なる意識
  • 業務要件
  • システム要件
  • 実行計画