新人エンジニアが初出図レビューで学んだ「仕事の型」と「先読み力」

はじめに：父として、エンジニアとして

はじめまして、シードと申します。現在、生後105日になる娘と、出産を終え里帰り中の妻と3人で暮らしています。

正確に言うと、今は一時的に「一人暮らし」の状態です。妻と娘は妻の実家でのんびりと産後の体を休めており、私はその間に仕事に没頭する毎日を送っています。窓から差し込む朝日を浴びて一人で目を覚ます朝は、少しだけ寂しさを感じますが、同時に「家族のために頑張ろう」という静かな活力が湧き上がってくるのを感じます。

私は現在の部署に異動してきて、まだ3週間ほどの新人です。毎日が新しい知識と経験の連続で、スポンジのようにあらゆることを吸収しようと必死にもがいています。そんな中、先日エンジニアとしてのキャリアで初めて「出図レビュー」というものに参加する機会がありました。

今回は、その出図レビューという場で私が体験し、学んだことを共有したいと思います。これは単なる業務報告ではありません。部署に配属されたばかりの新人エンジニアが、どのようにして仕事の「型」を学び、プロジェクトを円滑に進めるための「先読み力」の重要性に気づいたか、という成長の記録です。

ものづくりの現場で働く若手エンジニアの方、これから社会に出る理系の学生さん、そして「エンジニアって普段どんなことを考えて仕事してるの？」と興味を持ってくださるすべての方に、何か一つでも持ち帰っていただけるような、そんな記事を目指して綴ります。

第一章：そもそも「出図レビュー」とは何か？

「出図（しゅつず）」という言葉に馴染みのない方も多いかもしれません。これは、設計者が作成した製品の図面を、製造部門や品質保証部門、購買部門などの後工程の関係部署に正式に発行する行為を指します。いわば、設計者の頭の中にあったアイデアが、初めて「製品」という具体的な形になるためのパスポートを発行する瞬間です。

そして「出図レビュー」とは、そのパスポートを発行する前に、設計内容に問題がないかを多角的に検証する、非常に重要な会議体のことです。設計者にとっては、自分の成果物が厳しい目にさらされる、さながら「関所」のような場所と言えるでしょう。

なぜ出図レビューは必要なのか？

もし、この「関所」がなければどうなるでしょうか。設計ミスのある図面がそのまま製造現場に流れ、不良品が大量に作られてしまうかもしれません。必要な部品のコストが見積もられず、プロジェクトが大幅な赤字になるかもしれません。製品の安全性が担保されず、市場で重大な事故を引き起こす可能性だってあります。

こうした事態を防ぐため、出図レビューでは様々な分野の専門家が集まり、設計図面をあらゆる角度からチェックします。

品質保証部門：「この設計で、本当に顧客が要求する品質や耐久性を満たせるのか？」
製造部門：「この図面通りに、我々の設備で安定して生産することができるのか？」
購買部門：「この部品は、適切な価格で安定的に調達できるのか？」
営業部門：「この仕様は、顧客の要求を正しく反映しているか？」

これらの厳しい問いに、設計者は論理的に、そして客観的なデータに基づいて答えなければなりません。出図レビューは、設計者の独りよがりな設計を防ぎ、会社全体として「この設計で進む」という合意形成を得るための、ものづくりにおける民主的なプロセスなのです。

【雑学】図面の歴史：手書きから3D CADへ 今でこそパソコン上で3Dモデルをグリグリ動かしながら設計するのが当たり前ですが、ほんの数十年前まで、図面はすべて手書きでした。「ドラフター」と呼ばれる製図台に向かい、T定規やコンパス、烏口（からすぐち）といった道具を駆使して、設計者は一本一本、魂を込めて線を描いていました。そこには、線の太さや濃淡で情報を表現するような職人技が存在したのです。 1980年代以降、CAD（Computer-Aided Design）が登場し、製図の効率は飛躍的に向上しました。そして現在では、3D CADが主流となり、設計段階でコンピュータ上で組み立て（アセンブリ）や強度解析（シミュレーション）まで行えるようになりました。これにより、試作品を作る回数を減らし、開発期間の短縮とコストダウンに大きく貢献しています。出図レビューで議論される内容も、こうした技術の進化と共により高度で複雑なものになっているのです。

第二章：学び① レビューの「型」を知る – 承認者は何を見ているか？

さて、話を私の初出図レビューに戻しましょう。

私が所属するチームが担当していたのは、「A社向けに実績のある製品を、ハードウェアの変更なしでB社向けに転用する」というプロジェクトでした。つまり、ゼロから新しいものを作るのではなく、既存製品のカスタマイズ案件です。

私はまだ配属3週目ということもあり、このレビューで主担当として何かを報告する立場ではありませんでした。しかし、だからこそ客観的に、そして貪欲に学べる絶好の機会です。「承認者であるベテランのエンジニアたちは、一体何を気にしているのだろう？」「どういう説明をすれば、彼らは『よし、進めよう』と納得してくれるのだろう？」という2つの問いを胸に、私は会議に臨みました。

レビューが始まると、担当の先輩エンジニアがプロジェクトの概要を説明し始めました。当初、私は「レビューでは、開発中に困ったことや、一筋縄ではいかなかった技術的な課題を中心に話すのが良いのだろう」と漠然と考えていました。苦労話やそれをどう乗り越えたかというストーリーは、聞き手の興味を引きやすいと思ったからです。

しかし、レビューが進むにつれて、承認者たちの質問はもっと本質的な部分に向けられていることに気づきました。

「A社向けとB社向けで、要求仕様の違いは全て洗い出せているのか？」「ハードは同じでも、使われる環境が違うはずだ。その差によって新たに発生するリスクは検討したか？」「『問題ないはずだ』ではなく、『問題ないと言い切れる』根拠はどこにある？」

彼らが最も気にしていたのは、個別の技術的な課題解決のストーリーではなく、「ベースとなるA社製品からの変化点に対して、検討すべき項目が抜け漏れなく抽出され、一つひとつ潰されているか？」という、網羅性の証明でした。

ここで、私は最初の大きな学びにたどり着きます。

比較表こそが最強のコミュニケーションツール

レビューの終盤、あるベテラン承認者がこう言いました。

「会議の冒頭で、A社とB社の要求仕様や使われ方の違いをまとめた比較表を見せてほしかった。そこから、『この違いがあるので、我々はこの項目について再検証しました』という形で話を進めてくれれば、我々も全体像を把握しやすいし、検討の抜け漏れがないことも一目で確認できる。」

この一言は、私にとって目から鱗でした。

なるほど、レビューとは**「自分たちがこれだけ頑張った」という苦労を披露する場ではなく、「これだけ網羅的に検討したので、リスクは管理できています」という事実を、客観的かつ効率的に伝える場**なのだと。

そのためには、まず議論の全体像、つまり「どこが同じで、どこが違うのか」を明確に示すことが不可欠です。比較表は、そのためのいわば「航海図」のようなものです。この航海図を最初に示すことで、レビュアー（承認者）は「これから始まる議論は、この範囲内で行われるのだな」と安心して話を聞くことができます。そして、設計者はその航海図に沿って、「この海域（変更点）には、こんなリスク（心配点）がありましたが、このように対策（検証）したので安全です」と報告していけば良いのです。

もし自分が次にレビューをする立場になったら、必ずこの「型」に従おうと固く心に誓いました。最初に比較表で全体像を示し、変更点とそれに伴う検討項目を紐付けて説明する。この型さえ守れば、少なくとも「話が分かりにくい」と指摘されることはないはずです。

【追加情報】ビジネスフレームワーク「MECE」と「DRBFM」 この「抜け漏れなく」という考え方は、コンサルティングの世界などで使われるMECE（ミーシー） というフレームワークに通じます。「Mutually Exclusive and Collectively Exhaustive」の略で、「互いに重複せず、全体として漏れがない」状態を意味します。出図レビューにおいても、検討項目がMECEで整理されていることは、レビュアーに安心感を与える上で非常に重要です。

また、今回の学びに直結する設計手法として DRBFM (Design Review Based on Failure Mode) というものがあります。これはトヨタ自動車で開発された手法で、その名の通り「設計レビュー」に主眼が置かれています。DRBFMの最大の特徴は、「変更点」 に徹底的に着目することです。設計変更や用途の変更があった際に、「その変更によって、どのような心配があるか？」を関係者でブレインストーミングし、リスクを洗い出して対策を講じます。まさに、今回のレビューで承認者が求めていた思考プロセスそのものと言えるでしょう。

第三章：学び② 先手を打つ「予測力」- エンジニアは占い師であれ

もう一つ、このレビューで私の心に深く刻まれた学びがあります。それは、「予測力」の重要性です。

議題は、B社向け製品に課される「信頼性試験」についてでした。信頼性試験とは、製品が決められた期間、特定の環境下で、要求される性能を維持し続けられるかを検証するための、非常に過酷な試験です。例えば、高温や低温、高湿度の環境に製品を何百時間も放置したり、振動や衝撃を与え続けたりします。

今回のプロジェクトでは、ハードウェアはA社向けと同じです。しかし、顧客であるB社が要求する信頼性試験の基準は、A社のものとは一部異なっていました。担当チームは、そのB社の基準に従って試験を実施し、「無事に合格しました」とレビューで報告しました。

一見、何の問題もないように思えます。しかし、ここでもベテラン承認者から鋭い指摘が飛びました。

「その試験、実施する前に結果をある程度予測できていたか？ A社の試験結果という実績データがあったはずだ。そのデータと、B社の試験基準の差分から、『この項目は少し厳しいかもしれない』といった予測は立てていたか？」

そして、こう続けました。

「もし、事前に『不合格になるかもしれない』という予測ができていたのなら、試験を実施する前に、顧客であるB社に『A社での実績はこうです。貴社の基準だと不合格になる可能性がありますが、実用上は問題ないレベルだと考えます。基準を少し緩和していただけませんか？』と交渉する、という選択肢もあったのではないか？」

この言葉は、私に衝撃を与えました。

後追いから先読みへ

私はこれまで、試験というものは「決められた基準に合格するか否か」だけが重要だと思っていました。しかし、彼の指摘は、そのさらに先を見据えていました。

もし、多額の費用と時間をかけて試験を実施した結果、「不合格でした」となったらどうなるか。そこから設計変更を行ったり、顧客と基準緩和の交渉を始めたりすると、プロジェクトのスケジュールは大幅に遅延してしまいます。顧客がその製品を使って新しいサービスを始める計画を立てていたとしたら、そのビジネスチャンスを奪ってしまうことにもなりかねません。

そうではなく、すでにあるデータ（A社の試験結果）を最大限に活用し、未来（B社の試験結果）を予測する。 そして、その予測に基づいてリスクを先回りして特定し、最悪の事態を避けるための手を打っておく。今回のケースで言えば、それは「試験前の顧客への交渉」でした。

これは、単なる技術の問題ではありません。プロジェクトマネジメントの視点であり、ビジネスの視点です。エンジニアは、目の前の設計や試験だけに集中するのではなく、プロジェクト全体の成功、ひいては顧客のビジネスの成功まで見据えて行動しなければならない。そのためには、データから未来を読み解く「占い師」のような予測力が必要なのだと痛感させられました。

後から顧客に「申し訳ありません、試験に落ちたので納期が遅れます」と言うのは簡単です。しかし、プロフェッショナルな仕事とは、事前に「こうなる可能性があるので、こうしませんか？」と選択肢を提示し、顧客と共に問題を解決していくことなのでしょう。

【追加情報】信頼性工学とFMEA 製品の寿命や故障率を科学的に分析する学問を信頼性工学と呼びます。製品の故障率が時間と共にどう変化するかを示すバスタブ曲線は特に有名です。これは、使用開始直後に初期不良で故障率が高くなり、その後は安定した偶発故障期間を経て、寿命が近づくと摩耗故障で再び故障率が上がる、という傾向をU字型の曲線で示したものです。信頼性試験は、この曲線の各段階における製品の挙動を評価し、市場での問題を未然に防ぐために行われます。

また、今回の「予測」という考え方は、FMEA (Failure Mode and Effect Analysis：故障モード影響解析) という手法とも深く関連しています。これは、製品を構成する部品一つひとつについて、「どのような故障（故障モード）が起こり得るか」「その故障が製品全体にどのような影響を及ぼすか」を体系的に分析し、リスクの優先順位付けを行う手法です。事前に故障を予測し、影響の大きいものから対策を打っていくという点で、まさに「先読み力」を体系化したツールと言えます。

第四章：新人エンジニアがレビューを乗り越え、成長するために

今回の初出図レビューを通して、私は技術的な知識以上に大切な、仕事への向き合い方を学びました。それは、これからのエンジニア人生における、一つの羅針盤になるような気がしています。

最後に、今回の経験から得た学びを、私と同じように日々奮闘する若手エンジニアの皆さんへのメッセージとして、3つのポイントにまとめてみたいと思います。

1. 「Why」を問う：目的意識を持つ

レビューに参加する際、「何を話すか（What）」や「どう話すか（How）」ばかりに気を取られがちです。しかし、最も重要なのは「なぜこのレビューが行われるのか（Why）」という目的を理解することです。出図レビューの目的は、前述の通り、後工程に迷惑をかけず、顧客に価値を届けるための品質を保証することです。この目的さえ見失わなければ、おのずと「何を」「どう」話すべきかは見えてくるはずです。

2. 指摘を恐れない：全ては学びの機会

レビューで厳しい指摘を受けると、人格を否定されたかのように感じて落ち込んでしまうかもしれません。しかし、それは間違いです。レビューでの指摘は、あなた個人への攻撃ではなく、製品をより良くするための純粋なフィードバックです。むしろ、何も指摘が出ないレビューの方が危険です。多様な視点からの指摘は、自分一人では気づけなかった穴を埋めてくれる、貴重な学びの機会と捉えましょう。