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

　前回のブログでは、やることがどんどん増えて時間が足りなくなる、「技術的負債による負のスパイラル」の話をしました。今回は、どうやったら負のスパイラルから抜け出せるのかという話です。

本質的な解決策

　忙しさから逃れるためには、次の２つしか方法がありません。「やらないといけない仕事を減らす」「仕事を短時間でできるようにする」です。これは、皆わかっているのですが、そのための対策としてはこんな感じになることが多いように思います。

　やらないといけない仕事を減らす

　　　→ 仕事のやり方を見直し、無駄どりをする

　仕事を短時間でできるようにする

　　　→ IT化や自動化を進め業務の効率化を行う

間違ってはいませんが、負のスパイラルに陥っている場合、それで解決するかというと非常に疑問です。そういうレベルの問題ではないような気がします。やらないといけない仕事がどんどん増えていく状態では、無駄どりや効率化の対策だけでは追いつかず、なかなか解決は難しいでしょう。

　ここから本質的な解決策を３つ挙げます。最初に言っておくと、全て大きな労力とコストと時間がかかる解決策であり、簡単ではありません。これを読んでいる技術系管理職の多くの方にとっては、かなりハードルが高いように感じられるかもしれません。しかし、負のスパイラルにハマってしまった状態では、お手軽な解決策は焼石に水になりあまり機能しません。本当に解決したければ、時間をかけてでもやるしかありません。

1. 　対応する製品の数を減らす。

　当たり前のことではありますが、やらないといけない仕事を減らすのに一番効くのは、対応しなければならない製品を減らすことです。技術部門が対応しなければならないのは、現在販売している製品ラインナップだけではありません。過去に販売し市場に出ている製品へのサポートなどの対応も必要です。

まず、無闇に多くの製品ラインナップを抱えすぎていないか製品の棚卸しをし、同系列の製品の中で、似たようなラインナップになっているものは統合し、その他のものは生産を中止します。また、顧客への提供後あまりにも長期間使われているものがないかを調べ、顧客に対し新たな製品への更新を促します。可能なものはサポートを中止していきます。

　この解決策は、かなりハードルの高いものです。そもそも、企業の事業戦略と密接に関係しますので、技術部門の判断だけで決められるものではありません。関係部門と深く話し合う必要がありますし、市場や顧客との関係で難しいことも多いでしょう。また、その製品への対応をやめてしまった場合、事業にどのような影響があるかを評価し判断するのも簡単ではありませんし、なかなか結論が出ないかもしれません。

　それでも、技術部門は、製品の数について声をあげていくべきだと思います。関係部門や顧客を巻き込んででも、製品の数を減らす努力は絶えず継続していくべきだと思います。顧客ニーズの多様化、技術の専門化が進んだ今日では、いわゆる「フルライン戦略」を取ることができるのは、質量ともに経営リソースが豊富な非常に少数のリーディング企業に限られます。そこまでのリソースのない企業で事業を持続可能なものにするためには、新たな製品を登場させる分、やめることも必要なのです。技術リソースを把握している技術部門の意見は絶対に必要です。

2.　設計を標準化する

　負のスパイラルを何処かで断ち切りたいところです。やはり設計のとことろで断ち切るしかありません。いかに、時間をかけずに、品質問題を起こさない設計を行うかということに尽きるかと思います。設計で問題が発生する要因としては、いくつかのパターンがあります。

派生開発を繰り返すことによる問題

　製品の開発には大きく分けて、一から新たに開発を行う「新規開発」と、開発済みの製品に変更を加えて開発する「派生開発」があります。製造業の場合、同じ種類の製品を販売し続けることで収益を得るのが本筋の事業モデルなので、ほとんどの場合が派生開発です。

　派生開発の問題は、これを繰り返しているうちに、当初の設計意図や根拠が失われ、結果として品質を劣化させてしまうことです。派生開発のみを行なっている人は部分的な変更や機能追加しかしないので、元々の設計の意図や根拠を理解せずに、一部のみを見て設計をしてしまいます。その結果全体としての整合を欠き、製品の品質を低下させます。

設計の属人化の問題

　設計のために必要な知見を一部の人しか持ち合わせておらず、これが他の人と共有されていないような状態です。知見を持っている人が多忙で、設計にアサインできなくなった時に、他の人が抜け漏れのある品質に問題のある設計をしてしまう問題が起きます。知見を持った人が設計をする場合でも、限られた時間の中で片手間で設計してしまうとやはり問題をおこしてしまいますし、知見のない周りの人は問題になかなか気付けません。さらに、設計の進捗は知見のある人に依存し、この人がボトルネックとなった場合に工程が大幅に遅延するリスクがあります。

　これを解決するキーとなるのは「設計の標準化」です。これにより、派生開発の繰り返しによる品質問題の発生を極小化し、設計に関する知見を共有し属人化を防ぎます。主に製造業では、多品種少量生産に対応するために、製品の多様化を進めつつできる限り部品種類を減らしてコストダウンを図ることを目的とした標準化が行われてきました。最初は、単に製造のコストダウンのために部品を共通化する目的で考えられていましたが、今では、設計の手順や製品のアーキテクチャそのものも標準化するという考え方が導入されており、上記の問題の解決策になり得ます。

　標準化の手法については、解説し出すと長くなりますので、詳細については今後別記事として書くこととし、今回は以下の２つを簡単に紹介するに留めます。

モジュラーデザイン

　モジュラーデザインとは、ハードウェアの開発において、互換性が高い少数の部品（モジュール）を事前に複数設計しておき、それらを組み合わせて多様な製品を設計する手法です。

　設計の手順を標準化し、構造化した上で、必要となる最適な部品を定義していきます。市場要求→製品仕様→製品システム構成（設計部品、生産部品）という順で設計を進め、「市場要求項目」と「製品仕様項目」さらに「製品システム項目」の関連を明らかにします。従来、設計者個々の暗黙知となっていた「どのような要求の変化に対してどの仕様で応え、それがをどの方式、機構で実現するか」の関連性を明らかにし、これを標準として定義します。

ソフトウェアプロダクトライン

　ソフトウェアプロダクトライン（Software Product Line）とは、ソフトウェア開発において、共用・再利用のためのソフトウェア資産を整備し、これに基づいて個別プロダクトを作り出すスタイルの開発アプローチです。製品のアーキテクチャを統一し、共用・再利用するためのソフトウェア等を「コア資産」として定義します。

　この標準化による解決策も、やはり簡単ではありません。標準化を行うには、製品への深い理解に基づく分析と設計が必要であり、時間とコストがかかります。標準化のためのプロジェクトを立ち上げ、数年を要するのが普通です。即効性がない上に時間がかかるので、この解決策に懐疑的な人や、従来のやり方にこだわる反対勢力も出てきます。標準化による効果を説明し納得してもらうことから始めなければなりません。でも、うまくいけばその効果は非常に大きく、負のスパイラルから抜け出す決め手になる可能性は高いのです。

3.　負債をコントロールする

　技術系管理職は、自組織のどの技術的負債に対応し、どのように減らしていくのかを適切にマネージメントしていく必要があります。

　エンジニアから見ると、直したい技術的負債はたくさんあるでしょう。しかし、その全てに対応するわけにはいきません。対応するにはコストと時間がかかるのです。ほとんど使われない機能のソフトウェアの不具合を治すために、コードきれいに書き直しても、それは単なる技術者の自己満足にすぎず、時間の無駄です。事業上の大きな問題となるもの、緊急を要するものを中心に優先順位を決め、リソースを確保し、計画的に技術的負債を減らしていくことが必要です。

　これも、言うのは簡単ですが実際は難しい問題をはらんでいます。技術的負債の優先順位をつける前提として、現状の技術的負債の大きさを評価する必要がありますが、どうやって評価するのでしょうか？

　・無償工事費、アフターサービス費などの品質に関わる経費の額

　・顧客からのクレームの数

　・問題の対応にかかった時間

など評価指標に使えそうですが、これらの指標が実態を表しているか、あるいは、どう計測すれば良いのかなどを自部門の実態に合わせて考える必要があります。

本質的な解決のために技術系管理職がするべきこと

　繰り返しになりますが、負のスパイラルから抜け出すのは簡単なことではなく時間がかかります。もしかしたら、効果が出た時には、現在の管理職であるあなたはこの組織にはいないかもしれません。管理職は、日々目の前の問題に追われています。とりあえず「今」をマネージメントすることに全力を注ぎ、ほとんどの時間を日々の問題に費やしてしまいます。しかし、それでは本質的な問題の解決にはならず、結果的にあなたの後輩にツケを回しているだけになってしまいます。自分が辞めた後に成果が出ることも一つくらいやっても良いのではないでしょうか？多少苦労しても、一定の時間は自組織の未来のために使ってもらいたいと思います。

　また、本質的な解決策を実際にやっていく際には、「わかりやすく説明して説得するスキル」「プロジェクトをマネージメントするスキル」「自部門の業務量を定量的に把握するスキル」などが必要になってきます。これらは、技術系管理職をやっていると、色々な場面で必要となるスキルです。基本的な知識は、色々な本やネットから得られますので一度勉強してみることをお勧めします。あとは実践で自分のものにしていくことになりますが、この際に考え方のヒントとなるような記事も、今後このブログで書いていこうと思います。（了）