はじめに

今やアジャイル開発は社会的に十分認知された開発手法となりました。とはいってもウォーターフォールなどの従来型の開発手法がまだまだ多い状況です。これからアジャイル開発を導入しようとしている組織も多いことでしょう。
さて、実際に組織へアジャイル開発を導入しようとすると、そもそも組織が導入に否定的でうまくいかない、といった声もよく聞きます。アジャイルソフトウェア開発宣言^注1を見てみると、より良い価値のあるソフトウェアを作るしくみであることは説明されていますが、組織に対してどのようにアジャイルを導入するかまでは言及されていません。
本稿では、組織がアジャイル開発を否定的に考えてしまう原因と、それに対してどのように対策し、導入を進めていけばよいかを、具体例を示しながら説明したいと思います。

導入に否定的な原因

組織がアジャイル開発に否定的な理由を説明するうえで、次のような前提を考えてみます。あなたは自社サービスを提供している、ある開能性の問題まで、順を追って導入を阻む原因を説明します。

開発やビジネス上の危機感がない

アジャイル開発を導入したいリーダーのあなたが、上司にお伺いを立てにいきました。

リーダー「アジャイル開発を導入したいと考えているのですが……」
上司「そうはいってもだな、ウチは目標どおりの売上が出てるし、このやり方で今までうまくいっている。なのにどうして変える必要があるんだ？」

近年はビジネス環境の変化のスピードがとても速く、今の環境がずっと続くわけではありません。組織は常に危機感を持つ必要があり、その危機感がないというのは深刻なことです。
組織に危機感があれば、今のままではいけないという心理から、外部からの声に耳を傾けてもらいやすく、アジャイル開発のような新しい試みを導入する原動力になります。

変えることによるリスクを許容できない

アジャイル開発を導入したいリーダーのあなたが、上司に相談をしにいきました。上司はアジャイル開発の価値を知っている人物で、話せばわかってもらえるはずです。

リーダー「A案件のウォーターフォール開発をアジャイル開発にシフトしたいのですが……」
上司「君の言い分はわかるのだが、A案件のシステム開発は止められない。現状手一杯な状態なのに開発手法を変えるとなると、開発が停滞してクレームが来るだろう」

開発やビジネス上の危機感があるのであれば、ある程度組織は耳を傾けてくれるはずです。しかし、いざ導入を検討すると、組織を変えることによるリスクが存在することに気がつきます。
組織にリスクを許容してもらうことは、アジャイル開発の導入にとって最も困難な課題といえるでしょう。
リスクアセスメントという言葉は今や常識となっています。組織にとってリスク管理は重要であるがゆえに、アジャイル開発へのシフトが許容不可能なリスクとして認識される可能性があります。組織としてのリスクとしてはたとえば次のようなものになるでしょう。

アジャイル開発へのシフトは組織にとって大きな変化であるため、関係者の合意が必要となりますが、一部の関係者からは猛烈な反対を受けたり、質問攻めにあったりします。それらの関係者への説得は、難航して時間がかかってしまうのは明らかです。

実現できないと思っている

アジャイル開発を導入したいリーダーのあなたが、上司に提案を行いました。組織はアジャイル開発の価値とリスクを十分に理解していますが、まだ導入までには至っていません。

リーダー「品質管理部門に相談したところ許可を得られそうなので、A案件のウォーターフォール開発をアジャイル開発にシフトしたいのですが……」
上司「A案件をアジャイル開発にするのは難しいんじゃないか？　長年ウォーターフォール開発しかやっていないメンバーたちだし、やり遂げられるとは思えないんだが……」

危機感がありリスクも許容できる、となればアジャイル開発導入のゴールも近いのですが、「この組織では無理なのでは？」というありがたい意見をもらうこともあるでしょう。
耳を傾けると、「組織のさまざまなルールを変えられるのか」「誰が先導するのか、またそんな人材がいるのか」といった、実現可能性の問題であることが多いため、いくつかのアプローチを用いて実現可能性を示す必要があるでしょう。
以上、導入に否定的な理由について述べました。次節からは説得のアプローチについて、段階を追って解説します。

導入のアプローチ

前節で書かれたような障壁に対してどのようにアプローチしていけば良いでしょうか。状況に応じて適切な作戦を練りましょう。

誰を説得するべきかを特定する

アプローチを行う前に、誰を説得するかを整理する必要があります。極端な話、新入社員を説得したとしても、導入時には力にならなそうです。そのため、「この人が言うなら組織が動きそう」というキーパーソンを見極めるべきです。
あなたがすでに組織内の人物やその関係性を十分把握しているのであれば、誰がキーパーソンかわかるでしょう。しかし、そうでない場合は日々の会話の節々から人物を観察することで判断していきましょう。予算の意思決定者や、要件の意思決定者、システムの有識者などを把握しておくと良いでしょう。
また、アジャイルは、請負型の開発とは異なり、要件を考えるプロダクトオーナーが開発チームと協業する開発手法です。プロダクトオーナーはビジネス側^注2の組織が担うことが多く、その場合、開発組織だけではなく、説得相手にビジネス側の人物も含めなくてはなりません。
ターゲットを定めたら、アジャイル開発導入のためにキーパーソンを説得していきましょう。

危機感を持ってもらう

もし、キーパーソンに危機感がないのであれば、まずは危機感を持ってもらうためのアプローチをしましょう。業務を行ううえで、組織に対して「なぜこんなにのんびりしているんだろう、もっと危機感を持つべきなのに」と感じたことは少なくないでしょう。これはあなたが持っている情報と、組織が持っている情報に違いがある、つまり「情報の非対称性」から発生する問題なのです。あなたの持っている情報を組織に伝え、情報の非対称性を解消することで、あなたが感じている危機感を組織に持たせることができるのです。
そのためには、「メリット／デメリット」と「煽り」を使い分けるといいでしょう。たとえば、普段から話が通じやすくロジカルシンキングな相手であれば前者を、情報感度が低めで経験で物事を判断するようなタイプには後者を、というように、相手に応じて選択すると良いでしょう。

● メリットを論理的に、はっきりと示す

すでに世の中で語られている理論をベースに説得するやり方です。ここでは、アジャイル導入時によく使われる理論を紹介します。
ビジネス側の人物を説得する場合は、価値創造のやり方の違いにフォーカスすると良いでしょう。マーケットイン／プロダクトアウトという言葉を聞いたことはあるでしょうか。マーケットインは顧客のニーズに応じて開発・ビジネス展開を行う手法で、プロダクトアウトはサービスプロバイダの作りたいものを作ってから顧客を見つける手法です。ただし、顧客側もサービスプロバイダ側も正解（本当にほしいサービス）がわからない時代ですから、プロダクトアウトの考え方では時代にあっているとは言えず、アジャイル開発のしくみを活かし、顧客のニーズとサービスプロバイダの意向が合致するサービスを探しながら近づけていくことが重要であると言えるでしょう。
このような最先端の時代にマッチした開発手法である、という説得を組織が納得いくまで行いましょう。
開発側^注3の人物を説得する場合は、上記のマーケットイン／プロダクトアウトの話をしたうえで、プロジェクトの不確実性を説明すると良いでしょう。もし頻繁に要件が変わるとすると、計画を重視するウォーターフォールのプロセスでは、プロジェクトの計画も頻繁に変わり、プロジェクトが納期や品質、コストを守れなくなる可能性が高まります。アジャイル開発は、変更を前提にしたプロセスである、ということを理解してもらうことで、開発側としてもプロジェクトリスクが低減できると考えてくれるでしょう。

● 業界動向を使って煽る

業界動向による「煽り」は、日和見な組織にとって大きな効果があります。見えない部分で問題が進行し、そのうち大問題になってしまうかも、というリスクを提示するやや強引なアプローチです。いくつか例を紹介しましょう。
1つ目は、「競合と差を付けられてしまうぞ」と伝えて競争をうながす方法です。ライバル会社の先進的なプロセスを紹介して説得を行うと、身近な問題として受け取ってもらえるでしょう。
たとえば上司の返事に対して、このような説得を行います。

上司「そうはいってもだな、ウチは目標どおりの売上が出てるし、このやり方で今までうまくいっている。なのにどうして変える必要があるんだ？」
リーダー「大企業を中心にアジャイル開発導入が進んでいるというデータがあります。また、ライバルであるX社もアジャイル開発の専門組織を作るといううわさも耳にしました。周りが導入し始めている中、わが社だけ従来型の開発手法にこだわっていては、この先の競争に勝てないのではないでしょうか」

2つ目は、「従来型の開発手法は開発者にとっては化石のようなもので、キャリアアップにつながらない手法では優秀な開発者が逃げてしまうぞ」という考えです。技術力をアピールしている組織であれば、この手法が効果的かもしれません。
また、もしあなたがいわゆるSIerの立場であるなら、3つ目の方法として、「ウォーターフォールで人月商売していると先がない」と伝えることもできるでしょう。大企業からアジャイル開発案件が発注されることが増えてきているので、アジャイル開発が提案できないとそのうち仕事を取れなくなる可能性がある、というリスクを強調するのです。アジャイル開発の割合が増えている^注4 という情報は比較的集めやすいもので、説得力を持った交渉ができます^注5。
ある程度危機感を持ってくれる状態になれば、組織はあなたの話を真剣に聞いてくれるでしょう。アジャイル開発導入に向けての具体的な実行計画が見えてくると、それに伴うリスクが見えてくるはずですので、今度はリスクを許容してもらうために組織から不安を取り除くことが必要です。

不安をなくす

もし組織がアジャイル開発導入のリスクを認識し不安だと感じているなら、リスクを許容可能なレベルまで引き下げる必要があります。いくつか例を紹介しましょう。

● パイロットプロジェクトを使う

パイロットプロジェクトとは、新規プロジェクトを全面的に拡大する前に、規模を制限して新しいテクノロジや手法の実証と評価を先行的に行うことを目的としたプロジェクトです。これには、組織がリスクとして無視できる大きさで実験ができるメリットがあります。アジャイル導入のためにパイロットプロジェクトを立ち上げるのであれば、アジャイルに適した4～6人程度の規模で、失敗の可能性が低く、かつ開発部隊に裁量が任されているような自由度の高いテーマが好ましいです。
パイロットプロジェクトを運営しながら、アジャイル開発のノウハウをためつつ、ここで得た成功体験を組織に報告することで、実際には大変だったとしても、実証と評価を繰り返すことで実現の可能性が見えてくれば、アジャイルはけっして難しいことではないと組織に思わせることができます。

● アジャイルの有名人の招待

有名人の肩書きは、説得を行ううえで絶大な効果があります。とくにあなた自身にネームバリューがないと感じる場合は、外部に助けを求めるのが近道となるでしょう。現在ではアジャイル開発のプロフェッショナルを見つけるのはそう難しくないことです。たとえば、社内の勉強会やセミナーへ招待し、「あの人が言うのであれば安心できる」という空気を組織に取り込みましょう。

● 信頼貯金をためておく

信頼貯金、信頼残高という概念があります^注6。図1のように恩を売っておいて「貸し」をためた状態にしておき、重要な目的のために解放するというものです。信頼貯金があれば「キミが言うなら今回は許可しようじゃないか」という展開が期待でき、ある程度不安があってもリスクを許容してもらえる土壌を作ることができます。
組織にとってアジャイルの導入が高いハードルだととらえられているのであれば、信頼貯金をためるには時間がかかるでしょう。これまでにためた「貸し」がない場合は、日ごろから信頼貯金を蓄えるよう意識しましょう。

図1　信頼貯金と引き出し

実現可能であることを証明する

組織に危機感を持たせることができて、不安も取り除きリスクも許容できる、という状況になれば、次は実現可能性を証明し、具体的な実現イメージを共有していきましょう。
実現可能性に疑問を持たれているのであれば、それを払拭する必要があります。ケースに応じたアプローチを紹介します。

● 「机上の空論」だと言われる

理論上は可能だけど、いまひとつ確信が持たれていない、という状況であれば、まさにパイロットプロジェクトの出番です。前述したようにパイロットプロジェクトを立ち上げ、成功に導き、その成果をうまくアピールしましょう。

● 体制がない、人がいない

アジャイルの有識者が誰一人いない状態から、アジャイルチームを作るにはどうしたらいいでしょうか。育成のためにアジャイル開発を学習する方法はいくつかあり、外部の研修やアジャイルに関する書籍も多数あります。しかし、アジャイルは座学よりも実践が習熟への近道です。とにかく、チームを作り、テーマを見つけ、アジャイルを実践しましょう。そのときのポイントは次のとおりです。

● 組織が従来型開発手法に染まっている

従来型開発からアジャイル開発へのシフトは容易ではありません。ある程度の変化を許容できるのか、まったく変化を許容できないのか、組織の状態に応じてアプローチを使い分けると良いでしょう（図2）。

ある程度の変化を許容できるのであれば、既存の業務へ徐々にアジャイル開発の要素を取り入れる方法が使えるでしょう。筆者の過去の経験では、導入によるメリットがわかりやすい試験自動化や、インフラのクラウドへのリフトアップなど、従来型開発でもアジャイル開発でも両方使えるやり方から採用していくと、組織の拒絶反応も少なく、スムーズにアジャイルへ移行することができました。
組織がまったく変化を許容できない場合は、従来型開発の文化・プロセス・ルールを無理に変えようとせず、既存の組織とは別にアジャイル開発専用の組織を新しく作ってしまうのが良いでしょう。新しい組織は、アジャイル型の文化・プロセス・ルールを持ち、それに順応できる人材のみを所属させます。最初は、少人数の組織かもしれませんが、既存の組織からの異動や、新規採用などで徐々に人材を増やしていきましょう。
実現可能性が証明できれば、説得にあたってもはや阻害はないと言えるでしょう。あとは組織にアジャイル開発を浸透させていくだけです。

図2　アジャイルへの移行方式

さいごに

うまく最初のアジャイルをあなたの組織に導入できたとしても、それが拡大・継続できるかどうかはまた別のテーマです。順調に拡大していけば、いずれは1つの組織だけでなく、会社全体の文化やルールを変えなくてはならないでしょう。一方、アジャイルの目的をはき違え、形骸化してしまうかもしれません。
導入して終わりではなく、導入後もあなたがアジャイルに対する熱意を持ち続けて、組織を変え続けることが必要でしょう。

アジャイルコラム記事一覧

https://www.intellilink.co.jp/column/agile-devops.aspx