スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
【--/--/-- --:--】 | スポンサー広告 | page top↑
事例研究:具体的にPCL等をユニット経営に応用してみると!
さて、今回は、IT企業において、当たり前のツールである、PCL、工程管理図、障害管理票を、IT企業以外の業種の企業または、プログラム開発部門以外のユニットに具体的に応用してみたいと思います。

ユニット経営においては、明確なゴールを設定して、アクションプランに従い、良い結果を導き出す。

つまり、各ユニットが目標設定した具体的なゴールに向かって、アクションを立案して、実践して、そこで発生したさまざまな障害を乗り越えて、最終的な結果を出していく、ユニット全員参加のシナリオを作成していくことになりますね。

前回、お話しましたように、PCLは、プログラム開発のゴールを目指すための検証に関する、具体的なアクションを記述したものだと理解できます。つまり、ユニット経営に応用すると、ユニットの目標としたゴールを実現するために、具体的に実践する上でのアクションプランを具現化し、目標達成するためにメンバー全員の行動を記述していけば良い事になります。PCL(プログラムチックリスト)ではイメージしにくいので、PCL(プランチエックリスト)として意味づけしてください。

ユニット経営は、GPDCAで実践する。G(ゴール)、P(プラン)、D(ドウ)、C(チエック)、A(アクション)で管理していく。

工程管理図は、PCLの予定立案と実践の進捗状況を表すとともに、消化していく上での不良等の問題点を数値化して、その対策状況を「見える化」していましたね。つまり、PCLで作成した、各ユニットの目標を実現するための具体的なアクションを、工程管理図で、予定立案して、いつまでに全てのPCLを完了させるのか実践することになります。

アクションを実践すれば、さまざまな問題点が発生します。そういう意味では、常に、検証と問題点の対策を実施する必要があります。それらの状況をすぐに見える状態にする。また、アクションは、当初に想定したものと異なってくる可能性もあります。つまり、検証時点で、次回のアクションが変わってくるものが多いと思います。変更となったアクションは、また、新たにPCLに追加して工程管理していく事になりますね。

障害管理票は、実際に発生した不良とその原因、対策を管理するものでしたね。ユニット経営においても、Do(実践)した後のCheck(検証)をする事は、実践した内容を確認、問題点を洗い出する事に匹敵します。Action(改善策の立案)は、検証した結果に対しての問題解決と捉えることができます。

以上のように、応用して考えてみると、IT企業の常識である、PCL、工程管理図、障害管理票は、目的を正しく理解していれば、ユニット経営の考え方に準じている事がわかりますね。もちろん、他の業界や業種でも参考になる事が判明したわけです。

ただ、上記の資料は、管理資料として、決して捉えないでください。
※最も大切な事は、これらの資料を残してサンプル化して精度を高めていく事

みなさんの企業の中にも、さまざまな業界標準の管理資料と言われてきたものがあるかと思います。ユニット経営の原理原則に従い、見る目線を変えていけば、もっとすばらしいものが見えてくるのではないでしょうか。私は、そう、思います。

スポンサーサイト
【2008/07/07 15:15】 | ユニット経営 | トラックバック(0) | コメント(0) | page top↑
事例研究:問題が多発しているユニット。さて、どうしたものか?
これは、当社で実際にあった事例です。問題を起こしているユニットは、かなりの確立でいつも同じ部門である。当社には、システムを開発するユニットが存在します。IT企業なので、当然といえば、そのとおりですが、開発をするユニットには、必須となるしくみがあります。

PCL(プログラムチエックリスト)、工程管理図、障害管理票で進捗状況を把握する。

このしくみは、システム開発では基本中の基本であり、必要最低限の条件なのです。ところが、このしくみを利用して実際に作業をしても、全く意味をなさないケースが発生します。それは、これらのしくみの目的を理解していない場合です。目的がすり替わり、作成すればよいという認識、つまり、面倒であるが会社の方針なので仕方なく実行している場合です。このケースの際には、「そこには、やらされ感が発生します。」 いわゆる、ヤレッ!と言われているので仕方なく実行している場合です。

こういう状態においては、メンバーの心の中には、「悪魔が発生しています」 この悪魔は、常にメンバーに囁きます。「この程度でよいだろう」とか、「これくらいなら、文句はこないだろう」などというものです。このような状況においては、完全に目的が消えさってしまい、作成する事が目的となってしまう。「本来、何のために必要なのか」という、本来目的は、どこにも見当たりません。

では、PCL、工程管理図、障害管理票は、何故必要なのでしょうか? それは、開発工程において、「それが正しく機能している証拠証明のため」です。なお、実際には、業界では、単体テスト、結合テスト、運用テストなどにおいて、それぞれ作成するのが、一般的となっています。

ユニット経営においては、アクションプランの立案をする際にも、重要なヒントになります。この考え方を導入して、ユニット経営を実践される事をお勧めします。各ユニットの状況に応じて、内容を別のキーワードで読替えて実践してみてください。

1.PCL(プログラムチエックリスト)
 開発したプログラムが仕様どおりに正しく機能しているのか、実際にエンドユーザが使用する場合に、起こりうる可能性のある事象を想定して、検証項目を設定して、正しく動作するのかを検証するために作成するチエックリスト。
2.工程管理図
 作成されたPCLをどのように検証していくのかをまずは、予定を立案。実際にその予定にしたがい、作成したPCLを消化していく様子を図と数字で統計を取っていくものです。これらの工程中に発生した不良の件数とその対策状況も合わせて管理するため、実際にどのように検証を進めていくのかを「段取りの見える化」する票。状況により、PCLを追加して検証補正することもある。
3.障害管理票
 発生した不良に関して、どのような内容で、それらの原因は何で、どのように対策をしたのかを記述していく票。この票の件数は、工程管理図で管理されており、発生する不良に関しても事前に予測を立てて、それに対処できるPCLの不足を補うなどの連携がされている。この票は、問題解決の管理として、発生事象、原因究明、対策立案という事象管理をする。

上記のすべてがトータルで管理されるからこそ、それらの相乗効果を得られ、より性能と品質を維持した、いわゆる、「いい仕事をしてますね!」 に繋がると思います。
【2008/07/07 11:30】 | ユニット経営 | トラックバック(0) | コメント(0) | page top↑
| ホーム |
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。