調査した要件

私が好きなソフトウェア開発の引用文を 1 つ紹介します。

要件は、製品の構築を開始する前に発見する必要があるものです。構築中またはさらに悪いことにクライアントが製品を使い始めてから要件を発見することは非常に費用がかかり非効率的です。そのため、正常な思考を持つ人はそのようなことはしないでしょうし、二度と触れません。

-- Suzanne and James Robertson

これは彼らの著書「Mastering the Requirements Process」の第 1 版の冒頭段落です。私の好みが同意と無関係であると推測する読者もいるかもしれませんが、この引用文が好きなのは、ウォーターフォールメソッドにおける要件の価値体系を要約しているからです（実際、「要件」という単語は本質的にウォーターフォール的です）。

アジャイル手法は、構築中およびデリバリー後に「要件」を発見するつもりでこの根本的な仮定に反しています。しかし、この賢明な助言を無視する無神経さも、現在の多くの主要 Web サイトがやっていることとは比較になりません。これらのサイトにでは、ユーザーがサイトで何をしているかを観察し、そこから新しい機能のアイデアを次のような方法で生成することで要件を探っています。

• 人々がサイトで何を実現しようとしているのかを確認し、それらを実現するためのより簡単な方法を提供する。
• 人々が何かを行うのをやめている場所を確認し、彼らを悩ませていた問題を解決する方法を見つける。
• 新しい機能を構築し、人々が使用するかどうかを確認する。
• 実験的な機能を作成し、一部のユーザーベースに提供する。気に入りそうかどうかを確認できるだけでなく、サーバーにどの程度の負荷がかかるかも評価できます。

この種の分析をサポートするには、アプリケーションにユーザーログ記録の動作を追加し、これらのログを分析するためのツールをいくつか構築する必要があります。ログ記録の多くは Web アプリケーションで無料で表示され、これが人々がこれを開始するようになった大きなきっかけだったのではないかと私は考えています。しかし、ログ記録と分析は、アプリケーションに追加されるとさらに高度になります。

これを行う方法についてウェブ上でアドバイスをあまり見つけられず、実際にこれを行うことについて議論をあまり聞きません。多くの場合、監視機能を構築して、ソフトウェアの改善方法を探るためにそれを使用するための時間を費やす必要があります。さらに、アジャイルプロジェクトの場合でも、従来のソフトウェアプロセスの方法から大きく離れます。

しかし、ここには大きな可能性があります。人々が望んでいることと、人々が実際に必要で使用するものの違いはどれほど大きいかを誰もが知っています。ユーザーがアプリケーションで実際に何をしているかを監視することで、ソフトウェアで実際に起こっていることを把握できます。これにより、他のソースよりもはるかに直接的な情報を得ることができます。その結果、より多くのチームがこのアプローチをツールキットに追加することを検討すべきだと思います。