オンラインジャーナル/朝活セミナー

先号　　　次号

「第6回朝活セミナー」での話題提供を終えて

株式会社ビジネス・アソシエイツ　小宮　隆： 3月号

開催日：	2018年2月14日(水)　07：00～09：30
テーマ：	「プロジェクトを成功に導くキックオフミーティング(KOM)のやり方とは・・・？」
場　所：	東京グリーンパレスホテル地下1階　会議室
参加者：	9名

■概要■　(気づき)
　2017年10月にPMSプログラム試験に合格し、2018年1月PMSレベル講習参加で復習。P2M標準ガイドブックは、読んでとても面白いです。朝活セミナー2回目の参加で、話題提供担当となりましたが、P2M標準ガイドブックをまだ十分に理解しきれていないので、とても不安でした。

なんと「キックオフミーティング」というテーマ設定にGap発生

★	議論のポイントは、PMAJホームページのセミナー案内でも、こんな感じで提示しました。
・	皆さん方のキックオフミーティングのやり方との違いをご紹介下さい。
・	大規模プロジェクトマネジメントの視点で、気付きを教えて下さい。
・	P2M・PMBOK^®など実践経験の視点で、WBSなどの課題・改善点などの気付きを教えて下さい。
・	失敗するのは何故か？についてもご意見下さい。
・	建設的批判やユニークなアイディアは大歓迎です。

★

ここでもGap：キックオフミーティングの定義

・

私は、朝活セミナー当日までこんな認識でした。
発注者側において、システム導入プロジェクトが発足済(プロジェクトチャーター発行済)。
IT調達(以下、「パッケージ採用」の例とする)で、「RFP発行・選定完了・契約終了」。
発注者側と受注者側の両者参画による最初の合意形成の場が「キックオフミーティング」。
業務スコープと作業のスコープは、コスト見積・評価に十分なレベルで「見える化」している。
→どのフェーズのキックオフミーティングの話なのか？・・・もっともなご意見でした。
→キックオフミーティングは、フェーズ毎に行う等、様々なご意見でした。

★	ここでもGap：キックオフミーティングまでの準備
・	私は、RFP発行のレベルも様々。よって、想定リスクが明確になるまで柔軟に対応してきました。 →業務スコープ、作業スコープ、ヒアリングなど準備に対する考え・認識も、様々でした。 →tobe「要件定義」のレベル感に対する考え・認識も、様々でした。

要件定義のレベル感のGap

★

私は、キックオフミーティングを開催するからには、実現可能なWBS作成に必要なレベルまで、tobe「要件定義」(もちろんasisを踏まえている)」は完了しているという自分の考えで、勝手に説明していました。なんと不親切で配慮のないことでしょう。懺悔です。

・

例えばこんなイメージです。
発注側ユーザー言語(tobe「要求定義」・・・tobe業務設計概要レベル)を、受注側ベンダー言語(tobe「要件定義」・・・tobeシステム設計概要レベル)へ変換/翻訳するのは、その業界・業種などへの業務スキルがないと、業務ニーズの本質を理解するのに無駄に時間も必要となり、変換ミス/翻訳ミスも多発し、業務設計の品質に問題が発生してしまいます。
どこまで詳細に要件定義するかについては、いろんな進め方があると思いますが、ゴールを保証できるレベルまで(想定外リスクの発生もあるので絶対とは言い切れません。中止・撤退も想定が必要です。)、業務スコープを特定し、作業スコープを作成できると、あとはWBS通りにプロジェクトを実行していくだけです。
→よって、「キックオフミーティング」の前提条件などの事前提示も説明が不十分だったため
　ここでもtobe「要件定義」に対するGapが発生し、議論のきっかけにはなりました。

■詳細■(話題提供の内容)

★	構成
・	①本日の話題提供テーマの共通理解
・	②キックオフミーティングの準備
・	③プロジェクト目的を共有：ゴール・目的・目標
・	④スコープ(対象業務領域「組織：業務」)・・・図サンプル
・	⑤スコープ(必要な作業：WBS概要)・・・・表サンプル
・	⑥想定外リスクの発生

＜1＞本日の話題提供テーマの共通理解：本日問題のGap

＜2＞キックオフミーティングの準備

★	プロジェクトオーナー・経営層などへの事前説明・承諾。
・	プロジェクトに反対の方、納得されていない方、心配の方、遠慮なく意見発表して下さい、と建設的なバトルを誘導します。バトルは想定内ですし、リスクの洗い出しの参考となります。
・	キックオフミーティングでの発言で、その言動などが今後のプロジェクト遂行の障害になる恐れが予感できたとしても、当日の言動・行動を「人事評価」などの参考にしないで下さい。

★	RFPに要した時間を両者無駄にしないために
・	業務要件のasis・tobeを、効率よくヒアリングできるよう、発注者側視点で作成された「RFPなど情報(要求事項)」を、受注者側視点(パッケージ側業務機能の視点)へ変換します。
・	利用部門・事業部などに、チェックリスト(例として「業務分析質問書(Word)」を紹介)へ記載していただきます。「業務分析質問書」とは、業態・業種などを考慮した、業務ヒアリングのチェックリストのようなものです(ヒアリング・シナリオのようなもの)。利用中の伝票・帳票・メモなど、今後も必要と思われるものはすべて貼付(または差し込みファイル)します。ストーリ仕立てとなるので、読みやすく、だれでも理解しやすいものとなります。
・	注意点：忙しい、忙しい、忙しいと反発されても、実施します。必要に応じて、押し掛け訪問したりして、悩む時間・考えすぎる時間は最小限までカットできるよう指導します。

＜3＞プロジェクト目的を共有：ゴール・目的・目標

★	“単純にざっと”こんな感じのことを説明しています。
・	例えば、業務効率化(生産性向上)により、「同じ時間・コストで、より多くの仕事をこなせる」ようになるでしょう。そして、各部門でKGI/KPI設定しPDCAを実践できるようになるでしょう。
★	改革には、痛みをともないます。
・	①業務改革も並行して実行していくでしょうし、②改革は、全社最適化の視点でのぞみます。よって、最初は痛みをともなうこともあるでしょう。一緒に、頑張りましょう。
★	プロジェクト実行を通して、①組織も変わりますよ、②仕事のやり方(業務)も変わりますよ、③企業文化・社風も変わっていくでしょうね。
・	これから皆さんと同じ方向を向いて、建設的なバトルを繰り広げていきましょう。
・	反発があることは想定内です。思いっきりどうぞ。
★	今後の要望事項への対応は？
・	asis現行業務の機能・運用手順などは、6割検討対象、4割カットくらいの気持ちで、今後のヒアリングにのぞんで下さい。思いっきり“断捨離”を覚悟して下さい。
★	手作業は、完全になくす必要はありません。逆に、その手作業管理をどうしたら廃止できるか考えて下さい。
・	「運用手順」は変わります。「操作」はすぐ慣れます。よって、すぐに対応しない
・	何もしないような要望・課題は、対応方法のみ検討しますが、「課題管理表」に記載し情報共有し、継続検討課題とします。
・	本番稼働後に、優先順位に応じて再度検討します。本番稼働しましたら、「継続的業務改善」を開始します。
★	人件費削減・人員整理が主目的ではないので、勘違いしないで下さい。

＜4＞スコープ(対象業務領域「組織：業務」)

★	最低限この程度の業務領域・業務機能(業務トリガー)レベルを図数枚asisとtobe(上位・下位の2段階レベル程度まで)で表現しておけば(見える化)、ステークホルダー間での共通認識確保が可能です。対象業務領域の変更についての協議も、円滑に進みます。
★	経営資源の再配置を伴うでしょう。「今と変わらない」という前提はありません。仕事の分担も組織も人も、変わる想定です。プロセスだけ変えても、意味がありません、組織も人も変わるのです。

＜5＞スコープ(必要な作業：WBS概要)

★	どんなに多忙でも、作業は両社で分担します
・	WBS遵守のため、「こっちも・あっちも」モニタリングし完了迄指導します。
・	トラブルが発生しても、「体制」の問題・責任とならないよう行動しましょう。
★	現場の声(要望)は、ちゃんと聞いてもらえるのかな？
・	各種運用方針に基づき、対話を重視します。 ①定時内は全体対応でじっくりと、②定時外は個別対応でじっくりと(夕会・夜会)。
★	どんな作業を担当するのかな？
・	お互い面倒でも、最初にWBSをしっかり理解しましょう。あいまいな作業分担などで安心できなければ、WBSの詳細レベル表現に問題があるでしょうから、一緒に「あなたの」タスクや作業(アクティビティ)を追加しましょう。

＜6＞想定外リスクの発生(例)

★	想定外リスク1：発生時期＜本番稼働前＞
・	現象　：多くの社員が利用する既存外部システムの継続利用を計画していたが、その会社が倒産。
・	対応策：延期した。納期は、1年間本稼働を延長した。新規モジュールとして追加開発した。
★	想定外リスク2：発生時期＜本番稼働後＞
・	現象　：一部、既存外部システムの利用を継続していたが、その会社が製品開発から撤退したため、今後の保守契約の更新ができなくなった(保守不能)。
・	対応策：何もしない。本稼働後に自動連携処理への対応を計画していたため、問題発生時点で既に手管理で運用していた。よって、当面「何もしない」とした。

■最後に■(振り返り)
　テーマから参加者が期待したイメージとは、Gapが多々発生してしまいましたが、それが議論のきっかけとなり、少しは盛り上がっていただけたのではと思います。P2Mをより深く知るきっかけとなりましたので、話題提供を担当させていただいて、とてもラッキーでした。
　私は、この朝活セミナーを終えた夜から、P2Mの読み直しをゆっくりと始めました。やっぱり、P2Mは面白いです。基本はきちんと理解した上で、実社会で利活用していきたいと考えています。
　今後も、交流会・例会や講習会などへの参加を通して、P2Mへの理解をさらに深めたいと思います。
　以上、参加者の皆様、ありがとうございました。

参加頂いた方々からは下記のようなコメントを頂きました。

・	朝活セミナーに初めて参加させて頂きましたが、とても楽しく、多くの気づきを得られました。今後も他の話題にも参加していきたいと思います。また、自分の課題(主に、PM/PMO/品質)について、皆さんからご意見を頂けるような活動をしていきたいと思います。
・	キックオフミーティング前に、お客様とのコミュニケーションをとり、作業内容の見える化が出来るのは羨ましいです。
・	キックオフに多様な形態があることが理解できました。ありがとうございます。
・	事前に資料を見て頭の中で理解していた内容とはかなり違うけれど、そういうケースもあるのかと理解できた良い機会でした。内容としては、ERPパッケージを導入する受注者側PMが、成功させるために組織内の問題・課題を炙り出して、予定スケジュール・コスト通りに進めるために必要なキックオフミーティングの方法についてであったが、これは何にでも適用できる奥深いノウハウだと思います。
・	IT分野におけるキックオフミーティングの概要を把握できて良かったです。プロジェクトの本質的な課題は「いかに収益を上げるか」だと思っており、根本的な課題は「不採算PJをいかにNoGo出来るか」だと思っています。この課題を題材に意見交換できると良いなと思います。
・	キックオフミーティングまでの営業の能力がとても高い方でないと成立しなさそうだが、会社の文化・組織まで影響することを思えば、必要なことと深く理解できた。最初のバトルがあるから、発注者・受注者の両方で一緒に一体となって進めていけるのだと思った。
・	実務からのキックオフミーティングの目的と目標のポイントを理解できた。
・	ベンダーサイドからのキックオフミーティングの重要性とその後のプロジェクト成功への道筋を分かりやすく説明頂き整理できました。ユーザーサイドからのキックオフミーティングも対応して出して頂けると更に良かったと思います。パッケージの導入(ユーザー)と販売(ベンダー)及びシステム開発のキックオフミーティングまでの事前作業ではプロセスに違いがあるように思います。
・	想定外リスクの発生時の事例は参考になりました。システムライフやPDCAと想定外リスクとの関係についても、お話頂ける時間がとれれば良かったと思います。キックオフミーティングとカットオーバーミーティングの関係も話して頂けると良かった。
・	現在良い運営が出来ているのは、マネジメント力がベースにあるからと思います。パッケージベンダーの推進の仕方・考え方について理解できました。ありがとうございました。

以上