開発におけるマルチタスク化

開発現場で「スマホを見ながらコーディングを行う」なんて離れ業を行う人はいませんが、
複数のタスク（業務を分割したときの最小単位）の担当になることは、よくあります。

ひとつのタスクを完了してから、次のタスクに移るというのが理想なんですが、
なかなか理想通りにはいきません。

1. タスク１が完了する前に割り込みが入る
2. タスク１を中断し、次のタスク２を片付ける
3. タスク２が完了したので、タスク１に戻る
4. どこまでタスク１を進めていたかを思いす・・・（ ￣^￣）ξ
5. タスク１の続きを開始
6. また割り込みが入る（ ´＿ゝ｀）

大体こんな感じで生産性を落としていきます。

『アジャイルな見積りと計画づくり』に掲載されていたデータによると、
3つ以上のタスクを担当している開発者は、
タスクそのものにかける時間が少ない傾向にあるようです。
（残りの時間は、スイッチングコストに取られる。）

開発現場でのマルチタスクの発生要因

しかし、そうは問屋が卸さない。

ここからは、私の経験則になりますが、
実は、作業の割り込みのみに注意を払えばよいわけではなく、
無意識に現場をマルチタスク化してしまっているマネージャが多くいるのです。

要因１：設備投資の不足

私は、大規模なソフトウェア開発にも、いくつか携わったことがあるのですが、
ほとんどの現場では、開発者がビルドマシンのスペックに不満を持っていました。

ビルド時間は、ソフトウェア開発における一番身近な作業中断要因になります。
つまり、マルチタスク化の要因になっているわけです。

酷い現場では、5年くらい前の PC（OS も古い）を使っていたこともありました。
開発者が、「ビルド時間が作業の妨げになっている」ことを申告すると、


という返事が返ってきて、仰天したこともあります。

ビルドマシン以外にも、現場の設備投資が不足しているため
開発者が作業の中断を余儀なくされる例は、よくあります。

要因２：下流工程を考慮しない設計

以前、私がデータベースのテストを担当していたとき


という状況になったことがあります。
テストが失敗する度に、20分待たされるのです。
・・・いや、ほんとにストレスだった。

原因は、設計のテスタビリティ（試験性）の低さにありました。
それが、作業時間の分断を招いていたわけです。

なぜ、そのような設計になっていたかというと、
その開発プロジェクトが、テスト工程のことを全く考慮せずに進められていたためでした。

根本の原因は、プロジェクト計画の不備、及び各工程でのチェックの不備だったわけです。
要するに、プロジェクトマネジメントのミスです。

要因３：開発体制の不備

ソフトウェア開発は、規模が大きくなるに従い、テストの工数の比重が大きくなります。

⇒ 参考『ソフトウェア開発は開発規模に注意』


また、開発規模が大きくなるに従い、
チームリーダー、そしてプロジェクトリーダーという役割が必要になってきます。

⇒ 参考『ソフトウェアの開発規模とチーム人数』


人的資源（ヒューマンリソース）マネジメントは、マネージャの大事な仕事です。
開発規模に応じて、適切に人員を配置しなければいけません。

しかし、そんな状況において、こんなことを言うマネージャに会ったことがあります。


はい、無能。

・・・開発者みんなが、設計者 兼 テスター 兼 プロジェクトリーダー（ ´＿ゝ｀）
最悪のマルチタスクの発生です。

生産性へのダメージは大きく、現場の疲弊も著しいので、
マネージャは、このようないい加減な開発体制を敷いてはいけません。

今日のまとめ

• 開発現場でマルチタスクが発生すると生産性が下がる。
• マルチタスク化は、作業の割り込み以外でも発生する。
• プロジェクト計画、投資計画、開発体制の不備はマルチタスク化の原因になる。

最後に開発体制の話が出てきましたが、『体制図の意味』の記事で書いた通り、
開発体制の構築も、投資計画の一部なわけです。

プロジェクト計画を立てるときに、単純にスケジュールを引いたり、
体制図を書いただけで終わりにするマネージャがいますが、

• プロジェクトを完遂するまでの作業の規模を把握し、
• そのために、どの程度の生産性を確保しなければいけないかを把握し、
• そのための投資計画を立てる

・・・ということまでやっているマネージャは、非常に少ない気がします。
しかし、それがマルチタスク化の要因になってしまっているのです。