問題構造分析とPFDの併用による現実的・段階的な改善実践方法の提案

鈴木三紀夫 @mkoszk_live

問題構造分析とPFDの併用による 　現実的・段階的な改善実践方法の提案 　　～PFDを使いこなす能力を確実に身に着けるために～

鈴木三紀夫 @mkoszk_live

予定より早く始まりました。

鈴木三紀夫 @mkoszk_live

みなさん、こんにちは。（みんな疲れた感じ） 今日、最後の講演になります。くつろいで聴いてください。 この方法は、自社の問題点を改善するにあたって、使っている方法です。 でも、課題がありました。 PFDを作っていく過程で課題が残りました。 それを解決する方法を考えました。

鈴木三紀夫 @mkoszk_live

提案の背景。 PFDでプロセス記述が簡単だと思っていません。 PFDを仕事で使っている人、手を挙げて。（以外と少ない） 効果があるなと実感する人、手を挙げて（以外と多いですね） 自社でトライアルしたとき、効果を実感できませんでした。 清水さんの本を読んで試しました。

鈴木三紀夫 @mkoszk_live

スタッフ部門が書けても、現場で書けない。 なぜか。 自分たちの仕事を把握していないのが第一。 レビューをやったり、やらなかったり、それをはっきりさせていないので、 どのように書いて良いのか分からない。 そもそもPFDの書き方が分からない。

鈴木三紀夫 @mkoszk_live

PFDを書いているんだけど、現実に当てはまらない。 一般的なプロセスを書いているだけなので、メリット、効果が分からない。 でもって、問題点も分かりません。 ですから、書いて終わってしまい、活用しなくなります。

鈴木三紀夫 @mkoszk_live

プロセス設計について。 CMM(TR25)のプロセス設計の概念について。 （よく、清水さんがお話で取り上げる図ですね） ISO9000を導入するとき、プロセス設計を行った。 このときプロセス資産をどのように作ればよいのか分からない。

鈴木三紀夫 @mkoszk_live

プロセス資産はこのように作られていた。 ・他社のプロセス。 ・スタッフの想像。 ・上手くいったプロセス。 これは現場で使えない。

鈴木三紀夫 @mkoszk_live

プロセス改善の鉄則。 現状のプロセスと改善後のプロセスを表現する。 でも、現状のプロセスを現場の実際のプロセスを書かないので失敗する。 （開発プロセスだけでなく、業務要件定義の業務プロセスもそうですね。）

鈴木三紀夫 @mkoszk_live

手間をかけてプロセスを作ったのに上手くいかない。 そのための提案手法。 いきなりプロセスを書くのではなく、プロセス設計のワークを徐々に広げていって、プロセス設計の力を付けていく方法。 そのために使うのが問題構造図。

鈴木三紀夫 @mkoszk_live

問題構造図。 嫌なことを因果関係で繋げた図。 テストが少ない　→　納品後に怒られる。 とか。 この問題構造図はPFDと相性がいいだろうなと。 （古畑さんも僕もそう思っています。）

鈴木三紀夫 @mkoszk_live

問題を事実をもとに挙げてもらいます。 そして因果関係を粗く分析します。 追加で調査することもあります。これは後の発表で効いてくる。 つぎのプロジェクトで何とかしたいところを探る。 このときには、PFDを使っていない。

Yasuharu NISHI @YasuharuNishi

問題を解決するための手段としてプロセスを精緻に記述しようとすると、いつしかプロセスを精緻に記述することが目的になるからね。あるある。

鈴木三紀夫 @mkoszk_live

最初はこのときPFDを書かせていたけど、ものすごい工数がかかっていたので、今は辞めている。 さて、問題構造図にある問題事象は、「事象」なので、PFDに書かれるプロセスの候補でもある。そこに着目している。 PFDの表記方法に合わせていく。

鈴木三紀夫 @mkoszk_live

現場に合うプロセスを作ると、そのあと課題・問題事項を検出しやすくなる。 こんど、青いところを攻めるとき、レビュー領域を深掘りして、その深掘りしたいところで、詳細のプロセスを作っていく。

鈴木三紀夫 @mkoszk_live

改善が進んでいくと、あるプロジェクトの途中にきたところで、赤いリスクを予想して、青い対策を打っていく。 予防処置を途中で打つ。 先を見据えたもの。これを時系列で説明すると。

鈴木三紀夫 @mkoszk_live

（いやぁ、問題事象とリスクを一緒に語っているので、聴いている人は混乱するかも）

鈴木三紀夫 @mkoszk_live

問題からプロセス設計をすることは、正当なプロセス設計を実践している。 問題事象で改善したいこと、やりたいことが明確でなければ、プロセス設計をしても使われない。 「要求を獲得する」というのが、次のプロセスのどこに影響するのか分からないと使えない。 負の事象の先読みができる力が得。

鈴木三紀夫 @mkoszk_live

リスクの構造的先読み。 風が吹けば桶屋が儲かる。三味線が売れるには、目が不自由な人が三味線を使うというドメイン知識を知らないと、構造図を書けない。 構造的な先読みができるようになれば、最小の手間で最大の効果が得られる。 そのためには、鍵となる要素や知識が必要になる。

鈴木三紀夫 @mkoszk_live

少しずつ改善をぐるぐる回していくことで、この鍵となる要素や鍵が得られるようになる。 的確に先読みができるようになる。 ダイナミックなプロセス設計ができるようになる。 PFDと問題構造図は強いところ弱いところを補完できるようになる。

Yasuharu NISHI @YasuharuNishi

あだちさんのアプローチは、極めてオーソドックスだ。SPI、テスト、レビュー、開発、QCなど、多くの知識と経験に裏打ちされている。だからこそ、そのオーソドックスさが凄まじい威力を発揮するのだと思う。これだけオーソドックスなアプローチの発表で僕が面白いと思ったのは本当に久しぶり。

鈴木三紀夫 @mkoszk_live

これを使って、このノウハウを使って、フィードバックを使うのですが、次にフィードフォワードできるようになる。２～３ヶ月の小さな改善をぐるぐる回しながらね。

鈴木三紀夫 @mkoszk_live

課題もあります。 自分たちが仕事として認識している姿と、 実際の姿と、 それを表現する この３つを一致させるのが大切なのですが、これができない。そういう仕事の仕方を上手く回していく。

Yasuharu NISHI @YasuharuNishi

「見える化」という言葉を使いたがるが表面的にしか見える化を理解していない浅はかなコンサルとは対称的に、「見える化」という言葉を全く使わずに本当の「見える化」を説明しきった安達さんに拍手。

鈴木三紀夫 @mkoszk_live

質疑応答。 PFDと問題構造図を重ねて使っていきたいと思う。スライドでは、うまく重ねられているけど、実際はどうやっていますか？ ＝＝ いくつかの方法を採用。絵が巨大になるとパワポだと溢れるのでExcel使用。 貼り付けて、色を薄くして、その後、オブジェクトを貼り付けていました。