“コラボラティブである”ために（1/2）

コラボレーションを支える要件

形式・関係性についてより少ない制約で共有できること

経験も専門性も異なる利害関係者が増えてくれば、おのおのが情報伝達に使う“言語”も異なります。UMLやBPMNに習熟した方もいれば、ポンチ絵でもいっぱいいっぱいの人もいます。Excelでリクエストをまとめ上げる人もいるでしょう。

また、彼らがシステムに対する期待値を練り上げていく過程で参考になる情報は、なにも社内だけに限定されるものとも限りません。外部のWebサイトがアイデアのもとになっているかもしれません。

「誰が何をどう考えているか？」を共有し理解することは、相互の意思疎通をより質の高いものにするために必要です。いいかえれば、各人が自分の考えをより素直に表現するために使う形式に関し、管理するシステム側から制約をかけることは望ましいことではありません（まぁ、技術的には“あらゆる形式”ってのは実現不可能なんですが）。

これらをただ貯めたところで、最終的には仕様として提示できなければ、開発サイドに提示することもできません。伝統的な要求管理モデルに従って枠にはめることよりも、アイデアの源泉とその詳細化の過程を結びつける関係性の管理についても、多重度や形式等の制約を極力少なくすべきです。つまり、「人が思考し伝達可能なものとして整理していく過程を、より少ない制約の元で支援し管理する」機能が必要です。

“文脈”を保存し共有できること

アジャイルなスタイルで顧客を巻き込むとか密なコミュニケーションとか言っているのは、「顧客にぴっちり脇についてもらって、その言うことに全部従う」ということではありません。頻繁に顔を合わせ議論を繰り返すことで、ビジネス的背景や利害関係者の期待値の変化、プロジェクトの状況をより深いレベルで理解し共有することに意味があります。それにより、各自が主体的に適切な判断を下し実行できるようになることを狙っています。

プロジェクトの決定事項だけを管理するのではなく、その決定のもととなった背景情報や議論の過程を含めていわば自分たちの置かれている文脈を共有することが重要です。このためには、「承認された決定事項」に加えて、背景となった議論を蓄積する掲示板やWikiとの統合や、チャットやコメントによるバーチャルな会議室の機能が必要になります。

無用な“待ち”を排除して短時間化

リアルタイム性を高めること

これまで組織の情報共有の仕組みは、俗にALMと呼ばれるカテゴリーの製品で実現されてきました。しかし、その使い方を見ると、「決まったことを管理する」であり、成果物の関係性を管理することで、「進捗状況」や「網羅性」を把握するということに大きなポイントがありました。

これがアジャイルなスタイルになると、従来のような「時間をじっくりかけて検討した結果を実装する」というアプローチから、「意見交換→コードによる実装→フィードバックのサイクルを短時間で繰り返す」というアプローチへの転換が必要になります。このような環境では、「週に1度の仕様検討会議」などは、プロジェクトを間延びさせる要因でしかありません。

関係者への情報一斉通知や、自分がかかわる作業に対する変更やリクエスト等は、それが発生し次第できるだけリアルタイムに通知され、アクションを取れるようになるスピード感が必要不可欠です。情報を蓄積するだけではなく、それを利用して共同作業をする人と人とのかかわる速度を速めるような機能が求められるようになります。

次回は開発者間のコラボレーションに焦点を当てましょう。