- 講演資料：エンプラアジャイル導入の守破離
アジャイル導入・浸透に有効なPivotal Labの「Lean XP」
オープンソースのCloud Foundryプラットフォームを商用化したサービスで知られるPivotal。PaaSや開発支援ツールなどの提供だけでなく、リーン＆アジャイル開発の導入支援を行う「Pivotal Labs」も提供している。その手法は、単なるコンサルテーションではなく「素早く、持続可能な形で開発する方法を、顧客企業とともに実践しながら伝授・浸透させる」というものだ。
これを実現するためのポイントがいくつかあると、安西氏が説明した。
1つめのポイントとなるのが「バランスチーム」だ。「バランスチーム」とは、ユーザーを理解する「デザイン」、技術を理解する「デベロップメント（開発）」、ビジネスを理解する「プロダクトマネジメント（PM）」の各役割で構成される4〜5名のチームで、それぞれの立場で視点を出し合い、協力し合った時にいいプロダクトが生まれると考えられる。
そして2つめのポイントとして、「バランスチーム」を顧客企業とPivotalの両方で組織し、役割ごとにペアになって一緒に作業を行うことがあげられる。顧客側のメンバーがPivotal Labsに派遣される形で入り、4〜5か月間、同じ空間で密接にコミュニケーションを取りながら仕事を進めていくというわけだ。
Pivotal Labsではこの手法を「Lean XP」と呼んでいる。PMは「リーン」で実装と検証を柔軟に繰り返し、デザインは「ユーザー中心設計」で行われ、そしてデベロップメントはアジャイルの一手法である「エクストリームプログラミング（XP）」を実践していく。朝会の後にペア作業に着手。ランチを挟みペア作業を継続、そして18時には仕事を終えて退社するといったシンプルなスケジュールとなっている。
失敗でトラウマに！「アジャイル“あるある”物語」を回避するために
ここで、小俣氏から「とあるアジャイル導入体験談」として、エンタープライズでのアジャイル導入の際に“よくある”ストーリーが紹介された。
ある日、本を読んだり、経営者セミナーに出席したりした担当役員から「アジャイル開発がいいらしいね」とミッションが落ちてくる。それを中間管理職が引き取り、「若手チームで予算は組まずに」と勉強会から始めるよう依頼されるが、担当者はよくわからないまま、スクラムの本を読んでみたり、インターネットで他社の事例を調べてみたりしながら、「とりあえず何か作ってみよう」と始めてみる。
しかし、本のとおりにやるのは簡単ではないことに気がつく。ユーザーリサーチや新しいツールの導入にはコストや時間がかかり、プロダクトは何をどこまで自分たちで決めて良いのかわからず、ものを作っている時間が少ない。スペースは確保してもらっているのにディスカッションが多く、周りからは遊んでいるように見えてしまう。
そして数か月後に突然「成果を見せてほしい」と、あるウォーターフォールで開発中の部門を手伝うように言われ、アジャイルでやろうとするが、プロジェクトリーダーには「仕事は遅いし、やり方に従わないなら出ていってほしい」と怒られてしまう。そんなふうにして、社内の中でチームが潰されたり、成果が出ないまま肩身が狭い思いをしたりする……。
まさに“あるある”なストーリーだが、果たしてアジャイルを導入し、浸透させることなどできるのだろうか。その問いに答えるのが、「プロセス・チームフィット」「プロセス・カンパニーフィット」「スケール」による導入ステップだ。つまり、チームから適応範囲を広げて、全社に浸透させていくわけである。
その重要ポイントについて、小俣氏は次のように語った。
「アジャイルチームの成熟には時間がかかるため、焦るがあまりに未熟なうちに重要なプロジェクトを任せて失敗することも少なくない。それがトラウマになることもあるため、チームを守りながら成長させていくことが大切だ。つまり、アジャイルの価値を証明して社内の信頼を獲得するまで、チームを守るコミットをする必要がある。そのためには、失敗を許容できるようなセットアップで初めて成熟に合わせて負荷をあげていく。また、会社ごとにビジネスや制度、人なども異なるため、進め方に絶対的な解はない。他社の事例をまねるのではなく、自社に合うやり方を模索する必要がある」
チームから全社へとアジャイル開発を浸透させるための3ステップ
チームから全社へとアジャイル開発を浸透させるための3ステップとはどのようなものなのだろうか。
まず「プロセス・チームフィット」では、チーム自身がプロセスの価値を実感し、自信を持てるまで守ることが重要だ。そのためにはチーム自身がプロセスの価値を実感することが必要であり、社内の業務改善やサービスなど小さな成功事例を生み出すことが有効だ。そうすることで社内の賛同者・支援者を獲得し、「遊んでいるように見えている人たち」から「新しい取り組みを実践しているマジョリティ」となっていく。
これを実現するために乗り越えるべき課題として、「チーム自身がアジャイルの価値を実感して言語化できていないこと」「ステークホルダーを動かすための論理や事例がないこと」、そして「アジャイル開発のやり方がわからないこと」があげられる。
そして、“あるある”のリスクとしては、「成果が出ていない期間にチームが潰されてしまうこと」「社内に人材や方法論がないために、誤った実践となり、従来との違いがわからなくなること」「ウォーターフォールの一部をスクラムでやることで失敗すること」、そして最も怖いのが「失敗が組織的なトラウマ体験になって、導入が遠回りになってしまうこと」だという。
この対策としては、プロセスの価値を実感して小さな成功体験を生み出すことが何より重要である。それに集中するためには、新規事業や社内の業務改善など、チームでコントロールできる、失敗の影響が少ないスコープで試すことだ。当然ながら、ビジネスクリティカルなものは避ける方が望ましい。また、チームを信頼して野放しにしてくれるスポンサーをつけることや、アジャイル開発の経験がある人を採用するか、外部人材を頼ることも有効だろう。この人材提供においてPivotal Labsは大いに貢献できるという。
そして、チームが自信を持って取り組めるようになってきたら、次の「プロセス・カンパニーフィット」のステップへと進む。ここではアジャイル開発の社内導入ロードマップに合意した上で、従来の方法とのすみ分け・使い分けや、稟議・人事など必要な社内制度の変更に着手する。そして、チーム規模と適用範囲を広げ始めるというわけだ。
課題としては、「アジャイルの適用範囲をどこに拡大するか」、そして「チームの拡大と開発のバランスを取ること」があり、そのためには「社内の啓蒙活動」や「教育コストとチームの生産性のトレードオフ」について考える必要がある。また、「稟議や人事評価などの社内制度の検討」も重要になってくるだろう。
ここでのリスクは「急拡大させてチームが回らなくなること」や「メンバーの成長よりも開発を優先してプロセスが実践できないこと」、そして、コミュニケーション量が増えて初期のやり方が通じなくなることや、チームメンバーが全然増やせない、スコープを広げた時にうまく適応できないということもある。
そこで対策としては、「チームで話して、チームがコントロールできるイメージを持てない範囲を避けること」や「社内の制度変更のアジェンダをチームで考えた上でステークホルダーたちと合意する時間を十分に取ること」などがある。またチームメンバーが増やせないという課題については、「しばらくは外部人材に依存したとしても価値を生み出すまでのリードタイムを短くすること」がおすすめだという。もちろん、同時に社内人材の育成もできるとより望ましい。このステップでも、引き続きチームを信頼して野放しにしてくれるスポンサーが必要だ。
なお、ここまできたら最後は「スケール」のステップだ。全社に広がったところで、ビジネスクリティカルな案件へのアジャイル開発の適用や、チームを大規模化する上で発生するコミュニケーションの問題解決が必要となってくる。
成功事例１：小さな成功をもとにアジャイル適応範囲を広げていく
こうした3ステップにより、実際にアジャイル開発を導入できた企業の事例について、安西氏が紹介を行った。
事例１：「最初はひっそりステルス型」東日本旅客鉄道「JR東日本アプリ」
もともと数百万DLのアプリだが、「いろいろ盛り込みすぎでよくわからない」「使い勝手が悪い」などのユーザーの声を受けて、デザイン思考でのアプローチをアプリ担当者が決意することからプロジェクトが始まった。まずはデザインコンサルティングファームにリニューアルのコンセプト作りを依頼し、内製アジャイルチームを結成した。その際のチームの内訳はPM１名、デザイナー１名、デベロッパー2名、そしてPivotal Labsの4名。まずは一部機能を切り出し、別アプリとして実験的にリリースしたという。
数か月にわたって内製チームでの開発が続けられた。従来版から移植が必須な機能をチームで判断したが、なかなか重い機能だったこともあり、リソース不足に陥った。しかし、会社側にはその認識がなく「これまでどおり外注でいいのではないか」といった慣性との戦いが生じていた。
そこで内製化の価値アピールのためにリニューアルのマイルストーンを設定し、スコープや実装方法は前向きに妥協し、限られたリソースで間に合わせるようにした。さらにリニューアル後にチームの存在をより確実なものにするため、とある機能をAndroidとiOS両方で実現することをコミットした。しかし、やはりリソースが足りないということになり、再度Pivotal Labsのメンバーが参加した。幸いにして厳しいスコープの定義とリソース増強により無事リリースし、問題も起きず社内評判は上々。人が増えて地道な機能改善施策に取り組めるようになったことで、好意的なレビューや口コミが増え始めたという。
そして、この成功をもってチーム＆Pivotal Labsで成果と今後の青写真をまとめ、内製化の重要性とリソース不足に関してステークホルダーを説得した。そして、他部門を巻き込んで事業を推進する立場へと成長していき、内製チーム拡大のための採用の取り組みも動き出しつつあるという。
2回めのPivotal Labs参加時にPivotal側のPMを担当した安西氏は、この事例のうまくいったポイントについて「社内にエンジニアやデザイナーがいないながらも、外部人材を活用して長期的にアプリにコミットできる内製チームを確立したこと。『小さく作って徐々に育てる』体制を無理なく作るため、他事業に影響が少ない形でスタートし、ユーザー価値を検証したこと。そして、完璧な理想に固執せず、戦略的かつ前向きな妥協を行ったこと。Pivotal Labsのようなサービスも1回めは育成、2回めはビジネス成果というように目的を明確にして利用したことがある」と分析した。
成功事例２：トップの強力なコミットがアジャイル導入の推進力に
事例2：「経営爆裂コミット型」日本事務器による農業系BtoB新規事業「fudoloop（フードループ）
続いては、トップによる強烈なコミットがある場合の事例が紹介された。「既存領域の延長線上ではなく、新たな領域に新たなサービスを創出できる企業」への変革に向けてトップが旗振りを行ったことで、最初からエンジン全開コミットの状態でスタートがかなった。社長直下に新規事業部門を創設し、変化への適性を鑑みて人選を行うなど、スキル育成・チームビルディングに十分な予算と時間を投下したという。さらに事業の種探しをデザインコンサルティングファームと協業しながら行い、自社の強みを生かした事業領域を選択した。
Pivotal Labsには、コンセプトの具現化とクローズドベータまでの開発が依頼され、エンジニア、デザイナーなど新規事業部門以外のメンバーをチームに投入して育成することも試みられた。またチームリーダーが渉外として社内ステークホルダーやユーザー企業との調整を担当したために、チームが開発に集中できる環境を用意できたという。Pivotal Labsの支援後も、チームは自走でオープンベータを経て正式にローンチまで実現した。
現在は、新規事業部門を事業推進本部へ統合し、メンバーの一部入れ替えなどをしながら学びを徐々に他の事業へ展開中だという。そして、今もPivotal Labsはプロセスのメンテナンスや事業の展開に関してスポットでコンサルティングを実施している。
安西氏は「時間や予算といった具体的なリソース投入を伴ったことで、社内外に本気度が伝わってきた。チームを既存制度やプロセスから隔離された治外法権として確立し、事業に集中できる環境を整備するなど、経営層は見守りつつ「何をやるか」はチームに一任したことで成果につながった。失敗を前提に、既存事業の評価軸を無理に適用せず、新しい学びを重視したことも大きい」と語った。
最後に改めて小俣氏が「アジャイル導入には時間がかかるので早く始めることが大切」と強調し、「社内の信頼を獲得するまでのチームを守るコミット、失敗を許容できるようなセットアップで始めて徐々に負荷を上げていくことが大事。進め方に絶対的な解はなく、自社に合うやり方を模索してほしい」と語り、セッションのまとめとした。
お問い合わせ
ヴイエムウェア株式会社
VMware Cloud Native Day - LIVE（オンライン開催）
アプリのモダナイゼーションを実現するマルチクラウドプラットフォーム
2020年4月22日（水）13:00 – 16:30 オンライン開催
