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

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

具体的なシステムの話・・・の前に

前回の記事にて開発会社の選定やコストについての話をしました。
次は具体的なシステムの話を詰めて・・・その前にw
今までの記事でも書きましたが、システムというのは開発の前段階と開発中、そして開発後の運用というステップがあります。
開発前の段階では色々な構想や、仕様に関しての考えで頭がいっぱいになりがちですが、失敗しないためにはこの段階で確認するべきことが他にも色々とあります。

・開発体制
・納品物
・セキュリティ試験レベル
・性能試験レベル
・ランニングコスト
・開発後のサポート体制
・保守

開発体制

まず開発体制ですが、簡単に言えば、開発会社側の誰が窓口になるのかや、技術者は何人でそれぞれの役割はなんなのかといった内容のことです。
発注者側からすれば関係ないと思われるかもしれませんが、窓口となる担当者が営業職の人だったりすると、こちらの要望や意見、質問などがスポイルされて伝わったり、認識の差異が出てくることがままあります。
決して営業が窓口ではダメという訳ではなく、細かい機能面の話や、データの話など、技術面を担当する人が誰なのか、その人とのやり取りはどうするのかなどを、最初にある程度確認しておいた方が無難です。
会社によっては技術者は前面に出てこない、やり取りは全て営業やコンサルを通す、というところもありますが、私の経験上、そういった体制の場合、得てしてレスポンスが遅かったり、なかなか話が進まないという場合が多いと感じます。
基本的には窓口となる人を通して話をすればいいですが、緊急性が高い内容の問題が発生した場合など、技術者と直接やり取りをした方がスムーズなので、そういった体制が取れるかどうかは確認しましょう。
逆に窓口となる担当者がそのまま技術面のリーダーだったりする場合、技術面の連携はスムーズになりますが、コスト調整や営業面での動きはやや遅くなる場合もあります。
開発会社側の体制に口を出す訳にはいかないかもしれませんが、少なくともどういった体制でどのように分担して開発していくのかは確認しておきましょう。

納品物

納品物に関しては、以外にも曖昧なまま進める案件が多いと感じます。
開発したシステムそのものが納品物ではないの？と思われるかもしれませんが、他にも色々とあります。
最たるものはドキュメントです。
コスト面やスピード感を考えて、ドキュメントを極力減らすというのが最近の主流となってきていますが、最低限必要なものもあります。
システムの内容や開発手法にもよりますが、少なくとも

・設計書
・機能仕様書
・テスト仕様書とテスト結果報告書
・マニュアル等

このぐらいは納品物として要求してもいいかもしれません。
マニュアルに関しては、実際に運用する側であるあなたの会社で作成した方がいい場合もありますので、柔軟に対応しましょう。
当たり前ですがドキュメントを作成する工数も見積もりに入ってきますので、コスト面とのバランスを考えることが大切です。
設計書や機能仕様書などは、あなたが見ても内容が分かりずらいかもしれません。
ですが見ても分からないからいらない、と判断するのは尚早です。
私も何度も経験しましたが、既存のシステムを改修して欲しいとか、機能を追加したい、バグが発見された、などお客様から依頼が来た時に、既存システムは〇〇という会社に作ってもらったが、逃げられた(その他にも倒産したとか信用できないとか・・・)。
改修したいけれども設計書や仕様書はない。
以前の記事でも書きましたが、こういった場合、まず既存システムの解析というところから作業が始まります。
もちろんその分コストは大きくなりますし、スピード感も落ちるでしょう。
ですがあなたが分からない仕様書でも、技術者が見れば大体把握できる内容だったりします。
解析が不要、とまではいかなくても、コストや工数を下げる助けにはなります。
システム開発のプロであっても、見たこともないシステムの仕様は解析しなければ分かりません。
直接プログラムを見た方が早いといった場合も往々にしてありますが、設計書や仕様書などはあって損はありません。

セキュリティ試験と性能試験

Webシステムなどの場合は特にですが、セキュリティ試験というのが重要になってきます。
近年問題になりがちな個人情報の漏洩等のリスクだけでなく、そのシステムを通して社内のネットワークへ侵入されたり、データをハックされたり、ウィルスを混入されたり・・・
PCやネットワークを介したシステムである以上、セキュリティリスクというのは避けて通れない問題になります。
うちのような小さな会社のシステムに攻撃してくるハッカーなんかいないだろう、というのは甘い考えです。
特に個人情報の漏洩に関しては、その実害だけでなく社会的信用の失墜という多大な犠牲を払うことになりかねません。
セキュリティ試験に関しては、最初に考慮しておくべきでしょう。
とはいえ堅牢なセキュリティというのは、使い勝手や運用コスト、レスポンス等の性能とトレードオフです。
つまりセキュリティを高めれば高めるほど、運用者としては使いにくい、面倒な作業が多いシステムになりがちです。
その辺はバランスの問題なので、機能面も含めて開発側と詰めていきましょう。

次に性能試験に関してですが、機能としては動いているが、みんながいっせいに使ったら処理に3時間かかるようなシステムは意味がありませんよねw
運用に耐えるシステムにするためには最低でも、運用者側の人数や作業頻度、データ量や画像やファイル等のコンテンツ数、コンシューマー向けのシステムであればアクティブユーザーや同時アクセスの想定数等の情報を開発側へ伝えておきましょう。
その上で、各機能が何秒以内に完了するとか重い処理はバッチ化する等の条件を詰めていきましょう。
とはいえ、性能要件というのはどんどん変わっていく可能性があります。
使う人が増えていくかもしれませんし、データ量はどんどん増えていく可能性もあります。
ネットワーク性能も上がっていくかもしれませんし、PCやサーバーのスペックも変わっていきます。
ある程度幅をみて、最低限の性能と目標値を調整していくのが良いでしょう。
その性能要件を満たしているかを判定するための試験が性能試験ですので、どのような試験が可能か開発側に確認しておきましょう。

ランニングコスト、サポート体制と保守

ランニングコストとはその言葉通り、運用していく上で定期的にかかるコストです。
サーバー費用やネットワーク使用料、最近ではクラウド費用などもかかる可能性がありますね。
また重要なのが運用サポートや保守に関しての費用です。

よく保守費用に関して勘違いをされている方がいます。

保守・・・つまり現状維持ってことで、障害とかが何もなければ、ただ毎月お金がかかるだけでしょ？

と、思っていませんか？
確かに、何も起きなければただただ毎月支払いが発生しているだけのように感じます。
ですが、よく考えてみてください。
開発会社側には窓口になる人や、技術面のリーダー、設計したシステムエンジニアや、実装を担当したプログラマーなど、様々な人が関わっていますよね。
そしてその担当者達は、来年も、5年後も、10年後も同じ事をしているでしょうか？
していたとしても、あなたのシステムに何かあった時に、また担当者になるでしょうか？
外注先の人事や人員のアサイン、ましてや技術者個人の仕事や人生にまで口を出すことはできません。
システム開発後に何事もなく普通に運用していたとしても、そのシステムを理解している人は減っていくのです。
それは仕方の無いことですが、開発会社側がその知識や技術を他のメンバーや新入社員に共有し続けることで、知識の損失は防げます。
運用後のサポート体制に関しても、そういった体制をとることで、少なくとも担当者がいなくなる(誰もシステムの事を知らない)ということはなくなるでしょう。
しかし、何も実作業がないとしても、そういった知識や技術を保持し続ける労力は必要であり、そのためのコストも必要になります。
保守費用というのは、何かあった時の作業費用だけではなく、そういったシステム知識や技術の保全、そういった体制を組織としてとり続けるための費用という側面があります。
保守契約はせずに、都度スポット対応してもらうような体制も考えられますが、経済面でのリスクをとってでも保守契約することをオススメします。

要件定義と仕様検討

開発会社(もしくはSIerやフリーランスエンジニア)の選定が終わり、開発体制や納品物などの確認が終われば、具体的にシステム要件を詰めていく段階です。

この段階で発注者側が1番労力を使わなければなりません。
なぜならこの段階での要件定義、仕様がシステムの完成度に直結するからです。
実際の開発作業に入れば、後は開発する側の作業がメインとなりますので、発注者側はその前段階である「どんなシステムを作るのか」を定義するこの段階に最も力を注ぐように心がけるべきでしょう。

と言ってもやることは単純です。

・あなたがどんなシステムを求めているか
・そのシステムで何をしたいか、何ができるのか
・そのために必要な機能は何なのか
・どのように運用するのか、したいのか

という要望を開発側へ「具体的に細かく」伝えることです。
またその要望に対しての開発側からの意見や提案を吟味し、取捨選択の判断をすることです。

要望を伝えれば全てその通りになる訳ではありません。
専門家や技術者では無いあなたの要望は、時にトンチンカンな(失礼ですがw)実現しようのないものかもしれません。

ですが萎縮する必要もありません。

あくまでこちらの要望として伝え、分からないことは質問し、開発側からの意見や提案を引き出すようにしましょう。
またあなたで判断できないことが出てくる可能性も多々あるでしょう。
その際は上司に確認したり、現場の人にヒアリングしたりすることを躊躇わず行うべきです。
開発側はあなたの組織がどのように動いているのか分かりませんし、現場の人(そのシステムを実際に使う人、運用する人)がどう考えるかは分かりません。
そういったものを取りまとめて要望として伝えるのが1番大切なことだと考えましょう。
人によって言うことはマチマチだったりしますが、より良いものを作るための判断や取捨選択は必要です。

私の経験則にはなりますが、システム開発というのは多くの場合「実際に使って、運用してみなければ分からないこと」が、本当に多いと感じます。
ないものを作るわけですから当然ですが、誰もまだ見ていない新しいシステムの使い勝手がわかる人は存在しません。
しかし、開発側としてはどうすればいいのかを決めてもらうしか開発のしようがないのです。
要望を解決するための仕様が分からなくても、一旦は決めないと進まないことになります。

実際に作った後に、やっぱりこういう形の方が良かった、こうするべきだったというのは沢山出てきます。
しかし、多くの人にヒアリングし、発注者側の要望を高い精度でまとめていけば、手戻りを少なくすることはできます。
仕様変更や追加機能、手戻りは単純にコストに直結しますので、この段階で極力詰めていく事が重要です。

どうしても決めかねる場合は、フェーズを分けることも視野に入れましょう。
一部機能を先行して開発し、その使い勝手などを見て決める、というやり方もあります。
特にシステム規模が大きい場合は、ある程度のボリュームでフェーズを分けるべきでしょう。
一気に作ってしまうという手もあります(その方が初期コストは抑えられる場合が多い)が、手戻りリスクは高くなります。
(手戻りや仕様変更が多いと、結局トータルコストは高くなる)

開発側と打ち合わせを重ね、各機能の仕様などを詰めていけば、あなたが求めるシステムに近づいていきます。
どうかこのフェーズでの労力を惜しまず、良いシステムを作り上げてください。

今回の記事は長くなってしまいました・・・
発注者側の立場では1番大事な局面なので・・・

開発会社も決まり、コストや納品物、開発体制やサポート体制、保守内容、実際のシステム要件、各仕様が出揃えば、いよいよ開発ですね。

・・・そうです、開発中というのは発注者側の作業があまりありませんw
開発側から定期的に質問や判断を求められると思いますので、順次処理していきましょう。
ここで注意していただきたいのですが、質問への回答や、判断をなるべく迅速に行って下さい。
あなたの行動が遅くなれば、そのまま開発が遅れる可能性があるためです。
前述の通り、開発側はあくまで開発側であり、あなたが仕様を決めない限り動けないのです。
「よしなに」の精神は、開発側が優秀な場合上手くいくこともありますが、出来る限りあなたがハンドリングできる内容はあなた(もしくはあなたの部下や担当者)が迅速に対応しましょう。

次はシステム開発後の話を記事にします。
宜しければ、フォロー、スキをよろしくお願いします。
サポート頂けると非常に喜びます。


システム開発に関してこんな事が知りたい、こういう場合どうすればいい？
といったこともですが、今後プログラマー、システムエンジニアになりたい、エンジニアとして起業したいという方からの質問、コメント等もお待ちしております。