“皆さん、こんにちは！
ここ最近は出張で名古屋にいることが多い、ちっしーです。
手羽先もひつまぶしもラーメンも美味しく、名古屋も良い土地やと、行く度に感じています！
まあ、故郷の関西が結局は一番居心地が良いですけどね（笑）
さて、本題になりますが「千里の道も一歩から」シリーズ第2弾のブログです。
ちなみに第1弾も是非一読下さい！
第1弾では、日程情報集約による一元管理に関しての事例を書かせて頂きましたが、第2弾では技術知見の見える化というまた違った観点での、業務改善の事例をお伝えしていきます。
読者の皆様の会社で、
ベテラン技術者の知見や経験が伝承されてなくて、有効活用できてへん・・・
ということはありませんか？
ベテランが持っている知見や経験が暗黙知となっており、後々困ってしまうことが多かれ少なかれあるのではないかと思います。
これによって下流工程からの手戻りや類似不具合の発生が増加する可能性も高まり、そうなると現場は残業や休日出勤で対応することになり、結果として疲弊してしまいます。また、それだけでなく、会社全体で見ても余計なコストが掛かってしまったり、製品の品質が担保できなくなってしまったりなど、会社の信用低下や売上・利益に繋がってしまうので、会社全体で見ても決して放っておけない課題と言えます。
また、そういった知見を定量的に残すことによって製品設計時にCAE（※1）を使ったシミュレーションで不具合を未然に防いだり、手戻り防止による工数削減に取り組んでいる会社もあります。
（※1）CAEとは「Computer Aided Engineering」の略称で、コンピュータシステムを導入して工業製品の設計や構造の解析、机上の試験などを効率的に行うことを指します。
今回は、上記のような抜本的な業務改善も見据えての小さな1歩目となる業務改善の事例を紹介します。
＜事例＞
図面に心配点や注意点などの知見を記載して見える化し、新規参画メンバーのキャッチアップに活用
第1弾の事例として挙がっていた製造業の会社様のコンサル案件で、こんな課題が出てきました。
- ピカピカの新入社員であるA君が設計部門に配属。けど、設計していく上での注意点や心配点が体系的に残っておらず、キャッチアップに時間が掛かってまうねん
- B先輩が来月末に異動することが決まった！この製品の工程設計はB先輩が主にやっていたので早急に引継ぎが必要なんやけど、口頭で伝える以外の手段が無いねん
- 開発途中で不具合が発生。暫定対応と恒久対応を検討する際に過去の不具合を参照したいが、紙でしか残ってないので探すのに時間が掛かってまうねん
自身も前職では製造業の会社様の業務システム開発に携わっていたのですが、上記と似たような課題が発生していました。システムリリース直後やシステムの保守時に、不具合が発生して対策を検討していました。経験が浅いのもあって慣れない状況でしたので、不具合対応方針を上司や先輩に相談したら「あ～似たような不具合対応を俺も昔やったわ～」とか「別のシステムで似たような不具合埋め込んでもうたことあるねん～」と言われたことがあり、心の中で「ほなら、その不具合が起きた事象や背景とかどんな対策を打ったとか、何かの形で残しといてや・・・」と心で呟いていました。
一方で「スキルを獲得するには、自分で痛い思いをして経験を得るのが一番やねん」という考えもありますが、全部が全部そうでも無いですよね。先人達がやってしまった失敗を再度やってしまって成長をしていくのは、長期的に見ても遠回りで勿体ない部分も多々あります。
上司や先輩が3年掛かって達成できたレベルに自分達も3年掛けて到達するのでは、今後業務に携わる人たちのモチベーション向上にも影響が出ますし、会社全体で見ても成長に繋がらないと考えています。
さて、話を戻しまして、先に述べた課題を解決するアプローチの事例を2つ紹介します。
知見の共有その１：ワークショップ形式
このような課題が発生している状況では、まずベテランが持っている知見がベテランの頭の中にしか無いことが多いのです。
なのでまずは泥臭いやり方ではありますが、頭の中にある知見を書き出すことから始めて行きました。どう進めたかと言うと、各種製品の主要な図面を印刷して、その図面に付箋でベテランの知見を貼っていきました。
ここでポイントの一つとなるのは、新人や若手も同じ場でワークショップなどの形でディスカッションしながら知見の見える化を進めていくことです。ベテランと若手が共同で進めることによってワークショップの場で知識伝承が行われますし、それを付箋でも良いので紙ベースで書いていくことで見える化にもなります。
そして紙ベースで書いた知見をエクセルやパワーポイントでも良いので電子上に残していくことで、後からも活用しやすい知見となります。
実際の進め方のイメージとしては、下図のようなイメージです。
知見の共有その２：レビュー形式
また、別の方法として、エクセルやパワーポイントなどの電子上に図面を貼り付け、そこにまずは若手が考えている知見を記載していき、それをベテランがレビューして内容を充実化させて若手に知見を伝承させていくことで、見える化する方法もあります。
これを一度のサイクルでも良いですし、可能ならば何度かサイクルを回すことで、より活用できる知見へと充実化させることが可能です。
ここでも若手とベテランがセットで進めていくことが重要になります。
実際の進め方のイメージとしては、下図のようなイメージです。
この知見を新規参画時に参照すれば技術的な内容のキャッチアップも早まりますし、類似不具合を発生させる可能性の低減にも繋げることが可能です。そうなるとベテラン層にとっても効率良く知識伝承ができますし、効率化できた時間で新しい仕事にもチャレンジすることができるので、新規参画者とベテランの双方とも嬉しさを得られるのです。
あと、意外に多い意見が、今まで人の頭にしか無かった知見を体系化させるプロセスを経ることで、ベテラン層にとっても頭の整理に繋がって理解が深まり、他の人への説明もしやすくなったという声も多いです。
また、この知見を陳腐化させない運用を考えていくことも重要です。
よくあるのが、コンサルが入っている間は、知見をとりあえず入れて見える形にした！となるのですが、いざ自走するで！となると、時間が経つにつれて知見が陳腐化されてしまい、結局活用されないことがよくあります。
こうならないためには、例えば下記の運用を決めていくことが有効です。
※細かい運用はまだまだありますが、これを意識するだけでもだいぶ運用には乗せやすいです。
- 新入社員や中途社員がどのタイミングで知見を参照すれば良いのか
→単に参照！ではなく、「☆」付きのコメントは設計時の心配点なので、設計メンバーが参照など - 知見の更新はどのタイミングでやるのか
→開発がひと段落した後？DR（※2）が終わった後？など - 開発完了時の振り返りで活用
→新入社員や中途社員からのコメントも残すことで、知識が浅い人でも分かりやすい知見にブラッシュアップ
（※2）DRとはDesign Reviewの略称で、開発における成果物を複数の人にチェックしてもらう機会を指します。
上記の観点を意識して、知見の見える化→知見の活用→知見のブラッシュアップのサイクルを回していけると、知見の陳腐化を防ぐことが可能です。また、図面上で蓄積した知見をFMEA（※3）などの帳票に反映できる仕組みも、簡単なものであればエクセルのマクロで実装することも可能なので、そう言った仕組みを作るのもさらなる業務改善の一つの方法になり得ます。
（※3）FMEAとはFailure Mode and Effect Analysisの略称で、故障・不具合の防止を目的とした潜在的な故障の体系的な分析方法の一つであり、その際に帳票を用います。
こう言った見える化をしていくことで、初めに述べた「データを活用しての業務改革で不具合未然防止や設計工数削減」の実現に繋げることが可能になります。
一足飛びに業務改革を行おう！とやっても、中間管理職や現場が付いていけずに組織面で歪が生まれるなど、うまく行かないことも多いので、まずは見える化による知見の集約という小さな業務改善から取り組んでいくのがええで！という事例紹介でした。
簡単な内容ではありますが、内容伝われば幸いです。
弊社では、こういった業務改善のサポートも承っているので、少しでも関心のある方は是非ご連絡下さい。
第3弾として別の観点での小さな業務改善事例も紹介する？かもしれないので、ぜひぜひお楽しみに！！”