失敗する外注システム開発 発注者がするべきこと 〜4〜

10年以上エンジニアとしてシステム開発に携わってきた私が、経験を元に、システム開発を外注する場合に、発注者側の立場において、するべきことや考えるべきことを共有したいと思います。
前回の記事を未読の方はぜひ併せてご高覧下さい。

いよいよ開発

さてここまでの記事でお話したことをしっかりと実践して来た場合、いよいよ本格的な開発が始まります。

・・・が

当たり前ですが開発は開発会社のSEやプログラマーが行います。

じゃあ発注者側であるあなたのやるべきことは？

受け入れシナリオの作成

システムの開発中に発注者側が必ずやるべきなのは、受け入れシナリオの作成です。

受け入れシナリオって何？と思うかもしれませんが、開発会社はあくまでシステムを開発するだけで、実際に利用、運用するのはあなたやあなたの会社の人達です。

開発会社はシステムを納品しますので、発注者側は納品されたシステム(やその他の納品物)を確認し、「これでOK！」となるまで精査する検収作業をしなければなりません。

プログラム自体のテストは開発会社側が行うはずなので、発注者側の受け入れ作業は主に下記のようになります。

・各機能が仕様通りに動作しているか
・仕様漏れや検討不足な部分がないか
・運用に合致しているか
・納品物の精度(ドキュメント等)
・デザインやレイアウト等の確認と使い勝手の検証

個人的に受け入れ作業に関して「はしょる」方が多いと感じますが、非常に重要な作業になるので、手を抜かずに実施することをオススメします。

何故なら、いくらシステム開発のプロといえども、開発しているのは人間です。

システム規模にもよりますが、ちょっとしたバグや検討漏れなどは「絶対と言っていい」ほどあります。

逆に、バグが1つもない、最初の納品時点で完璧、という状態だった場合は、そもそものテストや検証が不足している可能性が高いと危機感を持つべきです。

開発者側の私が言うのもなんですがw

とはいえ技術者でもない発注者側の人間が確認できるのは表面上のことです。

つまり、実際に使ってみて「何か画面がおかしい」「データが期待通りの結果にならない」といったことを確認する作業になります。

そうなった場合に、なぜそうなるのか、何がおかしいのか、を確認・修正するのは開発者側の責任になります。

そういった内容を、どういう順序で検証していくのか、どのようなテストデータを使うのか、この画面でこうしたらデータがこうなるはず、といったシナリオをまとめていくのが、この段階で発注者側がやるべき事です。

逆に言えば、受け入れ作業をはしょったり、シナリオが不足していた場合、納品・受け入れ(検収)後に何かバグや欠陥が発見されても、開発者側は対応できる保証がないということになります。

実際にはまともな会社であれば、バグ等の改修は行うでしょうし、瑕疵期間もありますので、対応はすると思いますが、納品・検収後のそのタイミングでシステム開発チームのメンバーの手が空いている保証はなく、対応に時間がかかる可能性もあります。

またバグではなく、そもそもの仕様検討不足や認識の齟齬による欠陥の場合、それは検収漏れとなりますので開発側に責任がない・・・とは言いませんが、対応する義務はないことになります。

(対応の悪い会社などは、平気で「仕様書に書いていないのでこちらの責任では無い。よって対応できません。」とか平気で言うところもあります)

もちろん、開発側と良い関係が築けていれば無下にはしないと思いますが、どうしても改修するのに追加コストが発生したり、スケジュールが厳しくなったりする場合もあり、結果的にコストパフォーマンスが落ちていきます。

検収期間に発覚した問題であれば、実際にはまだ「開発中」となりますので、開発側も誠意を持って対応する必要があります。

もちろん、検収期間中であっても、バグではなくそもそもの仕様漏れなどの場合は、追加コストが発生したりもします。

前回の記事で、開発前の要件定義や仕様検討が1番大切と書いたのはそのためです。

できるだけ手戻りを少なくし、実際の運用が始まる前に問題を洗い出せるよう、受け入れシナリオはしっかりと作成しましょう。

受け入れ体制の整備

受け入れシナリオができたあとは、体制作りです。

システム規模にもよりますが、受け入れ作業は出来れば複数人で分担して行うのがベターでしょう。

誰がどの部分をどうやって検収するのか、という体制を決め、受け入れ作業がスムーズに進むようマネジメントします。

特に使い勝手等の運用面は、実際に運用を担当する人に確認してもらうべきです。

使いやすいかどうかというのは多分に主観が挟まりますので、あなたがこれでいいと感じても、運用者達は違うかもしれません。

本来は仕様検討段階で詰めるべき内容ですが、前の記事でも書いた通り、システムやアプリケーションというのは「使ってみないと分からない」箇所が沢山あります。

実運用の前にしっかりと確認し、改善策を検討しましょう。

納品→改修・改善→検収完了

受け入れ体制が整えば、実際の受け入れ作業です。

開発手法にもよりますが、納品されたシステムを順序検収していきます。

検収作業の中でバグや障害が発生するかもしれません。

あなたからすれば致命的な欠陥に見えるかもしれませんが慌てないようにしましょう。

エンジニアとしてシステム開発に携わっていく中でよく起こる事なのですが、バグや仕様検討漏れが発覚した際に、発注者側が必要以上に大騒ぎすることがあります。

散々大騒ぎしてこちらに悲壮な声で連絡が来て・・・

5分で直る

ということは往々にしてあります。

もちろん逆もあります。

発注者側からすれば軽微な修正や仕様変更のように思えても、実はシステムの根幹に関わる内容だったり、関連する仕様に不整合が出てしまったり、修正範囲が膨大になったりという場合です。

まずはバグと思われる現象や漏れていた仕様に関してまとめることから始めましょう。

ひとつずつ解決していけば、いずれ求めていたシステムの形になってきます。

とはいえこの段階であまりにもバグや想定外、仕様変更が多い場合は、そもそもの要件定義や仕様検討、開発側のテスト内容や精度に問題がある可能性が高いため、一度巻き直すのも一手です。

この場合、開発側に突き返すような形になりますが、不完全なシステムでどうにかこうにか運用するのは、後々問題が大きくなっていく可能性が高いので、言うべきところはしっかりと言うべきですし、コストをかけなければならないところは躊躇しないほうが無難です。

開発側と調整し、速やかに改善、解決できる方法を探りましょう。

システム完成！運用開始！

システムが完成して受け入れが終われば、いよいよ実運用開始です。

この時点で発注者としての仕事は一旦完了ということになるでしょう。

お疲れ様でした。

しかし、実際には運用してみるとやはりこうしたい、ここはこうした方が良かった、などなど、色々な課題が出てくるものです。

どんなに優れたシステムでも、時間が経てば環境や社会情勢等に対応しにくくなっていったり、そもそもあなたの会社の事業内容などが変遷していく可能性もあります。

システム開発は作って終わりではなく、事業が続く限り終わらないものなのです。

開発後も、追加改修やカスタマイズ等の要件が出てきます。

しかし、発注担当者としてするべきことは、ゼロからの開発でもカスタマイズや機能追加でも同じです。

何を目的として

どんなシステムが必要で

誰が、どのように開発していくのか

コストはどこまでかけられるのか

どうなれば成功なのか

細かな動きの違いはあれど、発注者側から見たシステム開発は大体こういった視点で判断していく流れになると思います。

開発側のスキルや精度も大事ですが、発注者であるあなた次第で、システム開発の成否は大きく変わります。

より良いシステムが完成するように、発注者側がどう考え、何をしなければならないのか、この記事が皆さんの指針のひとつとなれば幸いです。

ここまで読んでいただき、ありがとうございます。

「失敗する外注システム開発 〜発注者がするべきこと〜」はこの記事が最後になります。

宜しければ、フォロー、スキ、シェアをよろしくお願い致します。

コメントなども頂ければ非常に嬉しいです。

今後も専門的・技術的な話よりも、考え方やマネジメント、システムエンジニアという職種や関わり方に関する記事を書いていこうと思いますので、他の記事も読んで頂ければと思います。

ではまた