技術系管理職はなぜいつも忙しいのか　 〜製造業における技術的負債の話〜　（１）

　私は、長年、製造業の会社に勤務しており比較的成熟した事業の製品を多く扱っていました。成熟した事業の技術部門は、仕事のやり方が効率化・定型化されているのであまり多忙にならないイメージがあるかもしれませんが、実際には慢性的に多忙という状況が数多く見られます。なぜこうなってしまうのでしょうか？他のメーカーでも同じような話はよく聞きますので、何か共通した理由があるようです。

慢性的に多忙な製造業の技術系管理職

　忙しいこと自体は本来それほど悪いことではありません。しかし、やらないといけない仕事が溢れかえり、やってもやっても仕事が減らないと感じる「慢性的な多忙」は、管理職を始めとした組織のメンバーを精神的に追い込みます。その結果として、新たな取組みに対して大変消極的になります。「取組む時間がない」「余裕がない」「人がいない」と感じるからです。「それでなくてもやることがたくさんあるのに、これ以上仕事を増やさないでくれ」となってしまいます。しかし、組織は生き物と同じで、環境にあわせて新たな取組みをし続けないと生き残っていけません。これは非常にまずい状況です。

　組織が慢性的な多忙になっている原因の多くは、過去に開発・製造・販売してきた製品に起因しています。過去に開発した製品の量産開始後や市場クレームの設計起因問題への対応のための調査や検討や報告に多くの時間を割くことになってしまい、本来注力すべき、新たな製品の設計検討や試作試作評価実験に時間が割けない事態に陥るのです。

　管理職もこの状態が良くないのはわかってはいるのですが、有効な手が打てず結局目の前の問題にかまけて対策ができずに、次の管理職に同じ状態（もしくはさらに悪くなった状態）で引き継ぐことになってしまう事例をよく目にします。

技術的負債

　どんな組織でも、過去の製品に何にも問題がないというのことはまずあり得ないので、少なからず過去の問題への対処が必要になります。

　ソフトウェア開発には、技術的負債(technical debt)と言う言葉があります。設計段階において、時間がかかるより良いアプローチを使用する代わりに、すぐできる簡単な（限定的な）解決策を選択することで、後々に追加の変更や修正のコストが発生することを「負債」に例えたものです。金銭的な負債と同様に、技術的負債も返済されなければ「利子」が蓄積され、時間が経つにつれて最初の問題を修正するために必要なコストが増加していきます。

　技術的負債は常に良くないというわけではありません。例えば、プロジェクトの締め切りを守り、時間内にソフトウェアをリリースするために、一時的に技術的負債を作るケースがあります。この場合、負債は意図的なものであり、負債を認識しコントロールすることが可能です。負債を計画的に返済できれば、大きな問題にはなりません。一方で、開発プロセスにおける抜け・漏れや技術的判断の誤りから生じた技術的負債は、意図していないものでありコントロールが難しく、大きなリスクとなります。

製造業における技術的負債

　製造業の場合、企業が提供する製品の種類は複数あり、同じ種類の製品でも複数のラインナップがあります。設計部門はこれらの設計全てを行う必要があります。また、過去に出した複数のモデルが市場で使われており、これらに設計に関連する（関連する可能性がある）問題があった場合にはやはり設計部門が対処しなければなりません。現在設計中のものだけでなく過去の製品への対処も必要で、この数は下のようになります。

機種数　x 　ラインナップ数　x　市場で動いているモデル数

個別生産の製品の場合は、顧客ごとに個別の製品があり、設計部門が対処しなければいけないもの数はやはり多くなります。

　もし、これらの多くが「技術的負債」を抱えていたらどうなるでしょうか？いわゆる「多重債務」の状況になってしまいます。こうなると、当然のように慢性的に多忙な状況になります。

負のスパイラル

　製品の設計に大きな問題があり、対処に大幅に時間がかかってしまったり、さらに対処をしないといけない製品の数が増えて積み重なると、やることがどんどん増えて時間が足りなくなってしまいます。

　量産開始後や市場投入後に発生した、設計に起因する問題の対処には大きな労力とコストがかかります。製品の市場投入遅れや、市場に出した製品の回収などの大問題に繋がるため、問題の解決が最優先事項になります。他の作業を止めて、問題の解決に人員を投入することになります。特に、製品を熟知している数少ない優秀なキーエンジニアは間違いなく問題の解決に駆り出されます。問題が早期に解決できれば良いのですが、設計の上流に起因する問題に根本的に対処するためには、設計、検証をやり直すことになります。人員の数をかけた分短期で解決すると言うものでもなく、時間が多くかかります。根本的な解決ではなく、対処療法的なやり方を取ると、大抵の場合違う問題を引き起こし、これに対する対処にまた時間がかかります。

　こうやって目の前の問題の対処が長引いているうちに、次の製品プロジェクトの設計が始まってしまいます。本来、前の開発プロジェクトを振り返り次の製品の設計で改善すべきなのですが、振り返りをするところまでいかず、発生した問題のフィードバックが十分にされなくなります。問題の解決に投入されている優秀なキーエンジニアは、本来、次の製品の設計に腕を振るい、設計作業を通じて人材を育成するはずだったのに、次の製品の設計をする時間が取れなくなります。若手技術者は放置され適切なアドバイスを受けることができなくなります。

　結果として次の製品も場当たり的な設計になり、また次の品質問題を生み同じことを繰り返すことになってしまいます。また、根本的な対処ができていない製品が市場に出てしまうと、将来大きな問題が発生するリスクが大きくなります。設計から時間が経ってから発生する問題に対処するのはさらに大変になります。このように製品の品質問題が積み重なっていくことにより益々時間が取られていきます。

　一旦このような状況に陥ってしまうと、状況はどんどん悪化し抜け出ることが難しくなっていきます。いわゆる負のスパイラルです。現代の製品は、昔に比べ機能も増え、複雑になっていますし、顧客の要求に応えるために製品の種類も増える傾向にあるので、このような状況に陥りやすくなります。忙しい技術部門の多くがこのような状態になっています。

効かない対策

　負のスパイラルの状態から抜け出すためにはどうしたら良いでしょうか？よく見られる定番の解決策としては、「人員の投入」「問題の再発防止のためのチェックリスト」があります。しかし、これらは、手っ取り早い以下の解決策ではありますが、負のスパイラルに入ってしまっている部門にとっては、本質的な問題の解決にはならず、多くの場合有効に機能しません。

人員の投入

　品質問題解決のために、追加人員を投入すると言う解決策です。場合によっては他部門の優秀なエンジニアを投入し、品質問題を早く収束させようとします。設計の問題は人の数で解決しないのは言うまでもありませんが、だからと言って他の製品を担当している優秀なエンジニアが入るとすぐに解決するかというと、必ずしもそうでもありません。

　ある程度問題の原因が切り分けられていれば、その技術に詳しい人を投入すると効果はありますが、それ以前の原因を特定するまでのところに時間とコストがかかってしまいます。原因を特定するには、どこに可能性があるかを推定していく必要がありますが、その製品がどう使われているかの背景の理解と、その製品自体についての知識が必要です。製品の設計業務はかれ少なかれ属人化しているので、他の人を投入しても即効性は薄く、すぐに効果が出るわけではありません。問題の起きている製品に対する深い見識がある人が追加で投入できれば、効果がありますが、そのようなケースは稀です。

チェックリスト

　設計チェックリストとは、設計の抜けや漏れを防ぐために、チェックすべき事項をリスト化したものです。先に言っておきますが、このリスト自体は設計プロセスにおいて必要不可欠なものであり、決してこれがいらないと言うわけではありません。ただ、負のスパイラル状態に入ってしまうと、チェックリストに書かれる内容がおかしくなっていき、うまく機能しなくなるのです。

　大体の技術部門では、問題が発生するたびに再発防止策の策定が義務付けられています。負のループに入ってしまい、再発防止策を考える時間が取れない部門では、手っ取り早く今すぐできる対策に走りがちです。「発生しないようにチェックリストに追加する」はその意味で”人気がある”対策です。手っ取り早く時間をかけずに対策とするために、結果として表面化した問題の裏返しだけがリストに書かれます。例えば、「Xの場合Yの寸法はZ以下としているか？」などが書かれます。Z以下でないといけない理由は書かれていません。またX以外の場合はどうなるのかも書かれません。なぜそうなったかの本質的な問題には踏み込んでおらず、これ自体が非常に抜け漏れの多い場当たり的な対策になってしまいます。

　このやり方のもう一つの問題点は、問題が発生するたびにチェックする項目がどんどん増えていくと言う点です。チェック項目があまりにも多くなりすぎると、設計者にとって非常に大きな負担になり、チェックリストは実質的に使われなくなってしまいます。使われもしない形骸化したチェックリストだけが無駄に大きくなっていきます。

　では、本質的な解決には何が必要なのでしょう？　（続く）