設計書ってなんだろう

設計書は何で書く必要があるのでしょうか。深々と考えてみると、意外にいろんなことが見えてくるし、いろんなことを伝えたくもなりました。

うれしはずかし授業開始

UML講師の初日。緊張もしましたが、和気あいあいと生徒さんともお話できたので、いい雰囲気で開始できたかな、と思っています。このような機会を下さったみなさんに、感謝申し上げます。

 今日の授業のテーマは、「なんでUMLを勉強するのか?」です。

エラそうに教える手前、私もここ1週間ばかり、深々と考え込んでしまいました。アイディアをくださったみなさんにも感謝します(これからもヨロシクね!)。


設計書

まず、UMLうんぬんの前に、なんで「設計書」が必要がなのでしょう?

「設計書の書き方」は、たいていシステム開発会社に入ったら、一番最初に学ぶものですよね。でも「設計書とは何か」なんてことは、学んだ記憶がないです。

  設計書とは何か、設計書とは何か、
   ・・・うむぅ、ノイローゼになる?

開発を経験していく中で「どういう設計書が良いか、うまくいくか」は、誰でも考えてることだと思います。その中でなんとなく、設計書の役割みたいなものは分かってくるとは思うのですが、なかなか言葉にはできないですね。

一応、自分が出した答えは書いてみますが、私なんかの意見を読む前に、一度ブラウザ閉じて、「設計書ってなんだろう」と、思いを巡らせてみてはいかがでしょう。




私の答え

設計書は、コミュニケーションツールです。

一人で設計してプログラミングするなら、設計書なんていらないですよね。他の誰かとコミュニケーションするから、設計書が必要なんです。

お客さんといっぱいお話をするための道具。かつ、プロジェクトメンバーとの物理的な会話を最小限にするための道具。

システム目標だけじゃなく、企業理念、戦略、自慢、悩み、飲み会、ゴルフ・・・とにかくいっぱいしゃべって、お客さんが考えてることを聞きだす。そのために、要件定義書があります。もっと前段階の、RFPなんてのもそうですよね。この場面で、無機質なゼロイチの世界の話をするエンジニアは、失敗します。

さて、開発がスタートしたら、会話は最小限に抑えなければなりません。上と矛盾してるように感じるかもしれませんが、そうではない。
駄弁ってばかりはいられません。動かすのは「手」です。10~100人のエンジニアに、一気に正確無比な情報を伝達しなければならない。この場面で、口をいっぱい動かしてるエンジニアは、失敗します。

だから、設計書を書くのだ。と私は思います。
そして、「コミュニケーション」というキーワードは、その設計書を書く必要があるのかないのか、吟味する基準にもなるのではないかと。

設計書かくの、大変ですよね

私も、ずいぶんと設計書や技術資料を書いてきました。

結構疲れますよね。深夜に「なんでこんなもん書いてるんだろーなー」なんて考え込んでしまったりすることもしばしば・・・。

   品質かんりー
   あいえすおー
   客が「とにかく書いて」と言うから書いた意味不明なしりょー
   体裁だけのせっけいしょー
    ・・・エトセトラ、エトセトラ。

そんなお疲れのときは、改めて、「なんで書くのか?」を考えてみたらいいんだと思います。

  誰のどんなことが聞きたいのか。
  誰のために何を伝えたいのか。

いろいろと勝手に考えてみればいいんです。それだけで、その設計書には血が通うはず。すると、結構やりがいがでてくる。考えたあげく、やっぱり意味がない場合は、徹底的に戦って、周囲の理解を得るべきなんでしょう。

んで、なんでUML?

そうこう考えてるうちに、UMLを覚えようとしたキッカケを思い出しました。


数年前、私がUMLなんて知らなかった頃、我々が設計書を書いて、インドの会社で開発してもらうプロジェクトがありました。

設計書は、すでに日本語の「文章」で外部仕様が書いてありました。それを英訳してインドに送って、「このとおりに作ってね」と。この英訳作業にも、たくさんの人件費を投入しました。

そして出来上がったモノは、外部仕様もバラバラ、クラスやインスタンスの構造がめちゃくちゃ、マルチスレッドでは動かない、メンテナンスもできない「ただのコードの塊」。そんなものが出来上がってしまったのです。

そのプロジェクトは、みごとに失敗しました。

インドや中国と、「もっとスムーズにコミュニケーションできないだろうか?」と考え始めたのが、UMLを本気で学ぼうと思ったきっかけでした。

そしていったん学んでみると、「伝える」ことがスムーズになったばかりではなく、驚くほど多くのリソース(文献、オープンソースなど)がサクサクと読めるようになりました。もちろん、国や言葉なんて関係なしに。「絵」ですからね。


最後にもう一度、

  誰と何を話したいのか。

それが分かれば、どういう設計書を書けばいいのかがわかる。別にUMLを覚えなくたって、効率よくコミュニケーションさえできればいいんです。

設計書、あたりまえのようで、そうではないですね。


コメント

コメントしてください

closed.