開発標準導入の阻害要因：こうすればできる開発手順の標準化（2）

ソフトウェア開発を主業務とする企業や部署においては、常にその改革・改善が求められているはずだ。そこでは開発標準の導入や改善が、1つの大きな改革・改善項目の候補になることは明らかである。

» 2006年09月20日 12時00分 公開
[瀬谷茂，豆蔵]

1. ソフトウェアの開発標準の現状

「自社の開発標準がある　52.2％」

　これは、少々古いですが2003年に日経ITプロフェッショナル誌が行ったアンケート（日経BP社発行 日経ITプロフェッショナル 2003年7月号　「開発プロセス大全」より引用）結果です。これだけを見ると、半数とはいえ日本でも開発標準を活用した組織的なソフトウェア開発が行われているようにみえます。しかし、同じ調査で以下のような結果も出ています。

「開発標準の種類：ウォーターフォール型　82.8％」

　これだけでは何とも断言できませんが、おそらくこれらの標準の大半が、メインフレームやオフコン向けの開発標準の可能性があります。実際、筆者がいろいろな現場で拝見した開発標準のほとんどが、そのようなものでした。

　だから悪いというつもりは、毛頭ありません。また、「ウォータフォール型だからメインフレームやオフコン向け」という理論的な関係はありません。重要なのは、組織がどれだけ現場で有効な開発標準を提供できているか、ということです。現在の新規開発案件では、オブジェクト指向技術に基づいた言語やフレームワークを使う機会が少なくありません。

　その際、メインフレームやオフコン向けの開発標準がどれだけ適用できるでしょう？ 経験上、それらの多くが構造化設計技法やそれに近い開発技法に基づくもので、オブジェクト指向を利用した開発には不向きなもの（部分）が少なからず含まれていると考えられます。もちろん、プロジェクト管理関係の標準については、どのような開発技法でも利用できる部分が多くなる傾向にありますが、細部（例えば細かな工程の考え方や見積もり方法）を見るとやはり不適合部分は存在するでしょう。

　そのようなことも考えてみると、冒頭の52.2％というのは、単なる開発標準の有無を示しているだけで、現場にとって有効な開発標準の有無であると考えると、この数字を大きく下回るのではないかと推測します。

　また上記の2つの数字は以下のようなことを物語っているとも考えられます。

「過去、組織の5割以上にあった『有効な』開発標準が減少している」

　これは何を意味しているのでしょう？ 日本のソフトウェア開発が、組織的なものから個人の力量に依存するものに移行した、といえるかもしれません。しかし、意地の悪い見方をすると、それは意図しての結果というよりも、ソフトウェア開発技術の進歩に組織として適切に対応し切れなかった結果というふうにも考えられます。

　実際、組織の「束縛」から「開放」されたソフトウェアエンジニアたちは、一部を除いて自由を謳歌（おうか）するどころか個々にスキルアップを強いられ、大規模化・複雑化するソフトウェア開発のプレッシャーに個人で立ち向かっているかのようにもみえます。開発標準のない組織には、系統だった組織的な教育の提供は望めないからです。

　また有効な開発標準がない場合、組織にしてもソフトウェア開発で何か問題が発生しても、人頼り、場当たり的な対策に終始し、何かを本質的・継続的に改善する方向にはなかなか進めません。そもそも、改善の対象（工程や成果物）も効果も特定できないからです。

　かつてメインフレームやオフコン系のソフトウェア開発標準を策定し、普及させ、データを蓄積し、改善しながら活用していた組織は、少なからず存在していました。しかし、それらが何らかの理由により必要以上に形式化し、さらに開発技術の想像以上に速い進歩により形骸（けいがい）化し、現在に至っている――筆者は開発標準の現状を、大まかにそのようにとらえています。

2. 開発標準導入の課題

　ここまで書いてきたとおり、筆者が考える開発標準についての現状は、次のようなものです。

「現場に有効な開発標準を提供している組織は、それほど多くない」

　開発標準の必要性についての筆者の考えは前回の記事を参考にしていただくとして、開発標準導入の阻害要因と、その対応の簡単なスタートポイント（ヒント）を考えてみたいと思います。

　その前に、有効な開発標準が提供できていない組織についてもう少しブレークダウンすると、大きく以下のように考えられるのではないかと思います。

（A）最初から開発標準がない組織

（B）現在保有している開発標準が、現状に適合していない組織

　以下、それぞれについて検討してみたいと思います。

（A）最初から開発標準がない組織の場合

　前章で、メインフレームやオフコン向けの開発標準を持つ組織は少なくないと書きましたが、比較的新しい企業、小規模の企業や開発部門、情報システム部門では開発標準自体が存在していないところの方が多いのではないでしょうか。そのような組織では、「開発標準って何」というところや、「会社の文化やビジネスモデル上、開発標準は必要ない」と考えるところが少なくないように見受けられます。

　実際のところ、作業を標準化しにくい研究開発をメインに行う組織など、その業務形態上開発標準がなじまないところもあるでしょう。しかし、全体的に「開発標準って何」というような状況の場合、そもそも一度も標準化の必要性についてきちんと検討していない組織も少なくないように思えます。そのような組織では、まずは開発業務の改善という視点から、標準化し品質や生産性を改善できる作業はないか、検討するところから始めることが重要ではないかと思います。最初から開発業務全体での検討が難しい場合は、取りあえずはできる範囲から検討を始め徐々に広げていくことも1つの方策と考えます。

（B）現在保有している開発標準が、現状に適合していない組織の場合

　このような組織の場合、開発標準への不信感を持たれていることも少なくなく、上述のような組織以上に導入の壁が高い場合があります。その不信感は、開発標準の内容的な不適合、位置付け、運用体制や利用方法、利用による効果、普及教育活動などさまざまな要因で生じていると考えられ、中には根深いものもあるようです。特に「妥当性・有効性に疑問があっても、規則として開発標準に従って作業した」経験のある方々には、開発標準とは結局無駄な作業を押し付けるものというマイナスの印象が残り、以後ずっと不信感を抱き続けるという残念な結果に終わっているケースも少なくありません。

　同時にそのような組織では、開発標準による恩恵も多かれ少なかれ享受（きょうじゅ）できていたはずです。工程や作業、体制、作業成果物のイメージ、それらの品質や生産性の大まかな指標の共有、新規要員教育計画作成の容易性などです。そのようなものを個々のプロジェクトや担当者で一から検討・対応しないで済むことや再利用可能なことによる負担の軽減は、担当者にとっても管理者にとっても歓迎すべきことと思います。そのため「現状に適合した開発標準が欲しい」という要望も潜在的に持たれていることも決して少なくないのではないかと考えています。

　このように、開発標準に対する不信感と期待がないまぜになっている組織の場合、まずは現在の開発標準の現状に対するFit-Gap分析を行い、何が現状に適合し、何が不適合なのかを洗い出すことから始めるとよいでしょう。この際、開発標準の内容そのものだけではなく、上述のような運用体制や利用方法、利用効果、普及教育活動等も分析の対象にすることを忘れてはいけません。

　ここまで、やや乱暴に分類して状況分析を行ってきましたが、実際にはこのような状況が複雑に絡み合っていることも少なくありません。

（C）開発標準導入の最大の障害？

　最後に開発標準導入において、現在最も大きな障害と考えられることを書いてこの章を終わりにします。

　それは開発標準導入に要する時間・要員とそれらから算出されるコストに対する認識です。開発標準導入は投資活動に相当するといえますが、それがどのように回収され利益を享受できるのか。組織としてそこを明確にできない以上、投資できないという視点があって当然といえます。その算出には、何がどれくらい改善されるかの定量的データが必要になりますが、開発標準が普及していない組織では、その基礎データ、つまり現状の生産性や品質に関するデータが蓄積されていることはまれで、「卵が先か鶏が先か」の議論に近いものがあり、なかなかすっきりとした投資効果の予測を立てるのは難しい状況にあります。

　だからといってまったく立案できないわけではありませんが、開発標準を行いたいと考えている方が予算権限者の承認を得る際に、この点が大きな障害になっていることも事実です。このような場合、分かりやすい短期的な投資対効果を求めて判断しようすると、なかなか開発標準導入が進まない状況に陥ることになるでしょう。

　少し視点を変えて考えてみると、ビジネスに関するあらゆる業務には、その競争力を高めるための改革・改善が必要ということは、第1回「プロの条件と開発プロセス」の記事でも触れたとおり、避けられない現実ではないでしょうか。その中でも特にビジネス上重要な業務、ライバルと激しい競争を繰り広げるような業務、あるいはそれらに深く関連する業務については、なおさらと思います。

　そういう意味で、ソフトウェア開発を主業務とする企業や部署においては、常にその改革・改善が求められているはずです。そこでは開発標準の導入や改善が、1つの大きな改革・改善項目の候補になることは明らかです。そのような視点に立ち、まずは上述のような状況分析から始めて、当面の目標を定めてできるところから活動から始めてみる方が現実的といえるかもしれません。

「こうすればできる開発手順の標準化」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ