つい最近、セブンイレブンの決済サービス「7Pay」が大規模不正利用されてしまった事件が起こりました。

セブン＆アイホールディングスほどの大企業が、満を持してローンチしたサービスなのになんでこんことになってるの！？と、最初は驚きを隠せませんでした。

セブン・ペイの記者会見で、セブン・ペイ社長が二段階認証について見識がなかった旨の発言をしていて、正直「こりゃダメだ」と思いましたが、どうやら今回の根本的な問題は別のところにあったようです。

今回の7Payの開発においては、度重なる仕様変更とそれに伴うスケジュールの圧迫があったのだとか。
詳しくは BUSINESS INSIDER JAPANの記事を参照ください。

【極秘入手】7pay開発の内部資料。｢セキュリティー不備｣は急な開発と“度重なる仕様変更”が一因か

この記事では仕様変更の詳しい状況については述べられていませんが、内容が問題なのではなく、「仕様変更」が「度重なった」こと自体が問題なのです。

今や、中小企業でも自社システムを構築することは、そう大きなハードルではなくなっています。
個人レベルでも、ひと昔前では数百万円のコストをかけたようなシステムを数か月で組めるほどです。
（しかも、システム・エンジニアでもなくても！）

とは言え、スモールスタートだとしてもビジネスで使用するシステムであれば、外部の専門家に構築を依頼することになることが多いかと思います。

その際によく陥るのが、「仕様変更の嵐」⇒「スケジュールの遅延／コストの増大」⇒「不十分／不満足なシステム」というパターン。
最悪なのは、上記の7payのように決定的な不具合につながることで、少なくありません。

仕様変更に対する認識

システム構築とWeb構築では、仕様変更に対する認識が全く違います。

多くのビジネスシステムは、ブラウザ（インターネット）を介して離れた場所のサーバー内にあるシステム本体にアクセスするため、一見Webサイトを構築するのと変わらないのでは？と誤解している方がいますが、全く違います！

Webサイトは、乱暴に言ってしまえば「表示するものを変更することを前提としている」ので、80%なり90%なり、ある程度不完全でもローンチ（公開）することが可能です。

しかし、システムはそういかない。
仕様（要求される機能）は事前に決められ、それを実現することのみを満たすためにプログラムされるので、プログラムを組んでしまったら事実上変更するのは非常に手間と時間がかかるのです。
90%どころか99%でもダメなんです。

この構築思想が全く相反する２つが、同じブラウザ上で動いている（ように見える）から厄介なんです。
知識を持たないユーザーにとっては、その切り分けが非常に難しい。

これは、制作ディレクターにとっても非常に悩ましい問題であり、永遠の課題です。

制作途中の仕様変更を防ぐには

まずはシステムの目的を、依頼側と制作側できちんと共有すること。
制作側もただ要求される性能を満たせば良い、と考えるのではなく、なぜその機能が必要なのかというバックボーンから共有するのが大事です。
出来れば、そのシステムを使用するビジネス全体をきちんと理解しておきたいところです。（もちろん守秘義務契約を結んでね）

依頼側は、事前にシステムの目的、要求される機能・性能、その根拠となるバックボーンをきちんと説明でいるように、文章化してください。
よく、打ち合わせで口頭で伝えればいいや、と考える依頼主もいますが、依頼側もシステム全体をきちんと整理して把握し、構築に入ってもブレないためにも、必ず文章に落としてください。
何もパワーポイントの綺麗な企画書である必要はありません。Wordで箇条書きにまとめてもらっても構いません。
全てをきちんと書き出すことが重要です。

このリストは、制作側にとっても非常に有益です。
まず、構築費用が予算に収まるかの判断がしやすくなります。
もし、予算を超えてしまう場合でも、その機能を削ればよいか、もしくは代替案を提示するか、提案を立てやすくなります。
また、システム上での矛盾や、可不可の判断もしやすくなります。

ここで、かなりのディスカッションを必要としますが、それを嫌がらないことです。
この面倒を抜けてしまえば、あとが非常に楽になりますし、お互いストレスフリーで進められます。

そのディスカッションは煮詰まったところで、要件定義になります。
この段階で、ああでもない、こうでもないともめ出すと、システム全体の方向性を失いかなないので、あくまで要求項目の確認と合意のためのものと考えるべきでしょう。

全ては、要件定義前の共通認識を如何に深くできるかがカギになります。

なので、企業側も、最初のディスカッションであまり突っ込んでこない制作には依頼しない方が良いでしょう。
ビジネスの根幹・意味まで突っ込んでくるのがベストです。

一度決めた仕様は動かさない

当たり前の話なんですが…..

特にワンマン経営者（当然ITリテラシーはない）に多いのですが、仕様も決まり、詳細設計も終了して、さて制作、という段階にきて、

「あの部分は、こう変えてほしい」
「この機能を追加してほしい」

と言ってくるケース。多いんです、本当に。笑

本当に依頼側に肝に銘じてほしいのは、「仕様変更」は要件定義前、最悪でも詳細設計が出来上がる前までに！ということです。

もちろん、変更できるケースもありますが、まず難しいと考えてください。
無理やりやれと言われれば、やってできないこともないのですが、その分コスト追加になります。
根幹部分にかかわる部分の場合、コストが倍になる場合だってあります。

あ、要件定義や詳細設計の段階でも大きな変更であれば、設計費用の追加要求につながるのでご注意を！！

とはいうものの…

そんなことは判っているよ！とか、そんなのは理想論だ！と思われる方も多いかと思います。

しかしながら、これが出来ていない現場は意外に多いのです。
なので、あえて、ここで書いたわけです。

冒頭の7payのケースを見ても、大企業でも起こりえる（起こってしまった）ことなのです。

なんにせよ、制作側をサービスの企画段階からプロジェクトチームとして加えることとをオススメします。
コスト的に割高に思われるかもしれませんが、後々を考えると、その方が結果的にコスト削減になります。

それが出来なければ、一番最初に長い時間・回数を費やして、事業の根幹から共有してください。

それができれば、お互い気持ちよく、いいサービスがローンチできると思います。