分12今回は,現場力を高めることについて,考えてみます。問題が起きた際に,自分たちで解決できることが高い現場力なのでしょうか?問題が起こらない組織やプロセスを構築することが高い現場力なのでしょうか?現場力の定義にはいろいろあるでしょうが,最初はやはり抵抗が目立つものです。我々が業務改善のコンサルティング現場で目の当たりにする場面をいくつか示しながら,これまでの連載でお伝えしてきたことを振り返ってみましょう。無関心現場における初回キックオフ現場の拒否反応の兆しは,最初の顔合わせの段階から見え隠れしています。我々が業務改善のプロジェクトに入る前には,入念に依頼者であるコアメンバーと打ち合せを行い,業務上の問題だけでなく組織特性,社員のカラー,企業風土などの話を伺いながら「変革の青写真」を作り上げます。現場のメンバーとの初顔合わせはキックオフと称する1,2時間のミーティングです。依頼者のコアメンバー側からプロジェクトの目的を伝え,続いて我々からどんなスケジュールで,何をどうやって進めていくかを伝えます。事前に打ち合わせを行っていたコアメンバー以外は,我々も初対面です。現場のメンバーも同じで,社外の我々が入ってきたことに対してあからさまに警戒を示す人,ナナメに構えている人,不安そうな人などが皆一様に我々の品定めをします。考えてみれば当たり前で,ただでさえ忙しいのに,よくわからない業務改善のキックオフミーティングに呼ばれて(内心,出たくない⁠)⁠,初対面の我々から小難しい話を聞かされるわけですから。改善に無関心な現場であればあるほど,いざ改善が始まろうと差し迫ってくると,それなりの主義主張をし始めます。やらないための悪あがきキックオフの後には質問の時間を設けていますが,現場メンバーが警戒を示している,ナナメに構えているときは,どこの会社も同じような質問が出ます。下記のような質問で,「⁠→」以下は我々の心の声です。今まで職場で取り組んできた改善活動と何が違うんですか?→それがうまくできていたら,今この場に我々はいないけど。改善の時間は定時後や土日じゃないと取れません。残業代,出るんですか?→残業代?改善は仕事だと言ったのに聞いてないな~(⁠第7回参照⁠)⁠。改善のせいで,仕事が遅れたら責任取れますか?→責任...?別に我々は困らないし,我々が取るものでもないけどね。今期の人事の目標設定に業務改善はないんですけど,評価されるんですよね?→改善できてから言おうね!まぁ,このように"やらないための悪あがき"をするものです。「⁠文句ばかり言ってないで,せっかくの機会だし,今までの膿を全部出し切ろうよ!」と頼もしい人もいます。この段階では変革者として本物か似非かまでは見抜けませんが,コアメンバーや我々としては内心,「⁠そうそう,もっと言ってやれ!」と思っています。そこで,質問者は「そうは言ったって,課長。?」と今度は矛先を自分の上司やコアメンバーに向けるわけです。我々もそれなりに場数を踏んでいます。言って慣れるものではありませんが,この程度であればかわいいものです。第2回,第3回では,ソフトアプローチ,ソフト改革を同時に走らせる話をしましたが,このソフト改革を上手に走らせないと,現場には"やらされ感"が出るので,ファシリテーションも必要になることは以前にお話したとおりです。ある程度の時間をかけながら,我々と現場の信頼関係を築くことは欠かせません。「できない」ではなく「やらない」さて我々は,改善の初期段階ではいろいろな切り口で,現場の問題を聞きます。1対1でヒアリングをする場合,グループディスカッションをする場合,付箋紙や模造紙を使うこともあります。業務モデリングを終えているときは,すでにできあがっている業務フローを眺めながらとケースバイケースです。第8回で,問題の深掘りの話をしていますが,問題出しで多く見られることは,下記の2つです。2:解決策と一緒に問題が出てくる→例)「⁠□の問題が発生しているので,×すればよい」それぞれ,原因が深掘りした根っこの原因となっているか,問題がまだ現象レベルの表層のものかは別にして,我々は少し意地悪にこう言います。「解決策がわかっていて,なぜやらないの?」こう問われる現場の答えも決まっていて,「⁠うちの部門じゃないから言いにくい」「⁠やる時間がない」「⁠それはうちの部門の仕事ではない」などが8割以上です。第17回,第18回で話をしたような経営に食い込むような内容ではありません。改善の実行に恐ろしく費用がかかるとなれば,慎重にならざるを得ませんが,そうでない理由ばかりです。弱くなる現場その気になれば改善できるものに対して,"やらない理由"をこの後には延々と述べるわけです。問題だとわかっている,原因や解決策も目処がついているけど,先送りをしてしまい,日常の業務の繁忙さに埋没する繰り返しです。要は「できない」ではなく,「⁠やらない」だけです。このような状態が長く続くと,現場の底力である「本質を見極める」「⁠何が原因か徹底的に探索する」ことに必要な"考える力"が弱くなり,その場しのぎの対処療法で片付けようとします。いわゆるモグラたたき状態に陥ります。ゴール著者プロフィール世古雅人(せこまさひと)メーカにて開発エンジニアと半導体基礎研究(国の研究機関出向)の計13年を設計と研究開発の現場で過ごす。企業風土改革,組織・業務コンサルティング会社や上場企業の経営企画責任者などを経て,技術の現場あがりの経験や知識を活かした業務改善やコンサルティングなどに従事。経営を巻き込んだ「プロセス共有型」のコンサルティングスタイルを推し進めている。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。その他の連載CSS3アニメーションでつくるインターフェイス表現CSS3によるアニメーション表現を紹介していきます。その中でも,幅広い読者に応用してもらえるだろうインターフェイスを主なお題とします。MySQL道普請便り本連載では,MySQLを使ったアプリ開発・運用に関するノウハウをご紹介していきます。RecipeUbuntuの強力なデスクトップ機能を活用するための,いろいろなレシピをお届けします。JavaScriptセキュリティの基礎知識JavaScriptに関するセキュリティ上の問題はどこで発生し,どうすれば防ぐことができるのか?について解説していきます。〜システムをきちんと運用するための基礎知識システムは「作って終わり」ではなく,運用の中でさまざまな問題が発生します。問題の発生に備えて事前にどのような対応をしておくべきなのか,問題発生時に何をしなければならないのか,ポイントを解説していきます。きたみりゅうじの聞かせて珍プレーソフトウェア開発の現場で体験したトホホな失敗,思わずうなる珍プレーをきたみりゅうじ氏が四コママンガで紹介。Linuxのメンテナンスの傍ら,Linuxやオープンソースソフトと日々を過ごす著者が,その魅力とつきあい方を,エッセイ風味でお届けします。PRESS特別編集部員,さわやか笑顔のスーパーハカーはまちちゃんとネット大好き14歳わかばちゃんが,毎号,読者の皆さんから寄せられたおたよりを紹介します。皆さんの日頃の悩みにも答えちゃいますよ。]メールでのお知らせメールで次の案内をお送りしております。メールの配信を希望する方は,利用したい項目をチェックしてメールアドレスを入力し,[登録]ボタンをクリックしてください。UPDATES[ほぼ週間に1回]新刊メールマガジン[ほぼ週間に1回]電脳会議の各号案内[ほぼ1ヵ月半に1回]※変更する場合や停止する場合は,登録情報変更ページをご覧ください。※登録いただいたメールアドレスには,そのお知らせ以外,配信いたしません。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。