8D.wiki

マインドセットを変革する #10 — 結果ではなくプロセスを管理せよ

8D.wiki 編集部 — AI の支援で下書きし、創設者が査読・編集・組版したうえで公開しています。事実・数値・表・用語は公開前に確認します。
査読・組版: Alvin Jin — IATF 16949 専門家 · 認定 Product Engineering(PE)コーチ · DRBFM 専門家
Published 2026-10-25 ·  Last reviewed 2026-10-25

結果は管理できず、プロセスは管理できる。要求工学における引き出し、分析、レビュー、ベースライン化、変更管理、トレーサビリティを管理すれば、製品品質・納期・顧客満足は自ずとついてくる。プロセス管理の正しい在り方は、マイクロマネジメントでも放任でもなく、権限委譲されたチームループ上で動的に働くことである。

> TL;DR: 結果は管理できないが、プロセスは管理できる。プロセスを正しくすれば結果はついてくる。要求工学はその最も明快な例である。引き出し(Elicitation)、分析、レビュー、ベースライン化、変更管理、トレーサビリティを管理すれば、品質・納期・顧客満足は自ずと達成される。プロセスを管理する正しい方法は、「権限委譲されたチームループ(Empowered Team Loop)」上で動的に働くことであり、マイクロマネジメントでも放任でもない。 結果は制御できないが、プロセスは制御できる ここで提示する命題はこうである。結果ではなくプロセスを管理せよ——結果は制御できないが、プロセスは制御できるからである。プロセスを適切に管理すれば、結果は自ずとついてくる。 こう反論する人もいるだろう。私の上司は結果志向で、成果しか見ない、と。確かにその通りで、多くの上司がそうであり、それで構わない。しかし上司はプロセスを管理する必要はなく、良い結果さえ見えればよい。実際に仕事をする側であるあなたは、まさにプロセスを管理する必要があるのだ。 月探査計画の主任科学者は印象的な言葉を残している。月への旅は97%が進路修正である、と。宇宙船は月まで直線的に飛行することはできず、途中で実際の状態と偏差を継続的に調整して初めて到達する。月面着陸がそうであるなら、日常の仕事も当然そうである。結果は願うだけでは決して得られず、プロセスの中で観察・判断・調整を繰り返すことで一歩ずつ合わせ込まれていくものである。 プロセスを管理すれば結果はついてくる 次に業績評価を見てみよう。多くの企業はプロセスより結果を重視する。KPIを達成し、目標に到達すれば、その過程を誰もあまり気にしない。その結果どうなるか。一部の従業員は手段を選ばず成果を追い求め、社内外に多大な摩擦を生み、企業は有害な状態に陥る。 だからこそ私たちはむしろプロセスを評価したい——どこで誤ったのかを見つけ、時機を得て是正するのである。私たちは一つの原則を堅持する。プロセスが正しければ、結果は必ず正しい。 「結果だけくれ、プロセスのことは気にするな」と言うのはやめよう——プロセスは制御でき、結果は制御できず、この因果関係は逆にはできない。企業がプロセス管理に注力すれば、良い結果は自然についてくる。これらのことを毎日きちんと行えば、成果は自ずと達成されるのだ。 事例:要求工学におけるプロセス管理 プロセス管理の価値は、要求工学において最も明確に現れる。要求工学とは何か。それは製品開発の出発点であり、顧客と市場の声を明確で検証可能なエンジニアリング要求に変換し、設計・開発へ引き渡すことである。 要求自体が曖昧で変動しやすく、見落としやすいため、要求工学はプロセス管理されなければならない。 「製品を作り上げる」という結果だけを見つめ、要求を生み出すプロセスを管理しないままにすれば、結果はたいてい苦痛を伴うものとなる。 ある車載電子プロジェクトを例に取ろう。顧客の要求は曖昧だった。「機能は使いやすいものであること」とだけあり、何をもって使いやすいとするのか、どのような条件下で、どこに境界があるのかの定義はなかった。レビューでは「ほぼ十分」と判断され、そのまま通された。その後、金型を切削し、試作品を車両に取り付けた段階になって、顧客は挙動が期待と一致しないことを発見した。すべてをやり直す必要が生じた——要求の再定義、設計のやり直し、金型の再切削である。コストは何倍にも膨れ上がり、納期は何度も遅延した。 適切に管理された要求プロセスは端から端まで連携している。引き出しの後には分析が続き、分析の後には文書化された要求定義が続き、定義の後には厳格なレビューが続き、レビューの後にはベースライン化が続く——その後はあらゆる変更が変更管理を経なければならない——そして要求トレーサビリティが、すべての要求をその設計と検証に対応付ける。 同じプロジェクトでも、プロセスを管理したかどうかで結果は正反対になる。プロセスを管理していれば、曖昧な要求はレビュー段階で止められ、手戻りは決して起こらない。管理していなければ、問題は下流工程へ「通されて」しまい、数倍のコストで噴出する。 教訓はこうである。要求工学の結果——製品品質、納期、顧客満足——は、結果を追い求めることで管理し生み出されるものではない。引き出し、分析、レビュー、変更管理、トレーサビリティのそれぞれが適切に管理された後に、自ずと達成されるのである。 プロセスの管理とは権限委譲されたチームループである プロセス管理を理解するための印象的なモデルがある。リーダーシップ成熟度の「ポテトモデル(Potato Model)」である。リーダーの作業負荷とチームへの貢献価値を2軸とし、すべてのリーダーが抱く問いに答える——なぜ私はこんなに忙しいのか、そしてより大きなことのためにどう自分を解放すればよいのか。 このモデルには「権限委譲されたチームループ(Empowered Team Loop)」が含まれており、十分な委譲と真の余裕が実現した状態に対応する。そのループ上で働くことは楽に感じられる。わずかな努力で仕事が片付くのは、委譲度が高く、心配すべきことが何もなく、作業負荷が下がり続けられるからである。 プロセス管理とはまさにこの権限委譲されたチームループである。それは自ら手を動かすマイクロマネジメントでも、完全な放任でもなく、ループ上で動的に働くことを意味する。チーム、その能力、その成果への把握が確かなものに感じられれば、少し手を引く。しばらくして理解がずれてきたら、仕事の一部に再び入り込む——必要なら多く投資し、不要なら少なくし、そのリズムを自分の手に置くのである。 したがってプロセスを管理するとは、掴んだまま決して離さないことではない。プロセスを理解し、常にそこに踏み込み調整することである。緩めるべきところは緩め、締めるべきところは締め、常に正しい軌道に保つ。プロセスが軌道に乗れば結果も軌道に乗る——これが権限委譲されたチームループの本質である。 管理行動は二つの方向のいずれかに沿って進化する。チームから離れてマイクロマネジメントへと漂流する負の道か、チームから学び、チームと共に働き、最終的にチームに権限を委譲する正の道かである。同じチームでもプロセスを管理するかどうかで結果がまったく変わるのと同様に、リーダーがどちらの方向へ進化するかは、プロセスを権限委譲されたチームループ上に保ち続けられるかどうかにかかっている。 一行まとめ 結果は制御できず、プロセスは制御できる。プロセスを適切に管理すれば結果は良くなる。要求工学の事例は、引き出し、レビュー、変更、トレーサビリティを管理すれば、製品品質・納期・顧客満足が自ずと達成されることを示している。そしてプロセス管理の正しい姿勢とは、ポテトモデルの権限委譲されたチームループである。放棄でも独占でもなく、状況の変化に応じて動的に調整し、常に軌道に留まることである。プロセスを軌道に乗せておけば、結果は信頼できるものとなる。

Related articles

8D.wiki — Quality Engineering Knowledge Base