メッセージ。 - にゃー

不具合や障害が起きたとき、日本人は「残業でも徹夜でもして直すのが当たり前だ」と考えがちだ。この言葉の背景には、「不具合や障害はないのが当たり前。もし不具合や障害を起こしてしまったのなら、どのような犠牲を払っても、一刻も早く復旧すべき（ユーザーへのリスクなしに）」という論理が含まれる。

たとえばあるプロジェクトで、Aという機能が企画される。一ヶ月をかけてその機能は開発され、本番環境にリリースされた。Aの次はBという機能だ。Bもまた一ヶ月をかけて開発され、本番環境にリリースされる予定だった。しかしここで、本番環境にリリース済みのA機能に障害が起きた。

ユーザーや営業は、一刻も早く復旧しろと言ってくる。開発チームは、何日も残業や徹夜にまみれ復旧を行った。障害対応には数日かかったが、なんとか復旧はできた。しかし、障害報告書の作成や顧客への謝罪行脚、社内説明などで事態の収拾には時間がかかる。一度信頼を失うと、顧客や営業は、倍返しを求めてくる。より厳しいテスト計画、より完全な設計とテストエビデンスが次のプロジェクト以降に課される。

つまり、Bプロジェクトの開発負担は、当初よりもずいぶん重くなる。しかも、障害対応でたくさんの時間が失われている。しかし、それにもかかわらず顧客や営業は、「当初立てた通りのリリース期日」を求めてくる。時間が減っており、仕事が増えているにもかかわらずだ。

なぜかというと、それが日本人の倫理観だからだ。「やると約束したことは何があってもやらなければならない」「たとえ条件が変わったとしても、それは顧客のせいではない。では瑕疵の原因はどこにあるのか？技術の問題なら開発に責任がある。責任を負うものは無償で復旧しなければならない」「プロなんだから、障害を起こらないようにするのが当たり前だろう」「リスクがあるなら、最初からそれを織り込んでおくべき」という価値観。無限責任だ。

では逆に、欧米の人は不具合や障害が起きたときどう考えるのか。もちろん欧米の人も、障害が起きたときは残業したり徹夜したりして対応する。しかしそれは、あくまで限られたリソースの中での範囲だ。

たとえばある開発スプリント中に不具合が発生する。そのとき彼らは、プロダクトオーナーにこう尋ねてくる。「オーケー、不具合チケットを切ったよ。最優先タスクとしてこのスプリントに入れる？それとも、次以降のスプリントに入れる？このスプリントに入れる場合、当然当初このスプリントでやる予定だったチケットはドロップする」。

優先順位の判断を求められる。さらに彼らは、基本的に残業をしない。どれだけ不具合のチケットが溜まってようが、プロジェクトが遅延しようが、残業も休日出勤もしない。少なくとも自分からはしない。もし、マネージャが明示的に指示した場合は、ある程度残業や休日出勤もやるけれど、無理はしない。無理な指示をするマネージャがもしいれば、それは無能なマネージャなので彼らはすぐに会社を辞めてしまうだろう。

「リソースは限られている。そのなかでやれることをやる」。それが彼らの価値観だ。リソースから溢れるなら、多少不具合や障害があっても気にしない。それは想定内であり、リスクが計画に盛り込まれている。一方日本人にとっては、不具合や障害は想定外であり、計画に盛り込まれていない。正確には、計画などそもそも立てていないのだが、とにかくステークホルダーのあいだでゴールの認識がある程度一致している。暗黙の了解がある。