≪前編

後編≫

世界のアジャイル動向を読み解く(後編)クラフトマンシップの追究

2021年1月25日公開

前編では、過去5年間のState of Agile Reportをもとにアジャイルの普及状況や組織規模、メソドロジーの潮流といった動向を読み解きました。
本稿では、引き続き、企業がアジャイルを採用した理由と効果や、アジャイルプラクティス/ツールの動向を把握し、その背景にどのような要因がありうるか、筆者の見解を述べます。

ソフトウェアデリバリーの加速が急務

グローバルの企業や組織は何に期待を込めてアジャイル開発に取り組み始めたのでしょうか。
組織がアジャイル開発へと取り組み始めた理由とそこで得られた効果について見ていきます。

アジャイルへの期待と効果

組織がアジャイルに取り組み始めた理由としては、以下の3点があります。

  • ソフトウェアデリバリーの加速
  • 優先順位の変更管理能力の向上
  • 生産性の向上

変化の激しいビジネス環境に追従するため、これらを期待してアジャイル開発に取り組み始めているようです。

一部ではその効果が得られていない

実際に得られた効果として、期待を大きく超えたものには以下の4点があります。

  • プロジェクトの可視性向上
  • 分散チームにおけるマネジメントの向上
  • チームモラール(士気)の向上
  • エンジニアリング規律の改善

このように、マネジメントの向上やチームとしてうまく作用するようになったことが挙げられています。
アジャイルは市場の変化に追従するための開発手法としてとらえられがちです。
それだけでなく、チームや組織の効果を高め、組織文化を醸成するマネジメントの方法論なのです。

しかし、最も多い理由である「ソフトウェアデリバリーの加速」は、いくつかの企業で期待した効果を得られていないようです。
この要因について、アジャイルテクニック、ツール、エンジニアリングプラクティスそれぞれの観点で見ていきます。

ビジネスへの浸透か、小チームの機能不全か

このグラフは、組織が利用しているアジャイルテクニックの推移を表しています。

アジャイルテクニックの動向

イテレーションプランニングやレビュー、短いイテレーションが減少傾向にあり、かんばんは増加傾向にあります。
前編「利用しているアジャイルメソドロジー」で説明したように、ScrumBanやKanbanが若干増加傾向にありました。
イテレーションなどの反復期間を設けず、ストーリーを1個流しで開発し、常時リリースするチームが増えているように見えます。

また、リリースプランニングが減り、プロダクトロードマップやポートフォリオプランニングが増えているようです。
上記の傾向と併せると、市場を見て、どの機能をどの程度の期間をかけて開発し、いつ提供すべきかといった戦略がリリースの軸となり、機能要求の理解(バックログづくり)、優先順位付け、計画ゲームで必要なレベルの設計はリリースプランニングというイベントを待たずに常時行われているのではないかと推測します。

この傾向は、SAFeの台頭とも関連がありそうです。
SAFeの特徴として、ポートフォリオマネジメントがあります。
SAFeの台頭とともに、プロダクト全体のロードマップやバリューストリームへの投資といった企業戦略へと力を入れる組織が増えているのでしょう。
経営層などのビジネスにもリーンやアジャイルの考え方が浸透しているように見えます。

一方で、減少傾向にあるアジャイルテクニックは、チームの能力を向上させるもの、より小さなマネジメントサイクルを生むものです。
PIプランニングと呼ばれる中期計画にて実施した各イテレーションの計画は、それ以降チームで見直しされていないのかもしれません。
組織能力の基となるチームの成長や自律を生み出す仕掛けが、大規模化やトップダウンによりうまく機能しなくなっているようにも見えます。

これらアジャイルテクニックの減少による小チームの機能不全が、デリバリー加速を得られない要因の一つだと考えます。

ほぼすべてのツール利用が減少傾向へ

このグラフは、組織が利用しているツールの推移を表したものです。

ツールの動向

かんばんボードを除き、ほぼすべてのツールが2015年から2019年にかけて、右肩下がりのように見えます。

大規模なアジャイルチームは増加傾向にありました。 大規模開発では開発期間も長期にわたります。その間には多くの意思決定や人の入れ替わりも起こりえます。
いつ、何のために、何をしたのか、なぜそう判断したのか、その結果どうなったのか、このようなナレッジを蓄積するためにバグトラッカーやアジャイルプロジェクト管理、Wikiといったツールは必要不可欠です。

自動ビルド、ユニットテスト、常時結合といったツールを使わずに、品質をつくりこむことは容易ではありません。
チームの規模が大きく、開発期間が長ければ、なおのこと品質は重要になります。

ツールを使うことがアジャイルではありませんが、チームのナレッジを集積し、エンジニアリングの規律を醸成し、質とスピードを維持するために必要だと考えられるツールが減少傾向にあります。

スクラムマスターは何をみるのか

このグラフでは、特に2015年から2016年にかけて、何かが起きたように減少しています。
回答者のロールと照らし合わせると、開発者が減少し、スクラムマスターや外部コンサルタントが増加しています。
かんばんボードもチームの状態を見える化する重要なツールですが、それだけでは足りません。
例えば以下のようなツールを、1つ1つ、それぞれのつながり、全体を、その時点だけでなく傾向としてもみることで、チームが問題と認識していないものを発見することができます。

ツール視点
アジャイルプロジェクト管理ツールストーリーの粒度
ステータスの変更履歴
概要や作業ログの記載内容
リードタイム
同時着手数
常時結合ツールビルド頻度
ビルド時間
ビルド結果
テストカバレッジ
パイプラインフロー
ソースコード管理ツールコミットの粒度
コミットログ
ブランチツリー
コミット(マージ)担当者
常時結合のビルド結果

ツール利用減少に伴うナレッジの消失、質とスピードの劣化、問題認識の不全、これらもデリバリー加速を得られない要因でしょう。

良き習慣が失われつつあるのか

このグラフは、利用しているエンジニアリングプラクティスの推移を表したものです。

エンジニアリングプラクティスの動向

ユニットテスト、常時結合、リファクタリング、テスト駆動開発、持続可能ペースなど、XPのプラクティスが減少傾向にあるように見えます。
回答者におけるデベロッパーの割合は減少していますが、それ以上にスクラムマスターや内部コーチは増加しています。
スクラムガイドには、スクラムマスターがチームのエンジニアリングプラクティスを促進するという記載はありません。
しかし、エンジニアリングプラクティスを理解し、チームの習慣となるようにコーチングする責務もあると私は考えます。
そのような役割を担う人の回答が増えたにもかかわらず、エンジニアの良き習慣が失われつつあるこの状況は危惧すべき事態です。

エンジニアリングプラクティスの利用減少によってソフトウェアの品質、保守性を維持できなくなっていることが、デリバリー加速を得られない最も大きな要因だと考えます。

ヘロヘロScrumに陥らないために

  • チームの能力向上、小さなマネジメントサイクルを生むアジャイルテクニックの減少による小チームの機能不全
  • ツール利用減少に伴うナレッジの消失、質とスピードの劣化、問題認識の不全
  • エンジニアリングプラクティスの利用減少により、ソフトウェアの保守性維持が困難

これらが、組織が期待した「ソフトウェアデリバリーの加速」を得られていない原因だと考えられます。
スクラムイベントのようなマネジメントプラクティスのみを中心に据え、エンジニアリングプラクティスを疎かにしてしまえば、即座にヘロヘロScrumへと陥ってしまうでしょう。

内部品質、保守性を犠牲に捧げることで、一時的には機能が早く提供できることもあるかもしれません。
とりあえず受け入れ条件を満たすコードをプログラムする。
ユニットテストは次のイテレーションで開発する。
ペアプログラミングはやめ、コードレビューで対処、動作に支障がある致命的な箇所だけを修正する。

1ヵ月後、ビジネスは前回の機能提供がうまくいったため、新たに優先順位の高いストーリーを至急仕上げてほしいといいます。
「至急」が求められる状況下では、一度機を逃したユニットテストは開発されることがありません。
テストコードがないためリファクタリングは困難、そもそもリファクタリングをする時間もないでしょう。
誤認しやすい変数名、コードの重複、クラス構造、コードからは目をそむけたくなるような嫌な臭いがします。
しかし、一度コードをコミットしたら修正するチャンスはあまりありません。
こうして、過去のコードを読み解くこと、壊さないように慎重に改修することに時間を費やすようになり、新機能の開発が鈍化していってしまうのです。

エンジニアリングプラクティスは、ソフトウェアやサービスへ品質をつくりこめるようエンジニアを支えています。
高い品質が、高いスピード、アジリティを可能とするのです。
プロダクトを成功させるためにはマネジメントプラクティス、ツール、エンジニアリングプラクティス、それぞれが不可欠なのです。

クラフトマンシップの追究

商品やサービスの寿命、開発期間が短くなり、ナレッジを集積する必要性が感じられなくなっているのかもしれません。
以前、こんな話を耳にしました。

Redmineなどのタスク管理ツールは使用せず、付箋紙やホワイトボードのみでタスク管理している。
短期間のProof of Conceptプロジェクトなので、そこまでする必要はない。

確かに短期間の開発ではアジャイルのうまみを最大限に活かしきれません。
しかし、何をビジネス仮説と定義し、どのような方法で検証し、どのような結果を得られたか。
そこに至るまでの調査や技術検証、仮説の評価視点などを集積しておくことは、次を見据える上で重要なナレッジとなるでしょう。
仮説を証明し、その後廃棄するコードであればテストコードは不要かもしれません。
しかし、一度コードを捨てられる環境下で、本番さながらの訓練ができる機会はそうありません。

これまで述べてきたようなクラフトマンシップは、書籍や座学による知識だけで習得することは困難です。
自らが考え、手を動かして、実践し、鍛錬し続けることで少しずつ体得することが唯一の方法です。
機会を活かし、開発ツールやエンジニアリングプラクティスを実践することで体得を促し、組織やチームの持つ能力を高めることが、斧を研ぐよりよい方法だと考えます。


≪前編

後編≫

参考文献

執筆

大塚 憲(おおつか あきら)富士通株式会社 ジャパン・グローバルゲートウェイ
ソフトウェア開発者、SPC(SAFe® Program Consultant)、CSM(Certified ScrumMaster)
2007年よりアジャイルチームに参画し、主にWebサービス開発・運用に従事。
プログラマーとして OSS Personium の開発/運用のリードや、映像検索・分析サービスのインフラ含むバックエンドサービスを開発。
現在は、社内アジャイリストの育成や、アジャイル人材育成・研修サービスの開発を実践。

お問い合わせ

ページの先頭へ