%	2004年度	修士論文
%
\documentstyle[naist-jmthesis,graphicx,plext,12pt]{jarticle}   % 日本語

%
% 1ページ内に入れられる図の数を増やす
%
\setcounter{topnumber}{5}       % ページ上部に入る図の数 ≦ 5
\def\topfraction{.999}            % ページ上部の図が占める面積比 ≦ 0.7
\setcounter{bottomnumber}{5}    % ページ下部に入る図の数 ≦ 5
\def\bottomfraction{.999}         % ページ下部の図が占める面積比 ≦ 0.3
\setcounter{totalnumber}{10}    % 各ページに入る図の総数 ≦ 10
\def\textfraction{0}           % 各ページのテキスト部分の面積比 ≧ 0.2
\def\floatpagefraction{0.9}      % 図だけのページで図が占める面積比 ≧ 0.5

% \setlength{\floatsep}{3pt plus 2pt minus 2pt}% float 間の距離

\newcommand{\apsection}[1]{
\begin{flushleft}
{\Large\gt\bf #1}\\ 
\end{flushleft}
}

\newcommand{\apsubsection}[1]{
\begin{flushleft}
{\large\gt\bf #1}\\ 
\end{flushleft}
}

\def\yesno{\vspace{-0.5cm} \begin{flushright} yes  /  no  / わからない\end{flushright}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		ページスタイルの指定
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\pagestyle{final}       % 清書

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		使用言語の指定
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\lang{Japanese} % 日本語

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		学生番号
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\studentnumber{0351053}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		修士論文 か 課題研究 かの選択
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\doctitle{\mastersthesis}       % 修士論文

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		取得予定の修士号は 修士(工学) か 修士(理学) か ？
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\major{\engineering}    % 工学

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		日本語題目 (in LaTeX)
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\title{プログラム理解度がコードレビュー達成度に及ぼす影響の分析}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		英語題目 (in LaTeX)
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\etitle{Analysis of program comprehension that has effects on the code review
achievement}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		日本語氏名 (in LaTeX)
%		（姓と名の間に空白を入れて下さい）
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\author{栗山 進}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		欧文氏名 (in LaTeX)
%	   （first name, last name の順に記入し、先頭文字のみを大文字にする。）
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\eauthor{Susumu Kuriyama}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		論文提出年月日
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\syear{2005}
\smonth{2}
\sday{3}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		専攻の選択
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\department{\infsys}    % 情報システム学

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		審査委員（日本語）
%   		（姓と名、名と称号の間に空白を入れて下さい）
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cmembers{松本 健一 教授}{（主指導教員）}
         {西谷 紘一 教授}{（指導教員）}
         {飯田 元 助教授}{（指導教員）}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% 		審査委員（英語）
%     		（first name, last name の順に記入し、先頭文字のみを大文字にする。
%      		 first name と last name の間に空白、
%      		 last name と 称号の間にカンマと空白を入れて下さい。）
%
% \ecmembers{Professor Ken-ichi Matsumoto}{(Supervisor)}
%           {Professor Masaki Koyama}{(Co-supervisor)}
%           {Associate Professor Hajimu Iida}{(Co-supervisor)}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		キーワード５〜６個 (in LaTeX)
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\keywords{コードレビュー，試験，定量化，ソフトウェアプロセス，ソフトウェア品質}%* 研究会のまま


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		5 or 6 Keywords (in LaTeX)
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\ekeywords{code review, examination, quantification, software process, software quality}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		内容梗概 (in LaTeX)
%
%		注: 行の先頭が\\で始まらないようにすること。
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\abstract{
本研究の目的は，コードレビューにおけるレビューアのプログラム理解度と，コー
ドレビュー達成度(バグ発見率)との関係を分析することである．レビューアのプ
ログラム理解度を調べるために，コードレビュー実施後，レビュー対象コードについて
複数の側面から問う実験を行った．実験の結果，ロジックやインタフェースに関
する理解度との相関は見つからなかった．しかし，データ構造やデータ操作に関
する理解度は，それらと関連するバグの発見率との相関が高いことがわかった．
また，プログラム理解度は，バグを見つけるための必要条件となっていることが
わかった．}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%		Abstract (in LaTeX)
%
%   		注: 行の先頭が\\で始まらないようにすること。
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\eabstract{
The goal of this study is to analyze the relationship between the level
of program comprehension and the bug detection rate in a code review
process. We examined the reviewer's comprehension level of a program
after the review process was held by the reviewer. As a results of
examinations, we have found that the bug detection rate correlated with
the comprehension level of data structure and its manipulation while it
did not correlated with the comprehension level of logic and
interface. We also found the program comprehension was a necessary
condition for detecting bugs.
}

%%%%%%%%%%%%%%%%%%%%%%%%% document starts here %%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}

%------------------------------------------------------------------------
%
%		表紙 および アブストラクト
%
%------------------------------------------------------------------------
\titlepage
\cmemberspage
\firstabstract
\secondabstract

%------------------------------------------------------------------------
%
%		目次
%
%------------------------------------------------------------------------
\toc
\newpage
\listoffigures
%\newpage
\listoftables
\newpage

%
% ページ番号を振りはじめる
%
\pagenumbering{arabic}

%------------------------------------------------------------------------
%
%
%		修士論文	本文
%
%
%------------------------------------------------------------------------

\section{はじめに}

ソフトウェアの社会的重要性が高まる中で，ソフトウェアを開発する企業や組織
にとって，ソフトウェアの品質向上は，近年，特に重要な課題の一つである．ソ
フトウェアの品質向上のための取り組みの一環として，多くのソフトウェア開発
の現場では，ソフトウェアライフサイクルの各工程で作成される作業成果物に対
してピアレビュー(peer review)が実施されている．

ピアレビューとは，ソフトウェア作成者以外の1人以上の人物が，要求定義，設
計，テスト計画，テスト項目，ソースコードなどの作業成果物を調べ，欠陥を発
見したり改善を行う活動を指す\cite{Wiegers2004}．ピアレビューには，捕らえ
にくいバグを突き止めるために同僚の開発者に即席でソースコードをチェックし
てもらうといったアドホックレビューや，教育的・訓練的側面の強い構造化ウォー
クスルー\cite{Yourdon1991}，最も厳格なレビュープロセスが定義されているイ
ンスペクション\cite{Glib1999}など，柔軟性と効果によって様々な種類がある．

ピアレビューは，作成者以外の人間によって複数の視点から各種作業成果物を調
べるため，作成者本人の視点では気づくことが難しい欠陥を発見する機会を提供
する．しかし，レビューを行う人物の能力や経験，あるいはレビュー対象物への
理解力の違いによって，発見可能な欠陥の数や種類に大きな違いが生じる場合も
少なくない．このため，作業成果物に含まれる欠陥の数や種類が未知の時点で実
施されるピアレビューは，どれ程の労力をかければどの位の欠陥を見つけること
ができるかを，容易に予測することは難しいという問題がある．

ピアレビュー(または単にレビュー)という用語は，種々の作業成果物中に含まれ
る欠陥を発見するための活動を指すものである．一般的にはソースコードを入念
に調べバグを発見するためのコードレビューを指す場合が多い
\cite{Wiegers2004}．本論文でも特に断りがない場合は，コードレビューを指す
こととする．
% バグへと変更

的場\cite{Matoba1995}は，レビューの質の低下を早期に発見しプロジェクト管
理者を支援することを目的として，レビューの質を定量化するための試験方法の
提案を行い，試験結果(プログラム理解度)とレビュー達成度とに相関があること
を確認した．本論文では，バグの種類をより細かく分類した上で，的場が提案し
た試験方法を拡張し，分類(データ，インタフェース，ロジック，仕様)毎にプロ
グラム理解度を調べた実験結果について報告する．
% !読解力

本論文の構成は以下の通りである．2章では，コードレビューにおけるプロ
グラム理解度の影響と問題点について述べる．3章では，ソースコードに対する
理解度を定量的に測りレビュー達成度とそれらの関係を調べるための実験を詳述
し，\ref{sec:result_analysis}章でその実験結果を示す．
\ref{sec:discussion}章では，今回の実験結果を考察し，最後にまとめを述べて
本論文を結ぶ．
% !読解力

\section{コードレビューにおけるプログラム理解度の影響と問題点}\label{sec:review_prob}
%%%%%前フリ%%%%%

ソフトウェアの品質向上を目的としてこれまで提案されてきた様々なツールや技
法の中でも，Faganが開発したインスペクション\cite{Fagan1986}は，作業成果
物中に含まれる欠陥を発見する方法として最も有効性が高い手法であるとされて
いる．インスペクションによって摘出可能な欠陥の割合は，60\%〜90\% にも達
すると報告されている\cite{Boehm2001,Glass1999}．

このように，最も高い欠陥発見率を期待されるインスペクションではあるが，欠
陥の発見率には大きな差異が見られる．この原因として，インスペクションプロ
セスにおけるレビューの実施方法やミーティングでの対人関係・社会的関係など
があるとされており\cite{Glass2004}，現在も議論が続いている．

%%%%%問題設定%%%%%

本研究は，レビュー対象となるプログラムへの理解度が，レビューの質にどのよ
うに影響するのかを明らかにすることを目的とする．プログラム作成能力(生産
性)については，従来から数倍以上の個人差があると指摘されている
\cite{Sackman1968}．同様に，ピアレビューで対象とする各種作業成果物に対す
る理解力にも個人差があるのは明らかである\cite{Ko2003,Rifkin2000}．

%インスペクションだけではなく，各種レビュー全般に個人の理解力がレビュー達成度に影響すると考えることができる．

最終成果物であるソフトウェアの品質を管理する責任のある品質管理者など
の立場では，レビューの質をある水準以上(重大な欠陥がないことなど)に保つこ
とが必須の課題であり，どれくらいのレビュー能力のある人間をレビュー担当者
として確保するべきかについては大きな関心事である．成果物の品質確保のみな
らず，できるだけ早い段階で欠陥を除去することは，プロジェクトの遅延を防止
(手戻り作業などで必要となる工数は，欠陥の発見が後れれば遅れるほど膨大に
なる)する意味でも大きな問題である\cite{Boehm1976}．

レビューの質をある程度確保するために，インスペクションや構造化ウォークス
ルーでは，複数人でレビューを実施する前に，各個人で仕様書，設計書，ソース
コードなどの完全性をチェックする「準備」の段階がある\cite{Wiegers2004}．

「準備」の段階では，様々なソフトウェア作業成果物に見られる欠陥の典型例を
洗い出した欠陥チェックリストやルールセットを使用する．欠陥チェックリスト
を用いることによって，プログラムに障害を引き起こす可能性のある誤りの原因
候補に注意を集中しやすくなる．ルールセットは，タスクを実施したり成果物文
書を作成したりする際に特定の方法で行うように作成者に文書で指示するもので
あり，文章の内容，構造，表記法，構成などを指定するルールからなる．

チェックリストやルールセットは，最低限の水準以上のレビューの質を確保する
ために提供されるものであって，個々人の経験や能力による個人差を完全に解消
するものではない．欠陥あたり工数(欠陥を1つ見つけるために必要な平均工数)と
準備速度(一人のレビューアが準備の段階で1時間あたりに調べることができる平均コード行数)
との関係や，インスペクションの速度と発見される欠陥数との関係など，レビュー
の投資効果や最適なレビュー速度を計測し，インスペクションプロセスを定量的
に管理するためのメトリクスも提案されている\cite{Barnard1994,Ebenau1994}．
しかし，個人のプログラム理解度の違いがレビューの質にどのように影響するのか
に着目したものは，文献\cite{Matoba1995}以外には見当たらない．

そこで次節では，プログラム理解度とレビューの質との関係を定量的に測定する
試験方法をについて述べる．\cite{Matoba1995}の試験方法をバグの分類を細分
化し拡張することによって，プログラム理解度とレビューの質との関係をより詳
しく調べるためのものである．

\section{コードレビュー達成度とプログラム理解度の測定実験}

私は，コードレビューにおけるレビューアのプログラム理解度とコードレビュー
達成度（バグ発見率）との関係を明らかにするために，実際にコードレビューを
行い，バグを発見する実験を行った．

\subsection{被験者}

奈良先端科学技術大学院大学情報科学研究科の11名（博士前期課程の学生9名，
博士後期課程の学生1名，助手1名）に対してコードレビューを行ってもらった．
そして実際のコードレビューは被験者１名ずつ行った．また，被験者のプログラ
ミング歴とレビュー経験の有無を表\ref{table:subjects}に示す．平均プログラ
ミング歴は6.6年であった．

\begin{table}[tb]
 \begin{center}
 \caption{被験者のプログラミング歴とレビュー経験の有無}
  \begin{tabular}{l|c|c|c|c|c|c|c|c|c|c|c}
   \hline
被験者               &     A  &   B  &   C  &   D  &   E  &   F  &   G  &   H  &   I  &  J  &  K \\ \hline
レビュー経験の有無   &     有  &  有  &  有  &  無  &  無  &  無  &  無  &  有  &  無  &  有  &  無 \\
プログラミング歴（年） &     9  &  16  &   8  &   3  &   4  &  10  &   4  &   6  &   6  &   5  &   2 \\ \hline
  \end{tabular}
 \end{center}
 \label{table:subjects}
\end{table}

% 被験者                       1      2      3      4      5      6      7      8      9     10     11
% レビュー歴                  ◎     ◎     ○     ×     ×     ×     ×     ○     ×     ◎     ×
% プログラミング歴             9     16      8      3      4     10      4      6      6      5      2
% C言語歴                      9     13      4      3      3     10      3      1      3      5      2
% 全体のバグ発見率          69\%   76\%   55\%   17\%   24\%   38\%   52\%   17\%   41\%   14\%    7\%
% 全体の正答率（資料なし）  55\%   71\%   47\%   48\%   62\%   70\%   44\%   52\%   73\%   58\%   30\%
% 全体の正答率（資料あり）  87\%   75\%   75\%   73\%   83\%   83\%   78\%   71\%   82\%   73\%   45\%
% レビュー時間              2:30   3:30   3:10   4:00   3:00   3:00   2:20   2:50   3:30   4:56   3:20

\subsection{レビュー資料}

各被験者にはレビュー資料としてレビュー対象プログラムのハードコピー，仕様
書，プログラム概要説明資料を1部ずつ用意した．各被験者には同じ資料を用意
した．

\begin{itemize}
 \item {\bf レビュー対象プログラム}: \\
本実験では，大阪大学情報工学科の演習
で学生によって作成された酒屋倉庫管理問題のプログラム\cite{Matoba1995} を
使用した．実プログラムはC言語で記述されており，604行の大きさであった．コ
ンパイラが発見できる構文上の誤りは，あらかじめ除去した．このプログラムは
17個のバグを含んでいたが，今回の実験では，さらに著者が12個のバグを追加し，
合計29個のバグを用意した．バグを追加する際，多数の文を大幅に変更すること
はせず，文の入れ換えや削除，式の変更にとどめた．また可能な限り，不自然な
バグを追加しないように努めた．\\
 \item {\bf 仕様書}: \\上述のプログラムが満たすべき仕様が書かれた文書である．\\
 \item {\bf プログラム概要説明資料}: \\プログラム中に定義されている各関数の概要が説明されている．\\
\end{itemize}

\subsection{バグの分類}
\label{subsec:BugClassification}

プログラムは複数の構成要素(関数，データ構造など)からなり，また，複数の評
価の側面(アルゴリズムの正当性，仕様との適合性など)を持つものである．そこ
で，プログラムの理解度を調べるにあたり，理解の側面をデータ，インタフェー
ス，ロジック，仕様の4つに分類した．そして，理解の側面の分類に従い，バグ
も分類した．バグの一般的な分類方法というのはなく，文献\cite{Boris1994}を
参考にしながら主観的に決定した．以下に，分類名と，その分類に対応するプロ
グラムの構成要素や側面を挙げる．括弧内は，各分類毎のバグの個数である．

\begin{itemize}
 \item {\bf データ(7)}: グローバル変数，構造体，配列，プログラム実行時に動的に確保されるデータ領域とそれらに対する操作．\\
 \item {\bf インタフェース(8)}: 
関数のインタフェース(戻り値，引数，関数の呼び出し順の制限など)．\\
 \item {\bf ロジック(6)}: 
ロジックの誤り(アルゴリズム，フラグの意味・条件，境界値条件に関する判定，ループ制御など)．\\
 \item {\bf 仕様(8)}:
仕様に記述されている機能が実装されていないものと，仕様に記述されていない機能が実装されているもの．
\end{itemize}

%\begin{table}[tb]
% \begin{center}
% \caption{それぞれの\category に属するバグの個数}
%%  \begin{tabular}{l|r}
%  \Hline
%   分類名         & 個数 \\ \hline % ieicej.cls specific
%   \dataBug          &    7 \\
%   \interfaceBug     &    8 \\
%   \logicBug         &    6 \\
%   \specBug          &    8 \\ \Hline
%  \end{tabular}
% \end{center}
% \label{table:numsOfBug}
% \end{table}

\subsection{実験手順}\label{subsec:procedure}

\begin{flushleft}
手順1.　コードレビュー 
\end{flushleft}

ソースコードのハードコピー，仕様書，プログラム概要説明文書を利用してコー
ドレビューを行う．

\begin{flushleft}
手順2.　試験1回目 
\end{flushleft}

手順1.のコードレビュー実施時に使用した資料(ソースコード，仕様書，概要説
明文書)を参照できない状態で被験者が試験問題を解く．

\begin{flushleft}
手順3.　試験2回目 
\end{flushleft}

手順1.のコードレビュー実施時に使用した資料(ソースコード，仕様書，概要説
明文書)を参照しながら被験者が試験問題を解く．試験問題は手順2.試験1回目と
同じ問題である．

各レビューには，実験者が同席し，C言語の仕様と標準ライブラリ関数に関して，
被験者が不明だと思った事項に対して質問を受け付けた．ただし，プログラムの
動作に関する質問は受け付けなかった．

レビュー後に行った2回の試験の目的は，どちらの試験においても，被験者がソー
スコードや仕様書を理解した度合いを調べるためである．ビュー終了直後に試験
を行ったのは，試験成績が，コードレビュー終了から試験を受けるまでの時間に
左右されることを防ぐためである．

1回目の試験においては，レビュー実施時に使用した資料(ソースコード，仕様書，
概要説明文書)を参照できない状態で試験問題を解いてもらった．2回目の試験に
おいては，再び同じ試験問題を解いてもらうが，被験者は資料を参照することを
許可した．このような手順で試験を行った理由を以下に述べる．

1回目の試験で資料への参照を許可しない理由は，資料を参照することでレビュー
時よりも試験中にプログラムを理解するための情報量が増えてしまう可能性を防
ぐためである．ただし，1回目の試験では，レビュー中に与えた資料の内容を覚
えているかどうかという記憶力に依存した解答結果となる可能性が高い．

そこで，2回目の試験においては，試験実施時の資料を閲覧することを許可した．
ただし，2回目の試験では，レビュー時に理解していなかった事柄に関する質問
事項に対して，被験者はその場で確認後，理解してから解答する可能性がある．

\subsection{試験問題}

\begin{table}[tb]
 \begin{center}
 \caption{それぞれの分類に対応する問題文と解答欄の一例}
  \begin{tabular*}{150mm}{@{\extracolsep{\fill}}l|p{300pt}}
   \hline
   分類名            &  問題文と解答欄\\ \hline \hline
   データ            &    コンテナ構造体の領域は，必要時に動的に割り当てているか？ \\ 
                     & yes  /  no  / わからない \\ \hline
   インタフェース    &    出庫処理をする関数 SendLiquor は，引数の一つとして搬入日時を受け取るか？\\
                     & yes  /  no  / わからない \\ \hline
   ロジック          &    指定した量の酒があるかどうか調べる isExistLiquor 関数は，
                          コンテナ内の酒の構造体を調べるが，その際 \verb|MAX_LIQUOR|
                          回だけ配列を調べているか？ \\
                     & yes  /  no  / わからない \\ \hline
   スペック          &    積荷票の搬入年月としてどれが正しいか選択せよ． \\
                     & (a) 199401 / (b) 9401 / (c) わからない \\ \hline
  \end{tabular*}
 \end{center}
 \label{table:exampleOfQuestion}
\end{table}

試験問題は全部で77個の小問題から構成した．試験問題は1問毎に
\ref{subsec:BugClassification}節で述べたバグの分類の中の1つに深く関係したもの
となっている．データ，インタフェース，ロジックの分類に対応する問題がそれ
ぞれ19個，仕様の分類に対応する問題が20個である．表1に問題文と解答欄の一
例を示す．

試験問題は全てこのような選択解答形式となっている．1つの問題は，問題文と，
解となりうる選択肢(主にyesとno)と，`わからない'という選択肢からなってい
る．被験者には，正しいと思う選択肢がある場合にはそれに印をつけてもらい，
わからない場合は`わからない'に印をつけてもらった．

自由記述で解答する形式の試験問題にした場合，理解しているが明示的に答えら
れない事柄は記述できないため，理解度をより定量的に計測するためにすべての
設問を選択式で解答できるようにした．選択解答方式では，理解できなかった事
柄も解答可能であるが，`わからない'という項目が選択できることと，
\ref{subsec:procedure} 節で述べたように同じ試験を2回実施し両方を分析する
ことで選択解答形式の試験問題の欠点を補うことが可能であると考えた．

\subsection{採点方法}\label{subsubsec:score}

試験の成績として式(1)のようにバグの分類毎の正答率を計算し，プログラム理解度を測る尺度とした．選択肢`わからない'の場合は，不正解とした．

\begin{eqnarray*}
ある分類に対する成績 = \frac{分類毎の正答した数}{分類毎の小問題の総数}
\end{eqnarray*}


% 問題の作り方について余裕があったら述べる
% \subsection{コード把握度問題}

% ソースコードに対する理解した度合を試す問題であり，`yes / no / わからない'で答
% えられる多数の小問題からなる．各種類の問題はソースコードを基にそれぞれ次
% のように作成する．

% \subsubsection{データ}

% \begin{itemize}
%  \item ソースコードから無作為にいくつかの文，および，連続した複数文を選び
%        出す．そして，それらについて，その文の動作を説明する記述を作る．
%        説明を作る時，各記述には，5割の率で意図的に1個の誤りを混ぜる．
%        この説明が実際のコードと一致するかどうかを問う．
%        % 確率について考慮してなかったな．．しかし，どう影響する？
%  \item いくつかの関数を無作為に選び出す．そして，その関数の中の関数
%        呼び出しの回数や順番，または，条件分岐の回数や順番を説明する
%        記述を作る．各記述には，やはり5割の率で誤りを混ぜる．この説明
%        が実際のコードと一致するかどうかを問う．
% \end{itemize}

% 小問題の作成の例を示す．ここではC言語で書かれたソースコード中に次のよう
% なif文が入っていた場合を想定する．

% \begin{verbatim}
% if((fp=fopen(fname, "+r")!=NULL))
%   mainprog(fp,i);
% \end{verbatim}

% このプログラムは，テキストファイルを読み出して何らかの処理を行うプログラ
% ムである．上のif文は，ファイルを読み出すためにファイルを開く関数fopenを
% 呼び出した後，エラーが発生しなければ関数mainprogを呼び出すことを表してい
% る．このif文に対して，例えば，次のような説明を作成する．

% \begin{quote}
%   関数mainの中にはファイルを開くための関数fopenを呼び出している文がある．
%   この時，関数fopenには，ファイルの名前とリードオンリーを指定する引数
%   (``r'')とを渡している．
% \end{quote}

% 上のif文を見るとわかるように，実際にはリードライトを指定する引数(``r'')
% を渡している．従って，この小問題に対する正解は``no''である．コードレビュー
% の際にこの引数を確認したレビューアにとっては，容易に答えられる問題である．

% \subsubsection{インタフェース}

% \subsubsection{ロジック}

% \subsubsection{仕様把握度問題}

% プログラム仕様に対する理解の度合を試す問題であり，2--4択の

% 多数の小問題からなる．各小問題は，仕様書を基に次のように作成する．まず，仕様
% 書の中から，無作為に1個の文，または，図表中の1個の項目を選び出す．仕様書
% の中からそのような文や項目は，プログラムの入出力に何らかの関係があるはず
% である．そこで，その文や項目に関係する入力とその入力に対応する出力との一
% 例を挙げ，それらの入出力を説明する記述を作る．説明を作る時，問1と同様に，
% 各記述には，5割の率で意図的に1個の誤りを混ぜる．この説明が実際の仕様と一
% 致するかどうかを問う．

% 小問題の作成の例を示す．ここでは，ある言語の構文解析を行うプログラムの仕
% 様書の中に，次のような構文定義が書かれていた場合を想定する．

% \begin{verbatim}
%     変数宣言 = int 変数名[``,'' 変数名]``;''
%       変数名 = 英字{英字|数字}
% \end{verbatim}

% この部分は，正しく解析できる変数宣言の構文を表している．正しく解析できな
% かった場合は，適当なエラーメッセージを出力して，停止することになっていた
% とする．この構文定義に対して，例えば，次のような説明を作成する．

% \begin{quote}
%   入力に``int a,b,c;''と言う変数宣言が含まれる場合，
%   \underline{エラーメッセージを出力する．}
% \end{quote}

% 上の構文定義を見るとわかるように，3個の変数を1度に宣言する構文は許されて
% いない．従ってこの小問題に対する正解は``yes''である．コードレビューの際
% にこの定義を確認したレビューアにとっては，容易に答えられる問題である．

\clearpage

\nopagebreak[4]

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{all.eps}
 \end{center}
  \caption{バグ発見率(全体)と試験の正答率との関係}
 \label{graph:all} 
\end{figure*}

\nopagebreak[4]

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{data.eps}
 \end{center}
  \caption{バグ発見率(データ)と試験の正答率との関係}
 \label{graph:data} 
\end{figure*}


\nopagebreak[4]

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{if.eps}
 \end{center}
  \caption{バグ発見率(インタフェース)と試験の正答率との関係}
 \label{graph:interface} 
\end{figure*}


\nopagebreak[4]

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{logic.eps}
 \end{center}
  \caption{バグ発見率(ロジック)と試験の正答率との関係}
 \label{graph:logic}
\end{figure*}


\nopagebreak[4]

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{spec.eps}
 \end{center}
  \caption{バグ発見率(仕様)と試験の正答率との関係}
 \label{graph:spec}
\end{figure*}

\nopagebreak[4]

\clearpage

% \includegraphics[width=8.5cm]{hoge.eps}

\section{実験結果と分析}\label{sec:result_analysis}

\subsection{実験結果}

実験結果を表\ref{table:results_all}から表\ref{table:results_spec}に示す．
表\ref{table:results_all}には全体の実験結果が，表
\ref{table:results_data} から表\ref{table:results_spec}には分類毎に集計
した結果が示されている．

\begin{table}[tb]
 \begin{center}
 \caption{実験結果（全体）}
\begin{tabular}{c|c|r|r} \hline
被験者&レビュー時間&正答率（１回目）&正答率（２回目）\\ \hline
A     & 2:30    &   55\%  &  87\% \\
B     & 3:30    &   71\%  &  75\% \\
C     & 3:10    &   47\%  &  75\% \\
D     & 4:00    &   48\%  &  73\% \\
E     & 3:00    &   62\%  &  83\% \\
F     & 3:00    &   70\%  &  83\% \\
G     & 2:20    &   44\%  &  78\% \\
H     & 2:50    &   52\%  &  71\% \\
I     & 3:30    &   73\%  &  82\% \\
J     & 4:56    &   58\%  &  73\% \\
K     & 3:20    &   30\%  &  45\% \\ \hline
 \end{tabular}
 \end{center}
 \label{table:results_all}
\end{table}

\begin{table}[tb]
 \begin{center}
 \caption{実験結果（データ）}
\begin{tabular}{c|c|r|r} \hline
被験者&レビュー時間&正答率（１回目）&正答率（２回目）\\ \hline
A     & 2:30    &   68\%  &  100\% \\
B     & 3:30    &   89\%  &  84\% \\
C     & 3:10    &   37\%  &  68\% \\
D     & 4:00    &   47\%  &  68\% \\
E     & 3:00    &   74\%  &  89\% \\
F     & 3:00    &   74\%  &  89\% \\
G     & 2:20    &   47\%  &  89\% \\
H     & 2:50    &   58\%  &  79\% \\
I     & 3:30    &   84\%  &  100\% \\
J     & 4:56    &   58\%  &  63\% \\
K     & 3:20    &   42\%  &  32\% \\ \hline
 \end{tabular}
 \end{center}
 \label{table:results_data}
\end{table}

\begin{table}[tb]
 \begin{center}
 \caption{実験結果（インタフェース）}
\begin{tabular}{c|c|r|r} \hline
被験者&レビュー時間&正答率（１回目）&正答率（２回目）\\ \hline
A     & 2:30    &   47\%  &  87\% \\
B     & 3:30    &   68\%  &  75\% \\
C     & 3:10    &   47\%  &  75\% \\
D     & 4:00    &   47\%  &  73\% \\
E     & 3:00    &   68\%  &  83\% \\
F     & 3:00    &   79\%  &  83\% \\
G     & 2:20    &   42\%  &  78\% \\
H     & 2:50    &   53\%  &  71\% \\
I     & 3:30    &   74\%  &  82\% \\
J     & 4:56    &   37\%  &  73\% \\
K     & 3:20    &   42\%  &  45\% \\ \hline
 \end{tabular}
 \end{center}
 \label{table:results_interface}
\end{table}

\begin{table}[tb]
 \begin{center}
 \caption{実験結果（ロジック）}
\begin{tabular}{c|c|r|r} \hline
被験者&レビュー時間&正答率（１回目）&正答率（２回目）\\ \hline
A     & 2:30    &   37\%  &  68\% \\
B     & 3:30    &   63\%  &  68\% \\
C     & 3:10    &   58\%  &  68\% \\
D     & 4:00    &   37\%  &  53\% \\
E     & 3:00    &   47\%  &  74\% \\
F     & 3:00    &   53\%  &  74\% \\
G     & 2:20    &   21\%  &  58\% \\
H     & 2:50    &   42\%  &  58\% \\
I     & 3:30    &   58\%  &  63\% \\
J     & 4:56    &   68\%  &  74\% \\
K     & 3:20    &   0\%   &  26\% \\ \hline
 \end{tabular}
 \end{center}
 \label{table:results_logic}
\end{table}

\begin{table}[tb]
 \begin{center}
 \caption{実験結果（仕様）}
\begin{tabular}{c|c|r|r} \hline
被験者&レビュー時間&正答率（１回目）&正答率（２回目）\\ \hline
A     & 2:30    &   65\%  &  95\% \\
B     & 3:30    &   65\%  &  80\% \\
C     & 3:10    &   45\%  &  80\% \\
D     & 4:00    &   60\%  &  85\% \\
E     & 3:00    &   60\%  &  80\% \\
F     & 3:00    &   75\%  &  80\% \\
G     & 2:20    &   65\%  &  80\% \\
H     & 2:50    &   55\%  &  85\% \\
I     & 3:30    &   75\%  &  80\% \\
J     & 4:56    &   70\%  &  70\% \\
K     & 3:20    &   35\%  &  70\% \\ \hline
 \end{tabular}
 \end{center}
 \label{table:results_spec}
\end{table}

\clearpage

%% 縦書きの表
% \begin{table}[tb]
%  \begin{center}
%  \caption{実験結果}
%   \begin{tabular}{c|c|l|l|l|l|l|l|l|l|l|l|l|l}
%    \hline
%     &   &  \multicolumn{4}{l|}{バグ発見率}	& \multicolumn{4}{l}{正答率（1回目）} & \multicolumn{4}{|l}{正答率（2回目）}  \\ \cline{3-14}
%   \parbox{1zw}{被験者\hspace*{1zw}} & \parbox{1.2zw}{レビ\hspace*{0.5mm}ュ\\ー時間\hspace*{1zw}} &\parbox{1zw}{デ\\ータ}&\parbox{1zw}{インタフ\hspace*{0.5mm}ェ\\ ース}&\parbox{1zw}{ロジック}&\parbox{1zw}{スペック} &\parbox{1zw}{デ\\ータ}&\parbox{1zw}{インタフ\hspace*{0.5mm}ェ\\ ース}&\parbox{1zw}{ロジック}&\parbox{1zw}{スペック}&\parbox{1zw}{デ\\ータ}&\parbox{1zw}{インタフ\hspace*{0.5mm}ェ\\ース}&\parbox{1zw}{ロジック}&\parbox{1zw}{スペック} \\ \hline
%   \end{tabular}
%  \end{center}
%  \label{table:results}
% \end{table}

\subsection{分析}

\subsubsection{バグ発見率と正答率の関係分析}\label{subsubsec:detect_correct}

図\ref{graph:all}に，全体のバグ発見率と，試験全体の正答率との関係を示す．
図\ref{graph:data}--\ref{graph:spec}は，分類別のバグの発見率と，対応する
試験の正答率との関係である．表2には，1回目と2回目の試験の正答率とバグ発
見率の相関係数をそれぞれ示す．

ここで，分類別のバグ発見率とは，コードレビューに使用したプログラムに潜ん
でいた各分類別のバグの総数に対して，各被験者がレビューで発見したバグの割
合を意味する．試験問題の正答率は，\ref{subsubsec:score}節において述べた
計算式で算出した．

%%BoundingBox: 65 325 780 770
%% 試験の正答率 などのフォントサイズは24pt

% 全体(プログラム) & 0.338533336 &  0.524608488  \\ 

縦軸はバグの発見率を，横軸は試験の正答率を示している．グラフ上の各点は，
1人の被験者の試験の正答率とバグ発見率に対応している．本実験のように，同
じプログラムを同じ条件の下でレビューしても，バグ発見率が被験者によってか
なり異なることがわかる．また，各問題の正答率は，バグ発見率と関連があるこ
とがわかる．

図\ref{graph:data}において，試験の正答率が高い程，高いバグ発見率を示すと
いう傾向が，1回目と2回目の試験の両方で見て取れる．「データ」に分類された
バグに関しては，プログラムを良く理解している程，バグを多く発見するという
ことである．この他の種類のバグにおいては同様の関係は見られない．
% 抽象的に書きすぎ?

図\ref{graph:interface}においては，1回目の試験において，低い正答率を示し
ながらも，高いバグの発見率を示す被験者が2名存在していることが見て取れる．
同様に，図\ref{graph:logic}，図\ref{graph:spec}においても，このような傾
向を示す被験者が存在していることがわかる．

また，図\ref{graph:interface}において，2回目の試験の正答率に着目すると，
大部分のレビューアの正答率が，0.8--0.9の間という比較的狭い範囲に分布して
いることがわかる．これと同様の関係が，図\ref{graph:logic}や図
\ref{graph:spec}においても見て取れる．

また，図\ref{graph:data}--\ref{graph:spec}を見ると，インタフェースやロジッ
クにおける一部の例外を除いて，低い正答率を示した被験者のバグ発見率は低く
なっていることがわかる．また，高い正答率を示した被験者であっても，バグの
発見率が高いとは限らないことも見て取れる．

\begin{table}[tb]
 \begin{center}
 \caption{バグ発見率と試験の正答率の相関係数}
  \begin{tabular}{l|l|r}
   \hline
                  & 1回目の試験 &  2回目の試験  \\ \hline 
 全体             & 0.382 &  0.553  \\  
 データ           & 0.634 &  0.733  \\ 
 インタフェース   & 0.223 &  0.053  \\ 
 ロジック         & 0.067 &  0.350  \\
 仕様             & 0.067 &  0.594  \\ \hline
  \end{tabular}
 \end{center}
 \label{table:correlation}
\end{table}

%                   & 1回目の試験 &  2回目の試験  \\ \hline 
%  全体             & 0.382000843 &  0.553229807  \\  
%  データ           & 0.633588261 &  0.733207061  \\ 
%  インタフェース   & 0.222891853 &  0.052907429  \\ 
%  ロジック         & 0.067301439 &  0.350269722  \\
%  仕様             & 0.067168934 &  0.594145526  \\ \hline

\subsubsection{分類毎のバグ発見率間の相関}\label{subsubsec:correlation_matrix}

次に，分類間の関係を，バグ発見率間の相関係数から分析する．表
\ref{table:correlation_matrix}に分類毎のバグ発見率間の相関係数行列を示す．
表\ref{table:correlation_matrix}を見ると，分類ロジックと分類インタフェー
スとの間の相関係数が 0.831，分類データと分類インタフェースとの間の相関係
数が0.793 となっており，強い相関が認められる．

また，表\ref{table:correlation_matrix}を見ると，仕様のバグ発見率は他のど
の発見率ともあまり相関が見られない．

\begin{table}[tb]
 \begin{center}
 \caption{バグ発見率の相関係数行列}
  \begin{tabular}{l|r|r|r|r}
   \hline
分類           &	   データ &	インタフェース &	 ロジック &	       仕様  \\ \hline
データ         &			1 &	         0.793 &        0.647 &	      0.558  \\
インタフェース &        0.793 &				 1 &        0.831 &       0.641  \\
ロジック       &        0.647 &	         0.831 &			1 &	      0.528  \\
仕様           &        0.558 &	         0.641 &        0.528 &			  1  \\ \hline
  \end{tabular}
 \end{center}
 \label{table:correlation_matrix}
\end{table}

% 発見率の相関係数行列                
%                       データ  インタフェース      ロジック     スペック
% データ                     1     0.793146678   0.646794332  0.557655383
% インタフェース   0.793146678               1   0.830619262  0.640518218
% ロジック         0.646794332     0.830619262             1   0.52796579
% スペック         0.557655383     0.640518218    0.52796579            1

\subsubsection{バグ発見率・正答率とプログラミング歴の関係分析}\label{subsubsec:detect_prog_analysis}

図\ref{graph:detect_prog}に全体のバグ発見率とプログラミング歴との関係を
示す．図を見てわかるように，強い相関が認められる．相関係数は0.774 であっ
た．また，表\ref{table:detect_review}を見るとわかるように，過去にレビュー
を経験していた被験者は平均バグ発見率も高く，プログラミング歴も長くなって
いる．

% 被験者の平均プログラミング歴	6.636363636

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{detect_prog.eps}
 \end{center}
  \caption{バグ発見率(全体)とプログラミング歴との関係}
 \label{graph:detect_prog}
\end{figure*}

\begin{table}[tb]
 \begin{center}
 \caption{平均バグ発見率と平均プログラミング歴の関係}
  \begin{tabular}{l|r|r}
   \hline
                 & 平均バグ発見率     &	   平均プログラミング歴 \\ \hline
レビュー経験あり & 			 46\%     &                    8.80 \\ 
レビュー経験なし & 			 30\%     &                    4.83 \\ \hline
  \end{tabular}
 \end{center}
 \label{table:detect_review}
\end{table}


% 相関係数
% プログラミング歴と発見率       	 0.773545263
% C言語歴と発見率                	 0.691889315

次に，試験の正答率とプログラミング歴との相関を図\ref{graph:correct_prog}
に示す．1回目と2回目の試験の両方とも，強い相関は見られない．相関係数は1
回目の試験が0.623，2回目の試験が0.401となっている．

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{correct_prog.eps}
 \end{center}
  \caption{正答率(全体)とプログラミング歴との関係}
 \label{graph:correct_prog}
\end{figure*}

% 相関係数
% 正答率（資料なし）             	 0.623377084
% 正答率（資料あり）             	 0.401212867


\subsubsection{バグ発見率・正答率とレビュー経験の有無との関係分析}\label{subsubsec:detect_correct_review}

バグ発見率とレビュー経験との関係は既に表\ref{table:detect_review}で示し
た．レビューを経験者は平均バグ発見率も高く，プログラミング歴も長くなって
いる．

表\ref{table:correct_review}に試験の正答率とレビュー経験との関係を示す．
表の通り，レビュー経験者と未経験者において正答率に大きな差は認められない．

\begin{table}[tb]
 \begin{center}
 \caption{平均正答率とレビュー経験の有無の関係}
  \begin{tabular}{l|r|r|r}
  \hline
                 & 正答率（1回目）       &  正答率（2回目）       &     平均プログラミング歴 \\ \hline
レビュー経験あり &                  57\% &                 76\%   &                 8.80 \\       
レビュー経験なし &                  55\% &                 74\%   &                 4.83 \\ \hline
  \end{tabular}
 \end{center}
 \label{table:correct_review}
\end{table}

%                 平均バグ発見率  平均正答率（資料なし）  平均正答率（資料あり）  平均プログラミング歴
% レビューの経験者          46\%                   57\%                  76\%                    8.80 
% レビュー経験なし          30\%                   55\%                  74\%                    4.83


\subsubsection{バグ発見率・正答率とレビュー時間の関係分析}\label{subsubsec:detect_correct_reviewtime}

図\ref{graph:detect_time}にバグ発見率とレビュー時間との関係を示す．図を
見ると強い相関は認められない．相関係数は-0.434であった．図と相関係数を見
ると分かるように，レビュー時間が長い程，バグの発見率が低くなる傾向がある．

図\ref{graph:review_prog}にレビュー時間とプログラミング歴との関係を示す．
相関係数は-0.107であり，相関は見られない．

% 相関係数
% プログラミング歴とレビュー時間	-0.106756291

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{detect_time.eps}
 \end{center}
  \caption{バグ発見率(全体)とレビュー時間との関係}
 \label{graph:detect_time}
\end{figure*}

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{review_prog.eps}
 \end{center}
  \caption{レビュー時間とプログラミング歴との関係}
 \label{graph:review_prog}
\end{figure*}

次に，図\ref{graph:correct_time}に試験の正答率とレビュー時間との関係を示
す．図を見ると全くと言って良い程，相関は認められない．相関係数は1回目が
0.141，2回目が-0.256 であった．

\begin{figure*}[tb]
 \begin{center}
  \includegraphics[width=1.0\linewidth]{correct_time.eps}
 \end{center}
  \caption{試験の正答率(全体)とレビュー時間との関係}
 \label{graph:correct_time}
\end{figure*}

% 相関係数
% レビュー時間と発見率           	-0.433748252
% 時間と正答率（資料なし）       	 0.140914695
% 時間と正答率（資料あり）       	-0.256288744

\section{考察}\label{sec:discussion}

\subsection{先行研究との比較}

文献\cite{Matoba1995}においては，2つの異なるプログラムに対して同様の分析
がなされている\footnote{\cite{Matoba1995}は，1回の試験による正答率とバグ
発見率との関係を測定している点，2種類のみのバグ分類で分析を行っている点，
全体のバグ個数が17個である点で本研究とは異なる．}．その結果によると，相
関係数はそれぞれ，0.720，0.746 となっており，強い相関が認められる．しか
しながら，表2で示したように，今回の実験においては強い相関は認められなかっ
た．

\subsection{バグ発見率と正答率の全体の傾向}% 全体の傾向について述べる

試験の正答率とバグ発見率との間において見られる，全体的な傾向について考察
する．\ref{subsubsec:detect_correct}節では，インタフェースやロジックにお
ける一部の例外を除いて，低い正答率を示した被験者のバグ発見率は低くなって
いること及び，高い正答率を示した被験者であっても，バグの発見率が高いとは
限らないことを指摘した．この事から，試験の正答率，即ち，プログラム理解度
は，バグを見つけるための必要条件になっていることが考えられる．

% ちょっと違うかなあ．プログラム理解度は，バグの発見率の上限を定める．か？

なお，1回目の実験の，被験者の答案を見てみると，`わからない'という解答が
多く見られた．試験後に被験者に，どうしてわからなかったのかと尋ねると，覚
えていないからという返答が多かった．これは即ち，試験問題に，記憶を試す問
題が少なからず含まれていたものと考えられる．それゆえ，プログラムを良く理
解していてバグを良く発見しているにも関わらず，低い正答率となってしまった
ものと思われる．

\subsection{バグの分類毎の傾向}
\subsubsection{データ}

\ref{sec:result_analysis}章で述べたように，データ構造やデータ操作につい
て良く理解している程，その種のバグの発見率が高いことが実験結果からわかっ
た．この種のバグについては，まずデータ構造やその操作をより理解した上でレ
ビューにのぞむことが重要であるといえる．また，今回行ったような試験をレ
ビュー終了後に実施することによって，レビュー達成度を定量的に管理すること
ができるものと期待される．

\subsubsection{インタフェース}\label{subsec:if_discuss}

インタフェースに属するバグとして，今回のプログラムにおいては，関数の返り
値に対する処理のバグと，関数へ適切な実引数を渡していないバグしか存在しな
かった．これらのバグは，関数の返り値をきちんと確認すること，関数の仮引数
の意味と実引数の意味を確認することによって，比較的容易に見つけることがで
きると考えられる．この種のバグを探す際にはチェックリストを用いるのが有効
であると思われる．試験の正答率とバグ発見率に相関がみられなかったのは，プ
ログラムは理解していたが，レビュー時のチェックを怠っていたためと推測され
る．

% 上記の理由と試験問題の中に記憶力に依存した問題が少なからず含まれていたからであると推測している．

\subsubsection{ロジック}\label{subsec:logic_discuss}

ロジックにおいては，ループを回る回数が1回異なるという簡単なバグが3つ含ま
れていたが，これらのバグが発見される率(そのバグを発見した人数/レビュー者
の総人数)はそれぞれ，18\%，18\%，36\% であった．これらのバグのうちの1つ
を以下に示す．

\begin{quote}  
for文によるループで，\verb|i <  MAX_REQBUF|と書かれているべき所が，
\verb|for (i = 0; i <= MAX_REQBUF; i++)| のように，
\verb|i <= MAX_REQBUF|と書かれており，ループを一回多く回してしまっている．
\end{quote}

このようなバグの見逃しを防ぐためには，チェックリストを用いるのが有効であ
ると思われる．試験の正答率とバグ発見率に相関がみられなかったのは，インタ
フェースのところで述べた理由とほぼ同じであると考えられる．

% 11:被験者の人数, 3つのバグに対し，
% バグを発見した人数はそれぞれ，4, 2, 2 人
% (/ 4.0 11)
% 0.36363636363636365
% (/ 2.0 11)
% 0.18181818181818182

\subsubsection{仕様}\label{subsec:spec_discuss}

仕様においては，試験の正答率に大きな違いは認められなかったものの，仕様の
未実装を指摘した被験者らと，指摘しなかった被験者らの2群に分かれることが
わかった．後者の群に属する被験者らは，仕様書とソースコードとの間の対応に
注意を払わなかったものと考えられる．仕様書とソースコードとの間の対応は，
チェックリストを用いることにより支援が行えるため，この種のバグを探す際に
はチェックリストを用いるのが有効であると考える．試験の正答率とバグ発見率
に相関がみられなかったのは，インタフェースのところで述べた理由とほぼ同じ
であると考えられる．

\subsection{分類毎のバグ発見率間の相関}

\ref{subsubsec:correlation_matrix}節では，分類ロジック分類インタフェース
との間に強い相関があることを明らかにした．これは以下の理由によると考えら
れる．\ref{subsec:if_discuss}節と\ref{subsec:logic_discuss}節で述べたよ
うに，この種のバグはレビュー時にチェックを行ったかどうかが発見に大きく影
響する．そのため，注意深くチェックをしながらレビューを行った場合，ロジッ
クやインタフェースのバグは良く発見されるものと考えられる．それゆえ強い相
関が出たものと考えられる．しかしながら，\ref{subsec:spec_discuss}節で述
べたように，仕様のバグも同様に，チェックするかしないかという行為がバグ発
見に大きく影響するにも関わらず，インタフェースやロジックとの相関は高くな
い．これについては，以下のように考えられる．インタフェースやロジックに属
するバグはソースコードのみに注目していても発見することができるが，仕様に
属するバグというのは仕様とソースコードの双方に注目していなければ発見でき
ないためであろう．つまり，ソースコードを注意深くチェックしながらレビュー
を行う被験者でも，仕様についても同時にチェックを行うかは定かではないとい
うことである．

次にデータとインタフェースとの間の強い相関について考察する．データの操作
は関数を通じて行われるため，データ操作に関して理解も深く慎重にレビューを
行っていた被験者はインタフェースについても注意深く見ていたものと考えられる．
そのため両者の間に強い相関があったのであろう．

% \ref{subsec:spec_discuss}節で述べたが，仕様の未実装を指摘した群と指摘し
% なかった群の2群に分かれていた．このことは，レビュー中に仕様とソースコー
% ドの双方に気を配ったかどうかで2群に分かれたものと考えられる．

% インタフェースやロジックに属するバグはソースコードのみに注目していても発
% 見することができるが，仕様に属するバグというのは仕様とソースコードの双方
% に注目していなければならない．それゆえ，レビュー中に仕様とソースコードの
% 双方に気を配ったかどうかが影響したものと考えられる．
% \ref{subsec:spec_discuss}節で述べたが，仕様の未実装を指摘した群と指摘し
% なかった群の2群に分かれたことは先の説明を傍証するものと考えられる．

\ref{subsubsec:correlation_matrix}節では仕様のバグ発見率は他のどの発見率
ともあまり相関が見られないことを明らかにした．このことは，仕様に属するバ
グは，仕様とソースコードの双方に注目していなければ発見できないという事が
影響しているものと考えられる．

% もう少し論理的に述べたいなあ

\subsection{バグ発見率・正答率とプログラミング歴}\label{subsubsec:detect_prog}

次に，プログラミング歴とバグ発見率及び，試験の正答率との間の関係について
考察する．\ref{sec:review_prob}章で述べたように，レビューの質は個々人の
経験や能力に影響される．個々人のレビュー能力と関係が深い要因として，プロ
グラミング経験とレビュー経験が考えられる．そこで，ここではプログラミング
歴がプログラミング経験を良く反映しているものと仮定し，プログラミング歴と
バグ発見率などとの関係を考察する．なお，レビュー経験との関係については次
節で述べる．

\ref{subsubsec:detect_prog_analysis}節では，全体のバグ発見率とプログラミ
ング歴との間に強い相関があることを明らかにした．よって，プログラミング経
験はレビューの質に大きな影響を与えるものと考えられる．しかし，同時に指摘
したように，過去にレビューを経験していた被験者は平均バグ発見率も高く，プ
ログラミング歴も長くなっている．それゆえ，プログラミング経験のみがバグ発
見率に影響しているとは言い切れない．過去にレビューを経験していた人を除い
て，プログラミング歴とバグ発見率の関係を調べることもできるが，そうすると
被験者数が6名となってしまい有効な分析ができない．

% 言い切ってしまって良いのか

次に，試験の正答率とプログラミング歴の関係について考察する．
\ref{subsubsec:detect_prog_analysis}節で見たようにバグ発見率とプログラミ
ング歴との間に強い正の相関があることから，試験の正答率とプログラミング歴
との間に強い正の相関があれば良い試験であると考えられる．しかしながら，今
回の実験においては強い相関は認められず，問題改良の余地が大いにあると考え
られる．

また，1回目の試験における相関係数の方が2回目における試験よりも大きい値で
あった．よって，今回の実験においては1回目の試験の方が被験者のレビュー能
力やプログラミング経験を反映するものとなっていたと考えられる．1回目と2回
目では試験の問題自体は変わらないので，1回目の方式（参照資料を見ることを
許さない）の方がレビューの質を調べるには適しているものと考えられる．


\subsection{バグ発見率・正答率とレビュー経験の有無}\label{subsec:review_experience}

レビュー経験の有無とバグ発見率及び，試験の正答率との間の関係について考察
する．レビュー経験が豊富なほどバグ発見率は高くなるものと考えられる．また，
試験の正答率はレビュー経験が豊富なほど高くなっていると好ましいと考えられ
る．

% それに対し，試験の正答率にはレビュー経験はあまり影響しないものと考えられる．
% なぜ？問題の作り方がそうなっているから？問題の作り方について十分に述べたのか？

\ref{subsubsec:detect_correct_review}節で示したように，レビュー経験者は
レビュー未経験者と比べて平均バグ発見率が高くなっている．しかしながら，
\ref{subsubsec:detect_prog_analysis}節で見たようにバグ発見率とプログラミ
ング歴との間に強い正の相関があった．今回の実験で被験者となったレビュー経
験者はレビュー未経験者と比べてプログラミング歴も長かった．よって，レビュー
経験の有無がバグ発見率に影響しているとは言い難い．

また，レビュー経験者と未経験者において正答率に大きな差は認められなかった．
よって，今回作成した試験問題の正答率はレビュー経験に左右されないというこ
とである．これより，この試験問題ではレビュー経験によるレビュー能力の差を
調べることはできないと考えられる．もし，正答率に違いが出る試験が作れたな
らば，その差を調べることにより，レビュー能力の差となる要因を知ることがで
きるかもしれない．

\subsection{バグ発見率・正答率とレビュー時間との関係}

\ref{subsubsec:detect_correct_reviewtime}節で見たように，バグ発見率とレ
ビュー時間との間に，強い相関は認められなかった．また，レビュー時間が長い
程，バグの発見率が低くなる傾向が見られた．ならば，レビュー時間を短く制限
すればバグが取れるかというとそうではない．レビューに時間をかけないと仕様
書やソースコードを読むことさえできないからである．また，レビューに長く時
間をかけても見つけられないバグは見つけられないままであることが推測される．

レビュー時間に影響を与える要因として，レビューアのコードや文章を読む速度
やレビューの戦略，及びどれくらい丁寧に読むかということが挙げられる．コー
ドを読む速度はプログラミング歴と関係があると思われる．しかしながら，レ
ビュー時間とプログラミング歴との間に相関は認められなかった．よって，レ
ビュー時間にはコードを読む速度以外の要因が強く関係するものと思われる．

また，試験の正答率とレビュー時間との間に相関は認められなかった．試験の目
的はプログラムの理解度を調べることであった．試験の正答率がプログラム理解
度を表しているとするならば，レビュー時間を長く取っても，プログラム理解度
はあまり変化しないと考えられる．よって，プログラム理解を支援する何らかの
機構なり工夫が必要であると考えられる．

% 嘘臭い．全体の傾向から見えることを言っているだけ．
% ある個人の理解度が時間と共にどう変化するかを見ないとわからないはずだ．

\section{まとめと今後の課題}

本論文では，プログラム理解度とコードレビュー達成度との関係を分析することを
目的とした実験について述べた．

実験結果を分析した結果，データ構造やデータ操作について良く理解している程，
その種のバグの発見率が高いことが実験結果からわかった．この種のバグについ
ては，レビュー達成度を試験で調べることができると考えられる．その他のバグ
種別においては同様の関係は見られなかった．しかしながら，全体的な傾向から，
試験の正答率，即ちプログラム理解度は，バグを見つけるための必要条件となっ
ていることがわかった．

\ref{subsec:if_discuss}--\ref{subsec:spec_discuss}項で述べたように，プロ
グラム理解度以外にもレビューの質に影響を与える要因が存在すると考えられる．
プログラムの細部をきちんと確認するといった行為，対応が取られているべき箇
所をきちんと確認するといった行為がそれである．このことは同時に，チェック
リストやルールセットを用いてレビューを行うことの有効性を示すものであると
考えられる．

今回の実験においては，コード中に含まれていたバグの多くが，チェックリスト
やルールセットを用いてレビューすれば発見できた可能性がある．今後の課題と
して，被験者全員に同一のチェックリストやルールセットを用いてレビューを行っ
てもらい，その上で，プログラム理解度とレビューの質の関係を調べる必要があ
る．

データ構造やデータ操作について良く理解している程，その種のバグの発見率が
高いことがわかったが，その原因理由についてはまだ不明な部分が多い．これに
ついては，以下のような課題をクリアしながら明らかにしていく予定である．

\begin{itemize}
 \item 別のプログラムでも同様の結果が得られるのか調べる
 \item 記憶に依存しにくい問題の作成方法を見つける
 \item レビューの質に影響を与える他の要因の考察
\end{itemize}

% \mbox{\bf 謝辞} \quad
% 本稿で行った実験に快く参加して下さった被験者の皆様に深く感謝します．本研
% 究の一部は，文部科学省「e-Society基盤ソフトウェアの総合開発」の委託に基
% づいて行われた．

% さて，これをどう言おう．仕様関連の一部のバグは取れてる人と取れてない人に
% 分かれているが，これは戦略の違いからなのか，経験による違いなのか．経験に
% よって戦略が異なるとも言えるかなあ．仕様のバグは大変だから，重点的にチェッ
% クすべきということを経験的に知っている人と知っていない人とか．他に経験と
% してはバグの典型例にどれだけ熟知しているか．

% この実験結果の意義を述べる？低い理解度で高い能力を持つならばレビューのや
% り直しを指示することができる？しかし，理解度や読解力が何\%より上ならば良
% いのかわからない．<-ROIの計算ができないからというのではなくて，正答率と
% 発見率が比例すると仮定しても，その傾きがわからない(プログラムによって異
% なるであろうから，多数の人にレビューさせなければならない)ので，少人数で
% レビューを行う際はそもそも傾きが求められない．また，人数がある程度確保で
% きたとしても，一部の人にレビューのやり直しの指示を出すこととなり，インス
% ペクションにおいてはミーティングの延期となってしまう．

% 発見率と正答率の相関係数
%            1回目の試験    2回目の試験
% 全体      0.382000843 0.553229807
% program   0.338533336 0.524608488
% data      0.633588261 0.733207061
% interface 0.222891853 0.052907429
% logic     0.067301439 0.350269722
% spec      0.067168934 0.594145526

% 2:20 - 4:56 レビューに要した時間

% 追加したバグ数
% 合計      12
%  data      3
%  interface 5
%  logic     3
%  spec      1


% 総バグ数  29
% 合計
%  data      7 (4+3)
%  interface 8 (3+5)
%  logic     6 (3+3)
%  spec      8 (7+1)

% 質問数
% program(sum) 57
%  data        19
%  interface   19
%  logic       19
% spec         20

% \include{Chap1}
% \include{Chap2}
% \include{Chap3}
% \include{Chap4}
% \include{Chap5}
% \include{Chap6}

\clearpage

%------------------------------------------------------------------------
%
%		謝辞
%
%------------------------------------------------------------------------
\acknowledgements

Thank you. Thank you.

%------------------------------------------------------------------------
%
%		参考文献
%
%		pLaTeX2eのthebibliographyを利用した
%
%------------------------------------------------------------------------
\newpage

\begin{thebibliography}{10}

\bibitem{Wiegers2004}
K.E.~Wiegers：``ピアレビュー'', 大久保 雅一(監訳), 日経BPソフトプレス (2004).

\bibitem{Yourdon1991}
E.~Yourdon：``ソフトウェアの構造化ウォークスルー'', 伊土 誠一, 富野 壽(監訳), 近代科学社 (1991).

\bibitem{Glib1999}
T.~Glib, D.~Graham：``ソフトウェアインスペクション'', 国友 義久, 千田 正彦(訳), 共立出版 (1999).

\bibitem{Matoba1995}
的場 政明：``コードレビューの質を定量化するための試験方法の提案と評価'', 修士論文,
  奈良先端科学技術大学院大学 情報科学研究科, NAIST-IS-MT35112 (1995).

\bibitem{Fagan1986}
M.~E. Fagan: ``Advances in software inspections'', IEEE Trans. 
  Software Engineering, {\bf 12}, 7, pp. 416--423 (1986).

\bibitem{Boehm2001}
B.~Boehm and V.~R. Basili: ``Software defect reduction top 10 list'', IEEE
  Computer, {\bf 34}, 1, pp. 135--137 (2001).

\bibitem{Glass1999}
R.~L. Glass: ``Practical programmer: inspections?some surprising findings'',
  Commun. ACM, {\bf 42}, 4, pp. 17--19 (1999).

\bibitem{Glass2004}
R.~L. Glass：``ソフトウエア開発 55の真実と10のウソ'', 山浦 恒央(訳), 日経BP社 (2004).

\bibitem{Sackman1968}
H.~Sackman, W.~J. Erikson and E.~E. Grant: ``Exploratory experimental studies
  comparing online and offline programming performance'', Commun. 
  ACM, {\bf 11}, 1, pp. 3--11 (1968).

\bibitem{Ko2003}
A.~J. Ko and B.~Uttl: ``Individual differences in program comprehension
  strategies in unfamiliar programming systems'', 11th IEEE International
  Workshop on Program Comprehension (IWPC'03), IEEE, pp. 175--184 (2003).

\bibitem{Rifkin2000}
S.~Rifkin and L.~Deimel: ``Program comprehension techniques improve software
  inspections: A case study'', 8th International Workshop on Program
  Comprehension (IWPC'00), IEEE, pp. 131--138 (2000).

\bibitem{Boehm1976}
B.~W. Boehm: ``Software engineering'', IEEE Trans. Computers, {\bf
  25}, 12, pp. 1226--1241 (1976).

\bibitem{Barnard1994}
J.~Barnard and A.~Price: ``Managing code inspection information'', IEEE
  Software, {\bf 11}, 2, pp. 59--69 (1994).

\bibitem{Ebenau1994}
R.~G. Ebenau: ``Predictive quality control with software inspections'', Cross
  Talk, Vol.~7, no.~6, pp. 9--16 (1994).

\bibitem{Boris1994}
B.~Beizer：``ソフトウェアテスト技法'',小野間 彰, 山浦 恒央(訳), 日経BP出版センター (1994).

\end{thebibliography}

%------------------------------------------------------------------------
%
%			付録
%
%------------------------------------------------------------------------
\appendix

\section{作業の手引き}

\newpage

\begin{center}
{\LARGE\gt 作業の手引き}\\
\end{center}

\vspace{2eX}

\apsection{1. 概要}

まず，レビュー作業を行ってもらいます．次に仕様書やソースコードに関する質
問に答えてもらいます．そして最後に簡単なインタビューを予定しています．所
要時間は，レビュー作業が2-4時間，質問回答が40分，インタビューが10分程度
と見積もっています．

\apsection{2. レビュー作業}

\apsubsection{2.1 概要}

文書だけを見ながら一人でコードレビュー行ってください．目的は，ソースコー
ド中に含まれるバグを発見することです．文書は以下の3つです．

\begin{enumerate}
 \item ソースコード
 \item 仕様書
 \item プログラムの概要を説明する文書(プログラム説明書)
\end{enumerate}

時間制限はありません．1時間おき程度に，10分程の休憩をとるのは自由ですが，
その間，プログラムについて他の人と話したりはしないで下さい．

また，作業が終っても，このレビュー対象のコードや仕様書について他の人と話
さないで下さい．

\apsubsection{2.2 手順}

決まった手順はありません．文書を読みながらバグを探してください．その際，
仕様書には誤りがないものとして作業を行ってください．指摘するバグは仕様書
との不一致(仕様を満たさない，仕様よりも余分な機能が存在する)や，ロジック
の誤りなど，気づいた項目全てを報告して下さい．報告の仕方は，ソースコード
の該当部分に下線を引き，どのようなバグかを記述して下さい．どこの部分のバ
グなのかを記述し辛い，または記述できない場合は，別紙に文章で記述して下さ
い．

また，プログラム中にでてくる dprintf 関数の使い方や，dprintf の実装につ
いてはレビュー対象外として下さい．

% また，プログラム中，エラー処理の部分はレビュー対象外として下さい．
%% 質問でエラー処理に関する部分を聞いている

また，C言語の仕様やライブラリ関数の動作，要求仕様書の文面の意味については
質問を受け付けます．プログラムの動作に関する質問は受け付けません．

なお，バグを修正する作業は必要ありません．また，作業終了後，これらの文書
は回収します．

\apsubsection{2.3 プログラムの概要を説明する文書(プログラム説明書)に関して}

プログラム説明書は，仕様書をプログラマが読んで作成した，概要設計書のよう
な位置付けの文書です．この文書に沿ってプログラム及び，それを構成する関数
は書かれていますが，文書中で意図している機能が正確に実装されているかは保
障されません．また，プログラム説明書とソースコードの間にはずれが存在する
かもしれませんし，プログラム説明書と仕様書の間にもずれが存在するかもしれ
ません．プログラム説明書の誤りは指摘する必要はありません．ソースコードの
バグのみを報告して下さい．この文書はあくまでレビューの補助文書です．

\apsection{3. 質問}

質問用紙を渡しますので，それに沿って回答漏れのないようお答え下さい．質問
の意味が良くわからない(あいまいであるとか，日本語として変であるといった)
場合は遠慮なく尋ねて下さい．

\apsection{4. インタビュー}

質問用紙回収後に行います．

\newpage

\section{バグ報告書}

\newpage

\begin{center}
{\LARGE\gt バグ報告書}\\
\end{center}

\begin{flushleft}
 {\bf 1. 注意} 
\end{flushleft}
プログラム内で指摘できる場合はできるだけそちらの該当行に下線を引いて指摘して下さい．

\newpage

\section{質問用紙}

\newpage

\begin{center}
{\LARGE\gt 質問用紙}\\
\end{center}

\vspace{2eX}

\apsection{1. コード把握度問題}

以下の文章について{\bf プログラムの内容(レビュー前の状態．つまりレビューによ
り判明したバグは未修正として)と比較して} yes / no / わからない で答えよ．
わからないが，多分 yes だと思う場合には yes と わからない にマークを，
多分 no だと思う場合には no と わからない にマークをして下さい．

\begin{enumerate}

%%% ** data

 \item 入力された票が出庫依頼表の時，読み込む情報は，票識別子，送り先名，銘柄数，
   銘柄，数量の5種類である．
\yesno
% ans. no, 銘柄数はない．
% procmain vol2_main.c
%      この問題はあまり良くない気がする．出庫依頼表に元々書かれているように
%      感じてしまう．
% type. data
% 1

\item 新たに在庫不足票控を追加する時，在庫不足票控の配列をインデックスの小さい順に見てゆき，
      空いている(フラグが立っていない)ところに作成する．
\yesno
% ans. yes
% WaitRequest vol2_request.c
% type. data
% 簡単
% 2
% original question

%  \item 新たに在庫不足票控を追加する時，在庫不足票控の配列をサイクリックに，かつ，
%    空いているところに作成する．
% ans. ?
% WaitRequest vol2_request.c
%      サイクリックっていう言葉は意味が良くわからない
% type. data
% 2

 \item 新たに在庫不足票控を追加する時，在庫不足票控の配列が全て使用されて追加できない
   時は，エラーメッセージを出力して終了する．
\yesno
% ans.  yes
%      void WaitRequest vol2_request.c
%            error("\"reqbuf\" is full"); vol2_debug.c exit(1);
% type. data
% 3

 \item 在庫不足票控の配列は，空いているいないの判断のためにフラグ領域を持っているが，
       実際にフラグを立てられることはない．
\yesno
% ans. yes
% bug 1 そのものに関わる問題
% type. data
% 4
% original question

%  \item 在庫不足票の配列の空いているいないの判断のためにフラグ領域を持っているが，
%    その領域に設定するとき，使用している場合の値は1でも10でもプログラム上問題
%    ない．
% ans. yes
% WaitRequest vol2_request.c
%      問題が曖昧な気がするが．．全部それに合わせて変えれば良いと思うし．．
%      実際はバグにより，flag を立てる操作は行われていない
% type. data
% 4

 \item 在庫不足票を解消する時，在庫不足票控の配列の空いているいないの判断のために
   フラグ領域のみを未使用の設定値にしており，他の領域はクリアしない．
\yesno
% ans. yes
% CheckRequest vol2_request.c
% type. data
% 5

 \item ある銘柄の酒に対する在庫不足票控があるかどうかは，まず在庫不足票控の配列中
       のフラグが立っているかいないかが調べられ，フラグが立っていれば銘柄の照合が
       行われる．(isWaitLiquorに関する質問)
\yesno
% ans. yes
% isWaitLiquor vol2_request.c
% type. data
% 6

 \item 在庫不足票で出力される変数項目は，送り先名と銘柄と数量の3種類である．
\yesno
% ans. no
%      PrintWaitRequest vol2_request.c
%      依頼番号 送り先名 銘柄 数量 の4種類である
% type. data?
% 7

 \item 在庫不足票控の配列は，必要時に動的に割り当てている．
\yesno
% ans. no
%      reqbuf[MAX_REQBUF]_request.c
% type. data
% 8
% original question

 \item コンテナ構造体を新たに追加するとき，初期設定としてコンテナ内の銘柄をすべて
   NULL クリアしている．
\yesno
% ans. no
%      AddContainer vol2_container.c
%      数量を0に初期化しかしていない -> これはバグといえるのでは
% type. data
% 9

 \item コンテナ構造体の領域は，必要時に動的に割り当てている．
\yesno
% ans. yes
% AddContainer vol2_container.c で動的に確保される．この関数を呼び出すのは
% UpdateChamber vol2_main.c のみ
% type. data
% 10

 \item コンテナを削除する時は，単に該当するコンテナ構造体の領域を開放するだけで，他の処理は
       何も行わない．
\yesno
% ans. no
%      FreeContainer vol2_container.c
%      リンクの繋ぎ変えも行っている
% bug 5 と間接的に関係．ただし，bug を除去しても答えは変わらない．
% type. data
% 11

 \item コンテナの内容が空かどうか(出庫するとコンテナ内の酒の個数が0にな
	   るかどうか)調べるのに，コンテナ構造体内の空コンテナマークを
       見ているのは，出庫指示票作成時のみである．
\yesno
% ans. no
% 	 MakeSendlist  vol2_container.c
%      PrintSendlist vol2_container.c
% type. data
% 12

 \item 倉庫のルートは適切に初期化されており，ガーベージコレクションが
       実行されても削除されずに残るように配慮されている．
\yesno
% ans. no
% bug 3 を直接聞く質問
% type. data
% 13
% original question

 \item コンテナを表す構造体がデータとして所持しているのは，
       コンテナ番号，コンテナ構造体同士のリンク，コンテナ内の酒のリストである．
\yesno
% ans. yes
% liq.h
% bug 7 とちょっと関係する問題．bug を除去しても答えは変わらない
% 次の問題とも関連
% type. data
% 14
% original question

 \item コンテナ内の酒のリストが所持するデータは，銘柄名，数量，搬入年月，搬入日時
       である．
\yesno
% ans. no
% liq.h
% bug 4 とちょっと関係する問題．bug を除去しても答えは変わらない
% 前の問題とも関連
% type. data
% 15
% original question

 \item 出庫するコンテナのリストを表すSendlist構造体は，依頼番号，送り先名，
       銘柄名，コンテナの数，出庫するコンテナを表す構造体のリストから構成
       されている．
\yesno
% ans. yes
% liq.h
% 次の問題とも関連
% type. data
% 16
% original question

 \item 出庫するコンテナを表す構造体は，コンテナ番号，数量，空コンテナマーク
       から構成されている．
\yesno
% ans. yes
% liq.h
% 前の問題とも関連
% type. data
% 17
% original question

 \item 倉庫のルートを表すrootという変数は，複数のファイルから直接参照されている．
\yesno
% ans. no
% liq.h
% type. data
%% [意味的には「倉庫」を表しているが，この変数は] を省略
% Container *chamber 変数を用いて間接的に参照されている．root は static 宣言されて
% いて，他のファイルからは見えないようになっている．
% 18
% original question

 \item 出庫コンテナリストを作成する関数 MakeSendlist において，引数のうちの一つとして，
       作成する出庫コンテナリスト構造体へのポインタ Sendlist *sl が与えられる．
\yesno
% ans. yes
% vol2_container.c MakeSendlist
% type. data
% 19
% original question

%%% ** interface

 \item 入力された票が積荷票の時，酒の在庫数を更新するために呼ぶ関数の引数は，
   積荷票のコンテナ番号と銘柄と数量の3種類だけである．
\yesno
% ans.  yes
% UpdateChamber vol2_main.c
% type. interface
% 1

 \item 入力された票が積荷票で1銘柄ずつ倉庫に酒を入力する時，入庫するコンテナ
   構造体のポインタを得るために関数を呼ぶが，その引数は積荷票のコンテナ
   番号だけである．
\yesno
% ans. no,
%    vol2_container.c
% 	 Container *QueryContainer(/* 指定した番号のコンテナ構造体へのポインタ / NULL */
% 	 Container *root,      /* IN :在庫リストのルート    */
% 	 int number            /* IN :コンテナ番号          */
% 	 )
% type. interface
% 2

 \item 入力された票が出庫依頼表で出庫処理をする時，在庫不足票控があるかどうか
   調べるために銘柄数を引数とする関数を呼ぶが，処理結果として，存在した
   場合1が帰ってくる．
\yesno
% ans. yes
%      ref. isWaitLiquor vol2_main.c
% type. interface
% 3

 \item 入力された票が積荷票で1銘柄ずつ倉庫に酒を入力する時，コンテナ構造体の
   ポインタを得るために関数を呼ぶが，処理結果として，ポインタ値かNULLが返って
   くる．
\yesno
% ans. yes
%      QueryContainer vol2_container.c
% type. interface
% 4

 \item 入力された票が積荷票で1銘柄ずつ倉庫に酒を入力する時，積荷票で指定された
   コンテナにその酒の情報を更新するとき，酒の銘柄はサイズ21でコピーされる．
\yesno
% ans. no
% UpdateChamber vol2_main.c
%      ポインタで渡される
% type. interface
% 5

 \item コンテナが空でないかどうかを調べる関数 isNoLiquor は，コンテナが空の時は 1 を，
       そうでない時は 0 を返す．
\yesno
% ans. yes
% bug 1 とかなり関係する問題．ただし，bug を直しても答えは変わらない
% type. interface
% original question
% 6

 \item 空になったコンテナを全て削除する関数 CollectGarbageContainer は，内部で，
       FreeContainer を倉庫のルートとコンテナ番号を引数として呼び出している．
\yesno
% ans. no
% bug 2,3 と関係する問題．bug を直すと答えが変わる．
% type. interface
% original question
% 7

 \item 出庫コンテナリストを作成する MakeSendlist 関数において，空コンテナマーク
       の付与のため isNoLiquor 関数を呼んでいるが，その際の引数として，空かどうかを
       調べるべきコンテナへのポインタが渡されている．
\yesno
% ans. no
% bug 4 と関係する問題．bug を直すと答えが変わる．
% type. interface
% original question
% 8

 \item 倉庫に酒を入庫する関数 UpdateChamber へ渡す引数は，入庫するコンテナのコンテナ番号，
       銘柄名，数量が正しい．
\yesno
% ans. yes
% bug 5 と関係する問題．ただし bug を直しても答えは変わらない
% type. interface
% original question
% 9
 
 \item 出庫処理をする関数 SendLiquor へ渡す引数は，依頼番号，送り先名，銘柄名，数量
       が正しい．
\yesno
% ans. yes
% bug 6 と関係する問題．bug を直すと答えが変わる
% type. interface
% original question
% 10

 \item 指定した量の酒があるかどうか調べる isExistLiquor 関数は，指定し
       た銘柄／量の酒が倉庫に存在する場合は 1 を返し，そうでない場合は 0 を返す．
\yesno
% ans. yes
% bug 7 と関係する問題．ただし，bug を直しても答えは変わらない
% type. interface
% original question
% 11

 \item 倉庫に酒を入庫する関数 UpdateChamber は，コンテナに酒を入れる関数 StoreLiquor
       を呼び出す際，倉庫のルートと銘柄と数量を引数として与えている．
\yesno
% ans. no
% bug 8 と直接関係する問題
% type. interface
% original question
% 12

 \item 倉庫に酒を入れる関数 StoreLiquor は，引数として，
       入庫するコンテナの番号，銘柄名，数量を受け取るのが正しい．
\yesno
% ans. yes
% bug 8 と間接的に関係する問題．ただし，bug を修正しても答えは影響は受けない
% type interface
% original question
% 13

 \item コンテナを新たに追加作成する関数 AddContainer への引数は，作成する
       コンテナのコンテナ番号のみである．
\yesno
% ans. no
% vol2_container.c AddContainer
% type interface
% original question
% 14

 \item 不要になったコンテナを削除する関数 FreeContainer への引数は，
       不要となったコンテナへのポインタと，倉庫のルートへのポインタである．
\yesno
% ans. no
% vol2_container.c FreeContainer
% コンテナ番号と，倉庫のルートへのポインタ
% type interface
% original question
% 15

 \item 在庫不足票控えを解消する関数 CheckRequest は，引数として在庫不足票控の
       配列へのポインタを受け取る．
\yesno
% ans. no
% vol2_container.c CheckRequest
% 引数は受け取らない
% type interface
% original question
% 16

 \item 在庫不足票控えを作成する関数 WaitRequest は，引数として，在庫不足票を
       作成する元となった依頼票を表す構造体へのポインタを受け取る．
\yesno
% ans. yes
% vol2_request.c WaitRequest
% type interface
% original question
% 17

 \item 出庫処理をする関数 SendLiquor は，引数の一つとして搬入日時も受け取る．
\yesno
% ans. no
% vol2_main.c SendLiquor
% type interface
% original question
% 18

 \item 倉庫に酒を入庫する関数 UpdateChamber は，引数として，コンテナ番号，
       銘柄名へのポインタ，数量，倉庫のルートへのポインタを受け取るのが正しい．
\yesno
% ans. no
% vol2_main.c UpdateChamber
% type interface
% original question
% 19

%%% ** logic

%  \item 実行方法において，「\verb|sakaya -a file_name|」としたとき，'-'の後が'd'で
%   ないのでエラー表示をして終了する．
% \yesno
% ans.  yes
% main vol2_main.c
% type. logic
% 1

 \item 実行方法において，\verb|「sakaya -d file1_name file2_name」|と，\newline
\verb|「sakaya -d   file1_name -d file2_name」|は同じ結果を出力する
\yesno
% ans.  yes
% main vol2_main.c
% type. logic
% 2

 \item プログラム実行時ファイルを同時にオープンしている数は，最大1ファイルである．
\yesno
% ans.  yes
% main vol2_main.c
% type. logic
% 3

 \item 実行方法において，\verb|「%sakaya file1_name」|とした時，標準入力によるデータ
  入力はできない．
\yesno
% ans.  yes
% main vol2_main.c
% type. logic
% 4

 \item 実行方法において，\verb|「%sakaya」|とした時，標準入力より積荷票と出庫依頼票
       を入力し正常に処理したあと，プログラムは終了する．
\yesno
% ans.  yes なのだろうが，積荷票だけが入力ではあるまい
% main vol2_main.c
% type. logic
% 5

 \item 入力された票が積荷票の時，銘柄数の値は次行に続く[銘柄、数量]の組の行数
  を示すものであるが，銘柄数の値が5で[銘柄，数量]の組の行数が3の時，最後
  の[銘柄、数量]の組の後に何もなければ(eof)，エラーは生じない．
\yesno
% ans.  no, feof(fp)に引っかかる
% procmain vol2_main.c
% type. logic
% 6

 \item 入力された票が積荷票の時，銘柄数の値は次行に続く[銘柄，数量]の組の行数
  を示すものであるが，銘柄数の値が1で[銘柄、数量]の組の行数が10の時，最後
  の組の行数10の時，最後の[銘柄、数量]の組の後に何もなければ(eof)，エラーは生じない．
\yesno
% ans. yes, kind(銘柄数)回数，ペアを読み取るようになってる
%      eof ではなく，入力が続く場合はエラーとなるだろう．
% procmain vol2_main.c
% type. logic
% 7

 \item 入力された票が積荷票で1銘柄ずつ倉庫に酒を入力する時，`積荷票に記述
	   されているコンテナ番号のコンテナ'の酒の情報を更新できなかった
	   時，エラーメッセージを出力して終了する(UpdateChamber 関数に関する問題)
\yesno
% ans. no,
%      vol2_main.c
%      static void UpdateChamber で，関数中でもエラー処理は行われていない
% type. logic
% 8

 \item 入力された票が出庫依頼表で出庫処理をする時，出庫するよう指定された酒が
   必要以上に倉庫にあるか調べるための関数を呼ぶが，引数の1つとして出庫依頼票
   の銘柄名と同一サイズでコピーしたものを使っている．
\yesno
% ans. yes, strncpy でコピーしてから渡している
%      SendLiquor vol2_main.c
%      strncpy(req.name, name, NAME_SIZE);
%      ...
%      isExistLiquor(chamber, req.name, req.count)
%      この問題は言葉の表現があまり良くない．問題としてもどうかなあ
% type. logic
% 9

 \item 入力された票が出庫依頼表で出庫処理をする時，指定された銘柄の数量が0に
   なるまで，出庫の対象となるコンテナリストの作成および表示する関数を呼んで
   いるが，理由はそれらの関数が1度呼ぶごとに1つのコンテナに対する処理しか
   できないためである．
\yesno
% ans. no, 出庫指示票に書ける最大コンテナ数が仕様書で定義されており，それを満たすため
%      #define MAX_CONTAINER 10        /* 出庫指示票に書ける最大コンテナ数     */
%      void SendLiquor vol2_main.c
%        void MakeSendlist vol2_container.c
% type. logic
% 10

 \item 入力された票が出庫依頼表で出庫処理をする時，指定された銘柄の在庫不足票控
   があっても，出庫するよう指定された酒が必要以上に倉庫にあれば出庫している．
\yesno
% ans. no
%      SendLiquor vol2_main.c
%      if (!isWaitLiquor(name)...)
% type. logic
% 11

 \item 入力された票が出庫依頼表で出庫処理をする時，出庫の条件(要求仕様書
	   の条件ではなく，プログラムで記述されている条件)を1つでも満たさな
	   かった時は，在庫不足票の出力と在庫不足票控の作成のみを行う．
\yesno
% ans. yes
%      SendLiquor vol2_main.c
% type. logic
% 12

 \item 在庫不足票を解消する時，在庫不足票控の配列のインデックスの小さい順に走査し，
       在庫不足票控が解消できるようなら，解消操作を実行する
\yesno
% ans. yes
%      CheckRequest vol2_request.c
%      表現に改良の余地あり
% type. logic
% 13

 \item 在庫不足票控を解消する時には，同時に出庫指示票を出力している．
\yesno
% ans. yes
%      CheckRequest vol2_request.c
%        MakeSendlist
% type. logic
% 14

 \item 出庫するとき指定した量の酒があるか調べるには，必要以上に酒の量があったかと
   最大コンテナ数のみを条件としてコンテナを調べる．(isExistLiquor 関数に関する問題)
\yesno
% ans. yes
%      isExistLiquor vol2_container.c
% type. logic
% 15

 \item 出庫指示票のコンテナ数は，この票の作成時に参照したコンテナ数である．
\yesno
% ans. no, 出庫対象のコンテナ数である
%      コンテナを root から順に参照してゆく．
%      MakeSendlist vol2_container.c
% type. logic
% 16

 \item 空になったコンテナを全て削除する関数 CollectGarbageContainer はコン
       テナリストを辿ってゆき空コンテナを探し続けるが，空コンテナを探
       し続ける条件として，`コンテナへの構造体が NULL でない間\verb|(root !=NULL)|'
       のみを指定している．
\yesno
% ans. no, 出庫対象のコンテナ数である
%      CollectGarbageContainer vol2_container.c
% bug 1 と関連．bug を直すと答えが変わる．
% type. logic
% 17
% original question

 \item 指定した量の酒があるかどうか調べる isExistLiquor 関数は，コンテナ内の酒の構造体
       を調べるが，その際 \verb|MAX_LIQUOR| 回だけ配列を調べている．
\yesno
% ans. no, MAX_LIQUOR-1 回
%      isExistLiquor vol2_container.c
% bug 4 と関連．bug を直すと答えが変わる．
% type. logic
% 18
% original question

 \item 在庫不足票控を作成する WaitRequest 関数は，最大 \verb|MAX_REQBUF| 回だ
       け，在庫不足票控の配列を調べる．
\yesno
% ans. yes
%      WaitRequest vol2_container.c
% type. logic
% 18
% original question

 \item 出庫コンテナリストを作成する MakeSendlist 関数では，出庫指示票に書ける最大コンテナ数
        \verb|MAX_CONTAINER| の値に従って，出庫指示票を分割して作成している．
\yesno
% ans. no
%      MakeSendlist vol2_container.c
% bug 7 と関係する問題．bug を取り除くと答えが変わる．
% type. logic
% 19
% original question


\end{enumerate}

\newpage

\apsection{2. 仕様把握度問題}

以下の質問において，{\bf 仕様書の内容と比較して}正しい項目へ○をつけよ．
わからない場合は`わからない'へ，わからないが多分これだと思うという項目が
ある場合は`わからない'とその項目へ○をつけよ．

\noindent (1)積荷票の入力項目としてどれが正しいか

\begin{enumerate}
 \item コンテナ番号
 \renewcommand{\labelenumii}{(\theenumii)}
 \begin{enumerate}
   \item 999以下(3桁ということ)
   \item 99999以下(5桁ということ)
   \item わからない
 \end{enumerate}
% ans. (b) コンテナ番号は5桁．もうちょっと問題の表現を工夫した方が良いかもしれない

 \item 搬入年月
 \begin{enumerate}
   \item 199401
   \item 9401
   \item わからない
 \end{enumerate}
% ans. (b)

 \item 搬入日時
  \begin{enumerate}
   \item 150130
   \item 1501
   \item わからない
 \end{enumerate}
% ans. (b)

 \item 銘柄数
 \begin{enumerate}
   \item 10以下
   \item 99以下
   \item 999以下
   \item わからない
 \end{enumerate}
% ans. (a)

 \item 銘柄
  \begin{enumerate}
    \item 10文字以下
    \item 20文字以下
    \item 25文字以下
    \item わからない
  \end{enumerate}
% ans. (b)

 \item 数量
   \begin{enumerate}
     \item 99以下
     \item 9999以下
     \item わからない
   \end{enumerate}
% ans. (b)

\noindent \hspace*{-1cm} (2)出庫依頼表の入力項目としてどれが正しいか

 \item 送り先名
  \begin{enumerate}
    \item 10文字以下
    \item 20文字以下
    \item 25文字以下
    \item わからない
  \end{enumerate}
% ans. (b)

\noindent \hspace*{-1cm} (3)在庫不足票の出力形式としてどれが正しいか

 \item  1行目
 \begin{enumerate}
   \item \verb|"--- zaiko fusokuhyou ---"|
   \item \verb|"--- zaiko fusoku hyou ---"|
   \item \verb|"*** zaiko fusokuhyou ***"|
   \item \verb|"*** zaiko fusoku hyou ***"|
   \item わからない
 \end{enumerate}
% ans. (b) ちょっとシビアな問題の気もするし，二択の問題は他にもあるし二択にすべきでは

 \item  2行目
 \begin{enumerate}
   \item "irai-bangou okurisaki-mei(スペース10ch)meigara(スペース15ch)suuryou"
   \item "irai-bangou okurisaki-mei(スペース8ch)meigara(スペース15ch)suuryou"
   \item わからない
 \end{enumerate}
% ans. (a), 銘柄が20文字であるというのと出力の形式を考えれば回答できるが気づかないかと

\noindent \hspace*{-1cm} (4)出庫指示票の出力形式としてどれが正しいか

 \item  1行目
 \begin{enumerate}
   \item \verb|"*** shukko sijihyou ***"|
   \item \verb|"*** shukko siji hyou ***"|
   \item \verb|"--- shukko sijihyou ---"|
   \item \verb|"--- shukko siji hyou ---"|
   \item わからない
 \end{enumerate}
% ans. (c)

 \item  3行目
 \begin{enumerate}
   \item 出力項目は"依頼番号、送り先名、銘柄、コンテナ数"の値
   \item 出力項目は"依頼番号、送り先名、銘柄"の値
   \item わからない
 \end{enumerate}
% ans. (a)

 \item  5行目
 \begin{enumerate}
   \item 出力項目は"コンテナ番号、数量"の値
   \item 出力項目は"コンテナ番号、数量、空コンテナマーク"の値
   \item わからない
 \end{enumerate}
% ans. (b)

\end{enumerate}

\noindent (5)現在の在庫は，以下の通りである．

\begin{itemize}
 \item コンテナ番号1 搬入年月日1994年1月1日搬入時間12時
   \begin{itemize}
    \item 銘柄 a 数量 20
    \item 銘柄 b 数量 30
    \item 銘柄 c 数量 40
    \item 銘柄 d 数量 50
    \item 銘柄 e 数量 60
   \end{itemize}

 \item コンテナ番号2 搬入年月日1993年1月1日搬入時間12時
   \begin{itemize}
    \item 銘柄 a 数量 10
    \item 銘柄 b 数量 60
    \item 銘柄 c 数量 30
    \item 銘柄 d 数量 20
    \item 銘柄 e 数量 40
   \end{itemize}
\end{itemize}

\begin{enumerate}
 \item 積荷票(コンテナ番号3 搬入年月1994年2月1日搬入時間13時 銘柄数 2
 (銘柄 b 数量 20)(銘柄 c 数量 30))が入力された時，正しいのはどれか?
  \begin{enumerate}
   \item コンテナ1の情報が更新される
   \item コンテナ2の情報が更新される
   \item 搬入年月日と時間が更新される
   \item コンテナを倉庫へ入庫する
   \item わからない
  \end{enumerate}
% ans. (d)
% 少し問題をいじった．コンテナ番号と選択肢(d)を追加
% ans. (b) っぽいけど違う．シリアル番号のバグ

 \item 積荷票(コンテナ番号1 搬入年月1994年2月1日 搬入時間13時 銘柄数6
 (銘柄 f 数量 20)(銘柄 g 数量 30)(銘柄 h 数量 20)(銘柄 i 数量 30)
 (銘柄 j 数量 20)(銘柄 k 数量30))が入力された時，正しいのはどれか?
%  \renewcommand{\theenumi}{\alph{enumi}}
%  \renewcommand{\labelenumi}{(\theenumi)}
 \begin{enumerate}
   \item コンテナ1に酒の入庫情報が全て入る
   \item コンテナ1に入りきらないので，エラーになる
   \item 倉庫に新たにコンテナを作成し，入庫する
   \item 既に搬入されているコンテナと同じコンテナ番号を持つコンテナが入ってくることはありえない
   \item わからない
  \end{enumerate}
% ans.(d)
%  (a)コンテナ1に酒の入庫情報が全て入る
%  (b)コンテナ1に入りきらないので，エラーにすべき
%  (c)新たなコンテナを作成し，入庫する
% ans. (b)でも(c)でもないと思う．仕様書では触れられていないと思う．
%      なんというか，そもそも，同じコンテナ番号のコンテナが入って来るものなのかと
%      テストケースを見ても，同一番号のコンテナは入って来ない模様(バグと関連)

 \item 出庫依頼票(送り先 abe 銘柄 a 数量 5)が入力された時
 \begin{enumerate}
   \item コンテナ1の情報が(銘柄 a 数量 15)となる
   \item コンテナ2の情報が(銘柄 a 数量 5)となる
   \item わからない
 \end{enumerate}
% ans. (b) 搬入年月日が古いコンテナから出荷される

 \item 出庫依頼票(送り先 abe 銘柄 a 数量30)が入力された時
 \begin{enumerate}
   \item 出庫指示票は部分的に，(コンテナ数2(コンテナ番号 1 数量 20)(コンテナ番号 2 数量 10))の順序で出力される
   \item 出庫指示票は部分的に，(コンテナ数 2(コンテナ番号 2 数量 10)(コンテナ番号 1 数量 20))の順序で出力される．
   \item わからない
 \end{enumerate}
% ans. (a) コンテナ番号の小さいものから順に記述される(バグと関連)

 \item  出庫依頼票(送り先 abe 銘柄 a 数量 50)が入力された時
 \begin{enumerate}
   \item 出庫指示票(銘柄 a 数量 30)と，在庫不足票(銘柄 a 数量 20)を作成する．
   \item 在庫不足票(銘柄 a 数量 50)を作成する．
   \item わからない
 \end{enumerate}
% ans. (b)

\end{enumerate}

\noindent (6)現在の在庫不足票控は，以下の通りで酒の在庫は全てないとする．
\begin{itemize}
  \item 依頼番号 1 送り先 aaa 銘柄 a 数量 10
  \item 依頼番号 2 送り先 bbb 銘柄 b 数量 10
  \item 依頼番号 3 送り先 ccc 銘柄 c 数量 10
  \item 依頼番号 4 送り先 ddd 銘柄 d 数量 10
  \item 依頼番号 5 送り先 ddd 銘柄 b 数量 10
  \item 依頼番号 6 送り先 aaa 銘柄 b 数量  5
  \item 依頼番号 7 送り先 ccc 銘柄 d 数量  5
  \item 依頼番号 8 送り先 ddd 銘柄 e 数量 10
\end{itemize}

\begin{enumerate}
 \item 積荷票(コンテナ番号 1 搬入年月1994年2月1日 搬入時間13時 銘柄数 1
 (銘柄 c 数量 10))が入力された時，正しいのはどれか?
  \begin{enumerate}
   \item 依頼番号3が解消され，出庫される．
   \item 何も出庫されない
   \item わからない
  \end{enumerate}
% ans. (a)

 \item 積荷票(コンテナ番号 1 搬入年月1994年2月1日搬入時間13時 銘柄数 1
 (銘柄 b 数量 9))が入力された時，正しいのはどれか?
 \begin{enumerate}
   \item 依頼番号5が解消され，出庫される
   \item 何も出庫されない
   \item わからない
 \end{enumerate}
% ans. (b), 在庫不足票控の依頼番号2がのものが銘柄 b が不足しているので，そちらを無視して
%      出荷はできない仕様になっている

 \item 積荷票(コンテナ番号 1 搬入年月1994年2月1日 搬入時間13時 銘柄数 3
 (銘柄 c 数量 20)(銘柄 b 数量 30)(銘柄 a 数量 20))が入力された時，
 正しいのはどれか?
 \begin{enumerate}
   \item 出庫指示票の作成順序は，依頼番号 1, 2, 3, 5, 6 の順である
   \item 出庫指示票の作成順序は，依頼番号 3, 6, 2, 5, 1 の順である
   \item 出庫指示票の作成順序は，依頼番号に関係ない
   \item 出庫指示票は作成されない
   \item わからない
 \end{enumerate}
% ans. (b), 依頼番号の小さいものから順に出庫指示票は作成される
\end{enumerate}

% \begin{figure}
% \centerline{これはおまけの図です。}
% \caption{おまけの図}
% \end{figure}


\end{document}