システム開発で失敗する原因はこれ!システム開発で、NGな発注者の思考・行動10選!Part2
今回は「管理情報が納品されなかったために招いた悲劇」というテーマで投稿します。
システム開発の現場では、サーバーやインフラの管理情報がしっかりと発注者に引き渡されないままITベンダーが変わるケースがあります。今回は、そのような状況がどのようなリスクをもたらすのか、そしてそのリスクを避けるために何をすべきかについて解説します。
- ITベンダーを切り替える際の注意点を知りたい
- システム開発で失敗したくない
そんな方は、ぜひ最後までご覧ください!
※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。
サーバーの管理情報が納品されなかった本当のお話
まず、サーバーの管理情報が納品されなかったために発生した具体的な事例から説明します。
ある企業の出来事です。これまで契約していたITベンダーが「最近質問に対するレスポンスが遅い」「担当者が退職した」という理由で、システムの修正や新規機能の開発が実質的にできなくなったため、やむなく他社へ切り替えたいと考えました。
そして、切り替える先のITベンダーに相談したところ・・・
ITベンダー「分かりました。現状の調査をしますので、サーバの管理情報をください」
ユーザー企業「管理情報ってなんですか?」
ITベンダー「システム環境の構成資料、クラウドサーバへのログインID、パスワード。サーバのアカウントなどのアクセス情報です」
ユーザー企業「いまのシステム会社に任せているので分かりません。何とかなりますか?」
ITベンダー「どうしようもありません。。。」
結局は作り直しをするしかないということになり、その後はどうなったかは分かりません。
このようなお話は決して珍しいことではないと思います。ユーザー企業、つまり発注者側が「自分はシステムが難しくて分からないから、ITベンダーに全てお任せ」という考えに浸りきっている場合です。
子会社・グループ会社など絶対的な信用、途切れることがない関係が担保されているのであれば、それもいいでしょう。しかしそうでないならば、抑えておくべきところは抑えておかないと、いざというときに悲劇を招きます。
実際に聞いたことがある範囲のお話だと、簡単なWEBシステムのホームページの範囲ですが、それでも貴重なデータを保持しているため、作り直すとしてもデータだけは取り出したいということがありました。
簡単なWEBシステムやホームページなどは、安く作りたいのでフリーランスに依頼したものの、その後連絡が付かなくなることもあるようです。
そういう事例をいくつか聞いたということで、フリーランスを否定しているわけではありません。実際、当社もフリーランスの方にご協力頂いている案件も幾つもありますので、誤解がないように申し上げておきます。
悲劇を最小限にするために抑えておくべき管理情報
ITベンダーを切り替えなければならないことになること自体既に悲劇なのですが、それでも悲劇は最小限にしたいところです。
では、どのような管理情報を抑えておかなければならないのかを説明します。但し、これらについては、理解をしなくても構いません。自分の手元に残ってさえいれば、新しいITベンダーにその情報を渡すだけで済みます。
①システム環境の契約情報
オンプレミス、つまり企業がサーバーや通信環境などの設備やソフトウェアなどを自社で保有してシステム構築・運用する方法を取っているのでなければ、AWSに代表されるクラウドサービスを使うことになります。
WEBシステムであれば、ドメインを取得しますし、サーバ証明書も必要です。
スマホアプリなら、ストアに上げるためApple、Googleとの契約。
それ以外にも、外部のAPIと言われる仕組みを利用する場合は、他社と契約します。
このように、外部の様々なサービスを利用しながらシステム・WEBサービス・スマホアプリなどを開発する場合、サービスの利用先との契約が必要となります。
この契約自体も手間がかかるため、開発を委託する先に代行してもらうことも多々あるのですが、契約者情報は必ず発注者側の名義としてください。最低限、契約名義が発注者側にあれば、いざというときに何とかできます。
これは、忘れずにそうしてください。
②サーバーのアクセス情報
全ての外部サービスのアカウント。つまり、ID・パスワードです。
- AWS、Azure、GCPなどのクラウドサービスのアカウント・ログインID・パスワード
- サーバー、ミドルウェアの管理者アカウント
などですが、細かな要求を出すと漏れがあるといけないので、システムに関わる全ての管理者のアカウント情報として提示してもらいます。
「管理者のアカウント情報」というのが大切です。管理者アカウントは全ての権限を持っているからです。
③サーバー構成情報
サーバーにインストールされているソフトウェア・ミドルウェア・ライブラリのバージョン、設定ファイルの内容など、サーバーの全体構成が分かる情報です。これがあれば、新しいITベンダーがシステムを把握することが、スムーズにできます。
④ドキュメント
システムに関するドキュメント類。要件定義書、設計書、テスト仕様書、運用マニュアルなどです。開発が終了していれば納品されているはずですが、漏れていることがないように注意してください。
いまでも紙で提出されることもあるでしょうが、デジタルファイルも合わせて受け取っておくべきです。手直しできるというメリットよりも、キーワードで検索できるというメリットがあります。
ただし、注意すべきは契約時に納品物として約束されているということです。契約書に納品物として書かれていないドキュメントを強要することはできません。時には、契約書に書いてなくても「ドキュメントを納品するのは常識だよね」と迫る発注者もいますが、それは単に無茶な要求をしているに過ぎません。
抑えておきたい管理情報は上記4つですが、重要度も説明した順に等しいです。
サーバー構成情報とドキュメントがなかったとしても、システム環境の契約情報とサーバーのアクセス情報は必ず抑えておいてください。
管理情報が納品された際の注意事項
「先に説明した管理情報が納品されているから大丈夫。」では、済まないこともありますので、注意して頂きたいことを補足しておきます。
まず、管理情報の最新化です。開発が完了した時点で、管理情報が納品されたとしても、場合によってはその後パスワードを変更することもあり得ます。ですから、システムの運用に際しては、もし管理情報の何かが変更になった場合は、必ず共有してもらうことを忘れずにしてください。
情報は最新であるからこそ、意味があります。
そして、社内での情報共有です。これも、珍しくない話しでなのですが、「システムの担当者が退職したので、システム環境に関わる契約情報が分かりません」というケースがあります。
ITベンダーからはしっかりと管理情報が納品されたとしても、その情報の在処を知る人は社内でただ一人であるのはいけません。デジタルファイルであれば、最低限どのフォルダに各種情報が管理されているかということは2名以上で把握しておきましょう。
まとめ
今回は、「管理情報が納品されなかったために招いた悲劇」というテーマで、サーバーの管理情報が適切に引き渡されなかった場合のリスクや、発注者として抑えておくべき情報について解説しました。
ITベンダーの切り替えが必要になった際、サーバーやシステムに関する管理情報が不足していると、プロジェクトが停滞し、大きな損失を招く危険性があります。これを避けるためには、発注者としても責任を持って管理情報を把握し、定期的に最新の状態を維持することが不可欠です。
また、社内での情報共有も忘れてはいけません。管理情報が一人の担当者だけに依存している状態では、担当者の退職や異動時に大きなリスクを抱えることになります。情報を複数名で管理し、社内での共有を徹底することで、リスクを最小限に抑えましょう。