設計書みても分からない...

最近、非常に効率が悪いと思うこと。

お客さまが、作成した画面をみて「これでは分かりにくい」と言われること。

何故か...

 

設計書に書いてあるエラーメッセージが分かりにくいのだ。

確かに設計書の書き方に改善の余地はあるとおもう。

しかし、Sierの悪しき習慣がお客さま、開発者双方を悩ませているのではないかと改めて感じる。

 

最近のプロジェクトは、小規模化、短納期＆安価なものを求められる。

システムというものがコモディティ化しているためでもある。

最近は、お客さまのほうで画面を作成してから開発ベンダにその画面をもとにシステムを作成してくださいというケースも増えている。

しかし、保守的なお客さまは、未だに「基本設計」→「詳細設計」→…という工程で進めていく。

これを変えることはできないのか。

 

お客さまの受け入れ試験になって下記のようなやりとりはよくある話だ。

 

お客さま「ここ、こんなメッセージだと分からない。」

私「詳細設計レビュー時に合意したんですが...修正いたします。」

 

文書で書いても分からない。

チェックするメッセージの数が多すぎて、お客さまがいちいちメッセージの妥当性を理解する時間がかかって仕方がない。

実際、お客さまはチェックしない。そんな暇はないからだ。

 

だからこそ、基本設計書を書く前に画面の遷移および画面メッセージがわかるプロトタイプを作成してお客さまに見せて期限付きでフィードバックをいただくようにしたい。

これで、当事者同士の稼働を減らすことができる。

 

あとは、プログラムを知らない社内抵抗勢力にどう説明するかだ。

幸い前回のプロジェクトでシステムアーキテクチャ基盤を私が作成したため、プロトタイプを作成する環境は整っている。

このやり方をすると、障壁になる可能性のあることが３つある。

 

1.プログラムを書けない人をアサインされること

2.社内のお偉方の承認を得られないこと

3.お客さまのお偉方の承認を得られないこと（思ったより可能性が少ないのではないかと思う）

 

特に1.2.だなぁ。このため、今までこれだけコストがかかっている旨をまとめて納得していただけるように準備ですね。

最近、マネジメントも大事だが、管理項目ばかり増やしてどうするの？と思うことが多々あります。

やはり計画的に無理なのにすすめること自体が問題なんですよね。従業員を雇わないといけないというジレンマもあるので、正論ばかり唱えるわけにはいきませんが...