はじめに

Scrumで言うスプリント0とか、実際にプロジェクトが始まる前にやる準備活動をイメージしてます。

達成すべき事に対して、どうやって進めれば良いか、何をクリアしないといけないかが明確には見えないものがある状況で、プロジェクトはスタートするものです。
でも、何も準備なしにスタートするのはとても怖い。丸投げ反対。
どんな結果を期待して活動すれば良いのか、どんな人たち（社内外問わず）と、どんな風に問題をクリアしていきながら日々過ごすことになるのか、そういうものが見えると動きやすくなります。

そういうときのために"インセプションデッキ"というとっても良いものがあるので、それを使うのも良いと思います。

また、ryuzeeさんのアジャイル開発プロジェクトのはじめ方もとても参考になります。(他にもたくさんためになる発表資料があり、すごくお世話になってます)

ただ、いわゆるウォーターフォール的な感じで自分はこれまでやってきたころがあって（システム開発ではないのだけど）、その際に企業間での契約的な取り決めを行わないといけなかったりしました。
そうするとインセプションデッキだけでは足らないところもあり、プロジェクトスタートの準備にこんなことをやってきたなー、というのを残しておこうというのが趣旨です。
（インセプションデッキと重なるところもあります）

キックオフの前に、関係者で検討するイメージです。
（プリセールスとキックオフの間？）

いつも必ず、すべての項目をやってきたわけではないですし、他にやった方が良いこともあるかもしれないので、そのあたりはご意見ご感想いただけると嬉しいです。

やるといいこと

プロジェクトの関係者（自社メンバーだけでなくお客さんとか含む）で下記のことを検討してました。

検討項目

主な活動指針について

到達点（成果物、デモ、利用機能、KPI、活動背景、etc）
期間
優先事項の調整と決定方針
役割分担とプロセス(体制と伝達、組織とタスクの切り分けと結合点）

不確定事項への対応

調整方針
成果物のレベル感

活動条件について

共有情報（前提事項、免責事項、懸念事項、etc）
会議体や作業場
経費発生時の取扱い（購買プロセスと資産管理をどうするか、互いのやりかたのどちらに合わせるか、など）
種々のルール（メールの件名、ファイルの共有方法、課題管理、etc)

検討の時に意識してきたこと

ほぼポエム。
上記の検討項目は何を意識してまとめてくかを書いてます。

だいじなこと
到達点を検討し、自分たちがその期間内であきらかにすべきこと、生み出すものは何で、どうやって作るのか、現時点で不明確なこと/不安なこと/調査が必要なことは何かを表出しておく。
これが絶対に正しい、というものではなくて、変更もあるけど、スタートするためにお互いに学習や調査するアクションが見えている事が大事です。

また、プロジェクト活動中、調査・研究的な側面が必ず発生するし、具体的な成果物を事前に明確に定義しきれないのは当然です。プロジェクトは絶えず変化します。なので、活動前はモヤモヤしていた成果物も、活動が進むと目的に応じた必要なモノ・コトが見えてくるので、そのタイミングで具体化していきましょう。

でも残された時間で’当初想定していたもの’の納品が難しい場合もあるよね、という共通認識で進められる人たちが集まれていないと、人や企業の力関係によってはとても困ったことになるかもしれないです。

なので少なくとも、影響力の大きい人が、無理を押し通す無駄の発生源になる可能性については、アンテナを張っておいて損はないと思います。
現場のメンバー達が、変化を受け入れて、大事なところにフォーカスを移そうとしても、鶴の一声で元の木阿弥になるのが一番やっかいです。

<そういうだめな例>
事前に定義した名前のドキュメントかどうかが、成果物の評価指標として重要視される状況下で起こります。
誰の何のために使われるのか不明なままあらかじめドキュメント名だけが明示されていたものが、活動終期になるころに、これまでの活動実績として必要かどうか、今後の活動に有用かどうかではなく、その名前に即した中身かどうかでドキュメントが評され、幾度となく作り直しとなったりする。
「俺が認めた○○という名のドキュメントはそれじゃない」というような人どうしがぶつかりあって、かつ、そのドキュメント名がプロジェクトの活動に結びつかない結果となっていて、そのドキュメントに対する要求を明確にすることができないために二転三転していき、得てしてドキュメントは肥大化する。
（不幸にもこういうプロジェクトの途中から入った時にどう振る舞うのが良いのか、も検討の余地あるかも。良い方法が浮かんでるわけではないけど）

路頭に迷わないために
どれだけ準備をしても、不測の事態は起こるものです。活動する期間が半年以上とか、長期のものになるのであればなおさら。
どうやってプロジェクトとして皆で乗り越えていくのか、優先事項についてその調整方法や決定方針、役割分担とプロセスのイメージを共有しておくと良いと思います。

プロジェクト中は、次のアクションは何か決めて、何がアクションのスタートのトリガーになるのか、あるいはアクション（タスク）の終了条件は何か、というようなやりとりが次々に発生します。
そういったやりとりがスムーズにできるように、かつ個人のタスクを進めるのにちょっとした判断がしやすくなるように、検討項目について意見交換をしておきます。
特に役割分担については、活動していく中で明確になっていくことや、新たな役割が必要になることもあるので、いまわかっていることでどんな役割が必要そうか、話しておきましょう。
もちろん、準備時に決めたことは不文律ではないので、それもプロジェクトの関係者で共有しておきます。

会社間の契約だからね
前提条件や免責事項は、互いの責任範囲を明確にして、問題解決に注力するのに大事です。
ボールの投げ合い、言った言わないの水掛け論は珍しいことではありません。

やらないことリストも上げておくと良いです。
あいまいさを軽減できます。

限られた期間の中で誰が何に注力するのか、互いの背景やスキルなどをフラットにして、不足しているところを努力して向上するのか、外にお願いするのか、完全にやらないのか、などを整理して共有できると、日々の活動が自律的でうまく回りやすくなります。

「プロジェクト実施中に発生した問題に向かい合い、解決していく姿勢づくりのために、その準備をしているところです」という事が認識し合えているか、検討を重ねると見えてきたりします。
（でも、これをきっちりやろうとし過ぎて、プロジェクトのスタート前にもめてスタートが遅くなり、でも期限は伸びずで、プロジェクト期間が短くなってしまうなんてことも、考えられなくはない。バランスや言葉使いなどむずかしいところ）

おわりに

契約的な面だけで言えば、いわゆる請負か準委任か、みたいな話に終始するかもしれません。
でも、実際に現場に入ってなんとか互いに課題をクリアしていくメンバーとして、スタート前には誰も予想できなかったけれど、目的達成のためにはその問題解決が重要って時に、言った言わない問答で組織の責任者との対決が発生しちゃうとか、理解するのが大変な重厚長大なドキュメントに時間を割いている状況とか、すげーもったいないよね、ってので書いてみました。

ほぼポエムになってしまった。（ブログ案件？）

プロジェクトの振る舞いについて、あれやると良い、これやったらうまくいかない、みたいなのはわりと情報を見つけられるけど、なんでそれが良いのか、って背景的なものも含めて自分になじむまでには、しっかりした勉強が必要だったり、経験がないとなかなかわからないところはあると思うし、ここでの内容がその橋渡しぐらいになれば嬉しい。

自分もまだまだなじんでないので、少なくとも未来の自分のためにはなるか。