あなたのプロジェクトに「標準」はありますか？

前々回はアーキテクチャの重要性を、前回はJ2EEアプリケーションにおける1 つのソフトウェア／アプリケーションアーキテクチャの例として「軽量Java」を解説しました。システムアーキテクチャ、あるいはその下位概念としてのソフトウェア／アプリケーションアーキテクチャが、システムの作り全体に影響するものであることをご理解いただけたと思います。アーキテクチャは、設計やプログラミングにおいて全員が従うべき規則である「プロジェクト標準」となります。システム開発に携る多くの開発者が、一貫してアーキテクチャに沿った開発を行なうことで、システム全体の品質を保つことができます。システム開発プロジェクトには、開発者のほかにもさまざまな役割の人間が関わり、設計やプログラミング以外にもさまざまな作業を連携して行ないます。プロジェクト標準は、そうしたさまざまな役割／作業についてのガイドラインとなるものです。今回は、適切なプロジェクト標準のあり方について、もう少し踏み込んで考えてみましょう。

プロジェクト標準に求められるもの

「私が参加しているプロジェクトには、プロジェクト標準がある」という方は、「プロジェクト標準があって良かった」と思っているでしょうか。それとも、「あんなうっとうしいルールで縛られるのはまっぴらだ」とお考えでしょうか。筆者の経験からしても、「ばりばりプログラムを書くぞ！」というときには、できるだけ縛りがなく自由に作業できるほうが嬉しいものですし、標準に沿うために余計な手間をかけなくちゃならないなんて……と感じることもあります。標準やルールのあることは、必ずしもメンバーに喜ばれるばかりではありません。それなのに、なぜプロジェクト標準などというものがあるのでしょうか。プロジェクト標準には、そうしたいやな思いをするだけのメリットがあるからです。まず1つは、プロジェクト全体の視点からプロジェクト上の作業を均質化して管理でき、作業品質を保てるというメリットがあります（図1）。

図1 プロジェクトを均質化し管理しやすくする

例えば、「ビジネスロジックを実装するセッションBeanは機能単位に分割され、その粒度はシステムユースケースの単位とし、シナリオの各行を1メソッドとする」というセッションBeanの設計に関する標準があれば、セッションBeanのプログラム本数の見積りや、セッションBean1本当たりのプログラム規模が見積りやすくなります。また、これに加えて「システムユースケースにおいて、主シナリオおよび副シナリオにおいてはシナリオの全体が成功し、例外シナリオにおいてはシナリオの全体がロールバックされるものとする」というルールがあったとします。このとき、各システムユースケースがこのルールに則っているかどうかをレビューしておけば、設計／実装の作業を行なう際や、設計書やプログラムをレビューする際に、トランザクション制御の観点を極めて単純化できます。このように、レビューや設計、実装といった作業の中で、ルールがなければその都度開発者やレビュアが頭をひねる必要があるところを、ルールを設けることで、ルールに沿っていることを担保すれば済むようになり、作業の難易度や複雑度が下がり、トラブルを未然に防げるようになります。一方、プログラマをはじめとするメンバーの視点から見ても、プロジェクト標準にはメリットがあります（図2）。

図2 作業するメンバーにもメリットがある

1つに、作業の進め方が分かりやすくなることが挙げられます。例えば、テストの実施について考えてみても、図3のような大まかな作業の流れがあります。

図3 テストの大まかな流れ

こうしたテスト実施手順の流れが標準として定められていないプロジェクトでは、個々のテスト実施者は、何をどうしていいか、それぞれの場面でいちいち悩んでしまうことになります。この流れを標準として明示することで、メンバーはこのような悩みから解放されます。さらに、作業の進め方を分かりやすくすると同時に、作業を楽にしてくれる可能性も秘めています。標準が定められていることで、さまざまな作業支援ツールや自動化ツールの適用可能性が広がります。 先ほどの例で言えば、テスト項目を管理するExcelファイルに、障害管理票を生成／送信するマクロや、ログの自動収集マクロ、障害管理票に対応してテスト結果を自動入力するマクロなどを追加できるかもしれません。作業の流れが毎度異なるようでは、こうしたツールを作成したとしても使われる機会が限られますが、作業が標準化されていることで、ツールを作る“割が合う”ようになるわけです。設計やプログラミングの場面では、前々回に解説したフレームワークも作業支援ツールの1つと言って良いでしょう。アーキテクチャが標準化され、フレームワークが多くの開発者に使われることで、元が取れるようになるのです。もし読者の皆さんが、標準の定められていないプロジェクトに携っているのであれば、身近な範囲から標準化への取り組みを始めてみてはいかがでしょうか。適切な標準化は、きっとあなたやあなたの周りの仕事を円滑にしてくれるはずです。