一日の稼働時間=作業時間だと思っていませんか?
はじめに
皆さんは業務の中で作業見積もりをしているでしょうか?
最小単位はだいたい1タスクあたり何時間かかるか、で見積もりしていると思います。
なお、ここでは主に会社員(サラリーマン)のITエンジニアを対象とします。
フリーランスや個人事業主の方は裁量を持って労働時間を決められると思うので一旦は対象外にします(フリーランスや個人事業主の方が見積もりしてないというわけではありません)
では、1日の作業時間は何時間と想定しているでしょうか?
8時間ですか?
6時間?
それとも10時間や12時間、終電まででしょうか?
最近上司と会話している中で、1日の作業時間を8時間と見積もりしているITエンジニアがいるという話で盛り上がったので記事にしてみようと思いました。
1日の稼働時間は8時間だが、8時間分の作業時間があると思ってはいけない
例えば9時出勤、1時間休憩の8時間労働だと、18時退勤となります。
稼働時間は8時間です。
では、8時間まるまる個人の作業時間として実装やテストなど自分の手を動かす作業に充てられるでしょうか?
答えはNoです。
この8時間には個人の作業時間以外の様々な時間が入ってきます。
そのため、作業見積もりする際に1日の作業時間は8時間と見積もってはいけません。
だいたい6時間程度にしておくのが望ましいでしょう。
(経験が浅い人や掛け持ちなどで複数プロジェクトに参加している場合はもっと減らしてもいいでしょう)
では個人の作業時間以外にどんな時間が入ってくるかいくつか見てみましょう。
会議
一番代表的なものが会議だと思います。
例えば以下のような会議があるでしょう。
- 朝会
- 昼会
- 夕会
- 社内・社外への進捗報告
- 営業やカスタマーサポートなど他部署との打ち合わせ
- 1on1
- 全体会議
- 提案に関する活動
- スクラムイベント
- 仕様検討会
これら全てに参加するケースは稀でしょう。
しかし、複数プロジェクトに参加していて複数の朝会や進捗報告会議に参加しているITエンジニアがいるのも事実です。
これらは15分～1時間、長いと2～3時間の時間を奪っていきます。
やろうと思えば内職して自分の作業時間に充てることは可能ですが、そのような会議であれば出席しないこと、別の形で参加する方法(例えば進捗をテキストにして送るだけにする等)を考えたほうがよいです。
ただ、実際には欠席することは難しいでしょう。
チーム活動としても、組織の活動としても会議への出席は求められるものですし、代替手段が認められることは滅多にありません。
別の用事で欠席した際にテキストで進捗を送るなどがせいぜいでしょう。
これも結局別の用事なので別のことに時間を取られているだけで、会議に出ているのと変わりません。
割り込み作業
次によくあるのが、本番環境やテスト環境でのエラー調査・対応、コードレビューのレビュー・指摘対応、メンバーや部下からの質問などの割り込み作業です。
これは元々予定はしていませんでしたが、割り込みで入ってくる作業となります。
そして基本的に無視することは出来ません。
どの作業もビジネス影響の大きさや他人の作業を待たせてしまう点から作業しないという選択肢はありえません。
いつ発生するかはわかりませんが、必ず作業しなければならないので、自分の作業として見積もりしておく必要があります。
最近聞いた話では、細かいレビュー指摘に丁寧に何度も対応していたら進捗が悪いと言われてしまった、なんてこともあるそうです。
自分としては言われた通り必要な作業としてタスクを進めているのに遅れ扱いにされたらたまったものではありません。
これも事前にバッファとして作業時間を長めに取っておけば吸収することが出来ます。
(もちろんそれ以外の対策として指摘に対応する時間が長いと進捗に差し障ることを伝え調整するなどの方法もありますので最適な方法を取るのが望ましいです)
この点からも稼働時間=自分の作業時間にならない、してはいけないということが分かると思います。
テストやデプロイ時間
単体テストやE2Eテスト、テスト環境へのデプロイなど、最近のシステム開発は意外と待ち時間が発生するものです。
やっていることは自分の作業としてやっているわけですが、実態は待ち時間なので作業が進んでいるわけではありません。
これでテストが通ればいいですが、一発でテストが通ることは稀です(逆に一発で通ったら疑ったほうがいいです)
そのため、何度もテストを流すことになり、累積の待ち時間がどんどん増えていきます。
これらは「長いな…」と思った時点で改善するのがベストです。
しかし、そのための作業時間を確保するのは難しいのが現実です。
正直に「テストやデプロイに時間がかかるから改善したい」と言っても、どれくらいの作業時間でどれほどの改善効果が見込めるのか?がハッキリしないとGoサインが出ることはないでしょう。
また同じ時間を使うなら新機能やバグ修正など眼の前のビジネスインパクトが大きいタスクが優先されがちです。
そのためにも作業時間は一日6時間とし、余った時間で開発環境の改善や開発体験の向上を図るべきと思います。
休憩
細かい時間ですが、休憩時間も積み重なると大きな時間になるものです。
タバコ、飲み物を取ってくる、コンビニに買い物に行く、SNSを見るなど、数分の積み重ねが1日の合計になると30分や1時間になります。
そもそも人間は15分以上集中し続けることは難しいといわれています。
そのため、どうしたって作業を中断して休憩を取らざるをえません。
集中力を欠いた状態で作業してミスが発生し手戻りが発生するくらいなら、最初から3～5分休憩して集中し直したほうが良いということもあります。
この休憩が必要という観点からも、稼働時間=作業時間にしないほうが良いと言えます。
調査・検討時間
設計にしろ、実装にしろ、テストにしろ、何かしら調査したり検討する時間が発生するものです。
- この機能を実現するにはどうすればよいのか?
- この改修を実現するにはどこのソースを修正すればよいのか?
- このコードのテストはどう書くべきなのか、どう書いたらいいのか?
- このエラーはどうすれば解消するのか?
などなど。
これは自分の作業時間でもあり、タスクとしてこなしているので、無駄な時間では決して無いのですが、これらの調査・検討時間は事前に見積もれているか?というと大体が見積もれていないことが多いと思います。
そのため、当初予定していなかった時間となることが多く、予定していた時間をオーバーしがちです。
そのためのバッファだったりするのですが、稼働時間=作業時間で見積もりしてしまうとバッファがなくなってしまい、遅れになってしまうことがよくあります。
その他の時間
例えばトイレに行ったりとか、出社していたら会社の人に話しかけられて雑談したり、リモートワークであれば急に家のことで席を外したりと、何かしら仕事していない時間はあるものです。
また体調不良だったり急に眠くなったりで、作業進捗が悪くなることもあるでしょう。
これらは予測して見積もりするのはほぼ不可能と言っていいです。
そのためにも1日の稼働時間=作業時間とするべきではありません。
不測の事態に備えたバッファを取っておくべきです。
不確実性との戦い
システム開発は不確実性との戦いだと思っています。
不確実性コーンの話が有名ですが、これは個人のタスクレベルまで落とし込んでも不確実性は存在します。
なにごとも結局終わるまで確定することはないのです。
しかし、往々にして様々な人から「確実な予定」を求められるものです。
予定は予定なので確実な予定というのは本来矛盾しているはずなのですが、予定がなければビジネスは成り立ちません。
いつ完成するか分からないものにお金は出せないですし、予算は組めません。
大なり小なりビジネスとしてシステム開発する以上は見積もりは必要になり、なるべく正確な見積もりを求められます。
過大でも過少でも見積もりは役に立ちません。
難しい、というより不可能なのは承知の上で正しい見積もりを出さなければならないのです。
1日6時間作業で余った時間はどうするのか?
これはそもそもリソース効率で考えると作業していな時間がある=効率が悪いみたいな発想になってしまうのですが、余裕があるというのはデメリット以上にメリットがあるものです。
一番のメリットは先に述べた不確実性との戦いに有利に立てるということです。
システム開発において全ての作業を正確に予測しスケジュール化することは不可能です。
どうしたって変更や変化を受け入れざるを得ません。
また、アジャイルソフトウェア開発宣言の文脈では変更や変化を味方につけたほうが、お客様の競争力が上がると言われています。
これらのことから不確実性を許容するためには余裕が必要ということになり、システム開発においてリソース効率優先でパンパンに予定を組むと上手くいかないことが多いです。
そのためにも一日2時間程度の余裕はあったほうがいいですし、結果的にこの2時間は余裕や暇な時間になることはなく、何かしらの作業に費やされていくはずです。
さいごに～見積もりの仕方～
詳しい見積もりの仕方については以下の合同誌がおすすめなので買って読んでね!
ワンストップ見積もり
だけだと単なる宣伝になってしまうのでここまで書いてきた内容をまとめると、稼働時間=作業時間にはせずに1日の作業時間は6時間程度にしよう、
それにより不確実性との戦いに有利に立つことができ、システム開発が成功する可能性を挙げられると考えています。
また、余裕を作ることによってチームや組織内のコミュニケーション促進や、開発環境の整備、開発体験の向上など自分たちの道具を整備する(いわゆる斧を研ぐ)時間が生まれると思うので、ぜひとも余裕を持った見積もり、スケジューリングをして欲しいと思っています。
これはシステム開発に携わるすべての人々に考えて欲しい内容であり、発注元も発注先も同様に考慮して欲しいと思っています。
Discussion