一緒に考える

前回は早い段階での平行作業は精度の低い成果物しか作られないことを示しました。
今回は共同作業も進め方によっては効果が高いことを示します。

作業は個人作業で行い「会議の場は作業結果の確認の場」というイメージがあります。
また、会議は時間の無駄、極力時間を短くする　ということが言われています。

私は会議が生産の場になる得ると考えています。
当然会議にもいろいろな種類があるので全ての会議を生産の場に変える必要はありません。

会議という言葉がそぐわないのかもしれませんが、会議室で関係者が集まって生産的な打ち合わせをしていても周りからは「長い会議をしている」と見られがちです。

「会議は短いに限る」と固定的に考えずにみんなで考えることの効用を検討してみるべきです。

要件定義の最初の段階では方向性や方針を決めることが重要です。
そのためには関係者が集まり、意識合わせを行い方向性を決めていく必要があります。

方向性とは、以下の各々の項目について合意を得ることです。

　どのようなしシステムにするのか
　今回の開発で大切なことは何か
　何を実現するとこのシステムは成功と言えるのか
　何処までやるのか
　〜〜

などの各項目について意識を合わせることが方向性を合わせることになります。

同時に方向性を決めていく中で、要件を決めるための基準が必要になります。
それが方針になります。

しかし、無から有を産むのは大変なことです。
何かしらのやり方を用いないと、とたんに混乱します。

要件をまとめていくための仕組みが必要です。その仕組みがRDRAにはあります。
つまり、RDRAで作成する各モデルにはつながりがあり、そのつながりを利用して進めていくことで要件定義に必要な情報をまとめられるようになります。
このつながりとそのつながりを使った進め方について合意が得られれば、それに従って混乱無く会議を進めることが出来ます。

次に問題になるのが「どのように一緒に考えるか」ということです。

議論の対象が形で表されることなく無く口頭だけで議論すると空中戦が始まって結局何も残らない、ということがよく起こります。

一緒に考えるためには参加者が議論するための明示的な対象が必要です。

その対象として図的表現が優れています。
これは昔からホワイトボードにイメージを書いて議論していたことを思い出していただければ容易に想像がつくと思います。

そしてその図的な表現形式の一つがUMLです。

プロジェクターでUMLモデルを表示しながら、その上で議論します。
モデルで表現しきれない場合はホワイトボードなどを使って議論し、議論が収束したところでプロジェクターに写したUMLモデルに反映します。
具体的な対象を使って議論することで焦点がはっきりし、結果を残すことが出来ます。
また、UMLの利点は表記上のルールがあり、それを使って簡潔な表現で複雑な意味を表すことが出来ます。

UMLに不慣れな場合でも図的な表現で議論することが重要です。

こうして図的な方法で意識合わせすることで、その会議に出席している人たちの中で共通の認識ができあがります。

この共通の認識を足場に議論を積み重ねることで一緒に考えることが容易になります。