□------------------------------------------------------------------□
□　地方自治体Ｓ市地理情報システム構築における設計レビュー
□------------------------------------------------------------------□
---------------------------------------------------------------------
（設問ア）
---------------------------------------------------------------------
１．システムの概要とユーザーニーズの特徴
---------------------------------------------------------------------
１−１．システムの概要
----
　私は、地方自治体Ｓ市における都市計画基礎調査の結
果を解析するための地理情報システム（以降、本システ
ムと呼ぶ）の開発に参画した。
　都市計画基礎調査とは、５年に１度実施されるもので、
Ｓ市を約５，５００ヵ所のゾーンに分割し、ゾーン内の
人口や土地家屋の利用方法などについて調査を行う。そ
の結果は、電子データ化される。本システムは、基礎調
査結果のデータベースを任意の条件によりランキングし、
その結果を色替え地図として表現する。それにより、基
礎調査データから地域的な傾向を導き出し、今後の都市
計画を行う上での参考とするためのシステムである。

----
１−２．ユーザーニーズの特徴
----
　本システムは、旧システムの再構築プロジェクトであ
る。旧システムは、１０年前にＵＮＩＸプラットフォー
ム上に構築されていた。しかし、１つの指定を行うため
の操作が複雑だったり、１度指定した機能を解除する方
法が各機能により異なっているなど操作性の点でユー
ザーには評価の低いシステムであった。さらに、解析結
果データをユーザーが使用するＰＣ上に転送して利用し
たいなどの要望も高まっていた。
　このように、新システムの構築にあたっては、操作性
の向上が最重要課題であることを開発当初からユーザー
より伝えられていた。したがって、本プロジェクトにお
いては要件定義よりも外部設計のフェーズが重要となる
ことが予想された。

----
１−３．私の立場と役割
----
　私は、ソフトウエア開発会社に勤務しており、本シス
テム開発プロジェクトにアプリケーションエンジニアと
して基本設計・詳細設計を行った。

---------------------------------------------------------------------
 （設問イ）
---------------------------------------------------------------------
２．レビューの実施方法
---------------------------------------------------------------------
２−１．レビューを重視した作業フェーズ
----
　ユーザーと実施するレビューは、実現する各機能の操
作方法や機能間の連携などの外部仕様についてのレ
ビューを重視した。なぜなら、本開発プロジェクトは旧
システムの再構築であるため、システム要件については
ほぼ明確になっていることに加え、ユーザーが旧システ
ムの操作性について低い評価をしており、新システムで
はより高い操作性と各機能間の連携を望んでいたためで
ある。

----
２−２．適用したレビュー方法
----
　レビュー方法は、ウォークスルーを採用した。理由は、
システム要件については大きな変更はないものと思われ
たため、実際にシステムを操作する実務担当者と操作性
や追加すると便利な機能について具体的な意見が必要
だったためである。さらに、インスペクションのように
フォーマルな形式のレビューを行った場合、ユーザーと
の一体感が出しにくいことと、レビューに慣れていない
参加者にとっては意見を言いにくい場面も出てくること
が予想されたためである。

----
２−３．レビュー時に工夫した点
----
　レビューを効率的に行うために工夫した点とその結果
について以下に述べる。
(1)　参加者の選択
　レビューの参加者は、旧システムを実際に操作してお
り、かつ業務を熟知しているキーマンに絞って参加を依
頼した。その１つの理由は、小人数であればユーザーと
開発者が協力して一緒に良いものを作り出していこうと
いう一体感を出しやすいと予想したためである。その結
果、ユーザーと広範囲にわたっての意見交換ができた反
面、レビューに多くの時間を費やすという結果にもなっ
た。参加者を小人数に限定したもう１つの理由は、業務
を熟知しているキーマンであれば、旧システムから新シ
ステムに移行する必要のない機能やその代わりに追加す
ると業務の効率が上がる機能などを的確に指摘すること
ができると予想したためである。その結果、新システム
では、旧システムの良い機能はそのままに、操作性など
の悪い機能は改善して実現し、業務上不要な機能は新シ
ステムに移行しないという方向で機能が固まった。
(2)　わかりやすい資料の作成
　レビュー時にユーザーに提示する資料は、イメージ図
やフローなどを使用して、実際に操作するイメージが伝
わる資料にするよう心がけた。その理由の１つは、本プ
ロジェクトの場合、旧システムの操作方法や業務面から
見て理想的な操作方法について、ユーザーの方が多くを
理解しているため、現段階で開発者が考えている操作方
法をユーザーに示さないと、具体的な改善要望が出にく
いと考えたためである。この結果、大小含めてユーザー
から多くの改善要望が出た。もう１つの理由は、この
フェーズでユーザーと開発者の認識が同一でないと、下
流工程で仕様変更要求が多発する可能性が高いと予想し
たためである。この結果は、プロジェクトが現在進行中
であるため、まだ出ていない。
(3)　資料の事前配布
　レビュー用の資料は、事前にユーザーに配布し、疑問
点を整理してからレビューを実施するように依頼した。
理由は、キーマンばかりをレビューで占有してしまうの
はユーザーの実業務に支障をきたすため、週に１回２時
間程度の時間を確保してもらうのがやっとであった。し
たがって、時間を効率的に使う必要があったものの、操
作性の細かな点を限られた時間内で説明するのは現実的
に無理と判断したため、資料を事前に電子メールで配布
し、レビュー参加者が感じた疑問点や問題点に限って検
討を行うこととした。また、細かな検討が必要な事項に
ついては、レビューの場では方向性と検討を行う担当者
だけを決め、次回以降に検討結果を提示することとし、
効率的に時間を使うように工夫した。

---------------------------------------------------------------------
（設問ウ）
---------------------------------------------------------------------
３．レビュー結果のフォローアップ
---------------------------------------------------------------------
　レビュー結果のフォローアップは、以下のように行っ
た。
(1)　担当者と期日を明記した議事録の作成
　レビューの議事録は、検討が必要な項目については担
当者と期日を明記することにした。なぜなら、先にも述
べたように限られた時間内で検討できない項目について
は、次回以降に検討結果を提示する項目が多く出てきた
ため、担当を明確にする必要があった。また、プロジェ
クト全体として外部仕様確定のために与えられた時間を
超えてしまう可能性があったため、期日も明確すること
とした。この結果、レビューにより発生した問題の解決
に必要な作業タスクと担当・期日が明確となり、外部仕
様確定までのスケジュール短縮が図れた。
(2)　要望事項の管理と実現優先順位の検討
　レビューで得られた要望点は、各機能ごとに管理し、
最終的には優先順位をユーザーと討議して付与し、実現
するための概算開発規模も算出した。なぜならば、ユー
ザーからの要望は、大小さまざまなものが多く、それを
すべて新システムに反映すると開発費用が予算を超える
ことになる。そこで、ユーザーにはそれぞれの要望につ
いて、業務上効果的であるかどうかを基準に優先順位を
付与してもらった。また、開発者側では、それぞれの要
望を実現するためのプログラムの規模を算出した。この
資料は，外部仕様確定の最終段階において、ユーザーに
新システムで実現する各機能について要望を取り入れる
かどうか取捨選択した時の判断材料に使用した。

---------------------------------------------------------------------
４．今後の課題
---------------------------------------------------------------------
(1)　レビュー資料作成時間の削減
　今回、図を多用した質の高いレビュー資料を作成する
ために多くの時間を費やす結果となった。原因としては、
プロジェクトのメンバーがワープロソフトの図形描画機
能を充分使いこなしていなかったこと、ユーザーに理解
してもらうためには、何がポイントになるかが事前に明
確になっていなかったことがあげられる。
　今後は、ワープロの図形描画機能についての操作説明
をメンバーに対して行うことや、わかりやすい資料のポ
イントを標準化する必要があると考えている。
(2)　レビュー方法の多様化
　今回、さまざまな方法で、レビューを効率的に行うよ
うに努力したが、やはり、レビュー時間が足りない点は
否めなかった。しかし、現実的にはキーマンを長時間拘
束することは許されず、時間の不足を痛感する結果と
なった。
　今後は、より時間を効率的に使うためにも、レビュー
に電子メールだけでなくグループウエアの利用や電子会
議ツールの利用も検討の対象になるのではないかと考え
ている。