Webのシステムを作る仕事に転職して、一番困ったことが、この本には書いてあった。

前職と比べ明らかに変わったことがあった。顧客と業者である自分との関係である。
前職は生産設備のエンジニアだったのでアウトプットに対する要求はシンプルで、うまく生産できること、求められる工程能力を出すこと。生産という観点では完全にお客さんがプロで、こちらが素人という関係である。社内システムであることも起因しているだろう。

それに対してWebシステムでは、業者がプロで、お客さんは自分を完全に素人とみなすことが多い。彼らは「わからない」ので、業者に依存してしまう傾向にある。このような状態を本書では「責任過少」の状態と呼ぶ。

このような状態で、確実な要件を聞き出して、彼らのビジネスモデルを十分に生かすシステムを作るのは至難の業だ。「責任過少」の罠は、本人が本来の能力を発揮できなくなるところにある。うまく関係を持たずに話を進めると、往々にしてコミュニケーション不足に陥る。そしてビジネス的に素人であるシステム開発業者側がイニシアチブを取らなくてはいけない状況になる。

いつまで経っても要求仕様がすっきり固まらないときは、立ち止まってお互いのコミュニケーションが適切でないことを認識すべきだ。これは誰が悪いというのではなく、お互いの責任のバランスが取れていないということである。リリースの日がどんどん迫っていって待ったなしなわけだが、一度、立ち止まった方が良い。

仮にシステムがうまく完成して検収が順調に済んだとしても、不幸にして不満足な使えないシステムを作ってしまったら後悔しても後の祭り。もう一つ、適切なコミュニケーションがなされていない場合に起きる現象は、物が完成してからお客さんが気に入らない点に気がついて修正を要求されることである。これは利益に直結するので、できる限り避けなくてはいけないことである。

（Weｂの場合は意思疎通する簡単な方法があって、HTMLでプロトタイプを作って実際に触ってもらうようにすることをオススメする。これにかなう意思疎通手段はない。何故なら、お客さんは「素人」だからだ。仕様書だけで意思疎通するのは不可能。いくら文章や絵で説明したり、いろんな質問をしても、彼ら自身がWebに対する要求仕様が見えてないことが非常に多い。プロトタイプを作って実際に触った瞬間に、彼らは面白いようにこちらの仕様のマズイところを指摘しはじめることであろう。これを効率的に進めるためには、設計者がプロトタイプのために、基本的な画面レイアウト、サイズ、ユーザビリティ・・・かなりWebデザインに関わる画面設計をしなくてはならないというジレンマに。）

本書は、自分の持論にマッチしているが故に学ぶことが多い。ここでも書いたことだが、「システムは顧客側の担当者の能力、意欲以上にはなりえない」というのは未だにそう思っている。これは決定権を誰が持つか？という話で、エンドユーザーのためのUIの部分というよりも、運用などにも根ざしたビジネスロジックの話であるが、受託ビジネスの限界だと思っている。
だからこそWebのような、エンドユーザーが存在するシステム構築の難しさを感じているのだが、本書を読んで顧客側の担当者と最大限のコミュニケーションを取り、彼ら「プロ」のビジネススキルをWebに反映していくための努力の必要性は、大変痛感した。

本書のメインの内容は、自社内でのマネジメントでの問題点がほとんどであるが、本書で記述されている「責任過剰」と「責任過少」の関係は、異なる２者間で成り立つであろう汎用的な仕組みのため、エンジニアや医者、コンサルタントと言った「プロ」と顧客間の関係に関する話も載っている。

「リーダーシップ」と言ったキーワードでいろいろ思うところがある人は是非読むことをおすすめする。