はじめに
これまではオンサイトな開発がメインだった企業やチームにとって、
リモートも選択肢の一つになってきていますね。
ハイブリッドな進め方がこれから主流になってくると思っています。
とはいえ、これまで当たり前だった知識やノウハウがなくなるわけでもなく、
ハイブリッドな時代に何を残していくかが重要になるのかな、と思っております。
ここではプロジェクトコントロールのナレッジの一つであるキックオフについて、
あらためてのポイントを振り返っておきたいと思います。
※この記事はSalesforce 開発者向けブログ投稿キャンペーンへのエントリー記事です。
これ↓
https://developer.salesforce.com/jpblogs/2020/05/developer-blog-campaign/
なぜキックオフをやるのか
端的に言えば、この2点に尽きると思っています。
- 目的・使命の共有
- リスクの共有
プロジェクトにはトラブルがつきものなので、
目線を合わせてチームで対処できるようにする。
かつ、起きそうなリスクについて、対処の仕方を整えておく。
プロジェクトとは「1回限り」の活動であることから、
いつもの環境や秩序とは全く異なるケースがほとんどです。
どんな状態でもトラブルに対処できるようにしておく必要があります。
チームが完成されていてしかも作り物がほとんど見えていて、何もコミュニケーションを取らずとも
高い凝集度で結合度合いの低いプロダクトが自律的に作れるならば良いかもしれません。
そうでなければ、キックオフは「可能な限り省かない」がベストだと思います。
キックオフを設計しないことで起きる、よくあるトラブル
キックオフを省いたプロジェクトでは、しばしばトラブルが起きがちです。
たとえば
- 開発スタートしたものの、作業や成果物がばらばらに動いてしまい、まとまらない
- 事前に備えておくべきだったリスクが後になって判明して、リカバリーの手間が増える
- スケジュールや体制、リスクの全体観のイメージが掴めず、プロジェクトそのものに不安を生じさせてしまう
などなど。
本当はキックオフまでに情報を整理しておかないといけなかったのに、
前回提示した資料でそのままミーティングに臨んでお客様に叱られてしまう、というケースも何度か見たことがあります。。
プロジェクト初期段階において、不安を生じさせてしまう点については、
プロジェクトコントロール・アカウントコントロール両面で後々まで禍根を残してしまいます。
極力きれいなスタートを切りたいところです。
キックオフミーティングの設計の仕方
プロジェクト憲章と言われるものを作ることがあります。
キックオフで確認すべき5W1Hはそれそのものではありませんが、構成要素はおおむねプロジェクト憲章と近いはず。
つまり、少し概念的ですが、だいたい以下がカバーできた状態で臨めれば良いかと思います。
さらにここからキックオフ資料の台割をして、ページごとに資料を作っていきます。
たとえばマイルストーンやスケジュールは全体の矢羽工程図を引いたりカレンダーでのセッションスケジュールを書いたり、コミュニケーションプランでは連絡網や各種会議体を表にしたりリスク管理について RiskBreakdownStructure で分解してリスク試算したり、など。
規模やかけられる準備期間によって粒度は調整します。
アジェンダの作り方
資料のイメージがついたらミーティングの会議設計をします。
ここはwikiやQuipでテンプレートを作っておきましょう。
テンプレート例
こんな感じ。
| 項目 | 書くこと |
|---|---|
| 概要 | 開催日や場所、参加者などを記載 |
| 資料 | 当日利用する資料の一覧をあとから参照できるようにする |
| ゴール | このキックオフが完了したときにどうなっていたいかを記載する |
| アジェンダ | キックオフで話すテーマの一覧。資料のアジェンダと同一になる場合もあるし、資料に書くほどでもない単純な連絡・協議事項がある場合はこちらのアジェンダが全量になる |
| 論点 | 判断すべき事項の一覧。忙しい方が最悪ここだけ聞いて判断すれば離脱できるようにコンテンツから判断ポイントを抽出する（できれば推奨案も合わせて提示） |
| 決定事項 | 当日決まったことを記載する（後日追記） |
| 次回予定 | 次のミーティングの予定を書く（予定はできるだけ当日おさえてしまう） |
| TODO | 当日宿題になったこと、あるいは会議をして宿題になるであろうアクションアイテムをステークホルダーごとに書く |
普段の会議アジェンダ設計と基本形は同じです。
チームや社内でテンプレート化しておくと良いでしょう。
段取りに関するヒント
会議設計まで出来たら、最後にスケジュールを決めて動きます。
ポイントは逆算すること。
たとえば
07/15 キックオフ当日
だとしたら、2週間前くらいから取り組みをスタートさせます。
07/01 事前の内部目線合わせミーティング＆資料作成開始
07/03 1stレビュー だいたい50%くらいのクオリティ
07/10 2ndレビュー だいたい80%くらいのクオリティ
07/14 最終レビュー 99%くらいのクオリティ
前半が大変なのですが、ギリギリでやるよりも事前の想定質問や重要ポイントなどをしっかり潰せると思います。
なお、資料は開催するまでに送付しておくようにしましょう。
QuipかBacklog wikiにアジェンダと資料をアップしておくなど、
本番想定で準備しておくのがベター。
準備にあたって避けたい「追い込み型」
なにかとギリギリで間に合わせるケースも見かけますが、
それでなんとかなってしまうと、
その後のプロジェクトも追い込み型になってしまい、
調整に時間のかかるタスクの品質が下がってしまいがち。
このパターンは、規模が大きくなるに従ってどこかで破綻します。
プロジェクト成功＝ 着地 をさせるのがプロジェクトマネージャの仕事ですが、
そもそも計画段階では 着地の仕方 にもこだわるべきでしょう。
よりよいプロジェクトコントロールのテクニック
プラスアルファとしては、以下がおすすめです。
受注〜開発をスムーズにさせるのがキックオフの効果なのであれば、
営業提案時点でキックオフ資料を含めてしまう
営業時の提案資料の5W1H+Benefitに、デリバリーでの増分コンテンツも含めてしまう方法です。
※受託開発のイメージで書いてます
提案書の構成イメージ
＜提案書の主旨となるコンテンツ＞
○提案骨子
○提案の全体像
○システム実現イメージ（アーキテクチャ）
○開発上のポイント
○想定機能・画面
○想定作業内容
○スケジュール
○体制図
○見積・見積条件
などなど
＜合わせてデリバリーのコンテンツも追記する＞
○要件定義の主要テーマ
○テーマとセッションスケジュール
○キックオフまでの各種依頼事項
○コミュニケーションプラン・会議体
○リスク管理方法
などなど
前のめりになる分、セリングの資料としてボリュームが増えてしまいますが、
スタートしてからのイメージがつきやすいので、
受け手の安心感に繋がります。
準備の手間で見ても、トータルでの負荷も少なくなります。
セリングとデリバリーでチームが分かれているときは、
両者が継ぎ目なくコミュニケーションできるようにツールで縛るのが良いでしょう。
QuipやSlackで営業プロセスや受注に関するメモ、資料などをストックして、
デリバリーのメンバーを早めにQuipドキュメントやSlack channelに招待しておくと良いでしょう。
Quipのドキュメントに営業のメモを貯めていくと、
あとで決定の経緯を追えたり、プロジェクトのキーマンを特定しやすかったり、
ドキュメントそのものがキックオフの重要なインプットになります。
Quipなんぞやという方はTrailheadを見たり、
エヴァンジェリストの呉縞さんにお話を聞いてみましょう。
発展型として、 Salesforce Anywhere については、
2020年7月ベータ〜今年第4四半期GAになるらしいです。（ふむふむ）
そのときにはまたQuipと合わせて新しい時代のコラボレーションの仕方が論じられることでしょう。
Introducing Salesforce Anywhere: Technology Enabling the All-Digital, Work-From-Anywhere World
Salesforceプロジェクトで考えたとき
Salesforceプロジェクトも規模や特性がさまざまなので
ピュアなCRM/SFAから始めた組織やエンジニアが、
規模拡大に伴ってどこかでやはりプロジェクトマネジメント的な要素を求められるタイミングが来ます。
Salesforceプロジェクトの案件特性の例としては...
①ピュアなCRM/SFA導入など、いわゆる製品の標準導入もの
②マルチクラウドもの e.g. SF&Heroku, SF&AWS&GCP, CRM&MA&BI&Commerceなど
③移行プロジェクト（組織移行やデータ移行、ベンダー変更など）
④業務システムも含む複雑なシステム統合
⑤PoC（IoTやAI、Commerceなど）
⑥AppExchangeへの上市を目指した製品開発
⑦これらの組み合わせ（全部入り）
大きく分けるとこんなイメージ。
たまにPoCで単発プロジェクトとか、セールスデモアプリ構築とか短めのスパンで一気に作るプロジェクトもありますね。
ただ、Salesforceプロダクトはライセンスをベースに基本的には長く使うサービスであることから、
そのプロジェクトがこれらのどんな特性であってもやはりプロジェクトとしての目線をあわせる必要は出てくるはず。
そもそもスクラッチ開発の5人月がSalesforceだと1人月で済む、25人月が10人月で済む、
100人月が25人月で済むようなレバレッジが効きやすい製品であることから、
規模の多寡によらず勘所を外さない意識付けが求められるでしょう。
まとめ
キックオフ大事。
Salesforceプロジェクトでもキックオフは省かずに必ずセットしよう。
参考として読むべきTrailhead
テーマはLEXだったりB2CCに寄った部分もあるけど内容は非常に整理されていておすすめ。