開発システムの品質向上に貢献できる技術ドキュメントについて考える ―― ASDoQ大会2012
●発注側が理解できる要件定義ドキュメントを定義する
産業技術総合研究所（AIST） 知能システム研究部門 社会知能研究G 主任研究員の和泉 憲明氏は，「利用者主導情報システム開発における成果物の管理と運用 ～AIST包括フレームワークに基づく自治体情報システム開発～」と題した講演を行った（写真6）．同氏は，市役所などの自治体で使用する情報システムの開発について，利用者（発注者）である自治体担当者と開発者の仲立ちをして，利用者が理解できる形でシステムの要件を定義し，システム開発を分割発注できるようにした．これにより，自治体担当者が開発システムの内容を把握できるようになった．また，従来は大手業者に一括発注していたシステム開発を，地元の中小規模の業者に分割発注できるようになった．和泉氏は，この要件定義の手法や標準開発手順，品質チェック・リストなどを「AIST包括フレームワーク」という手法としてまとめ，複数の自治体に対して展開している．
写真6 講演を行う和泉 憲明氏（産業技術総合研究所 知能システム研究部門 社会知能研究G 主任研究員）
自治体のシステム開発で起こりがちなのが，利用者の欲する機能が開発者に正しく伝わらず，コストをかけて開発者が見当違いの機能を開発してしまう，という事態である．例えば，利用者が「虐待対象児のかな氏名後方一致検索がほしい」と言うと，開発者は，氏名のふりがなをすべて並べ替えて（「いずみのりあき」なら「きありのみずい」など），後方一致検索が行える機能を開発する．しかし，実際に利用者が欲しているのは，苗字（姓）ではなく名前で検索できる機能であったりする．このような誤解による開発のむだや，似た機能を重複して開発するむだがなくなることにより，開発コストの増大を抑えられるという．
開発知識のない利用者が，利用者の理解できる形で要件を提示するために，和泉氏の手法では，利用者側が業務の流れ図（業務フロー）を作成する．業務フローには，「誰が，どのような順番で，どの帳票に対して，何を使って作業するのか」を図示する．この業務フローを基に，各作業の概要と処理手順をそれぞれユース・ケースとして記述する（写真7）．
写真7 作成した業務フローとユース・ケース記述
※ 写真をクリックすると拡大できます
2006年から本手法によって開発を始めた横浜市役所の情報システム開発プロジェクトでは，当初の見積もり額である33億円の1割にあたる3億円を要件定義の予算として確保した．その結果，仕様が明確になり，重複する機能を開発せずにすんだおかげで，システムの見積もり額を20億円に圧縮できたという．その後，札幌市役所の情報システム開発を始めるにあたり，横浜市役所の了解を得て横浜市役所の業務フローを札幌市役所に持って行ったところ，利用者が差分をチェックして修正するだけですみ，要件定義が迅速に進んだという．
ただし，記述方法を決めるだけでは最初はなかなかその通りに書けないので，和泉氏らが手取り足取りで指導しながら要件をまとめているそうだ．
なお，ドキュメントを作る際には，個々の成果物として正しいことを追求するよりも，システム全体がうまく動くことを意識して，作成する内容や順番を検討しているという．そのためには，これまでの開発で発生していた品質課題の情報を収集し，対策を考えることが有効である．その対策はできるだけ具体的なもので，また，開発の前段階で対応できることが望ましい．
例えば，業務の要件について「第三者が読んでもあいまいさが残らないように記述してください」と言っても，業務の担当者にとっては自分の記述のどこがあいまいなのかを認識できない場合がある．そこで，5W1H（Who；誰が，What；何を，When；いつ，Where；どこで，Why；なぜ，How；どのように）を基本とした簡単な記述ガイドラインを作成することにより，要件を適切に記述してもらえるようになったという．
●ドキュメントの品質についての悩みが続々
本講演会の最後のセッションとして，講演を行った山本 修一郎氏，戸田山 和久氏，和泉 憲明氏，山本 雅基氏（ASDoQ 代表，名古屋大学 情報科学研究科 特任准教授），井佐原 均氏（産業日本語研究会 世話人会 代表，豊橋技術科学大学 情報メディア基盤センター 教授）が壇上に並び，パネル・ディスカッションを行った（写真8）．セッションは，会場からの質問に講演者らが答える形で進められた．質問が次から次へと続き，熱のこもったセッションとなった．
写真8 パネル・ディスカッションの様子
左から，山本 修一郎氏，戸田山氏，和泉氏，山本 雅基氏，井佐原氏．
「文書品質に適正品質は存在するのか？」という質問に対し，山本 修一郎氏は「目標品質があってこそ適正かどうかを判断できる．ゴールを設定することが重要」と答えた．和泉氏は，判断を行う時期について，「本来はシステム全体の開発完了を決める時点で判断したいが，分割発注していると部分ごとに判断せざるを得ない」と嘆く．山本 修一郎氏は，「文書の場合，問題が起きるのは次工程でその文書が読まれた時点．そのため，プロセスを前提とした文書が大切になってくる」と述べた．
「開発システムの機能仕様書を再利用することを考えたとき，その開発プロジェクト内では了解済みである前提について，どこまで記述すればよいか？」という質問に対して和泉氏は，「To-Be（開発するシステムの内容）だけ記述するのではなく，As-Is（システム開発前の現状や抱えている課題）についても記述しておく必要がある．そうしないと，なぜこの仕様になっているのかが伝わらない」と答えた．現状と課題の分析を共有できれば，あるべき姿（To Be）が分かり，開発可能なシステム（Can Be）で合意できるという．山本 修一郎氏は，「意思決定を組織知として残すことができれば，再利用できる範囲が増えるだろう」と述べた．
「あいまいな記述と抽象的な記述の違いが分からなくなることがある」という悩みに対して，戸田山氏は「どのように，どの程度の詳しさで記述すればよいかというのは，相手によって異なる．むやみに規則を作って機械的に順守すると，かえって文書の品質を下げてしまうことがある．利用者が使いやすいように，参考となる書き方の例を提示するとよいのではないか」と述べた．和泉氏は「業務要件は固有名詞を使い，システム要求は一般的な用語で書くなど，使い分けることが重要」という．「まだ実装されていないものについては，本質的に何をすればよいのかが伝わればよいので，抽象的な表現でよい」（和泉氏）．山本 修一郎氏は，「具体的なところと抽象的なところが交互に進化するので，1方向で突き詰めることはできない．やはり，プロセスとして解決するしかない」とまとめた．
