要求開発に必要なスキル

必要とされるスキル

要求開発を行う上で必要とされるスキルについて説明しましょう。この事は、「Vol.8 要求開発チーム」でも説明しましたが、ここではより詳しい説明を行います。

みなさんは、ここで説明するスキルについて、最初からすべて獲得する必要はありませんし、簡単に獲得できるものではなく数々の経験から蓄積されるものなのです。

ここに書いてあるスキルの説明を読んで、一歩一歩要求開発の道を歩んで行ってください。それぞれのカテゴリごとに比較的に学びやすい順に並べていますので、参考にしてください。

要求開発の必要なスキル表

表1(技術)要求開発の必要なスキル

カテゴリ スキル要素 説明 シチュエーション
技(技術) UML モデリング記述言語が理解できている。 Aさんは、ビジネスユースケース、業務フロー、概念モデルが書ける。
要求開発 要求開発の考え方、プロセス、モデルが理解できている。 Aさんは、要求開発プロセスの各フェーズの中でのモデリングの活かし方が分かっている。
モデリング 必要局面において、本質面で抽象化された"見える化"ができ、説明できる。 Aさんは、どんな局面でも、さまざまな工夫で、モデリングができて、いつの間にか、みんなに共有理解を与えられるんだよね。
問題・課題分析 問題・課題について、本質を見抜けるような分析能力を持っている。 Aさんは、問題の要素分解や、問題の本質を見抜く力に優れているし、それをスピーディに行い、人に説明できているよね。
業務(ビジネス) 問題領域の業務を理解している。 Aさんは、業務をある程度理解しているし、業務の問題・課題やあるべき姿について、しっかりと勉強しているよね。
開発(IT) プログラム言語知識、開発経験がある。 Aさんは、ビジネスのToBeの姿をITを用いてプロトタイプとして見せることが得意だよね。

表2 (人)要求開発の必要なスキル

カテゴリ スキル要素 説明 シチュエーション
人(人と人の活動) 記録 会議の要点を的確に記録できる。 Aさんがいると会議の要点をしっかりと記録して、後で誰にでもわかるように見える化できるよね。マインドマップも使えるしね。
スケジュール 日々、月々、フェーズにおけるスケジュールを組める。 Aさんは、要求開発の活動が手に取るように分かりやすいスケジュールを日々作成し、みんなに見せてくれるよね。
会議進行 会議をスムーズに進行できる。 Aさんがいると、要求開発の会議がスムーズに進行するよね、何でだろう?彼は、議題、ゴール、ステップを前もって予測して作成していて、事前に説明するし、最後に振り返りしているからじゃない?
リーダシップ 要求開発チームの中でうまいリーダシップが図れる。 Aさんやる気あるよなあ。いつも元気だし、皆に気を使って、チームを盛り上げてくれている。僕はあの人が好きだし、一緒に仕事がしたいなあ。
メンターリング 技術やノウハウを人に教えることができる。 僕もAさんから学びたいなあ。あの人の指導は、単に技術だけではないと思うよ。でも技術だけとっても、その技術の本質をちゃんと説明にしてくれる。
コーチング それぞれの役割に応じた、コーチができる。 僕はAさんのおかげでリーダになれたよ。あの人は自分の良いところを見抜いて、そこを自ら伸ばすための心得を教えてくれるんだ。
ファシリテーション 会議等の進行において、参加者の意識を高め、自ら積極的に活動していくために場を盛り上げることができる。 Aさんがいると会議がスムーズに進むよねえ。それにやる気もでてくるし。きっとAさん会議の進行がうまいんだよ。いやそれだけではない、彼は、人をやる気にさせたり、場を盛り上げる演出家なんだよね。

表3 (心)要求開発の必要なスキル

カテゴリ スキル要素 説明 シチュエーション
心(強い心) 明るさ 場を明るくすることができる。 Aさんがいると、何か周りが明るくなるよね、やっぱり笑顔だろうなあ。でも彼も僕らと同じく、つらい時もあるだろうし、きっと明るく楽しく仕事をやってもらおうと一生懸命なんだよね。
情熱 参加者と情熱を共有することができる。 Aさんは情熱をもって業務改革を進めているよね。あの人の言葉からは情熱がほとばしり、人に情熱を伝えて、人を変えてしまう。
Bさんも凄いよ、Aさんとは違ってパフォーマンスはしないけど、一言一言に重みがあって、行動自体に熱意がある。そうだね、タイプは違うけど、僕らは二人のようになりたいね。
やる気 参加者を、やる気にさせる。 Aさんは、人をやる気にさせることがうまいよなあ。彼は、人を使う事も、自分で積極的に動くこともできるし、なにより、人を動かすための言葉を発明するからすごいよね。
覚悟 チームの中で覚悟を取り付ける。 今日の会議のAさんは凄かったね。部長をうならせたよね。そもそもToBe業務の見える化に覚悟が必要だという基本的な事を疎かにしていたなあ。これからToBe業務を設計する上で覚悟が大切だということをAさんから学んだよ。
決断 チームの中で重要な問題に対して正しいステップで決断させる。 今回の会議もダラダラ感がないよね。それもAさんのおかげだと思わないかい?
そうだね、彼は、議論の空中戦が始まろうとすると、問題を的確に分析し、選択肢をさまざまな角度で説明して、チームの中で決断ができる土台を作りあげる。僕もあんな能力を学びたいなあ。
気づき 参加者に気づきを与え、意識改革を行う。 いやあびっくりしたよ今日のAさん、あれだけコスト削減の議論炸裂で皆のモチベーションを下げまくっていた部長が、あの発言で変わったよね。イノベーションというか、発想の転換というか、彼は人を気づかせるための様々な観点を持ち備えているんだろうね。

ページトップへ

 

「技」「人」「心」を強くする

さあ、いかがでしたか?
この表は要求開発のスキルについて「技」「人」「心」という観点で説明しているんですよね。そして、それぞれが非常に関係が深いことに気がつきましたか?
それは、人は「心」で動く動物であり、それを「人(人と人の活動)」で使い、そしてそれらを裏打ちされた「技(技術)」によって形にして人に伝達しているからです。

しかし、よくあるダメ事例としては、これら「技」「人」「心」をバラバラに教育してしまうことですよね。
あるいは「心」なき「人」の領域を学んだり、「心」と「人」なき「技」を教えたり。

「技」「人」「心」を分けつつも、つなげて教育する、これがこれからの教育であり、要求開発のスキル習得に最も重要な事なのです。
これができている人はどんな人でしょうか?
そうです要求開発マイスタースゴー君なのです。

図1 「技」「人」「心」が強いスゴー君
図1 「技」「人」「心」が強いスゴー君

図2には昨年から使用している「技」「人」「心」の説明図を示します。
さあ、みなさんも「技」「人」「心」バランスよく強化するように心がけましょう。

図2 「技」「人」「心」
図2 「技」「人」「心」

拡大画像

ページトップへ

 

目指せ、ビジネスアーキテクト・ITアーキテクト

さあ、これらのスキルを持って、どのようなキャリアを目指すべきでしょうか? 僕は、次の図のようにビジネスアーキテクト・ITアーキテクトを目指しましょうと説明しています。この図は、「Vol.4 ビジネス価値を創出できないシステムの図2 要求はHowでもある」で使用したものを改良したものです。 ビジネスアーキテクト・ITアーキテクトは、それぞれ下記の役割を担います。

ビジネスアーキテクト

ビジネス戦略を踏まえて、業務オペレーションを分析しToBe業務モデルを確立し参加者からの合意を得ることができる。また、その中からIT要求を開発し、開発担当に説明できる。

ITアーキテクト

ToBe業務モデルの構築にも参加でき、ビジネス戦略、業務問題・課題を背景としたシステム要求の確立についてビジネスアーキテクトと一緒に行動し、獲得されたシステム要求から、システムアーキテクチャを作りだすことができ、それを開発メンバーに分かりやすく説明する能力にたけている。

図3 ビジネスアーキテクト・ITアーキテクト
図3 ビジネスアーキテクト・ITアーキテクト

拡大画像

本来、ビジネスアーキテクトとITアーキテクトは同一人物の方が望ましいでしょう。しかしある程度の規模になると両者は分かれることになりますし、現段階で両者をこなせる人はそんなにいないでしょう。

ここで重要なのは、ビジネスアーキテクトとITアーキテクトのスキルがカスケード(重なり合っている)していることです。これにより、異なるロールを持つ両者の間で、見える化された知識交換がスピーディに行うことができるようになるのです。

そして、両アーキテクトは、プロジェクト参画メンバーに分かりやすい図と言葉で、これらのビジネスITの知識を伝えることが責務となります。

ページトップへ

 

誰が、ビジネスアーキテクト・ITアーキテクトになれるのか?

僕の経験では、ビジネスアーキテクトは、業務担当あるいはIT担当どちらでも「表1 要求開発の必要なスキル」を身につけていけば可能です。

ITアーキテクトはビジネスアーキテクトのスキル要素を自然に身につけていますので、ITアーキテクトはビジネスアーキテクトに転身することは比較的容易なことですが、その逆はITを初歩から学ぶことが必要となり難しいでしょう。

また、ビジネス(業務)スキルは、ビジネススペシャリストを目指すこととは異なります。
ビジネス(業務)の問題・課題を整理して、それをどう変えればよいか、ビジネススペシャリストに聞きながら、見える化していくスキルなのです。そういう意味では、業務知識に詳しい業務担当の他、ITアーキテクトのスキルを身に付けた人も目指しやすいのです。

またさて、要求開発に必要なスキルについての話はこれでおしまいです。 さあ、次回は要求開発の心得について話します。


  • ※掲載されている製品・サービスは、掲載当時のものです。
  • ※掲載されている社名および製品名は、各社の商標または登録商標です。

ページトップへ