納期がなぜ生産性をぶち壊しにしているのか？
昨年NewsPicks さんに取り上げてもらって最近動画が公開されました。そこでもお話させてもらっていることなのですが、アメリカで働きはじめると日本人からすると「納期が無い」感覚が物凄く衝撃的だった。
最近、納期が無いことと生産性について頭の中で整理がついてきたのでシェアしておこうと思う。ちなみに、動画も含めて、私の発言は私の体験と意見であり、所属会社には全く関係が無いことを改めてお断りしておきます。
日米納期の感覚の違い
アメリカで働いていると、日本人からすると納期がほとんどないという感じを受ける。もちろん納期があるものもあるが「本当に必要なもの」に限られる。例えば、大きなカンファレンスで何かの製品を発表するとかそんなのだと納期はもちろんある。そうでなれけばほとんど無いという感覚だ。私の所属会社だけではなく、北米の他の会社の人も同じような感覚らしいので文化によるものだと思う。
常に納期がある世界
なぜそう感じるか？というと、逆に日本にいた時には何でも納期が付いて回ってた気がする。凄ーくちいさな仕事を頼まれても「〇〇日までにお願いします」と納期が付いてくる。今からするとなんにでも納期が付いて回る感覚だ。こちらで仕事をしていると基本的にはできた時が完成という感覚がある。だから無理に徹夜したり、休出して間に合わせようとしたりはしない感じ。
納期に相当する言葉はない
こちらでいうと、先ほど挙げたようなケースでない限りは、納期を期待されることはあまりなく、相手にも要求しない。必要なときもETAという言い方をしていて、大体これぐらいでできるんちゃう？ぐらいの確度であり、日本人の感覚の「絶対的な納期」というイメージはどこにもない。こちらでは日本人の感じる「納期」を正確に表す言葉は無いと思う。Due date とかあるけど、我々の感じている絶対感が無い感じ。
これはサービスを受ける立場になってもそうなので、総じて「納期」に関するプライオリティが高くない感覚を受ける。デリバリも余裕で遅れるし誰も納期通りできるとも思ってない感じすらあるw
一方日本では、納期は絶対であり、納期通り仕事するのは社会人の基本ぐらいの勢いがある。この違いが生産性にどう貢献するのだろう？私のいるソフトウェア業界とその特徴と合わせて考えてみたい。
納期と生産性との影響
社会人１年目から、いや、子供のころから納期が大切！文化で育っている私は、ADHDであり、時間の管理はホント最低で申し訳ないといつも思っていた。アメリカに来てからは「あれ、納期って本当に必要な場面ってどれぐらいあるんだっけ？」と考えを改めた。
まず、ソフトウェアの場合、納期を予想するのがすごく難しい。自分が５日ぐらいと思ったのが、１か月とかざらだ。これは多分、ソフトウェア業界が常に新しい言語だったりバージョンだったり、新しいアーキテクチャと向き合うことになるので、全く同じものをずっと継続して鍛錬するということが存在しないことも大きいかもしれない。
納期見積もりの歴史
こういうのが得意な人はだからバッファを持たせるという戦略が常だった。そして、例えばアジャイルの世界では、始まった頃は、見積で、わからないときは、2.5倍して、実際の変数を計測するという手法から始まっていろいろな手法が提唱されたが、私の覚えている一番最後の方は「No estimate」ということを提唱している人も現れ始めた。実際の私のチームでは基本的にバックログやタスクレベルの見積もりはしない。これぐらいにリリースしたいなぁ。と大まかな計画はたてるが、それを死守しようとはしない。完成した時が完成だ。
多分これは途中で、積み上げるような見積などやっても無駄という結論に達したのだろうか？（私はそうなった経緯はしらないので）また、私が何かやっても「速くやって」とせかされることはなくて、自分が自主的に急いで、「速くできなくて申し訳ない」とか言っていると、逆に「急がなくていいから、しっかりした納得できるものを出そう」と言われてしまう。
これも、ソフトウェアサービスの場合、リリースして品質が低かった場合に、よりめんどくさいことになるからなのだと思う。
納期とスラック（余裕）
なぜ、このような違いが生産性に関係するか？というと個人レベルとチームレベルの話がある。
まず、個人レベルで考えるとわかりやすのだが、ほとんどの仕事に納期がある状態で仕事をしていると、常に「速く仕事を終わらせよう」という気分になる。仕事は、QCD+S (Quality(品質), Cost(コスト), Delivery(納期) + Scope(仕事の範囲))のトレードオフなので、例えば、納期をキープしたければ、他のものを犠牲にしないといけない。そしてそれはたいてい品質になるだろう。
例えば、「速く仕事を終わらせねば！」と思っていたら、「理解」がおろそかになる可能性も高いだろう。十分理解してなくても、手順書の通りにしたがったら作業は終わるかもしれない。理解は時間がかかる。だからこれをショートカットする人も多いだろう。しかし、中長期的には理解は生産性の向上の物凄いツールになる。
変化に対応する能力
たとえば、何かのバージョンが上がったりして、手順書の通りに動かなくなった場合、理解していれば、その対処は簡単で、その手順書に対して修正のプルリクエストを送ることが出来るだろう。
それが手順書を理解せず実行して「完了」させていたならば、それがかわったら、もう対処できないので、作った人に連絡して問題解決をお願いするのだろうか？
ソフトウェアの世界のように、ものすごいスピードでいろいろなものが変化していく世界だと、このような「変化への対応」の能力は物凄い差になると思う。そのためにも、急がずしっかり理解しながら仕事をした方が結局のところ早くなるし、変化に対応もしやすくなる。
私が若いころに上司によく言われていたのが、現場の画面や操作方法を変えてはいけない。現場が混乱するからとよく言われていた。確かにこれは日本では正しいかもしれないが、こちらでは、システムはゴリゴリに変わっていくけど、誰も文句を言わない。この背景には、この徹底した「納期文化」というのが大きく関係している気がしていて、ソフトウェア企業であれば、アメリカのマネをした方が良いのではと思ってしまう。
納期がある場合はどうだろう？
多くないとは言え、こちらでも、「納期」があるケースはある。実際体験するとこれも日本にいた時よりずっと気分が楽だ。日本の時はすべてのものに納期があったので、つねに「速くしないと」という思いがあり精神的にも常に張りつめている感じがあった。そもそも、すべてのタスクに納期があるのだから、新しい納期タスクが来た時には「納期調整」をするか「がんば
る」しかソリューションがなくなる。
納期仕事とストレス
こちらの場合それを優先順位１にしても良いし、普段納期ものが少ないため「よっしゃ久しぶりに納期もの来たか。普段ゆったりさせてもらってるからいっちょう頑張るか！」という気分の余裕が全然あることに気が付いた。納期仕事は、はやりストレスが高いものなのだと思う。だからここぞという時に使った方が良さそうだ。
無理なものは無理という共通認識
実際に納期ものが来た時も「休日・残業で頑張ろう」という方向性には絶対にならない。どうしてもMeetしたい納期がある場合、みんなで集まってどうやったらそれをキープできるかを話しあう。
これをやらなかったらどうだろう、とか、この機能をそちらで引き受けてくれたらできるかもしれない。とめっちゃ建設的なディスカッションがなされる。とにかく頑張るとかよくわからない結論には決してならないし、その後も休出や、残業をするとかも無い。物理的に無理なものは無理なのだという意識がみんなにあって、先ほど挙げたトレードオフを基に何を「引くか」を考える。
そうして出来上がった新しいプランもめっちゃ余裕があるものになっている。納期があるからこそ、ぎりぎりできるようなプランだと危ないからだろう。
まとめ
QCD+S は本来バランスが取れているのが良いのだろう。本来見直すと、日々の仕事で常に「納期」が優先という場面はそんなに多くないはずだ。自分にとっても、サービスを受ける側としても、「納期」に過度にこだわっていないかを見直すとその時々に、そのとき本当に大切なものは何かが見えてくるかもしれない。この納期絶対感が有効に働く分野もあるのだと思うのだが、多分ソフトウェア業界にはあまり向いていないのだと思う。
個人的には私の場合は、「納期を守って優秀と思われたい」という概念が、納期のない世界に来て崩壊した。周りもせかされないから、「理解に時間をかける」という本当の生産性そして、柔軟性のあるソリューションを実行できる。
仕事の優秀さは、納期だけではない。それだけだと歪だ。本当の良い仕事とは、インパクトとはどういうものかをこれからも考えていきたい。
昨年１０月に出した本が今も沢山読んでいただいているみたいで嬉しい限りです。よかったらどうぞ！
この記事が気に入ったらサポートをしてみませんか？