システム開発で陥りがちなワナ。。

止まらない仕様変更、、トラブル。。

日経クロステックに、
「逆転敗訴した野村情シスがIBMに送った悲痛なメール、横暴なユーザーを抑えきれず」
なる記事が投稿され、思わずクリックして読んでしまった。(^^;
　
詳細は当該記事をご覧いただきたいが、かいつまんで言うと以下のような事例だ。

野村証券が日本IBMに発注したシステム開発が頓挫し、約36億円もの損害賠償を起こした。
一審ではベンダー側（IBM）敗訴の判決だったが、二審の高裁判決では逆転勝訴となった。
記事によると、もともとパッケージソフトに合わせて業務を最適化するという方針だったところ、業務部門X氏の強い反発で自身の現行業務に合わせたカスタマイズ要求（追加要件）を開発工程からテスト工程に入っても五月雨式に続け、最終的にプロジェクトが中止になった。
というもの。

※記事中にもある「2017年 旭川医科大学とNTT東日本が争った裁判」については、過去のブログに記載しているので、そちらも参考にされたし。

SEの立場からすると、他人事ではない「あるある」のトラブル。。

問題点は２つ

(1) 既存の業務フローが変わることのリスク（抵抗）
まず、既存の業務をシステム化する、または既存のシステムを新システムに刷新する際、コスト削減や導入までの早さでパッケージソフトを導入することは良くある。
パッケージソフトは、確かにメリットも多いが、デメリットをきちんと把握した上で導入決定しないととても危険である。
その一つが記事にもあるように既存の業務フローをパッケージソフトに合わせて変更しなくてはならないこと。そして既存の業務フローを変えることには（特に古参の）社員から ものすごい反発があるということだ。

そしてもう一つが仕様を明確に確定（フィックス）させてから開発をスタートさせる、ということ。別の言い方をすれば、仕様が確定し開発がスタートしたら 安易に変更・機能追加を行わないことがとても大切だ。
システム開発では、例えば「入力項目を一つ追加する」と言った、ほんの些細なことと思われるような改修でも、実はデータベース（DB）の構造から見直しが必要になったりするようなケースが多々ある。

そうは言っても、仕様策定段階では気がつかず、後から「あ、やっぱこれも必要かも。。」なんて気づくこともあると思う。
そんな時は制作側（ベンダー）のアドバイスを聞きつつ、
① 比較的軽重な改修で収まるものは採用する。
② これを盛り込まないと致命的と思われるものは採用する。
逆に言うと、それ以外はガマンする、または運用開始後のフェーズ２で改めて機能追加する、などの判断が必要だ。

採用するにしても五月雨式にずるずると変更するのではなく、ある程度期限を区切って その期限までに出た要望を纏めて対処する、といった区切りが絶対に必要だ。
もちろん（特に②の場合は）、それにより追加費用が発生したり納期が延びる可能性もあるので、ベンダー側とよく相談しながら、発注側責任者の決済を仰ぎ 書面でエビデンスを残すようにしたい。
　

トラブルを防ぐためには！？

(1) 既存業務フローに合わせたシステム化
弊社では基本的に、既存の業務フローに合わせたオリジナル仕様のシステム開発を提案している。
それは本記事にもあるように、既存の業務フローを変えると（特に導入当初は）社内・現場がものすごく混乱する場合が少なくないからだ。ただでさえシステムツールの使い方をマスターしなければならない上に、業務フローまで変わっていたら、よほど事前に理解していなければスムーズに運用できないことは想像に難くないだろう。

また、今までそれでやってきた仕事の流れ（業務フロー）が変わってしまうことに、抵抗感を持つ社員はとても多い。システム導入は それを使う現場社員の協力なしには成り立たない。
なので、ベンダーSEが 既存の業務フローを細かく分析し（理解し）、そのどの部分をどのようにデジタル化するのがベストなのか仕様策定していくところが腕の見せ所だ。

弊社では、従来の帳票類、例えば見積書や請求書などの雛形も あえてほぼそのままの形式で出力できるようにし、抵抗なく使ってもらえるように心がけている。
　
(2) 詳細な画面設計書やモックによるデモ体験
仕様変更のスパイラルを防ぐ方法としては、初期の仕様策定段階で 仕様書として詳細な画面設計書を作ることにしている。
まずはトップのログイン画面から始まり、ログイン後の画面遷移を全ての画面について、画面の見た目そのままの詳細な設計図を全ページ分作成する。もちろんエラー画面やNGルートなども含めてだ。

その画面設計書のレビューを繰り返し、修正を重ねブラッシュアップしていく。だいたい5回くらい繰り返していくと、かなり完成度の高い（期待値に近い）仕様になってくる。
画面設計書は ちょっとしたシステムでも すぐに数百ページにもなり、、実はこの作業は 制作側にとってとても手間のかかる作業なのだが、この段階でキッチリ確認し仕様に反映しておかないと、後々記事のようなトラブルに発展するリスクを潜在化させることになる。
時間や手間、コスト削減を狙ったつもりで この作業を省くと、後々余計に時間と労力を費やすハメになることが多々ある。

また実際にプログラミングするプログラマ（PG）は、画面設計書があれば その通りに忠実に作って行けば良いのだが、曖昧な部分があると、都度SEや顧客に確認するか、PG自身が判断して作ることになるが、、それが見当違いだと、出来上がったときに「違う。。」となってしまう。。
　

モックによるデモも

業界内では「モック」という言い方をよくするが、「モックアップ」と言った方が耳なじみがあるかも知れない。
モック（モックアップ）とは、実物そっくりに作った試作品のことだ。
上記の画面設計書は、あくまでも「資料」であるため、実際に「画面に何か入力してクリックし、画面が切り替わる」といった実際の動作とは異なり、慣れている人でないと どうしても実感がわかない場合が多い。そんな時は 実際にデータベースがあるわけではないが、見た目の画面は完成形と同じような（ただしモックの段階ではデザイン化されていないが）操作感を体感できるモックを制作し、しばらく動かしていただくようにする。
※モックは紙芝居的に作っているので、入力欄にどんな値を入れても 決められた次のページが表示されるだけなのだが、使っている印象は完成品とほぼ同等に体感できる。

モックは 基本的にはオプションになるので、お客様には別途費用をご負担いただくことになるが、ここまで作り込んでおくと、記事のようなトラブルは未然に防げる。またモック段階で各部署の担当者に使ってもらい その意見をフィードバックしていくことで、システム化への抵抗感もなくなり 自分たちも一緒に作り上げたという一体感、満足感も出てきて、スムーズな運用に移行できるのも 大きなメリットだ。