2019/10/152019年9月11日に開催された「基礎と実例から探る、ビジネスとITを変革するアジャイル活用とは」。イベントには、アビームコンサルティングの安藤裕介ダイレクター、下田友嗣マネージャーが登壇。前半のプレゼンテーションではアジャイルの本質ならびに導入事例などを紹介した。後半の公開Q&Aでは、参加者からの問いに2人が回答。初心者アビームコンサルティング【講演】アジャイルは方法論(教科書)ではなく、考え方やエッセンスまずはアビームコンサルティングの安藤裕介氏が登壇。アジャイルの考え方やエッセンス、導入を進める上での課題、実際の導入事例などを紹介した。幅広い業界、かつ数十人規模から1000人を超えるビッグプロジェクトまで、さまざまなシステム・サービスの構築に従事してきたという安藤氏。その豊富な経験から、炎上したプロジェクト対策も含め、ビジネスをクイックに成功させるには、ある一定のセオリーがあることが次第に分かっていった。そのセオリーがアジャイルなのだが、安藤氏いわく「これまではあえて『アジャイル』という言葉を使わなかった」とのこと。その理由は、アジャイルの本質にあるからだと説明した。「結論から言えば、アジャイルはその通りに実行すればプロジェクトがうまくいく、教科書や方法論ではありません。すればプロジェクトを成功に導くことができるか。プロジェクトに取り組む姿勢やエッセンスがアジャイルの本質だからです。『アジャイル=スクラム』との考えも正しくないですし、同じくドキュメントを作ってはいけない。計画はきちんとしてなくてよい。このような捉え方も、全て勘違い。正確に説明すれば、スクラムはあくまでアジャイルの中の一つのエッセンスであり、イコールではありません。アジャイルを導入さえすればプロジェクトがうまく運ぶだろう。このような考えも正しくありません」(安藤氏)安藤氏は、アジャイルの起源についても言及した。今から20年以上前、システム開発などに携わる17人のメンバーが、それまでのプロジェクト開発でうまくいったエッセンスをまとめあげたマニュフェストであり、具体的には4つの指針と、12の原則で構成している。マニュフェストにおいては原文が載っているリンクを貼っておく。安藤氏が紹介したスライド以外にも、日本語に訳されたものなど多くの資料が出回っているので、深く知りたい方は調べてみることをお勧めする。●アジャイルマニュフェスト原文ページ基本的な考えとして、何をしたらいけない、ダメということはない。なく、現状の方法よりもベターなやり方を示していることがポイントだと安藤氏は繰り返し説明した。【4つの指針】1:マニュアルよりも、個人同士の対話を重視しよう。2:管理するだけや量を意識したドキュメントではなく、本当に必要なドキュメントをラフでもいいから作ろう。3:契約でガチガチに縛るのではなく、顧客と協調・譲歩しながらプロジェクトを進めよう。4:計画を遵守するよりも、都度のフィードバックから計画は柔軟に変化させよう。見て分かる通り、当たり前のことばかりである。安藤氏もそのことを何度も強調する一方で、これまでの自身の経験から、次のように述べた。「当たり前のことだからこそ、継続するのが難しいのです。実際、これまで携わってきた40ほどのプロジェクトで、実行できていたのは2つか3つです。目指すことに意義があり、そのような心持ちでプロジェクトに取り組むことで、成功確率は上がります」(安藤氏)もうひとつ、アジャイルは小規模かつ、昨今のDX絡みのプロジェクトに向いていると思われがちだが、これも勘違いだと指摘。先のマニュフェストが策定されたときにはクラウドなどはなく、いわゆる旧来の大規模レガシィシステムが全盛であったこと。メンバーの中には大規模システムはもちろん、オブジェクト指向のメンバーなど、さまざまな属性のメンバーがいたこと。安藤氏自身の実績からも、デジタル、ノンデジタル、組織やシステムの大小関係なく、適用できることを強調した。今、アジャイルなのか先に書いた通り、20年以上前から存在していたアジャイルが、なぜ今、これほどまでに注目されているのか。既存ビジネスが抱える以下の問題を解決するのに、アジャイルが適しているからだと安藤氏は説明した。・ディスラプターの出現・求められる変革スピード・ビジネススピードを阻害する新旧のレガシィ例えば、新しい技術の台頭による人材不足においては、自社4000人の中でも、全ての技術に精通しているのはわずか数名だという。プロジェクト経験の不足については、特に大規模プロジェクトの経験者不足を指摘した。会場の参加者に、100人月以上、300人月以上、1000人月以上のプロジェクトへの参加経験を問うと、300人月以上では1、2名。1000人月以上での経験はゼロと、安藤氏が指摘した通りであった。終盤では、実際にアジャイルで成功した事例を3つ紹介した。スパゲッティコード対策レガシィシステムなどで見られる、プログラムの順序や構造が複雑に入り組んでいて、整理されていない、しようとしても難しいスパゲッティコード対策の事案だ。安藤氏は以下のようにアジャイルを意識しながら進めることで、解決したと紹介。先の12原則に当てはめれば、「7動くものでは実測・実証」「9技術卓一優れた設計」あたりが該当することになる。次の事例はシステムのアーキテクチャではなく、“人”のアーキテクチャによる課題解決例だ。大規模なシステムになればなるほど、自社、ベンダー、顧客など。多数の人が介在することになり、その結果、さまざまなトラブルや問題が発生する。決裁が降りない、担当ベンダーの1社が多忙過ぎてスケジュールに対応しない、全体のアーキテクチャがなかなか定まらない、などだ。このような組織の問題もアジャイルを導入することで解決に導けるという。決裁においては、最低限必要なサービスから決裁することで解決とする。プロジェクトを小さく分割することで、承認をもらいやすくするわけだ。アーキテクチャにおいては、後からでも設計変更が可能な仕様とする。ボトルネックとなっているベンダーについては、そのベンダーの関与を最小限に抑えた設計とする、といった具合だ。1の事例と同じく12原則に当てはめれば、「2変更を味方に」「3短期リリース」「10シンプルでムダなく」あたりが該当することになる。ベンダー同士のプロジェクトへの参加姿勢についても、先のアジャイルの通りの考えを示した。「ベンダーが多ければ多いほど、メールのやり取りなどで問題が生じる場合があります。そこでアジャイルに則り、オンラインではなく、リアルな場でフェイス・トゥ・フェイスで意見を出し合うことで解決に導きます。結局のところ、同じゴールを目指している仲間ですから、何度か実際に顔を合わせていくうちに、次第にお互いが納得した上で、良き協業関係となっていくことを、私はこれまで何度も経験してきました。役割分担においても、今お話しした通りお互いが直接会い、机上で徹底的に意見交換することで、その後のトラブルがないようにしておきます。このフェイス・トゥ・フェイスの考えは、プロジェクトがスタートしてからも同じです。問題があったら集まり話す――。現行業務も仕様も不明3番目は最も難しかった事案で、2001年から着手し、プロジェクトが終了したのは2018年。現行業務も仕様も不明だが、数千人規模のシステムを既存レガシィから新しいものに刷新するプロジェクトだ。ポイントは、一度に全てのシステムを置き換えるのではなく、段階を踏んで、新しいシステムに置き換えていったこと。段階的にした理由は、一度で刷新しようとすると、どうしてもビジネスをストップする必要があるからとのこと。12原則「1顧客価値優先」の思考だ。5ステップ全ての段階で移行が終了したら、計算エンジン、データモデル、UI、機能性など。あらゆる点で、徹底的にかつ早期に反復チェックを行い、問題があれば改善。原則に照らし合わせれば「12定期的な振り返りと改善」に該当する。仮にその改善で工期が伸びたとしても、無理せず、最善のシステムを構築することに主眼を置き進めたという。「過度の残業、徹夜は論外」と安藤氏はきっぱりと言った。先の講演を踏まえ、参加者からアジャイルに関する質問を付箋に記入する形で寄せられた。各人が書いた質問は、同じテーブルに座っている参加者と共有し合い、チームの質問として優先順位をつけ発表。出された問いに、安藤氏ならびに当日モデレーター的な役割を担った、下田氏が回答。下田氏は会場に拍手を要求したり、時折りジョークを交えるなど、公開Q&Aは盛り上がった。安藤:先ほどの講演ではまるで失敗がなく、スムーズに進んだように説明しましたが、実際の現場ではそんなことは決してなく、皆さんがふだんのシステム開発でぶつかっている困難と同じように、さまざまな問題が生じます。具体的には、メンバーがお互いの様子をうかがったり、ドキュメントが全くダメだったり、といったことです。これらの困難や壁は、発生することが分かっています。言い方を変えれば、失敗することは仕方のないことだと捉え、その失敗を最小限にとどめます。大規模プロジェクトの場合は人数に比例して指数関数的に問題が生じますから、小さいプロジェクトでまわし、問題の芽は小さいうちに摘んでおく。繰り返しになりますが、これがアジャイルの考えです。言い方を変えれば、システムが最低限稼働するミニマムの設計をどんどん実行していき、そのレビューを頻繁に繰り返すのです。今まさに2800人月のプロジェクトを担当していますが、2日、2週間といった単位で、失敗を表に出すフィードバックループをまわしています。後者の質問の答えは、「アジャイルが合わない開発はひとつもない」です。現状うまくいっている開発に、無理に導入する必要はありません。下田:大規模プロジェクトの場合は、見積りや計画において、やった気になっていることが少なくありません。言い方を変えれば、ざっくりとした計画の場合が多い。どこまででできるのか、限界を認識することが重要です。Q2:アジャイルに理解してくれない顧客への対応A:具体的な成果を丁寧に説明する安藤:「アジャイルの方がいいのでは?」とお客様の方から提案いただくケースが、ここ2年ほどで増えてきました。一方でご質問のように、未だにアジャイルの採用に対して不安をお持ちのお客様もいます。そのような顧客には、何となくアジャイルがいいと曖昧に答えるのではなく、具体的に何がどういいのか。説明するようにしています。このようなこともあり、冒頭お話したように私はあえてアジャイルという言葉を使っていないのです。こんな不安をもらいます。「ユーザーフィードバックループをたくさんやるということは、ユーザーの負荷がかかるのではないか?」。実際は、ミニマムのフィードバックループで得たシナリオを量産化していきますから、逆に、顧客の負担は減ります。全てが完成してからまとめて確認してもらうよりも、ミニマムの段階で確認してもらった方が、負担が低いのは明らか。このようなことを丁寧に伝えることを意識しています。下田:安藤の補足になりますが、バランス、費用対効果を皮切りに説明するといいと思います。Q3:講演の事例3など、大規模レガシィシステムについて。それほど大規模でかつブラックボックス化しているシステムだと、全容を解明するまでにかなりの時間がかかるのではないか。A:メインストリームならびにキーパーソンを探る安藤:全部のシステムを一つひとつチェックする必要はありませんし、全てのシステムを変える必要もありません。大切なのは、顧客企業のビジネスにおけるメインストーリーを見つけること。ポイントは、変化や代謝が激しい領域です。見つけたら、繰り返しになりますが、サービスがスタートできる最低限の機能を同じく考えるわけですが、先のメインストーリーも含め、ここはじっくり時間をかけて探ります。実際、私たちも半年ほどかかることがあります。――ビジネスサイドがどれだけ協力してくれるか問題。どのように対応すればよいか。Aligned)」との言葉も候補に挙げていたそうです。ビジネスと共に歩む、という意味です。ITを導入しようではなく、業績を上げるためには何をしなければいけないのか、その上でビジネスはどのように展開しいくべきなのか。このことを、ビジネスサイドと一緒になって考える取り組みが必要だと思います。安藤:大抵は想いを持っている人がいますから、その人にリーチし全社的に動かすのがいいでしょう。そのようなキーパーソンは経営層に限りません。現場のベテラン社員であったりもします。我々はその人物を探すために、とにかく足を使って、徹底的に歩き回ることを意識しています。このようなキーパーソンを見つけることは、顧客だけでなくベンダーにも当てはまります。ビジネスサイドも含め、何をすることが会社、プロジェクトにおいて一番大事なのかも明らかにします。仮に、このあたりがモヤモヤしている案件だったり、経営層がしっかりと意思決定できない場合には、ご依頼をお断りすることもあります。Q4:社内に対して、アジャイル採用をどうやって説得するのかA:前後の実績を定量データで示す安藤:これまでの開発手法との違いを、生産性、不具合の発生率などでデータ化し、示します。アジャイル経験のない7名ほどのメンバーで、アジャイルとは特に言わず、プロジェクトを実行。その実績を2週間に一度ほどデータとして収集すると、約2倍の効果があることが分かりました。先ほどのユーザーレビューにおいても、ミニマムにレビューしてもらったケース、後からまとめて確認してもらったとき。どちらが多く時間がかかっているかを数値化し、説得力を持たせます。下田:振り返りのときは、必ず定量データを使うようにします。日頃からストップウォッチで時間を測るなど、定量データを蓄積することが重要です。Q5:開発コストについて知りたい(発注サイドで)A:安価なテストプロジェクトで様子を探る安藤:いきなり本番のシステムをお願いするのではなく、100万円、200万円ぐらいのテスト案件をお願いし、その品質ならびに費用、生産効率などもあわせて提出してもらいます。仮に、品質はよいけれど価格が高い場合は、外注費なども含め、改めてフィードバックしてもらうこともあります。何が出来上がってくるかが分からない」という声をよく聞きます。発注サイドとしてこのような状態は健全ではありません。ITの活用などテクノロジーの部分も含め、何のために構築するシステムであり、完成するとビジネスにどう貢献するのか。アジャイル関係なく、その点はしっかり確認するべきだと思います。Q6:最初の見積りの出し方(受注サイド)A:小さな設計で探る安藤:1日でも2日でも構わないので、実際にどれくらいの時間で何ができるのかを、しっかりと測り、見積りの参考とします。――その1日2日の予算は持ち出しとなるのか。安藤:私の場合は持ち出してやっていました。会社からは「ムダな時間だ」と怒られましたが、私としては大きなリスクを抱えたまま請け負うことの方がリスキーだと考え上での決断でした。各人の判断で決めることだと思います。先方に予算を請求することは難しいでしょう。Q7:アジャイルの本質はチームビルディングという理解で合っているかA:正解です。