失敗しないビジネス開発のために |
福岡寿和 FUKUOKA，Toshikazu 富士通SSL
Visual Basicでチーム開発を行なうときに問題になってくるのは、コードをどのように共有するのかということです。根拠があるわけではないのですが、マイクロソフトはVisual Basicを、チーム開発が必要なような大規模開発に使われることを想定しなかったフシがあります。そして、日本でVisual Basic 2.0が大規模開発に使われるようになったのを受けて、Visual Basic 4.0やVisual Basic 5.0のEnterprise版では、チーム開発をフォローするための機能やツールが添付されてきたような気がします。
今回は、もちろん、Visual Basic 5.0でのチーム開発をフォローするための機能やツールについても記述しますが、私がVisual Basic 3.0（Visual Basic 2.0という、障害が多く日本以外ではきわめて短命なバージョンは業務開発ばかりか、趣味としての開発でも使っていません）から使っているチーム開発の手法を中心にご紹介します。
| Windows時代のチーム開発のスタンス |
|---|
Windows時代のチーム開発では、今までのチーム開発とどこがどのように違うのでしょうか。それは、Windowsという発展途上で変化し続けているプラットフォーム上で開発しなければいけないことが影響しています。
通常、設計担当は、プログラミング担当を経て、顧客の業務内容に精通したり、また、顧客との交渉方法を身につけた人がなります。しかし、Windowsをプラットフォームにしたときは、プログラミングを担当したころと、設計を担当するころの技術で異なることが多く、過去の経験だけでプログラム仕様を決定すると失敗することが多いのです。これからの設計担当は、いままでのように、顧客から仕様を聞いて、処理方式を決め、進捗を管理していればよいということはないのです。チーム開発を念頭に置くのならば、「やりたい方法」を考え出すのではなく、「やりたいこと」を顧客から聞き出すのが設計担当の役目だといえるでしょう。チーム開発であればこそ、すべての技術を隅から隅まで精通する必要はありません。開発担当が精通していればいいのです。つまり、設計担当は、顧客と顧客の言葉で「やりたいこと」を話し合い、同時に開発担当と技術用語で「実現する方法」を話し合い、頭の中で現実をモデル化することが役割になります。
設計担当の役割に変化があったように、開発担当の役割もWindows開発では変化します。つまり、いままでのように設計書に書かれた方法でモノを作り上げられることが開発担当に求められる技術ではなく、設計担当がモデル化した「やりたいこと」を正しく理解して、モノを作り上げてゆくことが求められる技術です。つまり「やりたい方法」を見つけ出すのは、ほかの誰でもなく、開発担当の役割です。また、設計担当から下りてきた設計書を検討して、その結果を設計担当にフィードバックすることも必須の作業です。
しかし、現実にはこのような役割分担が正しく機能しないことが多いようです。これは、開発担当が成長すると設計担当になるという考え方が原因でしょう。設計担当と開発担当は、チーム開発における両輪なのです。どちらが上でどちらが下というような同じ土俵で優劣が決まるような関係ではないことに注意すべきです。
さて、さまざまなスキルの人が集まって開発するのがチーム開発です。しかし、チーム開発が成功するためには、
-
a）全員がある程度のスキルをもっている
b）誰か1人がスキルをもっている
のどちらかのスキルパターンが必要です。
もし、全員がスキルをもっていないときには、スキルアップが必須です。しかしチーム開発なのですから、スキルの種類を分類し、その分類ごとに人を割り当て、分担してスキルアップを図るのがよいでしょう（パターンbの変形）。
つまり、開発に必要なスキルがないときは、ウォーターフォール型でもスパイラルフロー型でも開発工程を少し考え直さないといけないでしょう。なぜなら、現在の開発工程では、事前にハードウェア構成やソフトウェア構成が決定されていることを前提にしています。確かに調査工程が必要なときもありますが、これはあくまでも業務知識の調査を行なう期間です。また、サンプルプログラムやプロトタイプをつくることもありますが、スキルがないときには、事前に決定した構成の調査や学習期間であったりします。これでは、事前決定された構成に誤りがあったとき、後々になって「動かないシステム」もしくは、よい場合でも「動くけれど使えないシステム」になってしまう可能性が高くなります。
全員のスキルがないときに「使えるシステム」をつくるためには、図1にあるように開発前提調査期間を別契約で取れればいいのですが難しいでしょう。そのようなときは、プログラミングからではなく、契約前の前提条件の整合性、実現性のチェックから外部スタッフの支援を仰ぐのが現実的です。確かに、よい人材が確保できない（下手をすると前評判と違う、期待外れの人材をつかんでしまう）かもしれません。多分、優秀な外部スタッフを探す労力と初めて開発前提調査期間を確保する労力は変わらないかもしれませんが、社内で育ちにくい人材が世の中に豊富にいるはずもないので、それは仕方のないことと腹をくくって探し回りましょう。
図1：開発工程
| 開発工程を考える |
|---|
チーム内にお手本となるプログラムが存在していることが、失敗の少ないチーム開発を実現するためのポイントです。そのために、開発範囲を管理できる範囲内にとどめて、ファーストリリースのサブシステムを早く稼働させ、実際に使っている人からのフィードバックをもらうのがよいでしょう。そのあとは、このファーストリリース部分をお手本にして、複数のチームがそれぞれ管理できる範囲内のサブシステムを担当して並行開発してもよいでしょうし、同じチームが次々にサブシステムをリリースしてゆく方法でもよいでしょう。1回の開発範囲内の工程は、ウォーターフォールでもスパイラルフローでもかまいません。自社や顧客、製品の特性にあわせて工程を考えてください。
このようにひとつのシステムをサブシステムに分割して、契約・設計・開発するのはなじみのない方法かもしれません。しかし、いままでの大規模開発でも、長期間の開発期間になるときには、中間納品として、設計書やソースプログラム、テスト結果および障害修正版プログラムを納品していたと思います。このような顧客を安心させるためだけの中間納品物の代わりに、実際に顧客が業務で利用できるサブシステムを納品すると考えるとどうでしょう。どちらのほうが本当に安心感があるでしょうか。実際に動くモノを提供するほうが安心感があるでしょうし、実際に業務で使うときの厳しい目にさらされて出てくるフィードバックこそ、次のサブシステム開発に役立つ内容になります。なお、1サブシステムの開発規模は、4人で4ヶ月あたりが妥当だと思います。人数を減らして期間が伸びたり、人数を増やして期間を減らすとバランスが崩れますので、12人月ではなく4人で4ヶ月が目安です。
|
自由な開発と規約のある開発 〜規約はチームのためだけではない |
|---|
チーム開発を行なううえで重要なことのひとつに各人が好きに開発するのではなく、チームで開発規約を決定することです。たとえば、命名規約の決定があります。これは慣れないうちは、かなり煩雑に感じるかもしれません。多少、規約に違反してもプログラムが動作すればいいじゃないのかと思うこともあるでしょう。また、コーディングするのが自分1人のときには、別に規約を決めなくてもよいと判断するかもしれません。
しかし、命名規約は、チーム開発や他人のためにあるのではありません。不思議に思うかも知れませんが、あなた自身のためにあるのです。たとえば、趣味でプログラムしているにしても、仕事でプログラムしているにしても、1本だけ仕上げたら終わりということはないはずです。しばらくしてから、同じようなプログラムを作成することになったり、バージョンアップすることになったり、一度完成したソースコードを見直すときもでてくると思います。そのときに、好き勝手にコーディングしていると自分が作ったものなのに、ロジックを理解するのに苦労します。命名規約に基づいて作業していれば、同じ目的の変数、関数、サブルーチンやオブジェクトは、直前まで作業していたものと、同じ名前になっているので、作った当時の記憶を呼び覚ますのが容易になってきます。
|
自由な開発と規約のある開発 〜VB命名規約サンプル |
|---|
Visual Basicの命名規約の基本は、LNC（Leszynski Naming Conventions）です。これは、
［接頭語］タグ［基本名］［修飾子］［接尾語］
という文法でオブジェクトを命名する規則です。接頭語、修飾子、接尾語は、任意指定です。LNCでは、基本名も任意項目扱いですが、タグとともに必須としたほうがよいでしょう。また、オブジェクト名はすべて英数字で表記して、先頭は必ず英字とします。英大文字と英小文字については、
［prefix］tag［BaseName］［Qualifier］［Suffix］
のようになります。たとえば、タグはすべて英小文字になります。
そして、オブジェクト名には、2バイト文字は使いません。これは、過去の経験からVisual Basicの仕様として2バイト文字を使うことができることになっていたとしても障害を誘発する可能性が高いからです。余談になりますが、Visual Basicの解説本の中には平気で2バイト文字をオブジェクト名に使っているものもあり、このような本が参考にされて、命名規約が決まってしまったらたまったものではないなと思ったことがあります。
なお、命名規約の適用対象としては、
- クラスモジュール
- フォームモジュール
- コントロール
- 標準モジュール
- プロシージャ
- 関数
- 変数
- 定数
- ユーザー定義型
があります。これらのオブジェクト名は、いったん本格的に開発に着手してしまうと、あとから変更するのはほとんど不可能です。たとえば、プロトタイプを作成するようなときから終始一貫して命名規約を適用してください。
接頭語（prefix）
接頭語は、タグをさらに詳しく説明した英小文字1文字で、適用範囲などを表わします（表1）。ひとつのオブジェクトに対して複数の接頭語を組み合わせて使うこともできます。表1：接頭語
| 接頭語 | 使用対象 | |
| c | 定数 | |
| （なし） | 変数 関数 サブルーチン |
|
| s | スタティック変数 | |
| スコープ | m | モジュール変数 モジュール定数 |
| f | フレンド関数 フレンドサブルーチン |
|
| p | パブリック変数 パブリック定数 パブリック関数 パブリックサブルーチン |
|
| a | 配列 | |
| i | カウンタ | |
| r | ByRef指定のパラメータ | |
| v | ByVal指定のパラメータ | |
表2：変数のスコープ
| スコープ | 宣言方法 | 有効範囲 |
| プライベート | プロシージャ内で宣言 | プロシージャ内だけで有効 |
| モジュール | モジュールのDeclarationsセクションでDimまたはPrivateステートメントで宣言 | モジュール内だけで有効 |
| パブリック | モジュールのDeclarationsセクションでPublicステートメントで宣言 | プロジェクト内だけで有効。ただし、フォームモジュールで宣言したときには、［フォームモジュール名］.［変数名］となる |
表3：関数、サブルーチンのスコープ
| スコープ | 宣言方法 | 有効範囲 |
| モジュール | Private Sub Private Function |
モジュールの中 |
| フレンド | クラスモジュールでのみ指定可能 Friend Sub Friend Function |
プロジェクト内だけで有効 |
| パブリック | Public Sub Public Function |
どこでも有効 ただし、Option Privateが指定されているときは、Friendと同等 |
表4：変数型・関数型タグ
|
表5：モジュールタグ
表6：プロシージャタグ
|
表1でスコープとあるのは、変数、定数、関数、サブルーチンがどこから使えるかを表わしています（図2・表2）。
なお、関数やサブルーチンはもともとモジュールの中で使うものなので、スコープの「m」を接頭語につけずに冗長性を削除しています。
図2：スコープ
タグ
タグは、基本名の特徴を表わした複数の文字であり、オブジェクト指向プログラミングでいうところの、クラス識別子になります。タグは、わかりやすさと将来の拡張を考えて、3, 4文字の長さで作ります（Microsoft Officeのオブジェクトモデルが将来拡張されるにつれ、新たに何百種類ものタグを作る必要がでてくる可能性があります）。タグは常に基本名の前につけ、すべて小文字で表記します。これは、基本名の先頭をわかりやすくするためです。
タグをつける利点は、
- プログラムが理解しやすくなる
- オブジェクトの種類でソートできるため、項目をクラス／プロパティ別に並べることができる
- フォームコントロールにタグをつけておくとコントロール名とコントロールの連結フィールドの参照との区別が明確になります
基本名
基本名の規則- 名前の中に空白文字を使ってはならない
- オブジェクト名の先頭は、英字または数字とする
- 大文字と小文字を使い分ける（可読性を上げるため）
- オブジェクト名は、複数形ではなく単数形とする
- オブジェクトの基本名には、そのオブジェクトの元となっているすべてのオブジェクトの基本名を含める（あくまでも可能な場合）
- 基本名を構成する要素は、読みやすさ、ソートを考慮して、左から右へ順に並べる
表7：コントロールタグ
|
|
