事業会社におけるXOps(改善者)からBizOps(改革者)へ~改革計画編1~
前回の記事では、改革をしていくための情報収集の方法と考え方をお伝えしました。
(情報収集や考え方についてはいろんな形があるので、網羅的ではないですが・・)
今回の記事では、いよいよ改革を計画!
自身の中にある改善案を「構想計画」としてまとめていく過程にフォーカスしていきます。
プロジェクト構想計画を書いてみよう
プロジェクト構想計画となると「う・・」と思わず息が詰まる方もたくさんいると思います。
緻密さが要求され、書いても他の人から指摘が入り全然進まない・・
なんて経験をされて方もいらっしゃるでしょう。
そうはいっても、何かしらのたたき台がないと前には進みません。
たたき台があるからこそ仕事で主導権が取れる!
そして主導権が取れると仕事が面白くなるのです。
プロジェクト構想計画の目次例
プロジェクト構想計画の目次は下記のようなものが一般的です。
タイトル(およびエグゼクティブサマリー)
プロジェクト構想計画発足の背景
課題と原因、解決策
プロジェクト構想の目的と目標
想定アウトプット
プロジェクトの範囲
プロジェクト体制案
コミュニケーション計画
マイルストーンとスケジュール
リソース計画及びコスト
順に追ってみてみましょう。
1.タイトル(およびエグゼクティブサマリー)
タイトルは重要です。
何しろ一番目にする機会の多いものです。
一般的なタイトルをつけても問題はないですが、一発で覚えてほしい場合キャッチコピーをつけるとベストです。
私や関わるチームメンバーはプロジェクトの中身をよく理解し仕事を進めていきますが、ステークホルダーの人達はMTGやたまにしかプロジェクトに関わりません。なので簡単で簡潔な名前を付けるのがベスト。
といってもこのあたりはセンスも出るところで、私はこの手のキャッチーなフレーズやネーミングを考えるのがつけるのが苦手なんですけどね・・・
過去実際に行ったプロジェクトでは、一緒に取り組んだ同僚が
「このプロジェクトの名前は≪フォースの覚醒≫だな」
と命名。
誰もが知るスターウォーズが連想できて、程よく短く呼びやすく、ちょっぴりかっこよさもある。
このネーミングが大成功。
上層部もプロジェクトメンバーも、プロジェクトを「フォースの覚醒」と呼び、コミュニケーションコストがぐっと下がりました。
なんてメリットっぽい話をしましたが、名前を付けてプロジェクトを遂行することの一番の良さは、とにかくやっていて楽しいことです(笑)
「フォースの覚醒定例やるよー」
「最近フォースの覚醒どうよー?」
「フォース覚醒したー?」
なんて飛び交う職場、結構楽しいと思いませんか?(笑)
と少々話が横道に逸れましたが…
エグゼクティブサマリーは「忙しい人がいたらこの1ページだけは読んでね」というプロジェクトの要約。
会議体に持ち込んでちゃんと通すなら必要ないかも。
ここにあんまり気合を入れたところで、結局口頭で説明をしてほしい人たちも多いのも事実。「俺は聞いてない!」みたいなことが発生しても面倒ですし(笑)
なので、必要に応じて作成しておくという程度の重要性かなと。
2.プロジェクト構想計画発足の背景
タイトルとサマリーがまとまったら、今回のプロジェクトを発足するに至った背景を書いていきます。
ここからがプロジェクトの内容になります。これまで地道にやってきた改善活動の内容が生かされるときがやってきました。
まず、これまで対処してきた課題をざっと並べてみて分類します。書き出してない場合メールやチャットツールをさかのぼってみて雑でもいいので書き出してみましょう。
おそらく、ここまでに対処してきた課題は現場に寄り添った課題。
そのままでは、部署横断的な「改革」の材料とするには抽象度が低いはずです。
ですから、分類した課題を部署横断的な、抽象的な課題に変換します。
この時ヒントになるのが、改革の材料集めの一環でヒアリングしたベンチマーク先の一次情報。
ベンチマーク先の情報を聞いて、「こんな形にしたいなぁ」とぼんやり思い描いておいた理想形から、抽象的な課題の切り口を探ります。
プロジェクト発足背景の例
「業務改善を実施してきたなかでMrk/IS/Sales/CS/経理の方々と話をして、細かい課題をXXX個解決してきました。
その内容を見ると大きく3つの課題が存在することがわかった。
【テーマ:顧客第一主義への回帰】
自分たちの業務で手いっぱいで、顧客を向いて仕事する時間が少ない
他の部署への受け渡しが乱雑で責任を押し付けあう構造となっている
各部署が好きなツールを使っているのでデータが分断されており、二重入力やプロセス横断型の数値をまとめるのに非常に苦労がかかっていることから、顧客のインサイトを探る時間が無くなっている
上記の課題を解決するため、プロジェクトを起案する」
こんな形でまとめられていると、聞き手の納得感が増します。
3.課題と原因、解決策
ここまで整理してきた課題の概要を、今度は原因・解決策を添えて掘り下げていきます。
最低限ロジックである程度つながっていれば、相手方が理解しやすくなり、説明もスムーズに進みます。
抽象的な課題を定義し、ロジックツリーのようにあらわすとわかりやすくはなりますが・・・世の中そんなにきれいに言葉として表せない。
コンサルみたいにMECEで完全なロジックで!とまで張り切る必要はありません。
思考の道筋が相手に見えるように、ある程度線で繋いで提示することを心がけてみてください。
ここで丁寧に思考の道筋が見えるように整理しておくことは、何よりも自分にとっての心強い道しるべになってくれます。
いざ改革を行うことが承認され、解決策を実行する中で、「この方法でいいんだっけ?」と迷った経験のある方も多いのではないでしょうか。
ここで整理した課題・原因・解決策のロジックは、この迷いに対する道しるべになります。
丁寧に整理しておくことで「あ・・この方法だと課題があんまり解決されないのでは?」という軌道修正もしやすくなります。
課題と原因、解決策の整理方法
アウトプットのイメージとして、私が過去実際に作ったものを・・・
とお見せしたかったのですが、あまりにも生々しい内容だったので、イメージでお伝えします(笑)
実際の課題から真因を結び付け、施策(解決策)に落とし込んでいきます。
BizOpsを題材としてはないですが、著者本人が具体例もツイートされていましたのでぜひ参考にしてみてください。
と、丁寧に理論的に整理してくださっているものの、実際にやってみると・・・
言葉で定義して、課題や真因を記載するが難しいこと難しいこと・・・これこそまさに「言うが易し 行うが難し」。正直簡単にできることではない。
一朝一夕でできることではありません。訓練あるのみ。だって改革なんですもの・・
コンサル時代から考えれば20年近くやっていることのはずですが、いまだに私も頭を抱えてうんうん唸ります。
自分だけで書くのは時間的にもスキル的にも限界があります。社内の方や社外(アドバイザーなど)との壁打ちを繰り返し、ブラッシュアップすることをお勧めします。人が作ったものをチェックするのは第三者の方が向いていることも多々あるのです。
上記のように課題(What)と原因(Why)、解決策(How)を結び付け、解決策を実施するプロジェクトを起案していきます。
改革計画編2につづく
プロジェクト計画を作るための材料が揃い、プロジェクトの発足背景や、解決すべき課題を言葉で定義できるところまで来ました。
次回は続きとして「事業会社におけるXOps(改善者)からBizOps(改革者)へ~改革計画編2~」。
どのようにAsIsとToBeを表現していくのか、書いていこうと思います。
「BizOps戦略室」では引き続きBizOps全体にまつわる内容をお送りします!
皆さんからの反響を励みに、是非とも記事やマガジンに「スキ!」「コメント」そしてTwitterの「いいね!」、「フォロー」をお願いします!
いいよ!興味あるよ!と言う方や企業の方がいらっしゃっいましたら、TwitterでDMを頂けると幸いです!Twitterはこちら。
BizOpsコミュニティを立ち上げたよ!
BizOpsコミュニティを立ち上げました!
できたばかりおよび超ニッチなところですが、その分熱量高く進めていきます!
現在20名以上の方々にコミュニティに入っていただきました!
まだまだ至らない点は多いのですが、ともに作っていければと思います!
BizOpsって経営的に必要なの?
BizOps業務をしているが、社内で同じ目線で会話できる人がない
BizOps業務に関心があるけど、どうしたらいいかわからない
といった思いをお持ちの方々、noteのコメントでもTwitterでのDMでも構いませんのでご連絡を頂ければ招待URLをお送りします!ぜひご参加ください。
新たな試みー記事への応援のお願いー
さて、記事の内容としては以上となります。
もしこの内容が皆さんの役に立っていたらちょっとだけ応援していただけないかと思い、有料機能をつけてみました。
有料部分を購入いただいても、なにか追加の情報が書いてあるわけではなくお礼だけが書いてあります。
ですので、購入いただいてもいただかなくてもお読みいただける内容には変わりはありません。
もし、記事が気に入っていただけたらちょっぴり応援購入していただけたら嬉しいな、と思っての新しい取り組みです。
もちろん「スキ!」「コメント」での応援もとても嬉しく、大歓迎ですので、新たな試みとおもって見守ってください!
ここから先は
¥ 300
この記事が気に入ったらチップで応援してみませんか?