宮地 弘子(みやじ ひろこ) 社会学者
大学院修了後、ソフトウエア開発企業2社でエンジニアとして勤務。その後、筑波大学大学院で博士号を取得(社会学)。IT業界をフィールドに労働と組織をめぐる問題の研究活動に取り組む。
著書に『デスマーチはなぜなくならないのか』(光文社新書)

─デスマーチが発生する要因は何でしょうか。

情報産業は、つくるものの性質や、組織の来歴・構造、雇用形態などが多種多様で、デスマーチといってもその内実はさまざまです。拙著『デスマーチはなぜなくならないのか』では、労働条件が良くエンジニアの自律性が十分認められている外資系のソフトウエア開発企業の現場を取り上げ、そのような現場でもデスマーチが発生する不思議さを扱いました。ですから、この本で扱ったことがデスマーチのすべてではありません。それでも、問題を「まなざす」視点に示唆があると考えています。このことを前提にお話ししたいと思います。

ソフトウエア開発者は、工業製品の技術者と同じようにエンジニアと呼ばれますが、両者の仕事の性質はまったく異なります。ソフトウエアには人知を超えた複雑さがあり、バグを取り切ることは不可能です。それゆえ技術的な完成がなく、「永遠のベータ版」とも呼ばれます。エンジニアリングというよりも芸術に近く、「魔物」にも例えられるソフトウエア開発作業の特質を、デスマーチと呼ばれる現象が起こる背景としてまず押さえておく必要があります。

─著書ではデスマーチの歴史も振り返っています。

大型コンピューターの時代は、ハードウエアづくりのノウハウをソフトウエアづくりに当てはめようとする開発手法のミスマッチが、デスマーチを招く大きな要因でした。その後、小型コンピューターの登場によって、ソフトウエアは個人や数人の力でつくることが可能になりました。特にベンチャー系の現場では、「パソコンマニア」や「マイコンマニア」出身の若者が腕と情熱を競うかのようにどこまでも完成度を追求し、昼夜を分かたず働く姿が見られるようになりました。このような視点から見ると、デスマーチは単なる労使関係の問題とは言えません。

─「単なる労使関係だけではない」というのは？

実際に燃え尽きた人の話を聞いてみると、「企業に搾取された」と自覚している人は少ないように思います。現場のエンジニアは、「魔物」にも例えられる作業をいかにして統御するかに懸命に取り組む中で燃え尽きているのです。確かに外部から見ると、搾取されているように見えますが、内部から見るとそうではない。エンジニアたちが、ソフトウエアという、人間がこれまで扱ってきたことのない性質の「もの」と試行錯誤で向き合っている。デスマーチはその中で発生している問題と考える必要があるのではないでしょうか。

─著書では00年代以降にデスマーチに注目が集まるようになったと指摘しています。

小型コンピューター向けのソフトウエア開発について言えば、例えばアップルやマイクロソフトが、若く優秀な「マニア」たちの腕を頼りに目覚ましい成果を上げた手法は、確かに産業の草創期・成長期の時代に適合的だったと言えます。しかし、いつの時代にも通用する開発手法はありません。00年という分水嶺を超えると、産業は成熟期を迎えます。ソフトウエアは大規模化し、ネットワークを通じた依存関係にさらされるようになったことで、複雑さも格段に上がりました。働く人のライフステージは移り変わり、ライフコースも多様化しています。個人の腕や情熱に頼る手法は限界を迎えるようになったのです。

もう一つ、ソフトウエアのインフラ化・コモディティ化という要因を挙げておきたいと思います。情報システムが社会のインフラとなり、日常生活に欠かせないものになったことで、ソフトウエアに対する人々の期待値が上がりました。

しかし、ソフトウエアは「永遠のベータ版」であり、一点の間違いもなく動くことは不可能です。けれどもこうした性質に対する理解は深まっておらず、高まる期待値とのギャップが、現場への圧力として作用している面があると思います。

─デスマーチを乗り越えるために何が求められるでしょうか。

産業が成熟期を迎え、専門分野が細分化しているにもかかわらず、なぜか「ソフトウエア開発」という言葉で一くくりにされがちです。まずは、この産業のさまざまな仕事がどのような性質を帯び、どのような問題を抱えているのかを具体的に調べる必要があります。「理解なくして対策なし」です。

さらに、ソフトウエア開発という仕事の性質への理解を広く促していく必要もあります。

ソフトウエア開発を大工仕事と比較して説明したエンジニアがいます。大工は木や鉄などの原材料を組み合わせて家をつくるが、ソフトウエア開発者は、原材料ですら一からつくるのだと説明していました。人知を超えた複雑性を帯びる「もの」を、まさに一から、何の制約もないところでつくり上げるのです。

そうした性質ゆえに、ソフトウエアの設計図を事前に描ききることはできず、すべての問題を見通すこともできません。ソフトウエア開発は、計画と非常に相性の悪い作業なのです。最初から完璧に「つくる」よりも、漸進的に「育てる」手法が適していると言われています。

しかし日本には、そうした「育てる」手法が浸透しにくい事情があります。

日本は工業製品のものづくりに対する自負が強く、一点の間違いもない製品を計画通り完璧につくり上げることが当然視されています。そうした手法は、ソフトウエア開発作業にフィットしません。

けれども、日本の情報サービス産業が製造業系の大企業を中心に形成されてきたこともあり、工業製品の時代に培われたものづくりの手法や商習慣が、諸外国に比べて根強く残っているのです。

ソフトウエアをつくる側も使う側も、発想を180度変える必要があります。完全な統御が不可能であることを前提として、そのような作業の性質にフィットした開発手法や契約のあり方を社会全体で検討していく必要があります。

─労働組合に求められる対応は？

新しい産業ゆえに集団的労使関係が未成熟と考えるよりも、旧来の運動のあり方がこの産業に適していないと考えるべきではないでしょうか。裁量労働制や年俸制の導入によって専門職労働の個人化が進む中、エンジニアは、同僚たちと共通した利害関係を想定しにくくなっているように思います。そのため会社に対して連帯して何かを訴える必要性を感じていない。

私は、多様な選択ができることがこれからの時代のキーになると思います。組織という枠組みを通した活動だけではなく、さまざまな事情を抱えたエンジニアが個人で参画し連帯を探っていくことのできる場がもっと増えてほしいと思います。新しい時代の新しい産業に合わせた、新しい連帯のイメージが必要なのではないでしょうか。

また、労働者の裁量を拡大する方向だけではなく、それに応じた企業の管理を求めていく方向の活動も重要です。

ソフトウエア開発という仕事の性質上、労働者の裁量を拡大することは、労力を際限なく投入した完成度の追求という事態を招く危険性があります。働き方の選択肢を広げる意味で裁量を拡大しつつ、企業が労働者の管理責任を適切に果たすことを、より明確に求めていく必要があると思います。