「できるか！」な設計書に、どう立ち向かう？：システム開発プロジェクトの現場から（7）（2/2 ページ）

» 2007年10月04日 00時00分公開

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

不満の出ない設計書の作り方

　自分がシステムの設計を担当するようになったとき、かつて感じた不満をちょっと振り返ってみて、どうなっていたらそれほど不満を感じずにコーディングすることができたのかを考え、以下のような点に気を付けるようにしてみました。

仕様が決まっていない部分は「未決定事項」とし、「いつごろ決まるのか」と併せて設計書に明記する

　仕様が決まっていないのに、あいまいに記述して設計書を完成させた気になっても、何ひとついいことはありません。決まっていないことができた気になって、すっかり忘れてしまうのです。設計者もプログラマも……。そしてそのことに気付くのは、かなり後のフェイズになってからなのです……。

設計書には自分の「思い」をきちんと記述する

　設計とは、クライアントの「～したい」をどうしたら実現できるか考えることだと思っています。そこに自分の思いがなければ、「～したい」を実現する設計はできないのです。コピー＆ペーストの設計書では、思いは伝わりません。

アーキテクチャを理解して設計する

　アーキテクチャというあいまいな言葉を使用してしまいましたが、ここでいうアーキテクチャとは、「そのシステムを構築するうえで必要となるハードウェア、ミドルウェアを含むすべての基盤」です。

　それらを理解することで不満が取り除かれるというよりも、きちんと（概要レベルでもよいので）理解できていないと「アクロバティックな設計」になってしまうのかなぁと、しみじみ感じています。

シンプルな設計にする

　シンプルにすることが、もしかしたら一番難しいかもしれません。でも、複雑な要件もシンプルにできるレベルまで分解できたなら、テストしやすく、品質が高く、メンテナビリティも高いシステムが出来上がると私は信じています。

　難しいことを難しく書いても誰も理解できませんし、誤った伝わり方をしてしまうこともありますよね。

　私自身、複雑な設計をシンプルにまとめられたときには、かなりの自己満足に浸ります。

設計者の気持ち、プログラマの気持ち

　いろいろと勝手なことを書きましたが、実際に設計をするようになってから、設計者の苦悩というものも理解できるようになったと思っています。納期のプレッシャーがある中、ユーザーとの調整が難航したりすると、とにかく先に進みたくなってしまうものです。例えば早期にプログラマがアサインされてしまい、稼働率を上げたくなって、取りあえずの設計書でコーディングをスタートさせてしまおうという誘惑にかられることもあります。

　無理にでもフェイズを進めると、「進ちょく率が上がる」という数字上の評価もあって、ある種の安心感が出てしまうのです。後の工程で発生する障害・設計漏れの対応の方が、設計時につぶせるものの対応よりも圧倒的に工数がかかることは分かっているはずなのに……。

　そんな「設計する人」の気持ちと、「コーディングする人」の気持ち、両者の気持ちが理解できると、前向きな議論ができるようになります。そうしたら、結構楽しくなりますよね。

　ちなみにいまの私は、自社の関連会社の開発方法論とピアレビューというすてきな行いによって、この「立ち止まる勇気」を持って設計を行っています。まだまだ未熟ではありますが……。

筆者紹介

アクセンチュア・テクノロジー・ソリューションズ

新楽清高

1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス～要件定義～開発・テスト～運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。

「次回」へ

「システム開発プロジェクトの現場から」バックナンバー