ソフトウェア開発工程とレビューとの関係を図8．1に示す．レビューは，設 計工程の成果物を評価し，技術的な問題を解決することにより品質を作り込む作 業である．成果物の評価を誤ったり，技術的問題の摘出が不十分であったり，摘 出できてもその解決が適切になされなかった場合，設計工程で不良が作り込まれ る⊂28］．テストは，プログラムを評価して品質確認を行う作業である．設計工程 で不良が作り込まれていれば，不良を摘出する．
このように，ソフトウェア開発の全工程を通して，レビューとテストによって 品質保証を行う．しかし，テストは不良が作り込まれている場合にそれを摘出す る作業であり，設計の品質向上にとっては，設計工程において不良が作り込まれ ないことが大事である．こうした点から，レビュー自体の品質向上は重要である．
レビューによる品質評価と改善
レビュー レビュー レビュー
本計基設 能計機設 細計詳設
⇒ プログラム 作成
結合
ト
テス
⇒ 総合
テスト
⇒ 運用 テスト
開発作業 品質確認 評価
図8．1ソフトウェア開発工程におけるレビューの位置づけ
8．2．2 レビューの実施方法
レビューの実施方法は，多種多様である［27］．本論文で提案するレビューによ る設計の品質管理を理解しやすくするために，我々が実施しているレビューにつ いて，目的，実施のタイミング，報告書の観点から説明する．
（1）目的
レビューを実施する目的には，技術面と管理面の2面がある．
技術面のレビューでは，①設計の妥当性の確認，②技術的問題の解決，が主目 的である．①では，誤りや後工程で問題になると予想できる点を早期に摘出し，
回避するように努める．②では，新技術を採用したり，技術的に難しい問題を抱 える場合に，レビュアの意見を求め，問題の解決を図る．問題の摘出と解決のい ずれにおいても，レビューメンバーには技術力や経験が必要であるため，レビュ ーが成功するには，必要な技術に関する有識者や，経験者がレビューメンバーに 入っていることが重要になる．
管理面では，作業の進捗状況および品質状況を把握することである．技術的な 問題を発見した場合に，その技術的な内容よりも，問題解決の分担といった次に 起こすべき行動を検討する．レビューで的確な判断を下せるためには，進捗や品
質の状況を把握できるための情報が必要である．
（2）実施のタイミング
技術面のレビューでは，工程の終了時点を区切りとして実施するものと，レビ ュー 必要とする事情が生じて行うものの2種類がある．前者では，設計書など の成果物が一応完成した時点で，品質保証部門を交えて成果物をチェックする．
後者では，設計の過程で詳細を詰めていくために，有識者や経験者を交えて，設 計内容を決める．設計の詳細は，性能要件，コスト，使い勝手などの点から全体 のバランスをとりながら決定する必要があるため，こうしたレビューが必要にな る．レビューでは一度に大量に議論はできないため，レビューは頻繁に行う．特 に，大規模システムの設計では，こうした小さなレビューの積み重ねにより，設 計は徐々に完成していく．
（3）レビュー内容
レビューでは複数のテーマが検討されることが多い．技術面のレビューでは，
（2）で説明したように，設計の詳細は，性能要件，コスト，使い勝手などの点から 全体のバランスをとりながら決定する必要があるため，関連性のあるテーマ（た とえば，システム処理方式設計とネットワーク構成設計など）も合わせて議論す
る。
レビューで検討する内容は，設計の成否を左右する重要なことが多い。レビュ ーでの検討が不十分であったり，結果が適切でなかった場合には，開発するシス テムの品質が低下したり，開発中あるいは稼動後に問題が生じる．従って，レビ ュー燉eをプロジェクトマネジャはチェックする必要がある．レビューに出席で きなかった場合には，（4）で説明する「報告書」のチェックにて行う．
（4）報告書の形式
レビューを実施した後には，レビューの結果・実績の記録としてレビュー議事
録を残す．
我々の用いているレビュー議事録の様式を図8．2に示す．
レビュー議事録は表紙と次紙から構成される．
表紙には，レビュー日時・出席者（所属と氏名）・レビューテーマ，概要，成果，
今後の課題レビュー対象の資料およびレビューの材料となった参考文献などを 記載し，レビューの概要が把握できるようになっている．
次紙には，検討テーマごとに，結論とその理由とを記載する．結論の理由とは，
どのような案を，どのような視点から比較検討したのか，何が決め手となって結 論の案を選択したのか，それは資料や参考文献のどこに基づいた考えであるか，
などであり，議論の詳細と言える．結論のみならず，理由を記載することにより，
レビュー議事録を見れば設計の考え方や方針が把握できる．
従って，開発中の設計を診断する場合や，開発中に問題が生じて設計を見直す 場合には，レビュー議事録は重要な参考資料となる．
ヒ群 ・紺コ卵ク ・n三蔀ぱ皇・囚遠澱ざi鎭i否蓼蕎担…≡禦牽土㍉
、、 w AA r 、ドつ〉」，A噛● ←Aw ← 馳∨当一wp1 一 噂 、一〔ぺぷ…ヤrぷ…r w∨A 、 ｛一、叩一Aw ×｝…馳m、」・、…「 ＼〔一∨ …Aがふ…
泊㎡臼爵良学・ ・懸 ・・戸い蔦密巴璽1蔑亘箆竺ふ二亘三
お般 e・養◎慧一巷冥
iフ㎡ル㊧錬⑤綱挿λP舘●〉一ル桓撫⑳⇔轡へ繊 亘
纏灘譲縫講灘薫慧︑趣︑二云こ︑攣
二 茎
、 礁
；靹 急㌶
毒諺 巷漁 羅』璽
繋
︼包w二聴↑︑︐譜一こe◎苓轡烏一．一副
畷・… 竃？⑱s治頒盈然工濁屯泣謁べ埴鴛4z 柘螺額ロ部5鱗コ田
システム（デザイン、一）レビュー報告書． ・D役番号・R
トー≡ 1
冤先《融共〉（オ〉 ．
@ 全公本（タケ）ゼ
@ 自治シ1（タテ）、自治シ2（クリ㍉
@ 自治シ3｛イイL
@ 開嚢ζコヒ）一（イシカ）一（粟祖） 徽｝
闘運OR鶴、 ↑・
∨↑ 融一 謀主 P 王忠 ﹈
乙rで、、／ 笈
．！ｾ＼；㌻・、
こ：9．⊇i・・：搭
吉・ メ
A 句 卜、ン
．1 七
̲3ジいさ〆ジ ｛
コ．3露名冨 APP〆 n、出席者一
2．システム ジ ロ 邑 システム、 システム 市 訟 3、儲・登w勾 392釦／総012∨4．工題㊧号．｛v＞旭号司㌔ 1
5． 揃．・ モ11 …8B ・，・狗⑯〜 ：、 ＿i 冶AP算「
6． ， 」抜
D
巴 A鈴P Q日） ⊇㌦
↑ぼピ1ユ︾1いメバン．バ∨．いぶ
舗公共）開完 iロヒL
@ ゾ 蕪
B 1．
@ … 1
E i◆
@ … …
@ … 7． ＿〈
u∠
白 、Aρρ o 昌 システム
N援シスデムのQFDについて円誕レどユーを実
¥する．べ
し◎旬
8． ド メント，
ｩ
合 ＿昼理システム OFO←
@規事務支援システム／QFε〉／
♪ ）∨
9． ヤ ．お 斯厩：ミ訟剰 ｝猷パ已録考1 ， ，
1 ．o ▼8 システ〔」 ● P
@「銃合文書管理システム」提能一覧薮，
ｳr法漫霧支援シスデムjAPP開発餓粋賑』
冬当シ
【ア4）．〈雫野）。
も
ご…『w一㎜油 丁麺資蒜 （荘泣、驚▼．響㌻竺㌢r§ぜ ご ←ご｛
酬蚕昏茜轡．三｝←1鍾一霧麟泣聴聾⊆、、
図8．2 レビュー議事録の形式
へ いゆ プグ：亘癒熱趣、鯉．照
．竺二竺』ク．○：．訂主騨お吐已翌⊇、バ㌍，素．△㌔
lQ亘箪直堕登三二ご巳豆一『iこ・三：iヱ堕を鷲1桧蚕1亘ρ縞 ・里・
…田挟∈｝斑霜λΦ㈹シールΦ男憎堪り⌒ヘルプ艘
あヒ ：〜 、ミ w渉×
三捲1村・・6‥s・18・↓o・・2＄
祢
8． ドキニメント∨
蛍x・ 鴇． 噌 ロ・・22・ ■ 嘔ト・鵡・ ：ミ・ 3〜8噺・購 【苫1 4か 碇、w《 碍・嚇 魂rロ・・曳・囑灘 ＾
二W
麟る．父ヌ卓一啓一深一芳
9． 甲 暢
」o ロシスデム QFDダ
， ⌒シスデム／QFO
1二し
←
ロ ・ シスデム」 《＃ ド（鴇．Oノ◆
②鶏給文書管理シスデム」亮能一r覧表文
③r法規事輸支握シスデム」APP開⌒，
④「法輪支援シスデム」H1コ／下楊造項目資李し
i坦ぽ属情公共 治⑰ 島二
アム
W （
千 （
ア
当シス
f犠 1紺 4 ｛学、・糠 2 侍． ．，一 3件。 、
︵翼
，●一パ▼≡＃
土登一＝︐S奮
2．〆 ε…，・
今後の検討項§ ）統合文書管理シスデムOFOの指摘醇竃頁穆正の実施
｝鑑文纏システム他吐と｛鮫資料のメンデナンス識。
）法規事務支援シスデムQ亡Dの指摘目口頁健正及びオ端発項Bの追加
鰻当音曙、 昌繧期日．
ご二な成゜・エ
議事録を書く 意義があるi
ー
§治AP2、
自治AP2、
自治AP2．
i相｜／も！24，
脚！磐／30．
細戊／24．
±jF
1各QFO
（2）各シス ．が明 一パノ」。．、
セ
コ噸
馳ぺぷ〔
τ
讃 讃
r
…x｛蛎 パばー… 胡野吾欝…ぷ㌔…丁折「灘㌘載1｝、㌻ ご 灘答愉〔＾値1 →』ヤ
島蟄璽 塑已〔趣⊇〔〔≡駆願蛭違繭・三
図8．3
レビュー議事録を書く意義榔 一M念ゴシプク ▼1勺一 治」r甘一西瀦ピ：べ・一蚕魂滅培≡ぴ老灘▲・〜
口㎡臼 d悟磁● ・ 識び 一 ・・ 璃」田亡コ羅為垣尋忠議ご、≡ ．．：口ψ
≡
緩冷 ηノwぷ∵
芹拒∞漂奄 〔鵬⊇㌍舎峯空警樂≡繋詮警告〔≡訟。。．＿一一竺一＿，．。・一．・一，
．黍窯
，．聡品｛シ㌻ム． 濠吉 象禽〜（ヌ倣） ． r
牽里 由 （挨討内谷）
騒
u鷲謬妄理システム 他守＃セ■交資⇔の鋭o内．
雫〜漠含蜘・N F N〒丁一゜ 1
：灘懸蘂
＿1垣一内副軍行 官士ゼ回γクス シ←今
h鑑鷲㌻縷鋼㍍
∀馨
：霊㌣忽ン院
︐嚢籔藻霧鷲
一L2 0F自㌔妨寸
：i號
@ 技術上のノウハウがで あるi烈︑寛
ジ≡婁ニニごr校驚一覧表モ牽 ま舟． 向
牟縷灘 工
㌣
（￡，会⊆筥貢ズ， の＝イヒ」 ‡＝
＝
萎
；@ 煤泌づ 司く妙や 写瀞… 恒
一ロ含畝穆， 日獺宰 ．
図8．4 レビュー議事録の技術上のノウハウ
漣戯㊥ず辿＾脳ヨ妬ザ
8．2．3 レビュー議事録によるレビューの品質管理
レビューの良否は出席者の技術力に依存する．つまり，レビューの品質は人と いう不確かな要素に左右されるため，レビューの品質管理が必要となる．
1つの方法としては，どのような根拠で設計したか，どんな案を比較検討した のか，どのような資料や参考文献を元にしたのかといった視点から定性的に管理 する方法がある．これらは，8．2．2で説明したように議事録の次紙の結論欄
とその理由欄，表紙にある参考文献や参照元から容易にわかる．
もう1つの方法は，以下の視点からレビューを定量化して管理する方法である．
（a＞有識者や技術力のあるメンバで議論したか．
（b）議論は十分か．
（c）議論した内容は設計全体を網羅しているか．
このうち，（a）については，議事録の表紙に記載された出席者の氏名と所属から容 易に判断できる．（b）は，同じテーマを何回にわたって議論しているかという視点 で押さえられる．8．2．2の（2）で述べたように，大規模システムの場合，設計 はレビューの積み重ねにより完成度が増していく．例えば，データ設計という一 つのテーマについても，通常何回かのレビューを実施するので，レビュー実施の 回数が，議論の程度を知る指標になる．（c）については，ソフトウェア品質特性 のうち，レビューを実施したものは何か，していないものは何かを調べることで 判断できる．これは，レビュー議事録の次紙全体をテーマごとに分析することに
より把握できる．
「レビュー議事録からレビューの品質が把握できる．さらに，レビューの品質 管理を行うことで設計の品質管理ができる」という仮説を立て，ツールの作成を
試みた．