【実務思考】【AU-H30-1-PM2-Q1】アジャイル型開発に関するシステム監査

🍀概要

 システム監査技術者試験 平成30年 午後2 問1について、AIを活用して、詳細分析した結果を示します。
 本分析は、AIが問題文からその背景にある本質的な課題を深く掘り下げ、システム監査人が目指すべき理想像の一端を理解することに役立つよう、多角的な視点から考察したものです。これにより、単なる模範解答の提示に留まらず、論述問題を通して試される思考プロセス問題解決のアプローチを深く理解するための示唆を提供します。

🧾問題・設問(AU-H30-1-PM2-Q1)

 出典:情報処理推進機構 システム監査技術者試験 平成30年 午後2 問1(🔗取り扱いガイドライン)

📘問題

■タイトル
 アジャイル型開発に関するシステム監査について
■内容
 情報技術の進展,商品・サービスのデイジタル化の加速,消費者の価値観の多様化など,ビジネスを取り巻く環境は大きく変化してきている。競争優位性を獲得・維持するためには,変化するビジネス環境に素早く対応し続けることが重要になる。
 そのため,重要な役割を担う情報システムの開発においても,ビジネス要件の変更に迅速かつ柔軟に対応することが求められる。特に,ビジネス要件の変更が多いインターネット関連ビジネスなどの領域では,非ウォータフォール型の開発手法であるアジャイル型開発が適している場合が多い。
 アジャイル型開発では,ビジネスに利用可能なソフトウェアの設計から,コーディング,テスト及びユーザ検証までを1~4週間などの短期間で行い,これを繰り返すことによって,ビジネス要件の変更を積極的に取り込みながら情報システムを構築することができる。また,アジャイル型開発には,開発担当者とレビューアのペアによる開発常時リリースするためのツール活用,テスト部分を先に作成してからコーディングを行うという特徴もある。その一方で,ビジネス要件の変更を取り込みながら開発を進めていくので,開発の初期段階で最終成果物,スケジュール,コストを明確にするウォータフォール型開発とは異なるリスクも想定される。
 システム監査人は,このようなアジャイル型開発の特徴,及びウォータフォール型開発とは異なるリスクも踏まえて,アジャイル型開発を進めるための体制,スキル,開発環境などが整備されているかどうかを,開発着手前に確かめる必要がある。
 あなたの経験と考えに基づいて,設問ア~ウに従って論述せよ。

📗設問

■設問ア
 あなたが関係する情報システムの概要,アジャイル型開発手法を採用する理由,及びアジャイル型開発の内容について,800字以内で述べよ。
■設問イ
 設問アで述べた情報システムの開発にアジャイル型開発手法を採用するに当たって,どのようなリスクを想定し,コントロールすべきか。ウォータフォール型開発とは異なるリスクを中心に,700字以上1,400字以内で具体的に述べよ。
■設問ウ
 設問ア及び設問イを踏まえて,アジャイル型開発を進めるための体制,スキル,開発環境などの整備状況を確認する監査手続について,監査証拠及び確認すべきポイントを含め,700字以上1,400字以内で具体的に述べよ。

📔出題趣旨・採点講評(IPA)

■出題趣旨
 インターネット関連ビジネスなど,ビジネス要件の変更が多い領域において,アジャイル型開発手法を採用して情報システムを開発する事例が増えてきている。アジャイル型開発は,短期間での開発とリリースを繰り返して,ビジネス要件の変更を積極的に取り込むことによって,ビジネス環境の変化に迅速かつ柔軟に対応しようとする開発手法である。一方で,開発の初期段階で,最終成果物,コスト,スケジュールを明確にするウォータフォール型開発とは異なるリスクも想定される。
 本問では,システム監査人として,アジャイル型開発の特徴を踏まえた上で,情報システムの開発着手前に,アジャイル型開発を進めるための体制,スキル,開発環境などが整備されているかどうかを監査する知識・能力などを問う。
■採点講評
 問1(アジャイル型開発に関するシステム監査について)は,設問アでは,アジャイル型開発の内容について論述していない解答や,情報システムの内容の論述にとどまっている解答が多かった。設問イでは,設問アで述べた情報システムの開発にアジャイル型開発手法を採用するに当たってのリスクとコントロールを求めているが,一般的な内容で具体性のない論述や,リスクだけでコントロールが記述されていない解答が散見された。設問ウでは,体制,スキル,開発環境などの整備状況を開発着手前に確認する監査手続を求めているが,運用段階での監査手続を論述している解答が目立った。また,監査手続ではなく,監査結果を論述している解答も多かった。解答に当たっては,問題文と設問をよく読み,題意を踏まえて論述してほしい。

🪄詳細分析(AI)

📝3行まとめ

  1. 【背景】ビジネス環境の急速な変化に対応するため、アジャイル型開発の採用が拡大しています。
  2. 【監査視点】アジャイル特有のリスク(成果物・コスト不透明化、品質低下、属人化)と、体制や開発環境の整備状況を監査する必要があります。
  3. 【行動・着眼点】監査人は、アジャイルのフレームワーク遵守状況や役割分担、進捗管理手法を具体的に確認し、開発着手前に評価すべきです。

🧭アジャイル型開発に関するシステム監査についての考察

1. 問題の背景と現状分析

  • 現状の課題・問題点:
    • ビジネス環境の変化が速まり、数ヶ月~数年先の要件を完全に確定させてから開発を始める伝統的な「ウォーターフォール型開発」では、市場のニーズに追いつけなくなってきた。
    • 特に、ビジネス要件の変更が頻繁に発生するインターネット関連ビジネスなどでは、柔軟に対応できる新たな開発手法が求められた。
    • その答えの一つとして、短い期間(1~4週間)のサイクルで設計・実装・テスト・検証を繰り返し、要件変更を積極的に取り込みながら開発を進める「アジャイル型開発」が注目されている。
    • しかし、アジャイル型開発は、ウォーターフォール型開発とは、その思想、プロセス、文化が全く異なり、特有のリスクを内包している。
    • 例えば、初期段階で最終成果物や総コストが不明確、頻繁な変更で品質が劣化する、文書が軽視され属人化が進む、といったリスクがある。
    • 従来のウォーターフォール型を前提とした監査手法では、アジャイル型開発を適切に評価できない。
  • 変化の必要性の背景:
    • 不確実性の増大とTime-to-Marketの短縮: 将来の予測が困難な時代(VUCAワールド)において、最初に完璧な計画を立てるアプローチが機能しなくなった。動くソフトウェアを迅速に市場に投入し、フィードバックを得ながら改善していくアプローチが求められた。
    • 顧客価値の最大化: プロジェクトの成功を、当初の計画(スコープ、コスト、納期)を守ることではなく、「顧客にとっての価値を最大化すること」と再定義する動きが広まった。
    • 開発者のエンゲージメント向上: 自己組織化されたチームが、裁量を持って開発を進めるアジャイルのアプローチが、開発者のモチベーションや生産性を高める効果も期待された。

2. 理想像の抽出と具体化

  • あるべき理想的な状態:
    • 規律あるアジャイル(Disciplined Agile)の実践: アジャイル開発が、単なる「行き当たりばったり」の開発ではなく、スクラムなどの確立されたフレームワークに基づき、明確な役割(プロダクトオーナー、スクラムマスター等)、イベント(スプリント計画、デイリースクラム等)、成果物(プロダクトバックログ等)を持って、規律ある形で実践されている。
    • ビジネスと開発の一体化: ビジネス部門の代表者であるプロダクトオーナーが、常に開発チームと一体となって活動し、開発の優先順位付けや仕様の決定に責任を持つ。これにより、ビジネス価値のないものが作られるリスクを低減する。
    • 自動化された品質保証(CI/CD): 頻繁なリリースを品質を維持しつつ行うため、テストやデプロイのプロセスが徹底的に自動化されている(CI/CDパイプライン)。「完成の定義(Definition of Done)」には、これらの自動テストをパスすることが含まれている。
    • 透明性と継続的な改善: プロジェクトの状況(ベロシティ、バーンダウンチャートなど)が、物理的または電子的なカンバンなどで常にチーム内外に「見える化」されている。スプリントの最後には、必ず「ふりかえり(レトロスペクティブ)」を行い、チーム自身がプロセスを継続的に改善していく。
  • 克服すべき障壁:
    • 文化的な壁: 指示待ち文化や、部門間の縦割り意識が強い伝統的な組織に、自己組織化や部門横断を前提とするアジャイルの文化を根付かせることの難しさ。
    • プロダクトオーナーの不在・形骸化: ビジネス側のキーパーソンが多忙で、プロダクトオーナーとしての役割を十分に果たせず、開発チームが方向性を見失う。
    • 技術的負債の蓄積: 短期的な開発スピードを優先するあまり、リファクタリングや設計の見直しがおろそかになり、徐々にコードの品質が劣化していく。
    • 契約の難しさ: 最終的なスコープやコストが確定しないアジャイル開発を、従来の請負契約でどのように扱うかという問題。
  • 利害関係者の視点:
    • 経営層/ビジネス部門: 変化する市場ニーズに迅速に対応できる。投資対効果の高い機能から順にリリースされるため、早期に価値を享受できる。
    • 開発チーム: 官僚的なプロセスや不要なドキュメント作成から解放され、価値のあるソフトウェア開発に集中できる。自己裁量で仕事を進められ、モチベーションが向上する。
    • 利用者: 開発の早い段階から、実際に動くソフトウェアに触れることができ、具体的なフィードバックを提供できる。最終的に自分の欲しいものと全く違うものができるリスクが低い。
    • 監査人: 従来のウォーターフォール型の監査(ゲートレビュー方式)から、アジャイルのリズムに合わせた監査へとマインドセットを切り替える。各スプリントの成果物やイベント(ふりかえり議事録など)を監査証拠とし、プロジェクトが「健全なプロセス」で進んでいるかを評価する。成果物(ドキュメント)ではなく「チームの振る舞い」を監査する。

3. 要約

  • [200文字]要約:
    アジャイル開発は、変化への迅速な対応を可能にするが、特有のリスクを持つ。理想像は、規律あるフレームワークに基づき、ビジネスと開発が一体となり、自動化された品質保証の下で開発を進めること。監査人は、スプリントごとの活動を評価し、チームが健全なプロセスで動いているかを検証する。
  • [400文字]要約:
    ビジネスの速度に対応するためアジャイル開発が普及したが、ウォーターフォール型とは異なるリスク管理が必要だ。あるべき理想像は、単なる場当たり開発ではなく、スクラム等の規律あるフレームワークを実践すること。ビジネス代表(プロダクトオーナー)が開発と一体化し、自動化されたテストで品質を担保し、ふりかえりを通じてプロセスを継続的に改善する。監査人は、従来の文書ベースの監査から脱却し、各スプリントの活動やチームの振る舞いを評価する必要がある。
  • [800文字]による詳細な考察:
    本問題は、ソフトウェア開発方法論の大きな潮流である「アジャイル」を取り上げ、伝統的な監査のアプローチが、この新しいパラダイムにどう適応すべきかという、監査部門にとってのデジタルトランスフォーメーション(DX)を問うている。監査人が、コンプライアンスをチェックする「警察官」から、チームの成功を支援する「コーチ」へと役割を変える必要性を示唆している。
    • あるべき理想像とは、「リーン・ガバナンス(Lean Governance)の原則に基づいた、信頼できるアジャイル開発エコシステム」の構築である。これは、アジャイルの価値(スピード、柔軟性)を損なうことなく、必要最小限かつ効果的な統制(ガバナンス)を組み込むアプローチを指す。理想的な状態では、監査人はプロジェクトの最後に登場するのではなく、開発の初期段階からチームの一員として(ただし独立性は保ちつつ)関与する。監査人は、デイリースクラムやスプリントレビューにオブザーバーとして参加し、チームの状況をリアルタイムで把握する。そして、スプリントの「ふりかえり」において、リスク管理や品質保証の観点から、チームのプロセス改善を支援するような建設的なフィードバックを提供する。監査の目的は、欠陥を見つけて指摘することではなく、チームが自ら欠陥に気づき、修正する能力(自己修正能力)を高める手助けをすることにある。
    • 理想像実現へのアプローチとして、システム監査人は、監査の「タイミング」「対象」「手法」を全面的に見直す。①タイミング:プロジェクト終了時の事後監査から、スプリントごとの継続的な監査へ。②対象:詳細な設計書や仕様書といった「静的なドキュメント」から、プロダクトバックログ、バーンダウンチャート、CI/CDパイプラインのログ、ふりかえりの議事録といった「動的な活動の記録」へ。③手法:チェックリストに基づく形式的な準拠性テストから、チームへのインタビューやワークショップへの参加を通じた、実態の理解と対話へ。監査人は、アジャイル開発チームが、そのフレームワーク(スクラム等)の儀式や原則を、形だけでなく「精神」まで含めて実践しているか、そしてそれがリスクの低減と価値の創出に繋がっているかを評価する。
    • 期待される効果は、ビジネス価値の高いソフトウェアを、品質を維持しながら、迅速かつ継続的に市場に提供できることである。
    • 考慮すべきリスクは、監査人がアジャイル開発への理解不足から、旧来のウォーターフォール型の考え方を押し付け、チームの自主性やスピードを阻害してしまうことだ。アジャイル監査を実践するには、監査人自身のマインドセットの変革と、アジャイルに関する深い学習が不可欠である。

📌補足(考察について)

「考察」の作成手順については、こちらで解説していますので、興味ある方はご参照ください。
なお、当サイトのAI活用方針につきましては、こちらをご確認ください。