楽しく速く仕事を進めるための3つのヒント

はじめに

みなさん、最近どうですか？忙しいですか？ストレスやプレッシャーは感じていませんか？
はい、おいらも忙しいです。やること多すぎです。開発スピードを上げろ上げろとプレッシャーも大きいです。

で、どうやってやりくりしてますか？
毎日毎日、馬車馬のように働き続けてへとへとになっていませんか？

そんなわけで最近のおいらは技術的なスキルを上げることよりも楽しく仕事をやりながら、なおかつスピードもアップさせるという無理難題を解決することに興味があったりします。
まあ、興味があるというか考えざるをえない状況なわけですが・・・(- -;;

楽しく速く仕事を進める秘訣はなんだ？

そんなこんなで、最近はアジャイル関連の本を中心に読みながら楽しく速く仕事を進める秘訣を探していました。
その中で何となく見えてきたのが、

• チームで仕事をする
• 仕掛りの仕事を残さない
• タイムボックスを積極的に活用する

という3点です。

チームで仕事をする

ウチの職場は小粒な案件が多いせいか、一人一案件でアサインされることが多いです。
なので、仕事中に何か困ったことがあったりしても、基本的に一人で解決する必要があります。
もちろん、ある程度は周りのメンバーも手助けできますが、案件のコンテキストや使っている技術を十分に理解できてない以上、深い手助けはできません。
また、精神的に参ってしまいそうな時でも仲間で悩みを共有したりすることも難しいです。

というわけで、一人一案件というスタイルは色々とデメリットが多いです。
どんな案件でもチームで対処するようにすればこうした問題は解決できます。

またチームでタスクを共有していれば、負荷分散もしやすいですし、メンバーの病欠などにも対応しやすいです。
結果として全体的な開発スピードの向上が期待できます。

仕掛りの仕事を残さない

「高い給料を払っているのに手を動かしていないとはなんだ！やることがないなら、他の案件に着手せい！」と、ひたすら何かやっていることが「効率が良い」と思われがちです。
また、ある案件に取り組んでいる最中でも「ちょっと伊藤くん・・・」と上司に呼ばれて、突然緊急案件を割り込みアサインされることもあります。

こういうことを繰り返していると、あっというまに「仕掛りの山」ができあがります。
あの仕事もこの仕事も途中までやって、ほったらかし。
「よし、この仕事が終わったらあの仕事に戻って最後までやるぞー」と思っていても、また別の仕事をアサインされてその仕事には戻れない。
「はやくあの仕事を終わらせたいのになあ」と頭の片隅でその仕事を気にしながら、別の仕事をやっている・・・どう考えてもストレス溜まりますよね。

そんなわけで、仕掛りの仕事はできる限りゼロにする必要があります。
そのためには「仕事をいつでも終了できる状態」にしておく必要があります。
仕事をいつでも終了できるようにするためには、大きな仕事を小さな仕事に分解して優先順位を付ける必要があります。
小さな仕事であれば終了しやすくなります。
大きな仕事を分解しないままやろうとするとなかなか終わらないので、割り込みが発生すると中途半端なところで中断させられる可能性が高くなります。

あと、できるだけ複数の仕事を同時にやろうとしないことです。
つまりマルチタスキングを避けるということですね。
マルチタスキングよりもシングルタスキングの方が実は効率が良いということは色々な文献で言われていることです。

タイムボックスを積極的に活用する

いい仕事をしたいと思うと、完璧主義になりがちです。
優秀なあなたは「あれもするべき、これもするべき」と、やらなきゃいけないことがいっぱい頭に思い浮かびます。
それを全部実現できれば、すばらしい成果物ができあがります。
そんなわけであなたのTODOリストにはいつも数えきれないぐらいのタスクが並んでいます。

あなたはTODOリストを消化するのに必死です。
これが終わったら次はそれ、それが終わったら次はあれ、それが終わったら・・・あ〜、時間が足りない！時間さえあれば、もっといい仕事ができるのに！！とあなたは頭を抱えます。

え〜っと・・・がんばってるあなたには申し訳ありませんが、永遠に時間なんてできません。

ま、この話はちょっと前までのおいらのことなんですけどね。(^_^;

「やりたいこと」や「やらなきゃいけないこと」を先にリストアップしてしまうと、時間がいくらあっても足りません。
ここは一つ発想を逆転させましょう。先に制限時間、つまりタイムボックスを決めるわけです。
タイムボックスを決めてその時間内で最大の成果が上がるように工夫するわけです。
一つ一つのタスクは100点満点にはならないかもしれませんが、いつまでたっても仕事が終わらないという悪循環は断ち切ることができます。

例えば会議でもアジェンダを先にリストアップすると、ついつい会議の時間が延びてしまいがちです。
タイムボックスを決めて絶対にそれを超えないことをミーティング参加者で約束し、決められたタイムボックス内でできるだけ多くのアジェンダを消化しようとした方が時間の効率が良いです。

受託開発では難しいかもしれませんが、要求や機能を先にリストアップするのではなく、先に開発期間を決定し、その中で重要な機能から開発するようにすれば、スケジュール遅れは理論的に発生しないことになります。

やりたいことを先に決めることをスコープドリブン、時間を先に決めることをタイムボックスドリブンと個人的に呼んでいます。

たぶんほとんどの人はスコープドリブンで仕事をやっているはずです。
スコープを先に決めてしまうと時間がいくらあっても足りません。
先に時間を決めて、時間にスコープを従属させましょう。
こういう発想を常に持っておかないと、現代の仕事はとてもやっていけないんじゃないかと思います。

最後に

ベストプラクティスはコンテキストに依存します。
ここで述べたような考え方やプラクティスはおいらの職場環境では効果があっても、他の人にとっては効果が薄いかもしれません。
また、どうがんばっても自分の職場では適用できない、というケースもあるかと思います。
特においらは社内SEをやってるので、社内SE特有のコンテキストに大きく依存している可能性もあります。
似たような状況にある人にとっては、ここに挙げたような考え方が何かのお役にたてば幸いです。

参考文献

こうした考えに影響を与えた本をいくつか紹介しておきます。

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

XPについてとても詳しく説明してくれている本です。

リーン開発の本質

徹底的にムダをなくそうというリーン開発の考え方は大変興味深いです。

アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)

マネージャーが部下を細かく指示する組織よりも、チームが自己組織化する方がうまく仕事が回る気がします。

Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects (Pragmatic Programmers)

開発効率を上げるためにはマルチタスキングを避けるべきだということが随所に書かれています。

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

これの本を読むと、ソフトウェアを開発するのはあくまで「人」であって、交換可能な部品ではない、ということを改めて気付かされます。
機械じゃないんだから「プレッシャーをいくらかけられても、速くは考えられない」。

ザ・ゴール ― 企業の究極の目的とは何か

一人ひとり、または一台一台の稼働率を上げても仕掛品が増えるだけで、全体的な効率は向上しない。この点は製造業もソフトウェア開発もおんなじです。

トヨタ生産方式――脱規模の経営をめざして

少量多品種の製造ラインでは、大量生産でコストを下げるのではなく、徹底的にムダを省いてコストを下げます。今まで当たり前だと思ってきたことも、ゼロベースで考えなおすと実はムダだった。そんなことがまだまだたくさんあるのかもしれません。

アジャイルな時間管理術 ポモドーロテクニック入門

先日ちらっと本屋で立ち読みしただけですが、先に時間を決めて仕事を始める、というのはおいらの考える「タイムボックスドリブン」と同じだな〜と思いました。