設計部長が知らないと損する、図面検索の本当のコスト——年間1,200時間が消える理由

設計部長が知らないと損する、図面検索の本当のコスト——年間1,200時間が消える理由
banner_01

「うちの設計者は図面検索に1日30分しか使っていない」——この回答を真に受けて投資判断を見送った設計部長が、半年後に「再設計の手戻りが想定の3倍」と頭を抱える光景を、この1年で何度も見てきた。検索時間だけを測ると、設計部全体のコストの3〜4割を占める「検索を起点にした判断遅れ」が完全に視界から消える。本稿は、図面検索コストを「秒数の合計」ではなく「設計判断のリードタイム」で再定義し、10名規模の設計課で年間1,200時間が静かに溶けている構造を分解する。読み終えたとき、月曜の朝礼で部下に投げかける質問が変わっているはずだ。

なぜ「検索時間の集計」では本当のコストが見えないのか

多くの設計部門で行われている検索コスト計測は、おおむね「設計者にアンケートで自己申告させる」「PLMのログから検索クエリ回数を数える」のいずれかだ。前者は過小申告バイアスがかかり、後者は「検索したが見つからず諦めた」「検索結果を眺めて流用を断念した」という不可視の時間を取りこぼす。結果として現場から上がる数字は「1人1日10〜30分」、年間に直すと約60〜120時間に収まる。これを見て「全社で数百時間程度なら、いまの体制で十分まわる」と判断する経営会議は珍しくない。

しかし、設計部の現場で実際に起きているのは「検索」という単独動作ではない。新規案件で類似ユニットを設計するとき、設計者の頭の中では概ね次の連鎖が走る。①過去案件の図面を探す→②見つからないので類似品番を流用候補に挙げる→③流用判断のため先輩や品質保証に確認を投げる→④回答待ちのあいだ別タスクに切り替える→⑤戻ってきて結局新規設計を選ぶ。このうち①の「検索」は数分でも、②〜⑤に伴う待ち時間・コンテキスト切替・再設計工数を含めると、1案件あたり半日から2日が消える。これが「検索起点の意思決定コスト」の正体だ。

国内の設計現場ヒアリングで筆者がよく耳にするのは「同じ部品を3回設計し直した」「既存図面が見つからず外注に丸投げした結果、社内ノウハウが流出した」「検索したが古いリビジョンで判断し、量産後に不適合が出た」といった事例だ。これらは検索時間の集計表には1秒も計上されない。ところが原価には確実に乗る。10名の設計課で月10件の流用判断が走るとして、平均1.5日/件の意思決定遅延を仮置きすると、年間1,200時間(150人日)が失われている計算になる。これは設計者1人分の年間稼働に匹敵する規模だ。

年間1,200時間が消える4つの構造

構造1:検索クエリの「ゼロヒット」が記録されない

PLMやファイルサーバの検索ログを開いたとき、最も注目すべきは「ヒット件数ゼロのクエリ」と「結果を1件もクリックしなかったクエリ」だ。多くの組織はクエリ総数しか見ていないが、本質的なコストはこの2種類のクエリに潜んでいる。ゼロヒットは「探しているが存在しない or 命名規則が違う」、ノークリックは「結果が出たが判断に使えない」を意味する。前者は再設計、後者は流用判断ミスに直結する。ある自動車部品メーカーでログを分析したところ、全クエリの27%がゼロヒット、18%がノークリックだった。つまり検索の半分弱は意思決定に貢献していない。にもかかわらず、設計者は「検索した」とアンケートに回答する。アンケート集計が実態を映さない一次原因はここにある。

構造2:「命名規則の世代交代」が検索を機能不全にする

10年以上稼働している設計部門の図面ファイル名を時系列で並べると、命名規則は平均して2〜3世代ある。「品番+日付+設計者名」「案件コード+顧客略号」「3DCAD自動採番」が混在し、世代を跨いだ検索ができない。新人設計者は最新世代の規則しか知らないので、10年前の優れた設計が事実上ロストする。ベテランは頭の中の対応表で検索するが、その人が退職した瞬間に検索精度は崩壊する。これは「検索ツールの問題」ではなく「ナレッジ継承の問題」であり、検索ベンダーを入れ替えても解決しない。設計部長が問うべきは「検索ツールは何を使っているか」ではなく「命名規則の世代をいくつ抱えていて、世代間の写像が誰の頭の中にあるか」だ。

構造3:「設計意図」が図面に残っていないため、見つけても使えない

仮に図面が見つかっても、なぜその寸法・材質・公差を選んだのかが図面に残っていなければ、流用判断はできない。設計者は安全側に倒して新規設計するか、ベテランに口頭確認することになる。設計意図の記録は本来、設計レビュー議事録や3Dモデルの属性に紐づくべきだが、議事録は別フォルダ、3D属性は空欄、というのが平均的な姿だ。SPESILLをはじめとする最近の設計ナレッジ基盤は、図面・モデル・議事録・要求仕様を1つのレコードに紐付けることで、この「見つけても使えない」状態を解く方向に進化している。SPESILLは仕様書管理ツールという紹介をされがちだが、実態は「設計意図の構造化リポジトリ」であり、図面検索の出口に意図メタデータを返す設計になっている点が本質だ。

構造4:「問い合わせ往復」のリードタイムが二重計上されない

設計者が流用判断に詰まったとき、品質保証や購買、生産技術に問い合わせるのは正しい行動だ。問題は、その問い合わせが非同期チャットやメールで行われ、回答までの平均リードタイムが2〜3営業日に達することだ。設計者はその間、別タスクに切り替えるが、戻ってきたときに頭の中のコンテキストを再構築するために30分から1時間を費やす。これが「コンテキストスイッチ税」と呼ばれる隠れコストで、認知科学の研究では複雑タスクで最大40%の生産性低下が報告されている。設計部の場合、1案件あたり3〜5回の問い合わせ往復が走ると、それだけで2〜3日のリードタイム延伸になる。これは検索コストではなく「コミュニケーションコスト」に分類されるが、起点は「図面検索で答えに辿り着けなかった」ことにある。会計上の費目が違うだけで、根は同じだ。

4つの構造を合算するとどうなるか

10名の設計課を仮置きしてみる。年間案件数120件、うち流用判断が走るのが月10件=年120件。1件あたりの内訳を、ゼロヒット由来の再設計0.5日、命名規則ロストによる新規設計0.3日、設計意図不在による安全側設計0.4日、問い合わせ往復による遅延0.3日と置くと、合計1.5日/件。年間180日=1,440時間。設計者1人分の年間稼働(約1,800時間)の8割に相当する。本稿のタイトルで提示した「年間1,200時間」は、ここから2割を「不可避な検索行動」として差し引いた控えめな数字だ。読者の組織で実測したらもっと大きい可能性がある。

反論先回り——3つの典型的な反論に答える

ここまで読んで「うちはPLMを入れているから大丈夫」「3D CADの検索機能で十分」と感じた設計部長もいるはずだ。3つの典型的な反論に先回りで答えておく。

第一に「PLM導入済みだから問題ない」という反論。PLMは構造化データの管理には強いが、ゼロヒットクエリの可視化や設計意図の自然文検索は標準機能ではない。導入から5年経った組織ほど、検索体験が業務実態から乖離している傾向がある。第二に「うちの設計者はベテランだから頭の中で検索できる」という反論。これは短期的には事実だが、ベテランの暗黙知が個人に紐づくほど、退職・異動時のリスクが増す。属人化はコストの先送りだ。第三に「検索改善より新規設計の自動化のほうが効果が大きい」という反論。これは半分正しい。ただし新規設計の自動化は「過去設計を構造化して学習データにする」ことが前提であり、結局は検索=ナレッジ抽出基盤の整備に戻ってくる。順序を逆にすると自動化投資が空回りする。

次のアクション——来週の朝礼で投げる3つの質問

来週の設計課ミーティングで、次の3つを部下に問うてほしい。①直近1ヶ月で「探したが見つからなかった」案件は何件か、②そのうち再設計に流れたものは何件か、③再設計の判断は誰が、どの情報をもとに下したか。この3問の回答が即答できなければ、検索コストはまだ可視化されていない。可視化が先、ツール選定は後。順序を間違えなければ、半年で年間数百時間を取り戻せる。

自己診断チェックリスト

  • 直近1年で「過去図面を探したが見つからず再設計」した案件を、件数として把握している
  • PLM/ファイルサーバの検索ログから「ゼロヒットクエリ」を月次で抽出している
  • 設計部のファイル命名規則の「世代数」を即答できる
  • 設計レビュー議事録と図面が、同一レコードで検索できる
  • 流用判断の問い合わせから回答までの平均リードタイムを計測している

3つ以上「いいえ」なら、検索起点の意思決定コストは未可視化の状態にある。まずは可視化から始めるべきだ。

関連記事:業務OSの最前線

本記事で扱った「検索起点の意思決定コスト」は、設計部の業務全体を貫く「業務OS」の発想と直結する。ツール導入よりも先に、業務の流れと意思決定のリードタイムを設計し直すアプローチだ。

banner_01
記事一覧
広告 広告

関連記事

の最新情報をお届け

厳選した記事を定期配信
キャンペーン情報などをいち早く確認