2009年02月26日
ソフトウエアエンジニアとPowerPointの功罪
ソフトウェアエンジニアとして仕事をしている、といっても、最近はプログラムをガリガリ書くといよりは、意志決定をするために考えたり悩んだり、その内容を的確に伝えるためにメールや図を駆使したり、というスタイルが多くなってきている。
拡張性を考慮してモジュールを分割しやすくしておくか、パフォーマンス優先でコンパクトに仕上げるのか、どのような順序でプロセスが起動され、それらの間でどのようなデータがやり取りされるのか。
こういった設計思想や意思決定を正しく伝えるには何らかの可視化が必須なのである。
目に見えないソフトウェアを目に見えるようにすること（ドキュメントを書くこと）がとても大切であることは、ソフトウェアに関わるすべての人が感じていることだろう。
そこで、よくつかわれるのツールのひとつがPowerPoint。
PowerPointは、本来、ビジネスプレゼンテーション目的として最適化されたツールである。
（ビジネスプレゼンのツールとしてのパワポに対する功罪を問う意見も多いが・・・。）
ところが、ソフトウェア設計の現場でも、お絵かきツールとしてPowerPointが使われることは、私の周りをみても非常に多い。
会議室でスクリーンに映してシェアしやすいだとか、箱と線がカラフルに色づけられて、直感的に配置できて、そもそも書きやすいだとか、アニメーションがないと・・・とかいろいろな意見があると思うし、私もよく使っているのだけど。
だけど、ソフトウェアの設計をPowerPointで表示するのには、相当な注意が必要なことを認識しないといけない。
上でも述べたように、ソフトウェアは本来目に見えないもの。
それを可視化するために、たとえばUMLのように、設計者間で共通に理解が可能なコンテキストを用いて表現することが多いが、そもそもPowerPointではUMLが正確に書きづらい。
さらに多くの場合にはUMLでもなく、独自の表現手法で設計ドキュメントを各ケースも多い。
（UMLが良いといっているわけではなく、きちんと書き方が定められたUMLであってもPowerPointでは表現しづらいということ。）
正確に書きづらいと何がおきるか。
書き手だけが理解できる謎の表現で、いろんな色の箱や矢印を駆使して、それっぽい画を描き始めてしまう。説明されて初めてわかる、色による、線の意味の違いなどに出会うことは本当に多い。
その画はUMLのクラス図ようにも見えるかもしれないし、見方によってはソフトウェアコンポーネントの動的なフローを描いた画に見えるかもしれない。徐々に、ひとつの画に複数の概念と視点が混在し始めてしまう。
書いた人の近くで仕事をしている人は、その人の画のクセや、表現しようとしている内容やコンテキストをよく知っていることが多く、誤解なく意思が伝達できるケースが多いかもしれない。
しかし、ひとたびその資料がメールにのって、広がり始めると、その画は、さまざまな誤解と混乱を生むことは容易に想像できる。
書き手がきちんと凡例を書いて、視点（書きたいこと）を明確にして書くということも大切だが、やっぱりツールがそれを助長しているようではダメだと思う。
PowerPointは、そんなツールの一つではないだろうか。
PowerPointで設計の図を表現する場合には、その便利さの裏には、ミスコミュニケーションによる多くの時間の浪費があることを、しっかりと認識しておいたほうがよさそうである。
投稿者 orval : 2009年02月26日 23:01
トラックバック
このエントリーのトラックバックURL:
http://www.orval-net.com/mt/mt-tb.cgi/894
