プロジェクト・マネジャーが知るべき97のこと/スクロールから学んだこと
12年前のことですが、私のチームはグラフィックデザイン会社の下請けとして、Webアプリケーションを開発するために雇われました。私たちは顧客と直接コンタクトすることを許されていませんでした。要件はすべて顧客から元請けに伝えられ、私たちはそれを時々送られてくるメールで知らされました。

そうしたメールのなかに、デザイナーが使うべき画面解像度に関するものがありました。以前の標準は640×480でしたが、新しい調査によると、Webサイトは最大800×600までの解像度をサポートすべきだと推奨されていました。（現在では、最もよくある画面解像度は1,024×768です。）元請けは経験豊富なデザイン会社でしたが、顧客向けの公式な要件（私たちは見たことはないですが）には次のように記載されていました。

もし私たちがこの要件を見ていれば、即座にこう訂正したでしょう。「各ページのレイアウトは横800ピクセル固定という標準にしたがうこと（800×600までのモニタ解像度をサポートするため）。」

私たちはこれまでWebサイトの仕事を数多くやってきており、一番重要なのは横幅であることを知っていました。ユーザーはブラウザを使うとき、横方向にスクロールすることを嫌います。そこで横幅にあわせて折り返すと、表示は縦長になります。よいかどうかはともかく、私たちは縦方向にスクロールすることは現実的で当然だと思っていました。そのため、私たちはこのことを顧客に伝えませんでした。それほど重要なことだとは思えなかったからです。

このWebサイトに不慣れな顧客が各ページに用意した内容は、あまりに巨大なものでした。結局、800×600の解像度に設定された15インチモニタでは、ほとんどのページが横幅におさまらず折り返され（縦方向に長くなり）、一画面では表示できませんでした。縦方向にスクロールせざるを得なかったのです。

この巨大なコンテンツを一画面で表示するためには、奇跡を起こす必要がありました。そのことを知って、エンドユーザーでもある顧客は激怒しました。顧客は私たちの元請けであるデザイン会社を非難しました。すると、そのデザイン会社は、私たちへの支払いを拒否したのです。彼らに言わせると、私たちは「要件を記載された通りに満たさなかった」のだそうです。

この経験から、私はずさんで出来の悪い要件の危険性と、それがどのように使われるのかを学びました。あなたの前提を必ず明記して、仲介役とではなくエンドユーザーとともに要件をレビューし、承認を求めることが重要です。

幸運なことに、アジャイル開発のプラクティスにしたがうと、こうした問題の一部は軽減されます。開発者と真の顧客のあいだの対面コミュニケーションの重要性を認識することによって、要件リストではなくユーザーストーリーの作成と、顧客に提供するビジネス価値に基づくフィーチャーの優先順位付けとがまとめてできるようになります。そして1～2週間のイテレーションプロセスによって、早期の頻繁なフィードバックと顧客の期待を明確にする機会が得られます。

あれから12年、私はこの時とまったく同じような状況に出くわしました。その顧客は1ページに大量のコンテンツを表示したいのに、縦方向にスクロールすることを非常に心配していました。幸いなことに、現在のプロジェクトの進め方と過去の経験から学んだ教訓のおかげで、以前のような混乱を引き起こすことはありませんでした。私たちは問題をすばやく解決して、現実的な顧客の期待を設定することができました。