<?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>株式会社ＫＢマネジメント &#187; BABOK®関連BLOG</title>
	<atom:link href="http://kbmanagement.biz/?cat=17&#038;feed=rss2" rel="self" type="application/rss+xml" />
	<link>http://kbmanagement.biz</link>
	<description>知識資産の最大化を実現する　ＫＢマネジメント</description>
	<lastBuildDate>Tue, 31 Mar 2026 10:30:41 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
		<item>
		<title>ビジネスアナリシスのマインドセット（2）</title>
		<link>http://kbmanagement.biz/?p=6098</link>
		<comments>http://kbmanagement.biz/?p=6098#comments</comments>
		<pubDate>Sun, 21 Apr 2024 13:12:19 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®関連BLOG]]></category>
		<category><![CDATA[#DX]]></category>
		<category><![CDATA[＃BABOK]]></category>
		<category><![CDATA[＃BA標準]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=6098</guid>
		<description><![CDATA[ビジネスアナリシスのマインドセット（2） 最近発行された「ビジネスアナリシス標準」では、マインドセットが大幅に ...]]></description>
				<content:encoded><![CDATA[<h1 class="MsoNormal"><span style="mso-bidi-font-size: 10.5pt; font-family: 'ＭＳ Ｐゴシック'; mso-fareast-language: JA;">ビジネスアナリシスのマインドセット（<span lang="EN-US">2</span>）</span></h1>
<p><span style="color: #000000;">最近発行された「ビジネスアナリシス標準」では、マインドセットが大幅に強化されましたのでご紹介します。</span></p>
<p><span style="color: #000000;"> <a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2024/04/BA標準.png"><img class="alignnone size-medium wp-image-6099" alt="BA標準" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2024/04/BA標準-207x300.png" width="207" height="300" /></a></span></p>
<h3><span style="color: #000000;">マインドセットとは</span></h3>
<ul>
<li><span style="color: #000000;">「マインドセット」とは、人がさまざまな状況にもたらす確立された一連の態度や習慣。</span></li>
</ul>
<h3><span style="color: #000000;">マインドセットがなぜ重要なのか？</span></h3>
<ul>
<li><span style="color: #000000;">すべての状況は独自（ユニーク）であり、決まりきったビジネスアナリシスのアプローチといったものはありませんので、そのコンテキストに応じて、タスク、テクニック、ツールを様々な組み合わせで活用する必要があります。</span></li>
<li><span style="color: #000000;">特に最近は変化の激しいVUCAの時代なので、変化に惑わされずに、自信を持ってアプローチするには、習慣、態度、行動、実践において、正しいマインドセットをもつ必要があるわけです。</span></li>
</ul>
<h3><span style="color: #000000;">ビジネスアナリシス・マインドセットの源泉は次の2つです。</span></h3>
<ul>
<li><span style="color: #000000;">ビジネスアナリシスの6つのコア・コンセプト</span></li>
<li><span style="color: #000000;">人々が持つ共通の価値観</span></li>
</ul>
<h3><span style="color: #000000;">まず、6つのビジネスアナリシスのコア・コンセプトがあります。BABOKの最重要な概念です。</span></h3>
<ul>
<li><span style="color: #000000;">ニーズ</span></li>
<li><span style="color: #000000;">チェンジ</span></li>
<li><span style="color: #000000;">価値</span></li>
<li><span style="color: #000000;">ソリューション</span></li>
<li><span style="color: #000000;">ステークホルダー</span></li>
<li><span style="color: #000000;">コンテキスト</span></li>
</ul>
<p><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2024/04/BACCM.png"><img class="alignnone size-medium wp-image-6100" alt="BACCM" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2024/04/BACCM-300x168.png" width="300" height="168" /></a></p>
<p>このコア・コンセプト・モデルについては下記URLのITmediaエグゼクティブのコラムで紹介していますので、そちらをご覧ください。</p>
<p><a href="https://mag.executive.itmedia.co.jp/executive/articles/2404/16/news026.html">https://mag.executive.itmedia.co.jp/executive/articles/2404/16/news026.html</a></p>
<h3> 共通の価値観は次のとおりです。</h3>
<ul>
<li> 敬意（人を信頼し尊重する）</li>
<li> 勇気（変革への勇気）</li>
<li> コラボレーション</li>
<li> 継続的な学習と改善</li>
<li> 顧客重視</li>
<li> 価値の最大化</li>
</ul>
<p>上記共通の価値観ですが、アジャイル分野では常識のものではないでしょうか。そうです、このマインとセットはビジネスアナリシスのコア・コンセプトとアジャイルでの価値観を組み合わせたものと考えられます。</p>
<h3>このマインドセットを開発するために、次のことに焦点を当てたビジネスアナリシスの活動をすることが奨励されています。</h3>
<ul>
<li>価値：　まずはビジネスアナリシスにより生み出される価値を考えましょう。</li>
<li>成果：　そして、生み出される成果をどのように考えるか</li>
<li>ビジネスアナリシス原則：　（後述しますので少しお待ちください）</li>
<li>ビジネスアナリシス・タスクへの取り組み方</li>
<li>基礎コンピテンシーの積極的な開発<br />
→　特に「倫理」「信頼感」「リーダーシップ」「チームワークと影響力」、「共感」、「システム思考」、「ファシリテーション」などです。</li>
<li>いくつかの基本的なテクニック（特に引き出しのテクニック）を使用しましょう。そしてステークホルダー・エンゲージメントを得ることが重要です。</li>
</ul>
<h3>上記を実行することにより、ビジネスアナリストは次の能力が身に付きます。</h3>
<ul>
<li>価値提供に優先順位を付ける（価値と成果、「優先順位を付ける」タスクが有効です）</li>
<li>影響を受けるステークホルダーに共感する（基礎コンピテンシー「共感」を使いましょう）</li>
<li>チェンジを起こすために仲間を作り協働する（ステークホルダー・エンゲージメントを高めます）</li>
<li>コンテキストを評価し、現実に適応する（ビジネスアナリシス・コア・コンセプト）</li>
<li>常にステークホルダーから学ぶ（ステークホルダー・エンゲージメントが有効です）</li>
<li>知識の構築と共有を簡素化する</li>
<li>フィードバックを反映して適応する</li>
<li>質の高い成果を生み出すよう努める（上記「成果」そのもの）</li>
<li>測定可能な価値を迅速に提供する</li>
</ul>
<h3>柔軟で順応性のあるマインドセットにより、次の様な活動が可能になります。</h3>
<ul>
<li>戦略に影響を与える</li>
<li>真の顧客に共感すること</li>
<li>ビジネスプロセスを変革すること</li>
<li>ビジネス・エコシステム内のステークホルダーに真剣に取り組んでもらうこと（エンゲージメント）</li>
<li>事実に基づくフィードバックと学習の推進</li>
<li>必要なチェンジを実装し、支援するためにテクノロジーを活用すること（DXにつながります）</li>
</ul>
<p>&nbsp;</p>
<h2> ビジネスアナリシスの原則</h2>
<h3>次の原則は、効果的なマインドセットのために重要です。</h3>
<ul>
<li>全体を見る</li>
<li>顧客として考える</li>
<li>価値あるものは何かを決めるために分析する</li>
<li>例を使って真実を得る</li>
<li>実行可能なものは何かを理解する</li>
<li>コラボレーションと継続的改善を促進する</li>
</ul>
<p>もとはBABOKのアジャイル拡張版に記載されていたものですが、アジャイルのみならずビジネスアナリシス全般における原則に昇格しました。以下に解説です。</p>
<h4>全体を見る</h4>
<ul>
<li>– 全体像のコンテキストでニーズを分析し、チェンジが必要な理由を特定する。</li>
<li>– 望ましい成果は、コンテキスト、ソリューション、およびステークホルダーを理解することによって生み出される。</li>
</ul>
<h4>顧客として考える</h4>
<ul>
<li>顧客体験上のニーズを理解して、そのニーズに対応するソリューションを構築する。</li>
<li>チームは、顧客ニーズの概要把握から始め、それを分解して詳細な理解を得て、新たなソリューションを進化させるのに利用する。</li>
</ul>
<p>自分が顧客だったら何が欲しいだろうかと、自問自答しましょう。</p>
<h4>価値あるものは何かを決めるために分析する</h4>
<ul>
<li>提供される価値を最大化するために、作業を継続的に評価し、優先順位を付ける。</li>
<li>チェンジにおける価値は、コンテキスト、ニーズ、ステークホルダー、ソリューションの可能性を理解することで生まれる。</li>
</ul>
<h4>例を使って真実を得る</h4>
<ul>
<li>実例を評価することは、ニーズと、ソリューションがそのニーズをどのように満たすかについて共通の理解を構築するために重要となる。</li>
<li>例を使用して、受け入れ基準を導き出し、ソリューションのデザインを支援し、ソリューションをテストするための基盤を提供することもできる。</li>
</ul>
<p>具体的なものを見たり聞いたりすると、自分が欲しかったものが分かりますね。「あっ、これが欲しかった」。</p>
<h4>実行可能なものは何かを理解する</h4>
<ul>
<li>ニーズと、優先順位付けされたニーズを満たせるソリューションを継続的に分析することにより制約条件の下でソリューションを提供する方法を理解する。</li>
<li>また、ソリューションが意図した価値を確実に提供するために、運用環境内での制約条件を考慮する必要がある。</li>
</ul>
<p>実行可能ですからチェンジ可能なものが分かります。使い物になっているかどうかは重要です。</p>
<h4>コラボレーションと継続的改善を促進する</h4>
<ul>
<li>すべてのステークホルダーが継続的に価値に貢献する環境の構築を支援する。</li>
<li>継続的なフィードバックを使用して、提供価値を高めるソリューション自体と、開発プロセスを適応させる。</li>
</ul>
<h4>ムダを省く</h4>
<ul>
<li>付加価値のある活動とそうでない活動を特定する。</li>
<li>ニーズを満たすことに貢献しない活動を排除する。</li>
</ul>
<p>&nbsp;</p>
<h2>マインドセットの効用としてUNLOCK</h2>
<p>DXを実現する際に大きな障壁となるのが、従来の常識や制約にとらわれた、いわゆるLOCKされた心理的状況です。これを打破するためにはこの心理的状況を解放（UNLOCK）する必要があります。ビジネスアナリストがLOCKされた状況ではDXを実現することは難しいでしょう。まずビジネスアナリストがUNLOCKされる必要があります。</p>
<p>上記の価値観やマインドセットがUNLOCKに大きく貢献するのではないでしょうか。</p>
<h3>　　Lockされた状況　　　　　　　　　　　　　        　UNLOCKする価値観やマインドセット</h3>
<ul>
<li>目的を考えるのは自分の仕事ではない　　　　　　　　戦略に影響を与える</li>
<li>組織では上司の意見に従うべき　　　　　　　　　　　勇気</li>
<li>予算がかかるものはやれない　　　　　　　　　　　　勇気</li>
<li>残業しないわけには行けない　　　　　　　　　　　　勇気</li>
<li>効率化しても残業代が減るからやりたくない　　　　　勇気</li>
<li>改善しても問題が出ると嫌だから提案しない　　　　　価値の最大化</li>
<li>言われたことをきちんとやることが自分の仕事　　　　真の顧客への共感</li>
<li>他の部門との調整が必要なことはしない　　　　　　   コラボレーション</li>
<li>これはシステム会社の仕事ではなく事業会社                    必要なチェンジを実装し、支援するためのテクノロジーの活用<br />
（親会社）のやること<em id="__mceDel"><em id="__mceDel">　　</em></em></li>
</ul>
<p>&nbsp;</p>
<p>マインドセットをしっかり持つことの重要性を認識しましょう。</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=6098</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ビジネスアナリシスのマインドセット（1）</title>
		<link>http://kbmanagement.biz/?p=6071</link>
		<comments>http://kbmanagement.biz/?p=6071#comments</comments>
		<pubDate>Wed, 10 Apr 2024 09:12:46 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®関連BLOG]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=6071</guid>
		<description><![CDATA[ビジネスアナリシスのマインドセット（1） あまり知られていませんが、重要なことにビジネスアナリシスのマインドセ ...]]></description>
				<content:encoded><![CDATA[<p>ビジネスアナリシスのマインドセット（1）</p>
<p>あまり知られていませんが、重要なことにビジネスアナリシスのマインドセットがあります。実は大変重要なことで、<br />
ビジネスアナリシス（BABOK）の根幹とも言えるものです。</p>
<p><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2014/07/V3_UC_Overview_2014年7月12日.png"><img class="alignnone size-medium wp-image-2051" alt="V3_UC_Overview_2014年7月12日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2014/07/V3_UC_Overview_2014年7月12日-300x225.png" width="300" height="225" /></a></p>
<p>まず、「基礎コンピテンシー」の行動特性があります。</p>
<p>行動特性は、ビジネスアナリストがステークホルダーからの信頼と尊敬を得られるようになるための行動特性をまとめたもので。知識やスキルではなく、実行（行動）できていなければ意味のないものです。ビジネスアナリストが信頼と尊敬を得るために必須です。特に、「倫理」と「信頼感」は不可欠です。</p>
<h3> 【倫理】</h3>
<p>ビジネスアナリストが倫理的であるためには公平さ、配慮、道徳的な振る舞いについての理解と集中が必要で、ビジネスアナリシスのアクティビティーと人間関係を通して行われます。また倫理的な行動には、提案したソリューションがすべてのステークホルダー・グループに及ぼす影響について考慮し、すべてのグループをできる限り公平に扱うように努力しなくてはいけません。特定のグループの便益だけを考慮するようなことをしてはいけません。<br />
また、自身の能力や作業パフォーマンスについて誠実であり、失敗や間違いの責任を受け入れることについても誠実になりましょう。</p>
<h3>【信頼感】</h3>
<p>BABOKでは、信頼感の要因としてつぎのことを述べています。<br />
「自信のある態度を一貫してとること。そのことにより、同僚やステークホルダーは、そのビジネスアナリストの姿勢に強さを感じる。誠実で率直な行動をとり、衝突や懸念があれば直ちに対応すること。そのことにより、同僚やステークホルダーは、そのビジネスアナリストの精神を誠実で裏表がないと感じる。」</p>
<p>次の問いはあなたの「信頼感」のチェックです。</p>
<ul>
<li>ステークホルダーが、議論や意思決定の場にあなたを同席させてくれますか？</li>
<li>難しいトピックや異論の多いトピックについてステークホルダーがあなたと話し合うことに前向きでしょうか？</li>
<li>あなたが問題が起こしたときにステークホルダーがあなたを責めないでかばってくれますか。</li>
</ul>
<p>読者の皆様はステークホルダーから信頼されていますよね（念のため）。</p>
<h3>【リーダーシップと影響力】</h3>
<p>リーダーシップと影響力は、人の意欲を引き出し、共通のゴールと目標の達成を目指して協力して働くように促します。ステークホルダーごとの動機やニーズ、能力を把握し、それらを効果的に組み合わせられれば、組織の共通の目標を達成しやすくなります。</p>
<p>プロジェクトマネジャーの場合は人・モノ・カネの権限を持ちますが、ビジネスアナリストはステークホルダーに対して何も権限ありません。それでもリーダーシップを発揮する必要があります。ですから、ビジネスアナリストは、相手が自分の直属の部下であるかどうかにかかわりなく、リーダーシップと影響力を磨くよい機会と言えます。</p>
<p>どうしたら良いのでしょうか。</p>
<ul>
<li>例えば、望ましい未来の状態について明確で意欲的なビジョンが提示し、ビジョンを行動にうまく移行させるのはどうでしょうか。明確なビジョンを示すことは極めて重要です。</li>
<li>また、お互いの利益を理解できるように、ステークホルダーを感化することも有効です。</li>
<li>他者に影響を与えるための個人の動機を超えてより広い目標を考慮するように、ステークホルダーに影響を与えたりしましょう。</li>
</ul>
<h3>【チームワーク】</h3>
<p>リーダーシップと表裏一体の関係にあるのが「チームワーク」です。</p>
<ul>
<li>ビジネスアナリストは、チームはどのように形成され、どのように機能するかを知りましょう。チームの力学を認識し、プロジェクトのさまざまな段階を踏んでチームが成長していく過程で、力学がどのように作用するかを知りましょう。</li>
<li>チームメートとの信頼を築き、良好に保つことは、チーム全体の一体感を高め、チームのパフォーマンスを最大限に引き出します。</li>
<li>しかし、チームにおいて衝突はよくあることです。適切に対処すれば、衝突の解消がチームにとってむしろメリットをもたらすこともあります。</li>
<li>そのためには、協働作業の環境が育まれ、適切に衝突が解消され、チーム・メンバー間の信頼を醸成しましょう。</li>
<li>そうすれば、共有されている高い達成基準に向けて、チーム内で支え合う雰囲気がでて、チームゴールに対する当事者意識を共有することができます。</li>
</ul>
<p>リーダーが全責任を持つという専制型のリーダーシップではありません。リーダーもチームメンバーも同等に責任を共有する、という新しいリーダーシップです。責任を共有する（Shared Responsibility）リーダーシップとでも言うのでしょうか。<br />
前述の信頼感が前提ですね。</p>
<p>ビジネスアナリストはステークホルダー（要求を引き出す相手）の上司ではありませんから専制型リーダーシップで「引き出し」がうまくできるわけありません。ステークホルダーが責任を共有してもらうようになってくれることが重要です。</p>
<p>ここで不可欠なのが、ステークホルダー・エンゲージメントという考え方です。</p>
<h3> 「ステークホルダーのコラボレーションをマネジメントする」タスク</h3>
<p>「エンゲージメント」に対応する日本語が見当たりません。有名なのは男女間でのエンゲージメントで「婚約」のことです。また、現在ウクライナでは戦争が起きています。痛ましいニュースに心が痛みます。そこではロシア軍とウクライナ軍が交戦していますが、この「交戦」も実はエンゲージメントと言います。喧嘩もエンゲージメント。2つの歯車が噛み合うこともエンゲージメントです。「婚約」と「交戦」が同じ「エンゲージメント」という言葉に、日本人の感覚としては（日本語にその概念がないため）理解しずらいです。</p>
<p>要するに、良い、悪いことには関係なく両者が真剣に取り組むこと（婚約も交戦も相手と真剣に取り組んでいる状態です）です。</p>
<p>知識エリア「引き出しとコラボレーション」の中の「ステークホルダーのコラボレーションをマネジメントする」タスクがあります。このタスクの目的は、「共通のゴールに向けて一緒に仕事をするように、ステークホルダーに奨励すること」です。</p>
<h3>ステークホルダーのコラボレーションをマネジメントするとは、</h3>
<ul>
<li>「ステークホルダーの前向きな反応を利用し、後ろ向きの反応をビジネスアナリストが和らげたり、回避したりすること」で、また、ステークホルダー・エンゲージメントがうまくいっている状態は、</li>
<li>「自分の声が届いている、自分の意見が取り上げられている、自分の貢献が認められている」、と関係しているステークホルダーのすべてが感じている状態」です。</li>
<li>コラボレーションがうまくいっている関係においては、妨害や障害があったとしても自由に情報をやり取りする経路は確保され、問題解決や望ましい成果の達成のための共同の取り組みが推進されます。</li>
</ul>
<p>最後にこのタスクのアウトプットを紹介します。</p>
<h4>アウトプット：ステークホルダー・エンゲージメント：</h4>
<ul>
<li>ビジネスアナリシスのアクティビティーに進んで取り組み、必要があればビジネスアナリストとやり取りしようとするステークホルダーの自発的意思</li>
</ul>
<p>最後の「取り組もうとする自発的な意思」がエンゲージメントという事になりますね。この「ステークホルダーのコラボレーションをマネジメントする」タスクはある意味、BABOK(R)の中で最も重要なタスクと言えるかもしれません。ステークホルダー・エンゲージメントをうまく高めることが、ビジネスアナリシスを成功に導く鍵、と言えます。</p>
<p>ビジネスアナリシスの活動は極めて人間的な要素が強いものです。決められたタスクを実行するだけのものではありません。</p>
<p>そして、その前提として、基礎コンピテンシーの「倫理」、「信頼感」、「リーダーシップと影響力」、「チームワーク」を忘れてはいけません。結果としてステークホルダー・エンゲージメントを得ることができます。</p>
<p>正に「人と人との絆（きずな）」と言えます。人と人との絆（きずな）がビジネスアナリシスには不可欠です。</p>
<p>ビジネスアナリシスは、望ましい成果を生み出すための人間主体の探索的で創造的な取り組みです。決められたタスクを単に実行するだけの活動ではありません。</p>
<p>少し長くなりました。続きは次回のお楽しみに。少しお待ちください。</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=6071</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>初めてのビジネスアナリシス　（6）最終回</title>
		<link>http://kbmanagement.biz/?p=4746</link>
		<comments>http://kbmanagement.biz/?p=4746#comments</comments>
		<pubDate>Fri, 17 Apr 2020 06:53:51 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®ガイドV3　情報]]></category>
		<category><![CDATA[未分類]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=4746</guid>
		<description><![CDATA[第6章　プロジェクト終了後のビジネスアナリシス ビジネスアナリストの活動の中にはプロジェクト終了後においても、 ...]]></description>
				<content:encoded><![CDATA[<h1>第6章　プロジェクト終了後のビジネスアナリシス</h1>
<p align="left">ビジネスアナリストの活動の中にはプロジェクト終了後においても、プロジェクト中から引き続き行わなければいけない活動があります。それは要求マネジメントです。要求はシステムが納入され運用されてもまだ価値を提供し続けます。ですからプロジェクト終了後の運用中においても適切に管理する必要があるのです。具体的には次のようなタスクがあります。</p>
<h3 align="left">要求をトレースする：</h3>
<p align="left">影響分析や、カバレッジ、割り当てのために、要求、デザイン、ソリューション・コンポーネント、その他のワーク・プロダクト間の関係を分析し、維持します。プロジェクト終了後においても要求の新たな追加が考えられますから、トレーサビリティは重要です。</p>
<h3 align="left">要求を維持する：</h3>
<p align="left">ライフサイクル全体を通じて要求とデザインを正確かつ最新に保ち、状況に応じた再利用を容易にします。特に再利用は運用中で可能になります。</p>
<h3 align="left">要求に優先順位を付ける：</h3>
<p align="left">特定の要求とデザインに関連する価値、緊急性、リスクをアセスメントし、常に、最も重要なものに対して分析または実装、もしくはその両方に関する作業が実施されるようにします。プロジェクト最中のみならず、運用中においてもシステム改修への要求の優先順位付けは重要です。</p>
<h3 align="left">変更要求を評価する：</h3>
<p align="left">新たなステークホルダー要求および変更されたステークホルダー要求を評価し、チェンジのスコープ内で対応する必要があるかどうかを判断します。プロジェクト終了後の運用中にも変更要求が出てくる可能性があります。</p>
<h3 align="left">要求を承認する：</h3>
<p align="left">ガバナンス・プロセスに関与するステークホルダーと協力し、要求およびデザインについて合意を形成し、承認を獲得します。</p>
<p align="left">これらの活動はプロジェクト中で行うだけでなく、プロジェクト終了後、運用中でも行わなければいけません。そして多くの作業は手作業（エクセル）ではなく専用の要求管理ツールで行うことが奨励されています。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/要求ライフサイクル_2020年4月17日.png"><img class="alignnone size-medium wp-image-4748" alt="要求ライフサイクル_2020年4月17日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/要求ライフサイクル_2020年4月17日-300x225.png" width="300" height="225" /></a></p>
<p align="left">[画像クリックで拡大表示]</p>
<p align="left">プロジェクトが終結したからと言ってビジネスアナリシスの仕事は終了ではありません。ここがプロジェクトマネジャーとの大きな違いです。一般にプロジェクトが顧客に受け入れられるとプロジェクトが終結し、プロジェクトのメンバーは解散します。プロジェクトマネジャーもお役目ご免になりますね。よく考えると、プロジェクトで作成したプロダクトが成功しているかどうかはまだわからないのに、プロジェクトの責任者であるプロジェクトマネジャーはどこかへ行ってしまいます。何か変だと思いませんか。しかし現実はそのようです。では、プロダクトが成功したかどうかを見極める責任は一体誰なのでしょうか。</p>
<p align="left"> 実はビジネスアナリストがそれを担っています。あまり知られていないかもしれませんが。もちろんスポンサーが最終責任者ですが、納入されたプロダクトがビジネス的に成功しているかどうか、そうでない場合は何をしたらよいのかを見極めるのもビジネスアナリストなのです。ビジネス的な価値が出ていればよいのですが、そうでない場合はプロダクト内の問題（ITで言えば欠陥・バグです）の深刻度、再発の可能性、業務オペレーションに及ぼす影響、さらに事業がその影響をどの程度吸収できるかを判断します。そしてどの問題は解決する必要があり、どの問題は他のアクティビティーやアプローチで軽減でき、どの問題は許容できるかを明らかにします。</p>
<p align="left"> また、プロダクト以外の問題、すなわちエンタープライズ側の問題として、組織文化をアセスメントしますが、これはプロジェクト内でステークホルダー・エンゲージメントが高まっていたはず（やる気になっていること）ですが、運用時でのエンゲージメントのチェックにもなります。この時点でエンゲージメントが下がっていると、使われないシステムになりかねないので極めて重要です。</p>
<p align="left">さらに、組織的変革が必要なソリューションにもかかわらず組織がまだ変革されていない場合は組織的変革を提案することにもなります。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/変革の管理_2020年4月17日.png"><img class="alignnone size-medium wp-image-4749" alt="変革の管理_2020年4月17日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/変革の管理_2020年4月17日-300x225.png" width="300" height="225" /></a></p>
<p align="left">組織的変革の活動の例：</p>
<ol>
<li>レガシー（従来のソリューション）のままではパフォーマンスが上がらないのみならず、組織の将来が危うくなる恐れがあることを明確に伝える。</li>
<li>変革を進めるために連帯チームを結成する。</li>
<li>新ソリューション導入後の成功した将来像のビジョンを作成し、戦略を考える。</li>
<li>作成したビジョンをさまざまな方法で周知徹底する（ポータルサイト、など）。</li>
<li>アーリーアダプターの人たちに自発的に変革を体験してもらう。</li>
<li>その短期的な成功事例を認め、他の多くの人たちにPRする。</li>
<li>マジョリティの人たちにも、安心して移行を働きかけ、さらに変革を進める。</li>
<li>変革を企業文化に定着させる。</li>
</ol>
<p align="left">　　　　　　　　（ジョン・コッター「企業変革力」を筆者がカスタマイズしたもの）</p>
<p align="left"> ここで重要なのはチェンジを実現することです。いくらバグのない（少ない）ITシステムが構築されて納入されても、ユーザー（顧客）が使用（それがチェンジ）してくれない限り価値は生まれません。いかにして使って（チェンジして）もらうかがポイントです。そのためには良いプロダクトを作成することだけでなく、顧客（やユーザー）が喜んで受け入れてもらうことが何よりも重要です。ですからビジネスアナリシス/BABOKはこのチェンジに重きを置いた知識体系になっていることをご理解いただければと思います。このようにプロダクトのみならず、それを使用するステークホルダー、受け入れてもらう組織構造や組織文化、そしてそれらの相互作用で価値を創出するという、エンタープライズ全体的な視点で考えるアプローチのことをシステム思考と言います。</p>
<p align="left">このシステム思考を理解することがビジネスアナリシスにとって極めて重要です。</p>
<h3 align="left"> <b>【システム思考】</b></h3>
<p align="left">問題や状況を、複数の要素がつながっている全体構造として考える思考であり、次のような考え方をします。</p>
<ul>
<li>「全体」は単なる「部分」の総和ではありません。森は森。木、数万本の集合ではありません。相互作用した全体が意味を持ちます。</li>
<li>「問題は全体構造にあります」</li>
<li>要素をむやみに排除しません、切り捨てません。</li>
</ul>
<p align="left">当たり前のことを言っているようにも聞こえるかもしれません。<br />
これは、システム思考とは対極的な位置づけにある分析的思考と比較するとその違いがよく分かります。</p>
<p align="left">分析的思考では、問題や状況を構成している要素（部分）に分けて考える思考（要素分解思考とも言います）であり、次のような考え方をします。</p>
<ul>
<li>「全体」は「部分」の総和です。森は木の集合です。木の相互作用は重視しません。</li>
<li>「問題は特定の部分にある」と考えます。ですからその特定部分を取り除くことが問題解決につながります。</li>
<li>重要でない要素は排除します、切り捨てます（重点的思考です）。</li>
</ul>
<p align="left">分析的思考では、アウトプットを重視する客観主義ですので、次のことに重きを置きます。</p>
<ul>
<li>「細部（種類）の複雑性」に着目します</li>
<li>分解するための次のような枠組みが重要です</li>
<li>「MECE」、「ロジックツリー」、「マトリクス」、「フレームワーク」など</li>
<li>また「事実と意見を分ける」ことはその基本です。</li>
</ul>
<p>一方、システム思考はアウトプットではなくプロセスを重視し、動態的であり、客観ではなく主観（内省主義）ですから、次のことに重きを置きます。</p>
<ul>
<li>変化の過程（流れ）、「時間的流れ・順序」「空間的隔たり」「行動の遅れ」</li>
<li>人や組織のメンタルモデル（価値観、世界観）まで考慮します</li>
<li>自分（気持ち、内的システム）と外部とのつながり</li>
<li>長期的で、全体的な課題像を重視しますから、戦略・ビッグピクチャ―・勝ちパターンなどを考察します</li>
</ul>
<p align="left">分析的思考は、従来問題解決の手段として広く活用されていてその価値は万人が認めるものです、決して分析的思考が劣っているということを主張しているのではありません。この点は注意が必要です。</p>
<p>実はシステム思考が活用されている場面は意外に多く見受けられます。例えば経済学。景気（消費者心理が重要）、気象の予報（天気予報）など。地球の温暖化はまさにシステム思考と言えます。</p>
<p align="left">下図は分析的思考とシステム思考との比較をまとめたものです。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/システム思考_2020年4月17日.png"><img class="alignnone size-medium wp-image-4751" alt="システム思考_2020年4月17日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/システム思考_2020年4月17日-300x225.png" width="300" height="225" /></a></p>
<p>実はBABOKはシステム思考の影響を大きく受けています。<br />
筆者が気付いただけでも下図のようにシステム思考が随所に反映されています。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/BABOK_システム思考_2020年4月17日.png"><img class="alignnone size-medium wp-image-4752" alt="BABOK_システム思考_2020年4月17日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/BABOK_システム思考_2020年4月17日-300x225.png" width="300" height="225" /></a></p>
<p>例えば、ビジネスアナリシスの定義「ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動」もシステム思考の影響を受けています。具体的にはエンタープライズ：「組織とソリューションからなるシステム」。このシステムはまさにシステム思考の「システム」です。</p>
<p>チェンジを引き起こすためにはステークホルダーの内面（心情や価値観）にまで気を配ることが重要です。単にITシステムを構築するだけでなく、喜んで使ってもらうためにはどうしたらよいかまで考える必要がありますが、まさにシステム思考と言えます。<br />
さらに、「4.5ステークホルダーのコラボレーションをマネジメントする」タスクはステークホルダーの「自発的意思」すなわち、内面（ひとの気持ち）を対象とした新しいタスクでありシステム思考そのものと言えます。システム思考を知らないとBABOK® を理解することができないと言っても過言ではありません。考えてみれば、ビジネスそのものもシステム思考と考えた方がよくわかるのではないでしょうか。ビジネスの全てが分析的思考で構成されていると考えることは難しく、システム思考として捉えた方が合理的かもしれません。</p>
<p align="left">この次のサイクルへの進み方には次のようにいくつかの場面（コンテキスト）があります。</p>
<ul>
<li>受入れ時の問題解決：<br />
バグ修正の小規模なプロジェクト</li>
<li>受入れ後の運用時の問題：<br />
ソリューションの改修プロジェクトになります。この場合は単なる問題解決（バグ修正）のみならず機能強化も実施されることになりますが、以前取り残された要求（優先順位が高くなくベースラインから外れたもの）を取り込むことを考えるのではなく、その時点の現状（Current）のビジネス状態を反映したものにすることが大切です。</li>
<li>長期間に使用していたソリューションの場合：<br />
継続費用（特に保守料）と初期投資を比較したり、機会コストや埋没コストを考慮して、ソリューションを廃止し、新たなソリューション構築のプロジェクトをスタートすることを提案することもあります。</li>
</ul>
<p align="left">最後にプロジェクト・マネジャーとビジネスアナリストの役割の比較です。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/PMとBAの役割_2020年4月17日.png"><img class="alignnone size-medium wp-image-4753" alt="PMとBAの役割_2020年4月17日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/PMとBAの役割_2020年4月17日-300x225.png" width="300" height="225" /></a></p>
<p align="left">出典：　Business Analysis: Best Pracatice for Success by Steven P. Blaise John Wiley &amp; Sons, Inc.</p>
<p align="left"> このリストをご覧になった多くのプロジェクト・マネジャーが共通に口にするのは次のようなことです。</p>
<ul>
<li>「でも、左側のBAの役割の仕事もかなりやっています」</li>
<li>「やらされていますね」</li>
<li>「誰もやってくれないから仕方なくやっています」</li>
</ul>
<p align="left">ではビジネスアナリシスの仕事に関する研修を受けていますか、と尋ねると帰ってくるのは決まって次のようなことです。</p>
<ul>
<li>「ビジネスアナリシスの研修は受けたことありません。勘と経験と度胸（KKD）で自己流でやっていますから、うまくいくときもあればうまくいかないときもあります。」</li>
</ul>
<p align="left"> 大変残念です。このままではいつまでたっても失敗プロジェクトが減りそうにありません。また研修も受けていないのに自己流でビジネスアナリシスの仕事までやらされている日本のプロジェクト・マネジャーは大変お気の毒だと思います。</p>
<p align="left">裁判沙汰にまで発展することになればなおさらです。</p>
<p align="left">真の解決策はプロジェクト委託契約をしっかりすることではありません。ステークホルダーの要求をしっかり定義できるビジネスアナリストを採用または育成することです。</p>
<p align="left">従来のプロジェクト・マネジャー（PMBOK第5版までのPMP）は受講したPMBOK関連の研修では、ビジネスアナリシトとの協働の必要性を何もご存じないと思います。</p>
<p align="left"> そしてプロジェクト・マネジャーは本来のプロジェクトマネジメント業務に専念しビジネスアナリストと協働でプロジェクトをマネジメントすることしかありません。</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=4746</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>初めてのビジネスアナリシス　（5）</title>
		<link>http://kbmanagement.biz/?p=4730</link>
		<comments>http://kbmanagement.biz/?p=4730#comments</comments>
		<pubDate>Sun, 12 Apr 2020 07:24:43 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®ガイドV3　情報]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=4730</guid>
		<description><![CDATA[第5章　プロジェクト中のビジネスアナリシス（後半） プロジェクトマネジメントの知識体系PMBOK®︎には「要求 ...]]></description>
				<content:encoded><![CDATA[<h1>第5章　プロジェクト中のビジネスアナリシス（後半）</h1>
<p align="left">プロジェクトマネジメントの知識体系PMBOK<sup>®︎</sup>には「要求事項収集」というプロセスがありますが、実は以前はありませんでした。最近と言ってもかなり前のことになりますが、途中から追加されたことをご存じでしょうか。PMBOK<sup>®︎</sup>第3版まではなかったのですが、第4版から追加されたのです。ですから第3版までにPMPを取得されたプロジェクト・マネジャーにとってはあずかり知れないことかもしれません。ではなぜ、途中の第4版から追加されたのでしょうか。疑問を感じる人はあまり多くなさそうですが、すこし考えてみましょう。</p>
<p align="left">PMBOK<sup>®︎</sup>によると、プロジェクトには大きく2種類のプロセスがあります。それらはプロジェクトのマネジメント・プロセスとプロダクト指向プロセスです。そしてPMBOK<sup>®︎</sup>はプロジェクトのマネジメント・プロセスのみを扱いプロダクト指向プロセスは対象外とされています。では、要求事項収集はどちらのプロセスでしょうか。プロダクトに関する要求事項を扱いますから、実はプロダクト指向のプロセスと言えます。マネジメント・プロセスとしてはWBSとして要求事項文書、アクティビティとして要求事項収集を定義し、メンバーの誰かをアサインし、進捗を管理するというプロセスを実施すればよいのです。すでにマネジメント・プロセスとしては十分にカバーされていると言って差し支えないものです。ですから本来のPMBOK<sup>®︎</sup>には「要求事項収集」というプロセスは必要ありませんでした。なくてかまわないものなのです。ITを扱うプロジェクトにおいて必要ならば、そのWBSとアクティビティを定義し管理すればよいのです。ですからこの「要求事項収集」というプロセスは、プロダクト指向プロセスは対象外というPMBOK<sup>®︎</sup>の原則を逸脱していることになりそうです。</p>
<p align="left">では、一体なぜPMBOK<sup>®︎</sup>の原則を踏み外してまでも新しい「要求事項収集」プロセスを追加したのでしょうか。不思議だと思いませんか。それは冒頭に紹介した日経コンピュータ誌の結果と同様に、PMIでの調査による失敗プロジェクトの原因の最大要因が「要件定義」だったからではないでしょうか。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/PMIサーベイ_2020年3月29日.png"><img class="alignnone size-medium wp-image-4731" alt="PMIサーベイ_2020年3月29日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/PMIサーベイ_2020年3月29日-300x225.png" width="300" height="225" /></a></p>
<p align="left">[画像クリックで拡大表示]</p>
<p align="left">PMIでは毎年Pulse of Profession Studyという調査をおこない、プロジェクトの失敗要因を調べています。上図は2014年の結果ですが、なんと失敗プロジェクトの47%が「要求管理の不備（Poor Requirement Management）」と結論付けています。この年はかつてなく悪い数字でしたが、ここ数年40%前後で推移しています。　<a title="PMI" href="https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/requirements-management.pdf?v=035f1807-7eea-420a-880f-2e6bf4acba4c" target="_blank">PMI Pulse of Profession Survey 2014</a></p>
<p align="left">PMBOK<sup>®︎</sup>の原則としてプロダクト指向プロセスは対象外のはずでしたが、このようにはっきりと失敗要因が明確になれば、究極の目的であるプロジェクトを成功させる知識体系としては原則を踏み外してもプロダクト指向の「要求事項収集」プロセスを追加せざるを得なかったのではないでしょうか。</p>
<p align="left"> 少し脱線したようです。ビジネスアナリシスの話に戻しましょう。ではその「要求事項収集」プロセスを見ていきます。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/要求事項収集プロセス_2020年4月12日.png"><img class="alignnone size-medium wp-image-4732" alt="要求事項収集プロセス_2020年4月12日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/要求事項収集プロセス_2020年4月12日-300x225.png" width="300" height="225" /></a></p>
<p align="left">[画像クリックで拡大表示]</p>
<p align="left">上図はPMBOK<sup>®︎</sup>第5版の「要求事項収集」です。このプロセスのアウトプットは要求事項文書ですが、その内容は次の通りです。</p>
<ul>
<li>ビジネス要求事項</li>
<li>ステークホルダー要求事項</li>
<li>ソリューション要求事項</li>
<li>移行要求事項</li>
<li>その他</li>
</ul>
<p align="left">この中のビジネス要求事項、ステークホルダー要求事項、ソリューション要求事項などは次の通りです。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/要求事項一覧_2020年4月12日.png"><img class="alignnone size-medium wp-image-4733" alt="要求事項一覧_2020年4月12日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/要求事項一覧_2020年4月12日-300x225.png" width="300" height="225" /></a></p>
<p align="left">[画像クリックで拡大表示]</p>
<p align="left">では、この「要求事項収集」プロセスのインプットとツールと技法からビジネス要求事項、ステークホルダー要求事項、ソリューション要求事項などが作成できるでしょうか。</p>
<p align="left"> 技法としてインタビュー、フォーカスグループ、ファシリテーション型ワークショップなどがありますが、これらは要求の引き出しで使われるものばかりで、ステークホルダー要求事項やソリューション要求事項を作成するのに必須のモデリング技法（データフロー図、UML、データモデルなど）がありませんね。ですからこのプロセスではこれらの要求事項（とくにステークホルダー要求事項とソリューション要求事項）をアウトプットとして作成することは無理があると言わざるを得ません。一体どうやってステークホルダー要求事項（モデル化された）やソリューション要求事項（モデル化された）は作られるのでしょうか。その疑問を解消するためには次の図を理解する必要があります。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/要求事項収集とBA_2020年4月12日.png"><img class="alignnone size-medium wp-image-4734" alt="要求事項収集とBA_2020年4月12日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/要求事項収集とBA_2020年4月12日-300x225.png" width="300" height="225" /></a></p>
<p align="left">[画像クリックで拡大表示]</p>
<p align="left">プロジェクトマネジメントのPMBOK<sup>®︎</sup>はプロジェクトマネジメント・プロセスだけを扱っていて、プロダクト指向プロセスには何も触れていません。そのため、このような形になります。4種類の要求はまさにプロダクト指向のプロセス（のアウトプット）です。それを扱っているのが、ビジネスアナリシス（知識体系としてBABOK）で、PMBOK<sup>®︎</sup>とBABOKで明確に2つを分担していることになります。</p>
<p align="left">ビジネス要求事項はBABOKの「戦略アナリシス」の活動で作成され、ステークホルダー要求事項とソリューション要求事項はBABOKの「要求アナリシスとデザイン定義」の活動で作成されま、移行要求事項もBABOKで作成されます。それら4種類の要求事項はすべてビジネスアナリストが作成します。ですから、PMBOK<sup>®︎</sup>ではプロジェクトマネジメントのプロセスとして、ビジネスアナリストが作成した4種類の要求事項を収集する（Collect）プロセスを定義しています。決して要求を引き出し（elicit）て要求事項をまとめるのではなく、ビジネスアナリストが作成した要求事項文書を収集（collect）するだけなのです。</p>
<p align="left">言い変えると、PMBOKの「要求事項収集」というプロセスは、ビジネスアナリシスのBABOKおよびその活動を実施するビジネスアナリストの存在を前提にしたプロセスである、といえます。ですからプロセス名は「引き出す（elicit）」ではなく、「収集（collect）」になります。ビジネスアナリストが要求を引き出し、要求に優先順位をつけ、要求を分析（モデル化）し、要求を検証し、要求の妥当性確認し、要求を文書化した「ステークホルダー要求事項」、「ソリューション要求事項」」などを、プロジェクトマネジメントとして単に「収集（collect）」するプロセスです。要求事項文書はビジネスアナリシス/BABOKでは「要求パッケージ」と称する場合があります。具体的には、RFP（お馴染みですね）、BRD（ビジネス要求文書）、SW要求仕様書、プロダクトロードマップなどが該当します。</p>
<p align="left">ところがビジネスアナリスト不在のプロジェクトの場合はどうなるでしょうか。次の図解をご覧ください。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/日本のPJの実情_2020年4月12日.png"><img class="alignnone size-medium wp-image-4735" alt="日本のPJの実情_2020年4月12日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/日本のPJの実情_2020年4月12日-300x225.png" width="300" height="225" /></a></p>
<p align="left">[画像クリックで拡大表示]</p>
<p align="left">誰も要求事項をまとめる人材がいませんね。ステークホルダー要求やソリューション要求を責任もってまとめる人材がいません。そして多くのプロジェクト・マネジャー（PMBOK第5版までにPMPを取得者された方）はビジネスアナリストがプロジェクトに不可欠なことをご存じありません。それが受注者側のみならず、発注者側にも不在だとしたら、そのプロジェクトの先行きは大変暗いものにならざるを得ない、ということです。日本のITプロジェクトの半数が失敗するのもうなずけるというものではないでしょうか。</p>
<p align="left">重要なので繰り返します。PMBOKはプロジェクトのマネジメント・プロセスのみを対象にしています。プロダクト指向、特に要求に関する部分はビジネスアナリシス/BABOKが担っています。プロジェクトを成功に導くためにビジネスアナリシスが不可欠な主要な理由です。 今まではPMBOKの第5版を参照していましたが、最新の第6版を見てください。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/6版_要求事項の収集_2020年4月12日.png"><img class="alignnone size-medium wp-image-4736" alt="6版_要求事項の収集_2020年4月12日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/04/6版_要求事項の収集_2020年4月12日-300x225.png" width="300" height="225" /></a></p>
<p align="left">[画像クリックで拡大表示]</p>
<p align="left">注目していただきたいのは「ツールと技法」の最初の「専門家の判断」です。この第6版で追加されました。これこそビジネスアナリストを指しています。やっと第6版でビジネスアナリストの存在が明文化されるようになりました。以下はPMBOK第6版からの引用です。よくお読みください。</p>
<ul>
<li>「ステークホルダーの要求事項を引き出し、文書化し、マネジメントすることは、プロジェクト・スコープ・マネジメントのプロセス内で行われる。プロジェクト・スコープ・マネジメントの傾向と新たな実務慣行は、ビジネスアナリシス専門家との次のような協業に焦点があてられる．．．」</li>
<li>「ビジネスアナリシスを実行する責任を負う役割は、十分なビジネスアナリシスのスキルと専門知識のある人的資源に割り当てられる必要がある．．．」</li>
<li>「プロジェクト・マネジャーとビジネスアナリストとの関係は、協力的なパートナーシップがなければならない。プロジェクト目標を成功のうちに達成するためにプロジェクト・マネジャーとビジネスアナリストが互いの役割と責任を十分に理解しあうことによって、プロジェクトが成功する可能性はより高まる。」</li>
</ul>
<p align="left">そして、プロジェクトマネジメントとビジネスアナリシスの主な違いは次の通りです。</p>
<ul>
<li>プロジェクトマネジメントの主な焦点はプロジェクト</li>
<li>ビジネスアナリシスの主な焦点はプロダクト</li>
</ul>
<p align="left">遅きに逸した感じがしますけれど、 やっとPMBOKにビジネスアナリストとの協働作業がプロジェクトを成功に導く旨の記述がされるようになりました。これで晴れて日本でもプロジェクトにおけるビジネスアナリシスの重要性が認識されるようになることを期待します。</p>
<p align="left"> 読者でPMP取得の方はぜひご自分が取得した時のPMBOKガイドのバージョンを確認してください。第5版までにPMP取得された方（ほとんどかもしれません）は最近のビジネスアナリストとの協働の必要性をご存じない可能性があります。ぜひ第6版をご覧いただきたいと思います。</p>
<h3 align="left">ファシリテーション</h3>
<p align="left">要求定義においても基礎的なコンピテンシーは重要です。特にファシリテーションで顕著です。テクニックのワークショップをスムーズに行うために不可欠なコンピテンシーです。出席者全員に参加を促し、ステークホルダー同士で意思決定し、問題を解決し、アイデアや情報を交換し、要求の優先順位や要求の性質について合意できるようにします。ある要求を主張するグループAとそれとは異なる要求を主張するグループB。Aの要求を採用するとBが困る（反対する）、Bの要求を採るとAが嫌がる。このような衝突はITプロジェクトでは珍しくありません。グループA、グループBを含む全グループの要求を引き出し、そして中立的な要求案Cを見いだすようにファシリテーションを行います。そこで役に立つのは「交渉と衝突解消」というスキルです。交渉のスキルを使うとうまく衝突を解消することができます。</p>
<h3 align="left">交渉と衝突解消</h3>
<p align="left">以下はある「交渉術」の研修で用いられている寸話を引用します。</p>
<p align="left">「ある姉妹が冷蔵庫にある一つのオレンジを取り合って喧嘩しています。二人ともオレンジ丸一個ほしいと言い合っています。それを見かねた母親が仲裁を試みますが、二人とも引き下がりません。二人とも、どうしても「オレンジ丸一個必要」と主張しています。そこで、母親はひとりひとりにどうしてオレンジ丸一個ほしいのか聞いてみました。姉は「昨日、家庭科の授業でオレンジマーマレードの作り方を教わったから、これからオレンジ丸一個使ってマーマレードを作る。レシピにオレンジ丸一個必要と書いてあるから半分ではできない。」と言い張ります。次に母親は妹を呼んで聞くと「ジョギングしてのどが渇いたから丸一個のオレンジをジュースにして飲む。半分では足りない」と。母親が、妹にオレンジの皮はどうするのか聞くと、「皮なんかいらないから捨てるわよ」と。姉は「マーマレードに必要なのは皮だけ、実の部分は要らない」と言いました」。見事に二人の姉妹は自分の欲しいものを100%ずつ手にすることができました。」</p>
<p align="left">似たような状況はいくらでもあるはずです。相手にとって重要なものでも自分とって取るに足らないものならあげればよい。代わりに相手にとって些細かもしれないが自分にとって価値のあるものならもらえばよい。そのためにはお互いが何を重要と感じているのか（価値観）を知ることが大切です。そうすればWin/Winの関係が実現できるのではないでしょうか。主張している立場（姉も妹もオレンジ丸一個を主張）が重要ではありません、二人の背後にある利害（本当に必要なもの：価値）を理解することです。それを可能にするにはお互いの信頼感が不可欠なことも忘れてはいけません。</p>
<p align="left"> リーダーシップとチームワークはビジネスアナリストにとって極めて重要です。</p>
<h3 align="left">リーダーシップ</h3>
<p align="left">ビジネスアナリストはステークホルダーに対して何の権限もありませんがリーダーシップを発揮する必要があります。ここはプロジェクト・マネジャーと決定的に違う点です。プロジェクト・マネジャーの場合は「人、モノ、金」の権限を持ちますが、ビジネスアナリストは何も権限を持ちません。にもかかわらずリーダーシップを発揮する必要があります。ポイントはビジョンです。望ましい未来の状態について明確で意欲的なビジョンを提示し、人を動かしビジョンを行動にうまく移行させるのです。お互いの利益を理解できるように、ステークホルダーを感化し、ステークホルダーに影響を与えるための協働のテクニックを効果的に活用することにより、個人の動機を超えてより広い目標を考慮するように、ステークホルダーに影響を与えます。これは上下関係に関係ないリーダーシップで、いわば「責任を共有するリーダーシップ」と言えます。アジャイルのリーダーシップ（サーバント・リーダーシップ）にも通じます。</p>
<h3 align="left"> チームワーク</h3>
<p align="left">チームワークも不可欠です。</p>
<p align="left">ビジネスアナリストは、チームはどのように形成され、どのように機能するかを知っておかなければなりません。チーム力学を意識し、プロジェクトのさまざまな段階を踏んでチームが成長していく中で、力学がどのように作用するかを知ることも極めて重要です。チームメートとの信頼を築き、良好に保つことは、チーム全体の一体感を高め、チームのパフォーマンスを最大限に引き出すのに有効です。チームにおいて衝突はよくあることです。適切に対処すれば、衝突の解消がチームにとってむしろメリットをもたらすこともあります。</p>
<p align="left">そして、協働作業の環境が育まれ、適切に衝突が解消され、チーム・メンバー間の信頼が醸成されるようにします。共有されている高い達成基準に向けて、チーム内で支え合う雰囲気を作るのです。チームゴールに対する当事者意識が共有されることが重要です。</p>
<p align="left"> 「リーダーシップ」と「チームワーク」は表裏一体です。リーダーが全責任を持つという専制型のリーダーシップ（PMBOKでのリーダーシップ）ではありません。リーダーもチームメンバーも同等に責任を共有する、という新しいリーダーシップです。協働型のリーダーシップとでも言うのでしょうか。前述の信頼感が前提ですね。</p>
<p align="left">ビジネスアナリストはステークホルダー（要求を引き出す相手）の上司ではありませんから専制型リーダーシップで「引き出し」がうまくできるわけありません。ステークホルダーが責任を共有してもらうようになってくれることが重要です。これもエンゲージメントにもつながります。</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=4730</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>初めてのビジネスアナリシス　（4）</title>
		<link>http://kbmanagement.biz/?p=4714</link>
		<comments>http://kbmanagement.biz/?p=4714#comments</comments>
		<pubDate>Sun, 05 Apr 2020 07:09:57 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®ガイドV3　情報]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=4714</guid>
		<description><![CDATA[第4章　プロジェクト中のビジネスアナリシス（前半）  プロジェクト中のビジネスアナリシスの活動は多くあります。 ...]]></description>
				<content:encoded><![CDATA[<h1>第4章　プロジェクト中のビジネスアナリシス（前半）</h1>
<p align="left"> プロジェクト中のビジネスアナリシスの活動は多くあります。<br />
いまさらながらですが、ビジネスアナリストとは何をする人でしょうか。<br />
以下はBABOKからの引用です。</p>
<ul>
<li>ビジネスアナリストは、エンタープライズ内のさまざまな情報源から情報を発見、統合し、分析する責任をおう。</li>
<li>ビジネスアナリストは現状の課題と原因を決定するために、ステークホルダーの真のニーズを引き出すことに責任を負う。</li>
</ul>
<p align="left">「真のニーズを引き出すことに責任を負う」とはすごいことを言ってますね。「ステークホルダーの真のニーズ」とは何でしょうか。言い換えるとステークホルダーのまだ自覚していない真のニーズを引き出すことです。まさに「言うに易し、行うは難し」。簡単なことではありません。筆者に言わせれば、顧客の真のニーズとは、それが分かれば苦労しないものです。なかなかわからないから、大変なのではないですか。<br />
そのため、あの手この手のテクニックを使わなくてはいけません。例えば、</p>
<ul>
<li>インタビュー</li>
<li>ワークショップ</li>
<li>調査・アンケート</li>
<li>ブレーンストーミング</li>
<li>観察</li>
<li>ベンチマーク</li>
<li>マインドマップ</li>
</ul>
<p align="left">などがあります。</p>
<h3 align="left">データマイニング：</h3>
<p align="left">ステークホルダーに聞けば教えてもらえるものは限られています。本人が自覚しているニーズや要求なら、インタビューで教えてもらえます。しかし、まだぼんやりしているニーズで自分ではうまく表現できない、しずらい、さらに全く気付いていないニーズや要求（真のニーズ）までを引き出す必要があります。そしてビジネスアナリストにはその責任があるのです。そのため最近では上記のテクニックに加えて、ステークホルダーの気が付いていない（全く知らない）ニーズを発見するために「データマイニング」まで引き出しのテクニックに追加されるようになりました。大変な驚きです。今から10年以上前ですが、アメリカのスーパー・マーケットで販売データを分析した結果、おむつを購入する若夫婦が帰りがけに缶ビールも購入する傾向が分かったというものです。そのスーパーではパンパースの売り場の隣に缶ビールを置いたところバカ売れした。という事例です。若夫婦たちは決しておむつと一緒に缶ビールを買うことが自分たちのニーズだとは思っていなかったかもしれませんが確かにそのような行動をしていたのです。ビジネスアナリシスで顧客ニーズを発見するということは、この様な活動まで意味するようになったのです。</p>
<h3 align="left">エスノグラフィー：</h3>
<p align="left"> また、テクニック「観察」の延長として最近ではエスノグラフィーも注目されています。これは単なる観察ではなく、ビジネスアナリストがステークホルダーの業務またはその一部を実際にやってみて経験することにより、洞察をえて、改善点（すなわちニーズ）を発見し、要求として認めていこうという試みです。ステークホルダーは前任者から言われたままのことを長年当たり前のようにこなしていて、なぜ、どうして、その業務をする必要があるのか、何の疑問も持たないまま長期間にわたり業務を遂行していることがよくあります。ビジネスアナリストが自分でやってみるとその業務の大変さがよくわかりますし、第三者として別のやり方や改善について気が付くこともあります。これもステークホルダーの気が付かない（知らない）ニーズや要求の新しい引き出しの方法として注目されています。</p>
<h3 align="left">信頼感：</h3>
<p align="left"> 従来のインタビューやワークショップでもステークホルダーは自分では言いにくいことや、言いたくないこともあります。そのような場合にはテクニック以前に重要なことがあります。それはビジネスアナリストとして基礎的な知識、スキルや行動特性、すなわちコンピテンシーです。例えば、「信頼感」。おそらく基礎的ですが最も重要な行動特性です。知識やスキルではありません。行動が伴っていなければ何も意味がありませんのでBABOKでは「行動特性」と言います。信頼されていない限り有効な引き出し活動を行うことは難しいでしょう。信頼を得るためにはいくつかの要素があります。まずビジネスアナリストとしてふさわしくなければいけません。具体的には約束を守るとか、適切な身なり（服装）、ビジネスアナリストとしての態度や言葉遣いなどです。このふさわしさはいくらできていてもあまり大きな信頼にはつながらないかもしれませんが、逆に怠ると大きく信頼を失うことになりかねませんので要注意です。政治家の失脚の多くはこのふさわしさが問題になっていることが多いものです。いくら立派な業績のある人でもその人（政治家）としてふさわしくなければNGとなりますね。</p>
<p align="left">続いて、ビジネスアナリストとして能力が高いことが重要です。今までの業績がモノを言います。またPMPやCBAP等の公的な資格を有していることも役に立ちます。人は能力の高い人に信頼を寄せる傾向があります。ですから成功プロジェクトや特定業界での長年の経験、保有している資格を示すのが良いと思います。</p>
<p align="left">三番目として相手に共感してあげることも信頼を得ることに役に立ちます。相手の悩みなどに親身になって相談してあげるのもよいでしょう。ビジネスアナリストにとって共感力は基礎的ですが極めて重要です。この領域は女性が強みを発揮できる点です。毎年U.S.で開催されるビジネスアナリシスの世界最大のカンファレンスBBC（Building Business Capability）に参加すると、女性のビジネスアナリストが多いことに驚きます。参加者の60%以上が女性なので、どうも女性に向いた専門職かもしれません。また共感に近いものとして共通性があります。人は自分と共通なものを持っている人に親しみを感じます。例えば、出身、学校、言葉（特に海外）、価値観、そして趣味。趣味が共通な人には大変親しみやすく感じませんか。趣味には音楽、スポーツなどいろいろあると思います。何でも構いません、相手に共通するものが何かを探すことです。</p>
<p align="left">そして最後に、相手の役に立つことです。人は自分が困ったときに助けてくれた人のことを決して忘れることはありません。あなたの身の回りにいる人で、現在は別の人が担当しているにもかかわらず、お客様がその人（以前の担当者）に相談を持ち込むような人はいませんか。きっとその人は以前お客様が困っていたのを助けてあげたのではないでしょうか。現在は別に担当する人がいるにもかかわらず、以前助けてくれた人のことを忘れずに何かあると相談を持ち掛けたくなるのでしょうね。いかに信頼を寄せているかが分かります。この様に実際に助けて上げられればそれに越したことはないのですが、そこまでいかなくても、「あなたの役に立ちたい」という気持ちを伝えるだけでも信頼感が増します。</p>
<p align="left">このようにして信頼感を得ていれば、デリケートな案件の要求を引き出すことが可能になります。またステークホルダーが意思決定にビジネスアナリストの意見を聞くことにもなるでしょう。さらに、ビジネスアナリストが間違って問題が発生した時、ステークホルダーがビジネスアナリストを責めることはなく逆にかばってくれることにもなるのではないでしょうか。読者の皆様はステークホルダーから信頼されていますよね。</p>
<h3 align="left">傾聴：</h3>
<p align="left"> 信頼感にも関係しますが、傾聴のスキルも必要です。インタビューでは特にそうです。傾聴は英語ではアクティブ・リスニング（Active Listening）と言います。単に耳で聞くのではありません。積極的な行為です。あいづちを打ったり、アイコンタクト、ジェスチャを交えて、自分が相手に「あなたの言うことを聴いていますよ」ということをしっかりと伝えるのです。それが伝わって初めて双方向のコミュニケーションが成立します。必要に応じて言い返す（リピートとも言います）ことや、「なるほど」とか「そうですね」などの簡単な言葉を使うことで相手の発言をさらに促すことができます。インタビューなのに、要求を引き出す相手よりもビジネスアナリストの方が多くしゃべっていることのないようにしましょう。</p>
<h3 align="left"> 適応力：</h3>
<p align="left">相手のスタイルに合わせて自分のアプローチ方法を変える適応力も重要です。ステークホルダー（スポンサーも含めて）には様々なタイプの人がいます。適応力は、テクニックやスタイル、手法、アプローチを変える能力のことですが、すでに確立されたいくつかの方法があります。そのいくつかを紹介します。</p>
<ul>
<li>ソーシャルスタイル</li>
<li>DiSC理論</li>
<li>エゴグラム（交流分析理論）</li>
</ul>
<p align="left">　　など。</p>
<p align="left"> ソーシャルスタイルでは、人の言動を次の2つの軸で考えます。思考を開放する度合い（断言するのか、問いかけるのか）の軸と、感情を開放する度合い（感情を表すタイプか感情を出さないタイプか）の軸です。この2つの軸を組み合わせると、次の4つのタイプに分類されます。</p>
<ul>
<li>ドライバー（断言する傾向が強いが、感情は出さない）。ズバリと物事を明確に発言するタイプです。結果にこだわり、一人で決断します。</li>
<li>アナリティカル（思考も、感情も出さない）。途中のプロセスを重視し、データや事実の細部にこだわります。</li>
<li>エクスプレッシブ（思考も感情も出す）。賑やかで親分肌。周りを盛り上げるタイプです。</li>
<li>エミアブル（問いかけが多く、感情は出す）。温和な人。周りの意見を尊重し、一人では決断しません。調整役として最適です。</li>
</ul>
<p align="left">DiSC理論も似ています。D（Dominant支配性）、ｉ（Influence影響力）、S、C（Conciencous）の4つの強弱の度合いで人のタイプを分けます。</p>
<p align="left">エゴグラムは性格診断で、5つの心の領域（CP、NP、A、FC、AC）に分けて分析します。</p>
<ul>
<li>CP：支配的な親</li>
<li>NP：養育的な親</li>
<li>A：　合理的な大人</li>
<li>FC：　自由な子ども</li>
<li>AC：　従順な子ども</li>
</ul>
<p align="left">上記3種類に限るわけではありませんが、どれか一つの方法を身に着けることをお勧めします。相手のタイプを知り、自分のタイプも知ることが重要です。やりやすい組み合わせ、やりにくい組み合わせが分かれば、相手に対してのアプローチ方法を変えることができます。例えば、相手がエミアブルなら根回ししたほうが良いことがあります、ドライバーは自分で決断するタイプなので根回しはしない方が良いでしょう。</p>
<h3 align="left">ステークホルダー・エンゲージメント：</h3>
<p align="left">有効にニーズや要求を引き出せるようになるには常にステークホルダーの意識を高めておく必要があります。このことをステークホルダー・エンゲージメントと言います。　ビジネスアナリシス活動に進んで取り組もうとする自発的意思のことです。</p>
<p align="left">ステークホルダー・エンゲージメントが下がらないように次のようなリスクをアセスメントします。</p>
<ul>
<li>ステークホルダーが他の仕事に忙殺されていないか</li>
<li>求められる品質を提供しない引き出し活動になっていないか</li>
<li>せっかく引き出した要求の承認が遅れていないか</li>
</ul>
<p align="left">そして、ステークホルダー・エンゲージメントをうまく行い次のような状態にすることです。</p>
<p align="left">「自分の声が届いている、自分の意見が取り上げられている、自分の貢献が認められている」と関係しているステークホルダーのすべてが感じている状態。</p>
<p align="left">この「引き出し」活動を独立した知識エリアに格上げしたことがBABOKの最大の功績ではないでしょうか。当時（今から10数年前）は要件定義の一部でしかありませんでした。そしてステークホルダーが要件として黙って提供してくれるものとして扱う知識体系が殆どでした。　下記のリストはその一部です。</p>
<p align="left">PMBOK、CMMI、システムズエンジニアリング・ハンドブック（INCOSE）、SLCP/ISO、SLCP/JCF（共通フレーム2007）、SWEBOKなど。</p>
<p align="left">今でもいくつかの知識体系では要件定義が最上位フェーズになっているものがあります。</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=4714</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>初めてのビジネスアナリシス　（3）</title>
		<link>http://kbmanagement.biz/?p=4706</link>
		<comments>http://kbmanagement.biz/?p=4706#comments</comments>
		<pubDate>Sun, 29 Mar 2020 02:17:13 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®ガイドV3　情報]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=4706</guid>
		<description><![CDATA[第3章　プロジェクト開始前の活動 プロジェクト開始前の作業のアウトプットとしてビジネス・ケースがありますが、こ ...]]></description>
				<content:encoded><![CDATA[<h1>第3章　プロジェクト開始前の活動</h1>
<p align="left">プロジェクト開始前の作業のアウトプットとしてビジネス・ケースがありますが、これは日本ではあまり馴染みがないようです。近いものとして「稟議書」があります。書かれている内容はほとんど同じです。大きく異なるのは承認方法です。ビジネス・ケースの場合はスポンサー（エグゼクティブなど）が責任をもってサインしますが、日本の稟議書の場合は多くの役員などの押印による承認で、根回しが必要なことが多く、またかなり時間もかかります。</p>
<h3 align="left">プロジェクト ビジネス・ケース</h3>
<ul>
<li>プロジェクト ビジネス・ケースは、十分に定義されていな選択された構成要素のベネフィットの妥当性を確認するために用いられる経済的な実現可能性検討文書であり、以降のプロジェクトマネジメント活動を認可する判断する根拠となる。ビジネス・ケースはプロジェクトの立上げの目標および理由を記載したものである。（PMBOK<sup>®︎</sup>第6版）</li>
</ul>
<p align="left">ビジネスアナリストがビジネス・ケースを作成しない限りプロジェクトはスタートできないとも言えるものです。<br />
ここで大切なのはビジネス要求です。英語ではBusiness Requirementsですが、PMBOK（日本語版）ではビジネス要求事項と言い、BABOKではビジネス要求と言います。Requirement(s)を「要求」と訳すか、「要求事項」と訳すかでニュアンスが少し違うかもしれません。さらに日本では「要件」という用語もありますが、こちらも英語ではRequirementsです。「要求（事項）」と「要件」では何が違うのでしょうか。別途コラムで解説したいと思います。</p>
<p align="left">まずPMBOK(R)における「ビジネス要求事項」の定義をご覧ください。</p>
<h3 align="left">ビジネス要求事項：</h3>
<ul>
<li>ビジネス上の課題や好機のような組織全体のよりハイレベルのニーズ、およびプロジェクトが採用された理由を表す。（PMBOK<sup>®︎</sup>第6版）</li>
</ul>
<p align="left">お分かりのように、ビジネス・ケース作成において最も重要なのはビジネス要求を明確に定義することです。ところが、受注側のプロジェクト・マネジャーは意外と顧客案件のビジネス要求を知らないものです。例えば、弊社のビジネスアナリシス研修で参加者（この研修はPMの方が多く参加される研修です。）によく聞く質問です。</p>
<p align="left">読者の皆様もお考えください。</p>
<h4 align="left">「現在、あなたの参加しているプロジェクトの本当の目的（理由）を知っていますか？」</h4>
<p align="left">例えば、</p>
<ul>
<li>ビジネスの売上金額（増）</li>
<li>ビジネスの利益（増）</li>
<li>新製品・サービスの提供とそれによる売り上げ・利益など。</li>
</ul>
<p align="left">ユーザー企業の読者なら、当然ご存知の方が多いと思います。しかしシステムを構築する立場のシステム開発側のプロジェクト・マネジャーの場合、プロジェクトの品質（Quality）、コスト（Cost）、納期（Delivery）に関して責任があるので、コストは当然管理するためにもしっかり把握しているはずです。しかしプロジェクトの結果、顧客はビジネスでいくらの売り上げを増加しようとしているのか、ビジネスの利益をいくら増加しようとしているのか（それがビジネス要求です）など、までは把握していないことが多いようです。</p>
<p align="left">プロジェクトの現場ではどのようなことが起きているのでしょうか。研修の参加者による問題点とその影響です。</p>
<p align="left">　個人的な要求が出てくる　→　プロジェクト活動に影響が出る</p>
<p align="left">　ユーザー部門の要求が人によってずれている　→　ソリューションがあいまいなものになる。→　使えないシステム</p>
<p align="left">　ユーザーが日頃の仕事の改善案として要求を出してくる。→　その人のみが使う機能。他の人は使わない。</p>
<p align="left">　本来の目的と異なる要求が多く出る　→　コスト増、生産性ダウン、手戻り　→失敗PJ</p>
<p align="left">　不要なテストをしてしまう。→　コスト増、スケジュール遅延につながる。</p>
<p align="left">　ユーザーと会話が通じなくなる</p>
<p align="left">これではまともなシステム開発ができない現状がよくわかるような気がしますね。</p>
<p align="left">では、逆にシステムインテグレーターのプロジェクト・マネジャー（またはビジネスアナリスト）が顧客のビジネス要求を明確にできるようになるとどのようなメリットがあるのでしょうか。これも研修の参加者の意見です。メリットです。</p>
<p align="left">　プライオリティの高低が分かる→効率的に仕事ができる　→成功PJにつながる</p>
<p align="left">　ニーズに合った提案ができる→　ユーザー満足→　成功PJにつながる</p>
<p align="left">　責任感が芽生える　→　PJメンバーの士気向上　→　成功PJにつながる</p>
<p align="left">　ユーザー要求に対して経営目標に合致している議論できる→要件が明確で手戻り減る→予算内、スケジュール通り</p>
<p align="left">　より良い提案ができる　→　顧客ニーズの満足　→　顧客満足度/SIerの評価向上</p>
<p align="left">　ユーザーと会話が通じ、関係が良くなる→　次の案件につながる</p>
<p align="left">　プロジェクトに対して提案できる　→　不要なことをやらなくて済む</p>
<p align="left">　　　　　　　　　　　　　　　　　→　採用されるとやりがいにつながる</p>
<p align="left">　変更要求に対してスムーズに要否を具申できる</p>
<p align="left">　PMとして信頼される　→　お客様から信頼される、感謝される</p>
<p align="left">　　　　　　　　　　　　　→　次のビジネスチャンスの可能性が出てくる</p>
<p align="left">　　　　　　　　　　　　　→　昇格できるかも</p>
<p align="left">まるで雲泥の差が出ることが理解できますね。</p>
<p align="left">ビジネスアナリシスの知識があれば、顧客にビジネスの真のニーズに気づいてもらえるようになります。RFPには書いていないより重要なビジネス機会が得られるかもしれません、また、目の前の小さな課題を解決することが大きなコスト削減につながる可能性が明確になるかもしれません。</p>
<p align="left">RFPが常に正しい要求を書いてあるとは限らないのです。顧客のRFPが正しくないこともありうるという事に気づくことも重要です。ですからRFP通りにシステムを構築しても顧客満足につながらないこともあります。</p>
<p align="left"><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/03/狩野モデル_2020年3月23日.png"><img class="alignnone size-medium wp-image-4710" alt="狩野モデル_2020年3月23日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/03/狩野モデル_2020年3月23日-300x225.png" width="300" height="225" /></a></p>
<p align="left">
<p align="left">
<p align="left">上図は、有名な狩野モデルです。ビジネスアナリシスを実践することにより、RFPにかかれていない真のビジネス要求を明確にすることができると、その効果は計り知れません。顧客は自分たちの考えていた以上のビジネス成果が出せることがわかったり、自分たちの考えていたのと異なるやり方の方が、より低コストでビジネス・ニーズを満たせることがわかったりします。まさに、図の「喜びのニーズ（魅力的品質）」が実現することになります。その時のシステム開発会社のプロジェクト・マネジャー/ビジネスアナリストの立場はどうなるでしょうか。顧客からの信用が飛躍的に高まることになるでしょう。提案価格はもはや大きな問題ではありません。価格競争から脱却することが可能です。十分なマージンのある見積もりを提示することもができます。競合上の優位性が確立されます。などなど。</p>
<p align="left">日経コンピュータ誌で調査対象のシステム会社の場合はプロジェクトの本当の目的を把握していたのでしょうか。多くのプロジェクト・マネジャーはビジネス要求まで把握していなかったのではないいでしょうか。</p>
<p align="left">プロジェクト開始前のビジネスアナリシスの代表的な活動は以下の通りです。</p>
<ol>
<li>ビジネスの現状を分析して取り組むべきビジネス・ニーズ（問題または機会）を決める。<br />
そのビジネス・ニーズを明確にしたものを、ビジネス要求としてまとめる。<br />
そして現状を記述する。</li>
<li>ビジネス要求を満たした結果の将来状態におけるゴールと目標を定義する。<br />
そのゴールと目標を達成するためのソリューションの概要と潜在価値を定義し、それを含めた複数の将来状態を記述する。</li>
<li>現状から将来状態へのチェンジ（トランスフォーメーション）の概要を記述する。<br />
そのチェンジの過程の概略（それがチェンジ戦略）をビジネス・ケースとしてまとめる。</li>
<li>2の複数の将来状態の各々のリスクをアセスメントし、リスクを考慮しながら3を行う。</li>
</ol>
<p align="left">大事なことは１から４をほぼ同時に行うことです。決して順番通りに進むのではありません。行ったり来たりしながら、4つのタスクを実行します。また、一度実行したらそれっきりということでもありません。ビジネスの現状は時々刻々変化しています。特に最近のビジネス事情はVUCAの時代と言われています。VUCAとは次の用語の頭文字を取ったものです。</p>
<ul>
<li>　Volatile（変りやすい）</li>
<li>　Uncertain（不確かで）</li>
<li>　Complex（複雑な）</li>
<li>　Anbigous（あいまい）</li>
</ul>
<p align="left">すなわち、変りやすく、不確かで、複雑で、あいまいな状況を表した用語です。VUCAな状況のビジネス環境では、現状が常に変化していることになりますから、現状に変化を感じたら即、戦略を見直す必要すらあるわけです。</p>
<p align="left">
<p>&nbsp;</p>
<p align="left">
<p align="left">
<p align="left">
<p align="left">
<p align="left">
<p align="left">
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=4706</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>初めてのビジネスアナリシス　（2）</title>
		<link>http://kbmanagement.biz/?p=4701</link>
		<comments>http://kbmanagement.biz/?p=4701#comments</comments>
		<pubDate>Mon, 23 Mar 2020 02:03:22 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®ガイドV3　情報]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=4701</guid>
		<description><![CDATA[第2章　ビジネスアナリシスの3つの役割 プロジェクトにおけるビジネスアナリシスの役割は大きく次の3つがあります ...]]></description>
				<content:encoded><![CDATA[<h1>第2章　ビジネスアナリシスの3つの役割</h1>
<p align="left">プロジェクトにおけるビジネスアナリシスの役割は大きく次の3つがあります。</p>
<ol>
<li>プロジェクト開始前の活動として、プロジェクト発足の理由や根拠を明確にします。</li>
<li>プロジェクト中においては要求の作成と管理、すなわち要件定義を行います。</li>
<li>プロジェクト終了後にソリューションの価値を評価し改善策を作成します。</li>
</ol>
<p><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/03/PMとBAの関係_2020年3月23日.png"><img class="alignnone size-medium wp-image-4700" alt="PMとBAの関係_2020年3月23日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2020/03/PMとBAの関係_2020年3月23日-300x225.png" width="300" height="225" /></a></p>
<p align="left">プロジェクトマネジメントとビジネスアナリシスの関係を1枚の絵で示したものです。グリーンがプロジェクトマネジメント、ピンク色がビジネスアナリシスです。<br />
まず、ビジネスアナリシスはビジネス要求を定義し、それをビジネス・ケースというドキュメントにまとめ、プロジェクトマネジメント側に渡します。プロジェクト側はそのビジネス・ケースを基にプロジェクト憲章を作成し、プロジェクトがスタートします。具体的にはPMBOKの「プロジェクト憲章作成」というプロセスへのインプットがビジネス・ケースであり、その作成責任者がビジネスアナリストです。プロジェクト中においては各ステークホルダーの意見を聞きながら要求をまとめていきます（要するに要件定義です）。プロジェクトではビジネスアナリストがまとめた要求に基づきプロダクト（最終成果物）を構築し、納入します。そしてビジネスアナリストは納入後、稼働しているプロダクト（ソリューション）の価値を測定し、ビジネス価値が達成されているかを評価し、改善策を提案します。</p>
<p align="left">すなわち、プロジェクト開始前の活動としては、ビジネス全体の課題を洗い出し、その中から最も重要なものを定めビジネス要求として定義し、その要求を満足するソリューションの概要を定義し、ドキュメントとしてビジネス・ケースを作成することです。そのビジネス・ケースを基にプロジェクト憲章が作成され、プロジェクトが正式に発足することになります。このフェーズでの最終成果物はビジネス・ケースです。このビジネス・ケースがない限りプロジェクトは開始できないという関係がありますので、プロジェクトにとってはビジネスアナリシスの活動が極めて重要ということになります。</p>
<p align="left"> プロジェクトが開始されると、ビジネスアナリシスの活動は要件定義をすることですが、そう容易なことではありません。まず、ステークホルダーの要求を引き出すことが重要です。単なるヒアリングで必要な要求が出てくるわけではありませんので高度なテクニックを使用する必要があります。ついでデータフロー図、UML、ER図などの複数のモデリング・テクニックを用いて要求を精緻化してステークホルダー要求、ソリューション要求と詳細度を高めていきますが、要求を検証したり、要求の妥当性を確認したりする必要もありますし、要求の優先順位も考慮しなくてはいけません。さらに要求を管理することも忘れてはいけません。具体的にはトレーサビリティを確立したり、要求を適切に維持したりするためには適切なリポジトリを準備してそこに要求を保存します。要求の変更を管理しながら最終的には要求を承認してもらい、それを関係者に伝えていく事が求められます。</p>
<p align="left">そしてプロジェクト・マネジャー率いるチームによりプロダクト（またはソリューション）が設計、構築、テストされていきます。このプロダクトの実装とデリバリーを統括するのがプロジェクト・マネジャーです。すなわち、プロジェクト・マネジャーとビジネスアナリストはタッグを組んで仕事をしていくことになります。おそらくこの図がプロジェクトマネジメントとビジネスアナリシスの関係を最もシンプルに表現している絵ではないかと思います。</p>
<p align="left"> 無事にプロダクト（またはソリューション）が納品されると、プロジェクト・チームは解散しますが、ビジネスアナリシスの活動はまだ続きます。本当にビジネス成果を出しているのか検証するのもビジネスアナリシスの重要な仕事です。</p>
<p align="left">プロダクト作成の責任者であるプロジェクト・マネジャーはプロダクトが納品されるとプロジェクトの終結とともに役割が終わります。QCDの責任は持っていますが、プロダクトのビジネス的な価値については何も責任ありません（変ですが現実です？）。そこで本当に実装されたソリューションはビジネス価値を発揮しいているのだろうか。もし発揮していないとすればその原因は何で、何を改善すればソリューションの価値が向上できるのかを見定めなければいけません。そのためには多くの活動が必要です。また、長年ソリューションが使用されていれば、耐用年数などからソリューションのリプレースも考慮しなければいけないかもしれません。これらもビジネスアナリストの重要な仕事です。</p>
<p align="left"> この様に、ビジネスアナリシスはプロジェクト活動の中だけでなく、プロジェクトの開始前、プロジェクトの最中、そしてプロジェクト終結後にも多くの活動をする必要があるのです。そのため、ビジネスアナリシスの活動をプロジェクトとは言わずにイニシアチブということが多いのです。プロジェクトの場合明確なスタートと終結がありますが、ビジネスアナリシス活動はプロジェクトの開始前から始まり、プロジェクトが終結した後も続くからです。</p>
<p align="left"> 以下の章において、上記3つの役割、すなわちプロジェクト開始前、プロジェクトの最中、そしてプロジェクト終結後の活動について具体的に解説していきます。</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=4701</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>よくわかるビジネスアナリシス　Kindle版　出版</title>
		<link>http://kbmanagement.biz/?p=4375</link>
		<comments>http://kbmanagement.biz/?p=4375#comments</comments>
		<pubDate>Sun, 11 Aug 2019 07:32:33 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®ガイドV3　情報]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=4375</guid>
		<description><![CDATA[IIBA日本支部　が下記　書籍を出版いたしましたのでお知らせいたします。 よくわかるビジネスアナリシス：　BA ...]]></description>
				<content:encoded><![CDATA[<p>IIBA日本支部　が下記　書籍を出版いたしましたのでお知らせいたします。</p>
<h1>よくわかるビジネスアナリシス：　<em>BABOK®</em>の心</h1>
<ul>
<li>形式：　　　キンドル出版</li>
<li>価格：　　　1,000円</li>
</ul>
<p><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2019/08/200+250.jpg"><img class="alignnone size-full wp-image-4376" alt="200+250" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2019/08/200+250.jpg" width="200" height="250" /></a><a title="アマゾンサイト" href="https://www.amazon.co.jp/よくわかるビジネスアナリシス-BABOK®の心-IIBA日本支部-BABOK研究会-ebook/dp/B07W5L4LB5/ref=sr_1_1?__mk_ja_JP=カタカナ&amp;keywords=よくわかるビジネスアナリシス&amp;qid=1565487125&amp;s=books&amp;sr=1-1" target="_blank">アマゾンサイトにリンク</a></p>
<h2>書籍の紹介</h2>
<h3 style="text-align: left;">はじめに</h3>
<p>昨今のIT業界では、デジタル・トランスフォーメーション（DX）が話題にならない日はないくらいにメディアを賑わせている。DXとは、デジタル技術の活用によって企業のビジネスを変革し、デジタル時代に勝ち残れるよう自社の競争力を強化することだ。日本ではすぐ短絡的にAI、IoTなどのテクノロジーを使えばDXが実現できると思いこんでいるふしが見受けられる。そのため、POC（概念実証）が華やかな打ち上げ花火のごとく行われているが、実際のビジネス変革には繋がっていないというのが多くの企業の現状である。挙句の果て「POC貧乏」なる言葉まで出始めているありさまである。このままではGAFA（Google,Apple,Facebook,Amazon）のようなディスラプターに破壊されることに手をこまねいて待っていることにならないだろうか。</p>
<p>経済産業省は2018年9月に「DXレポート「2025年の崖」の克服とDXの本格的な展開」を発表し、日本企業はレガシーに代表されるITシステムの刷新を早期に実現し、速やかにDXに取り組まないと2025年までに12兆円の経済損失が発生する、と警告を発している。よくよく考えてみると上記のPOC止まりのDXは、本来の目的であるビジネス戦略が不明確なまま手段のデジタル・トランスフォーメーション（DX）を進めていることではないだろうか。DX、すなわち、デジタル技術の活用によって企業のビジネスを変革し、デジタル時代に勝ち残れるよう自社の競争力を強化するためには、その目的であるビジネス戦略を明確にすることが不可欠である。それなくして手段であるDXを進めようとしても無理があると言わざるを得ない。</p>
<p>もうひとつDXに必要なのはトランスフォーメーション（変革もしくは変容）である。いくらデジタル技術を活用して新たなサービス（顧客体験）を提供しようとしてもそれを顧客がそれを利用しない限り価値ある体験に結びつかない。そのためには顧客にトランスフォームしてもらうことが不可欠となる。顧客は新しいサービスを使って（使うことがチェンジ）初めて価値を得ることができる。また、それによりサービスを提供する企業側にも価値が発生することになるのでこのチェンジは極めて重要である。プロダクトやサービスを作ればそれでおしまいということでは決してない。顧客にいかにすれば使ってもらえるかまで考えなければならない。それもトランスフォーメーションの一部である。</p>
<p>さらに、デジタル技術で新しいサービスを提供する企業自身も外部エコシステム（社会の変化）の変化に迅速に対応できること、すなわちビジネスのアジリティを高めておかなければならない。そのためには、組織構造・組織文化（人のスキルを含む）、意思決定、能力・プロセス、ポリシー、内部資産（情報資産含む）などが柔軟に対応できるようにトランスフォーム（変革・変容）しなければいけない。それが、ビジネスアジリティに通じる。企業側がトランスフォームするためにはデジタルビジネスに対応できるようにアジリティを高めておかなければならないわけである。</p>
<p>例えば、POCでダイナミック・プライシングが有効だと分かったとしよう。プラチナレベル、ゴールドレベルの優良顧客には有利な価格を提供したい。飛行機代金なら、早割、学割、など。小売りなら、昼間の価格、夕方混雑時の価格、閉店間際の特別価格など。量販店なら地域最安値を提供したいなど、ダイナミックに価格を決定することがビジネスに重要な意味を持つ例は多い。POCでそのようなダイナミック・プライシングの実証ができ、いざ本格的に運用しようとしても、肝心の基幹系の請求システムが「一物一価」にしか対応していなかったら、それこそ絵に描いた餅にしかならない。「一物一価」は極端にしても、基幹系がダイナミック・プライシングに対応するためには、ITシステムのデータベース構造（情報資産）のみならず、仕入れの仕組み（ビジネスプロセスやビジネスルール）、組織構造や組織文化（人のスキルも含めて）もそれなりに対応しなくてならないだろう。これらはPOCで小さなDXが実証できたとしても企業レベルでDXを成功させるためにはまだまだ多くのハードル（それもPOCとは比べ物にならないくらい高いハードル）を越えなければならないことを意味している。</p>
<p>本書籍はビジネスアナリシスの知識体系（BABOK® ガイド）の解説本である。ビジネスアナリシスとは、「ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動」である。ここで言うチェンジは、「ニーズに対応して変える行為」と定義されているが、実は原文は「The act of Transformation in response to a need.」すなわち「ニーズに対応するトランスフォーメーションの行為」である。４年前にBABOK® ガイドを日本語化する作業の中で、トランスフォーメーション（変革、変容）はあまりにも大げさなので、言葉を和らげて「変える行為」にしてしまったが、今のDXブームのことまで先を読めなかったのは残念と言わざるを得ない。言い方を変えると、顧客の知らない（まだ気づいていない）ニーズを定義し、価値ある顧客体験を提供することにより企業にDX（デジタル・トランスフォーメーション）を可能にする専門活動である。端的に言えばDX実現のために不可欠な知識体系と言える。</p>
<p>BABOK® ガイド v3　を具体的事例に即して解説しようと試みて、第2章は実在のプロジェクトの事例として「A社事例」を取り上げた。各知識エリアのタスクを「A社事例」に即した解説を試みている。DXほど大規模ではないが、ビジネスアナリシスをわかりやすく解説しようとしている。読者の理解の一助になれば幸いである。また、本書の随所に「心」と題するコラムが挿入されている。この「心」がBABOK® の神髄でありスピリットと言える。表面的にはわかりずらいがDX実現のためには不可欠な部分である。デジタル・トランスフォーメーション（DX）の基盤となる知識体系をお楽しみいただけると幸いである。</p>
<p>最後に、本書はIIBA日本支部のBABOK® 研究会メンバーによる執筆である。BABOK® ガイドV3出版当時からの研究成果としてまとめたものでもある。</p>
<p style="text-align: right;">2019年7月吉日<br />
IIBA日本支部<br />
BABOK® 担当理事<br />
清水　千博</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=4375</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>デジタル・ビジネスアナリシス（2）</title>
		<link>http://kbmanagement.biz/?p=4263</link>
		<comments>http://kbmanagement.biz/?p=4263#comments</comments>
		<pubDate>Sun, 03 Feb 2019 05:24:03 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®ガイドV3　情報]]></category>
		<category><![CDATA[未分類]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=4263</guid>
		<description><![CDATA[デジタル・ビジネスアナリシス（2） 先週に引き続き、IIBA発行の キャズムを超えて：　デジタル・ビジネスアナ ...]]></description>
				<content:encoded><![CDATA[<h1>デジタル・ビジネスアナリシス（2）</h1>
<p>先週に引き続き、IIBA発行の</p>
<p>キャズムを超えて：　デジタル・ビジネスアナリシス　です。</p>
<p><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2019/02/デジタルBA_Slide2_2019年1月27日.png"><img class="alignnone size-medium wp-image-4275" alt="デジタルBA_Slide2_2019年1月27日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2019/02/デジタルBA_Slide2_2019年1月27日-300x225.png" width="300" height="225" /></a></p>
<p>今週はベストプラクティスの概要を示します。</p>
<ol>
<li>戦略的課題を理解する</li>
<li>真の顧客に共感する</li>
<li>ビジネスプロセスを再考する</li>
<li>アジリティに対応する</li>
<li>継続的にステークホルダーと協働する</li>
<li>エビデンス・ベースの意思決定を推進する</li>
<li>テクノロジーを理解する</li>
</ol>
<p>具体的な内容を簡単に紹介します。</p>
<h2>１．戦略的課題を理解する</h2>
<p>簡単に言えば、戦略的な課題は全体像であり、「What」の背後にある「Why」です。すなわち解決されるべき本当の問題です。</p>
<p>ビジネスアナリストとして、戦略的課題を理解することは、BABOK®ガイドが現状と将来の状態を雄弁に表現していることを徹底的に知ることになります。 現状理解は、エンタープライズが現在どのように機能しているのか、その課題は何であるのか、そしてこれらの課題を克服するために何をする必要があるのかを知ることに関連しています。現状の理解はベースラインとチェンジの背景、将来状態はビジネスニーズが満たされたときにビジネスがどのように見えるかを定義します。 これは基本的なことです。 デジタルの世界をエキサイティングにするのは、「顧客」と彼らが今日期待する経験に焦点を合わせることです。そのため、組織のデジタル戦略とイニシアチブでは、顧客に重点を置くことになります。</p>
<p>戦略的課題は、ビジネスアナリストの活動だけでなく、組織のすべての活動を導く必要があります。 BABOK®ガイドには、ビジネスアナリストが戦略的課題を理解できるようにするための実用的なテクニックがいくつか記載されています。</p>
<ul>
<li>バランススコアカードは戦略的立案と管理のツールです。</li>
<li>ビジネス能力分析は、ビジネスアナリストがエンタープライズのビジネスゴールや目標を達成するのに役立つ能力を記述するのに役立つ手法です。</li>
<li>ビジネスケースは、ビジネスアナリストがチェンジを実行するための論拠または戦略的意図を理解するのに役立ちます。</li>
<li>ビジネスモデル・キャンバスは、エンタープライズが顧客に対してどのように価値を創造、提供、獲得するかを説明します。</li>
<li>SWOT分析は、内部の長所・短所、外部の機会・脅威を評価することによって、エンタープライズの全体的な状態を特定するのに役立つ</li>
</ul>
<p>&nbsp;</p>
<h2>2.　真の顧客に共感する</h2>
<p>優れた顧客体験を約束するビジネスモデルは、そのビジネスがお客様に確実に共感を持っている場合にのみ可能です。<br />
Zipcarは、顧客が毎時レンタルを必要としていることをどのようにして分かったのでしょうか？ 特にタクシーがいたるところにあるとき、Uberはどのようにして顧客へのチャレンジがタクシーを降ろすことにあると気付いたのでしょうか？</p>
<p>Netflixは、顧客はコンテンツが直接デバイスにストリーミング配信されるオンデマンドの経験を必要としていることをどのように認識できたのでしょうか。答えは共感です。　彼らは顧客に対して本当に共感できたのです。</p>
<h3>「デジタル環境では、最も重要なステークホルダーは顧客、つまりお金を払う人である。」</h3>
<p>当然のことながら、共感はデザイン思考の基盤のひとつです。 論文の中で、Fulmer氏は次のように述べています。 「ビジネスアナリシスは「アウトサイド・イン」思考を要求していた。伝統的なビジネスプロセスや情報ベースのアプローチでは、BAが行う仕事は内部ビジネスを支援することでした。BAに直接関与するステークホルダーは、ビジネスの内部に属するすべての人々でした。ステークホルダーは、ビジネス上の問題を理解するために彼らのニーズを識別し、ついで[ビジネスアナリストは]要求を定義し、解決策を評価していました。」</p>
<p>Fulmer氏は続けて次のように述べています。「デジタル環境では、最も重要なステークホルダーは顧客、つまりお金を払う人です。 そして、この道を歩んでいる他の多くのステークホルダーは、外部のパートナー、ベンダー、そしてプロバイダーです。 この視点の変化と、それらすべてが顧客体験の一部として結び付けるやり方が、デジタルの核心です。」</p>
<p>「ビジネスアナリストは、現在、ビジネスプロセスマッピング、それらのプロセスの分析、および新しいソリューションを確立するために必要なプロセスおよびシステム（情報システムを含む）の改善に関する推奨事項の作成に慣れています。 デジタルの世界では、BAは顧客のペルソナ、共感マップ、エコシステム・マップ、カスタマー・ジャーニー・マップを作成することを期待されます。 [将来のビジネスアナリシス]は、顧客体験の観点を十分に取り入れ、この形式のビジネスアナリシスをサポートするための新しいツールとテクニックに適応していきます。」</p>
<p>ビジネスアナリシスはますますコラボレーションが重要になってきます。 それは、顧客体験のデザイン・プロセスの一環として、顧客、パートナー、および従業員と関与することです。よりシームレスな顧客体験を提供するための、背後のサービスコンポーネントであるデジタルネットワークからなるソリューションは通常、より複雑になっています。<br />
さらに、それは望ましい顧客体験のために使用される単一つの技術ではありません、それは一連の技術です。 AI、機械学習、アナリティクス、IoTなどを組み合わせることで、重要な顧客ニーズを満たすだけでなく、いくつかの重要な問題を解決し、顧客を喜ばせる顧客体験を提供していきます。</p>
<p>「顧客体験の分析が非常に重要になるにつれて、ビジネスアナリストが顧客中心のインプットを「引き出す」方法も重要になっています。 私たちは、プロダクトやサービスに関する彼らの体験について、顧客からのフィードバックを積極的に求める必要があります。 多くのエンタープライズもまたこれには、電子メールや顧客サービスへの問い合わせ、ソーシャルメディアの投稿で証明されているように、顧客からのより間接的なフィードバックを調べることも含まれます」とFulmer氏は述べています。</p>
<p>実際の顧客と共感することは、顧客が口に出さないニーズを知るために極めて重要です。 共感は単に「本当の顧客」を発見し、ワークショップで彼らのニーズを引き出すことではありません。 共感は、顧客がビジネスとやり取りするときに顧客の本当の感情に触れながら、顧客が感じていることを感じることです。 そうして初めて、たとえ外面的に顧客が言葉や非言語で自分のニーズを表さなくても、顧客の真のニーズを知ることができるようになります。</p>
<p>相互の関係に共感を注ぎ込むことは、引き出しをまったく新しいレベルのものにします。 顧客の真のニーズを知ることで、ビジネスプロセスを再考する可能性が生まれ、それが今度は想像力に富んだ優れた顧客体験につながります。 この新しいレベルの引き出しは、デジタル世界でビジネスアナリストが活動する必要がある場所です。</p>
<p>&nbsp;</p>
<h2>3.　ビジネスプロセスを再考する</h2>
<p>ビジネスプロセスの漸進的な（画期的ではない）改善は、既存のエコシステムの効率を高めることがあるかもしれません。再考されたビジネスプロセスの場合は市場を破壊し、新しいエコシステムを創出し、それを全く新しいレベルに高めてその新しい状態でバランスさせます。</p>
<p>Zipcarが、顧客が車を借りるために列に並んでいる間の待ち時間を減らすことだけを求めた場合はどうなるでしょうか？ 彼らはおそらくもう少し効率的で、わずかに改善されたビジネスプロセスを考案したでしょう。しかし実際にはZipcarは顧客体験の異なる分野を目指し、レンタカービジネスモデルを再考し、完全にビジネスプロセスを再発明し、レンタカー業界に新たな標準を設定しようとしたのです。</p>
<p>Netflixは簡単にテレビチャンネルやネットワーク、あるいは制作会社を始めたかもしれませんが、それでも今日提供しているすべてのことができるようになるでしょう。 しかし、それは漸進的なものにすぎません。 市場のすべての人にとってゲームが変わるわけではありません。 その代わりに、Netflixは自分たちに質問をしました。「高品質のコンテンツをオンデマンドで直接消費者に提供し、最高品質の広告なしの体験を提供するにはどうすればよいか」と。<br />
Netflixは、従来のテレビネットワークとハリウッドのエコシステムを破壊することなく、エンターテイメントを提供するための新しいコンジットを作成しました。</p>
<p>将来のBAは、これらの大胆な質問を自分たちに投げかけて、ビジネスプロセスを再発明し、市場を混乱させることになると予想されます。 デジタル・ビジネスプロセスは、期待される顧客体験を提供するために考慮する必要があるだけでなく、このプロセスが顧客によって実行される方法も考慮する必要があります。 今日、ほとんどの顧客向けプロセスはモバイルデバイス上で実行されているため、このデジタル・ビジネスプロセスが実行される方法について、表向きのみならずその背景でも新しい考え方を必要としています。</p>
<p>ビジネスプロセスを再考することは本質的に可能性を想像するための創造性の練習ですが、BABOK®ガイドはそのような想像に構造を提供する特定のテクニックを収録しています。それは「プロセス分析」と「プロセスモデリング」です。</p>
<p>&nbsp;</p>
<h2> 4.　アジリティに対応する</h2>
<p>今日のデジタル世界のすべての企業は、アジャイルのマインドセットを必要としています。 この宇宙を創造している間、自然界でさえアジャイルのマインドセットを採用したと人は言うかもしれません。 進化はその証拠です。アジャイル思考は自然なことです。 アジャイル思考の基本原則に反するアプローチはありません。</p>
<p>アジリティはアジャイルソフトウェア開発のことを言うのではありません。 スクラム（SCRUM）やXPについては言及しません。 私たちはビジネスアジリティを感情、マインドセット、考え方として言及しています。 BABOK®ガイドのアジャイル拡張版は、アジャイルな考え方の目標を「最小限の入力で結果（提供される価値）を最大化するために」「より少ないことと正しいことを、正しく行う」と明確に表現しています。</p>
<p>アジリティの主な側面は次のとおりです。</p>
<ul>
<li>迅速かつ一貫して価値を提供する</li>
<li>勇気を持って協力する</li>
<li>学ぶために繰り返す</li>
<li>無駄を避けるために簡素化する</li>
<li>コンテキストを考慮し、現実に適応する</li>
<li>フィードバックを反映し、プロダクトとプロセスの両方を適応させる</li>
<li>最高品質のプロダクトを生産する</li>
</ul>
<p>デジタル世界でのイニシアチブは明確な始まりはありますが、明確な終わりはありません。 イニシアチブは永続的かつ継続的です。 たとえば、Google検索には、定義されたバージョン番号（少なくともユーザーに表示されるもの）はありませんし、目に見えるプロダクト開発の終着点もありません。</p>
<p>アジャイル思考では、ビジネスアナリストはプロジェクトではなくプロダクトのコンセプトを開発する必要があります。 ビジネスアナリストは、すべての成果物に対して最小実現可能プロダクト（MVP）アプローチを採用する必要があります。 MVPには、プロダクトを顧客に提供し、フィードバックを求め、そのフィードバックからの学習を加速し、それをプロダクトとして次のMVPレベルに向上させるための基盤として使用するのに十分なコア機能があります。 同様に、このMVPアプローチは、プロダクトだけでなく、あらゆる活動や成果物に簡単に適用できます。 MVPアプローチは、ビジネスアナリストがかなりの進捗を示し、フィードバックを求め、学習を引き出し、成果物を改善して次のMVPレベルに引き上げるのに役立ちます。</p>
<p>アジリティは、ステークホルダーとの協働に絶えず焦点を当て、継続的にステークホルダーからのフィードバックを求め、価値ある結果を提供しながら、真実を保ち、全体像または戦略的意図に適合することに重点を置くマインドセットです。 定期的な間隔で、間違いを早期かつ迅速に認識し、新たな情報に迅速に適応します。</p>
<p>IIBAのBABOK®ガイドのアジャイル拡張版、バージョン2は、ビジネスアナリストがアジャイルのマインドセット、思考、ツール、およびテクニックをデジタル化して成功させるための最良のガイドです。</p>
<p>&nbsp;</p>
<h2>5.　継続的なステークホルダーとのコラボレーション</h2>
<p>アジャイル思考は継続的なステークホルダーの関与（エンゲージメント）を必要とします。 「エンゲージメント」という用語はコラボレーションを意味します。つまり、ステークホルダーはビジネスアナリストとしてのあなたの活動において積極的な役割を果たします。</p>
<p>今、デジタル世界におけるステークホルダーのリストは、伝統的な世界よりも少し長く複雑になっています。 ビジネスアナリストは、日常生活の中で常に内部および外部のステークホルダーと関係を持ちます。 デジタル世界では、従来のステークホルダー・マネジメントの範囲を超えています。</p>
<ul>
<li>デジタル世界で鍵となるのは、ステークホルダーとのより深く継続的な関わり合いをもつことであり、そのためステークホルダーは文書に署名する偉い人というよりは一緒に旅（ジャーニー）をする人であると考えられます。 ステークホルダーとの継続的なエンゲージメントを確立することの絶対必要条件は、より新しくより関連性のあるステークホルダーがイニシアチブの間中いつでも表面化するかもしれないということです。 したがって、ビジネスアナリストは新しいステークホルダーを歓迎するだけではなく、常に彼らを発見することに積極的にならなければいけません。</li>
<li>そして、開発を進めているもう1組のステークホルダー、「デジタル・ステークホルダー」があります。Facebook、Twitter、WhatsAppなどを使っている人間を指すのではありません。時間とともに進化するインテリジェントな「デジタル」システムのことを言います。「人間のような」体験を提供するために開発されている「インテリジェント」システムについて言います。 このようなシステム間のやり取りは、メッセージフォーマットやデータファイルの交換ほど単純ではありません。 そのようなデジタルシステムの相互作用は、より大きな価値と望ましい顧客体験を提供するための情報交換を含むでしょう。 したがって、ビジネスアナリストは常に以下のことに注意する必要があります。　それがIT風景（ランドスケープ）です。</li>
</ul>
<p>継続的なステークホルダー・エンゲージメントは大変な作業です。 それはビジネスアナリストが彼らの意図を引き出しとコラボレーションで明確にすることを必要とします。 ビジネスアナリストは（プロジェクトとは対照的に）プロダクトの概念を開発する必要があることを考慮すると、「プロダクト・オーナー」のペルソナを採用する必要があります。 ビジネスアナリストはプロダクトのステークホルダーとの間で主導的な協働作業者です。 デジタル世界におけるビジネスアナリストの役割は、ビジネス成果とその成果を達成するためのプロダクトに対する説明責任者です。 BABOK®ガイドは、ステークホルダー・エンゲージメントのためのベストプラクティスを学び、内面化するための最良のガイドです。</p>
<p>&nbsp;</p>
<h2>6.　エビデンス・ベースの意思決定を推進する</h2>
<p>期待される顧客体験を提供するためにデジタル世界における新しいビジネスモデル/プロセスを考察しながら、エビデンスを評価し分析することが重要です。 これには、正しい意思決定をするために活用できるデータを見つける必要があります。 このようなデータは、調査や動向、業界団体、再考されているビジネスプロセスの履歴データなど、さまざまなソースから取得されます。 問題は、ビジネスアナリスト・コミュニティーが洞察を推進したり、仮説を立証したり、意思決定をするためのデータが利用できない、またはデータが正しい形式になっていない、さらにそもそもデータの形になっていない可能性があることです。 しかし、正しいエビデンスが得られれば、実際の顧客の真の問題点を明確にし、戦略的な課題を改善し、ビジネスプロセスを再考し、そして正確な顧客の問題を解決するソリューションを提供することができます。</p>
<p>大手小売チェーンの1つであるTargetは、彼らのクーポンビジネスにおいて、ROIが低いという問題がありました。顧客から収集したフィードバックを分析したところ、Targetは顧客がクーポンをゴミとしか見ていないことがわかりました。 隔週毎にすべての顧客が同じようなクーポンを受け取っていたのです。そしてそのクーポンは店の入り口でも入手可能であったため、クーポンは顧客にとって価値がなさそうなことがわかりました。</p>
<p>この謎を解くために、Targetは、所有しているペタバイト単位の売上データを分析することにしました。その結果、顧客のためにクーポンをパーソナライズする方法を考え出しました。 彼らは、顧客がある種類の製品を連続して購入すると、次回の購入時に特定の製品を購入することを販売データから学びました。 ターゲットは彼らにその製品のクーポンを大きなサプライズとして送ったのです。</p>
<p>さて、デジタルの世界で自分自身のことを考えてみましょう。優れた顧客体験を提供するためにビジネスプロセスを再考する際に、データを見て収集したエビデンスが望ましい結果を達成する可能性を大いに高めます。</p>
<p>そのため、デジタルの世界のビジネスアナリストは次の能力を保持する必要があります。</p>
<ul>
<li>必要なデータを理解する。</li>
<li>それを集めることができる、</li>
<li>効果的に整理して分析することができる。</li>
</ul>
<p>データは、顧客に提供しようとしている価値を高めたり、壊したりする可能性がある信頼できる唯一の情報源（a single source of truth）となる可能性があります。データ分析、アナリティクス、統計、シックスシグマ、情報アーキテクチャの卓越したスキルと能力を持てば、ビジネスアナリシス・コミュニティがデジタル世界で成功するのに役立ちます。</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=4263</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>デジタル・ビジネスアナリシス（1）</title>
		<link>http://kbmanagement.biz/?p=4254</link>
		<comments>http://kbmanagement.biz/?p=4254#comments</comments>
		<pubDate>Sun, 27 Jan 2019 14:10:11 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[BABOK®ガイドV3　情報]]></category>

		<guid isPermaLink="false">http://kbmanagement.biz/?p=4254</guid>
		<description><![CDATA[キャズムを超えて：　デジタル世界へ　（前編） IIBA発行の IIBA GLOBAL THOUGHT LEAD ...]]></description>
				<content:encoded><![CDATA[<h1>キャズムを超えて：　デジタル世界へ　（前編）</h1>
<p>IIBA発行の IIBA GLOBAL THOUGHT LEADERSHIP SERIES　の要約です。</p>
<p>IIBAによるデジタル（ビジネス）の定義は次のとおりです。</p>
<h3>デジタルは、顧客中心の真新しいビジネスモデルを創出し、テクノロジーによって画期的な顧客体験を可能にするプロセスを創出すること。</h3>
<p>ですから、顧客体験とテクノロジーが極めて重要です。</p>
<p><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2019/01/デジタルBA_Slide1_2019年1月27日.png"><img class="alignnone size-medium wp-image-4255" alt="デジタルBA_Slide1_2019年1月27日" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2019/01/デジタルBA_Slide1_2019年1月27日-300x225.png" width="300" height="225" /></a></p>
<p>&nbsp;</p>
<h2>エグゼクティブ・サマリー：The future is Now. Now is Digital.</h2>
<p>一般的な認識とは異なり、デジタルはテクノロジーだけを意味するものではありません。 デジタルは、伝統的なビジネスモデルを破壊し関心の中心のビジネスを置き換えてしまうことを意味します。 デジタルは、顧客を関心の中心に置き、テクノロジーによる画期的な顧客体験を提供するプロセスを創造することによって、真新しいビジネスモデルを創造することを意味します。 デジタルの世界では、ビジネスとテクノロジーの間のギャップがぼやけています。 テクノロジーは、エンタープライズがより良い価値提案を顧客に提供できるようにすることで、デジタルの世界でビジネスを推進します。</p>
<p>気がかりなのは、デジタル戦略がビジネス戦略の鍵となる世界において、ビジネスアナリシスが引き続き妥当性があるかどうかです。 もし妥当性があるなら、ビジネスアナリストがデジタルの世界で成功を収めるのに役立つビジネスアナリシスの「新しい標準」は何でしょうか。</p>
<h2>ビジネスアナリシスのための「新しい標準」</h2>
<ul>
<li> ビジネスアナリシスの中核は、デジタルの世界でも変わりません。 BABOK®ガイドに記載されている知識エリア、タスク、コンピテンシーは引き続き妥当性を維持し、実際は、デジタルの世界ではさらに重要になります。</li>
<li>デジタルの世界では、ビジネス全般および具体的にはビジネスアナリストがアジャイルな考え方を採用することが期待されます。 これには、ビジネスアナリストがプロジェクトではなくプロダクトのコンセプトを開発する必要があります。 ビジネスアナリストは、MVP（Minimum Viable Product）アプローチを採用する必要があります。</li>
<li>ベストプラクティスのいくつかは、従来のビジネスアナリシスの世界では適用されなかったとしても問題なかったものですが、デジタルの世界ではビジネスアナリストのためのベースライン・プラクティスになるでしょう。それは戦略的思考、顧客中心主義、共感、デザイン思考、アジリティ、テクノロジー、そして継続的なステークホルダー・エンゲージメントです。現在のデジタルの世界ではそれらなくしてはビジネスアナリストが決して成功することができないほどの基本的なベストプラクティスです。</li>
<li>ビジネスプロセスは、デジタルの世界で決定的な役割を果たすでしょう。伝統的な世界では、ビジネスプロセスはビジネスのステークホルダーを中心としていました（インサイドアウトのビュー）。 デジタルの世界では、ビジネスの顧客を中心としています（アウトサイドインのビュー）。 従来のビジネスアナリシスの世界では、ビジネスプロセスを自動化するために、ビジネスプロセスの段階的な変更が要求されました。 デジタルの世界では、卓越した顧客体験を提供するという意図でビジネスプロセスは再考（単なる変更ではなく）されなければなりません。</li>
<li>テクノロジーがビジネスを推進する世界では、ビジネスアナリストはテクノロジーを避けているわけにはいきません。ビジネスアナリストは、テクノロジーを十分深く学習しなければいけません。それはテクノロジーによってもたらされる可能性を知り、特定のビジネス状況におけるテクノロジーの有用性、適用性、利益を評価するため、そして、ビジネス状況に対するソリューションを実装するために選択されたテクノロジーをベースにどのようにビジネス要求、ステークホルダー要求、ソリューション要求を引き出し、分析し、文書化する必要があるかを理解するためです。</li>
<li>広まっているさまざまなテクノロジーの出現に伴い、ビジネスアナリシスは特殊化の道をたどるでしょう。 デジタルの世界では、誰もがエンドツーエンドのソリューションを提供することはできません。 これはビジネスアナリシスの専門分野を組み合わせたもので、希望する顧客体験を提供するのに役立ちます。</li>
</ul>
<p>デジタルの世界で効果的なビジネスアナリシスのマインドセットとベストプラクティスを適用することで、デジタルウェーブを採用するビジネスの成功を確実なものにします。</p>
<h2>将来のビジネスアナリシス</h2>
<p>デジタルの世界とビジネス・ドメインの融合では、ビジネスアナリシスについて従来とは異なる考え方をする必要があります。 将来を見据えながら、ビジネスアナリストは内省的であることに縛られています。 頭の中で妥当な疑問は次のとおりです。</p>
<ul>
<li>ビジネスアナリシスは、デジタル時代にはどのような関係があるのだろうか。</li>
<li>ビジネスアナリシスは将来に適応するためにどのように変わるのだろうか。</li>
<li>デジタル時代に自分のスキルは十分だろうか。</li>
<li>有効性を維持するには、自分は何を学び、そして何を再学習する必要があるだろうか。</li>
</ul>
<p>考え方、規律、ビジネス上の問題とその解決方法に取り組む際の考え方として、ビジネスアナリシスは時代遅れになることはなく、今後も廃れることはありません。 ビジネスアナリシスの中核は同じであり続けるでしょう。デジタルの世界において BABOK®ガイドに記載されている知識エリア、タスク、およびコンピテンシーは、引き続き妥当性があります。 これらは基本的なベストプラクティスであり、進化するデジタル世界ではこれまで以上に重要になるでしょう。</p>
<p>ただし、現在および将来のような変革期には、確立されたビジネスアナリシス・アプローチ、ツール、テクニックは、依然として適切で必要なものですが、それだけでは十分とは言えません。 では、ビジネスアナリストはどのように将来に適応したらよいのでしょうか。</p>
<p>BABOK®ガイドに記載されているベストプラクティス。 これらのベストプラクティスは今まで以上にデジタルビジネスに必要かつつよい妥当性があります。</p>
<p>いわゆる「伝統的な」ビジネスの世界では、ビジネスアナリストはこれらのベストプラクティスを意識しなくても、あるいは適用しなくても成功することができたかもしれません。</p>
<p>アジリティ、進化するニーズ、そして革新性を特徴とするデジタルの世界に私たちがキャズムを乗り越えるとき、次の７つのベストプラクティスはデジタルビジネスアナリストのためのベースラインのプラクティスです。これらのベストプラクティスを習得する以外の選択肢はありません。</p>
<p><a href="http://kbmanagement.biz/wordpress/wp-content/uploads/2019/01/BBC2018情報10.png"><img class="alignnone size-medium wp-image-4221" alt="BBC2018情報10" src="http://kbmanagement.biz/wordpress/wp-content/uploads/2019/01/BBC2018情報10-300x225.png" width="300" height="225" /></a></p>
<ul>
<li>戦略的課題を理解する</li>
<li>真の顧客に共感する</li>
<li>ビジネスプロセスを再考する</li>
<li>アジリティに対応する</li>
<li>継続的にステークホルダーと協働する</li>
<li>エビデンス・ベースの意思決定を推進する</li>
<li>テクノロジーを理解する</li>
</ul>
<p>次回は具体的な内容を紹介します。</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://kbmanagement.biz/?feed=rss2&#038;p=4254</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
