BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース ビジネスとITの協力を改善する方法

ビジネスとITの協力を改善する方法

ブックマーク

原文(投稿日:2013/06/06)へのリンク

ビジネスとITの協業は企業にとって問題になる可能性があり、今、さまざまな改善方法が模索されている。例えば、ビジネスとITを融合した事業体を構築して、ITのビジネス価値を向上させる。あるいは、DevOpsは開発と運用が一緒になってビジネスのニーズを支援する試みだ。また、組織内のコミュニケーションを可視化するためにソシオグラシーを利用し、ビジネスの利害関係者とアジャイルチームを結びつける。

David Ramel氏はApplication Development TrendsでForresterの調査がビジネスとソフトウエア開発の連携が弱いことを明らかにしたことについて書いている。

大きな障害のひとつは、成功しているソフトウエア開発プロジェクトは企業の文化であり、結果、協業が欠如してしまうことです。なぜなら、ビジネス側の幹部はIT部門を"注文取り"と見なしているからです。しかし、この見方はITリーダーには受け入れられません。

どの程度協力すればいいかについてもビジネスとITの間に認識のギャップがある。

43%[ビジネスの意思決定者]はITとビジネスが協力するのは、どのサービスや製品を提供するのかを決めるためだと答えています。

59%のIT/エンジニアリーダーがビジネスと協力しており、57%がITはパートナーとしてビジネスの利害関係者と共に意思決定に参加すると答えています。

今年のはじめ、InfoQはForresterによる継続的デリバリによるイノベーションの促進の研究を取り上げた。登録をすれば、Forresterのこの研究の報告書をダウンロードできる。この研究結果で推奨されていることのひとつは、“ビジネスリーダーとITリーダーは協力関係を改善する必要がある”ということだ。

(…) 従来のビジネスは組織のモデルを変え、ソフトウエア開発者を注文取りとしてではなく、パートナーとして見る必要があります。IT部門も組織を再設計し、エンドツーエンドのサービス提供に注力する必要があります。

Michael Maurer氏はbusiness IT fusion requires true collaborationと題したブログ記事でビジネスとITの協力について書いている。

ふたつ以上があつまってひとつの事業体を作った結果、融合が生まれます。ビジネスとITがひとつの事業体になったのを見たことがありますか。

ITは独立した部門として組織され、“ビジネスと融合”していない場合が多く、協力が難しい。

しかし、ITはビジネスをサポートすると考えられているため、サプライヤとして扱われます。ビジネスパートナーやビジネスに不可欠な部門として扱われません。ビジネスのマネージャはクライアントとして振る舞い、ITがサプライヤとして扱われるのです。

Michael氏は組織は協力体制を改善し、ビジネスとITの融合を推し進めるべきだと考えている。

まず、ITを独立した特別な機能と考えるのではなく、ビジネスの一部として認めることから始めるべきです。ビジネスのマネージャはITのマネージャでもあるのです。ITはより深いユーザ理解に注力するべきです。ビジネスの理解や、ITがビジネスに対してどのように良い影響を与えられるかをしっかりと理解する必要があります。ビジネスとITが双方とも、優れたITを持つことの責任を共有する必要ああります。

Kevin Parker氏はアジャイルやコラボレーションについて自身の考えをhow can you use agile to put a stake in the groundと題したブログ記事に書いている。氏は自身が見た、全体のプロセスの小さな一部しかカバーしないアジャイルの実践の問題を説明している。

アジャイルは組織に素早く価値を提供するよう設計されています。しかし、アジャイルプロジェクトは独立して存在しているのではありません。ITが何を作ればいいのか理解していなかったら、あるいは、ビジネス側がどのようにアジャイルプロジェクトに関わればいいのか理解していなかったら、目標を達成できないでしょう。

Kevin氏は、頻繁なリリースを行っていない場合、アジャイル開発チームを使ったソフトウエアの提供は、ITの生産性にとって障害になるという。DevOpsは開発と運用の協力をサポートするが、ビジネスのニーズもサポートする。

リリース管理のような困難を解決するのは、開発チームにとっての優れた手法としてのアジャイルと、ビジネスを変える競争差別化要因のアジャイルとの差異なのかもしれません。DevOpsの動きはアジャイルに存在する問題を引き受け、文化と理解が優れたビジネス価値をどのように導くかを見据えています。

“大きく複雑なプロジェクトを持つ組織はアジャイルの導入に苦しみます”、とDerwyn Harris氏はuse sociocracy to scale agile organizationallyと題した自身のブログ記事で書いている。組織が独立して働くアジャイルチームを作った場合、ビジネスとITの間の連携は生まれない。このような場合、ソシオクラシーの概念が問題の解決に役立つ。

ソシオクラシーは重複する“サークル”や“ダブルリンク”を作成することで組織にコミュニケーションチャンネルを合理化する能力を提供します。サークルはスプリントのように目的に対してのみ責任を持ちます。ダブルリンクは重複したサークルの代表が存在することを保証します。これは、単にひとつのサークルにひとりのマネージャを配置するということではありません。ダブルリンクは情報の欠如や混乱が発生することなく、コミュニケーションと意思決定が素早く行われることを保証します。

Derwyn氏はソシオクラシーを使って組織のコミュニケーションを可視化する方法を説明する。

組織内のサークルを書き出してみるのが良い方法です。(…) そして、どのようにコミュニケーションしているかを関連づけ、誰がダブルリンクを表現するのか決めます。多くのサークルでひとりがシングルリンクになっていたり、まったく重複していない場合もあるでしょう。このような状態がコミュニケーションの失敗を生みます。アジャイルが失敗する第一の理由です。

この記事に星をつける

おすすめ度
スタイル

BT