分12改善対象範囲を決めることはナンセンス業務改善は,部門ごとにこじんまりと始める場合もあれば,部門全体,あるいは全社的に大掛かりに取り組む場合もあり,様々です。本来,業務改善に「対象範囲を定める」という考え方はナンセンスだと考えています。その理由は2つあります。この段階では,なんとなく「業務改善をやるぞ~」と改善の狼煙が上がっているだけで,きちんと現状調査や業務分析を終えているわけではありません。どこが問題なのかわかっていない段階で対象を絞ることに意味がないというのが1つの理由です。2つ目の理由は,最初に対象を限定してしまうと,そこだけしかやらなくなることです。仕事は自部門だけで完結するものは意外と少なく,必ず,前工程と後工程が存在します。実際に改善が進んでいくと,前工程の業務から改善を行わないと,後工程だけでは改善の限界が見えてくることが多くあります。前工程の業務改善がなされておらず,後工程だけではカバーできない,改善効果が得られない場合は,前工程の部門を巻き込む必要が出てくるからです。改善対象にならないことを願う??改善などやりたくないから,対象にならないように願っている現場。本来は現場を率先していかなければいけないミドルマネジメントが,部下と一緒になって「やっても意味ないからな~」と発言している部課長。第1回,第2回で述べてきたように,無関心な現場では「やりたくない言い訳(時間がない,など)が得意」なので,最初は改善対象範囲を半ば強引でも定めるケースがほとんどです。したがって,一般にはどの部門とか,どこからどこまでを改善対象にするかを決めてから,着手することになります。前後工程,すなわち,「⁠前工程である上流」「⁠後工程である下流」があって,はじめて自部門の業務の一連の流れが成り立っていることを忘れてはいけません。改善対象範囲を決める業務改善の対象を定めます。対象選定には,いくつかのパターンが見られますが,代表的なものは,以下の2つです。部門のくくりで決める最も多いパターンです。業務改善の対象として,部門単位で行う場合は,すでに何らかの問題意識があり,目的もある程度わかっている場合がほとんどです。したがって,まずは自部門だけでやってみようという場合には,部門単位を改善対象範囲として定めます。一連の業務プロセスで決める部門を定めず,それなりのリソースの投入を行い,部門全体や全社的に明確に目的を持って実施する場合です。,「⁠CS(顧客満足)を高める施策のひとつとして,お客様への製品納期を今までの半分にする」などです。この場合は,営業部門のお客さまからの製品引合いの段階から,最終的に出荷をする物流部門までの一連の業務をくまなく見て,どの部門の,どの業務プロセスで時間がかかっているかを見極めなくてはなりません。業務は1部門で完結しないので,部門をまたがって後工程まで一気通貫で行うことになります。業務を特定して業務改善の対象とするので,比較的大きな活動になります。最初はスモールスタートがいい!先ほど,先に業務改善の対象を設定してしまうと,そこだけしかやらなくなる場合があると書きましたが,逆に言うと,条件が揃えばうまく進めることは十分可能です。本格的に業務改善に取り組む,過去に失敗したことがあり,二度目の失敗は許されないという会社は,通常は慎重になるので,まずはスモールスタートで行いたがります。部門単位で行う場合も,比較的,最初は小さなスタートとなります。無関心に加えて非協力的になりがちなので,最初から大きな風呂敷を広げて着手するよりも,「やればできるんだ!」という小さな成功体験を積むプロセスが必要になります。小さく開始した部門を,モデルケース(モデル部門)として,前工程や後工程への水平展開をはかることができます。対象部門は後から増減すればいい気をつけたいことは,対象を設定することはそれほど重要なことではないということです。最初に設定をした対象範囲内に,問題を生じてさせている原因が存在しない場合もあります。対象としている部門や業務以外に,関連する部門や業務に原因があった場合,放置しておいても解決はしないので,原因を見出した段階で「対象範囲を変えること=他部門への働きかけと巻き込み」が必要となります。したがって,ここで先に対象を設定するのは,改善活動初期の中心となる業務の対象部門であり,改善が進み原因が見えてきた段階で,対象部門を広げていきます。ゴール著者プロフィール世古雅人(せこまさひと)メーカにて開発エンジニアと半導体基礎研究(国の研究機関出向)の計13年を設計と研究開発の現場で過ごす。企業風土改革,組織・業務コンサルティング会社や上場企業の経営企画責任者などを経て,技術の現場あがりの経験や知識を活かした業務改善やコンサルティングなどに従事。経営を巻き込んだ「プロセス共有型」のコンサルティングスタイルを推し進めている。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。その他の連載CSS3アニメーションでつくるインターフェイス表現CSS3によるアニメーション表現を紹介していきます。その中でも,幅広い読者に応用してもらえるだろうインターフェイスを主なお題とします。MySQL道普請便り本連載では,MySQLを使ったアプリ開発・運用に関するノウハウをご紹介していきます。RecipeUbuntuの強力なデスクトップ機能を活用するための,いろいろなレシピをお届けします。JavaScriptセキュリティの基礎知識JavaScriptに関するセキュリティ上の問題はどこで発生し,どうすれば防ぐことができるのか?について解説していきます。〜システムをきちんと運用するための基礎知識システムは「作って終わり」ではなく,運用の中でさまざまな問題が発生します。問題の発生に備えて事前にどのような対応をしておくべきなのか,問題発生時に何をしなければならないのか,ポイントを解説していきます。きたみりゅうじの聞かせて珍プレーソフトウェア開発の現場で体験したトホホな失敗,思わずうなる珍プレーをきたみりゅうじ氏が四コママンガで紹介。Linuxのメンテナンスの傍ら,Linuxやオープンソースソフトと日々を過ごす著者が,その魅力とつきあい方を,エッセイ風味でお届けします。PRESS特別編集部員,さわやか笑顔のスーパーハカーはまちちゃんとネット大好き14歳わかばちゃんが,毎号,読者の皆さんから寄せられたおたよりを紹介します。皆さんの日頃の悩みにも答えちゃいますよ。]メールでのお知らせメールで次の案内をお送りしております。メールの配信を希望する方は,利用したい項目をチェックしてメールアドレスを入力し,[登録]ボタンをクリックしてください。UPDATES[ほぼ週間に1回]新刊メールマガジン[ほぼ週間に1回]電脳会議の各号案内[ほぼ1ヵ月半に1回]※変更する場合や停止する場合は,登録情報変更ページをご覧ください。※登録いただいたメールアドレスには,そのお知らせ以外,配信いたしません。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。