こんにちは、poipoiです。

「テクニカルディレクター目線のプロジェクトマネージメント手法」
を考えてみる記事。

今回は、体験展示の運用保守についてフローチャートで考えてみよう、というお話。

実際のプロジェクトにどう適用するか

前回、体験展示の運用保守契約を検討する際にポイントとなりそうな各要素についてピックアップして、それぞれについて考えてみました。

ただ、これはいろいろな要素を羅列してあるだけなので、じゃあ実際に運用保守契約を結ぼうとした場合に何から考え始めたらよいのかというのが直感的にわかりづらい内容でした。

そこで今回は実際の契約を検討する際の判断指標になるようなフローチャートを考えてみました。

あくまで私が普段頭の中で考えているものを図示しただけなので絶対的な指標ではありません。このフローチャートをたたき台にしつつ、実際にはクライアントと協議しながら定めるのが良いでしょう。

運用保守検討フローチャート

判断ポイントは以下の３つです。

展示期間
イベント等の数日間のみの展示か。常設など長期にわたる展示か。

稼働停止が許されるか
テーマパークや有料チケット制のイベント等、故障等による稼働停止が許されない展示か。もしくは多少の停止期間が許される展示か。

駆動部品・要メンテ部品が含まれるか
システム内に駆動部品やその他の要定期メンテな部品が含まれているかどうか。

それぞれの判断ポイントの内容によって、結ぶべき契約内容が変わってきます。
以降、それぞれの内容について詳しく見ていきます。

①自前オペレーション

展示期間が短く、特別にオペレータを用意せず制作サイドが自らオペレーションも行う場合。

この場合、運用保守契約は特に結ばずその代わり開発費用のなかにオペレーション費用まで含めて見積もります。
瑕疵への対応期間も展示期間中のみになりますので特段取り決めをしなくてもよいかと思います。

開発費用に関して
こちら側でオペレーションする必要があるためそれにかかる項目をそれぞれ見積もりに追加する必要があります。
・設営費用
・立ち合い、オペレーション費用
・撤収費用
それぞれ 日数 x 人数 x 単価 で見積もるとよいでしょう。

またイベント側が別途オペレータを用意し、その方たちがオペレーションを行う事もあります。
その場合、システムに詳しくない人間が触ることになるため
・運用の自動化機能の入れ込み
・管理画面の作りこみ
・マニュアル制作
などの工数についても見積もりに盛り込む必要があります。

②綿密運用

テーマパーク、有料イベントなどではお客様との間に金銭のやり取りが発生します。そのため突然の故障や、修理まで数日動きません、というような状況が許されない場合が多いです。
そのため開発に盛り込む項目や運用保守契約なども細かく取り決めをしておく必要があります。

開発費用に関して
以下を開発時に盛り込む必要があります。

・バックアップ機材
バックアップ用機材をあらかじめシステムに組み込んでおき、現地スタッフでも入れ替え可能な環境にしておく。

・余剰部品
余剰部品を用意しストックしておき、いつでも交換が可能なようにしておく。

・運用保守用機能
自己メンテナンス機能、遠隔監視機能など、運用保守に必要な機能を盛り込んでおき、万が一の場合にもすばやく復旧できるようにしておく。

・瑕疵対応期間
展示の性質やクライアントからの要望から鑑みて数か月～１年程度の対応期間を設けます。この期間の不具対応については検証費用と考えて盛り込んでおきます。

これらにかかる費用を見積もりにあらかじめ乗せておく必要があります。

運用保守契約に関して
瑕疵対応期間終了後は、運用保守契約にてメンテナンスや不具合への対応を行う事になります。
契約内容に以下の条件を盛り込んでおき、頻度などから換算して金額を決定します。

・不具合連絡への対応条件
〇日以内に第一報の返答。〇日以内に調査対応、など

・定期メンテナンス条件
〇か月に１回のメンテナンス、など

・オペレーションミスなど先方起因の問題への対応
発生するものとして、一定額を費用として乗せておく

・軽微な機能修正、追加への対応
一定額乗せておくと安心です

これらの条件をもとに定期メンテナンス契約としてまとめて、期間契約を結ぶのが望ましいです。

最後の「軽微な機能修正・追加への対応」については一概に必ず乗せるべき項目というわけではありませんが、長期展示だと要望がでる場合が多いのも事実です。
このようにあらかじめ定額の費用として乗せておくか、別途費用がかかる旨を事前に握っておくのが望ましと思います。

③定期メンテ

万が一の故障時など、復旧までに多少の日数がかかってもよい場合で、かつ可動部品などの定期的にメンテナンスが必要な項目が含まれる場合です。

こちらは、開発および運用保守契約の項目は②とほぼ同様です。

ただし、バックアップ機材や余剰部品の用意数、運用保守用機能の作りこみ度合い、不具合連絡への対応条件などの各種条件を②に比べてある程度ゆるめ、費用感も抑えめにしていくことになります。

クライアントさん側としては②と同様に万全を期した対応を求めてくる場合もありますが、フル項目を入れ込むと開発費や運用保守費用が相当跳ね上がるので予算にはまらないことが多いです。

まずは②の状態のざっくり見積もりを出しつつ、それをクライアントさんと眺めながらどの程度までは譲歩できるかを話し合い、最終的な項目を決めていくのがスムーズかもしれません。

④都度メンテ

復旧までに多少の日数がかかってもよい場合で、かつある程度安定的に稼働するため、不具合発生時のスポット対応のみでよい場合です。

開発費用に関して
項目や条件については②、③と同様の内容で大丈夫かと思います。
ただし各項目の条件については、定期メンテナンスを行わないため、③よりは堅牢にしておく方が無難です。
こちらも各条件についてはクライアントと協議の上、どの程度盛り込むべきかを決定していきます。

運用保守契約に関して
運用保守契約については特に結ばず、不具合が発生した際にその都度対応し、かかった実工数を請求する形にします。

ただし、以下の条件については事前に取り決めをしておく方が安心です。

・定期メンテ頻度
都度費用請求ではありますが年に１度など定期的にメンテナンスする方が安心です。

・不具合連絡への対応条件
〇日以内に返答、〇日以内に調査対応など。また急を要する対応については特急対応料金が発生する旨などをあらかじめ握っておくとよいです。

・部品や図面などの保管期間
常設の場合展示期間が非常に長期にわたる場合もあるため、あらかじめいつまで部品等を保管しておく必要があるか取り決めておく方が無難です。あまりにも長期間の保管が必要な場合は別途その保管費用の請求も検討すべきです。

と、今回もだいぶ長くなってしまいました。
今回の内容に関しても例にもれず、あくまで参考例です。
あまり詳細の内容に縛られすぎず、クライアントさんとの関係性の中で柔軟に契約を定めていくことが望ましいかと思います。

ということで運用保守契約のフローチャートでした。
今回はこのへんで。