シス開発：システム開発に役立つ様々な視点 |
最近の開発ツールは、オブジェクト指向技術を活用して、確実に進歩し続けている。多くの部品オブジェクトが提供され、ウィンドウのレイアウトなどはドロー系グラフィックソフトのように作れるし、プログラミングが必要な部分も減っている。デバッグ機能も充実し、バグの修正も容易になった。エンタープライズ向けでは、より上流となるクラス設計を支援するツールまで含まれている。同じ規模の開発なら、以前に比べて負荷が格段に軽減されている。
これだけ高機能になった開発ツールだが、きちんとしたシステム開発の視点で評価すると、まったく進歩していない面もある。その１つが、レビューを支援する機能だ。
レビューを支援する機能と聞いて、ぴんと来ない人がいるかも知れない。というより、そんな人のほうが多いだろう。改めて説明すると、レビューの支援とは、開発ツールで作成した内容が適切かを、作成者とは異なるレビュー担当者ができるだけ簡単に調べられるように、何らかの機能を用意することだ。
ただし、開発ツールを直接使いながらレビュー作業を進めるのではなく、レビューに役立つ情報を入力できたり出力できるだけでよい。この程度の機能でも、レビューの効率を格段に向上できる。また、凝った機能でないおかげで、開発ツールに加えるのも難しくない。その分だけ簡単に実現できるはずだ。
ところが、実際の開発ツールを見ていると、レビュー支援機能をほとんど持っていない。バージョンアップのたびに様々な機能が加わるものの、レビューに役立つ機能に限っては、まったくと言ってよいほど追加されない。どうやら、レビューの支援は、ツール改良の対象外となっているようだ。
これだけの説明だと内容が伝わらないと思うので、どのような機能が考えられるのか、代表的なものを紹介しよう。
最近の開発ツールは、GUIを積極的に採用している。おかげで簡単に使えるようになったのだが、細かな属性の設定を見るのにもマウス操作が要求される。ボタンなどのオブジェクトを数多く作成すると、全部の属性を確認するのが非常に大変となる。１つ１つの属性を順番に表示させなければならなからだ。
作成したオブジェクトをレビューする際には、個々の属性の設定も対象となる。属性の中には、システムの動きに関係するものや、設定値が不適切だと特殊な条件でトラブルを発生させたりする。このような設定ミスを見付けるのもレビュー担当者の役割で、詳しい技術者が見ればミスを容易に発見できる。
では、マウス操作の繰り返しが求められる現在のような開発ツールで、レビュー担当者はすべての属性を確認するだろうか。おそらく、ほとんどの人はやらないだろう。時間ばかりかかって、非常に大変だからだ。
このような状況を改善するには、レビューがしやすくなるような機能を、開発ツールに追加するしかない。具体的には、GUIで作成したオブジェクトの設定値を、テキストファイルとして出力する機能だ。作成したオブジェクトに関し、すべての属性名と設定値だけでなく、オブジェクト間の関係まで出力できればよい。こんな単純な機能でも、最低限の要望は満たせる。
出力ファイルを少しでも読みやすくするために、タブによる階層的な字下げなど、テキストの範囲内で可能なことは何でもやる。また、全部の属性を確認する必要はないので、見たい属性だけ指定して出力する機能も付ける。属性の選択を登録できて、簡単に呼び出せればなお良い。
テキストファイルなので、ファイル容量も大きくならず、メールで簡単に送れる。また、PDAのようなモバイル機器にコピーし、（本来あってはならないのだが）無駄な会議に出席しながらとか、電車の移動時間などに見ることも可能だ。空いてる時間を活用することで、レビューに余計な時間を割かなくて済む。
属性値のテキスト出力と似たような機能として、開発ツールで作成したファイルから仕様書を生成する市販ソフトがある。クラスのソースコードも含め、ワープロ書類やHTML書類として出力するものだ。この種の書類だと、余計な情報が多く含まれるために見るのが大変で、効率的なレビュー作業には向いていない。見たい情報だけを含んだテキスト形式が、もっとも汎用的で扱いやすい。
修正が必要な箇所の指示は、口頭ではなく記録の残る電子メールで行う。ただし、指示する箇所が多い場合には、テキストファイルを印刷して赤字を入れたほうが効率的だろう。どんな方法であれ、レビュー担当者からの指示は記録が残るようにする。
UMLで描いたクラス設計のように、テキスト化が簡単でない内容もある。それでも、無理をすればテキストで表現できるし、レビューに使えるレベルで出力ファイルを作れる。見やすいようにと、罫線文字を使って図の形で描かなくてもよい。タブによる字下げとテキストだけで十分であり、関連なども伝えられる。
クラス図を例に考えてみよう。クラスに関する基本情報は、クラス名の後に、１つ下の階層として続ける。表現が難しいのはクラス間の関連で、まず各クラスの下に関連情報として付ける。加えて、クラス名だけを用いた、関連を伝えるような表現も用いる。クラス名の後に、関連するクラス名と関連内容を字下げして入れる。これを全クラスで用意すれば、クラス間の関係が伝わる。関係が複雑だと見づらいが、内容は正確に表現できる。
UMLを用いて設計する開発ツールは高価なので、何台ものマシンにはインストールできない。テキストファイルでレビューできれば、どんなマシンでも読めるし、通信で簡単に送れる。この点も長所の１つといえる。
UMLで作成した内容をレビューする場合、クラスの属性や関連を見ただけでは、適切に設計されているのか判断できない。判断するための情報が含まれてないからだ。レビューを本当に支援するなら、なぜそのように設計したのかまで分かる情報を、レビュー担当者に伝える機能が必要だ。
そこまでUMLツールで実現するとしたら、設計理由を入力する機能も必要となる。設計理由としては、システムに求められる要件と、要件を実現するために検討した内容の２種類がある。その両方を入力できなければならない。その機能を持つと、出力するテキストファイルがレビュー可能なレベルに達する。
UMLツールを用いるのは、システム開発の中でも上位の工程である。以前はワープロソフトなどで書いていた一部を、UMLツールで置き換えたことに等しい。仕様書を一元化するなら、ワープロソフトで書いていた内容のすべてを、UMLツール側で入力できるのが望ましい。設計理由を書ける機能は、その目的にも役立つはずだ。
UMLツールが、UMLで規定されている以外の情報を多くサポートするほど、記述する内容が充実する。そのことは、レビュー用に出力するテキストの情報が増すことにつながり、より深いレビューを可能とする。
以上の話は、どんなマシンでも読めるように考慮して、出力ファイルの形式にテキストを選んだ。しかし、今後はXMLが急速に普及すると予想されるので、テキストファイルの代わりにXMLファイルで出力する方法もある。属性と設定値が並ぶようなデータはXMLに向いていて、特定の値を取り出しやすい。
XMLファイルで出力すると、XMLを読み込めるツールが利用できる。単純なテキストで見るのではなく、同じ属性値が縦または横に並んだ２次元の表で見れる。さらに、２次元以上の表にして多角的に見たり、データの関係を図で表現することも可能になる。
UMLツールでの設計内容をXMLファイルで出力すると、クラス図やシーケンス図の再現も可能となる。ただし、そのためにはXML上での表記方法をUML用として規定しなければならないが、これは難しくない。
XML化は、複数の開発ツールを組み合わせたときに威力を発揮する。複数のXMLファイルを読み込んで、整合性などを検査するツールも作れるからだ。完全な間違いを指摘するためよりも、間違う可能性が高い箇所を警告する目的で利用する。どんな箇所がどのような設定値なら間違っている可能性があるのか洗い出し、要確認の箇所として知らせるツールに仕上げる。検査ルールと警告メッセージを簡単に追加できるように、検査ルールを読み込んで処理する構造でソフトを作ればよい。検査ルールには処理も含まれるので、それを式などの形で規定し、全体の書式をXMLの形で標準化する。これにより、検査ルールもXMLツールで作成できる。
こうした検査の自動化は完全でないものの、人間によるレビューを手助けしてくれる。警告が出た箇所をレビュー担当者が調べ、本当にダメなのか判断する。レビューによる検査漏れが少しは減るはずだ。
XMLファイルで出力する機能を付けても、テキストファイルとして出力する機能も残しておく。そうすれば、XMLファイルを上手に読めないモバイル機器を使っている人でも、レビューが可能となる。
なお、複数の開発ツールが連携できる仕組みが用意されれば、以上のような工夫をしなくても、もっと高度な検査が可能となる。しかし、それが達成されるまでは、テキストまたはXML形式でのファイル出力は、かなり有効に使えるだろう。
レビューを支援する機能は、レビュー担当者だけに役立つわけではない。実は、作成している本人にも大いに役立ってしまう。
作成の最終段階や途中の重要な段階で、細かな設定が適切かどうか確認したくなる。もしかして設定し忘れた箇所があるかも知れないからだ。しかし、１つずつ属性を表示していたのでは、手間がかかって大変だと思う。そのため不本意ながら、確認を最後の１回だけにするか、大切なオブジェクトだけに限定してしまう。これでは、自信を持って作成物を提供できない。
ところが、設定内容をテキストで出力できれば、状況は一変する。面倒な手間をかけなくても、全部を素早く確認できる。最終段階はもちろん、途中の段階でも何度か確認するだろう。結果として、作成物の品質が向上する。このように、レビューを支援する機能は、作成者にも恩恵をもたらすわけだ。
このようなレビュー支援機能を持つ開発ツールが出てきて、それに慣れると、既存のツールは不満に感じるだろう。そればかりか、設定内容をきちんと確認する癖が付いているので、レビュー支援機能を持たないツールは使いなくなくなる。その意味で、高い品質を求める人にとっては、レビュー支援が必須の機能といえる。
最後に、重要な問題にも触れなければならない。ここで説明したようなレビュー支援機能は、なぜ開発ツールに付いていないのだろうか。これこそ、見逃してはならない点である。おそらくは、きちんとしたレビューを実施している組織が少ないためだと推測する。レビューだけではなく、きちとした開発方式を採用していない可能性が高い。そんな点を早急に改善し、開発方式や体制を整え、それに見合うような機能の要望を開発ツールの開発元に出そう。
（2000年２月23日）
開発ツールにレビュー支援機能を追加すべき |
