BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース #NoEstimatesを使って価値を提供する

#NoEstimatesを使って価値を提供する

ブックマーク

原文(投稿日:2015/05/21)へのリンク

Vasco Duarte氏は#NoEstimatesを学び、予算内で価値を提供するのに役立てる方法を探すのが良い、という。氏は#NoEstimatesについての本を書き、見積もりがなぜうまくいかないのか、#NoEstimatesを使ってどのようにプロジェクトを管理するのかを説明している。

InfoQは氏にインタビューし、#NoEstimatesについて、プロジェクトで#NoEstimatesを実践する場合にどのように意思決定するかについて、話をした。また、なぜ#NoEstimatesは抵抗されるのか、その抵抗にどのように対処するのかについて話を聞いた。氏自身がどのようにして#NoEstimatesを見つけ、実践したのかについても話を聞いた。

InfoQ:#NoEstimatesについて簡単に教えてください。

Duarte: もちろんです。1999年、2000年あたりに、私は管理するのが大変なプロジェクトに関わり、大変な思いをしていました。難しいミーティングをし、皆燃え尽き、大変な思いをして納期を守り、終わり近くでバグと戦い、プロジェクトをスケジュール内で完了させようとしていました。私は、もっと良い方法があることを知っていて、そのより良い方法を探し始めたのでした。

まず、要求プロセスで実験をしました。従来の要求プロセスではなくビジョンが書かれたドキュメントとユースケースだけで仕事を始めました。驚くべきことに、チームは幸せになり、プロジェクトはより良い結果を達成しました。スコープから何を除外するかについての難しい決定も簡単にできるようになり、納期が守れました。しかし、まだ納期内に納めるのは大変でした。

次のステップは明確でした。ユースケースを見積もるのではなく、ユースケースが特定の内部納期に間に合うように管理したのです。定期的にスコープについてのミーティングを行い、テストを簡単にし、テスト自動化に投資をして見積もりをすべてやめました。単に、小さな価値を積み重ね、デリバリの速さを計測しまただけでした。今、このやり方はアジャイルと呼ばれています。ただし、私たちは一切見積もりをしませんでした。つまり、私はアジャイルについて知る前に、見積もりなしで、現在スクラムと呼ばれているのに近いやり方を実践していたのです。私にとっては#NoEstimatesとはたったこれだけのことです。納期内、予算内に価値を提供する、ということです。

Infoq: 小さな前進をするためにユースケースをどのように管理したのですか。

Duarte: 素晴らしい質問です。どのように漸進的にデリバリをしたのか、それも、そうすることが難しそうなときにさえ。実際、この質問はとても重要で、私は私の#NoEstimatesの本の読者が、ユーザストーリーやユースケースの中から、機能を段階的に提供できる方法を見つけられるよう支援しています。

それぞれのユースケースをひとつの問いを念頭に置きながら、定期的にレビューします。その問いとはすなわち、何がやめられるか、そして、やめても提供できる価値は何か、ということです。事前条件、アクター、保証、シナリオなどをレビューし、それぞれについて、捨てられるか、捨てても価値を提供できるか考えます。このプロセスは、(多くのイテレーションを実行したあとで)アクターに明確な優先順位を定義し、デモというコンセプトを導入することで簡単になりました。ひとつの重要なポイントはアジャイルソフトウエア開発の導入のおかげで、段階的なデリバリのプロセスはより簡単になりました。

InfoQ: 見積もりなしでは選択肢を比較し意思決定できないという人が多いでしょう。#NoEstimatesではどのように意思決定すればいいのでしょうか。

Duarte: プロジェクトでは、毎日、さまざまなタイプの意思決定が生まれます。#NoEstimatesから利点を得られる意思決定のタイプはプロジェクトのコントロールから外れてしまう既存の制約の中でやらなければならないことについての意思決定です。最初、#NoEstimatesを実践していたときは、確固としてスケジュール上の制約がありました。私たちが製品を販売している市場は、納期が全く柔軟ではありません。コンシューマ向けのソフトウエア製品を開発しており、最大の商戦はクリスマスだったのです。どんなに理路整然としていても、クリスマスの日付を変えることはできません。2、3日ですら、遅れることはできないのです。

私にとって、#NoEstimatesはこのような状況でこそ、実践するべきものです。つまり、納期に交渉の余地がない場合です。プロジェクトである種の期限に間に合うようにするためには、私たちは100、あるいは1000の意思決定をする必要があります。明確で検証可能なデータソースで意思決定をガイドするのではないなら、クリスマスの納期には間に合わないでしょう。見積もりは明確でもなく、検証可能でもありません。見積もりは車内政治、バイアスの影響を受けます。#NoEstimatesを始める前、私が働いていた会社のプロジェクトは62%も遅れていました。つまり、100日のプロジェクトで62日も遅れてしまうということです。これは受け入れられません。既存の進捗データに基づいた意思決定ではなく、#NoEstimatesでは、私たちは見積もりをせずに、どのプロジェクトでも活用できる既存の進捗データに基づいて、意思決定をしたのでオンスケジュールでした。

InfoQ: 進捗データとはどのようなデータですか。どうやって使ったのですか。

Duarte: 私たちの場合は、プロダクションライクな環境に配置する進捗はユースケース(と機能、またはユーザーストーリー)です。実際、これが重要なのです。私たちがユースケースの開発を完成させ、配置しないのなら、その後、問題が見つかります。統合の問題かもしれませんし、品質の問題かもしれません。そのほかのタイプの問題かもしれません。したがって、Running Tested Stories (私が自分の本で使った言葉です)として進捗を確認するのが重要です。例えば、開発されたストーリー、テストされたストーリー、プロダクションライクな環境での実行などで、進捗を確認します。

進捗データは定期的(週次、あるいは日次)に何が完了したのか、何が残っているのかについての最新の情報を伝えることで、私たちの意志決定を通知します。

進捗データを見て、このデータを元に未来を予測することで、プロジェクトのプロジェクトのタイムラインを更新します。コストはほとんどありません。退屈な見積もりミーティングの必要もありません。

InfoQ: #NoEstimatesに抵抗する人もいます。理由はわかりますか。どのように対処したらいいでしょうか。

Duarte: 人は自分の考えや居心地の良さを脅かすもアイディアに反発するものです。それは、私にとっても同じです。私が実践の中から#NoEstimatesを見つけ出した理由はひとつだけです。つまり、選択肢がなかったのです。納期内、予算内に細尾者が手に入らなければ見積もりはうまくいきません。関連するデータはたくさんあり、おかしな法則もあります。私のお気に入りはホフスタッターの法則です。"いつでも予測以上の時間がかかるものである ・ホフスタッターの法則を計算に入れても。"というやつです。

InfoQ: #NoEstimatesを学びたい人向けのリソースを教えてください。

Duarte: #NoEstimatesについては多くの人が話したり、執筆したりしています。一番簡単なのは、YouTubeで"NoEstimates"で検索することです。多くの動画が見つかります。私はこの話題について本を書いています。すでにプロジェクトで立ち往生してしまっている人を支援する本で、#NoEstimatesを使ってプロジェクトを成功させる方法を説明しています。この本は(一定期間ですが)無料でNoEstimatesBook.comで読むことができます。

InfoQ:#NoEstimatesが実践できるようになる前に開発は必要でしょうか。

Duarte: はい、皆が実験をして、#NoEstimatesを役立てる方法を見つけるのがいいでしょう。#NoEstimatesには単一の絶対的な定義があるわけではありません。スクラムやカンバンのような手法と結びつくでしょう。私にとって重要なのは、アイディアを試すことであり、学び、知見を共有することです。まだ、#NoEstimatesの旅の入り口にいるのですから。

InfoQ: #NoEstimatesはどこへ向かっているのでしょうか。どのような未来が待っていますか。

Duarte: #NoEstimatesは会話です。ツイッターのハッシュダグで始まりました。私はこのアイディアを見つけた人から毎週メールをもらい、考え方のモデルの可能性に興奮しています。私たちはソフトウエア産業で上質な生活をするに値する存在であり、この考えがきっかけで#NoEstimatesに出会いました。知識はあります。誰も隠すことはできません。誰でも活用できるのです。

この記事に星をつける

おすすめ度
スタイル

BT