アジャイルQAジャーニー#1（リスクベースで見る開発手法判断）

はじめまして。品質マネージャ兼スクラムマスタをしています、SHIFT技術推進部アジャイル推進Gの谷岡です。日々アジャイル開発現場の品質確保とチーム／プロジェクト改善を土俵に戦っています。

弊社では大変ありがたいことに、数多くのお客様のシステム開発をご支援させていただいております。主にソフトウェアテストの領域でのご支援なのですが、お客様の文化／チーム構成によりその手法はさまざまです。ときには、臨機応変な対応が必要となる場面もあります。

私の投稿では、「アジャイルとは何なのか？」「アジャイル開発現場で品質を担保するにはどうすべきか？」あたりの観点で、経験談を少しずつですが綴ろうと思います。

アジャイルというと多くの書籍やご意見があると思いますがその裏返しで、「大正解！」「これだけでいい！」というものは存在しないようです。一方で少なからず成功してきたフレームワークは存在しているのは事実ですので状況に応じて、これらを組み合わせて適用していく必要があります。

第1回となる今回は、「リスクベースで見る開発手法判断」と題してお送りしたいと思います。把握の難しい事象を外側から多角的に捉えることで、掴んでいく手法をとっていく次第です。お付き合いいただけると幸いです。

アジャイル型か計画型か

「ウォーターフォールが失敗したから、アジャイルに取り組もう」「変更要求を自由に汲んでくれるんでしょ？」「アジャイルに開発するシステムを最近よく聞くからうちも」etc...

「ちょっと待ってください」と言いたくなるような理由で導入の声がかかり、いざ取り組むと苦しむという話をよく聞きます。やみくもな蹴り出しでは初めから失敗に向かって駒を進めるようなものです。
どういうときに、どちらの手法をとるとよいのでしょうか。

Barry BoehmとRichard Turner¹⁾ は、一般的なプロジェクトリスクを前提としつつ、リスク分析の観点でどちらの開発手法をとるべきか記載しているのでご紹介します。

■プロジェクトの一般的な環境に起因するリスク
・技術の不確実性
・多様な利害関係者との調整
・複雑なシステム

■アジャイル手法を利用することのリスク
・スケーラビリティとクリティカル性
・シンプルなデザインやYAGNIを使用
・人員の離職率や解約
・アジャイル手法に熟練した人材が不足している

■計画主導型手法を利用することのリスク
・急激な変化
・迅速な結果の必要性
・緊急の要件
・計画主導型手法に熟練した人材が不足している

アジャイル（適用型）、計画主導型ともに4つ目の熟練した人材不足はない物ねだりかなという感じですが、これらのリスクを逆手にとると、得意分野を双方に垣間見ることができますね。上記を参考にしながら、もう少し具体的に私の経験を踏まえて見ていきます。

適応性と計画性

計画主導開発（ウォーターフォール型）はシステムのV時モデルに従い、工程ごとに綿密に作成されたドキュメント、関係各所による細やかで段階的なレビュー、開発、QA、リリース、運用に至るまで長いと数年単位で計画されます。顧客が必要とする成果物が手元に届くまでのリードタイムが非常に長い反面、リスクに対しては大きな責任を負いやすい仕組みができあがっています。

こんなシステム／製品／商品があるといいなという、明確な要求に対してコミットする方式です。ユーザのなかに、具体的ではなくとも答えがあります。like this one.（こんなやつ）とオーダします。成果物を欲しているお客さんはそこにいます。売れます。利益が出ます。明確で遠い道のりを進むことになります。

一方、アジャイルでは3ヶ月以上先の話をしないことが往々にあります。考えていないわけではなく、不確定要素が多く考えられません。計画性がないのではなく、計画してもコンテキストが変わってしまい徒労に終わることが多いことを意味します。計画の反意語としてではなく、適応という観点がマッチします。

よりよいシステム／よりよい製品／よりよい商品を作りたいという、時代や流行の変化に対してコミットする方式です。ユーザのなかに、コレという答えはありません。Something better（よりよい何か）を探します。成果物を欲しているお客さんがいるか、本当に売れるのか、利益が出るのか、さまざまな要因を検討する必要があります。サブスクリプションや、随時課金制を用いている場合には解約リスクと常に隣り合わせにあります。不明確な闇のなかを手探りで進むことになります。

スケールとYAGNI

アジャイルにおいて人数、開発ボリュームが大きくなってしまうと品質、信頼性を担保するのがどんどん難しくなります。また、安定しているシステムに対して追加機能の算段を立てようという方向性と、YAGNIとシンプルな設計に従うというアジャイル開発者の願望を両立させることは、安定していればこそ困難になります。

クリティカルリスク

アジャイルに作られる成果物はリスクから遠い場所にあることが多いように思います。ダイレクトに人命に関わるものでもなければ、顧客にとって重要な支障をきたすものでないことが多いのではないでしょうか。システムが止まったら、それが一次原因として（2次3次以降は大いにあり得ると思います）危険が及ぶ可能性は低いのです。このため、仕様を早期に決定しサイクルを回してフィードバックを得ながらトライアンドエラーができる点はアジャイルの優位性であり、裏を返せばリスクと隣り合わせであることを意味します。

開発者のレベルと規模、そして人材

これは一概には言えませんが、長い工期のなかで正確に大量のドキュメントを携えた誤りのないシステムを作ろうとすると、どうしても人の手と目が必要になります。そうなると自社内で経験豊富な開発者を揃えるのは規模に従い困難になってくるものかと思います。工期ごとに必要な人材を適用していくと、その経験値は人それぞれとなることでしょう。また同じフェーズが次に回ってくるまで数年かかることもあるため、ずっとウォーターフォールで通り一辺倒をやってきた人材は全体最適化の選択をとることが多く、マネジメント方面に強くなる傾向にあり、局所的なエキスパートを生み出す土壌としての弱さがあります。

アジャイル開発では少ない人数で（10人程度のチーム）で短いサイクルを回すので、自ずとプロジェクトへのコミット力は高まり、ロール単位に研鑽されやすい状況にあるため、エキスパートが育ちやすい環境にはあるかと思います。しかしながら少人数であるため、重要な人材の離職が起こると暗黙知の崩壊や人的リソース不足など、大きなリスクが隠れています。

急激な変化／迅速性／緊急の用件

アジャイルに開発と聞くと迅速に作って、要件変更にも対応し、差込でも大丈夫なイメージをもたれますが、アジャイル開発では変更可能だからを免罪符にいつでも変更していいわけではありません。今まさにコードを書いている最中の開発者の肩を叩き、要件変更を繰り返すようでは叩く肩もなくなります。スプリントを終えてみて、成果物に対して当初の決定仕様のまま進むと不都合が生じる場合に変更を行い、別スプリント内で対応をするのです。

スクラムを例にしますと、スプリントの開始には必ずスプリントプランニングを行います。ここで決めた要求は基本的に変更しません。プランニングの段階までに仕様を決めないまま開発者に開発をお願いすると、開発者の独断と偏見が入って収集がつかなくなります。プランニングまでに（正確にはプロダクトバックログに記載するまでに）芯となる仕様を決定する責務がPOにはあります。

一方でウォーターフォール型の場合、明確な要件定義期間があり、基本設計期間がありとフェーズごとに成果物があります。ここで決定したことは（ほぼ）絶対です。遡って修正することもありますが、必ず経てきたレビューを再実行する必要がります。その分工数がかかるのでやり直し、仕様変更などはよっぽどでない限り行いません。そういった意味で本テーマではリスクと捉えられます。

組織文化

混沌と秩序といった言葉で表現されることが多いですが、アジャイルな現場と言いますとダイレクトに開発作業に響く会社の意思決定が何度かなされたり、当初の予定が次のスプリントでは変わったりと、四方八方から押し寄せて流れの変わる嵐のなかの小舟のような状況です。それでもその時々で舵をきり、帆を張るべき時には張る必要があります。いち早く状況を把握して役割を横断して手を伸ばし、助け合い、共にゴールに向かいます。誰も待ちの姿勢はなく強い意志で目標を達成しつづけるのです。とはいえ無理をするのではなく、プランニングしたものを的確に対応していきます。少人数でフラット組織であるため、多くの時間をかけずにちゃんと話し合い納得し合うことができます。必要であればキックオフ時に長時間かけた合宿もします。

一方、秩序立てて大人数で同じことをすると何が起こるかというと、膨大なお金がかかります。またミスコミュニケーションの回収が困難です。また、人数が多いとマネジメントコストが発生し、階層構造にならざるを得なくなります。秩序を保つ動きをとらざるをえない状況となります。

以上、さまざまなリスクに沿って書かせていただきましたが、いかがだったでしょうか。開発手法判断の一助となれば幸いです。

0 or 1ではなくメインの型を置きながらも双方の利点を活かす工夫は必要です。このバランスのとり方についても参考文献では詳しく記載されていますので、さらに深掘りしたいという方はぜひご一読ください！

---
<参考文献>
1)『Balancing Agility and Discipline: A Guide for the Perplexed 』Barry Boehm,Richard Turner著Addison-Wesley Professional; 1版 (2003/8/11) , No 1619/4331

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

執筆者プロフィール：谷岡 俊祐
2児の父。SIerにて自治体向けシステム開発に長年従事した後、SHIFTへ入社。エンジニアの知見とQA×SMの観点で業務改善や因数分解、チーム改善が得意。
最近は蓄積された知見や業務を如何に低コストで掬い上げるかをテーマに手法確立に向けて試行錯誤中。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/