2018年 秋期 応用情報技術者試験 問8

継続的インテグレーションに関する次の記述を読んで

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 ツールで自動実行できるように，テストプログラムを作成した。

なお，新機能のリリース後には，新機能の単体テストで用いたテストプログラムは，リグレッションテストのテストプログラムとして再利用することにした。

//テスト対象のプログラム
function checkTime(hour, min)
  if(hour が 0 より小さい 又は 24 以上)
    return false
  else if(min が 0 より小さい 又は 60 以上)
    return false
  end if
  return true
end function

//テストプログラム
function test_checkTime ()
  if(checkTime(-1,0)が false と等しい かつ
    checkTime(24,0)が d と等しい かつ
    checkTime(0,-1)が false と等しい かつ
    checkTime(0,60)が false と等しい かつ
    checkTime(0,0)が true と等しい かつ
    checkTime(23,59)が true と等しい)
    return true
  end if
  return false
end function

[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 を適用した。その結果，段階的な機能追加を実現させ，新機能のリリースサイクルを短縮した。