第10回　設計開発リーダーの大切な役割、標準化と人材育成

　「品質は設計開発工程でつくり込め、垂直立上げだ」とよく言われる。ちなみに、会社員の頃は「今年が勝負、今年が変革の年」とも、なぜか毎年言われていたように思う。結局、設計開発の総合力が必要になる中、人も時間も限られた状況下では現実的にどのように対応すべきか？過去9 回、大切と思うことを紹介してきた。しかし、まだカバーできていない部分がある。設計開発の標準化と人材育成である。この2 点はリーダーの大切な役割であると筆者は考えている。

　「開発を標準化できるはずもないのだから、標準化よりも個人のスキルアップに注力すべき」との意見をよく聞く。しかし、常に創造的な仕事をしているわけではない。創造的な仕事に極力集中できるように、情報の整理整頓を行い、報告作業や設計開発の付帯作業の標準化を進め、組織の効率化を図ることがやはり大切になる。

　情報はエンジニアにとって非常に大切な仕事道具である。5S活動同様、必要なものが必要なときにすぐに誰でも使えるように、維持管理する必要がある。　

　そもそも、筆者はしばらくの間、たった一人で梱包容器の仕事を行っていたので、情報整理は特に気にせずにいた。しかし、メンバーが増え、リーダーとなったときに、過去の情報が整理されていなかったので、メンバーとの情報共有に非常に苦労した。始めはサーバーにフォルダをつくって資料を保管していった。仕事の合間を見て整理を行い、1 カ月程度で整理は終わったが、筆者の頭の中を整理しただけで、ほかの人から見れば使う気にもならないようなものでしかなかった。結局、試行錯誤を繰り返しながらメンバーに使ってもらえるようになるのに1 年以上かかったと記憶している。　

　情報整理に関しては指南書が数多く存在する。昨今のAI技術の活用も考えられるが、参考までに筆者の経験から大切と感じたことを紹介する。

　（1）用語の統一、定義の確認　
　筆者は資料を探したいときに、どこにあるかわからなければ、それらしき資料を片っ端から開く。それでも見つからなければ検索をかける。しかし、検索をかけても検索結果の資料が多すぎれば見る気が失せる。また、検索ワードが人により違うと、思っていた資料が出てこない。資料の中に記載する言葉にしても名前がいろいろあるとヒットしない。また、経緯がわかっていれば、これは名前が違うだけと判断できるが、そうでなければまったくわからない。例えば、製品名でも、例えば「○×A」が製品名であった場合、Aを記載していたり、いなかったり、名称そのものが商品名であったり、コードネームであったりする場合すらある。　

　上記のような一般的な話以外に、どこの会社でも部署内でしか通用しない用語がある。しかし、全員が同じ認識を持っていないと機能しない。皆が理解していると思っても、実は独自の解釈をしている場合も多い。標準化するには用語の統一、定義の確認がやはり必要である。

　（2）共通管理する情報は整理して絞り込む　
　過去の資料をサーバーに移動しても、資料を作成した本人が見てもパッと思い出せないような資料は、ほかの人が見てわかるはずがない。つまり、共有の情報にするには、ある程度整理することが必要なのである。筆者は、人に報告する資料はフォーマットを決め、それに沿った報告として記載するようにし、それ以外の資料は個人管理をする、と割り切って管理するようにした。結局、不明なところは人に聞くことになるのだが、ゼロから話すのと、不足しているところを補うのとでは雲泥の差がある。

　（3）分類は極力最低限に　
　分類は細かくしていくと、分類に添わない資料が入ってくるなど、余計な外乱が加わってしまう。「その他」のフォルダが出るようであれば、その時点で破綻している。資料の種類、対象機種、年度ぐらいの分類とし、分類に悩まない程度にすることが大切である。必要があれば検索すると割り切ることも重要である。大ざっぱな分類でも中に入っている資料がしっかり分類されていれば、あとは検索をかければよい。

　（4）コード化にはリストが必要
　コード化するにあたってリストが必要なものとして、筆者が使っていた中で言えば、図番が挙げられる。図面を検索する際には、図番で検索するのが一番である。しかし、図番を見て何が描かれているのかわかるように、図番の付与ルールを決めている会社も多いと思うが、徹底するのはほぼ不可能である。往々にして「これって何だったっけ？」となる。図番と内容が紐づけられるリストはやはり必要である。

　（5 ）仕組みをつくったら使ってもらい改善していく　
　資料をフォーマットで作成したり、用語を統一したりすることなどを面倒と感じ、メンバーからは「それでなくても忙しいのに…」と不満が出る。しかし、それでもリーダーが推進していくしかない。そもそも使用に耐えられないレベルであれば仕方がないが、初めから100 点はあり得ない。実際に使っていかないと完成度も上がらない。権限も伴うため、リーダーが「これは自分の仕事だ」と思うことが最初の一歩かと思う。「成功の秘ひ訣けつは成功するまでやめないこと」と何かの本に書いてあったような気がするが、そういった考えが情報整理には大切であると感じている。

　設計開発の報告業務は上記の情報の整理を行うことが標準化そのものと言える。報告業務以外にも、開発の手続きや権限など、ISO 9001の要求事項を参考に設計開発管理規定などにまとめたり、各種実験方法や実験装置など、誰がやっても同じ結果が得られる必要があるものは作業標準書に準じたドキュメントを整備したりすることが必要である。　

　製造現場の場合、品質管理、生産性の点で多くのノウハウを標準化に落とし込む必要があるが、設計開発の場合、クレーム対応などで標準書を見直す必要に迫られることもない。装置の校正は必要であろうが、作業標準書はあくまでも新人教育の資料と割り切り、手順を明確にしたいわゆる手順書レベルに測定時の注意ポイントを付記したもので十分だと感じている。

　（1）属人化のデメリット
　業務の属人化は短期的には効率的な面もあるが、長期的にはデメリットの方が大きい。一番のデメリットは、業務内容について誰もフォローできなくなることである。担当者にもよるが、説明、共有化するのは無駄、あるいは時間が取れないと考えてしまい、ますます自分を追い込む状況にもなりかねない。また、得られた知見が会社の知見として蓄積されていかない。

　（2） マネジメントの問題
　業務の属人化はマネジメントの問題であると筆者は考えている。人が足りないため、担当が一人しか付けられないのはよくわかるが、フォローできるメンバーがいないと孤立する。担当者に「報連相をしっかりとしろ！」と言っても、担当者を追い詰めるだけになりがちである。大切なのは、決めた管理規定に沿って仕事を進めることである。そうしないと、属人化することで何が問題なのか明確でないままになってしまう。例えば、レビューが有効に機能しないなど問題点が明確になれば、人員の補強を図るなど何らかの対策を考えることが必要になる。しかし、単純に人員を補強すればうまくいくといった話でもない。かえって、担当者に負担がかかる場合もある。　

　やはり、上司が担当者のところまでおりていって「本当に必要な対策は何なのか」、「上司と担当者の仕事の分担は適切か」、「この部分はほかに振れないか」、「この業務はいったんやめよう」などといったことを協議し、具体的なアクションを決めていく必要がある。その上で人員補強を図ったり、フォローする人を付けたりする必要がある。

　（3）流用設計（部品の共有化）
　連載第4回の「基本設計􀃶基礎開発の段階で大切なポイント」で紹介したが、部品の共通化（流用設計）は、リーダーがコンセプトを確定させる際に明確にすることが大切である。設計開発は何をするのかを決めるのも大切であるが、しないことを決めるのも大切である。　

　流用設計と言いながら、似て非なるものができることが往々にしてある。取付け穴の位置が違うといった類の問題である。そうなると部品手配の工数が増え、管理も煩雑になり、ヒューマンエラーも誘発しやすい。また、国により調達できない部品もあるので注意が必要である。　

　設計初期にリーダーが流用設計の必要性をしっかり説明し、デザインレビューでフォローしていくことが大切になる。国によって調達できない、あるいは調達しにくい部品は互換性のある調達可能な部品を明確にすることも大切になる。