はじめに
こんにちは。
株式会社デジサク の多森です。
今回の記事では、要件定義・プロジェクト企画を推進するためのネゴシエーション術について扱っていきます。
ITプロジェクトを推進していて、こんなことを感じた経験はないでしょうか？
- 「バラバラな意見・要望を収集できない」
- 「発言力がある人の影響に負けてしまう」
- 「いつまでも追加要望が止まらない」
関係者の意見を尊重しつつも優先順位を明確にして、全員で同じ目的に向かってプロジェクト推進するバランス感覚が欲しいと常々感じます。
こんな悩みを解決するために、、
「センスに頼らない！要件定義・プロジェクト企画のネゴシエーション術」
こんなテーマで、様々な関係者とスムーズに調整する考え方を３つの軸（タイプ別・役職別・フェーズ別）で整理しました。
本記事の章立ては以下の通りです。
ーーーーー
- 企画・要件定義のほとんどは関係者との調整
- ポイント①：思考タイプ別のコミュニケーション
- ポイント②：役職別のコミュニケーション
- ポイント③：フェーズ別のコミュニケーション
- ネゴシエーション実践のコツ
- さいごに
ーーーーー
※SNSでも情報発信しています（Twitter：Saku731 ）
企画・要件定義のほとんどは関係者との調整
「プロジェクト目的の共有化」を最優先する
システム開発の最初にやるべき作業はプロジェクトの目的を明確にして関係者と合意することです。いわゆる「企画構想フェーズ」です。
そこから「現状とゴールのギャップ（解決すべき課題）」を洗い出します。
そして最後に「課題をどうやって解決するか？」といった解決策を要件定義に落とし込みます。
具体的な手順としては 「①要望→ ②要求→ ③検討→ ④提案→ ⑤要件」 の流れで整理すれば、トラブルが少なくプロジェクト上流工程を進めることが可能です。
特に最初の ①要望〜②要求 で 「プロジェクト関係者が同じ目的を共有」 できればプロジェクトの失敗リスクを大きく減らす事ができます。
ですが、実際のプロジェクトはこう簡単には進みません。
プロジェクトは大きくなるほど様々な関係者が集まります。当然ながら集まる意見・要望はバラバラです。
この状況をどうやって収集すればいいのか？
これがネゴシーエーションのキモとなってきます。
ネゴシエーションの必要性
ITプロジェクトは経営層・決裁者・現場スタッフなど、多くの意見を集めながら合意形成します。立場によって優先順位がバラバラなので１つに整理するのは困難です。
実際、プロジェクトに関わった中でこういった苦い経験をした人が多いと思います。
「開発中にプロジェクト方針が変わって作り直しになった」
「現場から"業務が忙しい"と言われて協力を断られた」
「リリース後に重要なビジネス要件が発覚した」
こういったトラブルの予防策が「ネゴシエーション」です。
日本では「口先で相手を納得させる表面的なスキル」だと思われがちですが、海外では「ネゴシエーター」と呼ばれる職業が存在するほど重要性が認められた分野です。
大きく分けると３つの手順でコミュニケーションを深めます。
- 関係者と信頼関係を構築する
- 利害関係を調整する
- 納得してもらえる着地案を作る
以降では、「いつ」「誰に」「どんな会話」をすればスムーズにネゴシエーションが進められるのか実例を交えて解説してきます。
ネゴシエーションは「３軸の掛け算」で考える
ネゴシエーションでは相手の気持ちに寄り添う事が重要です。
相手の興味関心に合わせて情報粒度を変えたり、伝え方を工夫することで、「相手にとって気持ちの良いコミュニケーション方法」 を選択するスキルが基本になります。
しかし、100人いれば100パターンの正解があります。口先で丸め込むテクニックでは限界があるので注意しましょう。
そこで、訓練すれば誰でも現場で活用できる 「ネゴシエーションをロジカルに実践する３軸の掛け算」 をご紹介します。
（１）思考タイプ別：「相手が好きなコミュニケーション方法」を選択する
まず最初に 「相手の思考タイプ（考え方の特徴）」 を知ることから始めましょう。
思考タイプごとに気分よく感じるコミュニケーション方法が決まっているので、適切な会話の流れを知っておけばスムーズです。
筆者の経験的に、４つのパターンに整理できると考えています。
- 決断型： 決断力があり、リスクを取れるので自分で判断したい（トップダウン思考）
- 分析型： じっくり考えるのが好きで、状況を具体的に把握したい（ボトムアップ思考）
- 情熱型： 情報通で、ワクワクする事をやりたい
- 実行型： キレイに整えるのが好きで、着実に進めたい
特別なセンスは不要なので、普段の言動パターンから思考タイプを判断すれば大丈夫です。
詳しくは 「１）思考タイプ別のコミュニケーション」の章でご紹介します。
（２）役職別：「相手の立場から見て重要なトピック」を選択する
続いて、相手の立場によって見ている視点が違うのだと理解しましょう。同じプロジェクトでも、役職・部署によって優先順位が変わってきます。
１つの例として以下のように整理できます。
- 経営者： 中長期で売上成長させる
- 部長クラス： 今年の売上目標を達成させる
- リーダー： プロジェクトを成功させる
- 一般メンバー： 目の前のタスクを完了させる
そう考えると、部長クラスに「現場はこんな非効率で困っている」と伝えても納得されないのは当然で、興味関心に合わせて 「現場の非効率を解消すれば売上が⚫︎％改善する」 と伝える方が得策だと判断できます。
より細かいノウハウは「２）役職別のコミュニケーション」の章で紹介します。
（３）フェーズ別：「プロジェクトの進展に応じた決定事項」を段階的に着地させる
最後の３つ目では 「決定事項には順番がある」 という事を理解しましょう。
よくある失敗としては、「プロジェクト目的（何が達成できれば成功か？）」を関係者と合意する前に「細かなシステム要件」を作成する失敗パターンが意外と多いです。
目的を決めずにスタートしたプロジェクトは、後から必ず重要な追加・変更が見つかるので混乱が起きます。最悪のケースではプロジェクト自体が消滅することも珍しくないです。
手戻りが少ないプロジェクト推進のためには、５つのステップで段階的に決定事項を着地させていきましょう。
- ①要望： プロジェクトの背景（誰が・何に困っているのか？）
- ②要求： 何が達成できればプロジェクト成功と言えるか？
- ③検討： エンジニアと協力してシステムに必要な仕様を洗い出す
- ④提案： 決済者にシステムの完成像を説明して承認をもらう
- ⑤要件： 明確なシステム仕様として要件定義に落とし込む
より細かい情報は「３）フェーズ別のコミュニケーション」の章で紹介します。
３つの軸を使えば、センスに頼らずに済む
プロジェクト推進のためには関係者とのコミュニケーションは避けられないです。
しかし、変化スピードが速い昨今のビジネス環境では、じっくり経験を積んでコミュニケーションを学ぶチャンスは少ないです。
そこで、３つの軸を組み合わせて、ロジカルに考えるコミュニケーション能力が重要となってきます。これがネゴシエーションだと考えています。
以降の章で１個ずつ解説していきます。
１）思考タイプ別のコミュニケーション
思考タイプ別のコミュニケーションでは、相手の「思考パターン（考え方の特徴）」に合わせた会話の流れを理解します。
思考タイプごとに好きなコミュニケーション方法が決まっているので、ポイントさえ押さえれば気持ちよく協力してもらえる可能性が高くなります。
- 決断型： 決断力があり、リスクを取れるので自分で判断したい（トップダウン思考）
- 分析型： じっくり考えるのが好きで、状況を具体的に把握したい（ボトムアップ思考）
- 情熱型： 情報通で、ワクワクする事をやりたい
- 実行型： キレイに整えるのが好きで、着実に進めたい
タイプ１：決断型
決断型の人は判断が早いので、細かな背景よりも明確な結論を求めるケースが多いです。
こういった言い方をする人は決断型だと判断できます。
- 「何をやったら良いですか？」など結論を早く知りたい
- 「優先すべき事はなんですか？」と聞いてくることが多い
- 「こういう事ですか？」など話の途中で結論を先回りする
決断型の上司とのコミュニケーション
そのため、決断型の上司にプロジェクトの承認をもらう時には「決断するための判断基準」を明確に伝えればスムーズに事が進みます。情報が足りなければ明確なNoが貰えるので非常に分かりやすいです。
つまり、ロジックの積み上げよりも、結論ファーストで伝える事がポイントとなります。
逆に、こちらから結論を誘導するコミュニケーションは逆効果です。
決断型の部下・関係者とのコミュニケーション
決断型の部下・関係者にタスクを依頼する時には「欲しい成果物は⚫︎⚫︎です。ココだけ外さなければ細かい部分は任せます」など、相手に任せるスタンスが有効です。
逆に避けたいのが「このフォーマットでお願いします」など細かく手順まで指定すると、勝手にフォーマットを変更されてしまうケースが多いです。
なので「手順どおりにやってもらえない可能性がある」と意識したコミュニケーションが重要で、あくまで「必ず満たすべき要点」だけを明確に伝えるタスク依頼が良いです。
タイプ２：分析型
分析型の人はじっくり考える事が得意なので 「なぜその結論になったのか？」といったロジカルな根拠を求めるケースが多いです。
こういった言い方をする人は分析型だと判断できます。
- 「詳しく説明が欲しいです」など詳細を深掘りする
- 「具体的な情報はありますか？」など根拠を気にする
- 「他にもありませんか？」など検討モレが気になる
分析型の上司とのコミュニケーション
分析型の上司に相談する時には、ボトムアップ的にロジックを積み上げる事が重要なので、「ロジックツリーなど全体俯瞰できる情報整理」 を意識するとスムーズです。
注意点として「検討が足りていない」など、曖昧な理由でプロジェクトが却下されるケースがあります。こういった時には「どこがOKで、どこがNGだったのか？」を明確に確認しましょう。
また、好きな資料フォーマットが決まっているケースも多いので、最初から正解サンプルを見せてもらうのも有効です。
分析型の部下・関係者とのコミュニケーション
続いて分析型の人にタスク依頼するケースです。相手が納得できるまでディスカッションする必要があるので時間に余裕を持って行きましょう。
進め方としては、まずこちらが持っている情報を「順序立てて説明」します。そうすると、疑問に感じたことを質問してくれるので、それに応えながら理解を深めてもらう流れです。
納得すれば的確に作業してくれるので心強い反面、「そんな断片的な情報では動けません」など納得感が低い時の反発が大きいのも特徴です。
つまり、要点だけ端的に伝えるコミュニケーションは逆効果です。
また、タスクの目的から脱線して本人の興味が向く方向に突き詰めてしまう傾向もあるので、任せる範囲を明確にしておきましょう。
タイプ３：情熱型
情熱型の人はインフルエンサー的な感覚を持っており、周囲と仲良くしたり、モチベーションを上げることが得意です。
理論よりも直感で判断するので「もっとワクワク感が欲しい」といった感覚的な話が多いです。「誰が関わっているプロジェクトか？」などの人間関係も重視します。
こういった言い方をする人は情熱型だと判断できます。
- 「それ誰が言ってたの？」など発言者を強く意識する
- 「それ面白いの？」など感覚的な発言が多い
- 「こんな事できそう！」などアイディアを広げるのが得意
情熱型の上司とのコミュニケーション
情熱型の上司にプロジェクトの承認をもらう時には、決断型・分析型のようにファクトを伝えるだけでは不十分です。
「楽しい事が起こりそうな予感」だったり「社内の影響力ある人が関わっている」など直感に訴えかけるコミュニケーションが大切になってきます。
また、テンションが下がった時の落差が激しく、「難しいプロジェクトだけど頑張りましょう」など、苦労や努力をイメージするようなコミュニケーションは逆効果になることが多いです。
あくまで楽しい事を連想するコミュニケーションが効果的なので、普段の発言をヒントにして 「この人は何にワクワクするんだろう？」を情報収集しておきましょう。
（「このプロジェクトが成功したら昇進しちゃいますね！」など）
情熱型の部下・関係者とのコミュニケーション
情熱型の人は熱しやすい反面、細かい作業を任せると冷めるのも早い特徴があります。
「アイディアを考えるフェーズでは積極的なのに、いざ実行するタイミングで急に冷める人」 に驚いた経験はないでしょうか？もしくは、あなた自身が情熱型かもしれません。
情熱型の人にタスクを依頼する時には以下のようなポイントを意識しておきましょう。
- タスクを分割して、短いスパンで達成感を用意する
- 「やり方のアイディアはありますか？」など工夫の余地を残す
タイプ４：実行型
実行型の人はプロセスを大切にするので「決められた手順通りに作業する」ことが好きです。自分のペースで丁寧に仕事を進めたいので、他のタイプよりも時間をかける傾向があります。
また、チーム全体の調和を大切にするのも実行型の特徴です。
こういった言い方をする人は実行型だと判断できます。
- 「具体的にどうやります？」など手順を知りたい
- 「急に言わないで下さい」などペースが乱れるのを嫌う
- 「みんなで協力しよう」など他の人を気にかける
実行型の上司とのコミュニケーション
実行型の上司は 「明確な作業プロセスまで決まった状態」 を好む傾向が強いです。
新しいチャレンジするよりも 「表面化している問題を着実に改善すべき」 と考えるので、情熱型が重視する「ワクワク」「楽しい」とは真逆の思想です。
そのため、プロジェクトを相談する時には以下を意識しましょう。
- 斬新なアイディアは逆効果（堅実な企画が好き）
- 「実行可能なタスクとスケジュール」が決め手になる
- リスクと対応策を十分に検討しておく
実行型の部下・関係者とのコミュニケーション
実行型の人は 「決められた手順通りに作業する」 ことが得意です。
いつも同じ品質でタスクを仕上げる能力が高いので、基本的にはルーティンを着実に進めるポジションが適任です。
本人が安心できる環境を用意できれば「あれ、もうタスク終わったんですか？」といった感じで良いパフォーマンスを発揮してくれます。
以下の項目を意識して、実行型の人が得意なルーティンに近い環境（急な変更が少なく、自分のペースで丁寧に仕事できる環境） を整えましょう。
-
タスクの依頼前に事前説明しておく
- いつ頃にタスクを依頼する予定か？
- どの程度のボリュームなのか？
- 上司にはOKもらっている
-
タスクの意図が明確
- 何に繋がるタスクなのか？（全体における位置付け）
- 成果物のフォーマットは？（達成基準）
- 成果物は誰が・何に使うのか？（誰のために？）
-
本人にとって余裕のあるスケジュール
- まず希望スケジュールを伝える
- 即答は求めずに後で回答してもらう
- 調整は「ここを削ったら早まりますか？」など提示
思考タイプ別のまとめ
以上４つの思考パターンで「気分よく会話できるコミュニケーションの特徴」を整理しました。
- 決断型： 決断力があり、リスクを取れるので自分で判断したい
- 分析型： じっくり考えるのが好きで、状況を具体的に把握したい
- 情熱型： 情報通で、ワクワクする事をやりたい
- 実行型： キレイに整えるのが好きで、着実に進めたい
意識してコミュニケーションすれば、あまり面識がない相手とのコミュニケーションでも大きく失敗するリスクを軽減できます。いつも苦手だった相手との関係が向上することもあります。
また、実際には 「１人が複数の思考タイプを併せ持つケース」 が多いです。例えば多いパターンで以下の２つが挙げられます。
-
決断型 + 情熱型
=> 自分で即断即決して、自分で周囲を巻き込む
（典型的なリーダー気質） -
分析型 + 実行型
=> じっくり考えて、じっくり作業する
（データサイエンティスト, 研究職などに多い）
あくまで基本の４パターンを土台に考えれば良いので、焦らず１個ずつ慣れていきましょう。
２）役職別のコミュニケーション
続いては役職別のコミュニケションとして、 相手の立場によって見ている視点が違う ことを解説します。言い換えると、 プロジェクトに対する価値基準が違うということです。
この章では役職別の興味ポイントを５パターンで解説しますので、「あの人にはどういったコミュニケーションが効果的かな？」など考えながら読まれて下さい。
- 経営層・決裁者
- 自分の上司
- 自分の部下（リーダー級）
- 自分の部下（一般メンバー）
- 関連部署
役職１：経営者・決裁者
まずは経営層・決済者の視座と興味を引くポイントです。
普段から中長期で市場動向・自社ビジネスの方向性を見ているので、会話する時には 「このプロジェクトは中長期のビジネス成長において、どういった役割を果たすのか？」 といった視点から説明が必要です。
具体的には以下のようなポイントを準備しておきましょう。
- 経営戦略における位置付け
- ３年程度のスパンで見た投資対効果
- 既存ビジネスとのシナジー
また、会社としてのリスク対策やコンプライアンスも考慮する必要があるので、事前に調査して対策を準備しておきましょう。
- 競合他社や業界全体の動向（そもそも追い風なのか？）
- テック企業による破壊的イノベーションの予兆（Amazon, Uber, Netflixなど、海外勢が数年遅れで日本進出してくる）
- 法令・規制・倫理的な基準（個人データ保護に関する法令など）
役職2：上司
続いて自分の上司に対してのコミュニケーションです。
上司の見ている視座は部署の予算達成であったり、メンバーのリソース配分。さらには他部署との関係性が挙げられます。
- 部署としてのメリット（予算達成への貢献）
- どれだけの工数が必要か？（既存業務とのバランス）
- 社内の協力が得られるのか？（協力部署のメリット）
もちろんリスク対策も重要です。自分達だけでなく、協力部署が懸念しそうなポイントを予測して事前に相談しておくと上司への説得力がアップします。
各部署が気にするトピックの例を挙げておきます。
- 営業部：新しい取り組みが顧客に受け入れられるか？
- 経理部：新しいルール整備（会計・税務）は必要ないか？
- 法務部：コンプライアンス的に問題はないか？
Tips：経営層・上司の「思考タイプ」に合わせるとベター
ここで少し経営層・上司へのヒアリングのコツをご紹介します。
要求フェーズでは経営層や上司へのヒアリングをして目的や背景を理解することが大事になってくるので、コミュニケーションで失敗するとその後のプロジェクト運営に支障が生まれます。
そこで、前の章で解説した「思考タイプ」を活用すると良いです。相手のタイプに応じて気持ちよく感じてもらえるコミュニケーションを心がけましょう。
-
決断型：
簡潔かつ即回答できるような質問だと気持ちよくコミュニケーションできます。例えば「A案とB案があり、それぞれ⚫︎⚫︎といった特徴があります。どちらが良いかご意見ありますか？」といった具合です。
-
分析型：
突然話しかけるのを嫌がるので「〜〜について、話しかけても良いですか？」など丁寧に確認します。そして、いきなり結論ではなく目的から順に説明すると心地よく回答してもらえます。
-
情熱型：
「〜〜さんなら詳しいと思って質問なのですが。。」など、相手を尊重する表現が喜ばれる傾向があります。また、重要な判断では高確率で「⚫︎⚫︎さんの意見は聞いた？」など聞かれますので、重要人物への共有は済ませておきましょう。
-
実行型：
着実に進める事を重視するので、「どうやって進めるのか？」などの実行プランもセットで提案しましょう。また、協調性を大事にしたいので「分からない」と言える余地を残しながら意見を聞くと心地よく回答してもらえます。
役職3：部下（リーダー級）
続いて自分から見た部下（リーダー級）とのコミュニケーションです。もっとも重要なポイントが 「担当する責任範囲の明確化」 です。
- どんな問題を解決するためのプロジェクトか？
- 部署戦略におけるプロジェクトの位置付けは？
- どこまでの判断を任せるか？
また、最後にプロジェクトの成否を分けるのは「リーダーの粘り強さ」です。きちんと「リーダー個人の成長・キャリアプラン」にも意識を配っておきましょう。
以下のようなポイントを意識してコミュニケーションすると良いです。
- 本人が望んでいるキャリアプランは？
- プロジェクトを通じて何を学べるか？
- どんな新しいチャレンジが出来るか？
役職4：部下（一般メンバー）
一般メンバーへのコミュニケーションで重要なのは、まずは 「タスクを理解してもらう事」 です。
多くのビジネス書では「まずプロジェクトの目的を共有しましょう」と説明されますが、最初から抽象的な事を説明してもスルーされる可能性が高いです。
まずは具体的なタスク（作業内容）を理解してもらいましょう。そうすれば、抽象的で難しいプロジェクト目的を理解するための余裕が得られます。
タスクの概要としては、最低限でも下記の内容を伝えたいです。
- 求めるクオリティ（可能なら成果物のフォーマットも用意）
- スケジュール（チェックに必要なバッファも含める）
- 想定されるリスク（「⚫︎⚫︎が起きたら教えて」など指示）
これらの土台が整った後に、プロジェクトの目的・キャリアプランなど抽象的なことを説明します。
- プロジェクトの目的（部署戦略との関連）
- 担当してもらう役割（全体のどこを担当するか？）
- 新しく学ぶ知識（次のキャリアへの繋がり）
役職5：関連部署
関連部署は「プロジェクトへの情報提供、タスク参加」など、具体的に作業ベースで協力してくれる部署を指します。
注意点として「担当部署だから協力してるだけ」「上司に言われて参加した」など、担当者のモチベーションは低くて当たり前 です。断られるリスクも想定してコミュニケーションします。
「それが実現したら嬉しい」「ここの部分なら協力できる」と感じて貰うために、次のような内容を強調しましょう。
-
１）依頼するタスク量・時期:
どれだけ素晴らしいメリットを伝えても、仕事のボリュームが不明瞭だと断られるリスクが高くなります。まずはここを整理しましょう。
-
２）責任範囲：
任せる責任範囲が不明瞭だと、リスクを嫌って協力してもらえないケースが多いです。特に人事部・経理部などの機密情報を扱う部署からデータ提供してもらうのが困難となります。
-
３）協力するメリット：
「⚫︎⚫︎の仕事が楽になる」など、分かりやすいメリットが説明できると理想です。担当者レベルではなく、部署レベルの規模でメリットが提示できるよう意識しましょう。
しかし実際には「相手にメリットが無いタスク」も多いです。そういったケースでは次の「４）全社戦略における位置付け」が重要になってきます。
-
４）全社戦略における位置付け：
「事業全体に⚫︎⚫︎なメリットがあって、そのためにタスクを依頼したい。これが無いと進まない」と明確に伝えれば、よほど保守的な部署でなければ協力してもらえます。
（３）で挙げた『明確なメリットが無い状況』でも「さすがに断れない。。」と納得してもらえる可能性が高まります。
３）フェーズ別のコミュニケーション
最後の３つ目では「フェーズ別のコミュニケーション」として、プロジェクトの進捗に応じて検討すべき項目を解説します。
具体的には５つの手順で企画〜要件定義を進めるとスムーズです。この順番を間違えると、大きなミス・手戻りに繋がってしまいます。
- ①要望： 解決すべき問題は何か？（経営層・上司との共通目的）
- ②要件： 何を達成すればプロジェクト成功か？（関係者との合意）
- ③検討： どうやってゴール達成するか？（システム仕様を整理）
- ④提案： プロジェクト承認を得る（開発目的とシステム仕様が一致）
- ⑤要件： 明確な完成像として要件定義に落とし込む
①要望フェーズ
要望フェーズで明確にすることは以下の通りです。
何よりも 「最初のタイミングで決済者と目的意識を一致させる」 ことを大切にしましょう。
- 依頼を受けた時にスケジュール感を確認する
- 要望（背景、目的など）を整理する
- 企画資料を作成する
- 企画資料（２０％の完成度）で認識合わせをする
ポイントはこの時点で理解が合っているか認識を取っておくことで手戻りを減らすことです。経営陣・上司が何を期待しているのか大枠から順に明確にしましょう。
その後、経営陣から依頼された内容をベースにして現場ヒアリングを行います。
ここでちょっとしたTipsですが、現場・他部署でヒアリングすると愚痴を聞くケースが多いです。
ここで変に賛同すると「もちろんシステムにも反映してくれるよね？？」などペースを奪われてしまうので、あくまで中立な立場を取ることが大切です。
その時にどのように対応したら良いのかポイントが３点あります。
-
否定も肯定もしない
シンプルに「なるほど」「そうなんですね」「理解しました」などの言葉で返事を返す。
-
「そう思うでしょ？」と聞かれても同調しない
「詳しいことは知らないのですが、⚫︎⚫︎さんの大変さは伝わりました！」など、相手の気持ちを尊重しつつ、同調はしない。
-
話題を問題解決の方向に切り替える
「それを踏まえて、どうしたら良くなると思いますか？」など、目線を前に向ける質問を投げかける。
②要求フェーズ
要求フェーズで明確にするのは以下の通りです。
『①要望フェーズ』で整理したプロジェクト目的を具体化して、何を達成すればプロジェクト成功なのか決めるために 「達成条件の明確化（可能な限り数値化する）」 を行います。
システム導入後の新しい業務フローを作成したり、システムでやりたいこと（ユースケース）の明確化も行います。
- 企画資料へのコメントを元に資料を更新
- 目的を数値化する
- ゴール達成条件を明確にする
- 導入・開発後のフローを書く
- システムで実装する機能を明確にする
ポイントは、プロジェクト関係者の共通理解として人によって解釈がブレないよう、達成条件を明確に表現することです。
すべて数値で表現するのは難しいですが、例えば「最適化」「効率化」「可視化」など人によって解釈が分かれる表現を避けるために可能な限り具体化しましょう。
③検討フェーズ
検討フェーズではエンジニアの技術的な知見を借りて、どうやってプロジェクト目的を達成するのか、現実的なラインで検討していきます。
また、検討フェーズはエンジニアにプロジェクト目的を理解してもらう役割も兼ねています。
よくある失敗パターンとして「エンジニアと機能要件ばかり会話して、目的意識がズレてしまった」と耳にすることが多いです。
エンジニアとディスカッションしつつ、以下の流れで共通理解を深めていくと良いです。
-
エンジニアにプロジェクトの目的を説明
- 誰が、何に困っているのか？
- 何を達成すればプロジェクト成功か？
- システムでやりたい事
-
実現したい事を図示
- 求めるビジネス要件（ユースケース図）
- システム導入後のフロー（アクティビティ図）
- その他「モデリング」と呼ばれる手法で情報整理
-
システムの完成イメージを描く
- 簡単な画面サンプルを描く（作図ツールを活用）
- 具合的な機能要件を洗い出す
- 大まかな開発スケジュール
ポイントはシステム開発に求めるビジネス要件をビジュアルで整理して、ビジネス・エンジニア両方の視点で検討漏れがいないのか確かめることです。
④提案フェーズ
提案フェーズでは名前のとおり決済者への提案を行います。
ここまでのフェーズで整理した情報を提案資料として説明すれば十分ですが、ただ説明しても「それで、何を決めたらいいの？」 と言われて終わりなので、３つの目的を意識すると良いです。
ポイントは、文字ばかりの資料ではなく、画面サンプルなどのビジュアルで説明する事です。
同じ完成サンプルを見ながらディスカッションできるので、「この部分は変更して欲しい」など具体的な要望を聞き出すキッカケになります。
また、提案フェーズでは最初に扱った 『思考タイプ別のコミュニケーション』 が効果的です。図のようにポイントを意識して 「決済者が好きそうな情報」 を準備しておきましょう。
⑤要件フェーズ
要件フェーズでは最後の仕上げとして、システムの明確な完成イメージを着地させます。開発する機能一覧を具体的に掘り下げたり、優先順位を整理します。システムに実装しないことを明確にすることも重要です。
ここまで整理すると、『①要望フェーズ』からスタートしたプロジェクト企画の一連プロセスが着地します。下図の「赤字で書いた部分」が、このフェーズで新たに作成する情報です。
意外に忘れがちなポイントとしては、システム実装をスタートする前に現場の方々などプロジェクトに関わる方に説明をしておくことです。もし叶えられない現場要望がある時には、できるだけ早期に共有しておくことが今後の関係継続で大切です。
さいごに
ここまで理解すれば 「プロジェクト推進を通じて、どうやって相手にとって気持ちの良いコミュニケーションができるか？」 の解決策が見えてきたと思います。
「３つの軸」を活用して、勘やセンスに頼らずロジカルに考えるコミュニケーション能力を磨いていきましょう。
まずは実践が重要なので、普段の会話から工夫してみると良いです。相手の反応が急に良くなったり、苦手だと思っていた人との会話が楽しくなったり、多くの変化を体感できます。
ネゴシエーションを活用して、皆さまのシステム開発プロジェクトが成功する事を祈っております。
最後までお読みいただきありがとうございました。
ーーー
P.S.
※SNSでも情報発信しています（Twitter：Saku731 ）