<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>アジャイル &#8211; 業務改善コンサルティング情報ブログ</title>
	<atom:link href="https://www.trilogyforce.com/blog/tag/%e3%82%a2%e3%82%b8%e3%83%a3%e3%82%a4%e3%83%ab/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.trilogyforce.com/blog</link>
	<description>業務改善で収益改善！</description>
	<lastBuildDate>Mon, 17 Jun 2024 01:21:12 +0900</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.1</generator>
	<item>
		<title>要件定義書は開発作業の要です</title>
		<link>https://www.trilogyforce.com/blog/the-main-requirements-definition-document-is-development-work/</link>
		<comments>https://www.trilogyforce.com/blog/the-main-requirements-definition-document-is-development-work/#respond</comments>
		<pubDate>Mon, 26 Oct 2015 12:50:48 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[ITに関する情報]]></category>
		<category><![CDATA[アジャイル]]></category>
		<category><![CDATA[システム開発]]></category>
		<category><![CDATA[ドキュメント]]></category>
		<category><![CDATA[要件定義]]></category>
		<category><![CDATA[要件定義書]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=1176</guid>
		<description><![CDATA[要件定義というのは、システム開発を行う際、顧客がシステムで行いたいことやそれに対する 要求事項などをヒアリングし、実装すべき機能を明確化していく作業のことを言いますが、 要件定義書はその内容を書面に書き起こしたもののこと&#8230;]]></description>
				<content:encoded><![CDATA[<p>要件定義というのは、システム開発を行う際、顧客がシステムで行いたいことやそれに対する</p>
<p>要求事項などをヒアリングし、実装すべき機能を明確化していく作業のことを言いますが、</p>
<p>要件定義書はその内容を書面に書き起こしたもののことを言います。</p>
<p><img fetchpriority="high" decoding="async" class="size-full wp-image-1178" src="//www.trilogyforce.com/blog/wp-content/uploads/2015/10/entity.jpg" alt="エンティティ" width="450" height="450" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2015/10/entity.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2015/10/entity-150x150.jpg 150w, https://static.trilogyforce.com/blog/wp-content/uploads/2015/10/entity-300x300.jpg 300w" sizes="(max-width: 450px) 100vw, 450px" /></p>
<p>皆さん、こんにちは。</p>
<p>業務コンサルタントの高橋です。</p>
<p>以前、<a class="sb-line" href="//www.trilogyforce.com/blog/?p=204">開発ドキュメントを残す重要性</a>という記事を書いたのですが、今回は少し内容を</p>
<p>掘り下げ、開発工程の一番先頭にある要件定義に絞ってお話ししてみたいと思います。</p>
<p>どのようなシステム開発においても、まずはクライアントがどのようなことを行いたいと</p>
<p>思っているのか？を、ヒアリングをしながらまとめていきます。</p>
<p>そして、それをシステム化するにあたって絵とテキスト文字にて表現し、設計段階に</p>
<p>入る前にクライアントと一緒にレビューというものを行います。</p>
<p>これは、クライアントと開発業者の間において、クライアント側としては要望している</p>
<p>ことが満たされているかを点検し、開発業者においてはヒアリングした内容に対する</p>
<p>認識が間違っていないかの点検を行う。</p>
<p>つまり、双方にとって間違いのないものであるかどうかを点検する作業になります。</p>
<p>従って、非常に重要な作業となり、タイトルで書いたとおり開発作業の要とも言えます。</p>
<p>では、これを行わないとどうなるのか？</p>
<p>言った言わないの世界に突入し、なかなか終息しない炎上プロジェクトに陥ります。</p>
<p>これはアジャイル開発でも同じことが言えます。</p>
<p>アジャイル開発は実際のシステムを作りながら確認作業を行っていきますが、</p>
<p>それにおいても双方においてコミットされたものは、後からまとまった段階で</p>
<p>ドキュメントとして残しておくのが一般的です。</p>
<p>この要件定義書を基に設計・製造の工程へ入っていくわけですが、それがしっかり</p>
<p>コミットされたものではない場合、間違った認識の基に設計・製造工程が進んで</p>
<p>しまうことになるため、結果的にトラブルに発展してしまうことになってしまいます。</p>
<p>そういったことにならないよう、この工程はしっかり押さえておくことが肝心です。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/the-main-requirements-definition-document-is-development-work/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
