この記事は、Magdalena Firlit さんの「Product Delivery – when Business and IT are talking」を翻訳したものです。翻訳は Magdalena さんの許諾をいただいています。誤訳、誤字脱字がありましたら、ご指摘ください。
はじめに
部門間の対立や部門による異なる目的に直面することがよくあるでしょう。もし直面したことがないようでしたら、たぶん健全な環境下で、有意義で、共通ゴールがあり、真のリーダーがいるのではないでしょうか。おめでとうございます！ぜひ続けてください！もし、このようなことに直面したことが「あるある」、「たまにある」、「いつもそうだ」と思ったならば、この記事が役に立つと思います。
何が問題なのか？
多くの組織でコーチングしてきました。何十もの組織で、数千人もの人たちに教えてきました。そのうちの70%がIT部門（デリバリー部門や技術部門などと呼ばれることもあります）とビジネス部門（プロダクト部門、マーケティング部門、営業部門など）の間には依然として困難な状況があると言っていました。両者は、よく納期遅れやスコープのミスという相互非難によって悩みを抱えています。ときには、仕事の進め方やプロセスに関して、これらの部門間で多くの誤解が生じることがあります。ビジネス部門は、ソフトウェア開発やエンジニアリング作業の複雑さを理解できていません。またその逆も然りです。技術部門は、顧客と接しているチームであるビジネス部門に共感することに苦労をしているでしょう。彼らの仕事が如何に大変かを理解できていないのです。
異なる期待値とゴールが、信頼性の欠如、協働の欠如、そして全体的な課題の原因となる対立を引き起こすことになります。このような環境下で仕事をし、共同作業をするのはフラストレーションが溜まることでしょう。私も昔、何年も前の会社員時代に何度か体験をしたものです。ある組織では、その正反対で、関係者間で協働を深めていったこともありました。この組織では何が異なるのでしょうか。これについて後述します。
どう共存するのか？
ビジネス部門であれ、技術部門であれ、まずは取り組みを始めることです。私たちは、よく他の部門が動くのを待ってしまいますが、待つ必要はありません。取り組むのが得策なのです。
経験上のいくつかの提案を以下に示します。これらは、意図的に順序立てられています。もしあなたが、Cレベル（CxO）や部門長クラスの役職に就ているのであらば、この困難を克服するのは比較的容易です。もし一般社員から生じた取り組みであったならば、その行動を支援しましょう。もし、大きな組織だから力がないと難しいと感じられたら、意思決定者の強力な支援を探しにいってみてください。彼らと関わる努力をしましょう。
ステップ
「相手の状況を理解し、語り合う」から始める
会話をしようとするときは、相手の視点に共感し、理解しようとするのを同時にしたときに有益になることがわかっています。
以下の質問に答えてみてください:
- なぜこのような状況になったのでしょうか？
- 何がその原因だったのでしょうか？
プロセスでしょうか？文化でしょうか？過去の遺産（レガシー）や古い構造や仕組みでしょうか？ - このとき、彼らはどのように感じているのでしょうか？彼らはこの状況や私たちについてどう考えているのでしょうか？
同時に、会話の中で「私たち vs 彼ら」になることを避けるよう提案したいです。ここでは誰が誰なのかを強調するために「彼ら」「私たち」とあえて表現しているのです
これらを踏まえて会話を始めてみてください！
信頼してもらうよう取り組む
信頼の欠如は、組織やチームにおいて最もよくある機能不全1です。ここで提案したいのは、信頼してもらうように取り組むということです。あなたの部門やチームが信頼できるということを示しましょう。他部門にいるパートナーやステークホルダーを巻き込んで、プロダクトについて協働したり、相互フィードバックを共有したりを頻繁に行っていきましょう。
共通のゴールを持とう
「共通のゴール」という提案は、最も重要なものの一つです。部門間で議論される課題に関して、共通の目的が画期的な変化をもたらすかもしれません。
部門間で、集中するための共通で単一のゴールを作ってみましょう。このゴールは、有意義で計測可能なものでなければなりません。同じプロダクトに共に取り組むのであれば、「プロダクトゴール」を作ることをお勧めします。あなたがプロダクトオーナー（もしくは、あなたのプロダクトにおいてこの責任を持つ誰か）である場合、この取り組みは、プロダクトに関する意思決定者である人から出してもらうべきです。
プロダクトゴールの設定については、こちらの記事をご覧ください。
エビデンスベースドマネジメント（EBM）〜 共通のゴールに向けた共通の計測指標
ゴールを決めることができたら、進捗状況を定期的に計測することが重要です。計測可能な指標を用いることで、早い段階で目的に関する仮説を検証し、素早く検査と適応を行うことができます。
計測可能なゴールでないとどのように達成したかを判断できなくなるでしょう。例えば、次のようなゴールがあったとします。
顧客満足度の向上
これは、どれくらいか、計測可能ではありません！
次の例を見てください:
顧客満足度を25％向上させる
必要に応じて時期を特定するのも有用です。例えば、「今期末までに」などです。
指標はステークホルダーと共に設定するようにしましょう。そうすることで、透明性が高まり、信頼も高まります。そして、同じ「計測可能な」ゴールに向かってより効果的なコラボレーションが実現するのです。
「定期的」ということを覚えておいてください。細やかに確認するのがよいです。
EBMについての多くの事柄を記事やビデオとして公開しています。これらはこちらからご覧いただけます。
Magdalena Firlit さんの記事の多くを本サイトでは日本語翻訳しています。こちらも併せてご覧ください。
スプリントレビューを活用する
あなたがプロダクトオーナーあるいは、スクラムチームのメンバーであったならば、部門間の橋渡しをする別の機会を用いることもできます。それはスプリントレビューにステークホルダーを招待することです。彼らにスクラムチームが作成したものについてのフィードバックを求めてください。計測指標やゴールを一緒に見たり、将来を見据えたりもしましょう。
訳註: スプリントレビューを本来の意味で実施しましょうという著者からの提案ですね
プロダクトバックログリファインメント活動
場合によっては、プロダクトバックログリファインメントの活動にステークホルダーを招待することも役に立つことがあります。主に、「どうして？（WHY）」と「ビジネスにとって」のリファインメントのために、ステークホルダーを巻き込むのです。一緒にペルソナを作り、実験をデザインしましょう2。ビジネスと顧客のニーズについて議論を尽くすことで、相互認識と透明性が生まれます。
まとめ
ビジネスとITの架け橋となり、課題を克服できるかどうかは、あなた次第なのです。信頼で安全な環境を築き、ステークホルダーと共に、共通のゴールと計測可能な指標に取り組み始めてください。お互いを理解しましょう。異なるバックグラウンドや異なる視点を持ちながらも、同じプロダクト、同じゴール、同じ顧客を満足させるのですから、これは実に「完璧」なことなのです。
- Patrick Lencioni, Overcoming the Five Dysfunction of a Team, 2005 ↩︎
- 詳細は、「実験するのはなぜか？」をご覧ください ↩︎
本記事の翻訳者:
長沢 智治 – アジャイルストラテジスト
サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。
『More Effective Agile』、『Adaptive Code』、『今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。
