アビームコンサルティングが明かす「ビジネス改革をアジャイル活用で失敗しないための方法」とは？

アビームコンサルティング（以下、アビーム）ではアジャイルを正しく理解するためのイベント「アジャイルマニフェストの誤解！アジャイル活用でビジネス改革を成功に導く。- アビームコンサルティング Meetup #04」を10月31日、TECH PLAYで開催した。

本イベントは「変革を成功に導く反復アプローチのコツ」と「ユーザーとの協働のコツ」という2部構成で実施。前半はアジャイルの本質を体現した具体的な活用方法、およびアジャイルがプロジェクト現場でどのように活用されているのかなど、事例と共に解説。

後半はユーザーとの協働のコツを紹介するだけではなく、ワークショップも実施。アジャイルの本質や活用の方法の理解に加え、ユーザーとの協働の具体的なコツをつかめる機会となった。

アジャイルプロジェクトの現場でよく聞くこと

「アジャイルはそんなにドキュメントを作ってはダメ」
「きちんと計画するのはアジャイルじゃない。計画なんていらないんでしょ」
「全部メンバーで決めないと！リーダーはいらないのがアジャイルじゃないの」
「はじめにアーキテクチャを決めたらアジャイルじゃない」
「大規模プロジェクトでアジャイルなんてできないよ」
「ウォーターフォールでアジャイルをするなんて邪道だよ」
「とにかくDevOps。自動化だよ」

アジャイルによるプロジェクトの現場で聞かれるこれらの言葉。このような言葉が出てくるのはアジャイルを開発方法論として捉えているからだ。そしてこのような言葉がまかり取っているプロジェクトでは、本来、失敗しないために用いたアジャイルが仇となり、失敗に至ってしまう。

ソフトウェア開発の分野でアジャイルという言葉が登場したのは2001年。ScrumやExtreme Programming（XP）Adaptive Software Development（RAD）、Crystal、DSDM（RAD）、Feature-Driven Development（FDD）などの異なる考え方を持つ代表者が集まり、より良いソフトウェア開発するためのたどりついた価値観を宣言した「アジャイルマニュフェスト」が起源である。

そこで語られた価値観や原則、考え方がアジャイルと呼ぼうということになったのだ。だからこそアジャイルを正しく把握するには、アジャイルマニュフェストを見直すことから始めるのが得策となる。

アビームではアジャイルを開発方法論ではなく、ビジネス・企業変革を成功に導くための一つの手段であると捉えている。

アジャイルの正しい理解とは

最初に登壇したのはP&T Digitalビジネスユニット ITMSセクター Directorの安藤裕介氏。安藤氏はアジャイルという言葉を使わずに、アジャイル的な考えを用いて大規模プロジェクトを成功に導いてきたコンサルタントである。

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

アジャイルがなぜ失敗するのか。安藤氏は「アジャイルマニュフェストの価値観が間違って伝わっているため」と言う。

以下はアジャイルマニュフェストを日本語にしたものだ。ここに書かれた言葉をみてほしい。

「～よりも」という表現が使われていることで、つい右側の太文字を重視するように読み取ってしまうと、「プロセスやツールはいらない」「包括的なドキュメントはいらない」「契約はあいまいでよい」「計画はいらない」というようになってしまう。

「それは間違い。左側をきちんと取り組んだ上で右側のことを行ってはじめてプロジェクトを成功に導くことができる。ここは間違えてはいけない価値観です」（安藤氏）

しかも安藤氏は「アジャイルは新しく出てきた考え方でもなんでもなく、もちろん大規模開発にも適用できる」と言う。それは歴史をひもといてみればわかる。

アジャイルのルーツは1930年に提唱したシューハートの品質管理の手法、PDSA（PLAN→Do→Study→Act）から始まる。その品質管理のための手法は1950年のデミング博士に受け継がれ、トヨタ生産方式（TPS）を生む。

さらにデミング博士の考えはソニーやホンダ、キヤノン、富士ゼロックスにも取り入れられ、1986年に野中氏・竹内氏がそれらの日本企業が採用している新製品の開発アプローチ手法に関する論文をハーバード・ビジネス・レビューに発表。

「この論文の冒頭に書かれていたのが『スクラムを組んで進め』という言葉。ラグビーのようにスクラムを組んでトライエラーを繰り返していけば、新製品開発が早くできるということを表現している。1993年、この新製品開発のアプローチを米国のコンサルタントがソフトウェア開発に応用。それがScrumです」（安藤氏）

シューハートの考え方は大規模プロジェクトを成功に導くための手法として取り入れられていく。それがIID（Iterative and Incremental Development：反復開発）である。ジェット機やスペースシャトルの開発に使われていた方法論で、1970年にロイスがソフトウェア開発に適用。「ロイスは大規模なものほど反復でやるべきだとレポートに記述した」と安藤氏。そしてロイスの考えはRAD、DSDM、FDD、XPへと受け継がれていく。

「この歴史の流れから見ればわかるとおり、アジャイルは大規模にも向いていることがわかる。またアジャイルは組織と戦略の話でもあり、プログラミングの設計の仕方という話でもあることがわかるでしょう」（安藤氏）

アジャイルの原則を適用し、企業の抱える課題を解決する

ではなぜ、アジャイルなのか。それはこれからの第4次産業革命/デジタルトランスフォーメーション時代に、企業か抱える次のような課題を解決できるからだ。

●「ビジネスとITをビッグバンで変えることが難しい」「ビジネスのスピードにITが答えられない」

アジャイルの原則「お客さまに価値をすばやく・継続的に届ける」を適用する。価値高い最小機能を厳選と短期リリースをする。最小限の機能でまず市場に投入し反応を見る。その傾向に合わせて継続的に改善するのである。

そのためにはビジネス価値をもたらす、最小機能を見極めるアプローチを取ることが必要になる。シナリオ分割やユースケース分割し、最初のリリース箇所を決める。過渡期システムデザインを描いて、段階的に新しいシステムに移管していくのである。

「これをうまく実現していくにはユーザーとITが協働する要求開発が必要になります。これについては、第二部で説明します」（安藤氏）

●「ビジネスとITの分離・縦割り組織・調整役不足」「正解泣きユーザー価値、まとめられない要求」

アジャイルの原則「動くものでお客さまの価値ある要求を見極め」を適用する。その手法として活用するのが、顧客フィードバックループ。

「これさえあれば、反復スタイルは部分的反復でも変則的反復でも固定的反復でも何でもよい。プロジェクトの特性と関係者のレベルに合わせて適用していくと良い。特にScrumは難しいので、ウォーターフォールしか経験したことのないメンバーの場合は、段階を踏んでScrumへ移行していくことが望ましい」（安藤氏）

実際に安藤氏は新規事業会社を作り、半年後に事業稼働させなければならないという大規模なウォーターフォールプロジェクトに顧客フィードバックループを採用。稼働後の不具合もゼロなど、無事成功に導いたという。

●「次々と出現する新しい技術の人材不足」「システム資産の巨大化・複雑化・属人化」

アジャイルの原則「未知なものは小さく試し、学び、即時是正」を適用する。早期にリスクを低減する反復手法を活用。最初に小さく試し、実力を把握して計画すれば、費用や期間の精度を高めていくことができるからだ。このとき試す対象は未経験なものすべて。

「技術だけではありません。チームや体制、プロセス、成果物、アプローチ、コミュニケーションなど、未経験であればすべてがその対象となります」（安藤氏）

●「プログラム・プロジェクトマネジメント経験者の不足」

アジャイルの原則「チームが自主的かつ継続的にQCDを改善」を適用する。高速PDCAサイクルを回せる組織・文化を作るのである。高速PDCAで重要になるのが、反復のあとに必ずよりよいアプローチを見直す時間を確保することだ。

「特定の人だけで実施したり、時間があまりにも短時間だったり、やらされ感満載だったりするようなふりかえりにしないこと。全員参加、ゆとりがあり、強い人から聞き、解決の行動を率先するように動くようにすること。こうすることで、継続的にQCDが改善するようなPDCAサイクルが高速に回せるようになります」（安藤氏）

アジャイルの原則にはアジリティを向上させる文化も含まれている。持続可能な作業ペースを確保するために、ふりかえり時間の確保や残業・休日出勤を禁止したり、人海戦術でカバーしたりするより、真因にリーチすることを推奨している。また「ムダの徹底除去・当たり前品質」という原則もある。

「同じ作業時間でムダを排除し、付加価値の有無時間を倍にすれば生産性は2倍になります」（安藤氏）

ここまでの解説で、きっと気づいたことがあるだろう。アジャイルが上手いプロマネが実践しているアプローチであるということ。

「アジャイルの原則の本質をわかっていれば、たゆまぬ学びはあっても、失敗はありえないんです」（安藤氏）

ユーザー協働がなぜ必要か

続いて「ユーザーとの協働のコツ」について解説を行ったのが、P&T Digitalビジネスユニット ITMSセクター Managerの下田友嗣氏だ。

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

「マニュフェスト通りに対話を重視して、ユーザーとの協働チームを組成したがうまくいかない」。このような相談をよく受けるという下田氏。

「そういう現場では、開発だけがアジャイルをやっている、プロジェクトオーナーが御用聞きになっている、ユーザーとITの混合チームを作っているが、ドキュメントの交換だけで協働ができていないといういずれかのパターンに陥っているはずです」（下田氏）

これらは構成や役割を考えているだけで、なぜ、協働が重要なのかを考えていないからだという。ではなぜ協働が重要か。それには「要求とユーザー」「ITに内包された業務」という2つの理由があるという。

●第一の背景「要求とユーザー」

「業務とITがより密接になり、ITを考えることが業務を考えることになっています。しかも今は新しい技術もどんどん出てくるなど、誰もが予想できない時代になっています。つまりユーザーだけで真の要求・要件を出すことは難しいのです」（下田氏）

たとえユーザーが「こういう業務をしたいから、こういう要件であるべき」とまとめたとしても、言葉で伝えることに失敗していることも多い。「自分が正しく伝えたつもりでも、相手が正しく受け取るとは限りません。同じ解釈ができるようなパーフェクトな文章を作ることはできないのです。言葉は自分の経験やバックグラウンドによって解釈が異なるからです」（下田氏）

例えば「テスト」という言葉を聞いて、何を連想するか。ソフトウェア開発者であれば、単体テストや結合テストなどソフトウェア開発における「テスト」を連想する。だが中学生や高校生であればそのようなテストは連想しない。

●第二の背景「ITに内包されている業務」

現ユーザーの多くは、システム化されている業務ルール・パターン・ロジックを把握していない。中には業務だと認識していない人もいる。

「本来はIT化されているところまで業務として認識されるべきところが、使い方だけを業務だと思っているのです」（下田氏）

これらの背景を踏まえた上で協働に取り組まないと、組織論やチーム論に執着してしまうこととなってしまうという。

共感・共通理解をするための手法「ストーリーマッピング」

ではユーザーとの協働のコツはなにか。「共感が重要になる」と下田氏。というのも今の時代、画一的なやり方が通用しないからだ。

では、どうやって共通理解を得る共感を実現すればよいのか。その手法として下田氏が活用を進めるのがストーリーマッピングである。2007年にジェフ・パットン氏による発表された同手法は、「共通理解を得るメカニズムとして、シンプルで非常に強力だ」と下田氏は言う。

ストーリーマッピングは現在マップと将来マップの2つの考え方で構成されており、「現在マップが共感への強力なツールとなる」と下田氏は説明する。

現在マップ：ユーザーが今、どのように働いているかを理解・可視化をする
将来マップ：ユーザーがアウトプットをどのように利用するのかを理解・可視化する

ここでストーリーマッピングを活用すると本当に共感が得られるのか、体験するためのワークショップを行うことに。ワークショップのお題は「起床してから仕事を開始するまでの活動におけるから課題と解決策を探る」。余談だがこのお題は初対面でも必ず盛り上がるので、「よく使っている」と下田氏。

ワークショップでは以下のようなことが行われた。

① 隣の人とペアになり、まずはインタビューやヒアリングという従来手法でお題と向き合ってみる。
② それぞれが自分の活動を付箋に書き出し、それを時系列にA3の紙に並べてグルーピングしタイトルをつける。それが終わると、今度は改善したいこと別の付箋に書いて貼っていく。
③ その作られたストーリーを見て、相手の話を聞くのである。