要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita

はじめに タイトルの主張が少し強いですが、以下の本を読んでコミュニケーションスキルについて書かれている部分が有益だなと思ったので メモ程度 にまとめました。 元の本では具体例などが書かれていてわかりやすいので、その点を押さえたい方は購入をお勧めします。 コミュニケーションスキル 以下の3つがある ヒアリングスキル ミーティングスキル プレゼンテーションスキル 1.ヒアリングスキル A.質問 Open-Close Open 5W2Hを用いた質問 Why,What,Who,When,Where How(程度),How to(手段) Close yes,noで解答できる質問 認識の不一致が連続すると信頼を下げやすいので注意する 深掘り 目的 原因 影響・結果 手段 反復 「それ以外にありますか？」 明確化 曖昧な表現を明確にする 例：「うまくできない」→「納期に間に合わない」 論理性チェック A

[shibainu1969]

要件定義が一番難しいといつも思うけど、なぜか素人でもできる業務とみなされている。

[hdampty7]

発注側が受動的で説明をやりたがらない場合とか、ヒアリング事項の全体像すら分からない状態で着手しなければならない時とか、実践的な話が聞きたいなぁと。新規案件のヒアリングフェーズの日程計画が難しい。

[mz_bee]

横堀と縦堀が難しいんやけどね。「それができないと、なにが困ります？」「それをするときにミスしたことあります？」とかの実際に使っているフレーズが欲しいね。

[takanq]

目の前でヒアリングしてる人が真のステークホルダーなのか?の確認からよね。情シス所属というだけで既存システムを全然利用してない人が担当者として要件定義の窓口になること多いから...

[aike]

言葉の裏に隠された本当の解決すべき課題と本当の制約条件を見抜くスキル。あと、関係者のイメージの解像度に合わせて、あえて曖昧さを残したまま進めるようなコミュニケーションもすることある。

[yuno001]

本当に価値を産むナレッジは共有されない典型

[dlive1]

ヒアリングスキル ミーティングスキル プレゼンテーションスキル

[dekasasaki]

ゴールを思い描きつつ問題や課題を見抜いて整理し対処しながら、着地点も変化させられる内面的なスキルが無い状態で、これらのスキルだけ使われると困っちゃうかも。

[remonoil]

要件定義とはあんまり関係無かった

[Rinta]

だいじー！

[kazkaz03]

本当にメモ書き程度しか書いてなかったw