-
コンサル基礎スキル / 会議ファシリテーションの実践
みなさんは会議を正しく「ファシリテーション」できていますか？
コンサルタントとしてプロジェクトを推進していくにあたり、クライアントとの会議を適切にファシリテートし、円滑な意思決定を促すことは重要です。
しかし会議のファシリテーションが上手くできないコンサルタントは数多く存在します。
会議のファシリテーションが上手くできないと、
- 目的とする意思決定まで時間がかかる
- プロジェクトが遅延する
- 無駄な工数が発生し疲弊する
- クライアントからの信頼が得られない
といったような弊害が生まれてしまいます。
「会議」はクライアントと直接対峙する「タッチポイント」であるが故に、会議でのプレゼンスはコンサルタントにとって非常に重要です。
本記事ではコンサルタントであれば必ず身につけたい「会議ファシリテーションの実践」を解説します。
プロジェクトを円滑に推進するためにも「会議ファシリテーションスキル」をぜひ磨きましょう。
まずは「会議」の定義について確認していきます。
ここでは「会議」を「様々な⼈が集まり、話し合いながら、何かを決めるもの」と定義します。
例えば、会議の種類には以下のようなものがあります。
- 進捗会議
- 意思決定会議
- ステアリングコミッティ
- ブレスト
- 1 on 1 等
これら多様な会議がある中で、コンサルタントは会議をファシリテーションする機会が多くあると思います。
ファシリテーションする目的はやはり会議を「良い会議」にすることです。
では「良い会議」とはどのようなものなのでしょうか。
筆者の考える「良い会議」とは、以下の特徴を持つ会議だと考えます。
- 化学反応が起こる
- 物事が決まる
- ネクストアクションに繋がる
- 出来れば短時間で終わる
化学反応が起こる
化学反応が起こる会議は「良い会議」です。
化学反応の例は、例えば
- 新しいアイデアが生まれる
- 課題を解決する新たな方策が見つかる
- メンバー同士の結束が強まる
などがあります。
会議という同じ時間を参加者全員が共有する場で、参加者の集合知が発揮されることで新たな発見を得られることを「化学反応」と呼んでいます。
物事が決まる
会議では何かを決めなくてはなりません。
目的のない会議は時間の無駄であり、会議を行い参加者の時間を割く以上、会議では「なにかを決める」ことをゴールとしましょう。
そのために会議のアジェンダを用意し、ゴールに向かって会議をファシリテーションする必要があります。
ネクストアクションに繋がる
仮に達成したかったゴールや決定事項が決まらなかったとしても、「次に誰が何をするか（ネクストアクション）」をしっかり定義しましょう。
なんとなく会議を行い、なんとなく終了。次に誰が何をするんだっけ？という会議は最悪です。
会議のクロージングでは必ず「ネクストアクション」を定義し、参加者間で共有しましょう。
できれば短時間で終わる
会議の時間を1時間確保した際に、1時間きっちり時間を使わなくてはいけない、と思う方も多いと思います。
しかし会議の時間は短ければ短いほど良いのです。
「短い時間で決めることが決める」というのが「良い会議」の特徴です。
予め決められた時間を超過してしまうのはもっての外ですので注意しましょう。
時間を超過してしまいそうになった場合は、参加者の合意を取り延長するかネクストアクションをまとめ次回の会議を調整するようにしましょう。
コンサルタントは会議を「良い会議」にするためにはどうしたら良いのでしょうか。
ここでぜひ覚えてほしいのが以下「会議運営のPDSサイクル」です。
Plan：会議の計画（企画→設計→準備）
「良い会議」にするためには、入念な計画が必要です。
会議の計画は「企画」→「設計」→「準備」の順番で行います。
企画フェーズで検討すべき事項は主に以下３点です。
- 会議の目的は？
- 会議の参加者は？
- 会議の開催手法は？（オンライン / オフライン 等）
これらをしっかり定義した上で、次の設計フェーズでは以下３点を定義します。
- 会議時間は？
- 会議に必要な資料は？
- 会議のアジェンダは？
その後、準備フェーズで以下３点を実施し、会議の準備を完成させます。
- 会議資料の作成 or 作成依頼
- 会議場所の準備
- 参加者の招集とアジェンダの通知
これら会議の計画をしっかりできるか否かでクライアントからの印象は大きく変わりますし、会議で得られる効果も変わります。
面倒くさがらず、慣れないうちは例え短い会議であっても入念な計画を行いましょう。
Do：会議の実施（オープニング→ボディ→クロージング）
会議の実施は「オープニング」→「ボディ」→「クロージング」の３部構成を意識します。
まず「オープニング」では以下を行います。
- 会議の目的を明確にする
- アジェンダを共有し時間配分を認識してもらう
特に重要なのは「会議の目的を明確にする」ことです。
会議の目的はできれば口頭ではなく資料上でテキスト化することで、参加者の理解度が上がり論点がズレにくくなります。
次に「ボディ」で意識したいのは一点だけで、
- 発散と収束を意識したファシリテート
です。
「発散」とは意見を出してもらうことで、より多くの参加者からより多くの意見が出る会議が「良い会議」です。
ファシリテーターは参加者が意見を出しやすい雰囲気作りができるようにしましょう。
コツは「否定をしない」「発言していない人に機会を与える」ことで、一人が一方的に喋っているような会議では、なかなか他の参加者から意見が出にくい場合があります。
一方で会議のファシリテーターは「収束」も意識する必要があります。
「収束」とは、会議の目的に向かって議論を収斂させることであり、様々な意見をまとめたり、論点がズレそうになったら会議の目的に合わせて議論を修正したりします。
この「収束」プロセスは会議時間を意識して行う必要があります。
最後に「クロージング」部分では以下２点を行います。
- 本会議の結論をまとめる
- 次のアクションをまとめる
ボディフェーズで収束させた論点の結論を導くのがこのクロージングフェーズで、このクロージングフェーズで更に意見が分かれたり、新たな議論が生まれてしまう状況は、「会議をファシリテート」出来ていません。
クロージングフェーズに至るまでに、ボディフェーズである程度議論を「収束」できるようにしましょう。
またこのクロージングフェーズでは、「次のアクションを決める」ことが重要です。
会議では予定通り100点満点の結論を出せることは稀で、必ず次のアクションが生まれます。
ポイントは必ず生まれる「次のアクション」を会議のクロージングの場で参加者全員で共通認識を持つことです。
See：会議の評価
一流のファシリテーターになるためには、会議後に「会議の評価」をすることを怠ってはいけません。
会議の評価プロセスでは、「対外的」と「対内的」に分かれて実施します。
まず「対外的」な会議評価とは、具体的には以下を指します。
- 議事録の発行
- タスクの管理
- 次のアクションのドライブ
会議での議事録をまとめ関係者へ展開するとともに、会議の中で発生したタスクの進捗管理も合わせて行う、もしくは行う担当をアサインしましょう。
また会議の中で定義した次のアクションを具体的にどう推進していくかを検討することも必要です。
一方で「対内的」な会議評価は「振り返り」の実施を指し、具体的には以下を行います。
- 自己評価
- 上司からのフィードバック
自身の会議ファシリテーションを振り返り、良かったこと・改善できることを洗い出します。
また同時に上司からの自身の会議ファシリテーションに対するフィードバックをもらうことも重要で、自身では気付いていない癖や改善点に気付く機会になります。
これら振り返り結果を自身のノウハウとして蓄え、次回の会議で実践することで、会議ファシリテーションスキルは格段に向上します。
このように会議は行なって終わりではなく、「準備→実施→評価」のPDSサイクルを回すことが一流のファシリテーターへの最短ルートです。
コンサルタントたるもの、会議のファシリテートは当たり前のようにこなせるようにしたいですね。
本記事では、コンサルタントであれば必ず身につけておきたい基礎スキルの一つである「会議ファシリテーションの実践」を解説させていただきました。
本記事を執筆している KICK ZA ISSUE株式会社では、企業のIT化/DX化のお悩みを解決できる各種コンサルティングサービスを提供しています。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク -
STP分析とは？（実践テンプレート付）
自社の立ち位置を明確にしたり他社との差別化を図ることができ、戦略立案をする際に用いられるマーケティング手法である「STP分析」。
マーケティング戦略を策定する上で非常に重要なフレームワークの1つです。
この分析（S：セグメンテーション・T：ターゲティング・P：ポジショニング）を行うことで、より効果的なマーケティングやプロモーションを実施できる可能性が高まります。
本記事では、STP分析の概要や基礎知識、STP分析を行う際の手順（※テンプレート付き）、注意点などを徹底解説していきますので、ぜひ今後の参考にしてみてください。
STP分析のテンプレートはこちら
STP分析とは、セグメンテーション（Segmentatoin）・ターゲティング（Targeting）・ポジショニング（Positioning）の3つの頭文字をとったフレームワークになります。
自社の立ち位置の明確化や他社との差別化を図ることができ、戦略立案に活用することができます。
STP分析を上手く活用することで、商品やサービスをローンチする前に、顧客ニーズや要望を把握することができ、より顧客や市場に適した商品・サービスを提供できるようになります。
上図にもありますが、もう少し詳細に分かりやすく解説していきますので、より理解を深めていきましょう。
セグメンテーション（Segmentatoin） 市場を細分化することを指す。一般的に次の4つの指標が用いられる。
・地理的セグメンテーション：物理的な場所や地域に基づいて、市場を分割する。都市部・郊外・農村地域など、顧客の生活スタイルに基づいたセグメンテーションができる。
・人口統計的セグメンテーション：人口統計情報（年齢・性別・職業・収入etc）に基づいて、市場を分割する。ライフスタイル・価値観・行動パターンなどを把握できる。
・心理的セグメンテーション：顧客の心理状態・利用目的・購入意欲などに基づいて、市場を分割する。商品やサービスに関する顧客のニーズや好みを把握できる。
・行動的セグメンテーション：購入頻度・購入金額・使用頻度など顧客行動に基づいて、市場を分割する。商品やサービスの利用方法や購入タイミングなどを把握できる。ターゲティング（Targeting） 市場を細分化したのちに、自社が狙いにいくべき市場を決めることを指す。特定のセグメントにフォーカスして、そのセグメントに最適化された商品やサービスを提供していく。より正確なセグメンテーションをすることで、需要や収益性の高い市場に焦点を当てることができる。 ポジショニング（Positioning） ターゲティングした市場の中で、自社の立ち位置を決めることを指す。ターゲット市場のニーズを理解することや競合他社のリサーチをすることで、自社のオリジナル性の確立や他社との差別化をすることができる。そのうえで、価格の設定や自社に適した戦略立案に繋げる。 STP分析の概要を理解したところで、次はSTP分析の役割・目的には、どのようなものがあるのか解説していきます。
- よりニーズに合わせた商品やサービスを提供することができるようになる
- どのような顧客がいるか把握することができる
- 顧客満足度を向上させることができる
- 市場における競合状況を把握でき、他社との差別化ポイントを発見できる
- 各セグメントの需要を把握できるため、より効果的なマーケティングを行うことができる
これらのようにSTP分析は、マーケティング計画を立てるうえで非常に重要な役割を果たしてくれます。
あくまでマーケティングにおけるフレームワークの1つではありますが、「マーケティング戦略の立案」という観点において、必ず役に立つので覚えておいて損は絶対にないでしょう。
それでは実際に、STP分析のやり方・手順を見ていきましょう。
- STP分析を実施する目的とゴールを明確にする
- 市場のセグメンテーションを行う
- 各セグメントのターゲット市場を決める
- ターゲット市場に合わせたポジショニングを行う
- マーケティング戦略の決定・実施・改善を行う
1. STP分析を実施する目的とゴールを明確にする
まずは、「なぜ」STP分析を実施するのか目的を明確にしましょう。
目的が不明瞭のまま分析作業を行ってしまうと、「分析結果の精度が低い」「そもそも見当違いの分析を行ってしまった」など、無駄なリソースを割いてしまう可能性があります。
そのうえで、自社が目指すべきゴールも明確にする必要があります。
目的とゴールを明確にすることで、より効果的・効率的な分析ができますし、後のマーケティング戦略を立案する際にも、より自社に合った意思決定ができるようになります。
また、目的とゴールを明確にするだけでなく、従業員・メンバーにも共有するようにしましょう。
2. 市場のセグメンテーションを行う
それでは実際に分析作業に入っていきます。
まずは、市場のセグメンテーションを行っていきましょう。
顧客を類似した属性やニーズ、行動パターンなどに基づいてグループ分けすることで、ターゲット市場を明確化することができます。
前述したように、地理的・人口統計的・心理的・行動的の4つの指標を用いてセグメンテーションを行うケースが多いです。
例えば、
- 年齢、性別、職業、収入などの属性をもとにグループ分けする
- 顧客が抱える悩みやニーズ、購入に至るまでの行動をもとにグループ分けする
- 地域ごとに異なるニーズや文化を考慮しながらグループ分けする
これらのように、自社の商品やサービスに合わせて市場を細分化し、セグメンテーションを実施していきましょう。
ただし、セグメンテーションはあくまで目安になるので、必ずしも全てを把握できるわけではないので注意が必要です。
3. 各セグメントのターゲット市場を決める
それでは次に、各セグメントにおいて以下のような観点を考慮しながらターゲット市場を決めていきます。
- セグメントの規模と成長性：特定のセグメントが多くの顧客を抱え、成長性が高い場合は、そのセグメントをターゲティングする。
- 特徴やニーズに合った商品やサービスの提供：セグメントごとに異なる特徴やニーズを把握し、それに合った商品やサービスを提供する。
- 競合他社の分析：自社の差別化ポイントや競合優位性を明確にする。
- ターゲット市場の適合性：セグメントの特徴やニーズに合わない市場をターゲティングすると、マーケティング活動の精度が落ちる可能性がある。
上記のように、セグメントごとに異なる観点を考慮しながらターゲット市場を決定することで、より効果的なマーケティング活動を行うことができます。
4. ターゲット市場に合わせたポジショニングを行う
ターゲット市場を決定した次は、それに合わせたポジショニング（自社の立ち位置を決める）を行っていきましょう。
以下のようなステップで、適切なポジショニングを行うことができます。
1.ターゲット市場のニーズや要望を把握する
顧客が求めるものや競合との差別化ポイントを把握する。
2.自社商品やサービスの差別化ポイントを明確にする
自社の強みや差別化ポイントを明確にして、それらを強調するようなポジショニングを行う。
3.ポジショニングの戦略を策定する
自社のビジョンや戦略、ブランドイメージなどを考慮しながら、ターゲット市場に適したポジショニングを決定する。
5. マーケティング戦略の決定・実施・改善を行う
STP分析は、セグメンテーション・ターゲティング・ポジショニングを行うフレームワークですが、これらを分析したうえでマーケティング戦略・アプローチ方法を決定するまでが、一連の流れになります。
分析作業を行い、そこで終わることがないようにしてください。
あくまで、「マーケティング戦略の決定・実施・改善」を行うための、下準備だと考えるようにしましょう。
しかし、STP分析だけで全てを網羅できるわけではありません。
その他のフレームワークや分析方法と併用することで、より効果的なマーケティング活動ができるようになります。
それでは最後に、STP分析を行う上での4つの注意点について見ていきましょう。
- セグメンテーションの方法を選定する際は、必ず顧客のニーズや特徴に基づいて分類するようにし、客観的な視点・基準で考えるようにする。
- ターゲット市場を選定する際は、市場規模・成長性・競合状況などの様々な要素を総合的に考慮しながら決定する。
- 常に市場環境や顧客のニーズに変化に対応できる柔軟性を持つようにする。
- 分析作業には、十分な時間や人のリソースを割くようにする。そのうえで、客観的な情報を元にマーケティング戦略やアプローチ方法の決定・実施・改善を継続的に行う。
これらの点に注意しながらSTP分析を行い、より効果的なマーケティング活動に繋げられるようにしましょう。
以上、「STP分析」について解説してきました。
このSTP分析は、マーケティング戦略を策定するうえでは欠かせない重要なフレームワークの1つです。
自社の立ち位置を明確にしたり、他社との差別化をできたり、事業の成長に大きく関わる要素を分析することができます。
概要をしっかり理解すれば、さほど難しくはない分析手法になりますので、ぜひ今後のビジネスに役立てられるようにしましょう。
また、STP分析だけでなく様々なフレームワークと併用することで、より効果的なマーケティング活動ができるようになるので、1つ1つ理解して上手く活用できるようになりましょう。
本記事を執筆している KICK ZA ISSUE株式会社では、新規事業の立ち上げに強みを持ったマーケティング・戦略コンサルタントが多く在籍しております。
これから新規事業を立ち上げる検討されている企業様は、ぜひお気軽にご相談ください。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク -
PEST分析とは？（実践テンプレート付）
企業戦略や市場分析、現状把握をする際に用いられるフレームワークである「PEST分析」。
外部環境の要因を整理し、分析するためのフレームワークになります。
企業やプロジェクトが直面する外部環境の変化に対して、柔軟に対応できるようになるために、このPEST分析をしっかりと理解・活用できるようになりましょう！
本記事では、PEST分析の概要や基礎知識、PEST分析を行う際の手順（※テンプレート付き）、注意点などを徹底解説していきますので、今後のビジネスに役立ててください。
PEST分析のテンプレートはこちら
PEST分析とは、政治（Politics）・経済（Economy）・社会（Society）・技術（Technology）の4つの要素から分析することで、自社に関連する外部環境を把握できるフレームワークになります。
これら4つの英語の頭文字を取って、「PEST（ペスト）分析」と呼ばれています。
PEST分析は、経営学者でマーケティングの第一人者であり、ノースウェスタン大学ケロッグビジネススクールの教授フィリップ・コトラー氏が提唱したものです。
では次に、それぞれどのような要素が該当するのか見ていきましょう。
政治（Politics） 法律、条例、規制、政策、政治的な安定性 経済（Economy） 景気動向、消費者行動、インフレーション、為替レート 社会（Society） 人々の価値観、ライフスタイル、人口動向、文化的な傾向 技術（Technology） 新技術、イノベーション、特許、競合他社の技術 これら自社で制御・コントロールできないマクロ環境（より大きな視点）を分析できることが特徴です。
マーケティング戦略や事業戦略立案の一環としてPEST分析を実施することで、自社の現状・立ち位置を把握でき、今後のビジネス戦略やアクションプランの策定に役立ちます。
それにより、市場やビジネス環境の変化に柔軟に対応できる可能性が高くなります。
PEST分析の概要を理解したところで、次はPEST分析を行う目的・役割には、どのようなものがあるのか解説していきます。
- 外部環境の要因を分析することで、企業や組織が直面する可能性のあるリスクや機会を特定することができる。
- 政治、経済、社会、技術の各要因のトレンドや動向を把握し、市場やビジネス環境の変化を予測することができる。
- PEST分析によって得られた情報を元に、ビジネス戦略やマーケティングプランを策定することができる。
PEST分析の目的・役割には、上記のようなものがありますが、あくまで“ミクロ環境”ではなく、自社ではコントロールできない“マクロ環境”を分析するフレームワークであると覚えておきましょう。
ここで注意したいのが、「マクロ環境を分析すること」を目的にしてはいけません。
分析・把握したうえで、今後の「マーケティング戦略/事業戦略の策定」が目的であることを必ず覚えておいてください。
マクロ環境をしっかりと把握することで、今後のマーケティング戦略や事業戦略の方向性を決めやすくなるのです。
それでは実際に、PEST分析のやり方・手順を見ていきましょう。
- 目的・ゴールを社内で共有・明確にする
- 政治・経済・社会・技術の4つの要素を振り分ける
- 振り分けた要素を「事実」と「解釈」に分類する
- 振り分けた要素を「機会」と「脅威」に分類する
- 振り分けた要素を「短期」と「長期」に分類する
1. 目的・ゴールを社内で共有・明確にする
まずは、なぜPEST分析を実施するのか目的やゴールを明確にするようにしましょう。
目的を明確化することで、分析結果を適切に効率よく活用することができます。
目的が不透明なままPEST分析を実施してしまい、「時間や労力が無駄になってしまった…」なんていうことがないように注意しましょう。
また、目的と併せてゴールの設定も大事になってきます。
設定したゴールに対して、どのような結果が得られたのかを判断することも、今後の改善に大きく影響してきます。
2. 政治・経済・社会・技術の4つの要素を振り分ける
目的・ゴールが明確化できたら、政治（Politics）・経済（Economy）・社会（Society）・技術（Technology）の4つの要素ごとに、情報をまとめていきましょう。
情報収集の方法は様々ありますが、一般的には新聞・テレビ・業界の情報誌や情報サイト・展示会などを活用することがおすすめです。
調べた情報をどの要素に振り分ければ良いか分からないこともあると思いますが、PESTを分類することが目的ではないので、一旦自分の思う要素に振り分ければ大丈夫です。（※もちろん正確な分類に越した事はありません。）
3. 振り分けた要素を「事実」と「解釈」に分類する
続いては、2で振り分けたそれぞれの要素を「事実」と「解釈」に分類していきます。
- 事実：実際に起こっていること、誰が見ても同じこと
- 解釈：受け手によって理解が変わること、個人的な考え
外部環境で起こっている出来事が、事実であるかどうかをしっかりと見極めることができなければ、正確な分析結果が得られなかったり、見当違いなマーケティング/事業戦略を策定してしまうリスクが生じてしまいます。
事実と解釈のどちらに分類すればよいか迷った場合は、複数人にヒアリングすることをおすすめします。
また、ネット上には様々な虚偽の情報も溢れていますので、注意するようにしましょう。
4. 振り分けた要素を「機会」と「脅威」に分類する
続いては、3で振り分けた「事実」を「機会（チャンス）」と「脅威（リスク）」に分類していきます。
- 機会（チャンス）：市場やビジネス環境の変化に対応するためのチャンスとなるポジティブな要素を指します。（例）新しい政策が制定されたことによって、自社の製品・サービスの需要が拡大する可能性がある
- 脅威（リスク）：市場やビジネス環境に対して、ネガティブな影響を与える可能性がある要素を指します。（例）新しい競合他社の参入や新しい規制によって、自社の市場シェアが減少する可能性がある
この「機会（チャンス）」と「脅威（リスク）」は、企業や状況によっては「機会が脅威に」「脅威が機会に」となる可能性もあります。
そのため、自社にとっての機会と脅威を正確に分類しなければなりませんので、様々な角度からの視点や複数人の視点から分類するようにしましょう。
5. 振り分けた要素を「短期」と「長期」に分類する
続いては、4で振り分けた「機会（チャンス）」と「脅威（リスク）」を、「短期」と「長期」に分類していきます。
「機会（チャンス）」と「脅威（リスク）」がそれぞれどの程度の期間で影響を及ぼすかを明確にしなければいけません。
ここを明確にすることで、チャンスを逃す可能性の軽減・リスク回避の可能性の増大に繋げることができます。
比較的近いうちに起こることなのか、将来的に起こることなのかの判断を間違えてしまうと、マーケティング/事業戦略にも影響が及んでしまいますので注意が必要です。
それでは最後に、PEST分析を行う上での4つの注意点について見ていきましょう。
- 事実にのみ基づき分析を行う
- 要因を過剰に分析しない
- 内部環境との関連性も考える
- 過去の情報だけに頼らない
上記4つをそれぞれ解説していきます。
事実にのみ基づき分析を行う
PEST分析では、客観的な分析を行うことが重要になってきます。主観的な考えや感情に基づいた分析では、正確な分析結果を得ることができなくなってしまいます。
必ず、事実に基づいた分析を行うようにしましょう。
要因を過剰に分析しない
PEST分析では、情報収集をすればするほど多数の要因を分析することができますが、必ずしも全ての要因を分析することが必要とは限りません。
自社との関連性を見極めながら、より重要な要因に着目して、分析作業に集中することがポイントになってきます。
自社にとって重要ではない、関連性のない要因を分析してしまい、社内リソースの無駄使いをしないようにしましょう。
内部環境との関連性も考える
PEST分析は、外部環境（マクロ環境）を分析するフレームワークですが、内部環境との関連性も考える必要があります。
内部環境が、外部環境にどのような影響を与えるかを考慮することも重要です。
SWOT分析（内部環境と外部環境を分析できる）も同時に行うなど、1つのフレームワークだけに頼りすぎないように注意しましょう。
SWOT分析については、以下の記事を参考にしてみてください。
SWOT分析 / クロスSWOT分析とは？（実践テンプレート付）
過去の情報だけに頼らない
PEST分析を行う際は、過去の情報を元に分析を実施することもあると思います。
しかし、市場やビジネス環境などの外部環境（マクロ環境）は、常に変化をしているため、過去の情報だけに頼りすぎるのは避けるようにしてください。
過去の情報にプラスアルファで、最新の情報も入手しながら分析を行い、より正確な分析結果を得られるようにしましょう。
今回は、「PEST分析」について解説してきました。
政治・経済・社会・技術の4つの要素は、昨今ものすごいスピードで変化し続けています。
これらの外部環境の影響を受けずにビジネスをすることは不可能であるため、よりこのPEST分析が重要になってきていると思います。
もちろんPEST分析を行うことは大事なポイントではありますが、あくまでフレームワークの1つであるということを忘れてはいけません。
フレームワークに当てはめるだけで、円滑にマーケティングや事業が行えるという訳ではなく、しっかりとした目的や計画を理解したうえで活用するようにしましょう。
本記事を執筆している KICK ZA ISSUE株式会社では、新規事業の立ち上げに強みを持ったマーケティング・戦略コンサルタントが多く在籍しております。
これから新規事業を立ち上げる検討されている企業様は、ぜひお気軽にご相談ください。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク -
SWOT分析 / クロスSWOT分析とは？（実践テンプレート付）
組織やプロジェクトなどの評価を行う際に利用するフレームワークである「SWOT分析」。
経営者の方や経営戦略に携わる仕事をしている方は、一度はこの言葉を聞いたことがあるのではないでしょうか。
このSWOT分析は、経営学者の“ヘンリー・ミンツバーグ”が提唱して、のちにハーバード・ビジネススクールの“ケネス・R・アンドルーズ”が執筆した著書によって、世界中に広まっていったと言われています。
経営戦略の方向性をより明確にすることができるように、このSWOT分析をしっかりと理解・活用できるようになりましょう！
本記事では、SWOT分析の基礎知識から活用方法（※テンプレート付き）まで徹底解説していきますので、今後のビジネスに役立ててください。
SWOT分析のテンプレートはこちら
クロスSWOT分析のテンプレートはこちら
SWOT分析とは、「Strenght（強み）」「Weakness（弱み）」「Opportunity（機会）」「Threat（脅威）」の4つの要素から構成される分析フレームワークの1つになります。
自社の強み・弱み（内部環境）とマーケットの機会・脅威（外部環境）を掛け合わせて自社の分析を行い、今後の経営戦略の方向性を見極める際に有効な手法です。
上記のようなマトリクス表を用いて、それぞれ4つの視点から、組織やプロジェクトの内部環境・外部環境を整理し、自社が取るべき戦略を考えていきます。
では実際に、この4つの視点（強み・弱み・機会・脅威）にはどのようなものがあるか、詳しく見ていきましょう。
Strenght（強み）：内部環境
自社の組織やプロジェクトが持っている、優位なポジションや特徴などの強みを指します。
これらは、目標を達成させるための優位性や成功要因となり得るプラスの要素になり、以下のようなものがあります。
- 高品質の商品やサービス
- 高いブランド力
- 優秀な人材やチーム
- 顧客ベースの豊富なネットワーク
Weakness（弱み）：内部環境
自社の組織やプロジェクトが持っている、優位なポジションや特徴などの強みを指します。
自社の組織やプロジェクトの、欠陥や不足点を指します。
目標達成のために必要な要素であるものの、マーケットにおいて他社より劣っている部分になり、以下のようなものがあります。
- 顧客満足度の低い商品やサービス
- ブランドイメージが悪い
- 人材不足やスキル不足の人員
- 資金力が劣っている
Opportunity（機会）：外部環境
自社の組織やプロジェクトが持っている、優位なポジションや特徴などの強みを指します。
目標達成に対して、有利に働くような機会（チャンス）の外的要因を指します。
この機会（チャンス）には、以下のようなものがあります。
- 新しい市場や顧客の開拓
- 技術や市場の発展や進化
- 新事業やニーズの需要アップ
- 政治や経済環境の変化による新しい可能性
Threat（脅威）：外部環境
目標達成に対して、外的要因としての危険やリスクなどの脅威を指します。
この脅威には、以下のようなものがあります。
- 競合他社が自社より優位性を持っている
- 政治や経済環境の変化や不安定性
- 消費者や市場のトレンドの変化
- 自然災害やテクノロジー障害
それでは「SWOT分析とはなにか」を理解できたところで、次はSWOT分析のメリット・デメリットを解説していきます。
SWOT分析のメリット
- 企業やプロジェクトの「強み」「弱み」「機会」「脅威」を明確にすることができ、問題点を洗い出すことができる。
- 内部環境と外部環境の2つの視点から戦略や方針を決定できる。
- 分析結果を社内にて共有することで、他の事案にも活用できる。
SWOT分析のデメリット
- 分析対象となる要素が少なすぎると、正確な結果を得ることができない。
- 分析メンバーや分析方法に偏りがあると、単純な分類になる可能性がある。
それでは実際に、SWOT分析のやり方・手順を見ていきましょう。
- 何をどのように分析したいのか、目的を明確にする。
- 分析に必要なメンバーを選定する。
- 選定したメンバーから、「強み」「弱み」「機会」「脅威」の4つの要素をリストアップする。
- 4つの要素をそれぞれクロスさせて分析を行う。（クロスSWOT分析）
- 分析結果を整理し、戦略・方針を決定する。
1. 何をどのように分析したいのか、目的を明確にする
まずは、何を分析したくてSWOT分析を行うのか、目的を明確にします。
ここでは、分析対象となる組織・プロジェクトや分析期間なども決定するようにしましょう。
目的（ゴール）を明確にすることで、今後の「分析方法～戦略・方針の決定」までのアプローチをより精度の高いものとすることができます。
2. 分析に必要なメンバーを選定する
SWOT分析を行う目的を明確にすることができたら、次に分析に必要なメンバーをしていきましょう。
よくある失敗として、「経営陣や役員のみで分析を行ってしまう」というケースがあります。
例えば、現場の声（営業担当や開発担当など）を反映させずに、SWOT分析～戦略・方針の決定を行ってしまい、結果的に「的外れな分析を行っていた」「現場とのミスマッチが起き見当違いな戦略・方針になってしまった」というパターンもあります。
このような失敗をしないように、目的に応じて必要なメンバーを正確かつ慎重に選ぶようにしましょう。
3. 選定したメンバーから、「強み」「弱み」「機会」「脅威」の4つの要素をリストアップする
それでは次に、実際の分析作業・情報収集に入っていきましょう。
「強み」「弱み」「機会」「脅威」の4つの要素を分析メンバーでリストアップしていきます。
実際に、リストアップをしていく中で考えに行き詰ったり、視野が狭くなっているなどのケースも想定されます。
複数人でリストアップを行っている場合がほとんどだと思いますので、他の人の意見を聞いたりディスカッションなどコミュニケーションを取りながら、主観的ではなくより客観的に物事を判断するように注意しましょう。
4. 4つの要素をそれぞれクロスさせて分析を行う。（クロスSWOT分析）
（※クロスSWOT分析については、次章にて図を用いながら解説していますので、ここでは簡潔に解説しています。）
「強み」「弱み」「機会」「脅威」の4つの要素をリストアップが完了したら、これらの情報を掛け合わせながら、さらに確度の高い分析を行っていきましょう。
5. 分析結果を整理し、戦略・方針を決定する
それでは最後に、これまでの①～④のプロセスで得られた分析結果を整理し、今後の組織やプロジェクトの戦略・方針を決定していきます。
戦略・方針をより具体的にすることで、社内でのミスコミュニケーションが起こるリスクも軽減でき、施策の実行や改善などをスムーズに行うことができるようになります。
クロスSWOT分析とは、SWOT分析で洗い出した4つの要素（強み・弱み・機会・脅威）を掛け合わせて、より詳しく分析していくフレームワークです。
上記の図のように、内部環境（強み・弱み）と外部環境（機会・脅威）をそれぞれクロスさせて、4つのパターンでの分析を進めていきます。
SWOT分析だけでは得られなかった細かな要素を発見できたり、組織やプロジェクトの問題点の抽出ができるので、より具体的に戦略・方針の決定を行うことができる可能性が高くなります。
また、問題点や対策方法などの見落としを防ぐという効果も期待できるでしょう。
それでは最後に、SWOT分析で特定した外部環境を、より詳細に分析することができる「PEST分析」というフレームワークについても解説していきます。
これまでSWOT分析は、内部環境（強み・弱み）と外部環境（機会・脅威）を特定するためのフレームワークであると解説してきました。
一方で、PEST分析は外部環境のみを分析するフレームワークになっています。
アメリカの経済学者である“フィリップ・コトラー”教授が提唱し、「政治・経済・社会・技術」の4つの視点から分析するマーケティング手法になります。
Politics（政治的要因） 政治環境、法律・規制、税制など Economy（経済的要因） 国内・国際的な経済状況、通貨・物価変動、消費者行動など Society（社会的要因） 人口動向、教育レベル、文化など Technology（技術的要因） 技術革新、特許、競合他社の技術的進歩など 外部環境の推移に伴い、自社にどのような影響を及ぼすかを把握・予測に役立つ分析手法です。
今回は、SWOT分析 / クロスSWOT分析とは？について解説しました。
本記事を執筆している KICK ZA ISSUE株式会社では、新規事業の立ち上げに強みを持った戦略コンサルタントが多く在籍しております。
これから新規事業を立ち上げる検討されている企業様は、ぜひお気軽にご相談ください。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク -
アジャイル開発のメリットとデメリット
システム開発にはアジャイル開発とウォーターフォール開発の大きく二つの開発手法があります。
アジャイル開発は「サービスインまでの期間を短縮できる」「仕様変更や要件変更に柔軟に対応できる」といった特徴があるため、近年はベンチャー企業だけでなく大企業でも取り入れている企業が増えています。
そんなアジャイル開発ですが、良い点ばかりではありません。
本記事ではアジャイル開発の特徴やメリット・デメリットを解説します。
アジャイル開発を正しく理解し、導入可否を判断できるようにしましょう。
アジャイル開発とは、2001年にアメリカにおいて「アジャイルソフトウェア開発宣言」として原則をまとめ確立された開発手法です。
「アジャイル（agile）」という言葉の意味通り、プロジェクトを小さい単位に分けて「素早く」システム開発を進めていきます。
アジャイル開発の特徴は、プロジェクトを小さいタスクに分けて、イテレーション（スプリントとも言う）と呼ばれる短い期間ごとに開発していく点です。
イテレーションごとに進めるタスクを決めて、機能を1つずつ実装することができるので、仕様変更に強く、ユーザーの要望を柔軟に反映することができます。
アジャイル開発において、イテレーションは基本的に1～2週間程度の期間で設定され、その期間ごとに各機能を開発、実装することで大きなシステムを完成させるので、アプリ開発や管理保守といった継続的な契約に向いている開発手法です。
反対に、成果物を納品して完了の買い切り型の契約や、長年手作業で行っていた工程をシステム化するなど、既に作るべき機能が明確に定まっている場合には適していません。
Sprint（=イテレーション）毎に要件定義〜実装まで行う もう1つの開発手法であるウォーターフォール開発との大きな違いは、その可逆性にあります。
ウォーターフォール開発では、「要件定義→設計→実装→テスト→リリース」と上流から下流へ水が流れるようにリリースまでの各工程を段階的に完了させます。
ウォーターフォール開発では基本的に前の工程に戻ることはありません。つまり一度決めた要件を変更することは基本的にNGです。
変更する場合は変更会議など必要なステップを踏む必要がありますが、ウォーターフォール開発において要件変更を発生させることは遅延や失敗のリスクになるので、基本的に要件変更はせず、要件定義工程できちんと要件を決め切ることをおすすめします。
一方でアジャイル開発はイテレーション毎に要件定義を行うので、柔軟に要件を変更できます。
前のイテレーションで決めた要件を実装した後に、「やっぱり思ってたのと違う」「これだと業務が回らない」などの理由により、次回イテレーションで再度要件を変更する、といった進め方が可能になります。
ウォーターフォール開発とアジャイル開発の違い アジャイル開発の中にもいくつかの種類があります。ここでは、用いられることの多い3つの種類の概要を紹介します。
スクラム開発
スクラム開発は、もっとも有名なアジャイル開発手法です。
開発チームのメンバーが自分たちで主体的に計画立案を行うことで開発を進め、チームリーダーとなるスクラムマスターがチーム内外との連絡調整を行います。
スクラム開発ではイテレーションのことをスプリントと呼びますが同じ意味で用いられます。
エクストリーム・プログラミング（XP）
事前の計画よりも仕様・要件の途中変更への柔軟な対応を重要視した手法です。
エンジニアがペアを組み、コーディング内容を互いに確認しながら作業を進めるため、エラーや仕様変更に対応しやすくなっています。
ユーザー機能駆動開発（FDD）
ユーザーに対してシステムが生み出す機能や価値を重視した開発手法です。
ユーザーへヒアリングを行い、開発する機能ごとにチームを編成します。
念入りなヒアリングが必要になる一方で、価値の高い機能を実装しやすいのが特徴です。
ここからはアジャイル開発を導入するメリットについて紹介します。
アジャイル開発は、ユーザーだけでなく開発を行うプログラマーやシステムエンジニアにとってもメリットのある手法であることが分かります。
仕様変更やユーザーのニーズに対応しやすい
アジャイル開発ではイテレーションごとに実装した機能に対するフィードバックをユーザーからもらうため、要望とのズレが生じにくいのがメリットです。
また、仕様変更があった場合でも、作業サイクルが小さいため手戻りとなる工数も少ないため、柔軟に対応することができます。
ユーザー側もイテレーションごとに打ち合わせを行うことで、ニーズと乖離したシステムが開発されるのを防ぐことが可能です。
要件定義が明確でなくても対応が可能
アジャイル開発では、ユーザーがどのような機能を欲しているか、全体像が見えていない状態であっても、プロジェクトの進行に合わせて固めていくことができるメリットがあります。
ウォーターフォール開発では実装に入る前に要件定義や仕様設計書を詳細に作成する必要があるため、ユーザーが自身のニーズについて整理できていない状態だと、開発に着手することができず、プロジェクトが停滞してしまいます。
トラブルに強く突発的な対応が少ない
アジャイル開発では、小さい単位で作業サイクルを回しているのでシステムエラーなどのトラブルが発生した場合でも振り返る作業範囲が小さく済むのがメリットです。
ウォーターフォール開発では、要件定義で決まった内容をもとにスケジュールや予算を見積もるため、仕様変更やトラブルが発生した際に追加作業が発生することが多いです。そのため、プログラマーやエンジニアにとってもアジャイル開発はメリットのある開発手法といえます。
アジャイル開発のデメリットは開発しているシステムの全体像が把握しにくいことです。
イテレーションごとに実装する機能を決め開発を行い、リリースまで手掛けるため、開発しているシステムの全体像を見失いやすいです。
プロジェクトの指針をしっかり持っていないと、システム開発にブレが生じる可能性があります。
そのためアジャイル開発では、ユーザーストーリーが重要です。
ユーザーストーリーとは、ユーザーが実現したいことを簡潔にまとめたもので、打ち合わせの中で構築されます。
このユーザーストーリーを基にシステム開発に必要なタスクをまとめたプロダクトバックログが作成され、イテレーションごとにプロダクトバックログから作業を行うタスクを選定し、機能開発を行います。
ユーザーストーリーが明確になっていれば、場当たり的な開発になることを防ぎ、一貫したシステム開発を行うことが可能です。
今回は、アジャイル開発の特徴やメリット・デメリットについて紹介しました。
アジャイル開発はユーザーだけでなく、プログラマーやシステムエンジニアにとってもメリットの多い開発手法です。
今後従来のウォーターフォール開発からアジャイル開発へ転換する企業も増えることが予想されます。
本記事を執筆している KICK ZA ISSUE株式会社では、アジャイル開発のプロジェクトマネジメント経験を持つITコンサルタントが多く在籍しております。
アジャイル開発の導入を検討されている企業様は、ぜひお気軽にご相談ください。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク -
システム開発プロジェクトにおけるプロジェクトマネジメントの基礎③
DX化の推進を背景に、システム開発プロジェクトを適切に管理する「プロジェクトマネジメント」の重要性は高まっています。
本記事では、「システム開発プロジェクトにおけるプロジェクトマネジメントの基礎」を、主に初めてシステム開発プロジェクトを担当することになった方向けに解説します。
なお本記事は「システム開発プロジェクトにおけるプロジェクトマネジメントの基礎①・②」の続きになります。
まだ読んでいない方はこちらから先に読んでいただくことをお勧めします。
システム開発プロジェクトにおけるプロジェクトマネジメントの基礎①
システム開発プロジェクトにおけるプロジェクトマネジメントの基礎②
プロジェクトマネジメントの基礎知識をこれまで解説してきました。
ここでは、プロジェクトマネジメントの重要性を再確認しておきたいと思います。
ここで質問です。
プロジェクトがなにも問題が起きずに完了する確率は何％だと思いますか？
実は実施期間が1年以上のプロジェクトに限って言うと、プロジェクトの成功率は約60%程になります。
つまり半分弱のプロジェクトは「失敗」するわけです。
ただでさえ難しい「プロジェクトマネジメント」ですが、正しい方法論を知らないとその失敗確率はますます高くなります。
ではシステム開発プロジェクトにおいてはどの工程で最も問題（コスト超過や納期遅れ）が発生するでしょうか？
正解は、「すべての工程で満遍なく問題が起きうる」です。
日経コンピューターが行った「問題が生じた工程」に関するアンケートの結果、すべての工程で満遍なく問題が発生していることが分かります。
どの工程においても気が抜けないのがお分かり頂けたかと思います。
システム開発プロジェクトをマネジメントするプロジェクトマネージャは、一見プロジェクトが上手くいっている時でも、「遅れるリスクはないか？」「PMBOK体系で考慮できていない領域はないか？」と疑い、問題に対して準備することが必要です。
先ほど、「遅延や工数増加は全ての工程で起きうる」とお伝えしました。
しかしその原因を紐解くと、ほとんどの場合「要件定義工程」が原因であることが分かります。
実際、日経コンピューターが行った調査においても遅延の理由として「要件定義が不十分」「システムの企画が不十分」が上位を占めています。
つまり上流工程、それも要件定義工程での成果が不十分だと、後続の工程で遅延や費用増が発生する可能性が高くなる、ということです。
では要件定義工程で遅れの元を発生させないためにはどうしたら良いのでしょうか。
ここでは、「要件定義で遅れの元が発生する」＝「要件定義が不十分」になってしまう最大の原因を３つ紹介し、それらに対する対策を解説します。
1. ユーザー部門を十分に巻き込めていない。
要件定義が不十分になってしまう最大の理由の１つは要件を出す側であるユーザー部門の巻き込み不足です。
巻き込み不足には以下２種類あり、
- 非協力的で要件を網羅的に出そうとする意識がない。
- そもそも要件を提示してもらう参加者が足りない。
１点目の「非協力的で要件を網羅的に出そうとする意識がない」という点に関しては、そもそもプロジェクト内での関係構築が上手くできていない可能性があります。
最も多いケースは、「システム開発はよく分からないけど上司に言われたから会議に参加している」というマインドのユーザー部門で、このようなマインドを持ったプロジェクトメンバーがいると要件定義漏れが頻繁に発生します。
この場合は、「このプロジェクトを成功させることの意義」をユーザー部門の方と共通認識化することが重要になるとともに、「システム開発プロセス」や「要件定義の考え方」といったテクニカル面もしっかり教育していくことが有効です。
またあまりにもユーザー部門の協力が得られない場合は、プロジェクトオーナーにメンバー変更を申し入れるのも有効です。
２点目の「そもそも要件を提示してもらう参加者が足りない」という点に関しては、構築するシステムの利用ユーザー部門・ステークホルダーの洗い出しが十分でない可能性があります。
システム開発を行う場合、そのシステムを利用する全部門を巻き込むのが理想的です。
しかしリソースが割けない等の理由でそれができず、情シス部門や企画部門の方のみと要件定義を進め完結させてしまうケースが散見されます。
そうなるといざシステムを作ってみると「こんなもの使えない」と実際の利用部門から反発があり「使われないシステム」が出来上がってしまいます。
このような事態を防ぐために、まず何よりも「このシステムの利用ユーザー部門は誰か」を明確に定義することが重要で、その後は「システムを利用する全ユーザー部門をプロジェクトに巻き込む」ことが必須になります。
ただ巻き込み方にも注意が必要で、全ユーザー部門の意見を全て聞き入れるというよりも「このような要件になる」と丁寧に説明し、一つ一つ各部門の合意を得て進めていくことで、後々大きな手戻りになることを防ぐことができます。
2. Want要件に惑わされる。
要件定義が不十分になってしまう理由の２つ目は、「Want要件に惑わされる」です。
基本的に要件を出す側のユーザー部門のマインドは「とりあえずやりたいことは全部言っておこう。言わないとやってくれない。」です。
これはシステム開発プロジェクトに慣れていないが故に「この機能ほんとにいるの？」と思われるような要件も思いつくがまま提示されます。
このような「なくても業務は回るがあると良い機能」を「Want要件」と言います。
このWant要件を全て聞き入れ要件定義を進めていくと、要件定義工程自体が遅延しますし「この機能がないと業務が回らない」＝「Must要件」の定義が甘くなり、後々の工程で遅延が発生します。
このような事態を防ぐために、プロジェクトマネージャは「Must要件」と「Want要件」に切り分けを必ず行う必要があり、Want要件よりもMust要件の定義に時間をかけるべきです。
ユーザー部門の意見を上手くコントロールし、意義あるシステム開発にすべきなのです。
3. プロジェクトの目的が共通認識になっていない。
要件定義が不十分になってしまう理由の３つ目は、「プロジェクトの目的が共通認識になっていない」です。
システム開発プロジェクトを進めるにあたっては、そのシステムを利用するあらゆる関係者を巻き込みながら進める必要があると、先ほど触れました。
しかしその関係者・関係部署間で、「システム開発をする目的」が共通認識化できていないことが頻繁に発生します。
例えば経理部は「老朽化したためしょうがなくシステム改修を行う。現状業務は一切変わらない。」と考えている一方で、経営企画部は「今の業務は非効率な部分が多すぎるため、業務プロセスを抜本的に見直し、新たな業務プロセスに合わせてシステムを構築する。」と考えているかもしれません。
実際このような「認識の差」はプロジェクト規模が大きく、関連部署が多岐に渡るほど多く発生します。
このように関係者・部署間によってプロジェクトの目的に認識の差があると、要件定義が難航しやすいです。
先ほどの例だと、経理部門は既存業務が変わらないと思っているのでシステム要件も「現行踏襲」が基本になりますが、経営企画部は０ベースでの要件提示になるため、齟齬が生まれやすくなかなか要件が決まりません。
こうした事態を防ぐために、「このシステム開発プロジェクトでは何を実現したいのか」というプロジェクトの目的を具体的に明文化し、関係者・部署間で合意した上で進めることが非常に重要になります。
「プロジェクトの目的」を明文化する際は、可能な限り具体的な記載にすべきで、例えば「システム導入後、〇〇という業務が月間30時間削減される。」だとか、「システム導入後、顧客満足度の〇〇という数値がXX%向上する。」といったKPI（Key Performance Indicator）を定義することも有効です。
本記事では、プロジェクトマネジメントを行うにあたり最も問題が発生しやすい「要件定義工程」を成功させるためのTipsをを解説させていただきました。
本記事を執筆している KICK ZA ISSUE株式会社では、企業のIT化/DX化のお悩みを解決できる各種コンサルティングサービスを提供しています。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク -
システム開発プロジェクトにおけるプロジェクトマネジメントの基礎②
DX化の推進を背景に、システム開発プロジェクトを適切に管理する「プロジェクトマネジメント」の重要性は高まっています。
本記事では、「システム開発プロジェクトにおけるプロジェクトマネジメントの基礎」を、主に初めてシステム開発プロジェクトを担当することになった方向けに解説します。
なお本記事は「システム開発プロジェクトにおけるプロジェクトマネジメントの基礎①」の続きになります。
まだ読んでいない方はこちらから先に読んでいただくことをお勧めします。
システム開発プロジェクトにおけるプロジェクトマネジメントの基礎①
プロジェクトマネジメントを理解する上で、「PM」と「PMO」の違いを理解することは重要です。
PM
「PM」とはProject Manager の略です。
その役割は「プロジェクトにおける重要事項を意思決定する責任者」としてプロジェクトを推進する人物を指します。
PMO
一方で「PMO」はProject Management Office の略で、その役割は「プロジェクトにおける意思決定を支援する」ことです。
つまり、PMが意思決定するために必要な情報を可視化・整理することがPMOの役割と言えます。
システム開発プロジェクトにおける一般的な体制図を以下に示します。
「PM」と「PMO」との違いは端的に「意思決定責任があるか否か」と表現できます。
任されたポジションが「PM」なのか「PMO」なのか、を正確に理解することは、自身の役割や期待値を把握する上で非常に重要なので、混同しないようにしましょう。
なお参考までに、「PGMO」というものもあります。
Program Management Office の略で、複数のプロジェクトが並行してそれらが同じゴールに向かって整合をとりながら進めていくべきものである場合、プロジェ クトの集合体をプログラムとして捉え、その全体のプランニング・マネジメントを担っていくべき機能をPGMOと呼びます。
プロジェクトマネジメントを行うにあたり、「PMBOK」を理解することは重要です。
この「PMBOK」を理解することで、「プロジェクトマネジメント」とは具体的にどのようなことを行うものなのか、が理解できると言っても良いでしょう。
「PMBOK」は、Project Management Body of Knowledge の略で、「プロジェクトマネジメント知識体系」と略すことができ、「ピンボック」と呼ばれます。
PMBOKは1987年にアメリカの非営利団体である「PMI（Project Management Insitute）」により、「A Guide to the Project Management Body of Knowledge」というプロジェクトマネジメントを行う上で実践すべき知識体系をまとめたレポートが発表されて以来、世界各国に知られわたるようになり、今では「プロジェクトマネジメントにおける世界基準」として浸透しています。
1996年に「PMBOK 初版」が公表されて以来約4年に1度のペースでアップデートされており、2022年時点では第7版が最新となっています。
PMBOKの意義は、これまで勘や経験を頼りに行われていたプロジェクトマネジメントを、そのプロセスを体系化しプロジェクトマネジメントの正攻法を確立させたことです。
これからプロジェクトマネジメントを行う方にとって、PMBOKを理解せずにプロジェクトマネジメントを行うのは武器を持たずに戦場に行くようなもので、戦い方さえ分からないのと同義ですので、しっかり抑えましょう。
そんなPMBOKですが、「10の知識エリア」と「5のプロセス」で成り立っています。
以下図は「PMBOKマトリクス」と呼ばれるもので、PMBOKの知識体系を表す際に必ず登場するものです。
横軸の「プロセス」は以下5つで構成されており、
- 立ち上げ
- 計画
- 実行
- 監視・管理
- 終結
縦軸の「知識エリア」は以下10つで構成されています。
- 統合管理
- スコープ管理
- スケジュール管理
- コスト管理
- 品質管理
- 組織管理
- コミュニケーション管理
- リスク管理
- 調達管理
- ステークホルダー管理
PMBOKでは、上述の各プロセス×知識エリア毎に作成すべき成果物が定義されており、例えば、「立ち上げ」プロセスの「統合管理」知識エリアにおいては、「プロジェクトスコープ記述書暫定版」という成果物を作成することになっています。
この「プロジェクトスコープ記述書暫定版」とは、プロジェクトにおける実行スコープを定義したもので、プロジェクトにおける重要な意思決定をする上で、必ず立ち返るべき重要な定義項目となります。
このようにPMBOKでは各プロセス×知識エリア毎に成果物を作成することが推奨されており、その作成方法も定義されています。
以下のように、成果物を作成するための「入力（Input）」があり、「ツールと技法」を用いて「出力（Output）」する、という流れです。
要約すると、PMBOKは「このフェーズはこの手法でこの成果物を作成し合意すべし」というプロジェクトマネジメントにおける羅針盤的役割を果たすものです。
各プロセス×知識エリア毎に作成すべき成果物の具体的な作成方法や注意点は別記事で解説します。
PMBOKに関して原文で学習したい方向けに、以下公式PMBOKガイドをご紹介しておきます。
リンク本記事では、プロジェクトマネジメントを行うにあたりPMBOKを理解することの重要性を解説させていただきました。
本記事を執筆している KICK ZA ISSUE株式会社では、企業のIT化/DX化のお悩みを解決できる各種コンサルティングサービスを提供しています。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク -
システム開発プロジェクトにおけるプロジェクトマネジメントの基礎①
DX化の推進を背景に、システム開発プロジェクトを適切に管理する「プロジェクトマネジメント」の重要性は高まっています。
本記事では、「システム開発プロジェクトにおけるプロジェクトマネジメントの基礎」を、主に初めてシステム開発プロジェクトを担当することになった方向けに解説します。
まず「プロジェクトマネジメント」の用語の定義から確認していきます。
プロジェクトマネジメントとは、以下のように定義できます。
プロジェクトの要求事項を満足させるために、知識・スキル・ツール・技法をプロジェクト活動に適用すること。
「プロジェクトの要求事項」とはプロジェクトの目的と同義であり、例えば「〇〇という課題を解決するシステムをXXまでに構築する」といった様に、「Q：品質」「C：コスト」「T：期間」の３軸で目的が設定されることが多いです。
プロジェクトマネジメントでは達成すべき重要な２つの機能があります。
それは、
- 計画（Planning）
- 管理（Management）
です。
「プロジェクトマネジメントを行う」ということは、この「計画」と「管理」を行う、ことと同義だと言えます。
「計画」を立てて「管理」する。この一見当たり前のように思える２つの活動のサイクルを、ツールや技法を駆使し回していくことこそが「プロジェクトマネジメント」と言えるでしょう。
計画（Planning）とは、
「先々どうするか」を考え定義し、プロジェクトに関わる人々が同じ認識になることができるようにすること
です。
ここで重要なのは、「プロジェクトに関わる人々が同じ認識になる」という点です。
計画は立てて終わりではなく、関係者と共通認識を持てることがスタートラインです。
計画を立てる目的は、「プロジェクトに関与するすべての人が、これから、何を、いつ、誰が、どうやっていくのか、を可能な限り共通認識化できるようにするため。」と言えるでしょう。
また「計画（Planning）」を立てるための具体的な作業としては、以下のようなものがあります。
- プロジェクト憲章の作成
- プロジェクトアプローチ作成
- 事業計画作成
- 成果物の定義 等
それぞれの作成方法や注意点等は、別記事にて解説したいと思います。
また計画は一度立てて終わりではなく、プロジェクトを通じて変化や詳細化が続いていくものです。
プロジェクトの進捗度や状況変化を考慮し、常に計画を見直す必要があることは忘れないでください。
次に「管理」とは、
プロジェクトにおける意思決定を然るべきタイムラインで行うことを可能にするためのコミュニケーションを取ること
と言えます。
少し難しいですが、ここで重要なのは「意思決定を促す」という点です。
プロジェクトには意思決定をする人物が必ずいます。
その人物にプロジェクトの重要局面で正しい意思決定をしてもらう、もしくは意思決定することが、プロジェクトマネジメントでは非常に重要になります。
例えば、プロジェクトに遅延を与えるリスクが発生した場合に、AかBかの選択肢を発生した時点で考え意思決定しているようでは遅く、事前に起きうるリスクを定義しそのリスクが発生した場合にどのような選択肢を取るか、を合意しておくことが「プロジェクトマネジメント」なのです。
そのためにプロジェクトマネジメントを行う人物は、「プロジェクトを見える化」し、プロジェクトで発生しうる事象を適切に意思決定者に伝え、適切なタイミングで判断できるように「管理」する必要があるのです。
具体的な「管理」を行うための作業としては以下のようなものがあります。
- 進捗管理
- 課題管理
- 論点整理
- コミュニケーションマネジメント 等
それぞれの手法や注意点は別記事で解説させていただきます。
本記事では、プロジェクトマネジメントを行うには「計画（Planning）」と「管理（Management）」が必要、というお話をさせていただきました。
本記事を執筆している KICK ZA ISSUE株式会社では、企業のIT化/DX化のお悩みを解決できる各種コンサルティングサービスを提供しています。
ご相談は無料ですので、お気軽に こちら からお問合せください。
ありがとうございました。
コンサルタント転職・副業情報発信メディア - Day1キャリア
国内最大級のコンサルタントマッチングプラットフォーム - コンサルデータバンク
