ポモドーロに分ける効果
なぜ25分にわけるのか。
シングルタスクで集中している状態を継続できれば、作業効率は上がります。しかし、長時間集中を保つことは難しいので、25分だけ集中する時間を作ります。また、25分を一単位として管理するので、「この作業は2ポモドーロで終わる」などという見積りもしやすくなります。
ということで、要は集中力向上で生産性をあげる方法だな、と思っていました。最初は。
ただ実際にやって見るなかで、別の効果があることがわかってきました。
タイムボックスの意味
時間を決まった単位に区切ってそこにタスクを割り当てるという手法は、「タイムボックス」と呼ばれるアジャイル開発の技法そのものです。
アジャイルは反復開発をするため2週間などの期間をタイムボックスとして設定し、その期間内で実装できる最も優先度の高い作業を集中して実施します。
ところでアジャイルでは、このタイムボックスの長さを調整するということをしません。例えば設定した作業があと2日で終わるから2週間+2日に変更することはありません。代わりに優先度の低いタスクを減らすことで対応します。
この方法を取る場合、ウォーターフォールでの開発と大きく変わるのは、開発者の見積に対する感覚です。
ウォーターフォールでは作業遅延が発生したときにマスタープランを修正できます。そしてプロジェクトではQCDを管理します。このプロセスは開発者に「一定以上の品質で、所定のコストを使い、できるだけ早くやる」という目標を持たせます。
ただこの目標には問題があります。なぜなら「できるだけ早く」ということは、「できなければ遅くなる」ということでもあるからです。開発者は作業遅延が発生したときに、端的に「所定の期間ではできなかったからだ」と考えます。逆に顧客は開発者の能力が高ければもっと早くできたはずだと考えます。作業は「できるだけ早く」できるのだから、所定の期間に終わらなかったのは開発者が「できない」やつらだったからだという論理に帰結します。
この状況は、個人的な作業でも生まれ得ます。
できないことを肯定する
目標が達成可能か否かという視点と、実際に目標にトライするかどうかという視点から、作業への取り組みにあたっての作業者の姿勢を以下の4パターンにわけます。
上記したような開発者が作業遅延時にあきらめのような感情を抱くケースは(b)に当たります。
4つのケースにおいて作業に取り組んだ場合、それぞれ以下のような帰結をします。
(a) 「できない」という事実に直面するので無力感は感じるが、作業コストはかからないで終わる。
(b) 当初からできないと分かっている作業なので、完了できなくてもあきらめが付く。
(c) 成果は出ないものの、やればすぐに出来ることがわかっているので、気軽に作業を保留できる。
(d) できるとわかっていることので、真摯に取り組まなくては結果がでない。ただし、最終的には成果を得られる。
実は、4つのケースのうち実際の成果が出るのは(d)の場合のみです。
にも関わらず、(a)〜(c)に当たるような取り組みを行ってしまうことは多いのではないでしょうか。
(d)は成果を得られるケースですが、同時に最もコストがかかるケースでもあります。唯一価値のあるやり方であるにもかかわらず、作業者の負担が最も大きいのです。
だから、作業者は簡単に(a)〜(c)のパターンを選択してしまいます。できないことを肯定してしまうのです。
できることだけをやる。
ポモドーロ・テクニックの効果は簡単にいえば、上記した(d)のケースにあたる作業を増やせることです。
これは単純に優先度づけをするタスク管理術にはできないことですし、ただ生産性を上げることにこだわる方法論の効果とも違っています。
タイムボックス=ポモドーロに割り当てるタスクは、常にできる範囲の作業です。あまりに時間がかかるような作業は分割しなくてはいけません。このためタスクの割り当ての段階で、(a)(b)のケースに陥る可能性が排除されます。
タスクを割り当てた段階で、タイマーが回っている時間内に自分が何ができるかが確定してしています。別の作業を割りこませることは禁止されているので、タイマーが回っている間、割り当ての作業をしないことはできません。このため(c)のケースも排除されます。
作業者は、結果として最も負担の大きい(d)のケースとして作業に向かうことができます。もちろんその見返りとして成果を得ることができます。
キッチンタイマーは、もともと、変更不可能な時間を計るために使われてきました。
その意味でも、ポモドーロ・テクニックという名前は適当なものなのかもしれません。
概要など
公式ページ
ポモドーロ・テクニックは25分を「1ポモドーロ」という単位にし、その間に集中してタスクを片付けます。
25分経過したら5分間休みをとり、30分周期で繰り返します。
ポモドーロというのは、考案者が時間を図るためにトマト型のキッチンタイマーを使ったことに由来します。
詳細は以下。
紹介ページ
書籍
本も出ています。
- 作者: Staffan Noeteberg,渋川よしき,渋川あき
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2010/12/16
- メディア: 単行本(ソフトカバー)
- 購入: 13人 クリック: 330回
- この商品を含むブログ (56件) を見る
作業をポモドーロに分割することについて
ポモドーロ・テクニックという、若干変わった名前の時間管理術があります。
■
「お客様」と「ユーザ」の違いについて
自分はパッケージソフトの開発をして生計を立てています。その開発現場では頻繁に「お客様」という言葉をつかい
ます。結局パッケージを使うのはお客様なのであって、いかにお客様志向であり得るかという問題は、開発に関わる
人々に共通する問題である、というのが職場では共通認識です。
ただ、なんとなく腑に落ちないことがあって、表題のことを考えました。
仮定として、システムの利用者を示す言葉を二つ定義します。
- 「お客様」
- 実際に取引のある顧客
- 営業担当者が顔を合わせて要望を聞く相手
- 開発者がシステムに対するフィードバックを得る相手
- 「ユーザ」
- システムに対して、広告の閲覧や課金をして利益をもたらしてくれる顧客
- システムを利用する不特定多数の顧客
- 開発者がシステムに対するフィードバックを得る相手
利用者であることに変わりはないので、今導入したこの二つの言葉の定義は重複しています。
システムを通じて開発者に利益をもたらしてくれるという点が共通していますし、システムを使用してそのフィード
バックをくれるという意味では全く同じです。
ただし、二つの間で最も顕著な違いがあります。それは「特定の個人か否か」です。
「お客様」とは、人格を持ったひとりの個人です。「お客様」はある刺激に対して一意な反応を返すことはありません。
お客様は人間ですから刺激に対してブラックボックスとしての人格を通じて処理を行い、その上で反応します。
それぞれ個別の人格ということは、あるお客様がとった反応は、別のお客様に共通することはないという意味でもあり
ます。
一方「ユーザ」とは、匿名的な利用者の集合です。
個別のユーザを見た場合、ユーザがシステムからの刺激に基づいてとった反応と、別のユーザが同じくとる反応は、
量的な差異の範囲で認識できます。
「ユーザ」においては個別の人格はあまり重要ではなく、むしろ集団が統計的にどのような傾向を持つかということが
重要になります。
「お客様」とは単体としての人格が意味を持つ利用者を指す言葉であり、「ユーザ」とは匿名的な集合として意味を持
つ利用者(の集団)を指す言葉だと考えていただければと思います。
この「意味を持つ」とはどのようなことでしょうか。開発者が利用者に期待することは、ひとつはシステムに対する
支払いをしてくれることであり、もうひとつは、システムを改善するためのフィードバックをしてくれることです。
つまり「お客様」の場合、個別の「お客様」が支払いとフィードバックの両方を充足してくれるのに対して、「ユーザ」
が支払いとフィードバックをしてくれるのは「ユーザ」が集合として存在した場合のみであるという定義であるという
ことになります。
あえてこの二つの見方で利用者をわけるのは、この視点の違いが、「支払い」「フィードバック」というそれぞれの
あり方を大きく変えてしまうからです。
まず支払い(=利益)ということでいうと、「お客様」は開発者に支払いをする実体であるので、開発者は一人ひとり
のお客様が望むものを製造することに注力する必要がありますし、それを最重要の問題にしなくてはなりません。
しかし「ユーザ」は開発者に支払いをすると限りません。もちろんシステム利用=課金であるシステムもありますが、
ここではそうしたシステムの顧客は「ユーザ」の定義から除外させてください。それよりも「ユーザ」とはシステムに
付随する広告を閲覧する利用者や、システムの利用の最中に課金を行ってシステム利用を継続するような主体です。
このように考えると、個々の「お客様」からは確実に支払いを期待できるのと違って単体の「ユーザ」からは確実に
支払いを期待することができません。広告モデルであれば、実際の支払いをするのは広告掲載企業であって、ユーザは
ページを閲覧することしかしません。課金モデルでも、すべてのユーザが必ず課金をするわけではなく、全ユーザの一部
のユーザが実際の支払いをするだけです。かといって、課金をするコアユーザだけをターゲットにしてシステムを作るわ
けにもいきません。
なぜなら一部のユーザが課金したというのは、結果であって、つぎも必ず同じ一部のユーザが課金するとは限らないから
です。コアユーザに手厚い対応をするよりも、母数としてのユーザ数を増やすことが、逆に課金をしてくれるコアユーザ
を増やすことにつながります。
このことは顧客からのシステムに対するフィードバックの得かたの違いにもつながります。
「お客様」は必ず支払いをしてくれる顔の見える相手ですから、個々の「お客様」から要望を聞き、「お客様」の期待に
答える改善をすることが、システム改善のための有効な手法になります。
一方「ユーザ」の場合、個々のユーザの要望は必ずしも重要でない場合があります。なぜなら要望をしているユーザは
本当に課金をしてくれる有効な顧客であるかどうかわかりませんし、そもそも不特定多数の顧客である以上、個々の
ユーザの反応から、全体のユーザに共通する要望を抽出することはできません。
ところで、こうした「お客様」的利用者と、「ユーザ」的利用者の具体例はどのようなものでしょうか。
まず、システムが一個の顧客にひもづく受託開発では、利用者はまさに「お客様」です。
一方システムが不特定多数の顧客にアクセスされるWebサービスの利用者は「ユーザ」になります。
受託開発においては個々のお客様の存在を無視することは致命的な失敗をもたらします。
しかしWebサービスにおいては個々のユーザの存在をむしろ無視することができなければ、システムの設計が混乱し、
極大化した要望に対応することができずに、開発は立ち行かなくなるでしょう。
Webサービスでは個々のユーザを人格として理解しようとすることは困難かつ有効性がなく、量的指標を用いてフィード
バックを得ます。
これはコミュニケーションのモデルの違いとして敷衍できる差異でもあります。
一方では個別の人格と人格が接する境界に発生するコミュニケーションがあり、もう一方には個別の人格を無視して
無機的なシグナルが交換されるコミュニケーションがあります。
この二つのどちらが有効かはコミュニケーションが生起する場に関わる人員のキャパシティによって、かわります。
受託開発ではインタフェース役の開発者と利用者は数人規模になるでしょうから、当然「お客様」的な利用者を想定
したコミュニケーションが有効です。
一方で、Webサービスでは不特定多数の利用者が、一箇所に配置されたシステムにアクセスしますから、「ユーザ」的
な利用者を相手にする前提でコミュニケーションを構成しなくてはなりません。
最後に、どちらのコミュニケーション形態が有効化は利用者の量によると書きましたが、受託開発とWebサービスを両極
にとったとき、パッケージ開発というのは中間に位置します。
この時に、ある問題が発生する、と思います。それはある部署(おそらく営業・サポートなどの部署)の担当者は、
「お客様」として利用者をみており、別の部署(開発部門?)の担当者は利用者を「ユーザ」として見ているという
ケースです。
この場合には様々な問題が発生します。例えば営業担当者がシステムへのフィードバックとして個々のユーザの問題を
集積して届けても、開発者にとってはそれは質的指標に基づくフィードバックなので、整理が困難になり開発項目に
有効に反映することができないかもしれません。
逆に開発者が利用者を「ユーザ」としてみてばかりでは、個々の「お客様」のニーズに応えられず、事業としての収益
が減少するきっかけになるかもしれません。
冒頭に書いた「腑に落ちない点」というのはこのあたりに問題があったようです。
なんにせよ、適切な形でシステムへのフィードバックを得るためには、開発部署の生産性と、システム利用者の量に
注目するしかありません。その増減は常に注視するべきです。
2010 夏コミ ありがとうございました。
本日、東 N-10a にて、会誌「オタモスフィア」のVol.5『おたくと収集』を販売しておりました。
わざわざ足をお運びくださいました皆様、誠にありがとうございました。
ちなみに、今回は部数が若干すくなかったこともあり、かなり早い時間で完売となってしまい申し訳ありませんでした。
過去に発行したものは、こまめに再販するようには心がけておりますので、また出店などする機会がありましたらご用意したいと思います。
出展のおしらせは、このページで掲載しますとともに、Twitterにてアカウント[twitter:@naokomada] にて、ちょくちょくつぶやきますので、よろしければたまにご覧いただけると幸いです。
今後とも、なにとぞ、よろしくお願いします。
セカイ系は世界を変えられるのだろうかね
小飼弾の本を読むと、ああセカイ系だなという感じがする。
もちろん、他にもIT系のひとはセカイ系っぽい雰囲気を出している。
「スティーブ 砂糖水」でgoogleるだけで出てくるエピソードにも世界という言葉が入っている。
いわゆる「社会」のイメージっていうのは、そのほとんどを人間が生身で仕切っている(最後の決定が人間の対面コミュニケーションになる)のだが、IT系の世界は構造が多層化していて、基盤技術になるほど普遍的で変えがたくなる。それで、普遍の基盤のうえに個別の事象が乗っているみたいな感じがして、おれの足下の地面には国境はないぜみたいなイメージが増殖するのかもしれない。
で、セカイ系の人の話は面白い。
抽象度が高く、論理的で、つっこみばっかりいれなくてすむ。
ただそれは、セカイ系ならではの特徴だ。朝生だって東浩紀にはみんなつっこみづらそうにしている。内容が完成されていて展開に蓋然性があるからじゃなくて、論理展開の方法自体がつっこみづらい形態なのだ。
だからセカイ系の人の話は素晴らしい理論で、これを使えば世界を本当に変えられるというはなしではない。
実際、セカイ系の人の理論を使おうとすると、セカイ系とそうでない系のあいだを超えるときに間違いなく止められる。そのセカイ系キャズムみたいなのの実体は、たぶん例の対面コミュニケーションに絡む問題だろう。
キャズムのこっち側つまりセカイ系アーリーアダプターたちは、簡単にマインドチェンジしてしまい本当に世界を変えるようなセカイ系企業を作り上げる。
でも、キャズムの向こう側では変わりたくないと思っている人たちがいっぱいいる。
彼らが変わりたくないと思っているのは、変化へのリスクの見積もりが高いからだが、それを悪いと言うことは誰にもできない。変化のリスクはもっとも見積もりが難しい。だれが見積もったって十全な蓋然性は得られない。
規律訓練を無視して、身体レベルで人間を管理/コントロールするという発想は、実はセカイ系のルーツがあるかもしれない。規律訓練とか内面とかを無視すると、例の対面コミュニケーション問題がなくなる。つまり、キャズム自体を無化できて、説得以外の方法で対処できるから。
気がつくと身体的な習慣になっているような変革というのは、過去にも宗教的な方法とかで実績があるので、またできないとも限らないかもしれない。