複雑かつ変化の激しい時代に、個人やコミュニティの幸福につながる価値を届けるには
株式会社SHIFTとそのグループ企業は、ソフトウェアの品質保証テストやアジャイル開発の支援、コンサルティング、企画、開発、運用といったサービスの立案から運用まで、トータルな支援を展開している。ナレッジ育成管理を意識し、非俗人化を進めながら、非IT業界の人々がITのプロジェクトで活躍できる場を構築し、ソフトウェア品質を起点としたデジタル変革や新たな価値創造を支援している。
船橋氏はまず、近年のビジネス環境について語った。現在は変化の予測が難しく、VUCA（ブーカ。Volatility：変動性、Uncertainty：不確実性、Complexity：複雑性、Ambiguity：曖昧性）の時代とも言われている。そして、日本が目指す未来社会のコンセプト「Society 5.0」ではデジタル技術と人の創造力の融合による課題解決・価値創造が求められている。
「価値」に対する考えも変わった。ひと昔前ならサービスが持つ「機能」が注目され、それを使ってもらうことが価値だった。現在では、機能の使用感の良さや良い体験を得られないと価値があるとは言われないようになっている。そして、コミュニティ形成や多くの人で経験を積み上げる価値共創も注目されている。
船橋氏は、IPA（独立行政法人 情報処理推進機構）が公表した資料「なぜ、いまアジャイルが必要か？」にも記されている言葉を引用し「価値とは個人や組織やコミュニティが良いと意味づけているモノ・コトの総体であり、それらは、個人やコミュニティの幸福につながっていくもの」と説明した。
続いて船橋氏は、ウォーターフォール型のソフトウェア開発の特徴を説明した。一般的に、開発からリリースまでの期間が長期化するため、企画や設計の段階の期待感が環境の変化に適応しにくい。このため、リリース時点では実態と乖離している可能性が高い。改修にも時間がかかるため、激しい変化には耐えられないやり方である。継続的に価値を提供し、ビジネスの期待に応えていくためにアジャイル開発の取り組みが進んでいるのだ。
ウォーターフォールからアジャイルへの移行で見られる失敗例
アジャイルの手法はいくつかあるが、船橋氏は世界のアジャイル開発の取り組みを調査した「State of Agile Report」の2021年の結果では、66％がスクラムを採用していることから、スクラムをベースにその後のセッションを展開した。
ウォーターフォール（V字モデル）のプロセスを採用したプロジェクトでは、インプットとアウトプットが明確に定義されていて、そのアウトプットである成果物や書類を完成していること、そしてそのレビューをして次の工程にすすみ、リリースを目指す。後工程での変更は前工程にさかのぼって反映させる必要がある。V字の前半（要件定義や設計、実装、初期のテスト）は開発チーム、後半（結合テスト、総合テスト、受け入れテスト）は品質保証のチームが担当する。
要求要件定義、基本設計と詳細化していく過程で、個々の機能詳細化、明確化していくので、フロントエンドの担当、バックエンドの担当など役割が固定される。各インターフェースは仕様書をもとにつながっているものの、個別具体的な部分の担当となっているので、担当外の領域がわからず全体的な把握がしにくい。
一方、スクラムの場合は最大4週間のスプリントを繰り返す活動となります。工程の概念はなく、開発活動期間も短いので必要最低限のドキュメントによってチームが共通認識を得る形を重視して進む。優先順位をつけたプロダクトバックログに順々に対応していくため、プロダクトバックログには改善事項だけでなく、どのような価値を与えるかにまで言及することも多い。設計、実装、テストの過程において全体の統制が意識される。
船橋氏は、ウォーターフォール（V字モデル）からアジャイル（スクラム）への移行がうまくいかない組織は、従来の開発チームが担当していた部分をスクラムチーム化して、品質保証チームは変わらず最後に対応する体制を構築しがちだと指摘した。
「その結果、本来動くプロダクトを重視しているはずが、スプリント内でリリースすることができないため、フィードバックを得られません。品質保証担当が取り残されているためリリース頻度の早期化というのも行いません。継続的に価値を提供することができない典型的な例です」（船橋氏）
船橋氏は、SHIFTが改善を担当した、ある金融プロジェクトを具体例として紹介した。SHIFTはこのプロジェクトのチームAから総合テストをしてほしいと依頼を受けた。スプリントは4回実施され、スプリントのたびに不具合の数は増え、スプリント4では重大な不具合が生じてテストが中止となり、アジャイルをやめてウォーターフォールに戻すこととなった。
「開発部隊と品質保証部隊は分かれているのだから、スクラムチーム化しても結果的にプロセスは変わりません。プロジェクト全体で一つのチームになれば解決すると考えますが、そう簡単にはいかないです。従来の工程に縛られて各々のタイミングで活動していた部隊同士がある日突然今日から一緒に活動しましょうっていうのは無理があります」（船橋氏）
完成に近づいたプロジェクトに対して総合テストをし、非機能テストをするなどの活動をしていたウォーターフォール型チームの場合、アジャイルになってさまざまなテストをどのタイミングで行えばいいかわからないという問題が生じるのだ。
続いて船橋氏は、同じ金融プロジェクトの別のチームの例（チームB）を示した。スプリント5回のうち、スプリント3と4では不具合の検出は低いものの、スプリント5ではテストケースがほかと比べて多く、テストケースが実施できていないように見える。このチームは開発や評価の方法も定まらずメンバーの関係がぎくしゃくしてしまい、安定したパフォーマンスが出せなかったという。
SHIFTが生み出し実践する、品質保証フレームワーク
これまで別に活動していた開発チームと品質保証チームの間には障壁がある。これを取り除かない限り、アジャイル開発はうまくいかない。船橋氏はSHIFTが構築・実践しているフレームワークの説明を始めた。
障壁の1つが、物理的な壁。開発チームと品質保証チームの部署が違っているプロジェクトや、セキュリティのベンダーに脆弱性診断を依頼しているプロジェクトなどの組織の壁だ。指揮系統が一貫しておらず、問題が生じやすい。
「作る側」と「指摘する側」というチームの関係の壁もある。品質保証チームは製品出荷のゲートキーパーを担っており、開発チームの意図を汲み取らず完成品について指摘をするので、軋轢が生まれやすい。価値を提供したいと考えている者同士で不協和音を奏でてしまうのだ。ウォーターフォールでは設計書を完成して実装し、検証という流れで役割分担もされて進んでいたので、それぞれの責任がわかりやすかった。船橋氏は、アジャイルの場合は特に「完成の定義」が重要だとした。
ソフトウェア開発において不具合の混入、検出はコーディングの時点で多く発生するが改修はしやすい。リリース近くになると不具合の原因調査、そして改修にはより多くの時間と労力がかかる。コードだけでなく環境の問題などもあるからだ。コーディング時点で1とした改修コストは、リリース直前には640倍にもなるという。そのため、不具合を検出するのではなく予防をする活動が求められる。
アジャイルでは不具合の予防のために自動テストの仕組みを入れたり、CI/CDによって継続的な発見をしたりすることが考えられるが、船橋氏は「完成の定義」がなされないとうまくいかないと述べた。
「完成の定義」とは、プロダクトの品質基準を満たすインクリメントの状態を示したもので、リリースできる状態を示しているものだ。これは、機能や要件だけでなく、受けるテストが完了していること、発見された不具合の扱いが決まっていることなど、品質の状態の定義も求められる。
船橋氏は「テストだけではなく、その環境はどこなのか、どのブランチに保存されたプログラムをデプロイ・ビルドデプロイするのか。コーディングする際に絶対にやっておかなければならないことはないか。開発と品質保証、それぞれが完成の定義に向き合う必要があります。チームの壁の問題があるので、プロジェクト発足当初のチームビルディングの際に検討する必要があります」と語り、戦略、スプリント活動両方を考えるフレームワークを紹介した。
このフレームワークでは、左の青い円上部「テストタイプ・レベル整理」から始まり「テストアプローチ検討」「完成の定義」「テスト方針検討」と進み、右の赤い円「テスト計画」「テスト分析・設計」「テスト実装・実行」「テストレビュー」のスプリント活動へと進む。スプリントのレビューによってテスト戦略の検討の見直しが必要であれば青の円に戻り、問題なければ次のスプリント活動を繰り返しすすめていく。
テストタイプ・レベル整理の段階では、対象となるシステムの構成を検討・整理する。外部サービスとの連携やテスト環境の準備なども考慮していく。どのようなテストを行うかの共通認識を持つことも重要だ。同じ組織、部署、プロジェクトでも、メンバー個人の認識が異なっている場合があるため、事前にプロジェクトチームの中で認識を合わせておかなければ後々問題が生じる。
テストアプローチ検討の段階では、各テストをどういった方法で実施するか検討する。テストケースや手順を設計書として作成して実行する手動テストや、コーディングによって実行する自動テスト、探索的テストの3手法から定義していく。
チームビルディング時には、ソースの管理方法、ブランド戦略、不具合が発生したときの報告ルートなど、テスト戦略以外のことも検討しているはずだ。それらの情報とそれまでに検討したテストの情報をつなぎあわせて行うのが「完成の定義」だ。そうすることで、チーム全体の意識を合わせるため、詳細に決定していく必要がある。
テスト方針検討の段階では、バックログリファインメントを開催する。実施した内容の価値や対応内容、受入基準などを決めていくなかで、それぞれのバックログで実施が必要なテストタイプまでチームの意識をあわせていく。
スプリントの活動では、各イベントにチーム全員で参加し、開発担当・品質保証担当という責任分担、責任転嫁をせずに常にチーム全体で確認していく。船橋氏は「積極的に情報共有をすることで、チームの品質意識を向上させ、不具合の予防につなげることも可能です」と付け加えた。
品質保証フレームワークをベースに、チームとプロダクトを成長させていく。
先に挙げた、スクラムからウォーターフォールに戻さざるを得なかった金融プロジェクトのチームは、別のプロジェクトにおいてこのフレームワークを導入し、各スプリントでの不具合数の予防に成功して数が減少し、本番障害も半年間ゼロとなった。メンバーの関係が円滑でなく、テストケースの消化が不安定だった金融プロジェクトの別チームも、不具合を予防できる傾向にあり、本番障害は半年間で5件に抑えている。いずれのチームも見事にアジャイルチームの変貌を遂げたのだ。
しかし船橋氏は、このフレームワークは盲信できるものではないと注意を促し、最後に次のようにコメントした。
「このフレームワークはあくまでスターターキットです。プロダクトの成長に合わせて改善、見直しを進めていく流れとなっています。最初はフレームワークに沿ってチームビルディングの過程でテストタイプやアプローチを検討し、完成の定義に品質を盛り込む。そしてスプリントにおいてもテスト戦略を守りながら活動し、必要に応じて戦略を改善していく。この流れによってアジャイル開発の成功に近づいていくと考えます」
