アジャイル開発に関する有識者検討会（第7回）

概要

本検討会の概要は、アジャイル開発に関する有識者検討会をご覧ください。

開催情報

日時：
令和8年（2026年）1月28日（水）15時00分から16時00分まで
場所：
オンライン（Microsoft Teams）
出席委員：
狩野座長、杉井委員、岡島委員、佐野委員、木村アドバイザー

議事次第

  • 開会
  • 座長の挨拶
  • 議事
    • 前回の有識者検討会の振り返り
    • 論点と仮説の共有及び議論
    • 今後のスケジュール
  • 閉会・諸連絡

資料

議事要旨

事務局から前回の検討会の振り返り、今回の検討会での論点と仮説について説明があった後、討議が行われた。各委員からの主な意見は以下のとおり。

アジャイル開発における会計監査・会計検査における留意事項

  • 現在、所属している組織において、基幹システムの開発を実施しているが、業務を適切に遂行していることの説明に関し、進捗やチームのパフォーマンス等の効率性については、社長や役員からの指摘も多い。その際、ベロシティの比較はするべきではないことや、相対見積りにおけるストーリーポイントの考え方を説明するが、理解されないことが多いため、複数チームや規模の大きいプロジェクトでは、見積りの基準にするストーリーとその大きさは合わせて比較・説明できるようにしておくことが望ましい。そのように対応することが結果的に、予算をとることや、説明責任を果たすことにおいては、重要な活動になる。そのため、現場で使っている数字と報告する数字は、切り分けて考えた方が良いと考える。なお、ストーリーとその大きさは合わせるというのは、全てのチームが、同じストーリーポイントで基準を置くということである。例えば、ECサイトで購入するところまで作成するとなった際、ECサイトを作らないチームも基準を合わせて、各チームの作業がどれくらいかを合わせておくと結果的にスムーズにいく。現場目線では理解されにくいやり方かもしれないが、プロジェクトマネジメント目線では、上位層へ適切に説明ができ、最終的にはコスト抑制も実現できたのではないかと感じている。ただし、これが絶対的に正解なやり方だとは思っていない点は留意いただきたい。
  • 他の委員が説明した事例と同様に、発注している金額や工数の話に戻して進めていくことは何度か経験がある。現場のベロシティの話と、上位層への報告や費用対効果の話は分けて議論していた。
  • アジャイル開発で、要件がうまく事業者に伝わらず、スプリント1で開発したものの修正が必要になり、本来1スプリントで済む開発が2スプリント要してしまった場合、スプリントの記録が残ることで、監査等で指摘される可能性が出てくるのではないか。
  • アジャイル開発に限らず、ウォーターフォール開発でも要件漏れはあり得るため、不具合やバグとして扱うことも一つの案である。ユーザーのフィードバックを受け、異なる要望が出てくることもあり、適切に取り組んでいれば説明ができると考える。
  • アジャイル開発が、準委任契約の作業の内容と同じように検査されるのであれば、善管注意義務を果たしていると証明できるものは定性的なものしかないと考える。
  • 民間では善管注意義務が果たされていることを証明するにあたって、タスクは個人ごとに割り振られ、チケットの履歴も残るため、特に問題視したことはなかった。準委任契約では、週単位や月単位で稼働報告を実施するため、各メンバーの稼働状況も証明できる。タスクやバックログをチケットで管理する際、スプリント1からスプリント2へ移行時に、終わらなかったタスクをそのままスプリント2に移すと、スプリント1で何をしたかが後で分からなくなるため、新しいチケットとしてスプリント2に引き継ぐなど、記録を残して作業履歴を追いやすくすることは重要である。
  • 留意事項として、バグの修正もチケットに残しておくことで、普段のタスク管理を後で追えるようにしておくことは大事なポイントである。

最初のスプリント開始前の準備事項

  • 特に、優先的にインプットすべき活動について、デザインの要素があるシステムの場合、デザインをいつ行うかを議論する必要がある。調達のタイミングや、アサインできる要員の状況なども関わってくるが、いきなり画面を作ろうとしてデザインが決まっていないと作業を進めることができないため、デザインを事前に検討しておくことが重要である。所属している組織の事例では、ノーコードのようなものが多かったため、チームビルディングに重点を置いていた。デザインやアーキテクチャが含まれるような場合は、最初に作り込んでおかないとスムーズに進められないので、事前準備として、チームメンバーが一斉に作業を開始できる状態を整えられるよう準備期間ややるべきことを決めることが重要である。土台作りや共通部分を作ることは、高いスキルが求められるため、担当者の選定は注意して行っている。
  • チームビルディングの土台作りにあたっては、ビルディングしながら、シニアエンジニアやアーキテクトで、開発環境の準備も含め技術検証を行っていた。資料2のP.18では準備期間を2週間とするとされているが、チーム状況によっては、準備期間が2週間を超える場合もあるため、2週間という期間がひとり歩きしないように留意する必要がある。
  • 準備として、システム開発前に、デザインシステムを使い、画面のイメージやアーキテクチャの検証等を済ませておくとスムーズである。また、アーキテクチャ検証で、実際に動くものを見ておくことでリスクが下がると考える。その上で、資料2のP.18で仮説として書かれていることに取り組むと効率よく進めていけるのではないか。インセプションデッキの準備事例として、トレードオフ・スライダー（プロジェクトの中で必要な機能の取捨選択をする際に立ち返る指標）を入れておくべきである。そうすることで、品質に関する問題が起きにくい。
  • 他委員の発言と同様に、システムの待機的な設計のリスクを未然に防ぐよう留意している。ハイブリッド型で開発するのか、純粋なアジャイルで開発するのかで準備期間は変わってくる。準備事項について、従来型のプロセスとの差分や追加のような形で表現すると分かりやすいのではないか。アジャイル開発やスクラム関係なく、調達時に要件として求めるべき準備事項はあると思う。アジャイル開発やスクラムの場合はそれらをべースに資料2のP.18の準備事項例をバランスよく追加する形がよいのではないか。
  • スプリント開始前の準備事項における成功事例のパターン化することは、できなくもないと考えるが、いずれにせよアジャイル開発に限らず、プロジェクト計画ができる適切なベンダーを選定することが重要である。
  • 重要な観点はしっかり記載し、書かれていない場合は評価を下げるなど、絶対に必要なライン（条件）があれば示しておくべきである。
  • 他委員発言の示すべき重要な観点について、補足すると、インセプションデッキは何のために作るのか、どのようなプロジェクトリスクを排除するためにやるのか、従来型のウォーターフォール開発との違いが重要となる。インセプションデッキの部分はプロダクトのゴールをベンダー側と理解を深めるために行い、その齟齬があるとうまくいかない。チームビルディングは従来型と違い、より密なコミュニケーションが必要であることが課題や懸念点になる。それぞれのプロジェクトごとの課題やリスク、懸念点に対してやるべきことを判断した上で、重要な項目を選択するという形がよい。
  • その他、スプリント開始前までに、どのような状態になっていると良いか、という観点で表現できると良い。スプリントを開始する際に、「安心して進められる状態」に向けて手段を選択して実行していくことが重要である。

以上