会社でシステムを外注することはよくある。しかし社内の発注者のリテラシーが低く不充分なシステムを納入されることがある。そして社内で検証できる人物がいないため泣き寝入りというパターンは少なくない。
あなたが、とある管理ソフトを外注したとしよう。新しい事業開発をするにあたりOSの切り替えが必要になり外注することにいたったと仮定する。
●社内でよくある現象
システムは稼動時点ではバグがあるものだ。個人情報漏えいのリスクや、そもそも要件を満たしていないなどの致命的なバグ以外は、稼動するなかで修正していくことはよくある。大手ベンダーの場合、アセンブリーやプロマネの能力が高いが、あなた自身に当該能力が補完されているなら個人でやっているようなシステム会社に発注することも一考だろう。
最初は、業務の流れや必要な項目を書面によって確認するが、稼動できる状態に仕上がった時にトラブルが発生することが多い。操作をしてみるとどうも動きがおかしい。余計な機能が多く想定していた動作の10倍の手間が掛かるなど。フリーズも多く画面が正常に表示されないことも多い。どうやら大量のバグがありそうだ。
しかし、大量のバグは事業開始に影響を及ぼす。カットオーヴァーに時間がかかりプロジェクトスタートに問題が生じてしまったら責任問題だ。あなたはシステム会社に細かい指示を出し、逐一報告を求めた。
そしてついにシステム会社が逆キレを起こす。あなたは「これ以上の時間が掛かると事業に影響を及ぼすので困る旨」を説明した。しかしシステム会社は、「これ以上の作業をするにはチャージ（追加料金）が掛かる」と主張する。
あなたは「このシステムは必要条件を満たしていない」と主張する。システム会社は「既に開発に追加料金をどんどんつぎ込み当初予算をオーバーしている」「検収しないなら全責任を取れ」と強気だ。そうしているうちに時間が経過し事業機会を逸してしまう。
●要件定義書と外部設計書と提出させる
私自身もシステムに詳しいわけではない。意味不明なスパゲッティコードを見せられても構造を把握することは難しい。スパゲッティコードとは、変数の有効範囲を拡大したりあとから色々な機能を後付けすることで発生する。スパゲッティが絡み合って1本を取り出すことができない様子を表現した言葉である。
このような事態に陥ると堂々巡りになる。こうならないためにも、要件定義書と外部設計書は精査したほうがよい。求めない限り、要件定義書と外部設計書を出さない会社があるがこれは必ず提出させなくてはいけない。
そして、そのうえで専門家に精査してもらう。そうすればプロジェクトの進め方や概要、金額の妥当性などについても把握できる。問題が発生したシステムは、それこそ前述のスパゲッティコードが立ち並び、バグが多くローパフォーマンスで処理が遅く、理解できない専門用語が並んでいるなんてことも少なくない。
要件定義とは概要（背景や目的、要件定義書の範囲、用語説明など）、システム要件（他システムとの連関性や位置づけ、用語説明など）が明示され、性能、インターフェイス、運用要件などが規定されているものである。
外部設計書は基本設計とも称するが、システム担当者と調整しながら、仕様を決めていく際に必要である。発注者に理解してもらうことが大切なので発注者が理解できなければ意思疎通をはかり合意形成を図ることは困難である。
要件定義を上流から把握したい方は情報処理推進機構のHPが参考になる。
●効果的な検証方法
私の知り合いの会社で検証作業を得意にしている会社がある。検証作業の際、アルバイトを採用して普通では考えられないような操作をしてもらうことで検証している。
その際に、書式のスラが足りないとか桁数がおかしいとか疑問に思うことはすべて抽出する。初期段階でのバグ出しには専門的な見地ではなく、むしろ非常識な作業方法が役立つ場合がある。数ヶ月程度試用すればいろいろなことが分かってくる。
考えられない作業をすることでエラーが増えるが、このテストをクリアすればシステムトラブルが発生しないレベルまで引き上げられることが可能とのことだ。一つの方法としては効果的な手法ともいえるのだろう。
尾藤克之
コラムニスト
追伸
アゴラ研究所は、次代の論客になりうる新しい才能を開拓するため、商業出版や電子出版の著者発掘セミナーを開催します。
講座に参加された方には、著者志望者の第一歩として重要なプロフィール作成文の添削までをおこないます。セミナー・スクール受講者から優秀な成績を収めた方は、「アゴラ」執筆陣に参加し、ご専門に関する論考を投稿するチャンスも用意されています。
