応用情報技術者 2017年 春期 午後 問08
アジャイル型開発に関する次の記述を読んで、設問1~4に答えよ。
U社は、コンビニエンスストアを全国展開する企業である。自社ブランド商品のファンを作るために、オリジナルのゲームなどが楽しめる専用の SNS(以下、本システムという)を開発することになった。
本システムでは、利用者を引き付け続けるために、コンテンツを頻繁にリリースしていく必要がある。そのため、ソフトウェア開発モデルとしてアジャイル型開発を採用する。
〔採用するプラクティスの検討〕
アジャイル型開発で用いられるチーム運営や開発プロセス、プログラミングなどの実践手法をプラクティスと呼ぶ。本システム開発における、システム要件や開発体制の特徴は次のとおりである。これに基づいて、採用するプラクティスを検討する。
・スコープの変動が激しい
テレビやコマーシャルなどの影響によって、要求の変更が頻繁に発生する。そのために、本システムの品質に責任をもち、優先順位や仕様を素早く決める役割をもつプロダクトオーナを任命する。そして、本システムの要求全体と優先順位を管理するためにaを採用し、反復する一つの開発サイクル(以下、イテレーションという)において、開発対象となる要求を管理するためにbを採用する。
・求められる品質が高い
一般消費者向け SNS という性質上、その不具合は利用者離れを引き起こしかねない。一定レベル以上の品質を保つために、継続的インテグレーション(以下、CIという)を採用する。
・チームメンバーの半数のスキルが未成熟
アサインされたプロジェクトメンバには、アジャイル型開発のベテラン社員と、スキルが未成熟な若手社員が含まれる。チームの中で業務知識やソースコードについての知識を互いに共有して、品質や作業効率を向上させるためにcを採用する。
この検討結果のレビューを社内の有識者から受けたところ、チーム全体の状況を共有するために、その①作業状態を可視化した環境を作り、メンバ全員が集まって必要な情報を短い時間で共有する日次ミーティングも採用するように、との指摘を受けた。
〔開発環境の検討〕
本システムは、不特定多数の一般消費者に対して速いレスポンスを提供するために、コンパイル型言語を用いて Webシステムとして開発する。
想定される開発環境の構成要素を表1に示す。

表1のレビューを社内の有識者から受けたところ、開発用 DBサーバは、ライセンス及び②構成管理上のメリットを考慮して、各開発用 PC内ではなく、共同の開発用 DBサーバを用意し、その中にスキーマを一つ作成して共有した方がよい、との指摘を受けた。また、ベテラン社員から、③開発者が一つのスキーマを共有してテストを行う際に生じる問題を避けるためのルールを決めておくとよい、とのアドバイスを受け、開発方針の中に盛り込むことにした。
〔CIサーバの実装〕
高い品質と迅速なリリースの両立のために、自動化された回帰テスト及び継続的デリバリを実現する処理を CIサーバ上に実装する。その処理手順を次に示す。
(1) ソースコード管理サーバから最新のソースコードを取得する。
(2) インターネットから最新のオープンソースライブラリを取得する。
(3) d に、(1) と (2) で取得したファイルをコピーして処理させて、モジュールを生成する。
(4) (3) で生成されたモジュールに、結合テスト環境に合った設定ファイルを組み込み、結合テスト用サーバに配置する。
(5) Webテストサーバに登録されているテストシナリオを実行する。
(6) (5) の実行結果を e に登録し、その登録した実行結果へのリンクを電子メールでプロダクトオーナとプロジェクトメンバに報告する。
(7) プロダクトオーナが (6) の報告を確認して承認すると、(3) で生成したモジュールに、本番環境に合った設定ファイルを組み込み、本番用サーバに配置する。
〔回帰テストで発生した問題〕
イテレーションを複数サイクル行い、幾つかの機能がリリースされて順調に次のイテレーションを進めていたある日、CIサーバからテストの失敗が報告された。失敗の原因を調査したところ、インターネットから取得したオープンソースライブラリのインタフェースに問題があった。最新のメジャーバージョンのバージョンアップで、インタフェースが変更されていたことが原因であった。このオープンソースライブラリのバージョン管理ポリシによると、マイナーバージョンの更新ではインタフェースは変更せず、セキュリティ及び機能上の不具合の修正だけを行う、とのことであった。
そこで、インターネットから取得するオープンソースライブラリのバージョンに④適切な条件を設定することで問題を回避することができた。
設問1:〔採用するプラクティスの検討〕について、(1)、(2)に答えよ。
(1)本文中の a ~ c に入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:アジャイルコーチ
イ:インセプションデッキ
ウ:スプリントバックログ
エ:プランニングポーカー
オ:プロダクトバックログ
カ:ペアプログラミング
キ:ユーザストーリ
ク:リファクタリング
模範解答
a:オ
b:ウ
c:カ
解説
解答の論理構成
-
[引用] 「本システムの要求全体と優先順位を管理するためにaを採用し」
・要求全体を一覧し、優先度順に並べ替えるリストは Scrum では “プロダクトバックログ” が定番です。
・解答群で対応する語は「オ:プロダクトバックログ」。
⇒ a=オ -
[引用] 「反復する一つの開発サイクル(以下、イテレーションという)において、開発対象となる要求を管理するためにbを採用する。」
・イテレーション(Sprint)単位で “今サイクルでやる項目” を抜粋したリストは “スプリントバックログ” です。
・解答群で対応する語は「ウ:スプリントバックログ」。
⇒ b=ウ -
[引用] 「チームの中で業務知識やソースコードについての知識を互いに共有して、品質や作業効率を向上させるためにcを採用する。」
・知識共有と品質向上を同時に狙う典型プラクティスは “ペアプログラミング”。
・解答群で対応する語は「カ:ペアプログラミング」。
⇒ c=カ
誤りやすいポイント
- 「イ:インセプションデッキ」を a に選ぶミス
要求一覧ではなくプロジェクト憲章的ドキュメントを指すため用途が異なります。 - b に「エ:プランニングポーカー」を選ぶミス
プランニングポーカーは見積り手法であり、イテレーション中の要求管理表ではありません。 - c に「ク:リファクタリング」を選ぶミス
リファクタリングは設計改善であり、知識共有を直接目的とはしていません。
FAQ
Q: プロダクトバックログとスプリントバックログの違いは何ですか?
A: 前者は「長期にわたる全要求の優先度付き一覧」、後者は「現在のイテレーションで着手する項目だけを抜粋した作業リスト」です。
A: 前者は「長期にわたる全要求の優先度付き一覧」、後者は「現在のイテレーションで着手する項目だけを抜粋した作業リスト」です。
Q: ペアプログラミングは必ず二人一組で全時間行うのですか?
A: 開発文化やタスクの性質に応じて “重要モジュールのみ” など限定的に適用するケースも多くあります。
A: 開発文化やタスクの性質に応じて “重要モジュールのみ” など限定的に適用するケースも多くあります。
Q: プランニングポーカーは本問で全く不要なのですか?
A: 要件見積り時には有用ですが、設問が求める “イテレーション内の要求管理” とは役割が異なるため不正解になります。
A: 要件見積り時には有用ですが、設問が求める “イテレーション内の要求管理” とは役割が異なるため不正解になります。
関連キーワード: プロダクトバックログ, スプリントバックログ, ペアプログラミング, イテレーション, 要求管理
設問1:〔採用するプラクティスの検討〕について、(1)、(2)に答えよ。
(2)本文中の下線①の環境を作るためのプラクティスを一つ答えよ。
模範解答
タスクボード
解説
解答の論理構成
- 問題文で求められているのは、チーム全体の状況を共有するために
“その①作業状態を可視化した環境を作り、メンバ全員が集まって必要な情報を短い時間で共有する日次ミーティング”
を導入するプラクティスです。 - アジャイル型開発では、カードや付せんを使って「誰が・何を・どこまで」進めているかを一目で分かるようにする情報ラジエータとして
“タスクボード”(Task Board/看板とも呼ばれる)
を設置するのが定石です。 - タスクボードは “作業状態(未着手 → 進行中 → 完了 など)を可視化” し、デイリースクラムや立ち会議時に最新状況を即座に共有できます。問題文の要件「作業状態を可視化」「短い時間で共有」に完全に合致するため、解答は
“タスクボード”
となります。
誤りやすいポイント
- “バーンダウンチャート” と混同する
→ バーンダウンチャートは残作業量の推移を示すグラフで、作業状態を一覧で可視化するボードとは用途が異なります。 - “かんばん方式” と回答してしまう
→ かんばんは概念として正しいものの、本問は具体的な環境(ボード)を問うているので “タスクボード” と書く方が適切です。 - “CIツール画面” と解釈する
→ CI はビルドやテストの自動化であり、日々のタスク進捗そのものを可視化する目的ではありません。
FAQ
Q: タスクボードは物理ボードでないといけませんか?
A: 物理・電子いずれも可ですが、アジャイルの原則では “常に見える場所” に置くことが重要です。遠隔チームの場合はオンラインボードを採用する例が増えています。
A: 物理・電子いずれも可ですが、アジャイルの原則では “常に見える場所” に置くことが重要です。遠隔チームの場合はオンラインボードを採用する例が増えています。
Q: デイリーミーティングではタスクボードのどこを確認しますか?
A: 未完了タスクにフォーカスし、「昨日やったこと・今日やること・障害」を 15 分程度で共有します。ボードの列移動が進行状況の更新そのものになります。
A: 未完了タスクにフォーカスし、「昨日やったこと・今日やること・障害」を 15 分程度で共有します。ボードの列移動が進行状況の更新そのものになります。
Q: タスクボードとプロダクトバックログの違いは何ですか?
A: プロダクトバックログは “要求の一覧と優先順位”、タスクボードは “現在のイテレーションに割り当てたタスクの進捗” を示す点が異なります。
A: プロダクトバックログは “要求の一覧と優先順位”、タスクボードは “現在のイテレーションに割り当てたタスクの進捗” を示す点が異なります。
関連キーワード: タスクボード, 可視化, スクラム
設問2:〔開発環境の検討〕について、(1)、(2)に答えよ。
(1)本文中の下線②にある、構成管理上のメリットを35字以内で述べよ。
模範解答
DBサーバの設定やテーブル定義などの構成を一元管理できる。
解説
解答の論理構成
- 【問題文】には「開発用 DBサーバは、ライセンス及び②構成管理上のメリットを考慮して、…共同の開発用 DBサーバを用意し、その中にスキーマを一つ作成して共有」と記載されています。
- “共同の”サーバを利用すれば、DBに関する設定やテーブル定義は全員が参照する単一箇所に集約されます。
- 集約されることで
・個々の開発用 PCに同一変更を繰り返し適用する手間を排除
・バージョン差異・設定漏れなどの構成ドリフトを防止
・変更履歴の追跡・監査が容易
となり、構成を“一元管理”できる点が最大の利点です。 - 以上より、「DBサーバの設定やテーブル定義などの構成を一元管理できる。」が適切な記述となります。
誤りやすいポイント
- ライセンスコストの削減だけを答えてしまい、構成管理の観点を落とす。
- 「データ量が増えても性能が出る」といった性能面をメリットとして挙げる。
- 「バックアップが楽になる」など運用全般に話を広げ過ぎて、構成管理に直結しない説明をしてしまう。
FAQ
Q: なぜ各開発者の PC に個別 DB を置くと構成管理が難しいのですか?
A: 個別 DB では設定・テーブル変更が発生するたびに全 PC へ同一作業を実施する必要があり、適用漏れやバージョン差異が発生しやすくなります。
A: 個別 DB では設定・テーブル変更が発生するたびに全 PC へ同一作業を実施する必要があり、適用漏れやバージョン差異が発生しやすくなります。
Q: スキーマを一つだけ共有するとテストデータの競合が心配です。対策は?
A: 本文中で「③開発者が一つのスキーマを共有してテストを行う際に生じる問題を避けるためのルール」とあるように、データ分割ポリシやトランザクション制御などを運用ルールとして定めるのが一般的です。
A: 本文中で「③開発者が一つのスキーマを共有してテストを行う際に生じる問題を避けるためのルール」とあるように、データ分割ポリシやトランザクション制御などを運用ルールとして定めるのが一般的です。
Q: 構成管理ツールを使っても個別 DB で問題ないのでは?
A: ツールで定義ファイルを管理しても、適用先が複数ある限り “適用漏れ” リスクは残ります。共有 DB はそもそも適用箇所が一つなのでツールと併用するとより確実です。
A: ツールで定義ファイルを管理しても、適用先が複数ある限り “適用漏れ” リスクは残ります。共有 DB はそもそも適用箇所が一つなのでツールと併用するとより確実です。
関連キーワード: 構成管理, データベース, スキーマ共有, テスト環境
設問2:〔開発環境の検討〕について、(1)、(2)に答えよ。
(2)本文中の下線③の問題を40字以内で述べよ。
模範解答
自身のテストデータと他の開発者のテストデータとの見分けがつかない。
解説
解答の論理構成
- 【問題文】では、共同の開発用 DBサーバに「スキーマを一つ作成して共有」するとあります。
引用:「開発者が一つのスキーマを共有してテストを行う際に生じる問題」 - 一つのスキーマを複数人で使うと、各人が投入したテストデータが物理的に同じテーブルへ混在します。
その結果、どのレコードが誰の検証用かが区別できなくなります。 - これにより「自分が投入したデータと思って操作したら、実は別メンバのデータだった」「意図せず他人のデータを削除・更新してしまった」といった不整合が発生します。
- したがって③の問題は「自身のテストデータと他の開発者のテストデータとの見分けがつかない。」という結論になります。
誤りやすいポイント
- 「同時更新によるロック競合」を答える受験者が多いですが、競合は結果であって“見分けがつかない”ことが本質です。
- 「スキーマごと破壊される危険性」など大きすぎる問題に飛躍しやすい点に注意しましょう。
- 「共同利用=性能低下」と早合点しやすいですが、本設問は運用面の識別性がテーマです。
FAQ
Q: スキーマを分ければ問題は完全に解決しますか?
A: 少なくともテストデータの混在は防げますが、構成管理やリソースの重複など別のコストが発生します。
A: 少なくともテストデータの混在は防げますが、構成管理やリソースの重複など別のコストが発生します。
Q: 共有スキーマのまま問題を軽減する方法はありますか?
A: テストデータの命名規約(プレフィックス付与など)やトランザクションを使った一時データ化、時間帯を区切った利用ルールなどが現実的です。
A: テストデータの命名規約(プレフィックス付与など)やトランザクションを使った一時データ化、時間帯を区切った利用ルールなどが現実的です。
Q: CIサーバとの関係は?
A: CIサーバが自動テストを流す際にも同じスキーマを使うとデータ衝突が起こり得るため、テスト用スキーマの分離かリセット処理が推奨されます。
A: CIサーバが自動テストを流す際にも同じスキーマを使うとデータ衝突が起こり得るため、テスト用スキーマの分離かリセット処理が推奨されます。
関連キーワード: スキーマ共有, テストデータ, 構成管理, CI, コンフリクト
設問3:
(1)〔CIサーバの実装〕について、本文中の d、e に入れる適切な字句を表1の要素名で答えよ。
模範解答
d:ビルドサーバ
e:チケット管理サーバ
解説
解答の論理構成
-
[ d ]に入るべき要素を確認
(3) には「“モジュールを生成する”処理を担当するサーバ」を指定する必要があります。表1には
「“ビルドサーバ:プログラムをコンパイルし、モジュールを生成する。”」
とあります。原文が示す動作と一致するのは「ビルドサーバ」だけなので、[ d ]=「ビルドサーバ」と判断できます。 -
[ e ]に入るべき要素を確認
(6) には「“実行結果を登録”し、リンクを全員へ通知する」機能が求められます。表1の
「“チケット管理サーバ:…設計やプログラム作成、テストなどを計画から実行、結果まで記録する”」
という説明が、テスト結果を格納・共有する目的に合致します。よって[ e ]=「チケット管理サーバ」となります。 -
まとめ
・[ d ]=「ビルドサーバ」
・[ e ]=「チケット管理サーバ」
誤りやすいポイント
- 「CIサーバ」が(3)を担当すると早合点しやすい
CIサーバは全工程を自動化するハブであり、“ビルド”そのものは「ビルドサーバ」に委譲する設計が一般的です。 - テスト結果を「ソースコード管理サーバ」に入れると考えてしまう
バージョン管理はファイル履歴を扱うもので、テスト結果やタスクの状態は「チケット管理サーバ」の役割です。 - 名称の取り違え
「チケット管理サーバ」と「タスク管理ツール」を混同し、設問要求の“表1の要素名”を正確に書かず減点になるケースがあります。
FAQ
Q: CIサーバだけでビルドもテストも行えるのでは?
A: CIサーバは“ビルドサーバを呼び出す”など各種ジョブを統括する仕組みです。ビルド処理自体は「ビルドサーバ」が担当し、役割分担を明確にすることでスケールや保守が容易になります。
A: CIサーバは“ビルドサーバを呼び出す”など各種ジョブを統括する仕組みです。ビルド処理自体は「ビルドサーバ」が担当し、役割分担を明確にすることでスケールや保守が容易になります。
Q: テスト結果をソースコードと一緒にリポジトリへコミットしてはいけませんか?
A: テストログは容量が大きく頻繁に更新されるため、ソース履歴と同じリポジトリに置くと差分管理が煩雑になります。チケット管理サーバに紐付ければ、タスク・バグ・テスト結果を一元的に追跡でき、関係者への通知も自動化できます。
A: テストログは容量が大きく頻繁に更新されるため、ソース履歴と同じリポジトリに置くと差分管理が煩雑になります。チケット管理サーバに紐付ければ、タスク・バグ・テスト結果を一元的に追跡でき、関係者への通知も自動化できます。
Q: ビルドサーバとCIサーバを同一マシンで運用しても問題ありませんか?
A: 小規模プロジェクトでは物理的に同一でも構いませんが、論理的な役割は分けておく方が障害切り分けや性能チューニングが容易です。
A: 小規模プロジェクトでは物理的に同一でも構いませんが、論理的な役割は分けておく方が障害切り分けや性能チューニングが容易です。
関連キーワード: 継続的インテグレーション, 自動ビルド, 回帰テスト, タスク管理
設問4:
〔回帰テストで発生した問題〕中の下線④の条件とは、どのような条件か。40字以内で述べよ。
模範解答
利用中のメジャーバージョンの中で最新のマイナーバージョンであること
解説
解答の論理構成
- 不具合発生の原因
- 問題文は、失敗原因を「“最新のメジャーバージョンのバージョンアップで、インタフェースが変更されていたこと”」と述べています。
- つまり major version を上げたことで互換性が失われたと分かります。
- バージョン管理ポリシの確認
- 同じ箇所で「“マイナーバージョンの更新ではインタフェースは変更せず”」と明記しています。
- minor version なら互換性が保たれることが保証されています。
- 適切な条件を導く
- メジャーバージョンを固定すればインタフェースは維持される。
- そのうえで最新の minor version を選べば「“セキュリティ及び機能上の不具合の修正”」も取り込めます。
- 以上より、下線④は「利用中のメジャーバージョンの中で最新のマイナーバージョンであること」となります。
誤りやすいポイント
- 「最新なら常によい」と考え、major まで自動更新してしまう。
- 逆に「固定すれば安全」と考え、minor すら更新せず脆弱性を放置する。
- バージョン番号の桁を取り違え、patch と minor を混同する。
FAQ
Q: major と minor は何を基準に区別されますか?
A: 多くの OSS は semantic versioning を採用し、重大な互換性変更があるときに major が上がり、互換性を保った機能追加・修正は minor で行います。
A: 多くの OSS は semantic versioning を採用し、重大な互換性変更があるときに major が上がり、互換性を保った機能追加・修正は minor で行います。
Q: CI でバージョンを固定すると更新が面倒になりませんか?
A: major を固定したうえで minor を自動取得する設定にすれば、互換性を保ちつつ自動更新が可能です。
A: major を固定したうえで minor を自動取得する設定にすれば、互換性を保ちつつ自動更新が可能です。
Q: patch レベルまで固定した方が再現性は高いのでは?
A: 再現性は高まりますが、セキュリティパッチの適用を逃すリスクも増えます。CI で同一 major 内の最新 minor・patch を取り込む方が実務的なバランスです。
A: 再現性は高まりますが、セキュリティパッチの適用を逃すリスクも増えます。CI で同一 major 内の最新 minor・patch を取り込む方が実務的なバランスです。
関連キーワード: バージョン管理, セマンティックバージョニング, 回帰テスト, 継続的インテグレーション, 依存関係管理


