分散開発管理のポイント

3. 真っ先にすり合わせるべきこと |

4. 拠点間のコミュニケーション管理

拠点間の関係性を管理する

開発の発注者が各拠点間のコミュニケーションを常にウォッチして、コミュニケーションに問題がないかを管理するということは、あまり現実的なことではないでしょう。そのような管理を行うためには、コミュニケーションのウォッチに膨大な時間を費やさなくてはならなくなってしまいます。ですので、日常的なコミュニケーションはある程度は開発者側に任せるということが必要になるでしょう。では発注者が行うべきコミュニケーション管理とは何かというと、各拠点間の関係性の管理です。

コミュニケーションとは、人と人、組織と組織の間での情報のキャッチボールです。当事者同士が互いにきちんと向き合っていなければ、キャッチボールは上手くいかなくなってしまいます。拠点間で摩擦が生じて関係が良好ではなくなってしまうと、コミュニケーションに支障をきたすようになります。したがって、拠点間のコミュニケーションを良好に保つためには、拠点間の関係性を良好に保つ必要があると言えるでしょう。

単なる拠点間の意見の不一致と摩擦の違いが何かというと、摩擦の方は何らかの感情的なすれ違いが生じている状態です。開発への参加者(各拠点)はプロフェッショナルとしての意識を持って開発に参加していますので、通常は各拠点の間で決定的な対立が生じてしまうということは滅多にないでしょう。ですが、何となく関係がぎくしゃくした状態になってしまうということはときにはあるのではないでしょうか。決定的な対立は論外ですが、関係がぎくしゃくしているといった程度の状態であってもコミュニケーションには良い影響を及ぼしません。

設計思想の不一致を解消する

拠点間に生じる摩擦は感情的な側面を持っていますが、摩擦の原因が単なる感情的な衝突のみであるケースはむしろ稀なのではないでしょうか。ほとんどの開発者はプロフェッショナルとしての自覚を持って開発に参加していますので、何もないところで感情的な衝突を起こしてしまうような開発者はあまりいないと当サイトは信じています。ですので、拠点間で摩擦が生じかけている、あるいは生じてしまったという場合には、感情以外の何らかの問題が裏に潜んでいる可能性について考慮することを当サイトはお勧めします。

摩擦につながりがちな問題の一つには、設計思想の不一致があります。[設計思想をすり合わせる]で説明しているように、設計を行う際に基本となる考え方・方針=設計思想にはいくつかのタイプがあります。拠点間で前提としている設計思想が異なると、意見の不一致が生じるのみならず、お互いに何を主張しているのかが理解できずにコミュニケーションがすれ違うようになります。このとき、当事者同士は設計思想が一致していないために話がすれ違っているのだということを自らは認識できないものです。設計思想は各開発者が長年の開発経験を通じて無意識に身につけていることが多く、設計思想という概念があって異なる設計思想が存在するということすら意識できないことがほとんどでしょう。ですので、拠点間で設計思想の不一致がないかを十分に注意し、不一致がある場合には設計思想のすり合わせを仲介することが大切になります。

隠された利害の不一致を解消する

もう一つ摩擦につながることの多い問題として、拠点間の利害の不一致があります。これは当たり前のことじゃないかと思われるでしょうが、さほど単純ではないケースも多々あります。というのは、技術的な意見対立の裏側に利害の不一致が隠されている場合があるからです。開発というのは共同作業ですから、各拠点が表立って自身の都合(利益・不利益)を表明することがはばかられる雰囲気になることも少なくありません(日本的文化の影響もあるのでしょう)。そういった場合に、表面上は単に技術的選択に関する意見不一致であっても、実際にはどのような選択を行うかによって生じる利害が本質的な問題であるということが起こり得るのです。

例えば、こんなケースが考えられます。

システム設計を担当するA社とノードXの開発を担当するB社との間で、設計方針に関する意見の不一致が発生しています。A社は「列挙型設計」を行うことを主張し、B社は「ポリシーベース設計」を主張しています(列挙型設計とポリシーベース設計については[設計思想をすり合わせる]を参照してください)。それぞれが自信の主張の技術的なメリットと他方の主張の技術的なデメリットを叫び、お互いに譲る気配を見せません。

これは一見すると技術に関する意見の不一致ですが、実は裏には次のよう双方の利害が隠されているかもしれません。

システム設計担当のA社は、発注金額に対して少し人手が余り気味で、次期開発の契約の際に発注金額を減らされてしまうことを心配していました。そこで、必要な工数が多めになる「列挙型設計」の方がA社にとって都合がよかったのです(※列挙型設計には列挙型設計のメリットがありますので、A社は自社利益のために好ましくない設計方針を主張しているというわけではありません)。

それに対し、ノードXの開発を担当するB社は、発注金額に対して少し人手が不足気味であることが見えてきていました。そこで、B社としては何とか開発工数を減らしたいと考えていて、「ポリシーベース設計」に持ち込みたい状況にあったのです。

このような状況では、A社とB社の間の技術的な議論のみで意見対立が丸く収まることはあまりないでしょう。一方が他方を押し切るかたちで方針が決まってしまうと、それは拠点間の摩擦へと発展してしまう恐れがあります。ここでは、両社が腹を割って利害調整のための話し合いを行うか、発注者もしくは開発全体の管理者が両者の利害を理解した上で方針の決断を行うかが必要になるでしょう。いずれにせよ、発注者や開発全体の管理者の仲介が望まれる状況です。

無料小冊子のお申込みはこちら

株式会社システム計画研究所のオフィシャルサイトはこちら

通信・ネットワークシステム開発に関するご相談はこちら

サーバ監視・ネットワーク監視ツール isNetSentry-S のサイトはこちら

信頼できるITシステムの開発と利用を支援する技術情報提供サイト「信頼のシステム開発.COM」はこちら