要チェック！DXで盛り上がる「アジャイル開発手法」の使いどころ【後編】―開発チームのパフォーマンスを上げる手法は全てのチームのためになる！？
本稿の前編では、アジャイル開発とは何かと、その動向についてご紹介しました。後編では、アジャイル開発の方法論を、ソフトウェア開発以外の業務に適用することの有効性について考察します。
▶ 前編はこちら
要チェック！DXで盛り上がる「アジャイル開発手法」の使いどころ【前編】―アジャイル開発が必要とされる理由とは？
例えば、アジャイル開発の考え方に大きな影響を与えたとされる方法論の一つに「エクストリーム・プログラミング（以下、XP）」と呼ばれるものがあり、その手法の一つに「ペア・プログラミング」があります。これは文字どおり、2人一組になってプログラミングを行うというものです。形式は、2人のうち一人がプログラムを記述し、もう一人がその評価や品質のチェックをほぼ同時並行で行うというもので、両者の役割を交代させながら作業を進めていきます。
常識的に考えると、2人が1つのプログラムを作るわけですから、それぞれがプログラミングを行う場合に比べて生産性が2分の1に低下するように思えます。ところが実際にはそのようなことはなく、ペア・プログラミングの実践によって、より品質の高いプログラムが、よりスピーディーに生産できるようになり、かつ、ペアを組む2人の間で相手に迷惑をかけたくないという意識が自ずと芽生え、スケジュールどおりにプログラムが完成する確度も上がるとされています。
プログラムは、コンピュータを動作させるための文書です。その文書を一人ではなく、2人で一緒に作ったほうが効率的であるとすれば、他のビジネス文書（例えば、顧客に提出する提案書やプレゼン資料、など）についても、同じ法則が成り立つ可能性が大きいと言えます。また、XPが登場したころは、ペア・プロミングの実践のために1台のパソコンを2人が共用するといったことが行われていたようですが、今日ではリモートからでも複数人による文書の共有・共同編集・加工・チェックが行えるようになりました。ですので、ペア・プロミングの考え方を取り入れるのはより簡単ですし、その実践によって、提案書やプレゼン資料などを作る作業効率がグンと高められる可能性が高いのです。
一方、今日では、アジャイル開発を実現するための方法論として「スクラム」と呼ばれるフレームワークが標準的に使われています。このスクラムの考え方も、開発以外の業務に適用して、チームのパフォーマンスアップに結びつけられる可能性があります。
しかも、スクラムの方法論は、“スクラムの父”とされるジェフ・サザーランド（Jeff Sutherland）氏（Scrum Inc. 創業者兼プリンシパルコンサルタント）が、一橋大学名誉教授である野中郁次郎が新製品開発のプロセスについて記した論文『The New New Product Development Game』から着想を得て1993年にスクラムを考案したことが原点とされています。野中氏の論文は、ソフトウェア開発の話ではなく、知的創造プロセスの話です。その論文を考え方の大元に置くスクラムは、ソフトウェア開発以外の業務やプロジェクトへの適応させられる可能性が高いと言えます。
以下、その点について見ていきます。
スクラムの出発点は、開発するソフトウェア（スクラムでは「プロダクト」と呼ばれる）の顧客（プロダクトのオーナー）が、プロダクトの目標を定めることです。つまり、開発するプロダクトは、「誰に対して、どのような価値を提供するものなのか」を確定させるわけです。
次に、その開発目的をスクラムチームのタスク（作業）に落とし込み、チームのキャパシティに基づくかたちで、各スプリントでどういった成果物を作り上げるかの計画と目標が定められます。
成果物は実際に動作するソフトウェアであることが前提で、その目標達成度が1回のスプリントが終わるごとに、プロダクトのオーナーである顧客によって評価され、それに基づくかたちで次のスプリントの計画と目標が定められていきます。これにより、開発の作業が開発の本来目的から乖離（かいり）してしまうリスクが回避できます。
プロダクトオーナーによる評価後には、チームのメンバーで自分たちのスプリントを振り返り、課題や問題点を洗い出す会議が行われ、それが次のスプリントの計画に反映されます。この振り返りをスプリントごとに行うことで、チームの能力を上げていくことが可能とされています。
チームやチームのメンバーが自律的に動くことを重視している点も、スクラムの特徴です。もちろん、チームは開発するプロダクトの目的を変更することはできません。ただし、目的を果たすためにどのような仕組みや機能を開発するかは、チームやチームのメンバーの判断に委ねられます。
つまり、スクラムにおける開発は、上からの指示や仕様書に従って機械的にタスクをこなすのではなく、自らのアイデアや創意工夫によってプロダクトの本来目的を果たす作業と言えます。ですので、上からの指示がないと動けない人は、スクラムには不向きです。一方で、ソフトウェア開発者はナレッジワーカーですので、上から指示を機械的にこなすことにやりがいを感じられない方が大勢います。ですので、そうした開発者にとって、スクラム開発は自分のモチベーションアップにつながる場であるようです。
こうしたスクラムの実践の場では、スプリントにおける各タスクの進捗状況を、タスク管理ツールなどを使って可視化し、スクラムチームのメンバー全員はもとより、プロジェクトマネージャー（スクラムマスター）やプロダクトオーナーなど、開発中のプロダクトの関係者全員で共有するのが一般的です。
このとき、各タスクとタスクの目的などを紐づけて管理しておくと、スクラムチームのメンバーは、自分が担当するタスクについて、それがプロダクトの本来目的を達成するうえで、どのような意味を持つのか、なぜそれが必要なのかを常に参照しながら、作業が進められます。また、プロダクトオーナー側も、自分の目的を果たすためにどのような作業が行われ、その作業の進捗がどういった状況にあるのかを常に確認することが可能になります。
さらに、スクラムでは、その日の作業をスタートさせる前にチーム全員が集まり、10分～15分程度、昨日と当日の作業内容や現在の困りごとを相互に報告し合うミーティング（大抵は、スタンドアップ式のミーティング）を催すことが提唱されています。
もちろん、基本的にはソフトウェア開発の方法論ですから、そのまま他業務に適用することはできません。とはいえ、スプリントで生み出す成果物を、ソフトウェアではなく他のモノに置き換えれば、さまざまなプロジェクトにスクラムの考え方を転用することができるはずです。また、スクラムでのタスク管理の考え方は、開発以外の業務を担うチームのマネジメントにも役立つ可能性があります。
例えば、スクラムでは、開発するソフトウェアの目的・目標に基づいて、スプリントで上げるべき成果が決まり、タスクの計画が決められ、ツールを使ってタスクの進捗が管理されます。この方式は、会社や部門の目標に沿って、チームが上げるべき成果を決めて、その成果を上げるためのタスクと、タスク遂行のスケジュールを決めて管理するやり方に置き換えることができます。
これはある意味で、成果主義的なチームマネジメントの方式と言え、こうしたタスク管理の手法を取り入れると、「仕事のための仕事」と言われる無駄なタスクを最小限に抑えることが可能になりますし、成果ベースでチームのメンバー各人の働きぶりがチェックできますので、それぞれの仕事のプロセスを細かく管理する必要がなくなります。
結果として、たとえチームのメンバー全員がリモートで仕事をしていて、それぞれの働く姿が常に見えなくても、タスク管理ツールなどを使って進捗を管理していれば、会社・自部門の目標・目的に沿ったチームマネジメントが行えることになります。
ちなみに、アジャイル開発・スクラムでは、チームメンバー全員が一つの場所にいて密接にコミュニケーションとコラボレーションを行うことを前提にしていますが、この考え方には、ビデオ会議やチャット、タスク管理のツールが今日のように普及・発達することは加味されていません。ですので、今日のツールを使えば、チームのメンバー全員がリモートワークを実施中でも、スクラムの実践が可能と言えます。実際、スクラムの作法の一つである前朝10分から15分のミーティングについても、ビデオ会議を使えばリモートワークの体制下でも行えます。
また、そもそもアジャイル開発など、特定のプロダクトを早期にリリースしなければならない業務以外では、チーム内でそう頻繁に互いの現状確認を取る必要はなく、毎日の就業前に必ず10分～15分のミーティングを行う必要もないと言えます。
とはいえ、メンバーの誰かが何らかの課題に突き当たり、タスクをスケジュールどおりに終えられなくなっている可能性もあります。そうしたリスクをチーム全員で常に共有しておけば、課題解決の一手が早期に打てることになります。
そのうえで、スクラムのように、成果を上げるためにどのような施策を講じるかについては、チームやメンバーの判断やアイデアに委ね、マネジャーがより良い成果が上げられるよう上手く導いていけば、チームやメンバーの自律性がアップしてパフォーマンスが上がり、現場判断を土台にした変化への俊敏な対応力を手にできるかもしれません。
いずれにせよ、ソフトウェア開発はチーム作業であり、培われたチームパフォーマンス向上のための方法論には、チーム力改善のためのヒントが多く含まれています。ご興味のある方は、スクラムやXPなど、アジャイル開発関連の書籍に目を通されてみてはいかがでしょうか。
▼前編はこちら 要チェック！DXで盛り上がる「アジャイル開発手法」の使いどころ【前編】―アジャイル開発が必要とされる理由とは？
▼DXの先進事例を読む「どうする、わが社のDX！？」そんな悩みに答える実践ノウハウ＆成功ポイント
アジャイル開発の方法論
アジャイル開発を実現するための方法論は、基本的に良質なソフトウェアを、よりスピーディーに作り上げるための方法をまとめたものです。ただし、アジャイル開発の方法論は、プログラミングのテクニックやツールの使い方を論じたものではなく、チームの生産性やパフォーマンスを高めるための仕事の進め方を示したものです。そのため、方法論には相応の汎用性があり、その手法を応用することで、ソフトウェア開発以外の業務を担うチームの生産性やパフォーマンスが高められる可能性があります。例えば、アジャイル開発の考え方に大きな影響を与えたとされる方法論の一つに「エクストリーム・プログラミング（以下、XP）」と呼ばれるものがあり、その手法の一つに「ペア・プログラミング」があります。これは文字どおり、2人一組になってプログラミングを行うというものです。形式は、2人のうち一人がプログラムを記述し、もう一人がその評価や品質のチェックをほぼ同時並行で行うというもので、両者の役割を交代させながら作業を進めていきます。
常識的に考えると、2人が1つのプログラムを作るわけですから、それぞれがプログラミングを行う場合に比べて生産性が2分の1に低下するように思えます。ところが実際にはそのようなことはなく、ペア・プログラミングの実践によって、より品質の高いプログラムが、よりスピーディーに生産できるようになり、かつ、ペアを組む2人の間で相手に迷惑をかけたくないという意識が自ずと芽生え、スケジュールどおりにプログラムが完成する確度も上がるとされています。
プログラムは、コンピュータを動作させるための文書です。その文書を一人ではなく、2人で一緒に作ったほうが効率的であるとすれば、他のビジネス文書（例えば、顧客に提出する提案書やプレゼン資料、など）についても、同じ法則が成り立つ可能性が大きいと言えます。また、XPが登場したころは、ペア・プロミングの実践のために1台のパソコンを2人が共用するといったことが行われていたようですが、今日ではリモートからでも複数人による文書の共有・共同編集・加工・チェックが行えるようになりました。ですので、ペア・プロミングの考え方を取り入れるのはより簡単ですし、その実践によって、提案書やプレゼン資料などを作る作業効率がグンと高められる可能性が高いのです。
一方、今日では、アジャイル開発を実現するための方法論として「スクラム」と呼ばれるフレームワークが標準的に使われています。このスクラムの考え方も、開発以外の業務に適用して、チームのパフォーマンスアップに結びつけられる可能性があります。
しかも、スクラムの方法論は、“スクラムの父”とされるジェフ・サザーランド（Jeff Sutherland）氏（Scrum Inc. 創業者兼プリンシパルコンサルタント）が、一橋大学名誉教授である野中郁次郎が新製品開発のプロセスについて記した論文『The New New Product Development Game』から着想を得て1993年にスクラムを考案したことが原点とされています。野中氏の論文は、ソフトウェア開発の話ではなく、知的創造プロセスの話です。その論文を考え方の大元に置くスクラムは、ソフトウェア開発以外の業務やプロジェクトへの適応させられる可能性が高いと言えます。
以下、その点について見ていきます。
スクラムのキホン
スクラムは、10名以下の少人数でチーム（スクラム）を組み、開発工期を1～4週間の「スプリント」という単位にわけ、スプリントを数回にわたって回しながら、ソフトウェアを仕上げていく方式です。スクラムの出発点は、開発するソフトウェア（スクラムでは「プロダクト」と呼ばれる）の顧客（プロダクトのオーナー）が、プロダクトの目標を定めることです。つまり、開発するプロダクトは、「誰に対して、どのような価値を提供するものなのか」を確定させるわけです。
次に、その開発目的をスクラムチームのタスク（作業）に落とし込み、チームのキャパシティに基づくかたちで、各スプリントでどういった成果物を作り上げるかの計画と目標が定められます。
成果物は実際に動作するソフトウェアであることが前提で、その目標達成度が1回のスプリントが終わるごとに、プロダクトのオーナーである顧客によって評価され、それに基づくかたちで次のスプリントの計画と目標が定められていきます。これにより、開発の作業が開発の本来目的から乖離（かいり）してしまうリスクが回避できます。
プロダクトオーナーによる評価後には、チームのメンバーで自分たちのスプリントを振り返り、課題や問題点を洗い出す会議が行われ、それが次のスプリントの計画に反映されます。この振り返りをスプリントごとに行うことで、チームの能力を上げていくことが可能とされています。
チームやチームのメンバーが自律的に動くことを重視している点も、スクラムの特徴です。もちろん、チームは開発するプロダクトの目的を変更することはできません。ただし、目的を果たすためにどのような仕組みや機能を開発するかは、チームやチームのメンバーの判断に委ねられます。
つまり、スクラムにおける開発は、上からの指示や仕様書に従って機械的にタスクをこなすのではなく、自らのアイデアや創意工夫によってプロダクトの本来目的を果たす作業と言えます。ですので、上からの指示がないと動けない人は、スクラムには不向きです。一方で、ソフトウェア開発者はナレッジワーカーですので、上から指示を機械的にこなすことにやりがいを感じられない方が大勢います。ですので、そうした開発者にとって、スクラム開発は自分のモチベーションアップにつながる場であるようです。
こうしたスクラムの実践の場では、スプリントにおける各タスクの進捗状況を、タスク管理ツールなどを使って可視化し、スクラムチームのメンバー全員はもとより、プロジェクトマネージャー（スクラムマスター）やプロダクトオーナーなど、開発中のプロダクトの関係者全員で共有するのが一般的です。
このとき、各タスクとタスクの目的などを紐づけて管理しておくと、スクラムチームのメンバーは、自分が担当するタスクについて、それがプロダクトの本来目的を達成するうえで、どのような意味を持つのか、なぜそれが必要なのかを常に参照しながら、作業が進められます。また、プロダクトオーナー側も、自分の目的を果たすためにどのような作業が行われ、その作業の進捗がどういった状況にあるのかを常に確認することが可能になります。
さらに、スクラムでは、その日の作業をスタートさせる前にチーム全員が集まり、10分～15分程度、昨日と当日の作業内容や現在の困りごとを相互に報告し合うミーティング（大抵は、スタンドアップ式のミーティング）を催すことが提唱されています。
成果主義でのタスク管理が可能に
このように、スクラムでは、顧客の目的に沿ったソフトウェアをチームで効率的に回すための方法が、原則としてさまざまに定義されています。もちろん、基本的にはソフトウェア開発の方法論ですから、そのまま他業務に適用することはできません。とはいえ、スプリントで生み出す成果物を、ソフトウェアではなく他のモノに置き換えれば、さまざまなプロジェクトにスクラムの考え方を転用することができるはずです。また、スクラムでのタスク管理の考え方は、開発以外の業務を担うチームのマネジメントにも役立つ可能性があります。
例えば、スクラムでは、開発するソフトウェアの目的・目標に基づいて、スプリントで上げるべき成果が決まり、タスクの計画が決められ、ツールを使ってタスクの進捗が管理されます。この方式は、会社や部門の目標に沿って、チームが上げるべき成果を決めて、その成果を上げるためのタスクと、タスク遂行のスケジュールを決めて管理するやり方に置き換えることができます。
これはある意味で、成果主義的なチームマネジメントの方式と言え、こうしたタスク管理の手法を取り入れると、「仕事のための仕事」と言われる無駄なタスクを最小限に抑えることが可能になりますし、成果ベースでチームのメンバー各人の働きぶりがチェックできますので、それぞれの仕事のプロセスを細かく管理する必要がなくなります。
結果として、たとえチームのメンバー全員がリモートで仕事をしていて、それぞれの働く姿が常に見えなくても、タスク管理ツールなどを使って進捗を管理していれば、会社・自部門の目標・目的に沿ったチームマネジメントが行えることになります。
ちなみに、アジャイル開発・スクラムでは、チームメンバー全員が一つの場所にいて密接にコミュニケーションとコラボレーションを行うことを前提にしていますが、この考え方には、ビデオ会議やチャット、タスク管理のツールが今日のように普及・発達することは加味されていません。ですので、今日のツールを使えば、チームのメンバー全員がリモートワークを実施中でも、スクラムの実践が可能と言えます。実際、スクラムの作法の一つである前朝10分から15分のミーティングについても、ビデオ会議を使えばリモートワークの体制下でも行えます。
また、そもそもアジャイル開発など、特定のプロダクトを早期にリリースしなければならない業務以外では、チーム内でそう頻繁に互いの現状確認を取る必要はなく、毎日の就業前に必ず10分～15分のミーティングを行う必要もないと言えます。
とはいえ、メンバーの誰かが何らかの課題に突き当たり、タスクをスケジュールどおりに終えられなくなっている可能性もあります。そうしたリスクをチーム全員で常に共有しておけば、課題解決の一手が早期に打てることになります。
チームの自律性がアップする可能性も
先にも触れたとおり、スクラムの考え方を取り入れると、会社や自部門、チームが上げるべき成果に紐づいてメンバー各人のタスクが決められるので、メンバー各人は自分に割り振られたタスクがなぜ必要なのか、なぜ、いま、それを行う必要があるかの意味を明確に理解できるようになります。また、自分に割り振られたタスクをスケジュールどおりに終えることが、チームや部門、会社の目標を達成するうえでどのような意味を持つのかも把握できます。そのうえで、スクラムのように、成果を上げるためにどのような施策を講じるかについては、チームやメンバーの判断やアイデアに委ね、マネジャーがより良い成果が上げられるよう上手く導いていけば、チームやメンバーの自律性がアップしてパフォーマンスが上がり、現場判断を土台にした変化への俊敏な対応力を手にできるかもしれません。
いずれにせよ、ソフトウェア開発はチーム作業であり、培われたチームパフォーマンス向上のための方法論には、チーム力改善のためのヒントが多く含まれています。ご興味のある方は、スクラムやXPなど、アジャイル開発関連の書籍に目を通されてみてはいかがでしょうか。
▼前編はこちら 要チェック！DXで盛り上がる「アジャイル開発手法」の使いどころ【前編】―アジャイル開発が必要とされる理由とは？
▼DXの先進事例を読む「どうする、わが社のDX！？」そんな悩みに答える実践ノウハウ＆成功ポイント