アビームコンサルティングが実例から導く「見せかけだけのアジャイルにならないための５つのアプローチ」

（プロフィール）

アビームコンサルティング株式会社
P&T Digitalビジネスユニット ITMSセクター
ダイレクター安藤裕介氏

アビームコンサルティング株式会社
P＆T Digitalビジネスユニット ITMSセクター
マネージャー　下田友嗣氏

アジャイルマニフェストの背後にある原理原則を支える理論を理解し、的確なアプローチをとる

前半のセッションは、アビームコンサルティングの下田友嗣氏が登壇。アジャイルの原理原則の背景にある理論をベースとしたビジネス改革を成功に導くポイントや具体的なフレームワークなど、2つの実例を挙げて紹介した。

事例①顧客に本当に価値あるものを提供するコツ

下田氏いわく、ビジネス改革を実現するためには魅力的品質を追求することが重要だという。

「まず重要なのは、品質には当たり前品質と魅力的品質の側面があることを理解し、自身のビジネスに置き換え、しっかりと分けることです。その上で、それぞれ品質を高めるためにアプローチをとっていきます」（下田氏）

●「当たり前品質」「魅力的品質」をしっかりと分ける

具体的なアプローチは、OODAループやPDSAといったフレームワークを活用し、限られた予算と時間の中で最も優先すべき価値を、自分たちで徹底的に追求し、絞り込むことが重要だ。

一方、当たり前品質はその名のとおり、すでに世の中に標準やパターン化されたものがある。、当たり前品質えは、最初に決めて作る人によって発生するブレをなくすことが重要である。また自分たちではなく、標準・パターンを知っている専門家に任せるべき。実現手段についても相談すべきである。、その浮いた時間を、先の魅力的品質の追求に費やす。

●“共創”が品質の高いサービスを生む

魅力的品質については1人で考えるのではなく、IT部門、ユーザー部門が協力してアイデアを出し合い共創することが重要であると下田氏は説明する。

そのような環境を実現するには、まさにアジャイルマニフェストの背景にある、リーダーシップ理論を活用すべきと続けた。

「上意下達でやらせるのではなく、各メンバーが自分たちの意志でやりたいと思い、動くような環境作りを、リーダーが構築するよう意識します。具体的には自分の課題にメンバーを巻き込み解決に導いたり。別のメンバーに行ってほしい課題を、自分から打診するのではなく、その人からやりたいと思わせる環境です」（下田氏）

事例②工数を減らし開発スピードを上げるためのコツ

「お客様の中には、ビジネス改革を行うために何でも一から作らなければいけないと思い込み、実際にそのようなアプローチをされている方も見受けられます。しかし時間や予算は限られていますから、そのようなアプローチでは生産性は低くなり、それぞれの品質も悪くなります。

さらに生産が遅れたことを、ユーザー部門とIT部門が他責し合うようになります。その結果、ユーザー部門はより多くの要求を提案するようになり、IT側はその対策として工数のバッファをとる。このような、より多くの工数がかかる悪循環に陥ります」（下田氏）

アジャイルの理論、具体的には要求と人と生産性の基礎理論を知っていれば、このような悪循環には陥らず、よりスピーディーに低い工数で価値を提供できると下田氏は強調。具体的には次の5つの軸において、それぞれのアプローチを紹介した。

●探索する どの業務にどれだけの時間をかけてよいのかを、まずは把握する。言い方を変えれば、優先すべき業務や作業、逆に、優先しなくてもよい事案を探索することが重要だ。先の①の事例、魅力的品質の探求に近いアプローチと言える。

また同業務はとにかくクイックに、半日や1日といった短期間で行うことが重要であり、1週間もかけて行うのでは意味がない。

●決める ビジネスやアプリケーションには一定の型がある。その型からパターンを見極めることで、何から何まで一から作らずに済む。結果として、生産性の効率が上がる。

具体的にはそのパターンをもとに、全体を俯瞰として観察し、差分を埋めるようなアプローチであり、下田氏は「再利用」との言葉で説明。また「探索」と同じく同工程も時間をかけずに、クイックに見極めることが重要だ。

●作業する メンバー一人ひとりのパフォーマンスは、当然、異なる。そのため一般的な生産性効率の指標は無意味だ。個々のパフォーマンスを実測し、それぞれ先人の知恵や理論をもとに工夫することで生産性を上げていく。また工夫は小さく試すことも重要である。

●検査する 最終的な合格基準でまとめて大きく検査するのではなく、できるだけ早期に小さく実装し検査することが重要。検査のアプローチでは2人同時にプログラミングを行うペアプロで実施すれば、瞬間的なレビューバックが可能だ。

●醸成する 事例①と同じく、働く環境の重要性も指摘された。挑戦を受け入れる環境であったり、生産性アップで浮いた時間を、自分のスキルアップや余暇に使えるのを許容するなど、ハッピーな未来や環境が先になければ、そもそもメンバーは工夫や改善はしないからだ。

いわゆる自律的組織の構築であり、実現するためにはこのような好環境のサイクルを続けることが重要なのだ。

下田氏は次のように総括し、セッションを締めた。

「このようにアジャイルは、ハイテクニックを使いこなすわけではありません。重要なのは、アジャイルの基礎理論を理解し、しっかりと現場で使い続けることです。座学など机上の学習や研修だけでは、本当の意味でのアジャイルは身につかないからです。

座学で腹落ちした理論を、現場に重ねていく。その上で説明したとおり、1人ではなく複数でディスカッションすることが重要です。

新しいビジネス価値を生み出すためには、当然リスクもあります。ましてや変化スピードが早い昨今では、不確実なものに対しては、とにかくアジャイルの理論に基づき、クイックに対策を施す。その上で日々アジャストしていくことが重要です。そのような取り組みの結果、アジリティは高まるのです」（下田氏）

【公開Q＆A】参加者からのDXやアジャイルに関する質問に回答

Q＆Aのセッションでは、同じくアビームコンサルティングのコンサルタント安藤裕介氏が登壇。参加者からの質問に的確に応えていった。

Q:ハードウエアなど、ソフトウェア内製開発以外のアジャイルの適用について聞きたい

アジャイルの本質は、より優れた価値をより少ないコストで実現することです。この理論に基づけば、すべての業務に適応できます。初めてやり取りするベンダーとのコミュニケーション構築や、新しい技術開発などでもアジャイルは活用できます。

私は仕事以外でも、たとえば地元のお祭りを立ち上げる際にもアジャイルの理論を活用した経験があります。これまでの経験から、特にリスクが高いプロジェクトにおいて、アジャイルの成功率が高かったように感じています。

Q: アジャイルならではの苦労は？

私がお客様に必ず伝えているのは、メンバー全員が集まり、個々の属性などを加味した上で、何がベストなのかを全員で考えることが重要だということ。当然、出てくる答えは1つではありません。

このような議論を重ねることで、チームや組織の垣根を超えて、本当の意味で開発環境が醸成された空気感こそ、重要なのです。そのため私はアジャイルという言葉を使っていませんし、テクニカルものでもないと考えています。

Q：アジャイルが実際の業務、限られたスコープ内でどのように実施されているのか

スコープがそもそも正しいのかどうかを考えることが重要です。というのも、テキストに書かれたスコープの裏には、言葉や文章を読んだだけでは伝わらない、背景や内容が隠されていることが往々にしてあるから。つまり、スコープを決めたつもりになっているのです。

最初にスコープを丸投げするのではなく、一番大事なシナリオを絞り込んで、そのイメージに合っているかどうかを確認することで、リスクが低減できます。アジャイルはリスク低減手法なのです。

Q：要件が再現なく追加されると、予算・スケジュールの見通しが難しいのでは？

予算と時間は限られているプロジェクトが大半ですから、どこに注力するのかを絞り込むことが重要です。たとえばiPhoneの初期モデルは薄さにこだわり、他の要素は後回しにしています。

もうひとつ、新しい技術を採用する際には、個々の能力のアジャストを把握するためにも、とにかくトライしてみることが重要です。それも少数ではなく、大勢のメンバーでクイックに、です。このようにメンバーのトライを定期的にモニタリングし、ベストな解決策を探る。これが、アジャイルです。

Q：アジャイルを軸に、企業のカルチャーを変えるにはどうすればいいか

方法論によらないように注意します。多くの人が型やマニュアルに頼りたくなるからです。なぜやっているのかを徹底的に考え、全員で議論することが大切です。

Q：PDCAとPDSAの違いとは何か？

PDSAでは、プランに対して同意できているかをチェックします。つまり現在のプランで進んで問題ないのか、プランが間違っているかもしれないとの前提でスタディします。

具体的にはクイックに試してみて、不具合があれば変える必要があると判断します。OODAループも同じアプローチですが、OODAループでは状況の変化がより早い場合に用います。

Q：ウォーターフォールからアジャイル開発にシフトするロードマップについて聞きたい

ロードマップではありませんが、ウォーターフォールでも、アジャイルの理論を活用することができます。たとえば、リスクの高いものを先にクイックに、小さく試すアプローチができるからです。

開発がスタートした後でも、最初のソースコードが上がってきたときに、そのレビューを先にチェックすることもできます。難しい箇所についてはまさにアジャイルの考えに従い、お客様の要求を確認しながら進めるようにします。

Q：IT部門とユーザー部門それぞれの意識改革はどのように行っているか

大変重要なポイントです。というのも、DXはユーザー部門だけで進めても成功することが難しく、IT部門の知恵を借りる必要があるからです。

逆に、ユーザー部門は業務に精通していますから、その知識を体系化したりITを活用することで、少ないリソースで最大の価値が出せるようなことを、お互いがよく話し合うことが重要です。

Q：経営層に対するアジャイルの理解や研修についてはどうか

費用対効果、具体的にはリスクベースで提案すると、多くの経営層は納得すると思いますし、私のこれまでの20年の経験でもそうでした。具体的には、最後にまとめて大きな金額を支払ったのにも関わらず、要求に沿ったものができないリスクがあること。

一方、アジャイルであれば少額の予算で、小さな要求を確認しながら進める開発であること。さらにその時点で、要求に沿っていなければ変更できることを提案します。

研修についてはいろいろありますが、本日紹介したような具体的な事例を説明することが多いです。まさに先ほどの内容ですが、範囲を限定し、小さく作るなどしてアジャストしていった方が、今の世の中の状況に合っており、ビジネスとして成功するといった内容を説明します。

Q: アジャイル開発に慣れていない現場への対応はどうしているのか

ウォーターフォールからアジャイルにシフトしたからといって、すぐに結果が出ないことを、特にユーザー部門の方々は認識しておくことが重要です。実際、アジャイルを導入したからといって、開発スピードが急に早くなったり、開発サイクルが短くなるとの結果は、すぐには出ないからです。

初回、2回目の開発では、ウォーターフォール開発での負債のようなものが表に出てきます。その出てきたものを、開発部門とユーザー部門が一緒に知恵を絞り合い、話し合うことが重要です。話し合いをすることで、その後の開発はより良くなっていくからです。

Q：戦略系のプロジェクトでもアジャイルの概念は使えるか

使えます。たとえば新規事業計画などは雲をつかむような業務であり、まさにリスクの塊ですから、できるだけ小さな段階でクイックに試すアジャイルの概念は重要です。

Q：緊急の機能追加や仕様変更はどう対応しているか

何でも受け入れるわけではありませんが、先ほど説明したように、アジャイルでは優先度が高いものから作っていきます。そのため変更内容がトレードオフできるものであれば、まずはメインの開発に絞り、後に変更を行います。

Q：スクラムについての意見を聞きたい

まず伝えたいのは、スクラムは万能の杖ではない、ということです。スクラムは課題を発見する方法論であり、スクラムを導入したからといって、課題が解決するわけではないからです。ただし優先度の決定などから、チームの意識改革の一助になる可能性はあると思います。

Q：実際、アジャイル開発でプロジェクトはうまく回るのか

アジャイルはあくまで方法論ではなく考え方ですので、その考えの背景にある知識やスキルを備えた メンバーで行わなければ、当然うまく回りません。

ただし、そのうまくいかなかった結果から学び、アジャイルの原則にもとづいて、何を優先すべきであるのか議論し皆が知恵を出し合い重ねていくことで、プロジェクトは次第にスムーズにまわるようになります。

Q：改革に対してネガティブなユーザー部門に対するアプローチはどうしているか

はじめから「アジャイルをやりましょう」というのではなく、まず何を目的に改革をするのか、どうありたいかを共有した上で、まずはターゲットとなるユーザ部門の業務やそこで働く人たちの思考や課題を知るために、実際に業務を行います。一緒に働く中で、雑談や業務を通して、改善すべき事案を見つけていきます。

その上で解決に際し、アジャイルの原則や考え方を活かすことが効果的であることを理解していただく。このような空気感を醸成することが重要だと思いますし、実際に私もそのようなアプローチをとってきました。

Q：誤課金が許されないシステムでは、アジャイルはフィットしないのでは？

金融システムなど、誤課金が許されないシステムにこそ、アジャイルの考えはフィットします。というのも、ミッションクリティカルな箇所こそ、先に徹底的に品質を確保しておく必要があるからです。

そして後から、アフターメンテナンスなどの箇所を、徐々に作り込んでいけばよいからです。実際、そのようなプロジェクトに携わったことがありますが、稼働後の不具合はゼロでした。

Q：ものづくりが重視されている環境では、どうアプローチすればよいか

リスクが高いところから優先付けして途上検証しふりかえり工夫するアプローチをとる場合、最初は思うように生産性や品質があがらないことがあります。ただし、途上の検証やふりかえりで工夫の余地が見えると次のイテレーションでは生産性や品質が少しずつ良くなっていきます。通常のプロジェクトでは、むしろこの生産性と品質が悪い状態がずっと続いているのにふりかえりも工夫もされず、人海戦術や残業などで隠されていることが多いかと思います。ユーザ部門の方は、目先の進捗にこだわるのではなく、最初に小さく実施することで早めにリスクを顕在化させていることを理解いただき、それが早くわかって対処ができていることの方が重要であることを理解することです。。

さらにリスクの高いものは一度のアプローチでうまくいかないケースも多いですから、そこはユーザー部門がIT部門に歩みより、共によりスピーディーに解決する。そのような協力体制が必要だと思います。