「改善」ではなく「改革」。

もし管理職やリーダとして、会社から認められる活躍がしたければ、このルールを活用できるまでに頭に叩き込み、経験を積んでおきましょう。

ちょっと引用や要約部(ネタバレ)が長くなってしまいましたので、3回に分けてお送りします。
本日は第3回目。私が気になったキーポイントを紹介します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■キーポイント

★P41〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
「既に達成したかのごとく、プロジェクトゴールを語り合え」
名言だと思う。
変革プロジェクトは、様々な立場の人が集まった寄り合い所帯である。
本来ならバラバラなメンバーが、一つのゴールを目指さなければならない。そのためにはまず、「これから登る山＝変革のゴール」がハッキリ示されていて、常に互いに語り合い、明日やるべきことをゴールから逆算して考えなければならない。
それが「既に達成したかのごとく、プロジェクトゴールを語り合え］ という言葉の意味である。
――――――――――――――――――――――――――――★

★P45〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
ゴールを何人か集まって考える時、「あれもこれも大事だから、あれもこれも達成しよう」になってしまうことが多い。または、あれもこれもを内包した、ぽんやりとしたゴールを１つだけ決めてしまう場合もある。
これでは、何かを決めたことにはならない。やることとやらないことが明示的に書かれていなければ、後々の意思決定の場面で頼りにならない。
「やらない」とすることが難しいならば、日野自動車の例のように「後でやる」とするのでも良い。このプロジェクトではお墓の土台である業務とシステムの基盤整備を最初の1年でしっかりとやり遂げ、次の1 年で墓石の部分に取り組んで、最終的には両方を成し遂げた。でも、「一度になんでもやる」という暖味な状態だったら、いまだにどちらも成し遂げられていないかもしれない。プロジェクトが迷走し、貴重な資源も分散してしまうからだ。

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

★P46〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
プロジェクトゴールは床の間に飾っておくものではない。プロジェクトでの意思決定に使っていくツールである。だからこそ、ツールとして不十分だと気づいた時には、再度議論し直す勇気が必要になる。
変革プロジェクトを立ち上げた時に議論して決めたプロジェクトゴールに対して不十分さを感じるということは、それだけプロジェクトが進展し、共体的な検討までたどり着いたことを意味する。見直すことに対して、必ずしもネガティブになる必要はないのだ。

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

★P49〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
コンセプトがないゴールは、ただの「目指すべきアドバルーン」になりがちだ。「売上10%を目指せ」「今より40%効率化せよ」というのは確かにゴールで張るのだが、それだけでは人はついてこない。「なぜそれをすると、ゴールに到達できるのか？」「どういう勝算があるのか」を示さないと、ゴールなんて過去声だけだと思われる(大抵の場合、本当に掛け声だけだったりする)。ゴールを目指そうにも明日から何をしたら良いのかもわからない。

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

★P60〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
合宿の利点は、立ち上げたばかりのプロジェクトチームが、即座にいいチームになれることだが、それ以外にもある。「具体的過ぎる話、詳細過ぎる話がやりにくい」ことだ。普段の会議とは違って、設備も時問も制限があるから、パワーポイントのきれいな資料を用意しまくるというよりは、フリップチャート（模造紙）や付箋を使って、その場で議論を発展させていかざるを得ない。それがいい。

事前に資料が用意されていると、どうしてもだれかが作ってきた資料を、上から目線でレビューするという雰囲気になりがちだ。でも資料が最初からなければ、自分たちで手を動かしてアイディアをひねり出すしかない。普段のオフィスで同じことをやろうとすると、「もっとちゃんと資料を用意しろ」となりそうなものだが、合宿だったら「まあ、合宿ですから。まずは議論しましょう」となる。

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

★P56〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
●変革にとってのF制約」を聞き出せ
「方針を示してください」という質問よりも「○○は、会社としてアリですか？」という質問の方が、ずっと効果的である。つまり、プロジェクトとして守らなければいけない制約事項を聞くのだ。
逆説的なのだが、制約をしっかり聞いておくと変革のプランを練る時に、大きな自由を手に入れられる。制約の枠の中に収まってさえいれば、多少突飛な発想でも、許されるはずだからだ。

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

★P89〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
●4大調査フォーマット
　・一覧表
　・アクティビティ一覧
　・業務フロー(スイムレーンチャート)
　・ファンクショナリティ・マトリクス

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

ここはちょっと用語について調べたので、記載しておきます。

・スイムレーンチャート
　http://ja.q-bpm.org/mediawiki/index.php/%E3%82%B9%E3%82%A4%E3%83%A0%E3%83%AC%E3%83%BC%E3%83%B3
　★――――――――――――――――――――――――――
　ビジネスの世界では、複数のパーティシパント（人、部門、情報システム）が複雑に絡み合ってビジネスプロセスを進行させていく。このようなビジネスプロセスを表す時に、誰がアクティビティを処理するのか直感的に理解できるように、パーティシパントごとにアクティビティを分割し整理するために使われるのが、スイムレーンである。パーティシパントにスイムレーンが割り当てられ、スイムレーンの内部に配置しているアクティビティが、そのパーティシパントが担当するアクティビティである。スイムレーンは、BPMN基本要素（BPMN Core Elements）の1つに数えられる。

　スイムレーンを用いて表されたプロセスは「プライベートプロセス（Private Process）」と呼ばれ、ビジネスプロセス全体はこのプライベートプロセスの集合体であると考えられる。BPMNを用いた図が複数のプライベートプロセスを表示するとき、プライベートプロセス間または関係者間のやり取りを表示することができることが、スイムレーン使用の最大のメリットである。

　BPMNでは、スイムレーンにあたる要素は
　　プール
　　レーン
　の2つがある。

　各関係者は「プール」で表され、すべての業務フロー図には、1つ以上のプールが含まれる。図に含まれるプールが1つだけの場合、通常、プールは描かれない。複数のプールが含まれる場合、表記が必須となる。

　プールをさらに役割や業務によって分割したものが、「レーン」と呼ばれるサブスイムレーンである。
　――――――――――――――――――――――――――★

・ファンクショナリティ・マトリクス
　http://itpro.nikkeibp.co.jp/article/COLUMN/20091029/339748/?ST=system&P=3
　★――――――――――――――――――――――――――
　表のセル1つひとつがシステム機能です。同じグループの機能が横に並んでいます。例えば、「注文管理」のグループには、「受注情報取り込み」「受注情報登録」といった機能が並びます。

　各セルの下段には「H/M/M」と記されています。これは、各機能の優先度合いを三つの観点から示したものです。三つの観点とは、左から「ビジネスベネフィット」「技術的難易度」「組織受入態勢」です。

　（1）ビジネスベネフィット（Business Benefit＝BB）：その機能の実現によるビジネス面での効果の大きさを評価する軸。プロジェクトゴールやCSF（「第11回と第12回「プロジェクトゴール & CSF（主要成功要因）」）への貢献度合いや、その機能による効果（コスト削減量、売り上げへの貢献度合い、顧客満足）などから評価します。当然、BBが高いほど優先度は高くなります。
　
　（2）技術的難易度（Technical Complexly＝TC）：その機能を実現する技術的難易度を評価する軸。難易度が高いほど工数がかかるため、工数（＝コスト）を評価する軸という見方もできます。例えば、導入実績がない新規性の高い技術が必要な機能は、予期せぬ障害などの発生リスクも高いためTCは高くなります。
　
　（3）組織受入態勢（Organization Readiness＝OR）：その機能が実現した場合に、利用者や運用者にとっての受入の容易さを評価する軸。例えば、高度な教育を伴わないと使いこなせないような機能のORは低いと言いえます。また、その機能を実現する場合に、運用負荷が高まるケースもORは低いと評価できます。

　FMでは、これら三つの観点で評価した個々の機能の優先度から、議論された結果としてのシステム構築全体をフェーズ分けします。セルの色でフェーズ、すなわち構築の順番を示しています。白抜きのセルが最も優先的に構築すべきシステム機能です。また、各セル（システム機能）について、機能詳細を別の文章としてまとめます（図4）。

　http://itpro.nikkeibp.co.jp/article/COLUMN/20091029/339764/
　前回説明したとおり、システム機能の優先順位付けにおける評価の観点は次の三つです。

　　・ビジネスベネフィット（BB：Business Benefit）
　　・技術的難易度（TC：Technical Complexly）
　　・組織受入態勢（OR：Organization Readiness）

　これらの三つの観点について、High、Medium、Lowの3段階で評価基準を定義し、評価付け（レイティング）を行います。ここでのポイントは、この評価基準の定義とレイティングの作業を、経営層、業務部門、情報システム部門の三者を巻き込んでコンセンサスを得ながら進めることです。

　図1は、評価基準の定義とレイティングを誰が行うかを示した一例です。この例では、業務部門はビジネスベネフィットと組織受入態勢の評価を担当し、技術的難易度は情報システム部門のみが評価します。

　そして、関係者の納得感が得られるような役割分担をあらかじめ設定し、評価基準の定義とレイティングを行う会議（セッション）を開催します（図2）。

　評価基準は一度決めたら終りではなく、レイティング後の全体のバランスを見て適宜、見直すことも必要になります。極端な例ですが、すべての機能のビジネスベネフィットが「High」と評価された場合は、基準の定義が適切でない可能性があります。レイティングを進める過程で適宜、評価基準を見直しつつ進めるのがよいでしょう。

　特にビジネスベネフィットは、プロジェクトのゴールと直結するものが「High」になるべきです。単純な効果の大きさだけで基準を設けるのではなく、プロジェクトのゴールに照らし合わせ、メリハリのある基準を設定することが、この後の絞込みで威力を発揮し、短期間でのシステム構築を実現させます。

　例えば、図2の評価基準の例では、「業務負荷を大きく削減する」は「Medium」、「CS向上に大きく貢献する」は「High」と設定しています。これは、このプロジェクトのゴールに「CS向上」を第一に掲げているためです。例え業務負荷の削減に大きく貢献したとしても、このプロジェクトにおける優先度としては「CS向上」が優先される訳です。


　一通りの機能にレイティングが完了したら、いよいよフェーズ分けの作業になります。基本的な優先度の考え方としては、ビジネスベネフィットが高く、技術的難易度が低く、組織受入態勢が高い機能が、すぐに取り組むべき最優先の機能になります。

　進め方は次のようになります。（1）機械的にフェーズ１の条件を定める、（2）その条件で機能のフェーズ分けを行い、大枠で問題ないかを確認する、（3）最終的な範囲を決めるために、各機能の依存関係など考慮して調整する、（4）やらない領域への対処方法を決定し、フェーズ分けを決定する（図3）。

　もう少し詳細に説明します。

　　（1）機械的にフェーズ1の条件を定める
　　　図3は、三つの評価軸を立体に並べたものです。原点から離れている機能が優先度の高い機能となり、原点に近い機能は優先度の低い機能を示します。
　　
　　　この例では、ビジネスベネフィットが「High」かつ組織受入態勢が「Medium」以上の機能をフェーズ1と定めました。また、ビジネスベネフィットが「Low」かつ組織受入態勢が「Medium」以下の機能をフェーズ3と定めています。技術的難易度が「High」の場合は、組織受入態勢が「High」であってもフェーズ3と定めました。そして、残りの機能をフェーズ2と定めました。
　　
　　（2）定めた条件で機能のフェーズ分けを行う
　　　各フェーズの条件を機械的に定めたら、この条件を満たすFMの機能を色分けしてみます。フェーズ分けの結果を見て、大枠な開発範囲について、予算などの制約を満たしそうか、各フェーズの範囲として適切かを評価します。明らかに予算オーバーしそうな場合や、機能不足の場合には、各フェーズの条件をさらに見直して再度色分けをします。
　　
　　　短期間でシステムを構築し、成果を早期に実現するためには、効果の高い機能にいかに絞り込めるかがカギとなります。この時点で、段階的なシステムリリースのシナリオを思い描き、フェーズ分けを見極めてください。
　　
　　（3）最終的な範囲を決めるために、各機能の依存関係など考慮して調整する
　　　大枠で問題ない範囲に分けることができたら、個々の機能について、機能間の依存関係や、システム運用上フェーズ1から備えなければならない必須機能などの漏れがないかを評価し、最終的なフェーズ分けの範囲を決定します。
　　
　　（4）やらない領域への対処方法を決定し、フェーズ分けを決定する
　　　フェーズ分けの結果、システム構築の対象外となった機能については、システム化しないことになります。そのため、当面の運用方法を明確にする必要があります。その業務そのものを実施しないのか、システム機能はなくともマニュアルなどで業務を実施するのか、業務面の方針を明確にします。

　これらの手順で作成したFMおよびフェーズ分けの結果は、経営者、業務部門、情報システム部門それぞれの意思としてのレイティング結果が反映されており、コンセンサスを集約した結果といえます。フェーズ分けの内容についても関係者の合意形成を取ることで、後々ぶれることのないプロジェクト運営につなげられます。
　――――――――――――――――――――――――――★

★P109〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
●また後で聞きにいける関係を作る
ヒアリングは一度で終わらない。聞きそびれたところ、さらに検討を追加したもの、新たな事実が明らかになったところ、投資対効果を算出するための基礎数値集めなど、後から追加で聞くことは山のようにある。
その時、現場の方と信頼関係ができていないと、時聞を割いてもらえなくなる。ヒアリングは、現場との関係作りの場であると考えるべきだ。極端なことを言えば、現場との関係が壊れるくらいなら、ヒアリングの目的が達成できなくてもいい。後から追加で聞けるのだから。

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

★P159〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
●もれなく施策を出したかチェックする方法
たまにしか参加しないメンバーや関係部署の社員はいつまでたっても「施策出しきれいている気がしないな」「施策受けているか不安」と感じてしまう。そういった方にも納得してもらい、変革プロジェクトに協力してもらう必要がある。そういう時には「施策―課題マッピング法」を作る。
縦軸に Assessment フエーズで分析した課題、横軸には考え出した施策を並べ、対応関係が一目で分かるようにしてある。こうすることで、全ての施策をやれば課題が全部解決できることや、それが無理な場合はどの施策から手をつければよいのかを議論できる。この例だと、 「シンクライアント化」と「メール送受信の制御」の 2 つの施策を実施すれば、全ての課題がカバーできる。予算には限りがあるのだから、当然この 2 つから実行することになる。

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

★P161〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
●業務改革の王道6選
　1. 標準化
　2. 一元管理
　3. 業務集約
　4. アウトソースノオフショア
　5. 承認ブ口セスの見直し
　4 納期短縮

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

★P229〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
●リスクを把握し、対応する4ステップ
1.プロジ工クト逐行上のリスク
　プロジェクトをやり切るために必要な人材が、途中で引っこ抜かれてしまうのではないか？
　反対者が多くて現状のルールを変えられないのではないか？
　システムが期限までに完成しないのではないか？
このような、プロジェクトをやり切ること自体への懸念は挙げていけはキリがない。だが、計画を立てる段階で考慮しておけば、対処できるリスクも多い。起きてしまってから慌てるのではなく、今だからこそきちんとリストアップしておこう。
2.施策実現上のリスク
次に、プロジェクト全体というよりは特定の施策のレべルでもリスクを考えてみる。よりイメージしやすいため、具体的なリスクが挙がる。

白川克(著) 『業務改革の教科書』
――――――――――――――――――――――――――――★

━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■参照先

――――――――――

◆アマゾン

業務改革の教科書―成功率9割のプロが教える全ノウハウ

◆楽天

業務改革の教科書 著者：白川克 価格：2,730円（税5%込、送料込） 楽天ブックスで詳細を見る

◆その他Webリンク

　書評業務改革の教科書―成功率9割のプロが教える全ノウハウ
　http://blogs.itmedia.co.jp/kataoka/2014/01/9-db45.html

■参考図書　『業務改革の教科書』

業務改革プロジェクト成功率9割のノウハウを、惜しみなく公開 企業変革・業務改革について書かれた良書はいくつかあるのだが、ほとんどが翻訳書である。 そのため、実際に日本企業で業務改革を進めるうえで最も悩ましいこと、例えば 　いかにトップに味方になってもらうか 　業務調査は何をどこまで調べればいいのか 　抵抗勢力とどう対峙するか といった、実務家が実際に悩むことについて、きちんと応えていない。 本書は、日本企業のなかで業務改革を起こしたいと思っている、「普通の人」のための教科書である。 実名での企業事例、当事者の声、実際に現場で使った資料をふんだんに盛り込み、ビジュアルに解説した。

◆アマゾンで見る◆	◆楽天で見る◆	◆DMMで見る◆
業務改革の教科書 著者　：白川克	業務改革の教科書 検索　：最安値検索	業務改革の教科書 検索　：商品検索する

●本書を引用した記事
　論理的に話す技術
　トラブルを上司に報告する前にするべきこと
　決断までの時間
　業務改革の教科書2
　あなたが座っていた椅子を見なさい
　生徒になるな、先生になれ
　課長・部長になりたかったら建設業か情報産業にいく？
　やる気がでないのであれば、「今日は休養で退社します」で良い
　スケジュールで決済のためのバッファを設ける
　気持ちだけ論理的5段階評価

●このテーマの関連図書

最強の業務改革―利益と競争力を確保し続ける統合的改革モデル(-)	(はじめの1冊!)オフィスの業務改善がすぐできる本	反常識の業務改革ドキュメントプロジェクトファシリテーション〈増補新…
6ステップで職場が変わる!業務改善ハンドブック	会社のITはエンジニアに任せるな!―――成功率95.6%のコンサルタント…	ビジネスプロセスの教科書

■関連する記事

●論理的に話す技術

本日は久しぶりに、管理人が良書だと思った本の要約。これ、書くのが結構時間がかかって手間なんだよね…『出口汪の論理的に話す技術』本書は、相手に納得してもらえる話の仕方を書いた本。よくある論理技術の話ではなく、「どのようにしたら自分の話を聴いてもらえるのか」という点にフォーカスしています。もちろん、一番の方法は「論理的であること」なのですが、それだけが重要ではありません。相手が何を聞きたいと思っているのかに沿って自分の..

●トラブルを上司に報告する前にするべきこと

よく、「問題が起きたらすぐに上司に報告しなさい」っていうビジネス書やネットの記事を信じて、速攻で報告に来る人がいたり、「自分でなんとかしよう」と頑張り続けている人がいたり、まあいろいろなのですが、どちらも上司からすると期待するものではありません。というか、「報告の仕方がなってない」っていらないところで減点をくらいます。上司の力を利用するトラブル解決の方法何か問題が起きたらとりあえず上司に報告するのがいいのですが、い..

●決断までの時間

リーダの条件として、自分が最も大切だと思っているのは「リーダーシップ」ではなく、「決断」だと思っています。もちろん同格の人たちと何らかのプロジェクトをする上で、自分の思い通りに進めていくためには、リーダーシップは必要です。ただ、リーダたる必要条件ではあっても、充分条件ではないという気がします。以前にも書きましたが、次期リーダとして課長候補の面接をするのですが、・課題認識・課題解決・マネージメント意識・リーダシップといった評価項目があるのですが、これらはある程度..

●業務改革の教科書2

あなたがもし、何かのプロジェクトのリーダーをやっていたり、組織を率いる管理職なのであれば、この本は絶対に読んでおいて欲しい本です。私は、この本の目次をマインドマップに書き出して、時々見返しています。管理職やリーダーに要求されることは、すごく簡単に言ってしまえば、組織力を使って会社に直接貢献できる成果を出すことです。そして、組織を改革して、常に効率を改善し続けることです。本書は、社内の結構大きな業務改革をするときに、必要なことが過不足なくリストアップされていますので..

●あなたが座っていた椅子を見なさい

私は、席をたつ時いつも自分が座っていた椅子を見るようにしてます。もともとは、私がオッチョコチョイで、すぐに忘れ物をすることから始めた習慣でした。最初は意識してやってましたが、最近は自然に視線が元いた場所に行くようになりました。数秒もかかりませんが、得られるものはすごく多いです。席をたつ時あなたが席をたつ時、何を考えてますか？おそらく大部分の人は、席を立った目的、つまりコーヒーを買いに行くとか会議に出るなどの目的があ..

●生徒になるな、先生になれ

なにか新しいことを勉強しようと始めたようとしたとき、どうしますか？まず講習会などに行って教えてもらう関連する本を一生懸命読む過去の経験で、これでうまく行ったことはあまりありません。うまく言ったのは、みんなに教えるということ。かつて会社でCMMIの導入を私用とした時に、自分から提案して、自分がメンバーにレクチャーをしながら導入を進めてきました。勉強のために、メンバーにはCMMIの講習(一人10万円もかかった…)を受けさせたりしたのですが、自分は受けずにメンバーや関..

■同じテーマの記事

●溜まりまくった受信箱を瞬時に空にする方法

仕事にもよりけりですが、私の場合1日に受信するメールの量はだいたい300件±100件くらいが普通です。で、出張やら休暇やらを複数日、1週間もメールをほとんど処理しない日が連続すると、目も当てられない状況になります。そんなときの必殺のメール処理方法があります。一瞬で受信箱のメールをゼロにする方法一瞬で受信箱にたまりまくったメールをゼロにする必殺の方法はメール一覧を出した状態でCTRL+A を押す（すべてのメールが..