nDiki : 見積もり

プロジェクト開始時の開発見積もりは意味がない

140文字程度のなんとなくやりたいことで、すぐに工数見積もりが欲しいと言われたりするので「ソフトウエア開発55の真実と10のウソ」真実 9. を言及できるよう引用。

真実 9. ソフトウエア開発の見積もりは、プロジェクトの開始時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。-- ソフトウエア開発55の真実と10のウソ p.48

(日本語訳では「開発時」となっているけれども原文からすると「開始時」なので上記では修正)

Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time. -- Facts and Fallacies of Software Engineering Rovert L. Glass

既に2005年にも引用しているのだけれど、何も決まっていないのに工数を聞かれると今でもこれを思い出してしまう。

せめてユーザーストーリーぐらいまではまず書こう。

Toggl でタイムトラッキングするだけで時間の使い方が良くなる

GTD では使える時間を基準に行動を選ぶ

GTD では次の行動を「状況」「時間」「エネルギー」「優先度」の順の基準で選びます。

今使っているタスク管理ツール Remember The Milk はタスクに予測時間を設定しておくことができます。そして検索やスマートリストで使える時間に応じたタスクをリストアップすることができます。

タイムトラッキングしてタスクの時間見積もり精度を上げる

ただこの予測時間の見積もりはだいたいこれぐらいかなと思って入力することがほとんどだったりします。もう少しきちんと入力できるようにタイムトラッキングしてどれぐらい時間がかかっているか実測してみることにしました。Remember The Milk にはタイムトラッキング機能が無いので、今回はタイムトラッキングサービスでは有名な Toggl 試してみます。

• https://toggl.com/

Toggl

サインアップすると Toggl サイト上でタイムトラッキングできます。Google Chrome 拡張を入れると Remember The Milk のタスクの横にも Toggl のボタンがついて1クリックでトラッキングの開始・終了ができるようになります。Remember The Milk のタスク名がきちんと Toggl のエントリの description に設定されるなど良くできています。これは便利。

スマートフォン向けアプリもあってそちらでもトラッキングの開始・終了ができます。以前ちょっとタイムトラッキングをしてみていた時(2007年前後)は Task Coach を使っていましたが、この頃は特定の PC でしかトラッキングできませんでした。スマートフォンの登場でかなり便利になりましたね。

タイムトラッキングすると時間の使い方が上手になる?

費やした時間を記録してあとで精査することで所要時間の見積もり精度を上げたり無駄な時間を見つけたりすることがタイムトラッキングの大きな目的だと思っていました。

しかし実際にやってみると

• 「トラッキング中はネットサーフィンなどのような計測している実際のタスクとは違うことはしたくない」という気持ちになって集中してやるようになる。マルチタスキングもしなくなるのでコンテキストスイッチのコストが無くなる。
• タイマーを設定することをイメージして「そもそもこんなことに時間を使わない方がいいな」と考えるようになり、無駄に思われる行動をやめるようになる。

など、ふりかえりをせずとも即行動に影響が現れたので驚きでした。家計簿をつけたり食べた物を書き留めるのと同じで、無駄に対する意識が高まるようです。

これは楽しいですね。しばらく続けてみることにします。

(画像は https://blog.toggl.com/media-kit/ より)

第7回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会7回目。今日は第7章 見積もりとベロシティ。

プロダクトバックログの見積もり

プロダクトバックログアイテム(PBI)の見積もりはプロダクトバックログリファインメント(グルーミング)で行うアクティビティです。この時プロダクトオーナーやスクラムマスターは「実際に見積もる作業」には関わらないのがポイント。

見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。

でなるほどと思いました。見積もられたサイズよりも、見積もるという過程を重視しているんですね。

ストーリーポイント

PBI の見積もり単位としてストーリーポイントと理想日を紹介しています。ストリーポイントはあくまで相対値なのでそのチーム内でしか使えない値です。プランニングポーカーのところで

多くのチームでは、1回のスプリントでこなせる最大のサイズを13で表している。

としているので、これが一つの目安でしょうか。それからストーリーポイントはベロシティと対にならないとあまり意味をなさないですね。

理想日の方はいわゆる人日。

ベロシティ

ベロシティで計測するのはあくまでも生産量であり(デリバリーしたもののサイズ)であり、成果(デリバリーしたももの価値)ではない。

ここは当たり前な感じではありますが誤解してはいけないところ。

計測で出てくるベロシティは見積もりの(精度ではなく)正確性によってかなり揺らぎがあると思うのですが、このあたりはチームが学んでいくことで安定していくものなのでしょうか。ベロシティに幅を持たせて表すと良いとありますが、どれぐらいの幅に収まっていくのか興味があります。

それからベロシティが上がるかという話がありました。ストーリーポイントとしては相対値なので上がらないはずですよね。アウトプットの絶対量は増えていくと思いますけれど。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

プランニングポーカーでプロダクトバックログアイテムの見積もり

プランニングポーカーを使ってプロダクトバックログアイテムの見積もりを初めてしてみました(私はプロダクトオーナーなので見積もる作業には関わらない立場)。「見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。」というの、なるほど納得しました。

第11回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会11回目。今日は第11章 開発チーム。

ここまでの章で様々な視点でスクラムの説明がされてきたので、開発チームの章は比較的おさらないな感じで読めました。

開発チームのスキル

開発チームは設計・開発・統合・テストなど必要な作業を全て行うので、必要なスキルをチームは全て備えている必要があります。

このために

マネージャーは、今いる人たちでT型スキルのチームを作るべきである。

マネージャーは、学習や実験の時間がうまく作れるように、チームメンバーを支援する必要がある。

と書かれています。他のメンバと互いに専門分野を教え合いながらできる仕事を増やしていくのがまずは近道でしょうか。ただこの方法だと浅く広く学習は進むと思うのですが、 T 型の縦の部分、専門分野の部分を深めていくのは(機能別のチームで学び合うのに比べて)難しくなるのではと感じました。

「専門分野については個人で学ぶ方法を獲得していて自力で学べるのでは」という意見が勉強会では出ました。

開発チームの構成

チーム構成の話では小さいチームの方が

• コミュニケーションでの帯域が向上する
• 誰かがやってくれるという意識が減る

としています。一方

• チームのもつスキル
• 議論の多様性
• 学習

などを考えるとある程度の人数も必要でこのあたりのバランスが重要そうです。本章では

一般的には5〜9人のチームが最適とされている。

ビジネス価値を迅速に届けるスイートスポットは5〜7人のチームである。

と述べられていました。そういう意味では今の私のいるところのスクラムチームは人数がちょっと少なすぎるかなと感じました。

掛け持ち

掛け持ちに対する問題は承知しているものの、現実的にせざるを得ない場合が発生します。

複数のプロダクト(またはプロジェクト)や複数のチームに関わると生産性が低下する

3つ以上のプロジェクトの仕事を同時に行うのは経済的ではない

とありこれに従うとすると仕方なく兼務にするにしても2つまでにすべきということですね。そういった状況が発生するのは

多くの組織では、同時に開始するプロジェクトが多すぎる

ということで組織体制の工夫以前にプロジェクトの見直しをすべきなのでしょう。

チームの寿命

長寿のチームはできたてのグループよりも生産性が高い

については完全同意。今までもチーム殺しをしないように意識はしてきました。特にスクラムではチームとして見積もりやベロシティの履歴が蓄積されることで正確性が向上していくところがあるので、チームを維持していくことがより大切に感じられます。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

第15回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の15回目。今日は第15章 さまざまなプランニング。昨年12月のプロダクトオーナーの章ぶりの発表当番です。

この章ではスクラムを使ったプロダクト開発に関係する以下のプランニングを紹介しています。

• ストラテジープランニング
• ポートフォリオプランニング
• プロダクトプランニング(エンビジョニング)
• リリースプランニング
• スプリントプランニング
• デイリープランニング

勉強会では自分たちの事業でのプロダクトは何か(例えば mixi は1つのプロダクト)を確認し、実際やっていることのどれが各プランニングにあたるのかを確認。スクラムチームメンバから直接体感できるのはプロダクトプランニングまでで、ポートフォリオプランニングはうかがい知れないことが多そうという話になりました。

それから(旧来からの)受託開発の場合は、リリースが固定スコープ・固定日だよねなんて話も。

スクラム開発チームメンバからは「トップダウン型のプランニングの流れの印象だが、スクラムチームの見積もりでわかった計画との差異はどのように上位の計画に反映していくのか?」という疑問もあがりました。

このあたりは続く章で説明があるのかもしれません。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

今日のさえずり: ワイルドブルー ヨコハマいいですよね(1度しか行けなかったけど)

2017年02月21日

• 13:48 「これまで2年に渡って運営、キュレーションしてきた各公式パブリケーションや公式 Twitter、公式 Facebook を本日を持って止めることを決定しました。」 / “Medium Japan より大切なお知らせ – Me...” http://bit.ly/2lFSai4
• 17:35 見積もり済み PBI 枯渇の危機。
• 20:16 ワイルドブルー ヨコハマいいですよね(1度しか行けなかったけど)。
• 23:05 ガイオンフェスティバル (Gion Festival)

第19回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。

スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。

タイミングと時間と参加者

スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。

今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。

• チームメンバが2時間のプランニングミーティングに耐えられない。きちんとスプリントプランニングするメリットを感じられていない。
• 3チームのプロダクトオーナー(自分)が時間を確保できない。

もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。

プロダクトバックログアイテムにかけるキャパシティ

完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。

 スプリントのキャパシティ
   = PBI にかけるキャパシティ + スプリントバッファ + それ以外

予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。

今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。

作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。

プロダクトバックログアイテムの選択

基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。

タスク分解と作業時間見積もり

自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。

スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

仕事に追われない仕事術 マニャーナの法則 完全版

タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。今までスルーしていたのですがここ最近クローズリストの考え方を取り入れてみているので、その辺りの話が書かれている「仕事に追われない仕事術 マニャーナの法則 完全版 (Do It Tomorrow and Other Secrets of Time Management)」を読んでみました。

• 仕事に追われない仕事術 マニャーナの法則 完全版

マニャーナの法則

まずマニャーナの法則ですが

• 原則1 新しい仕事は「明日やる」を基本にする
• 原則2 クローズリストを使う

という2つの原則のこととあります。日本語ではマニャーナの法則と訳されていますが the mañana principle なので「(行動)原則」の方が適切に感じました。

「すぐやる」ことの弊害

すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。

「すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。

ただ「すぐやる」については

• 「後回しにしてチャンスを逃す」ことのないようにする。
• 先送りすることで増大するコストを最小化する。

というメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。

全員がマニャーナの法則をやるとどうなるか?

個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。個人の稼働が最適化されるかわりに、作業の手待ち(idle work)が多く発生することになるからです。

このあたり要注意に思われます。

緊急レベルを判断する

入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。

• 緊急レベル1「今すぐ」
• 緊急レベル2「今日中に」
• 緊急レベル3「明日やる」(ベスト)

本書では「明日やる」がベスト。

これはすでに2週間前からRemember The Milk の優先度設定に取り入れてみています。

WILL DO リスト

その日にやるとコミットしたタスクを入れておくクローズリスト。自分は Remember The Milk でタスクの優先度を1にすることでリスト化しています。

処理する順番はファースト・タスクが最初で「明日のリスト作成」が最後です。それ以外はまったく自由。

1日の最後に何をおいても明日の WILL DO リストは作成することが必須とあります。仕事については実践していますが、プライベートでは翌日の WILL DO リストを夜に作るのがまだ習慣にしきれていません。

ちなみに本書ではタスクにかかる時間の見積もりについてはほとんど触れられていません。翌日時間が足りず WILL DO リストを完了できそうもない場合もいつもどおりリストを作成し翌日は「できるとこまでやる」「完了できない日が続くなら対策をとる」という感じになっています。

やり残しをどうするか?

WILL DO リストで完了できなかったものは、「やり残し」フォルダに放り込み、ファースト・タスクで処理しましょうとあります。

これは今週から Remember The Milk で backlog タグを付けるようにして実践中です。

ファースト・タスク

ファースト・タスクは「毎日の最初に行い、そこから1日をスタートさせるのが望ましい仕事」とのこと。毎朝最初にできる仕事は1つしかないので、常に1つ。

• 原則1 とにかく、する (Do)
• 原則2 一番始めに、する (First)
• 原則3 毎日、する (Every day)

ファースト・タスクに向いている仕事は

• 「やり残し」を片付ける
• 仕事のシステムを修正する
• プロジェクトを進める

です。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。

実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。

ダッシュ法

ダッシュ法はポモドーロテクニックにつながるところを感じました。ちょっとマニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。

二分等法 すべての仕事を半分にする

プロジェクトをタスクに分解する方法。 GTD でプロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。

その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。

全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。

行動の合間に考える習慣をつける

最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。

• 「毎日15分」など時間を決め確保する。
• 邪魔が入らない場所でノートと筆記用具を用意し、浮かんできたアイデアや考え方をノートに書き留める。
• 時間の終わりに近づいたら書いたものについて考える。良いアイデアや行動が必要なことに下線を引く。

というものです。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。ぜひ取り組んでみたいなと思います。

冒頭にキーワードが説明されているのが良かった

最後に本書の構成について。

本書では冒頭で「本書に登場する18のキーワード」として

• 「クローズ・リスト」「オープン・リスト」「チェック・リスト」
• 「コミットメント」「本当の仕事」「忙しいだけの仕事」
• 「バッファー・ゾーン」「マニャーナの法則」
• 「タスク」「プロジェクト」
• 「タスク・ダイアリー」
• 「デイリー・タスク」「ファースト・タスク」
• 「TODOリスト」「WILL DOリスト」
• 「ダッシュ法」「期限の効果」
• 「ラベリング」

が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。

本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。

• 仕事に追われない仕事術 マニャーナの法則 完全版

---

[ 読書ノート ] [ お薦めの本 ]

早すぎるプロダクトバックログリファインメント

今日はスクラムで開発している CS 開発チームのスプリントプランニングだったのですが、プロダクトバックログアイテムの中に見積もりした時のことをあまり覚えてないという事案が発生しました。多分1カ月ぐらい前にプロダクトバックログリファインメント済みのもの。

プロダクトバックログリファインメントであまり先まで検討しても、状況が変わって無断になる場合があるよというのは言われているのですが、それ以外にも単純に忘却してしまうというデメリットがありますね。