先日、メンバーズエッジカンパニー主催でアジャイル開発をテーマにしたウェビナー「VUCA時代到来！ アジャイルを成功させるために大切な3つのこと」を開催しました。
登壇していただいたのは、幣カンパニー技術顧問でもある中野安美さん。本記事ではウェビナーの内容をほぼそのままにまとめています。
アジャイル・スクラムについて基本的なところから解説していますので、基礎知識をおさらいしたい！という方におすすめです。
目次
中野さんのご経歴
Agility Design株式会社 代表取締役の中野安美さん。メンバーズエッジカンパニーの社外アジャイルコーチでもあります。生命保険会社向けシステム開発のＰＭを経験後、アジャイル開発をスタートされました。Agile Japan2020の実行委員長でもあります。
今、なぜアジャイルなのか？
ビジネスの変化はますます速くなり、“VUCA”の時代へ
まず、なぜ昨今アジャイル開発が注目されているのか？という観点からの話です。
皆さんもご存知のとおり、現在のビジネスの状況はどんどん変化のスピードが早くなってきています。その中で、ビジネスにおけるITの存在価値は重要度を増し、IoTやAIなど最先端の技術を中心においてどのようなビジネスができるか？ということを考えなければいけない時代になってきました。
世の中では「VUCAの時代」になってきた、とも言われていますね。※VUCA=Volatility(変動性),Uncertainty(不確実性),Complexity(複雑性),Ambiguity(曖昧性)
変動要素が多くある中で模索してビジネスを成功に導かなければいけなくなってきています。
失われた30年
日本では「失われた30年」と言われているように、世界時価総額ランキングを見ると、30年前に上位を占めていた日本企業は現在はすっかりランキングから姿を消しました。今ではGAFAやマイクロソフトなどの世界的なIT企業が上位を占め、日本企業はトップ50位にトヨタしか入っていません。
日本企業の競争力は世界の中でどんどん落ちて行っている状態と言えます。今回の新型コロナウイルスへの各国の対応と比較し、日本ではデジタルを使った施策の遅れがかなり目立っていました。
新型コロナウイルスによるビジネス状況の変化
そんな中で、新型コロナウイルスにより今後大きく変わっていくと痛感している出来事もあります。日経新聞の記事によると、すでに官民合同でテックチームを立ち上げて、スタートアップや大手IT企業と一緒にデータ分析して感染拡大を防止する取り組みに向けた動きが始まっています。
日本では対面・書面・押印といったアナログ文化が基本となっており、これがすべての対応スピードを遅らせている要因となっているのですが、これをきっかけに日本でも世の中がどんどんデジタルシフトしていくと考えられます。
ソフトウェア開発のあり方が変化
今後、ソフトウェア開発のあり方が大きく変わっていくと考えています。
理由は２つあり、1つは先ほどお伝えしたようにプロダクトやプロセスも変わっていく状況下、IT技術もどんどん進化する中で、不確実性が非常に高い状況になっていること。
もう1つは、数年前から「モノ」から「コト」へと言われるようになってきていると思いますが、モノを提供するのではなく、それを使った後の価値提供をしていく、顧客中心の姿勢が求められるようになった点が挙げられます。
その2点を解決するために、アジャイルなアプローチをして小さく、早く世に出して検証して改善していくアプローチが求められるのです。
ウォーターフォールとアジャイルの違い
ウォーターフォール開発とは？
ウォーターフォール開発とは、最初に要件を決めた上でスコープ・期間・コストを見積もって開発を進めていく開発手法です。各工程ごとに成果物を作成し、品質保証して次の工程へ進めていきます。
ウォーターフォールのメリット・デメリット
ウォーターフォールのメリットとして、最初に要件を見積もるので決められた予算の中で開発できる。先の見通しがつきやすいといった点が挙げられます。
一方デメリットですが、プロジェクトの成功割合を調査したデータによると、ウォーターフォール型のプロジェクトが成功している割合は全体として16.2%、大企業では9%しかありません。80%は何らかの課題があるプロジェクトと言えます。
また、ソフトウェア機能の利用割合を調査したデータでは、64%がほとんどorまったく使われていないことが明らかになりました。作ったはいいが、外的な要因や業務が変更になったことで使われなくなってしまったり、年に1度しか使わない機能を作ってそれが陳腐化していくこともあります。使われない機能が積み重なって結果的に保守コストがかさんでいく要因にもなっているのではないでしょうか。
ウォーターフォール開発で起こっている課題
ウォーターフォール開発で起こっている課題を、段階ごとに整理してみました。
要件定義の課題
最初の要件定義の段階では、やはり要件決めに時間がかかっていると考えられます。ユーザー側も最新のIT技術を使って何ができるのかわからないので、要件を出せないこともあります。
もうひとつが、クラウドテクノロジーを理解したシステムアーキテクトの人材不足。クラウドネイティブな開発のエンジニアはどちらかというとスタートアップやWEB系サービスの企業には結構いるのですが、昔ながらの大手SIerにはかなり少ないです。
設計の課題
最近はやはりUIUX重視なので、設計段階ではユーザーインターフェイスが複雑化し、画面仕様が頻繁に変わってスケジュールが遅延していくということが起こりえます。
実装の課題
実装面では、工程別に開発者が変わることによって情報伝達ロスや戻り作業が発生する、開発規約のもと従前の開発手法を守り続けることにより、自動化など生産性・品質向上施策が進まないといった状況もあります。
テストの課題
前工程からのスケジュール遅延により、最終的な品質確認が内部結合テストになりがちであったり、複数チームで開発している場合、インターフェイスの認識齟齬などで手戻りが発生します。
受入検証の課題
やっとユーザーが実際に動くものを見る段階になると、「ボタンのサイズが・・・」など細かいところまで仕様変更が噴出して、最終的には仕様変更かバグかでお客さんともめる、といった状況もよくあるケースではないかと思います。
アジャイル開発とは？
アジャイル開発とは、ソフトソウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である、とされています。（wikipediaによる）
「アジャイル」という考え方の基に、スクラムやKanban、XPなどのさまざまな開発手法が存在しています。アジャイル開発では、それらのやり方を組み合わせて実現していくことになります。
アジャイルの歴史
アジャイルはトヨタ生産方式からはじまり、それをもとに1955年にスクラムガイドが作られました。1999年にXPエクストリーム・プログラミング入門、2001年にアジャイルソフトウェア開発宣言が発表されています。
アジャイルソフトウェア開発宣言
アジャイルソフトウェア開発宣言によると、重要視している点は大きく4つあります。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
左側のことがらに価値があることを認めながらも、右側のことがらに価値を置く、という考え方になります。
アジャイル宣言の背後にある１２の原則
アジャイル宣言の背後にある原則をご紹介します。
価値のあるソフトウェアを早く継続的に、要求の変更はたとえ開発の後期であっても歓迎、意欲に満ちた人々を集めてプロジェクトを構成、自己組織的なチーム・・・など、
アジャイルというのはプロセスではなく、こういった思想や考え方になります。
よくウォーターフォールとアジャイルは比べられるのですが、ウォーターフォールはプロセスであるのに対し、アジャイルはプロセスではなく考え方、マインドセットになりますので、そこの違いをきちんと理解することが大切です。
アジャイル開発で利用される手法
アジャイル開発では、下記のような手法を組み合わせて開発を進めていきます。
スクラム
- 1986年に発表された論文「The New NewProduct Development Game」をもとに、ジェフサザーランド氏らによって2003年にプラクティスがまとめられた
- 最近では、IT以外にも導入されているケースが増えている
ＸＰ（エクストリームプログラミング）
- 1999年ケントベック氏らによって発表された
- ５つの価値（コミュニケーション、シンプル、フィードバック、勇気、尊重）
- 19のプラクティス（反復、テスト駆動開発、ペアプログラミング、リファクタリングなど）
かんばん
- 方法論としてのかんばんと、ツールとしてのかんばんがある
- トヨタのJustInTime方式で後工程から前工程に対して指示する管理手法
- アジャイルでは、見える化するツールとしてかんばんを活用する
リーン/トヨタ生産方式
- ７つのムダ、JustIn Time
- 使わない機能をつくってないか?、価値あるものか?、プロセスのムダはないか?などムダを排除、カイゼンする文化・取り組み
ウォーターフォールとアジャイルの比較
ウォーターフォールは多くが請負開発になりますので、お客さんから要件を聞いてベンダー側でそれを開発して納品する、という図式になります。お客さんとベンダーの間には、壁があります。
アジャイルは、お客さんと一緒にタッグを組んで進めることになります。お客さんが実現したいビジネスゴールを理解したうえで、「Why」を両者で共有。何をプロダクトとしてつくるかをお客さんから「What」として出していき、開発メンバーはそれをどう実現するか「How」を出して一緒に協力しながら開発していきます。
もう少し細かく整理すると、ウォーターフォールはシステム、モノを完成させることがゴールになっていますが、アジャイルはどちらかというとビジネス価値を最大化することに観点をおきます。IT投資に対してビジネス価値、ROIを最大化できるかという点がポイントになります。アジャイルソフトウェア開発宣言にもあるとおり、ウォーターフォールはプロセス、アジャイルは人重視、という考え方の差もあります。
ウォーターフォールは最初に計画を立てるので、計画に従ってQCDが達成されたかどうかでマネジメントしていきますが、アジャイルは常に要求の変化を受け入れます。優先順位をつけながら、どうリリースに向けて収束していくかという予測をしながら進めていくことになります。
スクラムとは？
次に、アジャイルでよく採用されているスクラムのフレームワークについて解説していきます。
スクラムガイドでは複雑で変化の激しい問題に対応するためのフレームワークと書いてあります。スクラムでは3つの役割、5つのイベント、3つの成果物、といったやり方が定義されており、これは可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものです。
スクラムの特徴
スクラムは「3つの役割、5つのイベント、3つの成果物」しかないため、軽量で、理解が容易と言えます。一方で習得は困難であると言われています。何事も経験した上で、次のステップを考えるというのが基本的な考え方になります。
スクラムの大きな柱として「透明性」「適応」「検証」の３つがあります。
透明性は今ある状況を見える化していくということですね。何かものをつくって検証して、検証した結果フィードバックを受けて今後やることを適応させていくという形になります。
アジャイルやスクラムをはじめたときに、この「透明性」が機能してくると、人間関係やチームの問題、組織の問題など、いろいろな問題が浮き彫りになります。アジャイルやスクラムをはじめるとうまくいかない、というのは、この「透明性」により問題が必ず出てくるため、とも言えます。習得がなかなか困難で難しい、というのはそういう意味でもあるのです。
スクラムフレームワーク
スクラムフレームワークについて説明します。前述したようにスクラムは3つの役割、5つのイベント、3つの成果物から構成されています。
スクラムにおける3つの役割
プロダクトオーナー
プロダクトの責任者であり、プロダクトの価値（ROI）を最大化することがミッションです。プロダクトバックログの管理者として、プロダクトバックログアイテムの優先順位付けを行ないます。
スクラムマスター
ウォーターフォールにはない役割かと思いますが、チームが自律的に協働できるように、チームのパフォーマンスを上げることに責任を持ちます。ファシリテーター、推進役となって、スクラムチームの生産性を高めるよう変化を促したり、POや開発メンバーを支援します。
開発メンバー
バックログを開発・完了させていくことに責任を持ちます。上下関係なくお互いの強みを生かして助け合い、自律的に行動して自分たちでやり方を決定します。
スクラムにおける3つの成果物
プロダクトバックログ
プロダクトオーナーがビジネスプランやビジネス戦略をもとに、どんなサービスにするかという観点で作成した要求の一覧を、プロダクトバックログといいます。それぞれの要求事項のことを、プロダクトバックログアイテムと言います。管理者はプロダクトオーナーです。
スプリントバックログ
たとえば1スプリントを1週間とした場合に、その1週間でやるものをプランニングし、作業タスクとして落とし込んだものがスプリントバックログです。タスクボードを作成して優先順位がわかるように可視化します。
インクリメント
スプリントで完成された成果物のことをインクリメントといいます。完成の定義を満たすプロダクトバックログアイテムで、リリースできるレベルの状態であることが条件となります。
スクラムにおける5つのイベント
上記の3つの役割、3つの成果物を踏まえたうえで、スクラム開発の流れに沿って5つのイベントを解説していきます。
スプリントプランニング
開発は1週間から2週間のタイムボックスを切って回していくことになります。
それを「スプリント」と呼びます。このスプリントの計画を立てることを、スプリントプランニングと言います。開発対象のプロダクトバックログアイテムを決め、スプリントの作業タスクを計画します。
デイリースクラム
開発の状況は、デイリースクラムと呼ばれる1日15分程度のデイリーミーティングで、みんなで日々確認していきます。
スプリントレビュー
1週間の最後にはスプリントレビューを行います。チームからステークホルダー向けに説明してレビューを実施し、ステークホルダーからフィードバックを受けます。
フィードバックを経て変更があればまたプロダクトバックログに追加していきます。
スプリントレトロスペクティブ
いわゆる「ふりかえり」です。1週間の「つくったもの」ではなく「プロセス」や「人との関係」など運営面を振り返り、改善点の洗い出しをして次のアクションにつなげていきます。
バックログリファインメント
プロダクトバックログの手入れを行ないます。プロダクトバックログアイテムの詳細化を行い、プロダクトオーナーが優先順位をつけて並べます。開発チームはそれをもとに、優先順位の高いものから開発していきます。
アジャイルの失敗例と成功のポイント
アジャイル開発をはじめると、さまざまな問題が噴出してうまくいかないことが当たり前です。よくある悩みとしては、下記が挙げられるでしょう。
- スプリントで予定通り開発が完成しない
- プロダクトオーナーが忙しくあまり関与していない
- スクラムマスターって何したらいいかわからない
- ユーザーがスプリント途中で要件変更を繰返す
- チームの一体感がない、雰囲気がよくない
- 要件・予算・期間が決まっていて調整余地がない
これらの問題の原因を整理してみました。大きく3つあります。
アジャイル開発の主な失敗原因
特に、ウォーターフォールからアジャイルにシフトした場合の失敗原因として整理しています。
アジャイル・スクラムを理解していない
ウォーターフォールは「開発プロセス」ですが、スクラムのデイリーミーティングなどのやり方だけを取り入れて、なぜそれをやっているのかという背景や、アジャイルの考え方そのものを理解せずにプロセスだけ取り入れて失敗するパターンがあります。
また、ユーザー側が「アジャイルは仕様変更をいつでもできる」と勘違いしている、ということも。スクラムチームの外部であるステークホルダーや、ウォーターフォールにはない役割のプロダクトオーナーやスクラムマスターが、役割をきちんと理解していない場合もあり得ます。
従来開発から脱却できない
従来の受委託の関係性の意識が根強くしみこんでいるため、その意識を変えるのはなかなか難しいことです。お客様側からスコープ・リリース日・予算がすでに決まっている状態で、アジャイルで開発したいと言われるパターンもあります。このような場合は、そもそもアジャイルではできないことをまずお客様に説明して理解してもらう必要があります。
また、従来の開発ルールをいかに変更していくか、ということも大切だと思いますが、ルールだけ見てしまってなぜこのルールができているかという背景を見ていないと、今回そのルールを適応するか否か、という判断が正しくできない原因になります。
あとは、「システムをつくる」ことが目的になりがちで、ROIを最大化する、という意識がないことも挙げられます。本当に意味のある作業か、ということを意識していかないと、「いつもやってるから」というだけで無駄な作業が増えていくかもしれません。
アジャイル以外の原因
そもそもアジャイル以外に原因がある場合もあります。
たとえばマイクロサービスを開発するとなると、上流の設計工程から変わってくるわけですが、マイクロサービスのアーキテクトの経験があるエンジニアは市場に不足しています。そこを理解したうえで、どのように開発するかをアレンジしなければいけないのです。
新規サービス開発、UIUX、テスト自動化、DevOpsなどの新しい領域が未経験のメンバーばかりだと、アジャイルと言いつつもアウトプットできない状態になりがちです。特にアジャイルだと1週間などのスプリント単位で品質を担保するためにテストを自動化することは必須になりますが、経験があるメンバーがチームにいないと、その技術キャッチアップだけで時間をとられてしまいます。
あとは、組織のサイロ化です。アプリ・インフラ・運用が別組織の場合、組織の壁があるので調整に時間がかかり、アジャイルに、スピーディーに物事が進められなくなってしまいます。
アジャイルが難しい理由
アジャイルでは深く染み付いた従来の考え方や意識を変化させ、従来の行動を変革させる必要があります。しかし、潜在意識を変化させる・気づかせるところに時間がかかってしまい、結果、行動を変革させることが難しくなってしまうというわけです。
アジャイル成功には強いチームが必須
アジャイルを成功させるためには強いチームをつくることが必須です。明確で簡単には成し得ないゴールをチームとして共有して、なんとしても成し遂げようという強いコミットメントを持ったワンチームをつくるというのが重要です。チームメンバーが得意なスキルを持ち寄り、助け合いながらゴールを目指す状態が理想です。
チームの成長プロセスを表したタックマンモデルというものがあります。
スクラムでは透明性により、問題点が明らかになりますので、必ず混乱期を通過することになります。混乱期をいかに早く通過して強いチームにしていくかが肝で、そのためにはチームの立ち上げ期、形成期にチームビルディングをすることが重要です。
アジャイルを成功させるために大切なこと
特にウォーターフォールからアジャイルへ切り替える場合に大切なことを３つ挙げてみます。
アジャイル・スクラムを正しく理解する
まず第一歩として、アジャイル研修などを受けてアジャイルのマインドセットを正しく理解すること。マネージメント、人事部門、品質管理部門など、関係する人たちすべてが正しく理解していることが大切です。研修を受けただけでは腹落ちしませんので、実践の中で体感しながら理解を深めていくことが必要になります。
チームの目指すゴール・ＷＨＹを考えて全員が共有する
ビジネスとして成功させるものをつくらないと意味がありません。チームとして目指すところは何か、というのを一緒に考えて共有しておく必要があります。なぜ我々はこのプロダクトをやるのか、という点を全員がしっかり考えて共有すること、また、なぜアジャイルを導入するのかという点もしっかり共有していくことが大切です。それが、チームの目指すゴールを一致させることにつながります。
チームメンバーへ感謝を伝える
強いチームをつくるために、チームのメンバーにまず感謝を伝えるところからスタートすると、チームのメンバーのまとまりが早くなると思います。Googleが何年か前に「強いチームの共通点は心理的安全性が担保されていること」と言っていますが、相手が嫌がることも含めて話せる関係性をつくることが、心理的安全性になってきます。
やはりビジネスとして成功させるためにみんなが動いているので、厳しいことも言わないといけない場面も出てきます。つまり、言っても大丈夫な関係性をつくっていく必要があります。そのためには、メンバー一人ひとりをよく知って、その人が貢献してくれたことに感謝してそれを伝えて信頼関係を醸成していくことが、チームビルディングの一番大切なところではないかと思います。
おわりに
「アジャイルを成功させるために大切な3つのこと」というタイトルですが、アジャイルを成功させるために大切なことは本当にたくさんあります。今回、中野さんにはあえて3つに絞ってお話いただきました。個人的には「ウォーターフォールはプロセスであるのに対し、アジャイルはプロセスではなく考え方、マインドセットである」という点に改めて気づかされました。アジャイルを正しく理解することが、アジャイル開発を成功させる第一歩ではないでしょうか。
今回の記事を参考に、ぜひご自身やチームのアジャイル開発のあり方を見つめなおしていただけたら幸いです。
スクラムマスターについてより実践的な話が知りたい方は、こちらの記事もおすすめです。
スクラムマスターがスクラムチームを立ち上げる時に意識すること
「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に自分なりの考えを持って答えてみた
