続：設計はUMLだけで済む

UMLだらけのプロジェクト名を仮にPJ-Uとしておきます。当初、私はPJ-Uに参加していて、SIerからの提案を現場で本当に使えるものなのか評価・判断する仕事をしていました。提案を受けた段階の感想と、実際のアウトプットを見せてもらった時の感想がここに書いてあります。それからしばらくして、共通基盤チーム(SIer)なるグループが作成したフレームワークと実装サンプルが届きました。その時の状況がここに書いてあります。

これらが前談です。じゃぁその後どうなったのか？本当にクラス図とシーケンス図とユースケースシナリオだけでプロジェクトは進んでいたのか？もちろんそんな事ありません。最初に出てきた資料が必要最低限なだけで、後になればなるほど、バラバラ資料が作成されていきました。プログラムを作成するために必要な資料ばかりではありません。プロジェクトの成果物として必要な物が多々作成されていきました。

めちゃくちゃ簡単に言うとPJ-Uで用意されている粒度がやたら細かい資料はユースケース図、ロバストネス図、シーケンス図、クラス図で、これに画面イメージ、入出力設計(IN/OUT)、ユースケースシナリオがあります。これだけで十分プログラムが作成できてしまうレベルです。PJ-UでのUMLは2段階を経て作成されていて、分析レベルフェーズと、設計レベルフェーズがありました。分析レベルのロバストネス図、シーケンス図、クラス図はメッセージが日本語で書いてあるもので、処理フローが分かります。普通はこのレベルで完結として、具体的命名はプログラマに任せる事もありますが、PJ-Uはもっと粒度を実装に近いレベルまで落とし込んだ設計書があります。それが設計レベルの〜図というもので、設計レベルのロバストネス図、シーケンス図、クラス図になると、具体的なパッケージ名、クラス名、メソッド名、引数の型まで書いてあります。シーケンス図にいたってはひとつの処理が最小レベルのメソッド単位まで落とし込まれていて、クラスの構造とメッセージのやりとりはそのまま写すだけじゃんというレベル。リバースしたのか、未来から持ってきたのか…粒度が非常に細かい。シーケンス図に登場するクラスは、もちろんクラス図によって、クラス名、フィールド名、メソッド名が決め打ちされています。

ユースケースシナリオ(と呼ばれているモノ)には作成するメソッド名から振る舞いまで詳細かつ具体的に書いてあります。例えば、処理で作成するFacadeのメソッド名、引数(DTO)、DTOへ設定する値の一覧が具体的に書いてあります。自然言語で処理内容が記述されていますが、これもとても分かりやすく書いてあり、すんなりとプログラムを作成する事ができます。DTOまでも設計段階で全て洗い出され、項目が定められていました。これだけの粒度のものがあれば、本当にUML+ユースケースシナリオで全て事足りますが、ほんとにプログラムからリバースしたかのような仕様書はそう書けるもんじゃないでしょう。そんな仕様書書く時間があるなら、プログラム書いて、リバースした方が効率が良い気がしちゃうくらいです。

ではそんだけのすばらしい仕様書が揃っているプロジェクト、どうやって開発しているか。PJ-Uはオフショア開発に出しています。中国の開発部隊を使って低コスト高品質を目指しました。中国に直接行った時の滞在記は過去の日記、中国滞在記１, ２, ３, ４にあります。それに関連してオフショア開発のコミュニケーションについてもレポートを書きました。コミュニケーションについて１, ２。今現在も開発中で、私の立場はブリッジエンジニアかと思いきや、既にプロジェクトの実作業から外れています。今現在、ブリッジエンジニアという明示的な立場を持った人はいません。あえて言うなら、メーリングリストがブリッジの役割を果たしていて、日本と中国の複数の担当者それぞれがブリッジエンジニアとなっています。わざわざブリッジしていなくて、もう相互にからみあってコミュニケーションを取っているので、ブリッジなんてイメージしなくても大丈夫です。勝手にメーリングリストで情報交換、コミュニケーションが展開されていますので、私が何かをしなくても、担当者同士で活発にコミュニケーションが取れています。それもこれも中国側の日本語能力が全く問題ないからできる事でしょう。非常に恵まれている環境だと思います。

メーリングリストは開設してから2ヶ月弱、既に437通のメールがやりとりされていて、尚もメールは飛び交っています。仕様書の間違い、質疑応答、障害報告、雑談。非常に情報の量が多いです。無駄な情報でなく、必要な情報の量なので全く無駄とは思いません。日本と中国でこれだけの情報交換ができるようになったのはとてもうれしい事です。プロジェクト発足時の音信不通状態が嘘のようです。今回のプロジェクトの大きな成果物のひとつとして、海外とのコミュニケーションをメーリングリストで行い、円滑にコミュニケーションができたというのもひとつとしてあります。このまま開発が続けば、きっと良い結果を収める事ができると思います。今回のプロジェクトの成功の秘訣は、やはり完成度が非常に高い仕様書の存在でしょう。中国からこんな事を言われています。「日本の仕事は技術的に難しい事は何もありません。仕様書が難しいです。」と。中国が言いたい事は、仕様書の書き方が下手で、読んでも理解できないって事です。仕様書の形式がUMLだったから成功なんていう事は無いです。ようは内容です。どんだけ実の詰まった正確で分かりやすい仕様書を書く事ができるか。今回はたまたまUMLだらけで仕様書が構成されていましたが、UMLがプロジェクト成功の決め手だとは思ってません。結局はUMLなんて図の書き方なんですから、重要なのは中身です。常に実装をリバースしたような精度で書けるとは限りませんが…っというよりそんなレベルで書ける方が少ない。設計者は身近に居て、飲みに誘えるのでその辺の秘密を今度聞いてみますか。別に秘密なんて無いでしょうけどね。業務内容を良く理解していて、ドリルダウンしていって、ちゃんと機能を細かい所へ落とし込んで、仕様書として完璧にアウトプットできている。あるべき姿というより、当たり前でありたい姿が実現できているだけでしょう。打ち上げには呼んでもらうとします(笑)