アビームコンサルティングが明かす「デジタルトランスフォーメーションを成功に導くアジャイル活用」とは

アビームコンサルティング（以下、アビーム）は、「アジャイル活用で、デジタルトランスフォーメーションの壁を突破する。-アビームコンサルティング Meetup #05 -」を2月20日に開催した。

今回のイベントは、大きく2部構成で展開。最初の約30分は「デジタルトランスフォーメーションを成功に導くアジャイル活用とIT協働のコツ」と題したセッションが行われ、後半の約1時間は「アジャイル活用の疑問に答える公開Q&A」というテーマで、参加者の疑問に答える時間が設けられた。

アジャイルにこれから取り組む人、アジャイルを取り入れているものの上手く回らないという人にとって、非常に参考になるヒントが得られる機会となった。

参加者同士のネットワーキングタイムからスタート

オープニングを務めたのは、P&T Digitalビジネスユニット ITMSセクター Managerの下田友嗣氏。「今日は一緒にアジャイルに関する悩みに対して、どう対応すれば上手くいくのかを一緒に考えていきましょう」と呼びかけ、イベントがスタートした。

▲P&T Digitalビジネスユニット ITMSセクター Manager 下田友嗣氏

最初の5分間は、各グループ内でこのイベントに参加した理由と自己紹介するネットワーキングタイムが設けられた。

▲シアター形式ではなく、参加者がグループディスカッションできるように島型形式のレイアウトで行われた。

企業が抱える7つの課題とは

参加者の緊張がほぐれてきたところで、P&T Digitalビジネスユニット ITMSセクター Director安藤裕介氏によるセッション「デジタルトランスフォーメーションを成功に導くアジャイル活用とIT協働のコツ」が始まった。

▲P&T Digitalビジネスユニット ITMSセクター Directorの安藤裕介氏

安藤氏は大規模プログラム・プロジェクトマネジメント、IT戦略・構想策定、新事業立上げ支援、ITライフサイクル改革・改善支援など、業界・業種を横断した幅広いコンサルティング、実現に向けたリーディングを実施している。

安藤氏とアジャイルとの関わりは1997年まで遡る。安藤氏は、「大炎上プロジェクトを立て直すために、細かくフィードバックを繰り返すということをやり始めました。当時はRADと呼ばれる手法を適用したのが始まりでした」と振り返る。以降、反復手法、アジャイル的なアプローチをずっと適用してきたという。

デジタルトランスフォーメーション時代の今、企業は7つの課題を抱えている。
第1は「ビジネス要求をまとめられるユーザーの減少」。安藤氏は「ユーザーのみで真の要求を出すことはできないのが実態だ」と言い切る。要求を出せたとしても「現行通り」になってしまうからだ。

第2は「ITに潜むビジネスルールのブラックボックス化」。「ITはより大規模で複雑になり、ITの中で実行されているビジネスルールがすべて把握できないケースが増えている」と安藤氏。

第3は「次々と出現する新しい技術の人材不足」。「AIやRPA､IoT、Python…というような新しい技術を理解し、ビジネスに応用できるような人はユーザー企業にはなかなかいません」（安藤氏）

第4は「ビジネスとITの分離・縦割組織・調整役不足」。かつてはビジネス全体を俯瞰し調整できるキーパーソンがいたが、昨今の大企業は縦割り文化が強くなっているという。

第5は「プログラム・プロジェクトマネジメント経験者の不足」である。現在、企業で使われているITは80年代から2000年代初頭に構築し、10～20年利用しているため、大規模なプロマネ経験者は希少になっている。実際、安藤氏が参加者に問いかけたところ、300人以上のプロジェクトのマネジメントをやったことのある人はゼロ、100人月のプロジェクトで2～3人しかいなかった。

第6は「ディスプラターの出現・求められる変革スピード」。「例えば5年かけてビジネスやシステムを改革していては、企業は潰れてしまう。それ程までスピードが求められる」と安藤氏は説明する。

しかし、ビジネスをスピーディに変革できない現実もある。それが第7の課題「ビジネススピードを阻害する新旧のレガシー」だ。

「基幹システムの継続改修によるロジックの複雑化、無策にアジャイルに構築した新しいITにより、システムのスパゲティ化が起き、それが阻害要因となっている」（安藤氏）

課題を突破する5つのアプローチ

では、これらの課題をどうやって突破すればよいのか。アプローチは大きく5つある。

ビジネスとITが共同する組織
必要最小限機能の見極め
変化に応えるアーキテクチャ
過渡期デザイン
反復手法による段階的変革

1. ビジネスとITが共同する組織

言葉はお互いの持っている背景によって変わる。
「例えばテストという言葉もITエンジニアならシステムのテストをイメージしますが、学生なら期末テストなどになります。文書による伝言ゲームは認識の違いと手戻りを拡げる。ユーザーとITの協働により、動くモノをこまめに検証していくことが必要となります」（安藤氏）

2.必要最小限機能の見極め

「要件として挙げられた機能の中には、めったに使わないものもあります。例えば現行のシステムの中にも不具合を起こしたときの暫定的な機能などもあります。ビジネスロードマップやITロードマップをしっかり立案すると共に、現場観察をし、シナリオのウォークスルーなどをしてモデル化して実現性を高めていく。大事なのは顧客価値を生み出す最小限は何かということをしっかり見極めることです」と、安藤氏は語る。

優先度の高いシナリオを実現するために、ITに求められる処理とデータの流れを捉え、それを実現する機能の見極め、段階的にリリースしていくのである。

3.変化に応えるアーキテクチャ

持続的かつスピーディに変化に応えていくためには、再利用可能なビジネスドメインの把握・維持とアダプティブなITアーキテクチャが必須になる。

「疎結合になるようなビジネスプロセスとデータモデルを維持する仕組みと考え方の伝授が極めて重要になります」（安藤氏）。

例えば数年後、スマートフォンはなくなっているかもしれない。また数年後にはUIは映像や音声など、五感を伴ったものに変わっているかもしれない。そのようなことになっても、ビジネスロジックは変えられるよう、優先度の高いものから、要るもの、要らないものをしっかり見極めてモデリングしていく必要がある。「変化に強くしないといけない領域に関してはしっかりやること」と安藤氏は指摘する。

4.過渡期デザイン

最小限のユースケースと機能を実現させるためには、変化させない業務や既存システムを生かす過渡期デザインが重要になる。

「ビッグバンでシステムを入れ替えることは不可能に近いからです」（安藤氏）

既存システムと併存し、新しいシステムを小さくリリースしていく。そうすることで新しいビジネスができるようにしていくことが大事なのだ。

5.反復手法による段階的変革

「反復は3つのアプローチがある」と安藤氏。それが「顧客フィードバックループ」「早期にリスクを低減する実現検証」「高速PDCAサイクル」である。

反復の3つのアプローチとは

第1の顧客フィードバックループとは、動くものでお客さまの価値ある要求を見極めること。最後になって『これは求めていたものと違う』と言われると、大きな手戻りが出てしまうからだ。

「私がヘルプしたプロジェクトの中には、総合テストの際に非常に多くの手戻りが発生し、1年間延期になったものもあります。また30億円を投じたプロジェクトが中止になったこともある。後回しにされた検証で品質を高めるアプローチは莫大な手戻りを生みます。昔からのセオリー通り、検査より予防が重要です」（安藤氏）

ウォーターフォール・モデルの起源は1970年代初頭にR.ロイスが発表した「MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS」という論文と言われている。この論文を見て、アメリカ国防省がウォーターフォール・モデルの標準化をしたという。だが、ロイス氏は反復手法の信者で、「ウォーターフォール・モデルはキレイな形だが、大規模には向いていない」と言い切っているのだそう。

安藤氏は「大規模なものほど、リスクテイクをする手法が必要で、反復手法はかなり昔から世の中に存在します」と語り、次のような例を挙げた。

1960年代のスペースシャトルプロジェクトでは、17回の反復開発が行われたという。1970年代にはIBM製品開発に適用された。「その後も大規模なものであればあるほど、反復開発でなければならないとされており、純粋なウォーターフォールの場合、8割は失敗すると言われています」と安藤氏は強調する。

また顧客フィードバックループさえあれば、反復のスタイルはウォーターフォールの途中でフィードバックタイミングを設定する部分的反復でも、Scrumが提唱している期間設定を採用した固定的反復でも、画一的なタイムボックスを設定せずに目的に応じてタイミングを設定する変則的反復のいずれでもよい。

「Scrumを採用しても、反復の意味がちゃんと検証されているのか。そこがちゃんと検証されていないプロジェクトが後を絶たない」と安藤氏は苦言を呈す。

安藤氏が担当したハイリスクなウォーターフォール・モデルのプロジェクトでは、ユーザーフィードバックを定期的に入れることによって、短期間で新規事業を開始できたという。

「プロフェッショナルなメンバーを集めたわけではありません。Java初心者が3人、ホスト系エンジニア5人でスタート。ピークは100人ぐらいいた大規模なプロジェクト。それでも反復手法を入れれば、リスキーなモノでも成功に導くことができます」（安藤氏）

第2の早期にリスクを低減する実現検証とは、「小さくてよいので、とにかく試すことが重要だ」と安藤氏は言う。メンバーの実力、一緒にやる人の実力などもわかるからだ。

第3の「高速PDCAサイクル」では、毎日、記録し、振り返って課題を見つけて、是正をするという時間を作ることが大事だと言う。「アジャイル初心者チームでもこのサイクルを3回ぐらい回せば、生産性や品質が2倍ぐらい向上する。それは事例からも明らかだ」と安藤氏は言い切る。

1週間ぐらいの小さなプロジェクトを回してから始めた方が、圧倒的に生産性が上がる。
このような反復手法を成功に導くには、「それを可能にする文化を創ることも重要だ」と安藤氏は指摘する。安藤氏が言う文化とは持続可能な稼働ペース、心理的安全が確保されていること。特に心理的安全が確保されていることは、生産性向上に大きく影響すると統計データでも明らかになっているという。

そしてリーダーは組織の壁があったり、先のような環境が用意されていない場合は、それを支える存在となる。つまりサーバントリーダーシップを持つことが求められる。

「この3つの文化があってこそ、フィードバックループが上手くいくのです」（安藤氏）

安藤氏の話には反復手法は出てきても、アジャイルという言葉は出てこない。またウォーターフォールという、アジャイルとは真逆と思われていたプロジェクトの話が登場している。

「『どこがアジャイルなのか』という疑問が生まれた人もいるだろう。しかし、アジャイルマニュフェストをじっくり読めばわかるが、アジャイルとは「より良い開発手法をもたらす価値観と原則のこと。私たちはこう解釈している」と下田氏は断じる。

実際、安藤氏が話した内容とアジャイルの原則をマッピングすると次のような図となる。つまり先の安藤氏が話したことは、「優秀なプロマネならすでに実践していること」と下田氏は付け加えた。

参加者の悩み、疑問に答える公開Q&A

続いては、一人ひとりの参加者の方の実態に合わせた公開Q&Aタイム。まずは1分半で一人ひとり質問を考え、その後、約4分半かけてグループで話し合い、質問を1つに絞るという作業が行われた。

Q1. 動くモノを作って確認していくという話だったが、システムを作った人が辞めた場合、設計書をなしにどうやって他の人に引きつげばよいのでしょうか。

安藤：結果からお伝えすると、これまで設計書を作らなかったことはありません。実装された結果は残りますが、その機能が必要だったのか、どういう条件でその要求を選んだのかということに関してはソースコードに書かれないからです。どんなシナリオにするかという想定を描き、要求、要件の対応、トレーサビリティがちゃんとできるようにしておくことが大事です。もちろん合格基準も書く必要があります。書かないと判断するのであれば、書かないことでの結果と、書いたことでの結果を比べて判断すればよいと思います。

下田：設計書は基本、作ると考えてもらった方がいいですね。振り返りの中で、不要だと思えば削っていけばよいと思います。例えばデベロッパーが複数の場合やDBの設計の場合などは、最初に設計しておかないと開発はできませんので、絶対作ってください。

Q2. ビジネスとIT部門のコミュニケーションや、お客さまとの信頼関係はどうやって築いていけばよいのでしょう。

安藤：ビジネスサイドの人と話をするためには、まずその人がどんなことをしているかを見ること。そして時間が取れるやり方について話をすることです。その際、誰にアクセスした方がよいかなども聞く。この辺りは企業文化によって異なりますからね。私は実際、3日間、働かせてくださいと言って、バイトしたこともあります。そういうことを毎回やっています。

下田：要件定義について「話をする時間をください」と業務部門の人に言っても、無理と言われてしまうことが多い。忙しいというよりも、心理的なハードルの高さがあるからだと思います。それを取り除くために、「ここはどうやっていますか」と聞くと、答えてくれます。そのようなヒアリング方法で、ユーザーストーリーマッピングに起こす。この方法だと意外にフランクに答えてくれます。

Q3. アジャイルの弱みについて教えてください。

安藤：今日話したことが全部、明日からできることではありません。これが最大の弱みと言えるのかも知れません。まずは一つずつ、記録を取ることから始まります。例えば設計書を書くのにもストップウォッチで計る。そういうことを繰り返ししていくことが必要です。優先順位一つ付けるのも、現場や人を見ないとできません。アジャイルはこのように、一つ一つやらなければならないことが弱点。一足飛びにはできるものではありません。

下田：安藤も言ったように、一つずつの積み上げが大事。そして、対面で会話をすることも必要。そこが難しいと思うポイントです。

Q4. 納期が決まっているアジャイルのプロジェクトで、ユーザーからのフィードバックが大量だった場合、どういうふうに整理していけばよいのでしょう。

安藤：納期が決まっているということは、その目的を達成するのに期間も予算も決まっているということ。スコープの段階で、目的を達成するためにマストのものと、そうではないものという風に優先順位付けをする。なぜ時間がかかるのかについて、理論をもって説明し、話し合うことです。納期が決まっているからこそ、スコープを落とすことが大事です。

下田：エクセルなどで記された要件リストを見ても優先度はなかなか決められません。というのも全体を俯瞰して見られないので、みんな重要だと言うからです。そこで整理方法としてオススメしたいのが、ストーリーマッピングの活用です。全体のストーリーを見て、重要度を見える化する。そうすると、「ここの機能は必要だよね」という話が建設的にできるようになるし、自然とユーザーも前向きになります。

Q5. 社内にアジャイルに精通している人間がいない場合、どうやって文化を創っていけばよいのでしょう。

安藤：まずやらなければいけないのは、お試しの範囲を区切ること。ビジネスの企画であれば、検証に十分な必要最低限を切り出し、それを作って、お客さまにアンケートを取り、検証します。これはシステム開発でも同じです。

例えば2000個ぐらいあるビジネスプロセスの中から、一番重要なビジネスラインのシナリオを切り出して、要件を書いて設計して開発して、一度回してみるのです。そして試している間はすべてを記録する。結果を見て、みんなで会話をして細かく振り返る。そして範囲を拡げたりして、別のバリエーションに取り組む。それを繰り返していくのです。

場合によっては有識者に入ってもらうこともいいでしょう。失敗したとしても、それは学びとなります。というのも、小さく区切るのはテクニック。そのテクニックについてScrumの本には書かれていません。だからとにかくやってみることが大事なのです。3回ぐらいやっていると人間はうまくなる。スポーツと同じ。繰り返して慣れていけば成功に繋がります。

下田：小さく試して、学び、そして失敗させる。まさにその通り。小さく試すことを繰り返すことで、強くなっていくのです。日本ではなかなかビジネスサイド向けのアジャイルの本はありません。すでに廃版になっていますが、ローマン・キヒラーの「スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発」という本がお薦め。内容は難しいですが、プロダクトオーナーの役回りをするビジネスサイドの人はぜひ、読んでほしいですね。

Q6. 差し込みがベロシティを悪化させることもあると思います。その中でどうやって運用をさせていけばよいのでしょう。

安藤：差し込ませないことが基本ですが、差し込みさせるのであれば、今、その変更をすることが、最終ゴールにどんなリターンをもたらすのかをきちんと検討することが大事です。場合によっては、プロジェクトを止めることも考える。変更を加えるのであれば、コストもかかります。

ここでいうコストはお金だけではありません。モチベーションなども含まれます。例えば休まないで徹夜でやらなければならなくなると、生産性は2分の1になりますし、モチベーションも下がります。それらを考えた上で、今やるべきかどうかを考えるのです。もちろん、今、集中してやった方が良い場合もあります。とにかくしっかり判断すること。すごく難しいし、勇気がいることではありますが…。

Q7. アジャイルは失敗から学ばせるとおっしゃいましたが、それができる失敗のさせ方について教えてください。

安藤：プロジェクトとは、これまで経験したことのないこと、やったことのないことをやること。計画しているけど、計画していないのと同じなので、失敗や予想外なことが起こる。だから試すことが大事になります。試す期間は許容範囲によって変わりますが、1～2カ月あると結構なことが試せます。先に試してからスタートすると、やり方に慣れているので生産性も上がる。口説き文句としては、後で手戻りする可能性を考えたときに、今かかるその人月分を投資しましょうということです。

Q8. ビジネスサイドでシステムを利用しています。あるシステムのルールエンジンをユーザーが開発・管理し、それを部内に展開しろと言われています。しかも部門長からその開発方法はアジャイルでやれと。このような場合、何から始めればいいのでしょう。

安藤：超高速開発、RPAなどが出てきたことで、ユーザーだけでもできるだろうと言われています。ですが、それは無理。たとえIoT、AIを知っていて、業務もわかっていたとしても、システムのセオリーやモデリング技術、要求開発、当たり前品質の確保の方法などまではわかっていません。初めて取り組む場合は、技術アドバイザーは必須でしょう。正しいやり方でやっているか、ウォッチしてもらうのです。そうすることで、チームができるかもしれません。