応用情報技術者 2018年 秋期 午後 問08
継続的インテグレーションに関する次の記述を読んで、設問1~4に答えよ。
C社は、会員間で物品の売買ができるサービス(以下、フリマサービスという)を提供する会社である。出品したい商品の写真をスマートフォンやタブレットで撮影して簡単に出品できることが人気を呼び、C社のフリマサービスには、約1,000万人の会員が登録している。
C社には、サービス部と開発部がある。サービス部では、フリマサービスに関する会員からの問合せ・クレーム・改善要望の対応を行っている。開発部は、フリマサービスを利用するためのスマートフォン用アプリケーション(以下、Xという)、タブレット用アプリケーション(以下、Yという)、及びサーバ側アプリケーション(以下、Zという)について、開発から運用までを担当している。
競合のW社が新機能を次々にリリースして会員数を増加させていることを受け、C社でも新機能を早くリリースすることを目的に、開発プロセスの改善を行うことになった。開発プロセスの改善は、開発部のD君が担当することになった。
〔課題のヒアリング〕
D君は、開発部とサービス部に現状の開発プロセスの課題をヒアリングした。
開発部: リリースするたびに、追加・変更した機能とは直接関係しない既存機能で障害が発生しており、会員からクレームが多数出ている。機能追加・機能変更に伴い、設計工程では既存機能に対する影響調査を、テスト工程ではテストの強化を行っている。しかし、①既存機能に対する影響調査とテストを網羅的に行うことは、限られた工数では難しい。
サービス部:会員からのクレームや改善要望は日々記録しているが、現在の開発サイクルでは改善要望の対応に最大6か月掛かる。改善要望をまとめて大規模に機能追加する開発方法から、短いサイクルで段階的に機能追加する開発方法に変更してほしい。
〔継続的インテグレーションの導入〕
D君は、既存機能に対するテストを含めたテストの効率向上及び段階的な機能追加を実現するために、フリマサービスの開発プロジェクトに継続的インテグレーション(以下、CIという)を導入することにした。CIとは、開発者がソースコードの変更を頻繁にリポジトリに登録(以下、チェックインという)して、ビルドとテストを定期的に実行する手法であり、aに採用されている。CIの主な目的はb、c、及びリリースまでの時間の短縮である。
D君は、開発用サーバにリポジトリとCIツールをインストールし、図1に記載のワークフローとアクティビティを設定した。D君が設定したワークフローでは、リポジトリからソースコードを取得し、コーディング規約への準拠チェックとステップ数のカウントの後に、各アプリケーションのビルドと追加・変更箇所に対する単体テストを行い、テストサーバへ配備して、全アプリケーションを対象とするリグレッションテストを実行する。
またD君は、このワークフローを2時間ごとに実行するように設定し、各アクティビティの実行結果は正常・異常にかかわらずX、Y、Zの担当チームメンバ全員に電子メール(以下、メールという)で送信するように設定した。
なお、ワークフロー内のアクティビティは、前のアクティビティが全て正常終了した場合だけ、次のアクティビティが実行できるようにした。

〔テストプログラムの作成]
D君は、単体テストで利用するテストプログラムを作成した。テスト対象のプログラムとテストプログラムの例を図2に示す。テスト対象のプログラムであるcheckTimeは、時と分を示す二つの整数値を引数hourとminで受け取り、hourが0以上24未満の値かつminが0以上60未満の値であったらtrueを返し、それ以外の値であったらfalseを返すプログラムである。一方、テストプログラムであるtest_checkTimeは、境界値テストの考え方に基づき、6種類の境界値に対してそれぞれ checkTime を呼び出し、全ての呼出しで仕様どおりの値を返したら true を、それ以外なら false を返すプログラムである。
また、D君はこれまで手作業で行っていたリグレッションテストについても CI ツールで自動実行できるように、テストプログラムを作成した。

〔CIの試行〕
次に D君は、フリマサービスのアプリケーションの全てのソースコードをリポジトリに移行し、CI の試行を開始した。試行開始から 1 か月後、D君の設定した CI ツールは問題なく動作していたが、開発部のメンバから次の 3 点を指摘された。
指摘 1:一つの要求を実現するために必要なソースコードの変更は多岐にわたるので、チェックインは 1 週間に 1 回程度行っている。ワークフローは 2 時間ごとに動作するように設定されているが、1 週間に 1 度で十分である。
指摘 2:Y の単体テストでエラーが検出されていたが、CI ツールから送信されるメールが非常に多く、Y を担当するチームはエラーに気付かず、1 日放置されていた。②開発者がエラーに気付くように、CI ツールから送信されるメールを限定してほしい。
指摘 3:X のビルドでエラーが検出され、単体テストまでワークフローが流れないことが多い。このため、Z を担当するチームでは、開発者の開発 PC 上で CI ツールと同じテストケースを実行しており、③CI の導入効果が出ていない。
D君は、この3点の指摘について必要な対策を実施するとともに、要件定義から設計までのプロセスの見直しも行い、フリマサービスの開発プロジェクトにCIを適用した。その結果、段階的な機能追加を実現させ、新機能のリリースサイクルを短縮した。
設問1:
本文中のa〜cに入れる適切な字句を解答群の中から選び、記号で答えよ(bとcは順不同)。
解答群
ア:ウォータフォールモデル
イ:エクストリームプログラミング
ウ:設計の曖味性の排除
エ:ソフトウェア品質の向上
オ:バグの早期発見
カ:プロトタイピングモデル
キ:網羅的なテストケースの作成
ク:要件定義と設計の期間短縮
模範解答
a:イ
b:エ
c:オ
解説
解答の論理構成
- 問題文の確認
- 「CIとは、開発者がソースコードの変更を頻繁にリポジトリに登録(以下、チェックインという)して、ビルドとテストを定期的に実行する手法であり、aに採用されている。」
- 「CIの主な目的はb、c、及びリリースまでの時間の短縮である。」
- a に入る語句
- 継続的インテグレーションはアジャイル開発、特に「エクストリームプログラミング」で代表的に採用されるプラクティスです。
- 解答群より「イ:エクストリームプログラミング」を選択。
- b・c に入る語句
- CI の目的について、問題文は「ソフトウェア品質向上」「バグ早期発見」「リリースまでの時間短縮」という典型的な三本柱を提示している。
- 解答群を照合すると
・「エ:ソフトウェア品質の向上」
・「オ:バグの早期発見」 - 両語句の順序は問わないため、b=「エ」、c=「オ」で成立。
- 結論
- a:イ
- b:エ
- c:オ
誤りやすいポイント
- ウォータフォール型でもビルド自動化は行われることがありますが、頻繁な「チェックイン」を前提とする CI はアジャイル系プラクティスである点を取り違えやすいです。
- 「設計の曖味性の排除」「網羅的なテストケースの作成」なども品質向上に貢献しますが、CI の直接的な目的ではないため選択ミスが起こりがちです。
- b と c が順不同であることを読み飛ばし、記号を逆に配置して失点するケースがあります。
FAQ
Q: CI の目的に「リリースまでの時間の短縮」が含まれるのに、解答群に該当語句が無いのはなぜですか?
A: 問題文が既に「及びリリースまでの時間の短縮」と明示しているため、空欄には別の目的を入れさせる構成になっています。
A: 問題文が既に「及びリリースまでの時間の短縮」と明示しているため、空欄には別の目的を入れさせる構成になっています。
Q: 「プロトタイピングモデル」も短いサイクルですが、なぜ選ばないのですか?
A: プロトタイピングは要件探索のための試作が主眼で、CI のように継続的なビルド・テストをチーム全体の開発サイクルに組み込む前提ではありません。
A: プロトタイピングは要件探索のための試作が主眼で、CI のように継続的なビルド・テストをチーム全体の開発サイクルに組み込む前提ではありません。
Q: CI を導入すると品質は本当に上がるのですか?
A: 変更を即座にビルド・テストし「バグの早期発見」を実現することで、障害の混入率が下がり結果として「ソフトウェア品質の向上」に繋がります。
A: 変更を即座にビルド・テストし「バグの早期発見」を実現することで、障害の混入率が下がり結果として「ソフトウェア品質の向上」に繋がります。
関連キーワード: 継続的インテグレーション、アジャイル開発、自動ビルド、単体テスト、リグレッションテスト
設問2:本文中の下線①について、(1)、(2)に答えよ。
(1)既存機能に対するテストを行うために必要なCIツールのアクティビティを図1中の字句を用いて答えよ。
模範解答
リグレッションテスト
解説
解答の論理構成
- 下線①は【問題文】で
「①既存機能に対する影響調査とテスト」
とあり、既存機能が壊れていないことを確認するテストを求めています。 - CI 導入後のワークフロー説明に
「リポジトリからソースコードを取得し、…テストサーバへ配備して、全アプリケーションを対象とするリグレッションテストを実行する。」
と明記されています。 - 図1のアクティビティ一覧にも、最後の工程として「リグレッションテスト」が配置されています。
- リグレッションテストとは“回帰テスト”とも呼ばれ、追加・変更箇所とは無関係な既存機能へ影響がないかを確認するテストで、まさに①の目的に合致します。
- したがって、図1中の字句を用いた解答は
リグレッションテスト
となります。
誤りやすいポイント
- 「単体テスト」は変更箇所だけを対象にするため既存機能全体を網羅しません。
- 「統合テスト」「システムテスト」と混同しやすいですが、図1にその語は存在しません。
- 図1の語句を使う指示を見落として“回帰テスト”と日本語訳だけを書いてしまうと減点対象です。
FAQ
Q: 単体テストとリグレッションテストの違いは何ですか?
A: 単体テストは追加・変更箇所など限定範囲の動作確認、リグレッションテストはシステム全体を通し既存機能への副作用を検証する点が異なります。
A: 単体テストは追加・変更箇所など限定範囲の動作確認、リグレッションテストはシステム全体を通し既存機能への副作用を検証する点が異なります。
Q: CI でリグレッションテストを自動化するメリットは?
A: 開発者が毎回手動で実行する工数を削減でき、変更による不具合を早期に検出してリリース遅延を防げます。
A: 開発者が毎回手動で実行する工数を削減でき、変更による不具合を早期に検出してリリース遅延を防げます。
Q: リグレッションテストはいつ実行するのが効果的ですか?
A: コードがリポジトリにチェックインされた直後、定期ビルドの流れで自動実行することで不具合混入を最小化できます。
A: コードがリポジトリにチェックインされた直後、定期ビルドの流れで自動実行することで不具合混入を最小化できます。
関連キーワード: リグレッションテスト、自動ビルド、単体テスト、フォーク・ジョイン
設問2:本文中の下線①について、(1)、(2)に答えよ。
(2)既存機能に対するテストについて、設定したテストケース数の妥当性を評価するために考慮すべき値を解答群の中から選び、記号で答えよ。
解答群
ア:各アプリケーションのステップ数
イ:設計書の変更ページ数
ウ:対応する改善要望数
エ:追加機能のステップ数
模範解答
ア
解説
解答の論理構成
- 【問題文】では、開発部が抱える課題として「①既存機能に対する影響調査とテストを網羅的に行うことは、限られた工数では難しい」と述べています。
- 網羅性を客観的に判断するには、既存機能が“どれだけあるか”を示す量的指標が必要です。
- 解答群を照合すると、既存機能の規模を直接示すのは「ア:各アプリケーションのステップ数」です。ステップ数はソースコード量=テスト対象範囲を示す代表的メトリクスであり、テストケース数の妥当性を評価する際によく用いられます。
- 他の選択肢は以下の理由で不適切です。
・イ:設計書のページ数は記述量であり、必ずしもコード規模と一致しません。
・ウ:改善要望数は追加・変更部分の規模を示しても、既存機能全体の規模を示しません。
・エ:追加機能のステップ数は新規開発分であり、「既存機能に対する」テストケース数の妥当性評価には直結しません。 - 以上より、「ア」が正解となります。
誤りやすいポイント
- 「改善要望が多いほど既存機能のテストが増える」と誤解し、ウを選んでしまう。
- ドキュメント量=プログラム量と短絡し、イを選んでしまう。
- CI 導入文脈から“追加機能”に注目し過ぎてエを選んでしまう。
FAQ
Q: ステップ数以外にテストケース数の妥当性を測る代表的な指標はありますか?
A: 関数・クラス数、複雑度 (サイクロマティック複雑度) などが用いられます。いずれも“コード構造”を表し、テスト対象範囲を把握するのに有効です。
A: 関数・クラス数、複雑度 (サイクロマティック複雑度) などが用いられます。いずれも“コード構造”を表し、テスト対象範囲を把握するのに有効です。
Q: ステップ数計測は自動化すべきですか?
A: はい。CI ツールに組み込めばチェックイン毎に最新のステップ数を取得でき、テスト工数やカバレッジの目標値をリアルタイムで管理できます。
A: はい。CI ツールに組み込めばチェックイン毎に最新のステップ数を取得でき、テスト工数やカバレッジの目標値をリアルタイムで管理できます。
関連キーワード: ステップ数、テストケース設計、カバレッジ、メトリクス
設問3:
図2中のdに入れる適切な字句を答えよ。
模範解答
d:false
解説
解答の論理構成
- 仕様確認
問題文には「hourが0以上24未満の値かつminが0以上60未満の値であったらtrueを返し、それ以外の値であったらfalseを返す」とあります。ここで 24 は “24未満” の条件に合致しないため不正な入力になります。 - テストコードの意図
図2のテストプログラムは境界値テストであり、各呼出しが仕様通りかどうかを確認しています。該当行は
「checkTime(24,0) が d と等しい」。
hour に 24 を渡すと仕様上 false を返すはずなので、期待値として比較するのは false です。 - 結論
したがって d に入る字句は false となります。
誤りやすいポイント
- 「24 は 1 日の時刻として見慣れているから true」と思い込み、仕様の“24未満”を見落とす。
- min が 0 なので「時だけ不正でも true」と誤解するが、論理は hour と min の両方を同時に判定している。
- テストプログラムが論理積(かつ)の連鎖であることに気付かず、一つでも期待値を誤ると全体が false になる実装意図を読み違える。
FAQ
Q: なぜ hour の条件は“24以下”ではなく“24未満”なのですか?
A: 仕様として 0:00 から 23:59 までを有効と定めているためです。24:00 は次の日の 0:00 と解釈されるケースが多く、扱いを明確に分ける目的で除外しています。
A: 仕様として 0:00 から 23:59 までを有効と定めているためです。24:00 は次の日の 0:00 と解釈されるケースが多く、扱いを明確に分ける目的で除外しています。
Q: min が 60 の場合も同様に false になるのですか?
A: はい。「minが0以上60未満」という条件に違反するため false です。図2でも checkTime(0,60) が false であることを確認しています。
A: はい。「minが0以上60未満」という条件に違反するため false です。図2でも checkTime(0,60) が false であることを確認しています。
Q: 24:00 を正当な入力として扱いたい場合はどう修正すればよいですか?
A: 条件を「hourが0以上24以下、minが0以上60未満」で、さらに hour が24のときは min を0のみに限定する追加判定を入れる必要があります。
A: 条件を「hourが0以上24以下、minが0以上60未満」で、さらに hour が24のときは min を0のみに限定する追加判定を入れる必要があります。
関連キーワード: 境界値分析、単体テスト、継続的インテグレーション、リグレッションテスト
設問4:〔CIの試行〕について、(1)〜(3)に答えよ。
(1)本文中の指摘1について、指摘者に対するアドバイスとして、誤っているものを解答群の中から選び、記号で答えよ。
解答群
ア:改善要望に対応したソースコードから随時チェックインする。
イ:一つの要求を細かな要求に細分化して開発する。
ウ:プログラムを小さな機能単位に分割して開発する。
エ:変更中のソースコードでもよいので随時チェックインする
模範解答
エ
解説
解答の論理構成
- 【問題文】には「CIとは、開発者がソースコードの変更を頻繁にリポジトリに登録(以下、チェックインという)して、ビルドとテストを定期的に実行する手法」とあります。したがって頻繁なチェックインは必須です。
- しかし同じく CI のプラクティスでは「ビルドが通らない、テストが通らないコードはチェックインしない」ことが大前提です。途中までしか実装されていないコードを共有すると、以降のビルドやテストが連鎖的に失敗し CI のメリットが失われるからです。
- 解答群を照合すると、
- ア「改善要望に対応したソースコードから随時チェックインする」
- イ「一つの要求を細かな要求に細分化して開発する」
- ウ「プログラムを小さな機能単位に分割して開発する」
いずれも“スコープを小さくして頻繁に✔︎済コードを登録する”という CI の考え方に合致します。
- それに対しエ「変更中のソースコードでもよいので随時チェックインする」は、中途半端な状態でのコミットを容認しています。これは 2. の理由で CI の原則に反し、誤ったアドバイスです。
- よって誤っているものは「エ」となります。
誤りやすいポイント
- 「頻繁にチェックインする = 途中経過のままでも良い」と誤解しやすい。CI では“ビルドとテストが通る単位で小まめに”が正解です。
- ブランチ戦略(例:フィーチャーブランチ)を取れば未完成コードを隔離できますが、本問は“リポジトリのメインラインに直接チェックイン”を想定している点を見落とすと迷います。
- 「1 週間に 1 回」の現状を変えるにはスコープ分割が必要だと気付きにくく、ア〜ウの選択肢がすべて正しく見えてしまう。
FAQ
Q: 変更途中のコードをどうしても共有したい場合はどうすればよいですか?
A: フィーチャーブランチを切ってメインラインから隔離し、完成後にマージすれば CI の健全性を保てます。
A: フィーチャーブランチを切ってメインラインから隔離し、完成後にマージすれば CI の健全性を保てます。
Q: “ビルドが通る”かどうかはどこで確認すべきでしょうか?
A: 各開発者がローカル環境でビルド・単体テストを実行してからチェックインするのが基本です。CI サーバは保険であり、一次責任は開発者にあります。
A: 各開発者がローカル環境でビルド・単体テストを実行してからチェックインするのが基本です。CI サーバは保険であり、一次責任は開発者にあります。
Q: チェックイン頻度はどの程度が理想ですか?
A: 一般には「数時間〜1 日に数回」が推奨されます。要は“作業が一区切り付いてテストが通る最小単位”で登録することです。
A: 一般には「数時間〜1 日に数回」が推奨されます。要は“作業が一区切り付いてテストが通る最小単位”で登録することです。
関連キーワード: 継続的インテグレーション、チェックイン、ビルド、単体テスト、フィーチャーブランチ
設問4:〔CIの試行〕について、(1)〜(3)に答えよ。
(2)本文中の下線②について、CIツールから送信されるメールを限定する方法を、正常時のメールの送信を停止する以外に35字以内で述べよ。
模範解答
各アプリケーションの担当チームにだけメールするようにする。
解説
解答の論理構成
- 【問題文】で D 君は「各アクティビティの実行結果は正常・異常にかかわらず X、Y、Z の担当チームメンバ全員に電子メール」と設定しました。
- その結果、「CI ツールから送信されるメールが非常に多く、Y を担当するチームはエラーに気付かず、1 日放置されていた」と指摘されました。
- 課題は “量” ではなく “対象外の情報” が混在している点です。
- 送信先をアプリケーション別に分け、関係のないチームへは送らないようにすれば、
・メール総量が減る
・担当者は自分のアプリケーションの失敗だけを即時把握できる
という効果が得られます。 - 以上より、解答は「各アプリケーションの担当チームにだけメールするようにする」となります。
誤りやすいポイント
- 通知を完全に止めるとエラー報告まで失われるので本末転倒です。
- 配信頻度を下げる(例:日次・週次)とエラー検知が遅延し CI の目的である「早期フィードバック」に反します。
- 件名や本文を工夫するだけでは、受信者が多いままなので根本解決になりません。
FAQ
Q: チーム別配信に加えて推奨される設定はありますか?
A: 失敗時のみ通知、チャット連携、ダッシュボード常設などリアルタイムで“見える化”する方法が効果的です。
A: 失敗時のみ通知、チャット連携、ダッシュボード常設などリアルタイムで“見える化”する方法が効果的です。
Q: メールを担当チームに限定すると、全体の品質把握が難しくなりませんか?
A: 集計レポートを日次や週次で管理者に一括配信すれば、個々の通知と管理レポートを分離できます。
A: 集計レポートを日次や週次で管理者に一括配信すれば、個々の通知と管理レポートを分離できます。
関連キーワード: 通知制御、CI, ビルド失敗アラート、情報過多、メールフィルタ
設問4:〔CIの試行〕について、(1)〜(3)に答えよ。
(3)本文中の下線③について、CIツールのワークフローをどのように修正するとよいか。40字以内で述べよ。
模範解答
各アプリケーションのビルド終了後、待ち合わせせず単体テストに移る。
解説
解答の論理構成
- 現状のワークフローでは、【図01】のステージ2に「Xのビルド」「Yのビルド」「Zのビルド」があり、その後に「ジョイン(二重線結合)」が置かれています。
- 注記2に「ジョインとは、並行に実行している全てのアクティビティの終了を待ち合わせてから次の処理に移ることを指す。」とあります。
- 本文では「X のビルドでエラーが検出され、単体テストまでワークフローが流れないことが多い。」と指摘されています。ジョインがあるため、1つでもビルドが失敗すると3つ全てのビルドが終わった扱いにならず、次のステージ3(単体テスト)へ進めません。
- その結果「Z を担当するチームでは、開発者の開発 PC 上で CI ツールと同じテストケースを実行しており、③CI の導入効果が出ていない。」という無駄が発生しています。
- 従って、ビルドごとに完了したものから直ちに単体テストへ進めるようにし、ジョインによる待ち合わせをなくす必要があります。
- 以上より、「各アプリケーションのビルド終了後、待ち合わせせず単体テストに移る。」という修正案が導かれます。
誤りやすいポイント
- ジョインを削除するのではなくフォークを削除すると勘違いする
- ビルド失敗時にCIを止めること自体が悪いと誤認し、通知方法だけを変えようとする
- リグレッションテストまでの全工程を並列化しようとして複雑化させる
FAQ
Q: ジョインを外すとテストサーバへの配備やリグレッションテストはどうなりますか?
A: 単体テスト後に再度ジョインを設ければ、配備やリグレッションテストは全アプリケーションの単体テストが通った時点で開始できます。
A: 単体テスト後に再度ジョインを設ければ、配備やリグレッションテストは全アプリケーションの単体テストが通った時点で開始できます。
Q: ビルドが失敗したアプリケーションの単体テストを実行しないのは問題ありませんか?
A: ビルドが失敗して実行可能ファイルが生成されない場合、そのアプリケーションの単体テストは実行不能です。ビルド成功分のみ先行して単体テストを行うことで、他チームの待ち時間を短縮できます。
A: ビルドが失敗して実行可能ファイルが生成されない場合、そのアプリケーションの単体テストは実行不能です。ビルド成功分のみ先行して単体テストを行うことで、他チームの待ち時間を短縮できます。
Q: リポジトリの整合性が心配です。ビルド成功・失敗が混在してもよいのでしょうか?
A: CIでは各ビルド結果を独立したジョブとして扱うため、成功したビルドだけを対象に次工程へ進めてもリポジトリの整合性は保たれます。失敗ジョブはエラー内容を速やかに修正し、再度ビルド・テストを行います。
A: CIでは各ビルド結果を独立したジョブとして扱うため、成功したビルドだけを対象に次工程へ進めてもリポジトリの整合性は保たれます。失敗ジョブはエラー内容を速やかに修正し、再度ビルド・テストを行います。
関連キーワード: フォーク、ジョイン、リグレッションテスト、単体テスト、ビルドパイプライン


