シス開発：システム開発に必要な技術の概要 |
システム開発は一発勝負なので「失敗しても後で改良すればいい」などといった考え方は通用しない。開発の重要な時点で、設計した内容が適切かどうかを確かめる作業が必要だ。それがレビューであり、開発の途中で何度か実施する。
レビューを成功させるには、その役割を参加者全員がきちんと理解しなければならない。レビューとは、設計された内容が適切かどうか、設計者以外の人を集めて検討する作業である。ただ検討するのではなく、必要に応じて改善方法も助言する。より多くの頭脳を集め、幅広い視点で設計課題を考える試みでもある。
このような役割なので、レビューの対象は何でもありうる。たとえば、プロジェクト管理で設計するタスクの一覧が、適切に洗い出されているかどうか、プロジェクト管理者がレビューを受けてもよい。テストに関してなら、テストシステムの仕組みや構成、洗い出したテスト項目などもレビューの対象となる。質を高めるために必要だと思うなら、何でも取り上げて構わない。
レビューの役割からは、実施すべきタイミングも見えてくる。設計内容をレビューするなら、設計が全部終わった時点では遅すぎる。もし間違った考え方で設計していたり、重要な考慮点を１つでも見逃していれば、設計をやり直さなければならない。それを発見するのがレビューなので、設計者が設計の大枠を決めた時点でレビューする必要がある。もし扱う対象が難しければ、全体の設計でレビューし、部分ごとに何回かレビューする方法を採用する。また、レビューした設計内容がかなり悪ければ、同じ対象で再度レビューすることもあり得る。
このような点を考慮して、レビューの時期を決定する。そして、プロジェクト管理のスケジュールに入れ、時期と参加者を明示しなければならない。
レビューというは、実際に設計したり作成したりする作業ではない。そのため、あまり時間をかけずに終わらせるべきである。早く済ませられれば、その分だけ設計や作成に時間を割り当てられ、全体の効率は向上する。
短時間で済ませるには、レビューに適した内容を取り上げることが重要だ。たとえば、設計の全体像を決めるレビューなら、以下のような点を検討する。
設計の全体像を決めるレビューで検討すべき点 １、この設計では、どのような点を考慮すべきか
２、考慮点を良くするために、どのような設計方法や技術を採用するか
３、設計全体として、どのような構成になるのか
−−−−−−−−−−−−−−−−−−−−
４、どのような点が未解決なのか
５、どうすれば、または誰に頼めば、解決できるか
このうち１〜３が主な内容で、４と５は未解決の部分があったときに検討する。この項目を見て分かるように、細かな内容を取り上げる作業ではない。設計の方針や大枠を決める作業である。たいていの開発は、使える時間が限られるので、設計の重要な点に絞ってレビューすべきだ。レビューが終わっても課題が残ったときは、参加者全員が協力して、できるだけ早急に解決を目指す。
設計の大枠が決まると、それに従って作業を進め、細かな内容まで設計する。そのレビューだが、時間に余裕があるならやっても良いが、通常は上司か同僚が内容を確認する程度で十分だ。決めた大枠に適合しているのか、レビューの参加者に資料を配って確認してもらう。問題が発見された場合以外は、わざわざ集まる必要はない。
細かな内容までレビューするのは、経験の浅い人が設計するような、特殊なケースだけと考えたほうがよい。経験のある設計者が集まってレビューすると、いろいろな考慮点が発言として出され、レビューされる人には勉強になるからだ。もちろん、最大の目的は、レビューによって設計の質を上げることである。
レビューを成功させるためには、きちんと準備することが“絶対に必要”だ。準備で満たすべき条件は、以下の４点である。
レビューを成功させる準備での条件 １、設計者は、レビューするための資料を用意する
２、作成する資料は、レビューすべき内容を満たしている
（つまり、上の表の１〜５を含んでいること）
３、用意した資料を、レビュー参加者へ“事前に”配る
４、レビューの参加者は、事前に資料を検討してから参加する
これらの内容から分かるように、レビューを開始する時点では、レビューすべき内容が見えるようにしておく。そうすれば、すぐに本題に入って、中身の濃い検討が可能だ。また、資料を事前に配ることで、問題点の解決案、別な設計方法などを調べる時間も確保できる。加えて、きちんとした準備は、レビューを短時間で終わらせることにも貢献する。
用意した資料が良くて、参加者の事前検討が終わっていれば、レビューの場では設計方針や大枠を決めるだけになる。大きな問題がない限りスムーズに決まるはずだ。
開発の作業では、設計者は忙して時間がない。設計内容を検討するときは、レビューを意識しながら作業を進めるようにしたい。レビューすべき項目は、設計者が最初に検討すべき内容でもある。それを適切にまとめれば、そのままレビュー用の資料として使えるはずだ。作業するときは、紙に何度も書くのではなく、アウトライン・プロセッサなどを用いて、どんどんと入力したほうがよい。考えながら資料を作る癖を付ければ、レビュー用の資料をわざわざ作る手間も減る。これからの時代は、資料を作りながら設計を進めるのが当たり前になるだろう。
レビューを成功させるためには、もう１つの重要な要因がある。参加者の意識だ。レビューの役割をきちんと理解していないと、重箱の隅をつつくような話題に終始して、無駄な時間を消費する。質の低いレビューが続くと、誰もレビューを受けたくなくなり、レビューする意味すら失われる。
レビューでは、ほとんど不可能な理想論を掲げる人も出てくる。他人が設計するので、かなり難しいことでも平気で言う人がいると、話がまとまらない。ほとんどの開発では、期間、資金、人材などの制約があり、現実的なレベルでの解決方法が必須である。これらをふまえた視点でレビューしないと、される人が困ってしまう。理想論ばかり言う参加者が出たら、レビューの役割をきちんと話して理解させる。もしダメなら、レビューから外れてもらうしかない。
理想論ばかり言わせないためには、誰もがレビューされる側に回る方法が効果的だ。自分もレビューされると分かれば、理想的なことばかり言えない。おのずと現実的な方法を提案するようになる。お互いにレビューするのが、対等な関係を作るのに役立つ。
レビューの質を高めるためには、レビュー全体を上手にコントロールすることが求められる。レビューの責任者を決め、その人がきちんと実施するのが一般的だ。取り上げている内容が適切か、技術的な裏付けを重視して検討しているかなど、中身をチェックしながら進める。
参加者の気持ちが重要なケースもある。悪い点を指摘しているつもりでも、指摘する箇所が多いと、レビューされる人は個人攻撃のように感じやすい。参加者全員がこの点を理解し、言い方に気を付けるとか、気分を悪くさせないように注意すべきだ。全体的な雰囲気が良くなるように、できるだけ楽しく進めながら、技術的にはきちんとした内容で検討したい。この辺の雰囲気作りも、レビュー責任者の役目となる。
どのような人が参加するかも、大切だ。あまり詳しくない人が加わると、その人が得意な話題へと導く傾向があり、本題から外れやすい。当たり前のことだが、その分野にある程度は詳しい人を参加させる。できるだけ人数を増やさず、レビューする能力を持った人に限定すべきである。
以上のようにレビューすれば、短い時間で済ませながら、設計の質を高められる。まず最初は、参加者の全員にレビューの役割を“真に”理解してもらうことだ。それが達成できれば、あとはスムーズに進むだろう。レビューでは、どのような点を考えて設計するのか話し合うので、勉強にも最適である。良い関係でレビューできれば、参加者全員が、お互いにスキルを高められる良い機会を得られる。
（1998年６月10日）
レビュー：早い時点で設計の質を高める検討作業 |
