システムエンジニアへ業務説明をする際にするとよい質問の仕方

on

昨日、三昧を聞いていてこれでてきて笑った。めちゃ楽しい。



こっちは「もしもし」と「葛切り」！！



さてさて、所属する組織でリソースが確保できないときがありますよね。というか、SIだとほとんどできないケースが多いいか…。理由は、プロジェクトとしてのスキルセットが充足できないとか、コスト制約から、のいづれかでしょうけど。


では、そういったときの外部のリソースを調達する際の業務説明でどんな質問をしたらよいのでしょうか。


クローズドクエッションとオープンクエッション
人にものを尋ねるときには、質問の仕方で答えが変わることを理解した上で質問を組み立てると確認したかったことが効率的に聞くことができます。しかし、質問の仕方を間違えると聞きたいことを確認できるまでが遠回りになったり、聞きたいことにたどり着けなかったりします。


質問の仕方で良く出てくる方法は「クローズド・クエスチョン/オープン・クエスチョン」です。用語を調べてみましょう。

クローズド・クエスチョン／オープン・クエスチョン

質問方法の代表的な分類。相手が「はい、いいえ」または「AかBか」の択一で答えられるような、回答範囲を限定した質問の仕方をクローズドクエスチョンという。これに対し、「どう思うか？」などのように、制約を設けず相手に自由に答えさせるような質問のしかたをオープンクエスチョンという。
クローズド・クエスチョン／オープン・クエスチョン(くろーずど・くえすちょん/おーぷん・くえすちょん)とは - コトバンク


では、クローズド・クエスチョン/オープン・クエスチョンを意識した上で、採用者として質問を考えてみましょう。あなたは採用者側でパッケージ製品Xの要件定義から主体的に動けるスキルを持つメンバを探しています。


運良く、当該スキルを持つパートナーが見つかったので業務説明をしながら、メンバの候補者とチームが組めるか確証を得たいと思っています。

採用者「あなたはパッケージ製品Xの経験がありますか」

Q1　この質問はクローズド・クエスチョン/オープン・クエスチョンのどちらの質問でしょうか
Q2　この質問で質問側が期待する答えはなんでしょうか
Q3　この質問で回答側が答えそうな回答は何でしょうか


A1クローズド・クエッションA2上流設計を主体的に動ける経験があるA3○○プロジェクトで経験があります


どうやら最初の質問は期待したことを上手に聞けなかったようです。もう一度質問指定みましょう

採用者「あなたはパッケージ製品Xを要件定義から設計したことはありますか」

Q4　この質問で質問側が期待する答えはなんでしょうか
Q5　この質問で回答側が答えそうな回答は何でしょうか


A4パッケージ製品Xを使ったプロジェクトで要件定義から主要メンバとして参画した経験がある/ないA5パッケージ製品Xを使ったプロジェクトで要件定義から参画した経験がある/ない


この質問では要件定義からの経験の有無の確認が取れますが、主体的にある範囲を任せられるかどうかまではわかりません。もうちょっと、質問を工夫してみましょう。

採用者「あなたはパッケージ製品Xを要件定義からブロックリーダとして設計したことはありますか」

Q6　この質問で質問側が期待する答えはなんでしょうか
Q7　この質問で回答側が答えそうな回答は何でしょうか


A6パッケージ製品Xを使ったプロジェクトで要件定義からブロックリーダとして参画した経験がある/ないA5パッケージ製品Xを使ったプロジェクトで要件定義からブロックリーダとして参画した経験がある/ない


やっと、ここまで来て質問する側と回答する側の回答が一致しました。一見、質問の仕方のプラクティスを訪ねているようにみえますが、実は、チームのスキルセットを確保する際に重要な質問の仕方を含んでいます。


それは、ロールの経験と自分で手を動かすことができるかを聞いているのです。それは、「ブロックリーダ」というデリバリーとしての技術のSEリーダとしての役割で示しています。


そして良くある確認を間違えてするやり方です。

採用者「経歴では、あなたはパッケージ製品Xの経験が多いでね。これだけあれば安心して参加をお願いできますよ」


キャリアのレジュメほど信用できないものはないでしょう。だって一緒に働いたことがないんですから、そのひとの仕事ぶりや基本スキル、技術スキルとレベル、経験してきたロール、持っているプラクティスの一切がわかりません。


こちらの必要とする技術スキル、レベル、はめたいロールの位置に合う候補者かを確認しないのなら、わざわざお互いに時間を使ってまで業務説明をする必要はないのです。業務説明をわざわざする意味を理解して効果的な質問をしましょう。