2010-02-23 22:56:27

プロセス改善とは?の1回答

テーマ:今日の出来事

今日はSEC主催のプロセス改善セミナーに、1コマ講師として参加させていただきました。


内容は「プロセス改善ナビゲーションガイド~虎の巻編~」の解説を通して、プロセス改善の進め方の例をご紹介するというものです。


プロセス改善ナビゲーションガイド 虎の巻編―改善のゴールに一歩近づくために (SEC BOOKS)/著者不明
¥1,500
Amazon.co.jp

(げげっ。著者不明って、なに?!)


以前にご紹介しましたが、わたしもこの本の著作チームに参加させていただいております。



少々暴露をいたしますと、このセミナーで使っているプレゼン資料は、わたしが作ったものではなく、同じ執筆チームに参加されていて、最初にこのセミナーの講師をされた方が作られています。

なので、資料の内容にわたしの個人的な思いや経験などは盛り込まれていません。その分、話す内容には多く含めるようにしました。


わたしの話し方は評判がよくないので、内容は良くってもアンケート結果が悪かったりするケースも多々あり。

それでも、あまり気にせず話してしまいました。


話すことで、自分がそれまで気づいていなかったことも見えてくる。そういうことがあるので、途中からエキサイトしてしまうのですね。だから評判悪いのかもしれない。反省。(たぶんしない。)


今回は「プロセス改善って何だろう?」ということの、1つの回答を見つけました。


回答というか、言い回しでしょうか。


プロセス改善とは、会社を倒産させないためにどうすればいいか?ということを社内の全員が考え、行動するための活動。


いかがでしょうか?

これは、今のような経済状況が厳しいときだからこそ使える言葉かもしれません。


会社が潰れたら、困りませんか?

これは新入社員から社長まで、簡単に答えられる質問だと思います。安易に聞こえるかもしれません。でも、だれもがわかりやすいから、必要性が共有できるのだと思います。


あまりに簡単な言葉を使うと「バカにしている」と思うような方もたまにいます。しかし企業の経営者の多くは簡単な言葉で説明することに好意的です。それは、自分が理解できればいいというのではなく、ひとりでも多くの社員が理解できる言葉が大切だ、ということを知っているからなのだと思います。


全社員が単純に理解できる共通の「困った」状態である「倒産」。それを起こさないようにするにはどうすればいいか?


ちょっと刺激は強すぎますが、これならみんな自分のこととして受け止め、考え、行動してくれるのではないでしょうか?

2010-02-17 23:17:56

フォロアーシップとは

テーマ:今日の出来事
今日、いろいろあって部下に言ったことで気付いた。

リーダーは忙しい。報告を失念することもある。それはリーダーの責任。


でも、真のフォロアーはリーダーと同じように「プロジェクトを無事に終わらせる」ことに思いを持ち、リーダーの忙しさを重々承知で、リーダーを煽らないといけない。


問題発覚の報告に十分な対策指示がないのなら、それが出るまで問い続ける。このままではいけない、と。

報告したらあとはリーダーの責任と、投げ出してはいけない。プロジェクトはプロジェクトの成功以外に、幸せは得られない。


それを踏まえてリーダーを動かすのがフォロアー。

2010-02-15 20:28:07

名古屋で改善推進者ワークショップに行ってきました。

テーマ:今日の出来事

前の記事で少々毒を吐きましたが、ワークショップそのものは大変有意義で、しかも楽しく参加できたのでちゃんと書いておきます。


名古屋においては“とある有力者”の主催であるためか、参加者数も40名ぐらいいてワークショップとしては大規模なものでした。


SECワーキンググループで作成した、改善の問題点を抽出するためのワークシートがあるのですが、それを記入してもらって、それをネタにディスカッションするという内容でした。


ワークショップとしてはとてもスタンダードな内容だったのですが、久しぶりに改善推進担当者の方たちと直接お話をして、いろいろと気づかされることがありました。


わたしが加わったチームには、まだ新人で業務も経験したことのない方がいたのですが、その方の意見が「改善もやらされ感をなくして取り組めば、仕事にやる気が出て効率も上がると思う。」と、今まで言い尽くされてきたことかもしれませんが、実にピュアに改善の本質を語っているものでした。


他の業務経験豊富な参加者は、改善の重要性なども重々承知で、現場だって苦労しているのもわかっているから。そういう様々な制約条件がフィルタになってしまって、自分たちは一体なんのために改善に取り組んでいるのか、という点を素直に口にすることができなくなっていました。


経験は重要です。そこから学んだ様々なことは、日々の業務を遂行するための原動力になっていることでしょう。しかし、ときにその経験は、というか、その経験により作られた固定観念が、本当に大切な何かに霞をかけてしまうこともあるんだな、と、気づかせてもらえたいいワークショップでした。


そして、SECのメンバーでいたからこそ、このような場に数多く参加する機会がもらえて、改善に関わる自分の視野をいつも広げてくれているということにも気づきました。


自社のことだけを見ていると、そこの事情に振り回されてしまって、改善の本質を見失ってしまうこともしばしばありました。しかし、そういう制約とは一切関係ない人たちと、改善に関する深い議論ができたことで、自分の世界に留まることなく、いろいろな考え方や方法を取り入れようとする姿勢を持ち続けられたのではないかと思います。


もうSECの活動も3年になりますが、まだ新しい出会いの場をいただいています。これからも微力ながら多くのみなさんの改善活動を助けていけるように、地道に活動していけたらいいなと、心に小さく刻んだ一日でした。

2010-02-15 14:26:09

朝会がないことの違和感

テーマ:今日の出来事

本日は、名古屋でSEC主催のワークショップにチューターとして参加しています。

まだ始まったばかりなので、ご参加いただいたみなさんに楽しんで何かを持って帰っていただけるように、これからがんばりたいと思います。


ところで。


今日は準備のため午前中から会場にいるのですが、着いた途端に数人がわさわさと動き出し、何らかの準備がはじまりました。

でもわたしは今までSEC主催のワークショップには参加したことがなく、どう動いていいかわからないままほぼ午前中が終わってしまいました。


なんかモヤモヤしたまま、ワークショップは始まり、30分ほどの担当プレゼンも終わらせました。(今ココ)


なんだろう、このモヤモヤ感。


そうだ。朝会がないからだ。


今日誰が何をして、どういうアウトカムを求めるか。毎朝それを確認しながら仕事するから、最初からキビキビと動けるのだろうに、それがないまま作業が始まっちゃうと、やっぱりなんかウロウロする。それでも何とかできちゃうから、これを見直そうという気持ちにならないんだろうなー。やっぱり日々の仕事を「見える化」してから動くのと、そうでないのとでは作業の成果にマイナスイメージのフィルタをかけてしまいそうだ。


なんてこと、今考えていたら「見える化」が大切なことを知るために「見えない化」をやるワークショップとかすればいいような気がした。例えば、わざと空中戦やって、一度結論だけのプレゼンしてもらって、再度討議をして他の人が発表してみる。さて、討議したメンバーは本当にその中身を理解していたでしょうか?


ワークショップというより、実験だけしてみるのもいいかもしれない。



まー、それにしても、SEC主催のワークショップなんだから、やっぱり朝会やりましょうよ。(毒)

2010-02-01 22:52:38

星野リゾートに学ぶ、メトリクスとは何なのか?

テーマ:今日の出来事

今、カンブリア宮殿を観ていました。今日は「星野リゾート」でした。

経営破綻した宿泊施設でさえ、人気のリゾート施設に再生する「リゾート運営の達人」のお話。


この中で、ホテルのスタッフがリピータのお客様を迎えるまでに、数人のメンバーで編成されたチームが徹底的に顧客の過去情報を分析して、どのようなおもてなしをするかという作戦を練っていました。


この過去情報とは「気づき情報」という名で、その顧客が以前宿泊したときに、とても細かいことでもスタッフの目線で気づいたことをコンピュータ上の情報共有ツールに入力しておくもの。

それを利用して、今度おもてなしをするスタッフは具体的なおもてなし戦略を作るのです。


これをみて、はたと気づいたことがありました。

わたしたちも、生産性やバグ率などのメトリクスは収集しています。面倒くさいと思いながらも。


一体、このメトリクスは何のために蓄積しているのか?


理屈ではわかっていても、どこか腑に落ちない部分を抱えていることが多かったように思います。では、その違和感は何か?品質や生産性の指標は、顧客に対して自分たちが「精一杯やっていますから認めてください!」と、ある意味では言い訳の材料にしようとしていたからではないか?揉めたときの交渉の材料にするため、と思ってはいないか?


「説明責任」のための材料ということは、全面的に否定するのもではありません。必要なこともあると思います。しかし、それが最初から前提でメトリクスを収集するというのは、最初から顧客を「仮想の敵」として考えているように思えてなりません。


話の最初に戻ります。

何のためにメトリクスを蓄積するのか?それは、最終的に「顧客満足を得るため」とすることが必要なのではないでしょうか。


そこに至るプロセスとして、説明責任としてのメトリクスという考え方は“あり”だと思います。

でも、本来は「お客様が満足して対価を支払ってもらうための資料なんだ」と、言葉を変えて「想う」だけで、そのメトリクスを収集することへのモチベーションは劇的に変わるのではないでしょうか?


わたしの以前の役割である「プロセス改善推進担当(SEPG)」としてそこに役割があるとすれば、やはり「顧客満足を得るためにメトリクスを収集するんだ」という思いを、もっともっと伝えていく必要があると思います。


なぜソフトウェア工学を使って顧客の理解を得ようとするのか。顧客が理解してくれる、ということはそのまま「顧客満足を得られた」と考えてよいのではないでしょうか。


自分たちの言い訳をするためと、顧客に満足・納得してもらう、ということの目指すゴールは異なっても「メトリクスを収集し分析する」というプラクティスは変わりません。しかし、そのアウトプットの質は大いに異なるように思います。


計測やプロジェクト運営に仕組みを作っていくこと。そしてそれを例外なく守っていくこと。それらの意義を説明する言葉に「顧客満足」が必ず繋がるように説明しつづけること。


大事なことなので2回書きます。


メトリクスは顧客満足獲得のためのツール


それはメトリクスに限ったことではないと思う。その他様々な「開発には直接関係ない、諸々の面倒なこと」と思われがちな活動に、魂を吹き込めるかどうかは、SEPGが如何に顧客満足と繋げてその必要性を伝えらるのか、ということにあるんじゃないかと、星野リゾートのスタッフの、生き生きとした働きぶりが教えてくれました。


いつか、星野リゾートのホテルに泊まってみたい。

Amebaおすすめキーワード

    アメーバに会員登録して、ブログをつくろう! powered by Ameba (アメーバ)|ブログを中心とした登録無料サイト