プロセス改善
このコーナーでは、他の領域を統合し、活用する”プロセス改善”について解説していきます。
プロセス改善では、他のコーナー(領域)に掲載しているような情報をどのように活用し、束ねて進めるかが問われますが、技術や工学的な内容以上に、人間系への対応が改善の成功に大きな影響を与えます。
人間系の内容を含めてこのコーナーを充実させつつ、それぞれの領域別に補足していきます。
身近かな実務レベルの改善~組織・組織間レベルのプロセス改善まで、これまでの経験則から重要だと感じている事項を含めて情報を提供していきますので参考にしてください。
プロセスって?
プロセスには国際規格を中心として正式な定義が存在していますので、詳しくはそちらをご覧ください。
簡単に言うと”ある目的を達成するための仕事の仕方”。もうちょっと付け加えると、それと併せて”仕事を行うための設備・施設、情報やツールなどの周辺環境全般や関係者のスキル、あるいはスキル状況を把握し、向上させるための取り組みの内容なども含める”と考えてよいでしょう。
プロセスの結果が成果物(例えば、開発したシステム)であり、そのために費やした工数、期間、あるいは利益、(システムを使った)顧客やエンドユーザの満足度、目的達成度合いなどが成果となります。
ここでの成果は、プロセスの目的と手段に左右されます。
そもそも改善が進まない組織
すごく太っているのに自分ではまったく気にせず、医者の忠告は無視して、好きなモノなら際限なく食べ続ける人。検査で異常な数値が継続して出ているのに、原因となっている行動(例:飲食)をやめるつもりのない人。
このような人達は処置なしですよね。
組織だって同じです。
問題があると認識できない組織、自らを変えなければならないと認識できない組織では改善はありえません。
また、改善しなくてもやっていける組織では「改善」は進まないでしょう。
改善以前に、仕事の仕方に根拠を求めなくてもそこそこ売上があがる組織、大金持ちのオーナーなどが際限なく資金を提供してくれるぬるま湯のような組織などが該当します。
例1: 昔からの顔つながりだけで仕事がもらえる組織
例2: カットイン後にいろいろと問題が発生しても、あまい顧客なのでなーなーにできるもたれ合い組織
また、旧来からの経験則だけがまかり通る、適切な成果・結果の評価が出来ない組織も同様に改善が進まない可能背が高いと言えます。それは自分たちの立ち位置、現状の問題点を把握することが出来ないからです。
自分たちにその気がない組織では改善は進みません。
プロセス改善は何も準備なしで思いつくままに進めると(必ずと言っていいほど)うまくいきません。
その原因には様々なものがありますが、当初は技術面はほとんどなく、主に人間系(組織を含む)の要因と(聞けば)誰でも分かるような当たり前の(難しくない)要因ばかりです。
思いつくままに並べると以下の通りになりました。
まだあると思いますが、下記の事項だけでもクリアできれば相当なことができるでしょう。
■当事者が”自ら成長したい””ユーザに喜んでもらいたい”と思っていること
改善を成功させる原動力は、実務者・管理者=当事者の心の底から湧き出るような”思い”です。
多くの失敗事例は、外向けにアピールしたい、よく見られたい等々の思惑により、当事者達にその気持ちがないのに適切な動機付けもなく、イベント的に改善を進めることが原因になっています。
それらを十把一絡げに、どこどこのプロセスが・・・という捉え方に変換して結論を出してしまっています。
一方当事者たちも、波風が立たないように現状に流されながら日々を送り、上からの指示待ちの構図ができあがっています。
自分たちの現状を変えずにそのままでいることはもっとも容易な選択であり、結果として自らの成長を阻害することにつながっています。
ひとり一人の力量が成果に大きな影響を与えるこの業界ですから、現状のままでいることは組織の成長、業界の成長を止める要因になってしまうわけです。
つまり特定の誰かだけに問題があるのではなく、双方に問題があるのです。
最終的には、何のために働くのか? 仕事への価値観を問い直すことが必要なのだと思います。
話を元に戻しますが、改善が成功するかしないかは、当事者達が”もっと成長したい”、”今日より明日は良い仕事がしたい””ユーザの皆さんに喜んでもらいたい”と心の底から思っているか(そしてそれを他人任せにしないで行動で示しているか)どうかに大きく左右される、ということです。
■気がついた人が始める
改善は誰がはじめるのでしょうか。そして誰が最初に進めるのでしょうか。
それは「自分たちの仕事に改善が必要だ=自らの腕を、技をもっと磨かなければ」と気がついた、そう「あなた」です。
”誰かがやらないと自分は動かない。そうでなければやってもムダだ。”という方が結構多いのが実情ですが、一面その通りであるものの、その考え方では結局うまくいきません。
改善は”誰かがやってくれる”というような他人事で成功することはありません。
ひとり一人が自らの仕事を見直し、どのように進めると、今まで以上の価値をお客さんに提供できるようになるか、さらに喜んでもらえるか、そして組織に、さらに仲間達も喜んでもらえるのかを真剣に考え、行動しない限り成功することはないと肝に銘じてください。
誰かに依存するのではなく、まずは気がついた人が自らのために自らがやる。自らの内面から変わることで周囲の環境を変える。さらに大きな成果を上げるためにチームや組織で協力して進める。
そうやって自分たちの内面から改善が拡がっていけば、様々な障害に出会っても、それを乗り越えて成功することができるでしょう。
■プロセス改善は経営レベルの問題
ますます多機能なソフトウェアを短納期で、しかも求められる品質を確保した上で開発することが求められています。一人の技術者だけでソフトウェア製品をすべて作り上げることはほとんどの場合ムリでしょう。
つまりチームで、組織的にソフトウェアを開発することは”前提条件”となります。
ということで、開発の仕方を改善する(=プロセス改善の)取り組みは、組織やチームで取り組むことに他ならない。
改善成果の良し悪しは、最終的に経営レベルに影響を及ぼすわけです。
誰か一人だけが、あるいは断片的に一部分で取り組んでも、最終的な全体の成果はほとんど変わらないのです。
ですから、組織的な成果向上を目指すのであれば、経営者や上級管理者がスポンサーとなり、組織的に、継続的に取り組む必要があります。
<補足>
「気がついた人から始める」だけでは効果が少なくて市場のニーズに追いつかない可能性が高い。
「経営者がスポンサーとなった取り組み」だけでは”やらせる→やらされる”対応になりがちで、結果的に成果どころか、目的とは逆に大量のムダ対応が増える(かつモチベーションが低下する・品質が悪化するなど悪影響が出る)可能性も高いわけです。
トップダウン+ボトムアップの両輪で進める必要がある、と受け取って下さい。
とはいえ、トップダウンが先行すると(アプローチのまずさ(^^;;で)「やらされ仕事」に直結するケースが多いので、まずは「気がついた人が始める」または「組織がきっかけを作り、現場から始める」ようにして、それを組織がしっかりバックアップしてあげて、継続的な取り組みに移行するのがよいパターンの一つだと思います。
■よく分からないまま進めないこと
これまでにマラソンを走ったこともない人が、いきなり世界トップレベルのタイムで優勝するような成果を目指すことは、ほぼ間違いなくうまくいきません。時間はともかくとして完走することですら至難の業でしょう。
しかし、よく聞くプロセス改善では、(システム開発プロジェクトと同様に)平気でそれをやれと言われることがあります。
つまりよくわからないまま、やみくもにプロセス改善を進める場合も多い、ということです。
特に経営者、上級管理層の思いつきで突然始まる改善対応でよく起きそうな気がします。
これまでの実績もないのに、短期間に、リソースもろくに提供せずに、いきなり大きな成果を出すことを至上命令としてプロセス改善を実施するのは最悪です。
プロセス改善は多くの人間が関わり、リスクも多い、非常に困難なプロジェクトだと思ってください。
当然、効果的に進める上で必要なスキルもあります。トレーニングも必要になるでしょう。
どのような難しさがあり、そのために最低限何を考慮して、どのように進めるべきなのかくらいは事前に把握して進めてください。
■事実情報により現状を把握してから推進する
プロセス改善がうまく行かない原因の中でも最も致命的なものの一つとして「現状を的確に把握できていないのに、改善策を実施してしまう」というのがあります。
これまでの経験上、売上や効率ばかりを気にして目先の作業に翻弄されている組織であればあるほど、改善対応を急ぐあまり、現状把握もそこそこに、改善案ばかりが提示される傾向があるように思います。
現状を把握しているさなかにも、思いつきの改善案を出してくる人たちが大勢います。
改善の過程では、今自分が何をしているのかを的確に把握していない方が意外に多いのです。
そういう場合は、「いまのは現状把握ではなく、改善手段のことですね」と教えてあげた上で、「現状把握が終わって、何を目指すのかが明確になったら改善手段を考えましょうね」と伝えます。
そして、現状は”事実情報”に基づき把握することが重要です。
誰かがそういっていた(噂)、きっとそうに違いない(決めつけ)、などは可能な限り排除し、現場で、現物で、事実を確認しながら現状を把握してください。
さらに、現状把握した結果はすべて記録に残し、関係者で共有する(次の関係者全員の認識共有へ)ことをお忘れなく。
# ここでの”現状”の中には、
# どのように(どのような要員が、などを含む)作業を行っているのか(プロセス面)、
# どのような成果が出ているのか(成果面)、の両面が含まれます。
■関係者全員の認識共有=ありのままの現状を知る・受容する
現状把握の中でも最も重要なことは、事実基づいて、現状をありのまま”関係者全員で共有する”ことです。
この関係者には、管理者や実務担当者(、改善推進者のような方がいるなら当然その方も)が含まれます。
他人事ではなく、自分たちのこととして現状をありのまま受け止める、いや受け容れることができなければ、本当の意味での効果的な改善は行えません。
改善がうまく行かない組織や管理者・担当者の典型的な特徴として”ありのままの現状を認めない・受け容れない”というのがあります。
事実情報から導き出した現状を見たときに、その情報を拒否したり、ごまかしたり、表面的には認めているように見せておいて、その後の改善アプローチの中で極論反対(意地悪に行動する)などの反応を示す、などがその事例です。
これまでの観察では、こういう方達は”外部からの評価を気にしすぎていて、表面的には問題なく見せる(実のところ問題があるのは分かっている)ことで体面を保っている(それでいて自分の内面の意味のある基準がなく、自分に甘い)”ような傾向があります。
現状把握+関係者共有でのおすすめは、”現状に対してよい・悪いを決めたり、判断しないこと”です。
よい、悪い、を決める際の判断基準は、意外と主観だらけだったりします。
特に、声の大きな方(=権力者)がいると、その人の主観でよい、悪いが決めつけられ、本当のまずい面や最初に手をつけるべき事項が隠蔽されることが多いのです。
そうなると、本質的な原因はそのままで、どうでもいい要因だけに改善の目が向けられてしまいます。
ですから、この時点では”よい、悪い”を判断せず、ただ”現状ではこうしている”ということだけ(=ありのまま)を受け容れることができるようにしてください。
それができないまま先に進んでも、効果的な改善にはならないと思います。
■自ら主体的に改善する
改善がうまくいかない原因の一つに、他者責任を追求する対応があります。
他力本願型改善は、目先ではうまくいくこともありますが結局長続きしません。
特に管理者から部下に、発注者から受注者に対して改善を持ちかける場合(依頼する場合)に、自分(管理者・発注者)が原因となっている事象がボトルネックになっていることも多いのです。
改善を本当の意味で成功させたいと思うのであれば、「まずは言い出しっぺが自らを変えることで周囲の環境を変える」取り組みにしてください。
成果が出せない人、伸びない人の多くは、「自分は悪くない、周囲や他者が悪いのだ」という誤った意識、認識を持っています。
実は自分が原因となって自らの境遇を作り上げているのです。
その状況を打開するには、まず自分の誤った(自分本位の、甘えた)考え方、固定観念を変え、行動を変え、そして成果を変えることが必要になります。
自らの努力なしで改善が成功するなんて甘い考えは捨てましょう。
たとえ周囲がやらなくても、自分は改善を行う覚悟、自らが主体的に改善を行う覚悟さえ決まれば、関係者との協力体制もできやすく、改善で獲得する成果も大きなものになり得るでしょう。
■いきなり大きな効果を目指さない(計画→部分試行→検証→展開)
改善はリソースと期間を必要とするので、できるだけ効果を確実に上げられるように進めたいわけです。
成果を変えるために考え出した改善手段が本当に欲しい成果を上げることができるのかは、やってみないと分からないところがあります。
# 計画時点で考え出した改善手段が有効に機能する可能性は、現状分析でどの程度的確に
# 現状とリスク要因を把握できたかによります。
ですからいきなり対象領域全体に改善手段を適用するのはリスクが大きいわけです。
私のお薦めは、まずは考え出した改善手段を「ある特定の一部分だけ」に適用し、その結果から、うまくいったところ、うまくいかなかったところをフィードバックした上で、徐々に領域を広げていくアプローチです。
この方法だと、当初考えた改善手段の有効性を早期に把握でき、さらに有効にするための見直し・修正が行えて、さらに改善手段が的確でない場合の手戻りやムダ、被害を最小限に食い止めることができます。
# ある特定の一部分 の選択にも工夫が必要です
成果を早く出したい、早く終わらせたい、という組織に限って、現状把握もそこそこに、いきなり全体に、無意味な(効果がほとんど期待できない、思いつきの)改善手段適用して、見事に失敗していきます。
そんな分かり切っている罠に、わざわざはまりに行くような対応にならないようにご注意ください。
■成果面の向上を目標とした対応とする
ISO9001・CMM・CMMiなどのモデルを導入する際によく行われることは、そのモデルに記載されている事項をそのまま取り入れることを目指すアプローチです。
この方法では、プロセス面(仕事のやり方)をモデルの記述に合わせることを目標とする=認証やレベルXを認めてもらうことが目標となってしまうわけです。
その結果、成果(例えば、製品品質が向上したのか、生産性は上がったのか、手戻りが少なくなったのか、開発期間が短縮されたのか、開発工数が少なくても済むようになったのか、少なくお客さんが以前より喜んでくれるようになったのか、などなど)が変わったのかは別問題となってしまうケースが多くなります。
プロセス面だけに着目して取り組み、規程や手順書、様式を取りそろえ、モデル文書に記載されている要求事項に合致するようにしたものの、さてさて成果はどうなったかな・・・・・と後付で考えるわけです。
いやいや、別問題にはしていない・・・とおっしゃる組織も多いのかもしれませんが、根拠や十分な現状分析結果から現実的な成果面の目標を設定して取り組んでいる組織はそう多くはないと感じています。
そもそも、改善前のプロセスの状態と成果の両面を的確に把握せずに改善に着手・進行することになれば、改善の効果なんて分かるはずはないのです。
効果は、改善前と改善後を比較して分かるのですから。
そして、成果面に目標を設定せずに取り組むと、必要のない対応や必要以上の対応事項を平気で足し込むことになるでしょう。さらに、対応が必要な事項であっても、単独に、バラバラに、工夫なく組み込んでしまう結果を招きやすくなります。成果を向上させるために必要な事項が明らかに存在するのにもかかわらず、モデルに記載されていないからという理由で対応しない・・・そんなお馬鹿なことも発生する可能性すらあります。
そうやって、無駄の多い(効果が不明な)プロセスを、形式的に実施する(あるいは、審査やアセスメントの時だけ実施したことにする)、価値のない取り組みになっていきます。
そしてその結果、ISO9001は意味がない、CMMiはこういうものだ、のような誤った認識を強化し、トラウマ化していくことも十分にありえます。
まずは、現状の成果を把握した上で、改善で目指す成果はなにか? を徹底的に議論して明確化してください。実際に困っていることを解決するために取り組むことを決める。あるいは、現状の成果面の課題や目標をクリアするために取り組む。そんな当たり前のアプローチにしていくべきだと思います。
どこのプロセスをどのように変えるべきかを考えるのは、それからの話です。
目的・目標が決まってから、原因に働きかける手段を考える・・・そんな当たり前のことを着々と行うことが求められます。
■効果を狙うなら組織として改善を運営する(必要なリソース・スキルと工数を持った要員の割当)
改善を行うには実務以外の時間を費やすためのリソース(工数など)が必要です。
個々人の工夫と努力で改善のための時間を捻出することも必要ですが、組織やチーム全体で改善に向かうのであれば、組織として改善をリードする(リードできる)要員を明確にする、必要ならばその要員が改善に費やす工数比率を高くする(本当に必要なら専任化する)などの”組織としてのリソース提供”が求められるでしょう。
失敗する改善の多くは、一方的に改善をやらせる、でも組織としてはリソースは提供や支援は一切しない、というものです。
これはプロジェクトの失敗の原因の多くが、過少見積もりによるリソース提供不足であることと共通しています。
改善は、達成したい成果を成し遂げるための活動ですから、一つのプロジェクトと考えても良いはずです。
ものごとを成し遂げるには、ものごとの価値に見合う努力量が必要になるはずです。
皆さんの改善は、どのような価値を実現するための取り組みですか?
その価値に見合うリソースを、個々人が、組織が提供していますか?
■急性に効果を求めない(なめてかからない・小さな成功を積み重ねる)
現状を的確に(例えば、定量的な計測値で)把握できていない組織や、改善による成果を(明確に証明できる形で)上げたことがない組織が、ある年に改善でいきなり”1年で生産性30%アップ”などの果敢な目標値を掲げて取り組む場合があります。
しかも、そのために必要なリソースも提供せずに、特定のメンバーだけが対応するような取り組みになっているのであればなおさら、このようなアプローチは失敗するでしょう。
改善の効果は、特定のメンバーだけが対応すれば獲得できる訳ではありませんし、改善の際に導入した手法や手順・基準などがその成果を成し遂げる訳ではありません。
最終的には、導入しようとした方法や手法、手順、ツール、基準などを十分理解した実務担当者や管理者が、理にかなう形で”実践”しなければ獲得できないモノなのです。
言葉を覚えること、九九の暗記、自転車の運転、車の運転、プログラミング・・・誰でもはじめからいきなりできるようになるのではなく、徐々に慣れながら覚えていくモノです。ですから当初は難儀します。
改善だって同じです。
実際に作業を行う方達や管理者が急に腕が上がる訳ではないのです。
ということで、改善に取り組む最初のステップでは、現実的な目標からスタートするべきです。
そして、段階的に目標値を高めていくのが良いと思います。
一方、成果が上がらなければすぐに飽きてしまう、目が向かなくなるのも人間です。
時間が必要だからといって長々と改善を続けていくのは難しい(途中でやめてしまう)側面があります。
ですから私の薦めは、効果が期待できそうな領域の中でさらに絞り込んだ一部分で試行的に改善を進めることです。
このようにすることで、短い期間で、改善成果までを確認できますし、自分たちで考えた改善手段の善し悪しが確認できます。また、自分たちの改善手段が失敗するリスクも最小化できます。
試行で獲得した結果を、次の改善領域に適用する際に、試行からのフィードバックを活用しながら実践できますので、成功率がどんどん高まっていくのです。
小さな成功を積み重ねながら、改善領域をドンドン広げて、最終的に欲しい成果を獲得してください。
■途中でうまくいかなくても隠さない、途中で投げださない
(よい経験、悪い経験を両方成功の糧にする)
改善がうまくいかない組織の特徴の一つは、改善手段(改善のための処置)を実施した結果を早く獲得したい、他者に認められたい(というよりは、他者に悪く思われたくない)などの気持ちばかりが焦ってしまい、うまくいかなかった結果をそのまま受け止められない、ということです。
目の前に事実として存在しているのに、存在していないことにするわけです。
うまくいかなかった、という結果を、良いも悪いもなく、ありのまま・そのまま受け容れられない限り、せっかくの経験をムダにしてしまう可能性が高まります。
そう、途中でうまくいかない状態は、その方法が適切ではない、条件に合わない、何か別の考慮が欠けている、などを教えてくれている。見直すべきことを見直せば、成功に近づくチャンスだ! と知らせてくれているわけです。
ですから、うまくいったことはそのまま継続し、途中でうまくいかなかったことは真摯に受け容れ、何が原因でそうなっているのかを今一度見直してみることが大事です。
途中でうまくいかなかった経験を生かして、最後には成功を勝ち取ることが、以降の改善成果をさらに高めることにつながります。
たとえ小さくても、成功を徐々に重ねていければ、いつのまにか大きな成果が自分たちのモノになります。
最後まであきらめず、途中で投げ出さず、一歩一歩成功を重ねながら進めてください。