第1章｜変革との出会い
――数字を追うほど、目標は逃げていった
なぜ、変革について考えるようになったのか
私が「変革」や「改善」という言葉を真剣に考えるようになったきっかけは、実はとてもシンプルな違和感からでした。事業責任者として、売上や利益といった結果を追い続けても、なぜか手応えがない。数字を追えば追うほど、目標は逃げていくように感じられました。
当時、私は次第にこう思うようになります。結果を直接コントロールしようとしても、うまくいかないのではないか、と。
そこで視点を変え、「売上はどのようなプロセスで生まれているのか」、「どのお客様に、何を、どのように届ければ利益が出やすいのか」、「その状態を実現するために、どのような体制が必要なのか」といった問いに向き合うようになりました。
試行錯誤の中で、いわゆるマーケティングのフレームワークを使って整理してみると、驚くほど理解が進むことに気づきます。
正直に言えば、それまで私は“机上の理論”には懐疑的でした。しかし、結果ではなく施策立案の妥当性や施策の進捗をメンバーと共有し、確認し続けることで、少しずつ業績は上向いていきました。
市場環境が良かった面もあったのかもしれません。それでも、少なくとも以前よりもはるかにストレスなく成長できていたという実感がありました。
後になって、「あの時の仕事は楽しかった」とメンバーから言ってもらえることが多いのも、今でも嬉しい記憶です。
そんなタイミングで、私はSAP社が主催するCOO養成塾に派遣されました。これは、全社変革を推進する立場の参加者が集い、SAP社自身がクラウドビジネスへと変革してきたプロセスを題材にしながら、議論を通じて「プロセスオフィサーとしての考え方」を形成していく研修でした。
振り返れば、これが私にとってビジネスプロセスとの本格的な出会いだったと思います。
それ以前にも、Lean Six Sigmaのグリーンベルトを取得し、いくつかのプロジェクトでチャンピオンを務めた経験はありました。しかしこの研修を通じて、ビジネスプロセスを磨くことで変革が実現していく姿、そして北極星を掲げ、全社が同じ方向を向いて改善を続けていくことの力を、具体的な事例として目の当たりにしたのです。
変革とはイベントではなく、能力である
こうした経験を通じて、私は次第に変革と改善は、本質的には同じものなのではないか、と考えるようになりました。一般に「変革」という言葉からは、組織の再編や大胆な戦略転換、あるいはトップダウンで一気に進める大きな施策が連想されがちです。
一方で「改善」は、現場で行われる日々の地道な取り組み、部分的で小さな活動として捉えられることが多いように思います。しかし私は、変革と改善の違いは、本質的なものではないと考えています。
変革する能力と、改善を自律的に、かつ全社最適で回し続ける能力に、本質的な差はありません。違いがあるとすれば、それは外見的なものだけです。
変革とは、全社で同じ方向を向いて改善を進めること。変革とは何か新しいことを始めることではありません。ましてや、派手な施策を打つことでもありません。私が考える変革とは、組織全体が一つの方向を向き、改善を積み重ねていける状態そのものです。その方向性は、次の問いに集約されます。
どのお客様に、どのような価値を、どのような方法で届けることが、自分たちにとって最も合理的なのか。この問いに対して、経営、企画、現場が同じ理解を持ち、同じ前提で議論できているかどうか。ここにコンセンサスがなければ、どれだけ個別の改善を積み上げても、それは全社としての変革にはつながりません。
製造プロセス改善と、変革の構造は同じである
製造プロセスの改善を考えると、この構造は分かりやすくなります。
製造現場では、全体プロセスを俯瞰し、ボトルネックを特定し、そこから改善を進めることで、最終的に全体のスループットを高めていきます。
個々の改善は小さく見えても、全体視点が共有されていれば、結果として大きな成果につながります。これは、改善でありながら、同時に変革でもあります。
ビジネスプロセスでは、複雑さが増すだけ
この考え方を、間接業務を中心としたビジネスプロセスに当てはめると、途端に難しくなります。
プロセスが見えにくい、成果がすぐに数字として現れない。部門ごとに評価軸が異なる、そのため、全社視点での改善を進めるには、KGIやKPIを含む構造的な整理が不可欠になります。確かに手間はかかります。しかし、やっていること自体は製造プロセス改善と何も変わりません。
全体を俯瞰し、方向を揃え、改善を積み重ねる。違うのは、対象の複雑さだけです。
変革は「一度きりの取り組み」ではない
ここまでくると、変革を一度のプロジェクトやイベントとして捉えることが、いかに危ういかが見えてきます。変革とは、完了するものではありません。変革とは、問い続け、調整し続ける能力です。
改善が回り続ける組織は、環境が変わっても、自ら軌道修正ができます。それこそが、変革できる組織の姿だと思います。
改善の積み重ねが、変革になる
改善は変革と違う。そう言われることは少なくありません。しかしそれは、改善を部分最適としてしか扱えていない状態を見て、そう感じているだけなのではないでしょうか。全社視点で整理され、同じ北極星に向かって束ねられた改善の塊。それが、変革です。
変革は、特別な誰かが起こすものではありません。改善を正しく回し続ける能力を、組織として持てるかどうか。その差が、「変革できる会社」と「いつまでも変われない会社」を分けているのだと思います。
ここまで述べてきたように、ビジネスプロセスを起点に改善を回し続ける考え方は、一般には BPM（Business Process Management）と呼ばれることもあります。
ただしここでは、BPMという言葉そのものよりも、その中身である「考え方」と「実践」に焦点を当てていきます。
第2章｜全社最適は、なぜこんなにも難しいのか
――部分最適に陥る三つの構造
前回、変革とはイベントではなく、能力である。そして、変革と改善は本質的に同じものである、という考え方を共有しました。では次に浮かぶ問いは、自然とこれになります。
それほどシンプルな話なのに、なぜ多くの企業では全社最適が実現できないのか。改善活動は行われています。DX施策も走っています。会議も、資料も、KPIも、決して少なくありません。それでも、「会社全体として良くなっている実感がない」という声は後を絶ちません。
この違和感の正体を、構造から整理してみたいと思います。
改善は行われている。だが、つながっていない。多くの組織で、改善そのものは真面目に行われています。業務効率化、工数削減、システム導入、データ活用、DXプロジェクト、どれも間違っていません。
個別に見れば、合理的で、正当な取り組みです。
問題は、それらが全社としてつながっていないことです。各部門は、自分たちの「正解」を懸命に追いかけています。しかし、その正解が本当に、「会社全体にとっての最適」なのかは、誰も確かめられていない。
結果として起きるのは、部分最適の積み上げによる全体非最適です。
なぜ部分最適に堕ちるのか。ここで強調しておきたいのは、これは現場や管理職の意識の問題ではない、ということです。
多くの場合、構造上そう動かざるを得ない仕組みになっているだけです。
部分最適が生まれる理由を、三つに整理します。
1. 「プロセスの顧客」が定義されていない。業務改善を進める際、「この業務の顧客は誰か」という問いが、意外なほど曖昧なまま進められています。
次の工程なのか。他部門なのか。それとも最終顧客なのか。顧客が曖昧なままでは、改善の良し悪しを判断する基準も曖昧になります。
結果として、「自部門が楽になる改善」、「評価されやすい改善」が優先されてしまう。
これは自然な行動です。誰かが悪いわけではありません。
2. 改善テーマがKGIと結びついていない。もう一つの大きな理由は、改善テーマとKGIの間に、明確な接続がないことです。
この改善は、どのKGIに効くのか。そのKGIが達成されると、何が変わるのか。ここが共有されていないと、改善は「やること自体が目的」になってしまいます。
部課長の立場で考えてみると、一つの目安はこういう問いです。
自分の部署で進めている改善テーマを三つ挙げたとき、それらが同じKGIに向かっていると説明できるだろうか。
この問いに即答できないとすれば、個々の改善が正しくても、全社としては力が分散している可能性があります。
3. ビジネスプロセスは、製造よりも見えにくい、製造プロセスでは、モノが流れる、在庫が見える、ボトルネックが比較的特定しやすい、という特徴があります。
一方、ビジネスプロセスでは、情報が流れる、判断が介在する、成果が時間差で現れる、ため、どこが詰まっているのかが非常に分かりにくい。
見えないものは、管理できません。
見えないものは、改善の優先順位もつけられません。
その結果、「とりあえず目についたところから改善する」という動きになりやすくなります。
全社最適とは、「方向が揃っている状態」である。ここまで整理すると、全社最適が難しい理由は明確です。個別の改善は正しい、しかし、向いている方向が揃っていない。だから、力が打ち消し合ってしまう。全社最適とは、すべてを完璧にコントロールすることではありません。
改善の方向が、同じ北極星を向いている状態、それが全社最適です。
だから、KGI・KPIが必要になる、ここで初めて、KGIやKPIの話が意味を持ちます。KGI・KPIは、管理のための道具ではありません。
現場を縛るための数字でもありません。
全社で同じ問いを持つための思考の装置です。
何を目指しているのか。どこに効く改善なのか。今、どこまで来ているのか。これが共有されて初めて、改善は部分最適から抜け出し、変革の力になります。
しかし、KPIを増やせば増やすほど、現場が疲れていく。仕事が楽にならない。そんな感覚を持ったことはないでしょうか。それはどうしてなのでしょう。
第3章｜KPIを回しているのに、なぜ仕事は楽にならなかったのか
――「管理のためのKPI」が現場を追い詰める
今から20年ほど前の話になります。私はある外資系企業で、部長職として事業戦略と売上・利益などの計数管理を担っていました。当時、私に課されていたのは、売上や利益といった結果指標だけではありませんでした。
・希望納期達成率
・SKU総数
・低利益製品の割合
・停滞在庫の金額
・新製品売上比率
これら複数のメトリックスを、同時に達成することが求められていました。
その頃、日本では製造工場の海外移転が急速に進んでいました。
日本国内市場のみを対象としていた当社にとって、市場は明らかに縮小局面に入っていました。その中で、売上、利益、そして複数の業務指標を同時に満たすことは、現実的に非常に難しい状況でした。
未達の指標があれば、「実行可能な挽回策を提示せよ」と求められます。しかし、手を抜いているわけではありません。すでにできることはやっている。
だからといって、すぐに効果が出る挽回策など、あるはずもない。
結果として、「打つ手がない」という感覚を、強く持つようになっていきました。
この企業は、イノベーションを通じて社会や顧客の便利をつくる、というビジョンを掲げていました。
しかし現実には、数値説明、未達理由の整理、挽回策の検討に多くの時間が割かれ、本来注ぐべきだった創造的な仕事の時間は、少しずつ、しかし確実に削られていきました。
言い訳はできません。数字は事実だからです。
ただ、「本当に大切なことに使えるエフォートが奪われている」という感覚だけが、強く残っていました。
以前は、ここまで厳格な管理は行われていませんでした。
状況が変わったのは、グローバル本社の経営陣が刷新され、厳格なKPI管理が持ち込まれてからです。それは「変革」と呼ばれていました。では、その結果、何が起きたのでしょうか。
振り返ってみると、その「変革」によってもたらされたのは、売上成長というよりも、コストカットによる利益の伸長だったように感じます。売上成長率自体は、その後も大きく改善することはありませんでした。
もちろん、例外はあります。
いくつかの事業は、大きな成長を遂げました。しかし、それらに共通していたのは、技術、市場、そして初期メンバーの強い熱量が、最初から揃っていたことでした。
これらの経験を通じて、私は一つのことを強く感じるようになりました。
技術で顧客の便利を実現する、というビジョンから落とし込まれていないKPIでは、持続的な成長は生まれない、ということです。短期的な利益改善から逆算されたKPIは、一時的な成果を出すことはあっても、人の情熱や創造性を削っていきます。
結果として、新しい事業は生まれにくくなり、顧客のペインに向き合う余力も減り、組織は静かに疲弊していく。それが、当時の私が体感した現実でした。
ここで、はっきりさせておきたいことがあります。
KPIが苦しいのは、部課長や現場の努力が足りないからではありません。
KPIの設計思想そのものが、成長に向いていなかった。それだけの話です。
正しいKPIは、現場を縛るものではなく、どこに力を使えばよいかを示す羅針盤になります。
第4章｜KGI・KPIを、改善を回し続ける装置にする
――製造プロセスとビジネスプロセスの違いから
では、どうすれば、KGI・KPIを、「管理の道具」ではなく、「改善を回し続ける装置」として設計できるのでしょうか。
KGI・KPIは、どう設計すれば現場の自由度が上がるのか。前回、KPIを回しているはずなのに、仕事が楽にならず、創造性が削られていった実体験を共有しました。
問題はKPIそのものではありません。問題は、KPIの「設計のされ方」です。
では、現場の自由度を奪うKPIと、改善を回し続けるKPIの違いは、どこにあるのでしょうか。
製造プロセスでは、スループット、タクトタイム、不良率、在庫量といった指標が、比較的自然に受け入れられています。
それは、プロセス全体の構造が見えているからです。
一方で、ビジネスプロセスでは、情報が流れ、判断が介在し、成果が時間差で現れます。
そのため、KPIだけが先に決まり、プロセスが後付けになることが少なくありません。
これが、現場を苦しめるKPIが生まれる典型的なパターンです。
良いKPIと悪いKPIを分けるポイントは、プロセスに紐づいているかどうか、そして現場が手を打てる余地が残されているかどうかです。
悪いKPIは、結果に近すぎ、未達時に「なぜ？」しか問われず、改善行動に結びつきません。良いKPIは、どこを良くすればいいかを示すヒントになります。
KGI・KPIは、ツリーとして整理するだけでは不十分です。プロセスの流れの中で、どこに効いているかを考える必要があります。
ここで、少し具体的な例を考えてみましょう。
多くの企業に共通する「受注〜納品〜請求」プロセスです。このプロセスでは、営業、製造、調達、経理といった、複数の部門が関与します。よくあるのは、次のようなKPIが設定されているケースです。
・営業：受注金額、受注件数
・製造・調達：納期遵守率
・経理：請求処理リードタイム
どれも正しそうに見えます。実際、各部門は真面目にKPI達成を目指します。
しかし現場では、月末に無理な受注が入り、製造の優先順位が頻繁に変わり、経理はミスを恐れて確認工数を増やす、といったことが起きがちです。
これは誰かが悪いわけではありません。
KPIが部門ごとに最適化されているだけです。
一方で、受注から請求までを一つのプロセスとして捉えると、見える景色は変わります。
例えば、受注から請求までのリードタイム、初回請求の正確率といったプロセスKGIを置き、そこからKPIを設計するとどうなるでしょうか。
・受注時点での情報完全率
・設計変更の発生率
・手戻り件数
こうしたKPIは、現場に「次に何を改善すべきか」を教えてくれます。
KPIが、管理のための数字ではなく、行動を揃えるための装置に変わる瞬間です。現場の自由度が上がるとは、任されている感覚が生まれることです。
では、どうすれば、KGI・KPIを、管理の道具ではなく、改善を回し続ける装置として設計できるのでしょうか。製造プロセスでは、KPIが自然に機能していた。まず、製造プロセスを思い浮かべてみてください。
製造の世界では、スループット、タクトタイム、不良率、在庫量、といった指標が、比較的自然に受け入れられています。それは、プロセス全体の構造が見えているからです。
原材料が入り、工程を流れ、製品として出ていく。どこで詰まっているか、どこを改善すれば全体が良くなるかが、比較的分かりやすい。
KPIは、「管理のために押し付けられた数字」ではなく、改善の方向を示す目印として機能していました。
ビジネスプロセスでは、同じことが起きにくい、一方で、ビジネスプロセスでは状況がまったく異なります。
情報が流れる、判断が介在する、成果が時間差で現れる、そのため、全体像が見えにくい、ボトルネックが特定しづらい、改善の効果が測りにくい、結果として、KPIだけが先に決まり、プロセスが後付けになります。
これが、現場を苦しめるKPIが生まれる典型的なパターンです。
「良いKPI」と「悪いKPI」の決定的な違い。ここで、KPIの善し悪しを分けるポイントを整理します。
悪いKPIの特徴。結果に近すぎる、未達時に「なぜ？」しか問われない。改善行動に結びつかない。こうしたKPIは、説明責任は果たせても、改善は生みません。
良いKPIの特徴。プロセスに紐づいている。手を打つ余地が残されている。現場が自分で考えられる。良いKPIは、「達成せよ」という命令ではなく、「どこを良くすればいいか」を示すヒントになります。
KGI・KPIは「木」ではなく「流れ」で考える。多くの組織では、KGI・KPIを「ツリー構造」で整理します。これは間違いではありません。
しかし、それだけでは不十分です。
重要なのは、KPIがプロセスの流れの中で、どこに効いているか、を理解することです。
このKPIは、どの判断に影響するのか。どの行動を変えれば、数字が動くのか。これが見えないKPIは、現場にとって「動かしようのない数字」になります。
現場の自由度が上がる瞬間、KGI・KPIが正しく設計されると、現場にはある変化が起きます。何を優先すべきかが分かる、余計な説明が減る、改善の仮説を立てやすくなる、結果として、管理されている感覚が薄れ、任されている感覚が強くなる。
ここで初めて、KPIは「縛るもの」ではなく、改善を回すための装置になります。
部課長にとっての現実的な問い、ここで、部課長の立場で考えてみてください。
今、自分が追っているKPIは、部署のメンバーが、「次に何を改善すればよいか」を考える材料になっているだろうか。
もし答えが「NO」だとすれば、それは努力不足ではありません。
設計を見直す余地がある、というサインです。
第5章｜プロセスを「描くこと」が目的になった瞬間、改善は止まる
――そして、何をそろえるべきなのか（製造プロセス対比入り）
ここまで、変革と改善の関係、KGI・KPIの設計思想、そしてBPMの考え方について整理してきました。
この流れで、多くの組織が次に取り組むのが、プロセスの可視化です。
・業務フローを描く。
・As-Is／To-Beを整理する
・BPMの方法論やツールを導入する
ここで、注意しなければならないことがあります。
BPMという言葉に、どこか距離を感じる方もいるかもしれません。
それは、BPMが、「考え方」ではなく、「方法論」や「仕組み」として語られてきたことが多かったからではないでしょうか。
方法論をそろえること自体は、悪いことではありません。特に組織が大きくなればなるほど、やり方がそろっていることには、明確なメリットがあります。
・情報共有がしやすい
・他部門の議論を理解しやすい
・改善の経験を横展開しやすい
改善が全社で一体感を持って行われる状態。それこそが、変革です。
その意味で、やり方をそろえることは、北極星を共有することと同じくらい重要だと、私は考えています。
しかし、問題は「何を」そろえたのか、です。
フォーマット、記号の使い方、粒度、書き方のルール。これらを厳密にそろえた瞬間、プロセスは「考える対象」ではなく「提出物」になります。
結果として、描くこと自体が目的になり、現場は正解探しに走り、改善は止まります。
もう一つ重要な点に触れておきたいと思います。
ビジネスアナリシスやマーケティングの体系、各種フレームワークは、いずれも非常に有用です。私自身、それらに何度も助けられてきました。
しかし、それらを専門組織や一部の担当者に委ねた瞬間、変革は他人事になりやすくなります。
分析はされている。
資料も整っている。
けれど、事業を実際に動かしている主体自身が、思考し、判断し、改善する能力を身につけていなければ、それはフレームワークを「使った」だけで、何も変わっていないのです。
BPMやプロセス可視化も、同じ構造を持っています。
誰かが描いたプロセスを「見る」だけでは、組織の能力は高まりません。自分たちで考え、自分たちで悩み、自分たちで修正する。その経験を通じて初めて、方法論は共通言語として機能し始めます。
ここで、製造プロセスとの対比を考えてみたいと思います。製造プロセスの改善において、日本企業は長年、非常に強みを発揮してきました。
・外部任せにはしない。
・方法論は学ぶが、改善は自分たちで回す
・現場が主体となって、試し、失敗し、学ぶ
外部の専門家は、代わりに改善する存在ではなく、考え方を伝え、支える存在でした。
一方で、ビジネスプロセスになると、状況は一変します。
・分析は専門組織や外部に委ねる
・現場は「説明を受ける側」になる
・改善はプロジェクトとして切り出される
同じ企業でありながら、主体の置き方がまったく逆になるのです。
私は、この構造こそが、「ものづくりには強いが、ビジネスに弱い」日本企業を生み出してきた一因ではないかと考えています。製造では、プロセスに向き合い、改善を回す能力を、現場が自らのものとして獲得してきました。
一方で、ビジネスプロセスでは、その能力を専門組織や外部に委ねてしまった。
その結果、プロセスは「考える対象」ではなく、「説明される対象」になっていったのではないでしょうか。
では、本当にそろえるべきものは何でしょうか。それは、考え方と、ステップの踏み方です。
・なぜこのプロセスを扱うのか。
・どこから手を付けるのか。
・何をボトルネックとして見るのか。
・どう振り返り、次につなげるのか。
この思考の流れが共通していれば、アウトプットの形が多少違っても、議論は成立します。これが、組織としての共通言語です。
プロセスを描く本当の目的は、一つしかありません。
対話を生み、考える材料にすること。
・なぜここで手戻りが起きるのか。
・なぜこの判断は属人化しているのか。
・なぜ改善が続かないのか。
こうした問いが生まれない可視化は、どれだけ整っていても、改善にはつながりません。
BPMは、ツールでもテンプレートでもありません。
組織として、ビジネスプロセスに向き合い続ける能力です。この能力は、研修や専門組織の設置では育ちません。一つのプロセスを選び、実際に改善し、うまくいかなかった理由を振り返り、次に活かす。
この経験を通じて、組織が自身で変革する能力は少しずつ高まっていきます。
第6章｜最初の一つは、どのプロセスを選ぶべきか
――BPMを「回り始めさせる」ための現実解
ここまで、BPMは方法論ではなく、組織の能力であること、そして、そろえるべきは「型」ではなく「考え方とステップ＝共通言語」であることを述べてきました。
では、次の問いに進みます。
最初に、どのプロセスから手を付けるべきなのか。
この問いに対する答えを間違えると、BPMは高い確率で止まります。
「重要そうなプロセス」から始めると、だいたい失敗する、多くの組織が、最初に選びがちなのは次のようなプロセスです。
・全社横断で影響が大きい
・経営からの期待が高い
・DXや改革の文脈で象徴的。
一見すると、正しそうに見えます。
しかし、BPMの立ち上げフェーズにおいては、この選び方は危険です。理由は単純で、関係者が多すぎる、利害が複雑すぎる、正解が一つに定まりにくい。
結果として、可視化だけが進み、合意形成に時間がかかり、改善は先送りされます。
最初の一つに求められる条件
最初に選ぶプロセスには、成果よりも「学習」が求められます。私がよく使う判断軸は、次の4つです。
１． 困っている人がはっきりしている。
誰が困っているのかを説明できること。定量でなくても構いません。
２．境界がある程度、切り出せる
部門横断でもよいですが、決めた後に広がらないことが重要です。
３．失敗しても致命傷にならない
いきなり全社標準を決めない。試行錯誤が許される余地があること。
４． 改善の余地が見えそうである
手戻り、待ち、属人判断。こうした兆しが見えているプロセスが望ましい。
製造プロセス改善と、まったく同じ始め方でよいのです。製造プロセス改善を思い出してください。いきなり全工場、全工程を変えたことは、ほとんどないはずです。
一つのライン、一つの工程、一つの不具合。
そこから始めて、試し、学び、横展開する。
この進め方は、ビジネスプロセスでもまったく同じです。違うのは、対象がモノか、情報や判断か、それだけです。
「成功事例」を作ろうとしない。
最初のプロセス改善で、立派な成功事例を作る必要はありません。むしろ重要なのは、なぜうまくいかなかったのか、どこで議論が噛み合わなかったのか、何が共通言語として不足していたのか。これらを言語化できることです。
この振り返りこそが、BPM能力を高める核心です。
完璧を求めないことが、改善を前に進める
問題や困りごとの解決において、最初から完璧を求めないことが重要です。あるべき姿を描き、抜け漏れなく整理し、きれいに改善したくなる。しかし、その姿勢こそが、改善を止めてしまいます。
最初の一歩では、次の4点が明確であれば十分です。
・何を対象にするのか
・どこまでを扱うのか
・いつまでに一区切りつけるのか
・誰と一緒に考えるのか
この4点を決めるだけで、改善は現実の仕事になります。
いきなり改善に進まず、「悪さ」を数値化する
ここで、いきなり改善に進まないことが重要です。まず行うべきは、「悪さ」を数値化することです。
・どれくらい待ちが発生しているのか
・どれくらい手戻りが起きているのか
・どれくらい説明に時間が使われているのか
精緻な分析は不要です。仮の数字でも構いません。重要なのは、「なんとなく困っている」を、同じ前提で語れる状態を作ることです。
「悪さの数値化」は、一つでいい
悪さの数値化は、いくつも考える必要はありません。むしろ、一つに絞ることが重要です。
・計れそうで
・今の状況を端的に説明でき
・関係者全員が「それは困る」と感じるもの
代表的な指標を一つ選ぶ。それだけで十分です。
複数の数値を並べた瞬間に、議論は「どれが正しいか」に移ってしまいます。最初に必要なのは、正確さではなく、共通の問題認識です。
その一つの数字を前にして、「なぜ、こうなっているのか」を語れる状態を作る。
それが、改善を回し始めるための最短ルートです。
BPMは「始め方」で9割決まる
BPMは、立派な構想よりも、最初の一歩の置き方で結果が決まります。小さく、当事者で、学びを目的に回り始めた改善は、やがて組織の能力になります。
第7章｜改善を「点」で終わらせない
――振り返りと横展開が、組織の能力をつくる
第6章では、最初の一つをどう選び、どう始めるかを整理しました。小さく始め、完璧を求めず、悪さを一つの数字で捉える。ここまで来れば、改善は確実に回り始めます。
しかし、ここで終わってしまう組織が非常に多いのも事実です。
理由は明確です。改善をやりっぱなしにしてしまうからです。
改善が「点」で終わる瞬間、よくある光景があります。
・ある業務を改善した
・少し楽になった
・数字も多少よくなった
そして数か月後、誰もその改善について語らなくなる。
報告書は残っている。フロー図もある。しかし、次に活かされない。
このとき起きているのは、改善が成果で完結し、学習になっていないという状態です。
振り返りの目的は「反省」ではない
ここで重要なのが、振り返り（レビュー）の位置づけです。振り返りというと、何が悪かったのか、どこが足りなかったのか、という反省会をイメージしがちです。
しかし、BPMにおける振り返りの目的は、次に使える知恵を残すことです。
問いは、次の三つで十分です。
・なぜ、このやり方を選んだのか
・どこで議論が噛み合わなかったのか
・次にやるなら、何を変えるか
ここで初めて、改善は経験になります。
数字が語れるようになると、振り返りは変わる
第6章で述べた。悪さの数値化を思い出してください。たった一つの数字でも、それを前にすると、振り返りの質は大きく変わります。
なぜこの数字は下がらなかったのか。
なぜここで止まったのか。
何を見誤っていたのか。
個人の頑張りではなく、プロセスとして何が起きていたかを語れるようになります。
これが、属人化しない改善の第一歩です。
横展開とは「真似をさせること」ではない
次に来るのが、横展開です。ここで多くの組織が誤解します。
横展開とは、成功事例を配ること、同じやり方を他部署に当てはめることではありません。それをやった瞬間、改善は再び他人事になります。
横展開すべきなのは「結果」ではなく「思考」
横展開すべきなのは、どのプロセスを選んだのか、なぜその指標を選んだのか、どこで悩み、どう判断したのか、という思考のプロセスです。これが共有されると、他部署はこう考え始めます。
自分たちなら、どこから始めるか。
自分たちなら、何を数字にするか。
ここで初めて、改善が自分ごとになります。
共通言語が、横展開を可能にする
第5章で述べた。考え方とステップをそろえるという話が、ここで効いてきます。
目的の置き方。
スコープの切り方。
悪さの捉え方。
振り返りの観点。
これらが共通言語になっていれば、フォーマットが違っても、議論は成立します。
横展開とは、やり方をそろえることではなく、考え方を伝染させることです。
組織のBPM能力は、こうして高まる
BPM能力は、次のサイクルで高まります。
1. 小さく始める
2. 悪さを一つの数字で捉える
3. 試す
4. 振り返る
5. 思考を共有する
これを、違う部署、違うテーマで繰り返す。
すると組織には、プロセスで考える癖、数字で語る習慣、改善を怖がらない空気が、少しずつ蓄積されていきます。これが、変革をイベントにしないための正体です。
部課長の役割は「答えを出すこと」ではない。
このフェーズでの部課長の役割は、改善案を示すことではありません。
問いを立てる。
数字を見る視点を示す。
振り返りの場をつくる。
これだけで十分です。
改善を回す主体は、あくまで現場です。
変革は、いつ始まったのか。振り返ってみると、組織の変革は、大きな号令とともに始まったわけではありません。
一つの困りごと。
一つの数字。
一度の振り返り。
そこから、静かに始まっています。
変革とは、改善が自律的に回り続ける状態です。連載を通して伝えたかったこと。ここまでを通じて伝えたかったのは、特別な方法論ではありません。
変革は能力であること。
その能力は経験でしか身につかないこと。
部課長こそが、その起点になれること。
BPMは、専門家のものでも、一部門のものでもありません。
日々の仕事の中で、少し見方を変えること。
そこから、すべては始まります。
あとがき
――変革は、特別なことではないここまでお読みいただき、ありがとうございました。
ここでは、変革やBPMを、特別なイベントや大掛かりな施策としてではなく、組織の能力としてどう育てるかという視点で整理してきました。
振り返ってみると、ここで述べてきたことの多くは、決して新しい理論や派手な方法論ではありません。
小さく始める。
困りごとを言語化する。
数字で状況を共有する。
振り返り、次に活かす。
どれも、現場で仕事をしていれば、一度は経験していることばかりです。
それでもなぜ、ビジネスプロセスの改善や変革は、難しいもの、特別なものとして扱われてきたのでしょうか。変革が「他人事」になった瞬間、一つの理由は、変革を専門組織や外部に委ねすぎてきたことにあると、私は考えています。
分析は誰かがやってくれる。
プロセスは誰かが描いてくれる。
改善案は誰かが示してくれる。
その結果、事業を動かす主体自身が、考え、判断し、試行錯誤する機会が、少しずつ失われていった。
これは、能力の問題ではありません。構造の問題です。
ものづくりの世界では、当たり前にやってきたこと。興味深いのは、製造プロセスの改善においては、日本企業はまったく違う姿勢を取ってきたことです。
ほとんどのメーカーでは、改善を外部任せにするのではなく、方法論は学ぶ。しかし、改善は自分たちで回す。わかるまで、できるまで、現場で試す、という姿勢を、長い時間をかけて貫いてきました。
その結果として、改善が一過性の取り組みではなく、日常の仕事の一部として根づいていったのだと思います。
重要なのは、それが特別な改革プログラムではなかったという点です。
日々の仕事の中で、小さな違和感に向き合い、試し、振り返り、次に活かす。
それを、組織として積み重ねてきただけなのです。
ビジネスプロセスでも、本当は同じことができる、ここで伝えたかったのは、そのやり方は、ビジネスプロセスでも同じだということです。
対象がモノか、情報や判断か。違いはそれだけで、考え方も、進め方も、本質は変わりません。
完璧を求めない。
まず一つ、困りごとを選ぶ。
悪さを一つの数字で捉える。
振り返りを通じて学ぶ。
これを繰り返すことで、改善はやがて自律的に回り始めます。それこそが、変革と呼ばれてきたものの正体です。
部課長の立場だからこそ、できること。ここでは、部課長層の方を主な読者として想定してきました。それは、部課長こそが、現場の現実を知り、経営の意図も理解し、両者をつなぐ立場にあるからです。
大きな号令を出さなくてもいい。
立派な構想を描かなくてもいい。
一つの仕事を取り上げ、「なぜうまくいかないのか」を、プロセスとして考えてみる。
そこから始めるだけで十分です。
変革は、静かに始まる、変革は、ある日突然始まるものではありません。
一つの問い。
一つの数字。
一度の振り返り。
そこから、静かに始まります。
そして気づいたとき、組織の中に、プロセスで考える習慣。
数字で語る文化。
改善を怖がらない空気。
が根づいている。
それが、変革が能力になった状態です。この記事が、その最初の一歩を踏み出すきっかけになれば、これほど嬉しいことはありません。
BPMという言葉が、わかりにくいと感じられてきたのは、それが専門用語として、あるいは特別な仕組みとして語られてきたからかもしれません。しかし本来のBPMは、もっと日常的で、もっと実務に近いものです。
困りごとをプロセスとして捉え、数字で状況を共有し、試し、振り返り、次に活かす。ここまで扱ってきたことは、ただそれだけの話でした。
おわり