リスクマネジメントを積極的に使い倒す
プロジェクトのリスクについてどのような対策をしているか、と友人のデザイナーや制作会社に聞くと「見積もりの備考欄に細かく書く」というケースが結構多い。そこで「それってちゃんとクライアントに見てもらえているかな? 」と突っ込んで聞いてみると「そこまではわからないかな。」とか「まあ見てないかもねー。」という返答も案外多かった。そう、特にWebデザインにおいては公開後の調整も可能なためか、天候や素材調達に影響されないためか、プロジェクトのリスクが大きな問題に(裁判沙汰になるとか)なることがあまりないためか、しっかりとリスク管理されていることは多くないように思う。
昨年まで僕が所属していたロフトワークではプロジェクト毎にPMBOKをベースにした「プロジェクトマネジメント計画書」を作成するというルールがある。そして、リスクマネジメントはその中の大項目の1つだ。想定されうるリスクについて洗い出し、プロジェクトの初期段階からクライアントともリスクを共有しておくためのもの。ここではリスクを積極的に回避するためというよりは「リスクとしてあげられるようなコトが起きたときに慌てず対処する」ため。いわば避難訓練マニュアルのように、災害(リスク)が起きたらどう行動するかを記したものとすることが多かった。
しかし最近になってリスクマネジメントはもっと使い倒せることに気づいてきた。プロジェクトマネージャーが積極的にリスクマネジメントを行うことで、プロジェクトにマイナスの影響を与えうることを確実に減らすことができる。
そこで下記に私たちが実際のプロジェクトで、どのようなリスクマネジメントを行い、クライアントへ提案・実施しているか、いくつか代表的なものをまとめてみます。
リスク:各部署ごとの個別要望が後からでてくるため設計やデザインのやり直しが何度も起こる。
解決案1:プロジェクトスタートの段階で、各部署に対して現状の不満点やリニューアルに対する期待をヒアリングする。ヒアリングはインタビューシートやアンケートフォームを作成し回答をもらう形で行う。
解決案2:設計後の各部署からの個別要望は受け付けない。スケジュール・コストを優先させるためデザイン着手後の変更を行うバッファがない。要望がある場合は設計提案の段階を最終とする。
リスク:プロジェクトメンバーが集えるタイミングが少なく情報共有がスムーズにいかない。
解決案1:プロジェクトコアメンバーを5名以内に限定し、コアメンバーのスケジュールを最優先してMTG日時の調整を行う。なおMTGで協議された内容は各所属先のメンバーが次回MTGまでにそれぞれの所属先で共有を行うものとする。
解決案2:MTGを毎週定例とし曜日と時間を決定する。定例MTGに参加できないメンバーがいる場合でもMTGを行うことを優先とする。なおMTGで協議された内容は各所属先のメンバーが次回MTGまでにそれぞれの所属先で共有を行うものとする。
リスク:作業範囲の認識にズレがあり、これもやってくれると思っていたという話が後から出てくる。
解決案1:作業範囲で行われるタスクおよび要素成果物をすべて箇条書きで書き出し事前に確認する。成果物については共有方法や拡張子も合わせて記載する。特にデザインデータの拡張子については契約内容およびコストに大きな影響があるため漏れなく確認するようにする。
解決案2:解決案1で記載した作業内容に追加・変更がある場合は「設計・デザイン」「機能・設定」「原稿・写真・コンテンツ」のどこに影響があるのかを検討した上でコスト・スケジュールの調整を行う。
リスク:デザインのイメージが擦り合わずFIXできない。
解決案1:デザイン着手前にインタビューの機会を設け、プロジェクトメンバーおよびデザイン承認者の方の意見を聞く。インタビュー内容は「コンセプトシート」にまとめ、解釈に相違がないかデザイン提案前に確認をする。なお、例として「未来的なデザイン」を目指すとした場合、「未来的とはどのようなものか」についてインタビューでは掘りさげる必要がある。
解決案2:デザイン着手前にワークショップの機会を設け、プロジェクトメンバーおよびデザイン承認者の意見を発散・収束するようにする。ワークショップを通じてコンセプトをまとめ共通理解として確認をする。
リスク:最終承認時にプロジェクトオーナーより変更要望またはNGがあり予定通りの公開ができなくなる。
解決案1:デザイン提案時にプロジェクトオーナーへ直接プレゼンする機会を設ける。またプロジェクトのマイルストーンで適時共有をしていただくことで段階的に合意を重ねるように進める。
解決案2:スケジュール・コストに大きな影響が出る場合は、公開後の対応とし、公開スケジュールを優先しプロジェクトを進める。
●リスクマネジメントを積極的に行うとクライアント理解は深まる。
リスクマネジメントを積極的に行うことは、プロジェクトを開いたり、深めたりすることだと思います。プロジェクトメンバー以外の人の話を聞きにいったり、まだもやもやとしている理想のすがたの「もやもや」に一緒に入っていったりと。それは結果的にクライアントへの深い理解や、プロジェクトの背景にある企業文化やユーザー文脈への正しい認識へとつながっていきます。そして意外にも、リスクについて考えるのは、なんだか楽しい。
ここでは私たちが普段行っているリスクマネジメントの代表的なものをいくつかまとめましたが、他にも「こんなリスクマネジメントやってるよ」という実践的なものがあればぜひ教えてください。
🤫
この記事が気に入ったらサポートをしてみませんか?