The Dragon Scroll

Be just and fear not.

コミュニケーションレスが招くデスマ。

デスマに至る要因として考えたのが、次の二点。

本日は、後者の方について考えて見ます。


プロジェクトに関わる人々をあげてみましょう。
まずは、顧客。
一口に顧客とっていも、様々ですよね。

  • 情報システム部
  • 企業内のエンドユーザ
  • BtoCにおける、エンドユーザ
  • 企画部
  • 経理
  • 経営層

etc


開発するシステムのタイプや目的によって、
顧客層も多岐に渡ります。
ここが、ひとつ厄介な問題を引き起こすところ。
顧客内での、部門間の壁は往々にしてあるもの。


次に、開発側。

  • プロジェクトマネージャ
  • プロジェクトリーダ
  • サブリーダ
  • SE
  • PG
  • テスター
  • 協力会社
  • 営業

etc


こちらも、プロジェクト体制によって、様々なステーク
ホルダーを列挙することができます。
設計工程までは、元請企業が担当し、協力会社さんには
開発以降をお願いするケースや、設計工程からお任せする
ケース。ケースによって、それぞれの立場が果す
役割も異なります。


これらの多様な人々が関わる、開発プロジェクトにおいては
コミュニケーションレスが命取りになります。
「あれ?これ言ってなかったけ?」なんて言葉が、
出てくること、心臓が打つ音がもう一気に加速しだします。


コミュニケーションを考える上で大切なのは、合意が
できているかです。
コミュニケーションには段階が存在します。
まずは、一方通行の"連絡"。メールを送って、相手に
情報を伝える。
これでは、不十分で、果たして、相手に伝わっているか
確認をする必要があります。伝わっていれば、"着信"された
状態。当然、相手側に伝えた情報を、理解してもらって
始めて"着信"です。
理解はしてもらえたが、何故か一向に話が進まない
ケースがあります。これは、"合意"にまで至っていない
ということ。


例えば、とある画面のUIを決める上で、相手に案を提示し
その決定を依頼する場合。
当然、決定の期限を切りますが、相手が平気で、
その期限を守らないことがあります。
これは、期限が守られないことで、如何に開発に影響するか
そして、それがプロジェクト全体にどのように影響するか
を理解してもらっていないということです。
そして、期限が守られない以上、相手側にも
その責任を担ってもらう必要があります。
そこまで、理解してもらって、それに対する"合意"を
得ていなければなりません。


開発における、コミュニケーションとは、この"理解"と"合意"を
ステークホルダー間で確実に取ることだと考えています。


しかし、これが難しい。
特に合意を形成することが難しい。
この点については、ファシリテーション等がその一助と
なると思います。
合意を得るためには、相手のことを理解しなければなりません。
立場や、思考や、状態を把握することです。
そして、実際には、個人ではなく集団で物事を決めることが多く、
そこでも合意を形成しなければなりません。


要件定義でもそうですが、やはり丸腰で事に挑むのは
厳しいでしょう。
如何に、"備え"を作っておくかが重要と考えています。
それは、SIerが全社レベルで考えておかなければならない
ことでもあるでしょう。