2009年10月23日

[コンセプト]PDCAサイクルのあるべき姿

更新が不定期ですいません。

さて前回の話から明らかではあるのですが、PDCAで分析ができないのは、そもそもが分析すべき対象が存在しないからです。
つまり、PDCAは仮説検証のサイクルであるにも関わらず、仮説として設定されていないということです。
ならば話は簡単で、検証が可能なように仮説を設定するれば良いと言うことになります。

まず、目標は仮説になりません。
目標が不要であると言うのではなく、目標を達成できるように仮説を設定するのがマネージャーの仕事なのです。

こうした話になると、必ず今よりも広いマーケットを設定してという話が出がちですが、現実問題としてそれが上手く行ったという話はほとんど聞きません。
なぜならば、そうしたマーケットには強力な競合が既にいるか、そもそも需要がないからです。
こうした戦略が出来るのは、卓越したブランドを持っているか、業界トップの企業が周辺の領域へ進出するときぐらいでしょう。
要するに強者の戦略なのです。
世間の大半の企業にとっては関係がない話です。

では、製品力も価格もブランド力も何も差別化できていない場合はどうすべきでしょうか。
顧客が購入しているのが単純に製品そのものである場合は難しいのですが、大半の場合において顧客が求めているのは商品であり、商品とは製品+サービスです。
サービスは例えば支払方法であるとか、キャンセル可であるとか、相手が法人の場合は社内稟議の代筆など非常に幅広く考える事ができます。
明らかに自社製品が向かないが繋がりを維持したい場合は、あえて競合製品を推薦するというのも、サービスです。
つまり、マネージャーが設定すべき仮説は、目標を達成可能なサービスであると言うことになります。

と、ここまで書いてきましたが、大概の営業関係部署では大なり小なりこうした事をやっているはずです。
しかし、振り返ってみるとあまり変わり映えしないことを続けていると言うのも現実でしょう。
すなわち、こうした取り組みの結果が定着または積み重ねられていないと言う事です。
次回このあたりについて書きたいと思います。
posted by Senoh at 01:04| Comment(0) | TrackBack(0) | コンセプト

2009年09月01日

[コンセプト]上手く行かないPDCAサイクル

業務の改善手法としてPDCAサイクルがあります。
PDCAサイクル自体は有名なものなので、ご存知の方も多いでしょう。
しかしその一方で、営業活動などのホワイトカラー業務ででPDCAサイクルが上手く回っているという話はほとんど聞く事ができません。
もちろん全てがというわけではありませんが、ここではありがちな上手くいかないパターンについて考えます。

よくある、営業活動に対するPDCAサイクルは以下の様なものでしょう。

1. 予定として売り上げの目標を設定し、そのための顧客リストを用意する
2. 受注活動を行い、記録を残す
3. 目標が達成されたか確認する
4. 達成されていない場合は何が問題か分析し、改善案を立案・実行する

さて、目標が達成されているならば問題はありません。
問題になるのは達成されていない場合です。

では、目標が未達の場合は、どう分析すれば良いのでしょうか。
明らかな問題があるならば、それを改善すれば良いのですが、それはPDCAサイクル以前の話でしょう。
普段から鎬を削っているような場合は、そうした問題は既に潰されているため、「原因」を探るのは大変困難です。
そもそも営業マンの立場からすれば、「目標が高すぎる」と思わないわけがありません。
実際、無理なノルマを課しているだけという可能性はあるのです。

なぜ分析できないのか。その理由は簡単です。
目標が妥当である事を誰も証明できないからです。
会社を取り巻く環境は日々変化するのですから、過去の実績は根拠になりません。
本来、もっと目標は高くできるのに、なんとなく惰性で目標を低くしてしまっている事もあるでしょう。
会社が大変だから10%アップしろと言われても、それで売り上げが上がるわけもありません。
ベースになる数字に根拠がないならば、それをもとに分析できるはずがないのです。

次回、PDCAサイクルはどうあるべきかについて、自分の考えを書きたいと思います。
posted by Senoh at 20:57| Comment(0) | TrackBack(0) | コンセプト

2009年08月24日

[コンセプト]業務マニュアルとシステム

考えていた事を整理していたら、ずいぶん長い間更新が滞ってしまいました。すいません。

さて前回の続きですが、業務における「プログラム」とは何であるかと言えば、業務マニュアルが思いつきますが、これが妥当か考えてみます。

まず、プログラムは良く調査して該当箇所を変更することにより、システムの動作を変更することができますが、同じ事がマニュアルに対して行えるかと言えば疑問があります。

その理由は、マニュアルを変更しても、それだけでは誰も確認してくれないからです。
すくなくとも説明会も開かずに、運用ルールを変えられる会社はほとんどないでしょう。
マニュアルは参考にする程度のもので、組織はそれに基づいて動いているわけではないということです。

次にプログラムには、システムの全ての動作が記述されていますが、マニュアルはどうでしょうか。
例えば部門の社員を全員入れ替えて、マニュアルだけみせたとき、たとえ時間がかかろうとも前と同じように業務を遂行できるかということです。
これも常識的に考えて不可能でしょう。
現場には、マニュアルに書かれていない暗黙の運用ルールが必ず存在するものです。
なぜそうなってしまうのかと言えば、現場主導で業務を見直しているからです。
もちろん、そうした活動自体は良い事なのですが、その結果効率化が阻害されることがあるということです。

経営者の方々はこうした問題を普段から肌で感じているからこそ、運用ルールを抜本的に変える場合にシステム化の検討をされているのではないでしょうか。
つまり、システム化されれば、新しいルールを意識せざるを得ませんし、システムの指示に従うことでバラツキなく業務を遂行させることができるからです。
しかし、システム化は初期コストがかかるだけでなく、それを変更する場合にもコストが発生します。
これはマニュアルにはない欠点です。

マニュアルは柔軟であるが厳密性に欠け、システムは厳密ではあるが柔軟性に欠けると言うことになります。
ならば、システムの中にマニュアルの柔軟性を取り込めば良いのではないかと言うのがZiraffeのコンセプトです。

次回以降、もう少し具体的な形で検討をしたいと思います。
posted by Senoh at 03:26| Comment(0) | TrackBack(0) | コンセプト

2009年07月13日

[コンセプト]ブラックボックス化について

ソフトウェア開発の世界においては、ブラックボックス化という考え方があります。これはシステムの各部分に対して、それが外部とどの様にやり取りをするのかさえ定義してしまえば、その内部構造は見えなくても構わないはずであり、ならば積極的に見えないようにしようと言う考えです。適切なブラックボックス化はシステムの構造を単純にし、効率よく開発が出来るようになります。これは業務に置きなおしてみると、仕事のやり方の変更も含めて、現場に権限移譲するイメージと言って良いでしょう。

ブラックボックス化は内部の実装方法に自由を与えるため、何か変更が必要な場合でも対応が容易であるとされてきました。しかし現実には、何か仕様変更をする場合は複数のモジュールにまたがって変更が必要な事が大半であり、結局内部の実装が分かっていなければ適切な対応を行う事はできません。

これを業務に置きなおすと、既存のサービスを一部変更するにあたり各部門の調整をしようとしたが、「その業務を自分の部署で引き受けるのは難しい」という言葉ばかりで出て、話がまとまらないような状況です。解決案を出そうにも部門内の詳細が分からないため上手く言えない、どうしても自分の考えを理解してくれない、そんな経験は数多くあるはずです。実際、部下の仕事を全て自分でも対応できる自信がある人は少ないでしょう。ほとんど方が、周囲に色々とやり方を聞きながら辛うじてといったところだと思います。自分が思っているほどには部下の業務の手順を理解できていないのです。

さて、では業務における「プログラム」は一体何なのでしょうか。次回のコンセプトではこれについて書きたいと思います。


posted by Senoh at 03:27| Comment(0) | TrackBack(0) | コンセプト

2009年07月06日

[コンセプト]経営とプログラミング

前回のコンセプトの続きです。

経営とは事業を続けることであると考えた時、一番重要なのは環境に合わせて変化することではないかと思います。これはパッケージのソフトウェアでも同様で、常に変化し続けていなければ、少なくとも商品としては価値が無くなります。変化が無くなれば、後続にキャッチアップされてしまい、単純な価格競争に陥ってしまうためです。

さて、ではソフトウェアを変化させ続けるにはどうすればよいのでしょうか。
明確なビジョンを持つことでしょうか?
新しい技術を導入することでしょうか?
もちろん、それらもあるでしょう。しかし一番重要なのは、身も蓋もない話ですが、そのソフトウェアのプログラムが書きかえられる様に出来ていることです。大概の場合、ビジョンや新しい技術を用意すること自体は難しくありません。問題は、それが実現できないと言うことなのです。
この事は経営においても、同じ事が言えると思います。

実現できないのは、プログラムが書きかえられなくなってしまうからです。
ではなぜ、プログラムは書きかえる事ができなくなってしまうのでしょうか。多くの場合、プログラムは何度も書き変えられる毎に、その影響範囲が読みにくくなります。影響範囲に不安があるため、変更するよりも外部にプログラムを追加して、対応することが増えます。その結果、同じような処理がいたるところに発生し、ますます可読性がなくなります。
すなわち、プログラムと言うものは、追加・変更する毎に徐々に変更できないものに変わってしまうものであると言う事です。

これも経営において同じことが言えると思います。
例えば、組織が硬直化し新規にやりたいことがあっても既存の組織では対応できず、新しい部署を起こしたが従来の業務と被る部分が多く、全体としてますます混乱してしまうと言った状況です。

では、どうすべきなのでしょうか?
その答えも、身も蓋もないものですが、プログラムを書き換えられるようにすればよいのです。続きは次回のコンセプトで書こうと思います。


posted by Senoh at 02:33| Comment(0) | TrackBack(0) | コンセプト