ITコミュニケーション上でよく聞かれる８つの (困った) 言い草とその対応策

どんな組織でも、ちょっとした対立や論争というものは避けられません。権力闘争につながったり、特定の個人に嫌悪感を抱くようになったりするネガティブな衝突は論外ですが、健全な論争はITコミュニケーションを改善し、部門全体がお互いへの信頼感でつながることに結びつけられる可能性があります。以下で、論争のもとになる典型的な言い草と、それにどう対応するのがいいかを考察します。

1. 「でも、これが我々のトップ・プライオリティだから」

開発、ネットワーク、システム、セキュリティ、サポートなどのそれぞれの部門は、目的やプライオリティが異なるため、IT部門では常に何を優先すべきか調整する必要があります。DevOps はどこからでも書き込みと共同作業ができる柔軟性を求めますが、セキュリティ担当者はしばしばこの自由を制限するロックダウンされた開発環境を求めます。

対処方法：ITの優先順位は状況によって変化し、砂の中に恒久的な線を引くことはできません。会社の wiki や Kona などのアプリを使って社内ソーシャルネットワークを樹立すると、ITコミュニケーションの流動性を維持し、部門での優先順位の変更やプロジェクト状況の更新があった場合にリアルタイムでコミュニケーションできます。遠隔地のメンバーともリアルタイムで最新情報を共有できるなど、社内ソーシャルネットワークはメリットがたくさんあります。

2. 「私の上司でもないのに」

「The Accidental Successful CIO」のブロガーであり、GSL Solutions の製品管理副社長である Jim Anderson 博士の観察によれば、IT部門の衝突は、誰が誰に何をするよう指示する権利があるのか、といったことに起因するものが多いようです。博士は、「最初の兆候は、2人の間で交換された一連の電子メールのコピーを受け取り始めたことでした。」と、2人の部下の間のなわばり論争について説明しています。「私にCCでメールが届き始めたという事実は、状況が良くないという最初の手がかりだったはずです。」

対処方法：社員が自分の業務の範疇に関することを指摘するような受動的に見えて攻撃的な電子メールや発言に注意してください。対立を早期に突き止め、言い争っている社員同士を同席させて、誰がどのタスクとプロセスの責務を担うのかを明確にします。

3. 「遅いチームには所属したくない」

システム管理者が関与するチームは、特にソフトウェア開発の場合、進行する速度が違うことがあります。「高速」チームは製品を少しでも速く市場に出そうと意欲満々で、「低速」チームは帯域幅を監視したり日常のメンテナンスを確実に実施することを目指します。

CEBの米国IT担当マネージングディレクターである Jaime Capella 氏が指摘するように、遅いチームに所属したいと思う人はいません。「高速チームを作り、響きのいい名前をつけて、新しいオフィスをあてがいます。」と彼はCIOを集めたクラスで説明しました。「彼らは注目を集め、上級管理職からも多くの称賛を得ます。ですが、その後、絶望の谷が待っています。」高速チームは単独では業務を達成できず、低速チームやその他の部門の協力が必要ですが、華やかな高速チームに対する羨望はモラール問題を引き起こします。

対処方法：速度の違う2種類のITを作らず、情報セキュリティのような優先度の高いタスクを中心に組織全体が寄与する適応型アプローチを採り入れられないか検討します。高速・低速の2種類が避けられない場合は、メンバーを入れ替えて全員が両方を経験できるようにする体制を整えます。二元論は（特にIT外の人にとっては）便利で理解もしやすいですが、すべてのITチームは優先順位の変更に応じてペースを調整できる必要があります。

4. 「私の仕事はこれ、あの人は何でも」

ITスタッフの中には、自分の仕事だけに固執する人がいます。反対に、依頼があれば何でもやり、部門の普遍的なリソースとして頼られる人もいます。注意したいのは、自分の仕事にフォーカスする人が常に利己的だったり怠け者だったりするわけではなく、何でもする管理者が必ずしも仕事をうまくまとめられなかったり、こなし切れなかったりするわけではない点です。

対処方法：誰かが多方面からの依頼が多過ぎて動きがとれなくなった場合は、チームの残りのスタッフが協力できるか、または依頼そのものが正当に必要なものなのかどうかを検討してください。自分の仕事にフォーカスしていた人が協力したり、何でもする人が一歩下がって配分を見直すことも重要ですが、最終的には技術部門トップの判断で増員しなければならないこともあります。

5. 「それは我々のやり方じゃない」

それぞれ独自のコミュニケーション方法を培ってきた2つのIT部門を統合する場合は、問題が生じがちです。それまでとは異なる規範にぶつかり、自分のこれまでの仕事がなくなってしまうのでは、と心配します。

対処方法：リストラの際の偏見をなくし、スムーズな統合を行うには、コンサルタントを招くことも一つの方法です。それが不可能であっても、統合を開始する前に、部門のコミュニケーション方法を再確認することは大切です。2つのIT部門の統合にあたって、新チーム結成イベントに全員が参加できるようにしてください。例えば、ボウリング大会や食事会で友好関係を育むようなことが考えられます。

6. 「あの人、信用できるの？」

会議の場では納得したように頷きながら、その場にいなくなった途端に他の人に不平を言う人がいます。そのような人には、意見表明を阻止しようとしないのが得策です。代わりに、自分のメモとして不一致があったと記憶しておきます。

対処方法：Brian Robertson 氏が提唱するホラクラシーという経営哲学は、会議の時間を意見の不一致や「テンション」に対処するために使うことを控えるように勧めています。対人関係の紛争ではなく、運用面に集中するようにし、暗黙の緊張を背後で煽るようなことは決してしないでください。

7. 「私がしたことじゃありません」

依頼されたことを文字通り正確に行ったと考えているために、ミスを犯したことに気付かないシステム管理者もいます。ミスを犯すことはこれまで懸命に努力して獲得した地位とIT部門のメンバーからの敬意を失うことになるので、自分を守るためにこのような発言をする人もいます。

対処方法：良好なITコミュニケーションが行われていれば、適切なミスを犯すことは奨励されるべきものであることを再確認します。より大きな目標を追求するための創造的なアクシデントは、イノベーションへの礎石になり得ます。人々に実験の機会を与えるハッカソンのようなものに相当するとも言えるかもしれません。チームを牽引する独創力を賞賛することで、より優れたサポートを行えるようになります。

8. 「私が若かったころは…」

年配の経営幹部は、変化を受け入れることを好まないかもしれません。IT部門の仕事は、獲得すべきスキルの必要性を伝えることです。

対処方法：従業員に訓練の機会を提供し、継続的な訓練のために予算を割り当てます。現従業員のスキルを向上させることは、スキルを持った社員を新規採用するよりも簡単（そして低コスト）です。

ITは技術的レベルが高く、個性的な人も多いですが、ときどきみんなで楽しい時を過ごすことも大切です。少々はめを外すことで仲間意識が醸成され、対人関係の壁を崩すことも可能かもしれません。