アビームの現役コンサルタントが基礎と実例から語る「ビジネスとITを変革するアジャイル活用」とは

【講演】アジャイルは方法論（教科書）ではなく、考え方やエッセンス

まずはアビームコンサルティングの安藤裕介氏が登壇。アジャイルの考え方やエッセンス、導入を進める上での課題、実際の導入事例などを紹介した。

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

SIer時代から数えると、20年以上にわたり、金融、流通、公共、社会基盤などの幅広い業界、かつ数十人規模から1000人を超えるビッグプロジェクトまで、さまざまなシステム・サービスの構築に従事してきたという安藤氏。

その豊富な経験から、炎上したプロジェクト対策も含め、ビジネスをクイックに成功させるには、ある一定のセオリーがあることが次第に分かっていった。そのセオリーがアジャイルなのだが、安藤氏いわく「これまではあえて『アジャイル』という言葉を使わなかった」とのこと。その理由は、アジャイルの本質にあるからだと説明した。

「結論から言えば、アジャイルはその通りに実行すればプロジェクトがうまくいく、教科書や方法論ではありません。どうすればプロジェクトを成功に導くことができるか。プロジェクトに取り組む姿勢やエッセンスがアジャイルの本質だからです。 ですから『アジャイル＝スクラム』との考えも正しくないですし、同じくドキュメントを作ってはいけない。計画はきちんとしてなくてよい。このような捉え方も、全て勘違い。
正確に説明すれば、スクラムはあくまでアジャイルの中の一つのエッセンスであり、イコールではありません。同じく、アジャイルを導入さえすればプロジェクトがうまく運ぶだろう。このような考えも正しくありません」（安藤氏）

安藤氏は、アジャイルの起源についても言及した。今から20年以上前、システム開発などに携わる17人のメンバーが、それまでのプロジェクト開発でうまくいったエッセンスをまとめあげたマニュフェストであり、具体的には4つの指針と、12の原則で構成している。

マニュフェストにおいては原文が載っているリンクを貼っておく。また安藤氏が紹介したスライド以外にも、日本語に訳されたものなど多くの資料が出回っているので、深く知りたい方は調べてみることをお勧めする。

●アジャイルマニュフェスト原文ページ

基本的な考えとして、何をしたらいけない、ダメということはない。そうではなく、現状の方法よりもベターなやり方を示していることがポイントだと安藤氏は繰り返し説明した。

【4つの指針】
①：マニュアルよりも、個人同士の対話を重視しよう。
②：管理するだけや量を意識したドキュメントではなく、本当に必要なドキュメントをラフでもいいから作ろう。
③：契約でガチガチに縛るのではなく、顧客と協調・譲歩しながらプロジェクトを進めよう。
④：計画を遵守するよりも、都度のフィードバックから計画は柔軟に変化させよう。

【12の原則】
①顧客価値優先
②変更を味方に
③短期リリース
④ビジネスとITの協業
⑤サーバーントリーダーシップ
⑥フェイス・トゥ・フェイス
⑦動くものでは実測・実証
⑧持続可能なペース
⑨技術卓一優れた設計
⑩シンプルでムダなく
⑪心理的安全・チーム
⑫定期的な振り返りと改善

見て分かる通り、当たり前のことばかりである。安藤氏もそのことを何度も強調する一方で、これまでの自身の経験から、次のように述べた。

「当たり前のことだからこそ、継続するのが難しいのです。実際、これまで携わってきた40ほどのプロジェクトで、実行できていたのは2つか3つです。ただ目指すことに意義があり、そのような心持ちでプロジェクトに取り組むことで、成功確率は上がります」（安藤氏）

もうひとつ、アジャイルは小規模かつ、昨今のDX絡みのプロジェクトに向いていると思われがちだが、これも勘違いだと指摘。先のマニュフェストが策定されたときにはクラウドなどはなく、いわゆる旧来の大規模レガシィシステムが全盛であったこと。メンバーの中には大規模システムはもちろん、オブジェクト指向のメンバーなど、さまざまな属性のメンバーがいたこと。そして安藤氏自身の実績からも、デジタル、ノンデジタル、組織やシステムの大小関係なく、適用できることを強調した。

なぜ今、アジャイルなのか

先に書いた通り、20年以上前から存在していたアジャイルが、なぜ今、これほどまでに注目されているのか。既存ビジネスが抱える以下の問題を解決するのに、アジャイルが適しているからだと安藤氏は説明した。

【既存ビジネスが抱える課題】
・ビジネス要求をまとめられるユーザーの減少
・ビジネスルールのブラックボックス化
・次々と出現する新しい技術に対する人材不足
・ビジネスとITの分離・縦割組織・調整役不足
・プログラム・プロジェクトマネジメント経験者の不足
・ディスラプターの出現・求められる変革スピード
・ビジネススピードを阻害する新旧のレガシィ

例えば、新しい技術の台頭による人材不足においては、自社4000人の中でも、全ての技術に精通しているのはわずか数名だという。またプロジェクト経験の不足については、特に大規模プロジェクトの経験者不足を指摘した。

会場の参加者に、100人月以上、300人月以上、1000人月以上のプロジェクトへの参加経験を問うと、300人月以上では1、2名。1000人月以上での経験はゼロと、安藤氏が指摘した通りであった。

アジャイルを導入した3つの事例

終盤では、実際にアジャイルで成功した事例を3つ紹介した。

1. スパゲッティコード対策

レガシィシステムなどで見られる、プログラムの順序や構造が複雑に入り組んでいて、整理されていない、しようとしても難しいスパゲッティコード対策の事案だ。安藤氏は以下のようにアジャイルを意識しながら進めることで、解決したと紹介。先の12原則に当てはめれば、「⑦動くものでは実測・実証」「⑨技術卓一優れた設計」あたりが該当することになる。

空いている時間を使って、障害の多発地帯を見極める
　▼
高品質・保守性の高いアーキテクチャにリモデリングする
　▼
反復計画・フィードバックループを繰り返す

2. 組織構造的な課題の対策

次の事例はシステムのアーキテクチャではなく、“人”のアーキテクチャによる課題解決例だ。大規模なシステムになればなるほど、自社、ベンダー、顧客など。多数の人が介在することになり、その結果、さまざまなトラブルや問題が発生する。

決裁が降りない、担当ベンダーの1社が多忙過ぎてスケジュールに対応しない、全体のアーキテクチャがなかなか定まらない、などだ。このような組織の問題もアジャイルを導入することで解決に導けるという。

決裁においては、最低限必要なサービスから決裁することで解決とする。つまり、プロジェクトを小さく分割することで、承認をもらいやすくするわけだ。アーキテクチャにおいては、後からでも設計変更が可能な仕様とする。

ボトルネックとなっているベンダーについては、そのベンダーの関与を最小限に抑えた設計とする、といった具合だ。①の事例と同じく12原則に当てはめれば、「②変更を味方に」「③短期リリース」「⑩シンプルでムダなく」あたりが該当することになる。

またベンダー同士のプロジェクトへの参加姿勢についても、先のアジャイルの通りの考えを示した。

「ベンダーが多ければ多いほど、メールのやり取りなどで問題が生じる場合があります。そこでアジャイルに則り、オンラインではなく、リアルな場でフェイス・トゥ・フェイスで意見を出し合うことで解決に導きます。

結局のところ、同じゴールを目指している仲間ですから、何度か実際に顔を合わせていくうちに、次第にお互いが納得した上で、良き協業関係となっていくことを、私はこれまで何度も経験してきました。

また役割分担においても、今お話しした通りお互いが直接会い、机上で徹底的に意見交換することで、その後のトラブルがないようにしておきます。そしてこのフェイス・トゥ・フェイスの考えは、プロジェクトがスタートしてからも同じです。問題があったら集まり話す――。この反復が重要です」（安藤氏）

3. 現行業務も仕様も不明

3番目は最も難しかった事案で、2012年から着手し、プロジェクトが終了したのは2018年。現行業務も仕様も不明だが、数千人規模のシステムを既存レガシィから新しいものに刷新するプロジェクトだ。

ポイントは、一度に全てのシステムを置き換えるのではなく、段階を踏んで、新しいシステムに置き換えていったこと。段階的にした理由は、一度で刷新しようとすると、どうしてもビジネスをストップする必要があるからとのこと。まさに12原則「①顧客価値優先」の思考だ。

また5ステップ全ての段階で移行が終了したら、計算エンジン、データモデル、UI、機能性など。あらゆる点で、徹底的にかつ早期に反復チェックを行い、問題があれば改善。原則に照らし合わせれば「⑫定期的な振り返りと改善」に該当する。

仮にその改善で工期が伸びたとしても、無理せず、最善のシステムを構築することに主眼を置き進めたという。「過度の残業、徹夜は論外」と安藤氏はきっぱりと言った。

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

先の講演を踏まえ、参加者からアジャイルに関する質問を付箋に記入する形で寄せられた。各人が書いた質問は、同じテーブルに座っている参加者と共有し合い、チームの質問として優先順位をつけ発表。出された問いに、安藤氏ならびに当日モデレーター的な役割を担った、下田氏が回答。下田氏は会場に拍手を要求したり、時折りジョークを交えるなど、公開Q＆Aは盛り上がった。

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

Q1：いろいろなシステム開発でアジャイルは適用できるとのことだったが、大規模システム開発での困難点、特にアジャイルの特性が活かせるプロジェクトを知りたい

A：アジャイルはあらゆるプロジェクトに対応可能

安藤：先ほどの講演ではまるで失敗がなく、スムーズに進んだように説明しましたが、実際の現場ではそんなことは決してなく、皆さんがふだんのシステム開発でぶつかっている困難と同じように、さまざまな問題が生じます。具体的には、メンバーがお互いの様子をうかがったり、ドキュメントが全くダメだったり、といったことです。

ただ、これらの困難や壁は、発生することが分かっています。言い方を変えれば、失敗することは仕方のないことだと捉え、その失敗を最小限にとどめます。特に、大規模プロジェクトの場合は人数に比例して指数関数的に問題が生じますから、小さいプロジェクトでまわし、問題の芽は小さいうちに摘んでおく。繰り返しになりますが、これがアジャイルの考えです。

言い方を変えれば、システムが最低限稼働するミニマムの設計をどんどん実行していき、そのレビューを頻繁に繰り返すのです。今まさに1800人月のプロジェクトを担当していますが、2日、2週間といった単位で、失敗を表に出すフィードバックループをまわしています。

ですから後者の質問の答えは、「アジャイルが合わない開発はひとつもない」です。もちろん現状うまくいっている開発に、無理に導入する必要はありません。

下田：大規模プロジェクトの場合は、見積りや計画において、やった気になっていることが少なくありません。言い方を変えれば、ざっくりとした計画の場合が多い。特に、どこまででできるのか、限界を認識することが重要です。

Q2：アジャイルに理解してくれない顧客への対応

A：具体的な成果を丁寧に説明する

安藤：「アジャイルの方がいいのでは？」とお客様の方から提案いただくケースが、ここ2年ほどで増えてきました。一方でご質問のように、未だにアジャイルの採用に対して不安をお持ちのお客様もいます。

そのような顧客には、何となくアジャイルがいいと曖昧に答えるのではなく、具体的に何がどういいのか。きちんと説明するようにしています。このようなこともあり、冒頭お話したように私はあえてアジャイルという言葉を使っていないのです。

たとえば、こんな不安をもらいます。「ユーザーフィードバックループをたくさんやるということは、ユーザーの負荷がかかるのではないか？」。

しかし実際は、ミニマムのフィードバックループで得たシナリオを量産化していきますから、逆に、顧客の負担は減ります。また全てが完成してからまとめて確認してもらうよりも、ミニマムの段階で確認してもらった方が、負担が低いのは明らか。このようなことを丁寧に伝えることを意識しています。

下田：安藤の補足になりますが、バランス、費用対効果を皮切りに説明するといいと思います。

Q3：講演の事例3など、大規模レガシィシステムについて。それほど大規模でかつブラックボックス化しているシステムだと、全容を解明するまでにかなりの時間がかかるのではないか。

A：メインストリームならびにキーパーソンを探る

安藤：全部のシステムを一つひとつチェックする必要はありませんし、全てのシステムを変える必要もありません。大切なのは、顧客企業のビジネスにおけるメインストーリーを見つけること。ポイントは、変化や代謝が激しい領域です。

見つけたら、繰り返しになりますが、サービスがスタートできる最低限の機能を同じく考えるわけですが、先のメインストーリーも含め、ここはじっくり時間をかけて探ります。実際、私たちも半年ほどかかることがあります。

――ビジネスサイドがどれだけ協力してくれるか問題。どのように対応すればよいか。

下田：アジャイルを生み出した先の17名は、名称を決める際「ビジネスアラインド（Business Aligned）」との言葉も候補に挙げていたそうです。ビジネスと共に歩む、という意味です。

つまりITを導入しようではなく、業績を上げるためには何をしなければいけないのか、その上でビジネスはどのように展開しいくべきなのか。このことを、ビジネスサイドと一緒になって考える取り組みが必要だと思います。

安藤：大抵は想いを持っている人がいますから、その人にリーチし全社的に動かすのがいいでしょう。ただそのようなキーパーソンは経営層に限りません。現場のベテラン社員であったりもします。

だから我々はその人物を探すために、とにかく足を使って、徹底的に歩き回ることを意識しています。そしてこのようなキーパーソンを見つけることは、顧客だけでなくベンダーにも当てはまります。

もうひとつ。ビジネスサイドも含め、何をすることが会社、プロジェクトにおいて一番大事なのかも明らかにします。仮に、このあたりがモヤモヤしている案件だったり、経営層がしっかりと意思決定できない場合には、ご依頼をお断りすることもあります。

Q4：社内に対して、アジャイル採用をどうやって説得するのか

A：前後の実績を定量データで示す

安藤：これまでの開発手法との違いを、生産性、不具合の発生率などでデータ化し、示します。たとえばアジャイル経験のない7名ほどのメンバーで、アジャイルとは特に言わず、プロジェクトを実行。その実績を2週間に一度ほどデータとして収集すると、約2倍の効果があることが分かりました。

また先ほどのユーザーレビューにおいても、ミニマムにレビューしてもらったケース、後からまとめて確認してもらったとき。どちらが多く時間がかかっているかを数値化し、説得力を持たせます。

下田：振り返りのときは、必ず定量データを使うようにします。日頃からストップウォッチで時間を測るなど、定量データを蓄積することが重要です。

Q5：開発コストについて知りたい（発注サイドで）

A：安価なテストプロジェクトで様子を探る

安藤：いきなり本番のシステムをお願いするのではなく、100万円、200万円ぐらいのテスト案件をお願いし、その品質ならびに費用、生産効率などもあわせて提出してもらいます。仮に、品質はよいけれど価格が高い場合は、外注費なども含め、改めてフィードバックしてもらうこともあります。

下田：「予算は高い。でも何が出来上がってくるかが分からない」という声をよく聞きます。正直、発注サイドとしてこのような状態は健全ではありません。ITの活用などテクノロジーの部分も含め、何のために構築するシステムであり、完成するとビジネスにどう貢献するのか。アジャイル関係なく、その点はしっかり確認するべきだと思います。

Q6：最初の見積りの出し方（受注サイド）

A：小さな設計で探る

安藤：1日でも2日でも構わないので、実際にどれくらいの時間で何ができるのかを、しっかりと測り、見積りの参考とします。

――その1日2日の予算は持ち出しとなるのか。

安藤：私の場合は持ち出してやっていました。会社からは「ムダな時間だ」と怒られましたが、私としては大きなリスクを抱えたまま請け負うことの方がリスキーだと考え上での決断でした。ただこれは、人それぞれ。各人の判断で決めることだと思います。ただ先方に予算を請求することは難しいでしょう。

Q7：アジャイルの本質はチームビルディングという理解で合っているか

A：正解です。良きシステム・サービスを構築したいとの全メンバーの意見合致が重要

安藤：合っています。たとえば受注側の場合。発注サイドから「いい人材をとにかく安い値段で」と、ただの一業者として、ある意味買い叩かれているような関係性では、人間関係はもちろん、いい成果物が生まれるとは考えにくいですよね。

一方、お金のことは二の次で、発注・受注といった立ち位置なども特に気にせず、いいものを一緒になって作ろう。そのような考えの関係会社ならびにメンバーとは、良き関係が構築でき、その後のビジネスの繋がりも生まれものです。そしてこのことはまさにアジャイルマニフェスト、サーバーントリーダーシップそのものでもあります。

私の前職は200名ほどのSIerで、案件の多くは二次請けでした。しかし良いものを作りたい想いが強く、直接顧客に要求をヒアリングするなど、業務の範疇を超えるようなこともしていました。

今考えれば余計なお節介だったかもしれませんし、会社にとってはリスキーだったかもしれませんが、そのような姿勢で仕事をしていたことで、お客様のモチベーションが上がったことが何度もありました。

また同じような考えを持つ仲間もできました。そしてそのような仲間が多くいる現場では、プラスのムーブメントが生まれ、結果としてプロジェクトが成功することを何度も味わいました。

発注側だから、受注側だから、二次請請けだから。このような思考は、良いシステムを開発する上では、全く関係のないことだと思います。