プロジェクト内外のコミュニケーション
プロジェクト内外のコミュニケーションについては、いろいろと言い尽くされている感があります。
その割には、みんな「まだまだ問題アリ」だと思っていますよね。それがどこのプロジェクトにおいても現実のような気がします。
プロジェクトの反省会をやると、
「コミュニケーションが足りませんでした」
はかならず出てくる反省点の一つです。
—-
当然ですが、ただ指をくわえてみているだけではなくて、プロジェクトマネージャやプロジェクトリーダーたちは様々な手法をこらします。
例えば、オフショア開発の場合には、そこを強化するための「ブリッジSE」がいるのが普通で、彼らの出来がプロジェクトの行く末を大きく左右します。これもコミュニケーションをうまく通すための一つの方法です。
また、マーチン・ファウラーがアジャイルソフトウェアプロセスを使ってオフショア開発なんかで書いているような、
オフショア開発でなくてもコミュニケーションはとても重要で、これができていないチームにかかると、
「結合してみたら動かない」
なんていういのはまだかわいいほうで、
「どうしてこんなにとんちんかんなソフトウェアを作っちゃうの？」
とか、
「もう引き返せないんだけど、どうするの？」
というような、「後の祭り状態」になるなど、本当に大変な目にあいます。
—-
こういう失敗の一つの理由として、
「前提となる用語定義が、あいまいだったり不足したりしているために起こる、コミュニケーションのズレ」
が挙げられます。
こういうことに対する処方箋が、DomainDrivenDesignの「Ubiquitous Language（ユビキタス言語）パターン」です。
DDD難民に捧げる Domain-Driven Designのエッセンスでは、このように要約されています。
● Ubiquitous Language（ユビキタス言語）パターン
ドメインを正しく捉えた柔軟で価値の高いソフトウェアを設計するには、チームの共通言語を創造しなければならない。共通言語はユーザ、ドメインの専門家から、設計者、プログラマまで、分析／設計モデルからプログラムコードに至るまで、プロジェクトのすべての関係者、成果物に行き渡っていて、同じ意味で理解されるようなユビキタス（遍在的）な言語である。ドメインモデルがユビキタス言語となるようにし、ドメインモデルを介してプロジェクトが一体となるようにする。
よく世間でいう「ユビキタス」は、世の中で「意識しないうちにそこにあって、それを利用できる状態」を言います。
DDDでいう「ユビキタス言語」は、様々なドメインについての理解がチーム内外にいきわたることを指しています。そして、それをコミュニケーションの前提とすることで、コミュニケーションが楽に深まり、プロジェクトに一体感をもたらします。
—-
とはいうものの、こういうことは、相当意識して行わないとなかなか行えるものではありません。実際には、「プロジェクトを継続していくつかやっていくうちに、ようやくできてくる」といった感じが普通ではないでしょうか。
また、それだけ時間がかかっているからこそ、今まで作り上げた「ユビキタス言語」を理解して分かってくれる開発プロジェクトにはまた次の依頼がくる、という図式になっていきます。
実はここをうまくショートカットして構築できると、少ない時間で長い間慣れ親しんだようなチームができあがる（はず）だと考えています。
このあたりも、system-enablersの課題として考えていくつもりです。
コメントはまだありません。