「プロジェクト標準」の正しい作り方／伝え方

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

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

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

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

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

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

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

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

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

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

プロジェクトの特性に見合った標準を作る

「苦労をするだけのメリットがある」「割が合う／元が取れる」という話からもお分かりいただけると思いますが、標準を作って運用するには、それなりのコストが発生します。標準化の活動では"あれもこれも"と、得てして過剰になりがちです。標準化を検討する際には、「コストに見合ったメリットが得られるか」の意識を強く持つように心がけると良い結果が得られるでしょう。標準化のコストは2 つに分けられます。「標準を作成するコスト」と、「標準を遵守するコスト」です（図4）。標準化の活動では、これらのコストをできるだけ小さく抑えて必要充分な効果を得ることを考えます。

図4 標準化の2つのコスト

標準化のスコープを検討する

標準を作成するコストについては、「スコープを適切に区切ること（どこまでを標準化するか）」と、「再利用性を考えること（どのくらい使い回せるように抽象化するか）」の2点に留意します。「どこまで」というスコープの考え方としては、まず開発の作業の流れ（プロセス）を可視化し、どの範囲を標準化するかを検討します（図5）。

図5 標準化のスコープ検討

ここでの可視化は、必要な成果物と作業をリストアップすることが目的ですので、大仰なフロー図を書くまでもなく、作業を分類し、一覧を作るだけでも十分です。その上で、標準化の範囲を次の3段階に分類します（図6）。

図6 標準化の3ステップ

1. 成果物の標準化
2. 作業の標準化
3. 作業支援ツールの提供

一番初期段階としての「成果物の標準化」では、どのような成果物を作るかを定めるために、ドキュメントのテンプレートや記述の規約を用意することになります。プログラムレベルでのコーディング規約も、ここに含まれます。3 ～ 5人程度以上の体制を必要とするビジネスアプリケーションの受託開発プロジェクトでは、プロジェクト中で公式に取り扱われる設計書や要件定義書、テスト項目書などの文書について、少なくともこのレベルの標準化を行なうことが望ましいでしょう。それらの標準を早期に顧客に提示することで成果物イメージの共有を図り、トラブルを事前に防ぐ効果も期待できます。

次の段階としては、どのようにその作業を進めるべきかを定める「作業の標準化」に至ります。「共有サーバー上のファイル管理ルール」「議事録の承認ルール」といった定型的な作業ほど標準化しやすく、「ソースコードレビューの観点」や「モジュール分割の進め方」といった個人の暗黙知やスキルに頼るところの大きい作業は標準化しにくいものです。定型的な作業を標準化するだけでも、プロジェクト進行の円滑さは変わってきますが、暗黙知やスキルの部分についても「レビューチェックリスト」などのように形式知化できれば、メンバーへの教育的観点から言っても、作業分担のしやすさから言っても、メリットは非常に大きいでしょう。

最終段階として、「作業支援ツールの提供」に至ります。作業の全体や一部を自動化するツールを購入あるいは開発し、作業負荷を低減するものです。ツール提供のアプローチの1つとして、内部設計書に対する外部設計書、ソースコードに対する内部設計書というように、成果物同士に階層構造があったときに、上位の成果物から下位の成果物の一部あるいは雛形を自動生成する、というものがあります。データベースの設計に利用されるER図からDDL（データ定義言語）を出力したり、RDBMSに接続して直接スキーマを生成したりするツールなどは、本誌読者の方には馴染みが深いものだと思います。「転記」や「翻訳」といった機械的な作業が、このようなツール適用の候補になります。このような自動化ツールを適用するには、「ER図を書いてデータベース設計を行ない、それをもとにスキーマを作成する」というように、自動化する対象となる作業の進め方を定義することが必要になります。そのため、「標準化の最終段階」と言っていますが、適用する作業の範囲を小さくして、手軽に部分的な自動化を行なうことももちろん可能です。このように、3 つの段階のいずれにおいても、さらにその中で「どこまで定めるか」を加減することが可能です。

プロジェクト内標準か、部署内標準か、社内標準か

以上のように、プロジェクト標準の作成はそれなりのコストがかかる作業ですから、一度作った標準を使い回せるようにしたいという発想は自然なものでしょう。そのプロジェクトの中でだけ使われる標準から始まって、部署内のほかのプロジェクトや社内での標準など、標準を使い回せる範囲が広がれば広がるだけ、「標準を作成するコスト」を都度支払う必要はなくなります。ただし、どんな範囲で使い回せるようにするかによっても、作成のコストや得られるメリットが変わってくることには注意する必要があります（図7）。

図7 標準の適用可能範囲

例えば、詳細な設計資料をどう書くのが良いかは、言語によって違ってくることも多いでしょう。Javaにはインターフェイス仕様書をソースコードに埋め込めるJavadocというツールがありますが、こうしたツールによって変わる面もあります。そもそも、そうした設計資料として何を記述すべきかについても、言語や利用技術によって変わってくるものです。例えば、Webアプリケーションとクライアント／サーバー型アプリケーションでは、セッションの考え方が違いますから、「セッションデータ仕様」を共用できる標準としてテンプレート化するのはなかなか困難なことでしょう。単体のデスクトップアプリケーションであれば、そもそもセッションという考え方自体が不要です。また、分析設計をDOAでやるかオブジェクト指向でやるかという方法論の違いによっても、作成するドキュメントは異なってきます。また、個別の顧客によっても、成果物として何が適切な文書になるかは異なります。

• 技術に詳しいシステム部門の方に理解してもらえれば良いのか、それ以外の業務担当者にまで理解してもらう必要があるのか
• ホストの経験はあるがオープンシステムの経験はない人にとって分かりやすい文書は何か
• 顧客の会社としての社内テンプレートはあるか。また、これまでの開発で見慣れたドキュメントはどのようなものか

こうした、個別の顧客ごとに異なる事情に合わせて工夫が必要な場面はありますが、標準が存在することによって、そのような工夫をしようという発想が失われることも考えられます。 これらのことを考え合わせると、標準を使い回そうという発想は自然ですが、実現するにはかなりの努力が必要になることが分かります。そこで、より安全な考え方としては、まずは「プロジェクト内標準」にとどめた標準化を進めるのが良いでしょう。それ以降のプロジェクトで、その標準を改変しつつ流用するだけでも労力は低減できます。そうして作業を継続する中で、個別のプロジェクトの色を消していきます。また、そのように経験を積むにつれて、ドキュメントの種類や個々の作業といった部分部分から使い回せる範囲を見極められるようになります。そのレベルにまで到達すれば、「J2EEアプリ開発設計書標準」や「金融業務要件定義標準」といった、より広く適用が可能な標準に仕上げるのも容易になるでしょう。標準化は1日にして成らず。日々の地道なカイゼン（改善）を積み重ねて、効果的な標準を育てていきましょう。

現場に受け入れられる標準を作る

さて、こうして標準を作っていく際にもう1つ考えなくてはならないのが、「標準を遵守するコスト」です。冒頭にも述べたように、自由に作業できるほうが嬉しいのが人間というものです。また、そうした自由のあるところからこそ、創造的な仕事が生まれるということもあります。標準は、こうした人間の感情面にとってのストレスというコストをはらむものでもあります。さらに、目の前の作業では大して重要でない項目までも、定型のフォームを全部埋めなくてはならないドキュメントなど、標準に沿うための余計な作業が発生することもあります。また、見落としがちなことですが、新しい標準を導入したり、新しいメンバーが参加したりする際には、標準を学習するにも時間と労力がかかります。こうした「遵守するためのコスト」が高い標準は、コストとメリットを差し引きして得られる効果が低くなるばかりか、開発現場に歓迎されないものになります。悪くするとまったく現場に受け入れられない無意味なものになってしまう可能性もあります。標準を作成する際には、「これは現場に受け入れられる標準か？」という視点を忘れないようにします。実際にプロジェクトの前線で働いている人には、「標準？ 意味もなく面倒な余計な仕事を増やすだけのものでしょう」という印象を持っている人が少なくありません (注2) 。

そのような現場に受け入れられるには、なにより心理的な障壁を取り除くことが大事です。標準がもたらす具体的なメリットを充分に説明し、標準化の意義を納得してもらうことです。本稿前半で述べたような内容について、「プロジェクトにとっての意味／大義」と、「目の前の仕事を楽にしてくれる可能性のある、当人にとってのメリット」を両立するものだ、ということを納得してもらえるように説明します。 たいていの場合、大義については「そりゃそうだろう......」という消極的同意が得られると思います。ただし、これだけで納得してもらえることは少ないのが現実です。現場の人にしてみれば、「そりゃ、標準とかそういうものはあったほうが良いだろうし、それに沿って仕事できれば良いだろうさ。とはいえ、標準を作ったり、いちいちそれを守ったり、現実にそんなことやってられる余裕があると思うか？」というのが正直なところでしょう。大義に正面から反論するのは難しいものですから、口に出して反論されることは少ないでしょうが、それだけ余計に内心の不満はたまります。そこで、「目の前の仕事を楽にしてくれる」メリットが重要になります。どのようなメリットをどのように伝えれば良いか、これは難しいところではありますが、一例として、筆者の経験では、新人や若手に対してであれば「こういう標準があれば、仕事の段取りややり方が分かりやすくて、進めやすいでしょう」、中堅どころにはOJT 的な見地から「こういう標準がないと、若手の仕事を手取り足取り見てもらわなくちゃならないところだけど、それがなければだいぶ楽になるよね」とメリットを伝えると、効果があることが多いようです (注3) 。

現場で作り上げる標準

標準の意義について現場の納得が得られたところで、標準化の進め方を検討します。当然のことですが、標準は、プロジェクトや社内など標準の適用される範囲全体で同じものが共有されなくては、標準として機能しません。そのため、標準化を進める場合には、標準のリポジトリを管理し、適用範囲にそれを伝える機能が必要になります。プロジェクト内で標準化を進めるのであれば、専任／兼任は問わず、標準化チームを置くことになるでしょう。ここでは、標準化チームが一方的に標準を作成し、現場に押し付ける形になるのは避けたいものです。標準に対する現場の積極的な姿勢を引き出すためにも、標準の作成は現場の意見に基づいて進められることが望ましいでしょう。このように進めることで、「実際に現場が望むもの」「現場で使えるもの」が標準に取り込まれていくようになります。 一人前の開発者であれば、読みやすいドキュメントの構成や、アプリケーションの使いこなし、作業を進める手順上のコツ、ちょっとしたマクロやスクリプトなど、それぞれ何かしらの技を持っているものです。そうした技をプロジェクト内で共有できるように、標準に取り込んでいきます。

とはいえ、「XXさん、なにかすごいワザ持ってないですか？」と聞いてもなかなか出てきません。そこで、XPのペアプログラミングのように作業を協同で行なうと、驚くような技を目の当たりにすることができます。そういうところから、「それ、いただき！」と、技を貯め込んでいきましょう。一人前の開発者同士であっても、得意技はそれぞれ違うもの。みんなの得意技を共有できれば、チーム力は格段に上がります。また、ドキュメントのテンプレートや作業手順の標準化については、できるだけ最小限に定めるところから始め、それに対する不満や要望を汲みあげることで、段々に充実させていくようにします。標準化チームは、標準を「作る」ことよりも、技や不満／要望を受け入れて、全体として整合性があるように誰もが使えるようにまとめること、まとめた標準をメンバーに伝達することに集中すると上手く回りやすいものです（図8）。

図8 標準化チームの果たすべき役割

また、標準化チームで「伝達することに集中する」ことが、学習コストを低減する工夫のしどころになります。現場の仕事を進めるための学習において、一番のポイントになるのは、「何を学習すれば良いのか」を見つけやすくすることです（図9）。

図9 何を学習すれば良いのか

個別の成果物テンプレート、作業手順やツールなどからなる標準について、「いつ／どこで／どれを使えば良いか」が分かれば、その先の「使い方」についてはどうとでもなると言っても良いようなものでしょう。現場の技の寄せ集めであれば、なおさら概要の資料などそろっているはずがありません。作業全体の流れを概観する資料から、個別の技を見つけられるようになれば、学習コストは大きく低減されます。また、「こんなことで困ってるんだけど、なにか役に立つものはないかな？」という疑問に答える逆引きインデックスなども、特に細かいツール類を活用してもらうためには便利でしょう。

そのプロジェクトに合った標準にしよう

ここまで述べてきたように、現場で作り上げる標準であれば、プロジェクトの課題を適切に解決するものになっていくはずです。そうではなく、社内や一般に公開されているものなど、既存の標準をプロジェクトに適用するときは、その標準がプロジェクトの特性に合ったものかどうかに十分注意しましょう。 ハードウェアと並行して開発し、いったん完成したら修正不可能な組み込みソフトウェアと、日々新機能を追加していくWebサイトでは、同じ標準を適用してうまくいくはずがありません。また、3人のプロジェクトと30人のプロジェクトでは、発生するコミュニケーションの質量ともにまったく異なりますので、そうした2つのプロジェクトで同じ成果物を作ろうというのは愚の骨頂です。大規模なプロジェクトでは、途中での方針転換に大きなコストがかかりますので、方針決定をより慎重に行なわねばならず、それに耐える成果物やプロセスが必要になってきます。

また、一般に大人数のプロジェクトであればあるほど、経験の浅いメンバーの比率が上がってきます (注4) ので、より綿密な手順を定める必要があるでしょう。プロジェクトが大規模になるほどルールがたくさんあるのはこうした理由があるからです。逆に、隣り合わせに座っている少人数のプロジェクトであれば、そのような重たいルールは必要なく、声を掛け合ったりペアプログラミングしたりと、より低コストな進め方ができます。 このように、プロジェクトの対象や求められる品質特性、体制やメンバーのスキルレベルなどを考慮して、どの作業／成果物について標準を定めるか、ツールによる効率化が可能な作業はどれか、どこまで細かい標準とするかなどを検討することが大事になってきます。既存の標準から「このテンプレートとこのツール」などと取捨選択したり、足りないところは補うなどして、プロジェクトの特質に合った標準にしましょう。

おわりに

システム開発は、複雑かつ困難な活動です。技術や要件など、システムが扱う事象の複雑さや難しさがまず大変なものです。多くの人や組織がそれぞれの利害関係をもって関わりあう体制も複雑です。複雑な体制の上で複雑な事象を扱うための、作業の進め方も当然複雑になります。複雑で困難な活動を、多くの人が協力し合って円滑に進めるためには、何らかのルールが必要となります。ルールというと堅苦しい、自由を奪われるものと考えがちですが、目的や効果を踏まえて、積極的に活用しましょう。