ソフトウェア開発におけるウェブベースのコミュニケーションにモデリングを導入する
ここ数年、WikiやBTSの機能を備えたオープンソースの開発支援ウェブアプリケーションが増えてきました。サーバを一つセットアップすれば専用ツールの準備が必要ないこともあって、ソフトウェア開発における課題や成果物（外部設計、内部設計、ソースコードなど）などを共有する目的で導入も進んでいるようです。
一方、UMLのようなモデリング言語が成熟してきたことを受けて、エンジニア同士で設計意図を共有するためにモデリングが行われるケースも増えてきました。小さなプロジェクトでは、UMLのようなモデルは議論の途中で作成される中間成果物的な扱いになることもありますが、大きなプロジェクトでは、成果物となる仕様書にUMLを含めるケースも多くあります。
また、オフショア開発の広がりの影響を受けて開発拠点が分散することが増えてきたことや、オープンソースプロジェクトのように開発拠点を一カ所に集めない開発スタイルが出てきたことから、情報共有の助けとなるウェブアプリケーションやモデリングの必要性は高まりつつあるようです。（もっとも、単一の開発拠点でも、配置の容易さからウェブアプリケーションが選択されるケースは増えています。）
まとめると、今のソフトウェア開発では以下のような流れがあると言えます。
- ソフトウェア開発を支援するウェブアプリケーションの普及
- モデリングの普及
- 開発拠点の分散
一方、モデリングツールも成果物の作成を重視しながら独自の発展を遂げてきました。一般的なモデリングツールは、スタンドアロンで動作し、オフィスツールや統合開発環境との連携機能やきれいな図を作成するためのユーザインタフェースなどを特徴としています。
こうしたモデリングツールはソフトウェア開発において重要な役割を果たしており、成果物を作成する上では有用なものです。しかし、モデリングはコミュニケーションツールでもあるわけですが、コミュニケーションを支援する機能は、サーバによる共有やリアルタイムの連携などいくつかの機能が実験的に実装されてはいるものの、まだまだ未発達な状態にあります。
こうした状況を踏まえて、筆者は2006年度下期未踏ソフトウェア創造事業にて、ウェブというコミュニケーションツールとの相性にフォーカスをあてたKodouguというモデリングツールを開発しました。本記事では、このKodouguの紹介をします。
開発拠点の分散に見られるコミュニケーションパターン
Kodouguの紹介に入る前に、まずは開発拠点が分散したときによく遭遇するコミュニケーションのパターンを、特に成果物のレビューにフォーカスをあてていくつか紹介します。
出張による対面ミーティング
開発拠点が分散している場合、離れた拠点に出張してミーティングを行う場合があります。プロジェクト初期における重要な判断が必要な場合、トラブルが発生した場合などによく発生するパターンです。また、定期的に出張を行う場合もあるようです。
ミーティングの形式は単一拠点開発時のミーティングとあまり変わりませんが、出張時にミーティングを効率よく進めるために単一拠点開発時と比較すると会議を強くコントロールする場合があります。
このやり方のメリットは、対面ということもあって密度の高いコミュニケーションが可能であることです。デメリットは、出張コストが高いことが挙げられます。
メール
開発拠点が分散していて、プロジェクトのスタートアップ時など、VPNのような環境がまだ整備されておらず、あるいは共有の構成管理システムが立ち上がっていない場合によく発生するパターンです。何らかの事情でVPNを立ち上げることができない場合や開発環境を整えない小さなプロジェクトにも発生します。
オフショア開発であれば、海外の開発担当から、該当となる成果物のファイル（Excelやモデルファイル）をメールで送付してもらいます。日本でその内容をレビューして、その結果をメールで返します。レビュー記録を残す場合は、専用のファイル（Excel）などを作成します。
このやり方のメリットはすぐに始められることです。デメリットとしては、メールで開発中間成果物を共有するというやり方が非効率という点と、最新版を取り違えてトラブルになる可能性があるという点が挙げられます。また、メールを記録として残す仕組みを構築しないとやはりトラブルの原因となる可能性があります。
プロジェクトのスタートアップ時など、開発環境が整っていない時期に過渡期的に出現すべきパターンです。あるいは、規模があまりにも小さい場合もこのやり方を取るケースが多いようです。
このパターンは、VPNのような環境が整備されるようになって構成管理システムを分散した開発拠点で共有することができるようになれば、問題点をかなり改善することができます。この場合、作成された成果物とレビュー記録は構成管理に格納し、レビューの開始や完了などと言ったイベントの発生をメールによって伝えることになります。構成管理システムへのコミット時に送信されるコミットメールを使う場合もあります。
電話会議
開発拠点が分散していて、重要な設計判断を行う場合に発生するパターンです。ただし、電話会議は進捗会議にはよく使われますが、レビューにはそれほど多く使われないかもしれません。
Skypeなど何らかの方法を使って開発拠点を電話でつなぎ、それぞれの場所で仕様書やモデルなどを見ながら口頭でレビューを進めます。多くの場合開発担当側に記録係を置いて、議事録・レビュー記録を作成します。
このやり方のメリットはレビューにおいて多くの情報を伝えることができることです。デメリットとしては、通訳を介す必要がある場合（開発拠点によって言語が異なる場合）、そこがボトルネックとなって時間あたりに消化できるレビュー量が限られてしまうなどの問題があります。
ウェブアプリケーション
開発拠点が分散していて、VPNのような比較的セキュアな環境が整っている場合、もしくは開発成果物をインターネット上に配置しても問題のないオープンソースプロジェクトなどで発生するパターンです。また、このパターンが発生するケースでは、WikiとIssue Tracking System（課題管理システム）と構成管理システムを統合したRedmineやtracのようなウェブアプリケーションを併せて導入しているケースが多いようです。
Redmineやtracのようなウェブアプリケーションには、課題管理やWikiといった機能的な特徴以外にも、次のような特徴があります。
- 成果物をウェブ上で共有
- それぞれの成果物をリンクでつなぐことによって追跡可能性を確保
- コミュニケーションパスの一つとして利用可能
外部設計・内部設計・レビュー記録はWikiに記述するケースと、Excelなどのスタンドアロンアプリケーションで作成してから構成管理システムに格納するケースがあるようです。
このやり方のメリットは、共有が容易であること、課題から成果物までの追跡可能性を確保しやすいこと、Wikiにレビュー記録を残す場合は、記録として残しやすいことと後から閲覧しやすいことなどが挙げられます。デメリットとしては、ウェブアプリケーションに搭載されている個別のツール（文書作成ツールとしてのWikiなど）は、スタンドアロンの専用アプリと比較するとユーザビリティがやや劣る場合があることなどが挙げられます。
たとえば工数管理などは、tracでもプラグインをインストールすれば可能ですが、Excelなどのツールにユーザビリティが及ばないため、tracとExcelを手動で同期させながら併用するということもあります。
組み合わせ
言うまでもないことですが、ここで挙げたパターンが全てではありませんし、これらのパターンは単独で発生することはあまりなく、同時に複数のパターンが出現することが普通です。また、プロジェクトのフェーズに応じて利用するパターンが変わってくることもあります。
総じて言えば、メールを使うパターンはプロジェクトの成熟とともにウェブアプリケーションを使うパターンに移行していくものです。ただし、ウェブアプリケーションを使ったパターンに移行しても、メーリングリストのようなものは維持され廃止されることはまずありません。また、電話会議を使うパターンは必要に応じてどのフェーズでも登場し得るものです。
モデリングツールによる解決
さて、ソフトウェア開発におけるモデリングの目的は「コミュニケーション」と「成果物作成」と言うことができます。モデリングツールはモデリングをどのように支援してくれるのでしょうか。
よく利用されるスタンドアロン型のモデリングツールは、コミュニケーションの場に対して同程度の距離感を保ちながら、成果物としての図を作成することに最適化されています。たとえば、設計ミーティングの際に、モデリングツールはホワイトボードと比較すると使い勝手が劣ります。設計ミーティングが行われる場合にモデリングツールが使う場合は、以下のような流れになることが多いです。
- 設計ミーティングでホワイトボード上にラフなモデルを作成する
- ツールで清書する
- 仕様書もしくはWikiに貼り付ける
つまり、よく使われるモデリングツールは、コミュニケーションでモデリングをしてからツールでモデルを清書する、もしくはツールでモデルを作成してからコミュニケーションの場（レビューなど）で検討を行うというような使い方がなされます。また、統合開発環境との連携機能を持つツールの場合は、コーディング時に同時にモデリングを行うこともできますから、総じて一人で作業をすることに最適化されています。
こうしたスタンドアロン型のモデリングツールのメリットは「美しい図を作成できること」「使いやすいこと」「（UMLなどのモデリング言語なら）文法的に正しい図を作成できること」です。サーバを持つモデリングツールの場合は、前述のメリットに加えて「モデルの蓄積と共有」や「バージョン管理」などと言った機能を使うこともできます。
こうした使われ方以外に、モデリングツールは個人的に思考を整理するために利用される場合もあります。つまり、仕様書にUMLを使うことが求められていない場合でも、個人的にモデリングツールを使って設計を整理する人はいるということです。このような場合にもスタンドアロン型のモデリングツールは力を発揮します。
デメリットは、ツールがコミュニケーションから離れてしまうことです。モデリングの目的の一つは開発メンバー間のコミュニケーションである以上、コミュニケーションが終わってしまった後に清書用として使用するというのは残念なことです。もちろん残すことに意味はありますが、時にはモデルが厄介者扱いされてメンテナンスされなくなり、実情とかけ離れたものになってしまう場合があります。
Kodouguとは？
Kodouguとは、ブラウザ上で動作するモデリングツールです。従来のモデリングツールのように仕様書に掲載するモデルを作成する機能に加えて、ウェブアプリケーション上で行われるコミュニケーションの場に近いところでモデリングを行えるように工夫しています。
クライアントはFlashで動作するため、ブラウザ（IE/Firefox/Safari）とFlashプラグインがインストールされていれば、専用のツールをインストールすることなく利用することができます。
図1「ブラウザ上で動作するモデリングツールKodougu」
また、Kodouguは複数人で一つの図を同時に編集できるように設計されています。Cometと呼ばれる技術を用いているのですが、誰か一人が図を変更すると、その変更内容がその図をブラウザで開いている人全員に通知されます。チャットやインスタントメッセンジャーなどと併用しながらモデリングを複数人で行うことを想定しています。
Kodouguは小道具
Kodouguの名前の由来はもちろん「小道具」から来ています。システム開発ではツールに目を向けるだけでも、ドキュメント共有（Wikiなど）、課題管理、統合開発環境、Officeツールなどさまざまなツールが存在しており、見ようによっては全てのツールが「自らは主役」と主張しているように見えなくもありません。
システム開発はドキュメント駆動開発であり、モデル駆動開発であり、チケット駆動開発（前述のtracでは、課題をチケットという単位で管理するためこのような名前がついている）であり、動作するソースコードはもちろん中心です。
本当に何が主役になるかは状況によって変わってくると考えられます。Kodougu自身はブラウザ上で動くモデリングツールに過ぎず、その主となる目的はコミュニケーションを手助けすることです。従って、Kodouguは主役となるツールと併用するための便利な「小道具」であることを目指しています。
trac/pukiwikiに組み込む
Kodouguの魅力はさまざまなウェブアプリケーションに組み込むことができることです。とりわけ、ソフトウェア開発現場で人気のあるtracやpukiwikiには簡単に組み込むことができます。
Kodouguをtracに組み込むには、Kodouguを組み込むためのプラグインを使用します。プラグインをtracにインストールして、wiki上で「[[Kodougu(/u/username/diagram/tool/ID)]]」というような記述を行うことで、以下のようにモデリングツールをtracに組み込むことができます。
図2「trac（Trac Lightning）に組み込まれたKodougu」
Kodouguはtracと同様、pukiwikiにも簡単に組み込むことができます。Kodougu用のプラグインをインストールして、wikiに「#Kodougu(id)」というような記述をすることで、以下のようにモデリングツールをpukiwikiに組み込むことができます。
図3「pukiwikiに組み込まれたKodougu」
Googleガジェット
広範なアプリケーションに組み込めるように、Googleガジェットにも対応しています。以下のようにGoogleガジェットに対応したサイト（以下の例ははてなダイアリー）に貼り付けることができます。
図4「はてなダイアリーに組み込んだKodougu」
Eclipseに組み込む
まだ実験的に検討されている機能ですが、ブラウザを内蔵した統合開発環境であれば、ウェブアプリを組み込んで使うこともできます。
図5「Eclipseに組み込んだKodougu」
Kodouguの利用シナリオ
Kodouguを使うとどのような開発が可能になるのか、紹介します。
ウェブアプリケーションを利用したシステム開発
プロジェクトによって採用できるツールは異なりますが、開発環境をウェブアプリケーション化するとどのようになるのでしょうか。ウェブアプリケーションを活用すると以下のような作業をウェブ上で行うことになります。
- 仕様書作成（Wiki）
- 課題共有・バグ管理
- マイルストーン管理
- ソースコードをウェブ上で閲覧・構成管理
- ビルドレポートの共有
また、私が過去に参加したプロジェクトでは以下のような環境もそろえました。
- ブログによる情報共有
- RSSによるプロジェクト内の新着情報の配信
- タギングによる情報整理
- プロジェクト内情報の全文検索
- 議事録の蓄積
- ML記録の参照
情報の閲覧/共有、中間成果物の作成、対面などで解決されるものをのぞいたコミュニケーションに関わるほとんどの部分が、ウェブアプリケーションで共有されました。コーディング・清書/印刷が必要になる成果物・モデリングはスタンドアロンで動作するツールを利用しました。
このプロジェクト実施時はまだKodouguが存在していなかったため、モデルの扱いに悩みました。Wiki上でカジュアルに仕様について議論しているときに、図を貼り付けると意見交換には大変有益です。しかし、既にレビュー済みの確定した図を貼り付ける場合はそれでも構いませんが、そうでない場合、図に対する指摘などを即座に反映する方法がありません。
つまり、ツールで修正して貼り付ける（貼り付けるという手作業をある程度自動化することはできますが）という作業が必要になります。結局、この一手間が障害となって文字ベースの議論に終始し、モデリングは積極的に活用されないことがあります。（というよりは、多くの現場では、モデリングは仕様書を飾る以上に利用されていないのが実情と思われます。）
こうした開発では、Kodouguを導入すると、Wiki上で議論とモデリングを継続して行うことができるようになります。基本的に文字ベースの議論を行っているところに、状況を整理するためにモデリングを導入することができます。Kodouguの図はPNGで出力することができる（画像にもURLが与えられる）ので、議論が収束したらWord/Excelなどの仕様書に貼り付けると良いでしょう。
また、Kodouguの図は凍結することができるので、レビューが完了した図は凍結して編集不能にすることができます。仕様変更などでモデルを変更する必要がある場合は、モデルの所有者は凍結を解除する権限があるので、モデルの所有者が凍結を解除してモデルの修正を行えるようにします。
TwitterやWassrを利用したモデリング
最近、TwitterやWassrのようなミニブログが流行しています。カジュアルなモデリングを行う場合は、Kodouguとこうしたミニブログは相性がよいようです。私もたまに行うのですが、モデリングのテーマを決めてTwitter上で募集をかけます。人数が集まってきたら、各人がモデルに手を加えながら、Twitterでコメントをやり取りしつつ、モデリングを進めていきます。あまり時間をかけすぎないようにしつつ（長くても一時間以内が望ましいです。可能なら15分から30分程度に抑えましょう。）、議論を収束させて図を完成させて共有します。
こうしたカジュアルなモデリングは、インターネット上で行うのが普通ですが、ある程度の人数がいる企業であれば、企業内で部署横断的な交流としてモデリングを行うこともできるかも知れません。もちろん、情報をインターネットにばらまくわけにはいかない場合もありますから、Twitterのようなミニブログの機能を備えた社内ツールを準備すると良いでしょう。
Kodouguのメリットとデメリット
Kodouguには、一般でよく使われているスタンドアロン型のモデリングツールと比較すると以下のようなメリットがあります。
- 専用のクライアントツールをインストールする必要がない
ブラウザとFlashプラグインがあれば動作するため、特別なツールをインストールする必要がありません。開発者は、モデリングツールのバージョンを気にする必要も無くなるので、開発環境の管理が楽になります。 - スケーラビリティが高い
Kodougu自身は通常のウェブアプリケーションと同じアーキテクチャで実装されています。つまり、ステートレスなアプリケーションサーバとデータベースで構成されていると言うことです。（Cometを利用する場合は、Cometサーバも必要です。）
従ってKodouguは、通常のウェブアプリケーションと同じく、アプリケーションサーバやデータベースのサーバを増やすことでスケールさせることができます。これは大規模プロジェクトや、業務の効率化のために全社で統一した開発環境を構築する場合などにも利用できると言うことです。 - ウェブアプリケーションと統合できる
具体的に言えば、Kodouguはiframeを利用すればどのウェブサイトにも組み込むことができます。現在、Kodouguにはtrac/pukiwikiに統合するプラグインが準備されていますが、他のウェブアプリケーションにも容易に統合することができます。 - モデルの管理が行いやすい
Kodouguのモデル情報はサーバで一元管理され、全ての図/モデルにURLが振られます。これにより、ファイルをやり取りすることによる取り違えなどのトラブルを抑えることができます。モデルを見せる場合もURLを送付するだけです。また、モデルを凍結する機能（編集不能にする機能）やモデルの公開／非公開設定を行う機能が有り、必要に応じてモデルの編集制限や不可視かを行うことができます。
Kodouguには一般でよく使われているスタンドアロン型のモデリングツールと比較すると、以下のデメリットもあります。
- オフラインで動作させることが難しい
Kodouguはサーバ上で動作しますから、スタンドアロン型のモデリングツールと比較するとインストールに手間がかかります。ローカルで使う場合には導入に手間がかかります。 - ユーザビリティが一歩劣る
ブラウザやFlashの制約から、「使えるショートカットに制限がある」「コンテキストメニューが使いにくい」など、図を作成する機能に関するユーザビリティは劣る面があります。これは、ウェブと統合することによってえられるユーザビリティとトレードオフの関係にあると言えます。 - レスポンスが良くない
回線の品質に影響を受けますが、サーバとブラウザが通信をする以上、スタンドアロン型のモデリングツールと比較すると、レスポンスが劣る場合があります。
Kodouguは万能のツールではありません。メリットとデメリットを検討して採用するかどうか判断すると良いでしょう。
Kodouguが対象としないもの
今のところ、Kodouguが対象としていない機能は以下の通りです。
- ソースコードからのリバースエンジニアリング
- ソースコードの生成（フォワードエンジニアリング）
ソースコードからのリバースエンジニアリング
実際のプロジェクトでは、ソースコードの粒度に限りなく近いクラス図やシーケンス図を成果物として要求されることがあります。このため、ソースコードをリバースエンジニアリングして、UMLの図を自動生成する機能を持ったモデリングツールは多数あります。
納品物の一部としての必要性はともかく、仕様書としての価値を考えれば、ソースコードの中身をそのままなぞった「図」はそれほどの価値を持ちません。ソースコードをそのままなぞった図は、往々にして複雑で詳細な内容になりがちです。
詳細かつ複雑な情報を閲覧する場合はソースコードもしくは文章のような文字ベースで閲覧する方が、効率が良いと考えているため、Kodouguはリバースエンジニアリングによって図を生成する機能は対象外としています。
ソースコードの生成（フォワードエンジニアリング）
ソースコードを生成する用途があると言うことは、図にソースコードと同等の情報を含めると言うことになるので、リバースエンジニアリングを対象としていないことと同じ理由からKodouguでは現在は対象としていません。
ただ、ソースコードのリバースエンジニアリングとフォワードエンジニアリングに関しては、Kodouguとしては「推奨しない」という姿勢を保っているものの、「これらの機能がなければ実案件で利用できない」ということもあり得るため、要望が多ければこうした機能を実現するAPIの解放などを検討したいと考えています。
Kodouguを利用するには
Kodouguは最終的にはpukiwikiやtracのようにLAN上にインストールして利用するパッケージの提供をしたいと考えていますが、現状は内部の変更が激しくモデルデータの互換性などを維持しがたいという理由から、敢えてインストールパッケージは提供せず、www.kodougu.netサーバのみで運用されています。
従って、現状でKodouguを利用するには、公式サイトにアクセスしてユーザー登録する必要があります。
また、本記事では、Kodouguのウェブブラウザ上で動作するモデリングツールとしての側面から紹介しましたが、Kodouguはその他にもさまざまな機能を持っています。さらに詳しく知りたいという人は、ウェブサイトを参照してください。
著者について
黒田 洋介（フリーランス、八角研究所技術顧問）：ソフトウェアエンジニア。2006年度下期未踏ソフトウェア創造事業にて、「Web上で動作するモデリング環境Kodougu」というテーマで採択され、開発に参加しました。
ものづくりを支援するシステムに強い興味を持っており、現在は、ものづくりにおけるコミュニケーション支援と生産性向上の実現を目指す「Kodougu」と、ソフトやコンテンツ開発で問題となりやすい著作権の派生を追跡するシステム「コピトレ」の開発に従事しています。