キックオフミーティングとは何か?その目的と効果を上げる進め方を解説

2020年5月25日

キックオフミーティングとは?

キックオフミーティングとは、ソフトウェア開発やアプリケーション制作などのプロジェクトを開始する際に、一番最初に行われるミーティングのことです。
キックオフミーティングの内容は一様ではなく、プロジェクトの目的や概要をプロジェクト・チーム間で共有するだけのこともあれば、 仕様・要件の相談がメインになることもあります 。
あるいは、具体的に開発する機能やUIのイメージなどを、プログラマーやデザイナーに共有してプロジェクトへの理解を深めてもらい、必要工数の見積もりを依頼したり、実制作を担当する人から別の提案などをもらったりすることもあります。
このように、キックオフミーティングは、プロジェクトの内容によって変わってくるものの、プロジェクトマネージャーやディレクターは、しっかりと事前に準備した上で臨むことが大切です。

キックオフミーティングの目的

なぜキックオフミーティングは必要なのでしょうか?
それはプロジェクト・メンバーの足並みをそろえ、プロジェクトのスタート地点を明確にするためです。
プロジェクトに召集されたメンバーには、企画段階からプロジェクトに携わり、プロジェクトの目的やそこから得られる利益・効果について十分に把握している人もいます。
しかし、「情報システム部の人の同意も必要だから、彼を呼ぼう」「この活動は人事部も関係するから、人事部からも担当者にでてもらおう」というように、プロジェクトの開始前後で内容も十分に理解せず、プロジェクトに参加する人も少なからずいるでしょう。
あるいは、プロジェクトの企画段階から参加していたメンバーの間にも、最終的に得られるプロダクトへのイメージに違いがあることもあります。
その結果、召集されたメンバーが適切なアドバイスを行えなかったり、ゴールの認識の違いから、プロジェクトが暗礁に乗り上げてしまったりすることもあります。
このようなトラブルを防ぐためにも、メンバー間のプロジェクトに対する認識や情報量の差異を埋め、プロジェクトのゴールや情報を改めて確認することで、プロジェクト・メンバーの足並みをそろえることがキックオフミーティングの目的であると言えるでしょう。

キックオフミーティングを進める上で重要な4つのポイント

上記の目的を踏まえ、キックオフミーティングを行う際は、大きく以下の4つのポイントを軸にして進めていくとよいでしょう。

  1. プロジェクトの背景
  2. 要件
  3. プロジェクトの体制
  4. 不安材料

ここからはこれらの内容について解説していきます。

プロジェクトの背景の確認

キックオフミーティングで確認しておきたいのは、「そもそもどのような理由でプロジェクトが始まったのか」というプロジェクトの背景です。
これはプロジェクト・メンバー間の認識を合わせるという目的もありますが、解決したい課題や達成したい目標に対して、プロジェクトの内容が本当に最適な方法なのか検証する機会にもなります。
例えば、もともと日本の植民地であった台湾にこのようなエピソードがあります。
第二次世界大戦後、台湾は日本の領土から離れ、中国国民党が統治する土地となります。
台湾に乗り込んできた中国国民党の人たちには蛇口を知らない人もおり、「ひねれば水がでる不思議な道具」と思ったそうです。
そのため、家に水が欲しい中国国民党の人たちは台湾にいた人から蛇口を買うのですが、それを家に付けても水がでるわけはなく、中国国民党の人たちは不思議がったという話です。
このように、「水が欲しい」という目的に対して、「蛇口を買う」という手段は適切な対応ではなかったのですが、プロジェクトでも同様の現象が発生することが少なからずあります。
こうした手段の誤りをできるだけ早く察知するために、プロジェクトが始まった経緯をキックオフミーティングで確認することが大切です。
また、なぜ依頼された開発を行うのかしっかりと確認し、その内容を実制作を担当するプログラマーやデザイナーなどに共有することで、ゴールを明確にし、彼らのモチベーションを高めるだけでなく、さまざまな提案を引き出すこともできるかもしれません。

要件をできるだけ詳細に整理

要件をできるだけ細かく確認しておくことも、キックオフミーティングでは重要です。
これは今回のプロジェクトの作業内容を確認するという意味もありますが、先ほども述べたような目的に対する手段の誤りを早い段階で知るためにも重要な作業です。
ITプロジェクトでは、組織外のベンダーからのプレゼンを受け、その内容をもとにプロジェクトを進めていくことが多いですが、プレゼンの内容にこだわりすぎず、別の対応をとりいれる柔軟性をもちながら、要件を詰めていくことが大事です。
プロジェクトは段階的詳細化、つまり「プロジェクトの進行とともに細かな内容がはっきりしていく」という性質があるため、キックオフミーティングの時点ですべての要件に対し、詳細な対応方針を明らかにすることはできませんが、キックオフミーティングが終わった後、プロジェクトの作業範囲がある程度定まり、作業の工数の見積もりが行え、具体的なスケジュールが作成できる、という状態を目標にしていきましょう。

プロジェクトの体制を確認する

キックオフミーティングは初回のミーティングであるため、プロジェクト・メンバーの自己紹介が行われるのが常です。
より充実したミーティングにするために、キックオフミーティングのタイミングで各メンバーが「何をするのか?」「どのような役割を担っているのか?」も明確にしておいたほうがよいでしょう。
さらに、 指揮伝達 ・情報伝達の流れも含め、プロジェクト体制を明確にし、プロジェクト・メンバー間のコミュニケーションを円滑にしていきます。
プロジェクトの体制が明確になっていると、コミュニケーションが楽になるだけでなく、必要のないメンバーはミーティングに出席しなくともよいとすることで、ミーティングの効率化につなげることもできます。
例えば、全くデザインの議題がないミーティングにデザイン担当のメンバーが出席したとしても時間の無駄ですし、下手に気を利かせてわからない議題に口をはさむと、話がややこしくなってしまうこともあります。
こうした非効率的なミーティングを回避するために、早々にプロジェクトの体制を整理し、次回以降どの会議に誰が出席するのかを明らかにしておくとよいでしょう。

不安材料は忌憚なく話す

キックオフミーティングでは、プロジェクトに対して抱いている不安材料について忌憚なく話し合うことも大切です。
例えば発注側・ユーザー側のメンバーに「現在困っていることは何か?」「過去にどのような失敗があったか」「今回のプロジェクトで難しいと思っていることは何か?」を確認しておくとよいでしょう[1]深沢 隆司『ベースラインで成功する プロジェクトマネジメント』日本実業出版社、2008年、161~163頁。。これらの情報は、後々のリスク・マネジメントの計画を考えていく上で、重要な情報になります。
また、制作側・ベンダー側においても、プログラマーやデザイナーなどの作業を行うメンバーが感じている不安も汲み取っておくことも大切です。
例えば、「お客さんの依頼している方法でも対応可能だけれども、陳腐化した技術なので、別の対応をとりたい」「参考として提示されているWebデザインが古い」というような意見があれば、それらの内容も議論しておくとよいでしょう。
達成すべきプロジェクトの目的から外れてしまうことは避けねばなりませんが、実際に作業するメンバーの意見を汲んで、よりよい成果物を目指していくことが大切です。

キックオフミーティングを有意義なものにするために準備すべきこと

キックオフミーティングを、有意義なものにするために、進行を助けるいくつかの資料を準備しておくとよいでしょう。
例えば、草案レベルであっても以下のような資料があれば、より具体的にプロジェクトの内容を検討することができます。

  • 要件定義書
  • スケジュール
  • プロジェクト体制図
  • 不安材料リスト

要件定義書

要件定義書とは、今回のプロジェクトで「何をするのか?」「何をつくるのか?」をまとめた文書です。
要件定義書は顧客やユーザー、依頼者の要求事項を踏まえ、要求の重複を除去し、不足している内容を追加し、システムに盛り込む機能や条件を整理して作成していきます[2]飯村結香子 (著)、大森 久美子 (著)、西原 琢夫 (著)、川添 雄彦 (監修)『ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版 … Continue reading
この要件定義書があれば、開発側・ベンダー側が「何をしようとしているのか?」が明示されるため、依頼者側と開発側で完成品のイメージが大きくずれるということがなくなります。
また草案の段階であっても、この要件定義書がキックオフミーティングの場にあれば要件の整理をスムーズに行うことができます。

スケジュール

プロジェクトの不安材料を洗い出すために、キックオフミーティングでは「現段階で想定している」スケジュールを用意しておくとよいでしょう。
スケジュールは全体の流れを確認するために使用することもできますが、スケジュールをたたき台にし、プロジェクトの中の不安材料・懸念事項をあぶりだすことができます。
例えばプロジェクト・チームでスケジュールを確認していくと、「うちの広報部は確認に時間をかけるから、この確認期間じゃ進まないよ」「この期間は会社の繁忙期だから、ここまでタスクを詰められると対応できないかも」というような意見がでてくることがあります。
こうした声をまとめていくことで、事前にプロジェクトのトラブルに対処することができます。

プロジェクト体制図

プロジェクト体制図の例のイメージ

プロジェクトの体制を確認するためにも、キックオフミーティングで現段階でわかっているプロジェクト体制図を作成しておくとよいでしょう。
上記に簡単なプロジェクト体制図の例を掲載しましたが、このように、どのような人物が参加し、どのような情報伝達の経路を持っているのかを図解しておくと、各メンバーのプロジェクトの役割がはっきりしていきます。

不安材料リスト

プロジェクトにはさまざまなリスクが潜んでいます。それらのリスクに対処できなければ、プロジェクトは失敗してしまいます。
このリスクの予兆が、プロジェクト・メンバーが感じている不安材料です。
「プロジェクトが佳境になるこの時期はリソースが足らなくなる」
「要望の内容が不明瞭で、プロジェクト・メンバー間の認識が異なっている気がする」
こうした不安材料はプロジェクトが始まってしまうと、なかなか話し合う機会がありません。
そのため、不安材料をリスト化し、キックオフミーティングの中でプロジェクト・メンバーと検討するとよいでしょう。

おわりに

今回はキックオフミーティングの内容と目的、進行の仕方を解説していきました。
キックオフミーティングはプロジェクト・チームの足並みをそろえるために開催されるミーティングです。
進行する際には、「プロジェクトの背景」「要件」「プロジェクトの体制」「不安材料」について話し合うとよいでしょう。そして、その話し合いをより充実させるため、草案レベルでもかまわないので「要件定義書」「スケジュール」「プロジェクト体制図」を作成していくと、より詳しくプロジェクトの中身を検討していくことができます。

1深沢 隆司『ベースラインで成功する プロジェクトマネジメント』日本実業出版社、2008年、161~163頁。
2飯村結香子 (著)、大森 久美子 (著)、西原 琢夫 (著)、川添 雄彦 (監修)『ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版 エンジニアになったら押さえておきたい基礎知識』翔泳社、2018年、63頁。