システムを作ったあと、誰が運用するのか決めていますか
業務システムの相談を受けるとき、話題の中心になるのはたいてい「何を作るか」です。どんな機能が必要か、いつまでに欲しいか、いくらかかるか。
一方で、納品したあとの話は後回しになりがちです。 「作って終わりではない」ということ自体は、たいていの方が分かっています。ただ、具体的に誰が何をするかまで決まっていることは、あまり多くありません。
ここが決まっていないと、動き出してから困ります。
納品後に、必ず起きること
システムは、納品した状態のまま静かに動き続けてはくれません。放っておいても、次のようなことが起きます。
動かなくなる
サーバーやサービスの都合、証明書の期限切れ、利用しているソフトウェアの更新。こちらが何もしていなくても、外側の事情で止まることがあります。
変えたくなる
制度が変わった、取引先が増えた、業務のやり方を見直した。使われているシステムほど、変更の要望が出ます。 変更が出ないシステムは、たいてい使われていません。
担当者が変わる
導入時に中心になっていた方が、異動や退職でいなくなる。引き継ぎができていないと、誰も全体像を知らない状態になります。
データが増えて重くなる
運用開始時は快適でも、数年分たまると動作が遅くなることがあります。
これらは事故ではなく、時間が経てば普通に起きることです。だから先に決めておく価値があります。
決めておきたい4つのこと
難しい取り決めは要りません。この4つが決まっていれば、たいていのことは回ります。
① 社内で、最初に相談を受ける人は誰か
システムに何かあったとき、現場の人が最初に声をかける相手です。この人が技術に詳しい必要はありません。「困ったらこの人に言う」が決まっていることが大事で、決まっていないと、それぞれが別のところに連絡して話が混ざります。
② どこまでを社内でやり、どこからを外に頼むか
たとえば「利用者の追加や権限の変更は社内、それ以外は開発会社」といった線引きです。ここが曖昧だと、小さな変更のたびに見積もりを取ることになり、かえって手間が増えます。
③ 連絡手段と、どのくらいで返ってくるか
メールなのか、チャットなのか。急ぎのときはどうするのか。「翌営業日までに一次返信」程度の目安でも、あるとないとでは現場の安心感がまったく違います。
④ 費用の形
月額で決めておくのか、発生したときに都度見積もりにするのか。変更の頻度によって向き不向きがあります。あまり変更が発生しない見込みなら、都度払いのほうが安く済みます。 逆に、頻繁に手が入るものは月額にしたほうが結果的に安くなることが多いです。
「作った会社が運用する」とは限りません
これは意外と知られていないのですが、開発した会社と、運用する会社が別でも構いません。
社内に対応できる方がいるなら社内でもよいですし、開発は開発会社、運用は別の会社という形もあります。
ただし分ける場合は、引き継ぎのための資料が必要になります。構成がどうなっているか、どこに何があるか、変更するときにどこを触るか。これは開発が終わってから作ろうとすると大変なので、作っている最中に用意しておくものです。
実際に、何を残しているか
先日納品した案件では、次のような資料を成果物として揃えました。画面が20枚ほど、データベースのテーブルが90本近くある規模のシステムです。
- 機能一覧
- 画面仕様書
- DB設計書、ER図
- API一覧
- バッチ処理仕様書
- 使用ライブラリ一覧
- サーバー環境の設定値一覧
- テスト結果の報告書
このうち「使用ライブラリ一覧」と「サーバー環境の設定値一覧」は、忘れられやすいのに、あとから一番困る資料です。 どのバージョンで動いているか、どういう設定で構築されているか。これが残っていないと、次に触る人は動いているものを解析するところから始めることになります。
操作マニュアルについては、文書ではなく動画にしてシステムの画面から直接見られるようにしました。 紙のマニュアルは、たいてい誰も開きません。担当者が変わったときに、その場で見られる形になっているほうが実際に使われます。
もうひとつ、古いシステムのデータを閲覧するためだけの専用ページを、別途用意しました。 入れ替えのときは「前のシステムに入っていた過去のデータをどうするか」が必ず問題になります。全部を新しいシステムに移すと構造が歪むので、参照できれば十分なものは、見るための場所を分けて用意するという選択肢があります。
「あとで運用を誰かに任せるかもしれない」と思っているなら、その前提を最初に伝えておいてください。 作り方と残す資料が変わります。
開発中にやっておくと、運用が楽になること
納品後に困らないために、作っている段階でできることがあります。
変更履歴が残るようにしておく
誰がいつ何を変えたか。金額や契約に関わるデータでは、あとから必ず必要になります。
権限を見直す前提で作っておく
人事異動のたびに権限を変えることになります。担当者が自分で変更できる形にしておくと、そのたびに依頼しなくて済みます。
異常に気づける状態にしておく
これが抜けやすいところです。システムが止まったとき、誰がそれに気づくのか。
多くの場合、気づくのは利用者です。朝出社した人が「開かない」と言って発覚する。この状態だと、夜間や休日に止まった場合、翌朝まで誰も知らないことになります。
止まって困るシステムであれば、人が見るのではなく、動いているかどうかを機械的に確認する仕組みを入れておくほうが確実です。これは開発とは別の領域の話になるので、必要かどうかも含めて相談していただければと思います。
小さく作った場合ほど、決めておく
「まずは小さく始めましょう」という進め方をした場合、運用の話はさらに後回しになりやすいです。規模が小さいぶん、なんとなく回ってしまうためです。
ただ、小さく作ったシステムこそ特定の一人が面倒を見ている状態になりがちで、その人がいなくなった瞬間に止まります。規模が小さくても、①の「最初に相談を受ける人」だけは決めておいたほうがいいです。
まとめ
- システムは納品後も、止まる・変わる・人が入れ替わる
- 決めておくのは4つ。相談窓口、社内外の線引き、連絡手段、費用の形
- 開発した会社が運用するとは限らない。分けるなら引き継ぎ資料が要る
- 止まったときに誰が気づくのか、を決めておく
これから作る場合も、すでに動いているシステムがある場合も、整理のお手伝いができます。 「作ったはいいが、誰も面倒を見ていない」という状態のご相談も承っています。