連載
» 2007年03月27日 12時00分 公開

こうすればできる開発手順の標準化(5):開発標準の「標準」を満足させる3つの要素

今回は開発標準に求められることについて説明したいと思います。

[瀬谷茂,豆蔵]

 本題に入る前に、読者の皆さまは、いわゆる「開発標準」というものが具体的にどのような内容になっているのか、イメージがわきますか? いままでに「開発標準」を利用したことがある人はその内容が思い浮かぶでしょうし、そうでない人はもしかしたら全くイメージがわかないかもしれません。また、組織として規定されているものなのか、プロジェクト向けに規定された標準なのかによっても、持っているイメージは異なると思います。

 当然のことながら、「開発標準とはかくあるべし」というような決まりはどこにもありません。ですので、その組織にとって事情がさまざまに異なるように、どのような形・内容が良いのかはまちまちであり、さらにプロジェクトごとにも変わってくるのが当然と思います。それは、会社ごとに目指すものや業務の進め方や文化が異なるということ、そのものでもあります。

 では、開発標準はどのようなものでもよいのでしょうか? それがその組織に合っているものなら、よいと思います。逆に、どこかの組織でうまく使われているからといって、それをそのまま持ってきて適用できることは、まずありません。あくまで、その組織の開発業務がどうあるべきか、というところから検討を始めなければ、「良い開発標準」は作り出せません。

 ということで、今回の話はここまででおしまいです。……というのもなんですので、個々の組織の事情を超えて、現在のソフトウェア開発を取り巻く状況を考慮した場合、開発標準にどのようなことが求められるのか、以下検討してみたいと思います。

 独断的ではありますが、おおよそ以下のようなことが挙げられるのではないかと思います。

  1. 時には国境まで越える、さまざまなパートナーとの協働の考慮
  2. 開発技術の絶え間ない進化への対応
  3. 人材の流動性への対応

 以下、それぞれについて説明していきます。

1. 時には国境まで越える、さまざまなパートナーとの協働の考慮

 おそらくいま現在一番多い開発形態は、国内の会社同士の開発業務の連携ではないかと思います。準委任や開発受託など契約形態は分かれるにしても、1つのソフトウェア開発プロジェクトには、複数の会社の管理者や担当者がかかわるのが普通ではないでしょうか。このような前提に立つと、自ずと開発標準に求められることが1つ明らかになります。それは、ほかのさまざまな開発方法に慣れている開発者でも、プロジェクトに支障のない範囲で習得し、適用できる内容であること。当然、初めてその開発標準を利用するメンバーがいきなりすべてを理解するのは難しいので、最低限そのメンバーの担当範囲内の部分だけ理解できればよいということになるでしょうが。

 そのためには、できるだけスタンダードな方法論や各種手法、プロセスを採用するということが大切になります。例えば、オープン系のシステム開発向けであればオブジェクト思考や統一プロセス(いわゆる、UP)の考え方・開発方法を取り入れたり、CMM/CMMIやPMBOKのプロジェクト管理の考え方を採用したりというようなことになると思います。そうすることによって、その組織独自の考え方に基づく開発標準よりも、理解容易性が高まります。たとえ、そのようなスタンダードな考え方や手法に慣れていないメンバーが参加することになっても、それを理解するための書籍やトレーニングは一般的な形で提供されていますので、それらを利用できるメリットは少なくないことでしょう。

 また最近ではオフショア開発を含め、他国の会社をパートナーとして選択することも増えてきていますので、全体的にグローバルスタンダードにのっとった開発標準にしておくことで、コミュニケーション上のトラブルを減少させることも可能になります。

 と、ここまで読んでいると、すべてがスタンダードな内容になっていれば良いのか、ということになってしまいますが、必ずしもそうではありません。前回までにも説明しましたとおり、開発標準はその組織のノウハウでもあり強みになる部分ですので、そのための独自性というのはいずれかの段階で重要になってきます。その場合、独自性にこだわるメリットとスタンダードな内容を選ぶメリットをてんびんに掛けて、妥当な方を選択すればいいと思います。ただし、独自性にこだわる部分については、上述のような状況も考え、できるだけその部分の説明を厚くしておくなどの対策が必要になります。

 パートナーも含めて常にほぼ同じメンバーでプロジェクトを進めているという開発組織の場合、かなり独自性が強くても実際は問題ないかもしれません。ただし、この後で説明するような「人の入れ替わり」については、常に意識しておく必要があるでしょう。

 とはいっても、世の中のスタンダード(であろう)といわれているものは、CMM/CMMIや統一プロセスのように、枠組みだけが示されているものも少なくありません。また例えばオブジェクト思考開発手法のように、細部でさまざまな方法が提唱されているものもあります。ですので、全体から細部まですべてをスタンダードなものでカバーしようとしても、簡単にはできないという現実があります。個人的な経験と感覚では、思想や枠組みについてはスタンダードなものを採用して、その具体的な実践方法について独自の選択・ノウハウで最適化していくという形がよいように思えます。

2. 開発技術の絶え間ない進化への対応

 開発言語がマシン語からJavaや.NETへと、開発手法が手続き型からオブジェクト思考型へと進化(?)してきて、さらにソフトウェア開発を取り巻くさまざまな状況は常に変化しています。このような状況に対応するためには、以下の2点が重要と考えられます。

a) 安定部分と変化しやすい部分の分離
b) 開発標準そのものの改善の組み込み

以下それぞれについて説明します。

a) 安定部分と変化しやすい部分の分離

 常に変化しているとはいえ、大きく変わっている部分とそれほど変わっていない部分があると思います。例えば、要件定義→設計→実装→各種テスト→リリースという物作り の基本的な流れ(=ウォーターフォール 型開発という、開発ライフサイクルの意味ではありません。ほかの回で別途この点も説明したいと思います)は、ほとんど変わっていないのではないでしょうか。また、品質や生産性に対する基本的な考え方も、オフコンやメインフレーム系のシステム開発とオープン系開発においてそれほど違っているとは考えられません。

 一方、開発言語・手法やアーキテクチャ的な考え方、オープンソースを含めた各種フレームワークやライブラリ、各種開発・テストツールについては、幅は異なるにせよ常に変化(進化)を続けています。

 このように、ソフトウェア開発においては、時代とともに変化しやすい部分と比較的安定している部分が存在しているといえます。開発標準自体を長期的に維持していくことを考えた場合、このような点を意識して、できるだけそれらを分離しておくと、その保守性が高まることは間違いありません。蛇足ですが、これはソフトウェア開発(アーキテクチャ設計)そのものにも当てはまる考え方といえます。

b) 開発標準そのものの改善の組み込み

 上記の点に加えて、常に変化に対応し、開発プロセス・管理プロセスを最適化していくという活動も重要です。いくらある時点で完ぺきな開発標準が出来上がっても、極端にいえばその翌日にはどこかが陳腐化しているかもしれません。開発標準を組織のノウハウとして考えた場合、その蓄積のためにこの活動は特に重要です。

 具体的には、CMMなどでいわれているような、SEPG(ソフトウェア・エンジニアリング・プロセス・グループ)のような開発プロセス(開発標準)を管理するようなチームや仕組みを設けておく方法が有力でしょう。

3. 人材の流動性への対応

 すでに始まっている2007年問題のように、どのような組織でも人の入れ替わりはあります。開発標準の1つの目的は、できるだけ属人性を排除して、組織内に継続的にノウハウを蓄積することにありますので、開発標準を適切に維持していけば、このような問題にも比較的容易に対応できるはずです。

 しかし、開発標準だけがあれば、技術が人から人へとうまく継承できるとは限りません。開発標準に加えて、その継承のための仕組みも必要です。具体的には、開発標準の内容の理解を促進するためのトレーニングや説明会の開催、各種資料の提供等が挙げられます。これらは、新たに組織やプロジェクトに加わるメンバーへの効率的で効果的な育成ツールになるはずです。

 以上 、現時点で考えられる開発標準に求められることを説明してきました。開発標準の策定や改訂を考えられている場合、このようなことも早い段階で検討しておくとよいでしょう。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ