無駄の排除はリーンなソフトウェア開発を支える中心的な原則のひとつであり、資金的に余裕がなく、至るところに大惨事が潜んでいるようなスタートアップ企業ほど、無駄に厳しい環境はない。よって、生産性の問題に重点を置いているスタートアップ企業は、組織内の無駄排除に邁進するアジャイル・チームのお手本として、二重に適していると思われる。
8aweek(サイト・英語)はサービスを提供するスタートアップ企業だが、8aweekのサービスはユーザーのオンラインにおける習癖をモニターし、ユーザーの気を散らすWebサイトへのアクセス制限を可能にし、「生産性成績評価」という方法でフィードバックを提供する。InfoQは最近、8aweek共同設立者のDave Fowler、Zachary Garbowの両氏に、ユーザーとの連絡方法や、仕事の優先順位のつけ方、物事の達成方法について質問する機会を得た。
InfoQ: 8aweekについて、また8aweekが平均的な開発者に何を提供できるのかをご説明ください。
8aweek: salary.com(サイト・英語)が最近行った調査によると、平均的な従業員は1週間に8時間以上の有給就業時間を無駄にしており、その大部分がオンライン上で浪費した時間です。自営業者や学生も全く同程度の時間を無駄にしており、若い労働者ほど浪費時間が増加します。8aweekはブラウザのツールバーで、コンピュータ作業中にユーザーの注意をそらすものの制御を手助けすることにより、時間を浪費させないようにすることを目指しています。ユーザーは時間を浪費しすぎるサイトを指定しますが、そうしたサイトにかけることのできる時間を8aweekが制限し、その時間が過ぎると徹底的にブロックします。
InfoQ: 8aweekはどのようにして生まれたのですか。当初は自分用として構築したのでしょうか。そうでなければ、動機は何だったのでしょう。
8aweek: 私たちは2人ともモチベーションが高いのですが、インターネットに莫大な時間を奪われて、物事を処理する上で妨げとなっていることに気づいたのです。2年の間、私はホストファイルを編集しては気を散らすものの締め出しに努めました。やっかいなハックで、コントロールやインタフェースは何もありませんでした。けれどもそれを使うと、Facebookを5分ごとにチェックする気にならなかったので、生産性が少なくとも倍にアップしました。Zackとこのハックをシェアしたのですが、Zackはアイデアを大いに広げてくれました。そして私たちは、使いやすく、かつ役立つパッケージの中で、この機能を皆に提供するツールを作ろうと決めたのです。
InfoQ: 8aweekの開発には、内部でどのような開発プロセスがあるのでしょう。あればお教えください。
8aweek: 私たちの開発プロセスはユーザー機能駆動開発に似ています。ユーザーのフィードバックに基づき、どの機能をつければ最大多数の人々が喜ぶかを明らかにして、スケジュールを作成し、そうした機能の統合を計画します。
InfoQ: 新しく創り出す機能は、どのようにして特定するのですか。また、物事の優先順位はどのようにつけるのでしょうか。
8aweek: まず、ユーザーが定義したリストに基づいてWebサイトへのアクセスだけをブロックする非常に単純なプロトタイプを作りました。この限定版プロトタイプを使って実験したところ、プロトタイプをいっそう堅固なものとするために必要な機能の長大なリストが簡単に出来上がりました。当初は、ベータ版を早急に発表する上で一番インパクトのある機能に焦点を合わせたため、そこから繰り返しユーザーフィードバックに戻りました。
発表のおよそ1日前に、ほとんどはた迷惑とも言えるフィードバック・応答システムを追加しました。簡単にアクセスできるように、ツールバーのすぐ中にフィードバック入力ボックスを入れたのです。ユーザーは毎日、バグを報告し、励ましのメッセージを送り、新機能をリクエストしてくれます。発表してからわずか2ヵ月ですが、その間に1,600件のフィードバックを受け取り、返答しました。
ユーザーとこのように密接な関係を持つことは、非常に貴重です。正しい道を進んでいるのがどの部分で、ユーザーにとって最も重要なのはどの機能か、最大の問題をもたらしているのはどのバグかを理解することができます。同時に、非常に高いモチベーションとなり、プロジェクト全体がとても私的なものになります。朝…いえ、昼過ぎに起床して、早朝まで働き続ける原動力となっているのです。
InfoQ: 物事を世の中に発表できるほど十分「完成した」と、どのようにして決めるのでしょうか。
8aweek: ユーザーフィードバックに基づく、迅速な繰り返しに焦点を合わせています。ですから、機能にバグがなくなればすぐにリリースし、その機能はそれで正しかったのか、それとも改良すべき側面があるのかをユーザーに教えてもらいます。私たちができるのはユーザーの希望を推測することだけですが、結局はユーザー自身に教えてもらうのがずっと良いのです！
しかし、ユーザーフィードバックを余りにも文字どおりに受け取ることには危険があります。自分が厳密に何を欲しているのかをユーザー自身がわかっていないこともあるので、ユーザーからのリクエストの根源にある原因を見極め、リクエストそのものの意図を推察することが重要です。そうすれば、その問題の解決へ向けて最良のアプローチを決定できます。その後、機能をリリースすれば、その機能は成功だったのか、そうでないのかを、ユーザーの反応からかなり明確に判断できます。