仕事の基本ルール
あなたがもし、何かのプロジェクトのリーダーをやっていたり、組織を率いる管理職なのであれば、この本は絶対に読んでおいて欲しい本です。
私は、この本の目次をマインドマップに書き出して、時々見返しています。
管理職やリーダーに要求されることは、すごく簡単に言ってしまえば、
組織力を使って会社に直接貢献できる成果を出すこと
です。そして、
組織を改革して、常に効率を改善し続けること
です。
本書は、社内の結構大きな業務改革をするときに、必要なことが過不足なくリストアップされていますので、小さな改革プロジェクトでは、いらないものはあるかもしれませんが、少なくとも必要な物が抜けていることはないと思います。
「改善」ではなく「改革」。
もし管理職やリーダとして、会社から認められる活躍がしたければ、このルールを活用できるまでに頭に叩き込み、経験を積んでおきましょう。
ちょっと引用や要約部(ネタバレ)が長くなってしまいましたので、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割のプロが教える全ノウハウ
◆楽天
 業務改革の教科書 |
◆その他Webリンク
書評業務改革の教科書―成功率9割のプロが教える全ノウハウhttp://blogs.itmedia.co.jp/kataoka/2014/01/9-db45.html
■参考図書 『業務改革の教科書』
業務改革プロジェクト成功率9割のノウハウを、惜しみなく公開企業変革・業務改革について書かれた良書はいくつかあるのだが、ほとんどが翻訳書である。
そのため、実際に日本企業で業務改革を進めるうえで最も悩ましいこと、例えば
・いかにトップに味方になってもらうか
・業務調査は何をどこまで調べればいいのか
・抵抗勢力とどう対峙するか
といった、実務家が実際に悩むことについて、きちんと応えていない。
本書は、日本企業のなかで業務改革を起こしたいと思っている、「普通の人」のための教科書である。
実名での企業事例、当事者の声、実際に現場で使った資料をふんだんに盛り込み、ビジュアルに解説した。
★著者 榊巻より
通常、コンサルティング会社はプロジェクトで使う方法論や、ツールを公開しません。
なぜなら、それこそが「メシのタネ」だからです。しかし僕らは、
・すべてをオープンにして、一丸となってプロジェクトを進めなければ上手くいかない。
・僕らの手の内がバレても、世の中から不幸なプロジェクトが減るなら、それでいいじゃないか!
と、わりと本気で思っていて、立ち上げノウハウを文章化することに決めました。
実は、書き始めてから原稿が出来上がるまで、丸々2年半もかかりました……。明文化されていない、暗黙的なコツもたくさんあり、まとめるのに非常に苦労しましたが、その分、実践的な良い教科書になったと思っています。
★著者 白川より
プロジェクト計画は、実行されなければゴミである。
その昔、全社を変革する大きなプロジェクト計画作りに参画したことがある。
その時作られたのは、一言で言えば、「文書ファイル7冊ほどの燃えるゴミ」だった。
「計画書としての質」は高かったのだが、計画が実行に移されることはなかった。いかに書類としてよく書けていたとしても、実行に移されなければ、その会社にとっての価値はない。
僕にとって、この仕事はショッキングだった。あれほどの頭脳と熱意をつぎ込んで成し遂げた仕事が、結局なんの役にも立たなかった。
それ以来、「きちんと実行に移され、プロジェクトを成功に導くプロジェクト計画の作り方」「どう立ち上げれば、プロジェクトは成功するのか」を考えるのはライフワークとなった。この本では、このことについて今のところ僕たちが知っていることを全て書き出した。
皆さんにとって、この本が良き道しるべになりますように。
| ◆アマゾンで見る◆ | ◆楽天で見る◆ | ◆DMMで見る◆ |
 業務改革の教科書 著者 ：白川克 | 業務改革の教科書 検索 ：最安値検索 | 業務改革の教科書 検索 ：商品検索する |
●本書を引用した記事
ファンクショナリティマトリクス
業務改革の教科書3
業務改革の教科書2
業務改革の教科書1
名言コレクション
あなたの特技は何ですか？
できない人はできない
業務改革の王道
業務改革の教科書
●このテーマの関連図書
最強の業務改革―利益と競争力を確保し続ける統合的改革モデル(-)
反常識の業務改革ドキュメントプロジェクトファシリテーション〈増補新装版〉
(はじめの1冊!)オフィスの業務改善がすぐできる本
会社のITはエンジニアに任せるな!―――成功率95.6%のコンサルタントがIT嫌いの社長に教えていること
ビジネスプロセスの教科書
7つの要素で整理する業務プロセス(forMutualInterestSERIES)
