読者です 読者をやめる 読者になる 読者になる

職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

デザイン指示書 その未来

その他 デザイン

WebサイトやWebアプリケーション、iOS / Android などの開発の現場において、デザイナが他者に指示を出すために「デザイン指示書」やそれに類するものを作成することは少なくありません。
ここ数年の間で、このような文書のやり取りに絡んだトラブルの事例を数件見たり聞いたりしたので、そこで起きている典型的な問題と、それに対する対応策を紹介したいと思います。

※業界や業態が変われば「デザイン指示書」が指す文書の役割は異なり、デザイナに指示をするための文書を指すこともあるでしょう。この記事を読まれる際には、皆さんの環境において使われる文書名に置き換えて頂ければと思います。印紙税の課税対象であるか否かが文書の名称ではなくて文書の内容によって判断されることと感覚的には同じですね。この記事では、デザイナがプログラマや広報担当者などに出す指示を文書化したものという意味で デザイン指示書 という語を使っています。

問題点

例です。

デザイナのD氏は、顧客のC氏から「こんなものを作りたい」という要件を聞き出して取りまとめ、要件や工期、予算などについてC氏と合意をした上でデザイン指示書を仕上げ、プログラマのP氏に引き渡しました。
P氏が要件やデザイン指示書の内容を確認したところ、その製品を指示通りに作り上げるにはNP困難な問題を解く必要があり、仕様の変更か、工期や予算の追加のいずれか、または両方が必要であることがわかりました。
デザイン指示書を書き上げたD氏は、既にそのプロジェクトからは外されて別のプロジェクトに加入してしまっており、P氏はC氏との仕様の調整に追われた結果、金銭的にも時間的にも大きな追加コストが必要になってしまいました。それだけではなく、せっかくD氏が作ったデザインは、陽の目をみることがありませんでした。

途中経過を随分と省いてしまった例になっていますし極端な例でもありますが、これに似た惨劇を体験されたことのある方もおられるのではないでしょうか。最終的には予算的にも期間的にも失敗するのです。
経験のある方は容易に想像できるかと思いますが、ここで起きている現象は、ソフトウェア開発の場面でよく用いられていたウォーターフォール型開発で発生する現象の一つ、上流工程において誤った仕様を組んでしまったときに甚大な被害が発生する、というものと同じです。

デザイン指示書が活かされる条件

筆者の経験上、デザイン指示書が期待通り活用されるのは次の条件のうち少なくとも1つ以上が満たされるときであると考えています。

  • 似たような内容、納期(期間)、予算、構造、技術構成要素、顧客業界、用途 のものを、同じ構成員で何度も繰り返し作成すること
  • デザイン指示書の内容について、事前に十分にプログラマに伝達され、十分にフィードバック及びそれへの対応がなされていること
  • 指示を出す側のデザイナが実際に持っている知識やスキルセットが、指示を出される側に求められるそれのスーパーセット(上位集合)(参考:Wikipediaの部分集合の記事)であること

これらの1つ以上が満たされているときに何が起きるのかというと、指示を出す側のデザイナが「全てお見通し」の状態になり、地雷原を上手く避けることができるようになります。

じゃあどうするの?(少しだけ一般化した話)

このような問題は デザイナ+プログラマ という組み合わせに限らず、前工程の担当者が後工程の全てを十分に理解していない環境においては、大なり小なり、どの世界でも起こり得るものです。
十分に防止するためには、前述の「デザイン指示書が活かされる条件」のうち1つ以上が満たされなければならないのですが、組織の成熟度合いをここまで引き上げたり、前工程の担当者のスキルをこの域まで高めるのは、多くの場合では難しいことでしょう。
それではどうすれば良いのでしょうか?
「手戻りが発生する」「作ったものは誤っている可能性がある」という前提での計画を立てるのです。冒頭に掲げた例の場合であれば、デザイン指示書を書き終えたD氏をすぐにプロジェクトから外すような計画を立ててはなりませんし、P氏による技術チェックを早期に開始するような計画を立てるのが良いでしょう。そう、「デザイン指示書が活かされる条件」の2番目の状況を作るのです。この3つの条件のうち、最も低コストで実現可能なのは2番目のものであることが多いはずです。ここで必要になってくる追加のコストは、プロジェクト大炎上時の追加コストに比べれば随分と安いものです。追加コストの部分を保険商品として評価すれば優良商品であるとことはすぐにわかるでしょう。

プロトタイピングは銀の弾丸なのか?

ここまでを読まれた方の中には、プロトタイピングをきちんとやっていれば避けることができる問題なのでは?とお考えの方もおられるかと思います。
しかし、プロトタイピングによってもたらされる最大の効果は、作成されたデザインがビジネス要件に適合しているかどうかを確認し、「売れない原因」「使われない原因」を早期に検出することにあります。実装困難であることの検出にもある程度の効果は見込まれますが、専門家によるレビューを受けることができない環境であれば、同じ問題に見舞われることでしょう。プロトタイピングは銀の弾丸ではありません。(繰り返しますが、別の効果が絶大です。プロトタイピングは是非やりましょう。)

まとめ

プロジェクトの計画は、きちんと立てましょう。