情シスとベンダーが一緒に成功させるために必要なこと

こんにちは、ごろうです！

『情シスとしてベンダーさんといいシステムが作りたいけど、どんなことが問題になるのかがわからない？』と悩んでいませんか？

そんな方に向けて、今回はシステムエンジニアとのお付き合いの方法について書いていきます。

この記事では、「システム開発で成功させていくようになりたい人向けに」に紹介しますね！

今回大切なのは、「システム開発でどうしても起きることを理解て対応する」。

本記事で書いてあることを実践すれば、システム開発で問題が大きくならないようになりますので、ぜひご覧ください！

ごろうの経歴

システム開発会社と情シスとシステム開発を成功させるために大切なこと

システム開発がうまくいかない理由の多くは、情シス側ユーザー側に起因することが多いです。それはなぜか…

わかりますか？

欲しいシステムを１００％理解するための資料を用意できていない

これに尽きますね。まぁ、現実的にこれできないんです…なぜか分かりますか？

認識齟齬は、どんなに関係が深くても起きるし、新しく作るシステムに必要なすべてを作る前から想像できないからですね。作って、発展させてきたのは、文化や歴史からもわかることですよね。

でも、少しでも認識齟齬を防ぐためにどうしたらいいのか？ってことを実践で学んできた、ベストな方法をお伝えしますね！

結論からどうぞ。

認識齟齬ってなんで起きるの？

認識齟齬がいちばんのシステム開発にとってのトラブルや失敗の原因になります。

じゃあ、なんで認識齟齬って起きるのか？

あなたが、わたしに「お昼ごはん、いこうか？」と誘ってみた時に、私が「大丈夫です。」と答えた時、これは、『一緒にきましょう』なのか『もうごはん食べたので大丈夫です』か、どちらでイメージしましたか？

ようするに、人間の関係性や、その業界特有の慣習など様々な要因があって、認識齟齬は起きるんですよね。

『おれの伝達力はすごい』って思っているような人に限って失敗するので本当に気を付けてくださいね。

最初に機能が詰め切れない…なんで？

まぁ、これは実際にごろうが、システムを作る立場のときに発生したことの実例がわかりやすいかなぁって思います。

こちらが、実際にあった依頼です。

Excelで検索等をしやすくしたら、次は、

こんな感じで、ちょっとすすんだら、これもできら、あれもできたらって、想像がしやすくなって、改善ポイントや欲しい追加機能がわかってくるんですね。

これが、最初からすべて想像し必要機能として洗い出せずにいる場合に、システム会社からすると、聞いていない機能なので、追加費用がかかります。ってなるんですよね。

じゃあ、どうやって対応したらいいの？

認識齟齬が起きること、システムに必要な機能をすべて最初に想像することが難しいことは分かったにしても、じゃあどうしたら、防げるの？ってなりますよね。

本当に大規模システムでないなら、プロトタイプ・アジャイル開発がオススメです。小さく作って使って、本当に役立つ機能から追加していく方法ですね。

これをすることで、

画面を見て、動きがあるから必要機能が想像しやすい。

認識齟齬が起きていることを早めに気づくことができる。

認識齟齬のリスクを減らす方法

ウォーターフォール型で開発した場合、ユーザー側がシステム会社に伝えたことで認識齟齬があったとしても、それがわかるのは、システム会社が開発を終えて、すべてのテストを終えて、「受入テストお願いしまーす」って、ユーザー側に提供されて、受入テストを実施して初めてわかるんですね。

じゃあ、受入テストの段階で修正ってなると、影響範囲は大きく、修正が正しくできているのかのテスト工数も膨らみます。早い段階で見つけた方が、傷は浅く済むんですが、一般的にシステム開発で認識齟齬が発覚するのは、本当に完成までの工程の最後の最後なんですよね。

ここからは、ごろうが行った認識齟齬リスク対策の具体的な方法です。すべて実践で経験し役立ったものです。

とにかくドキュメント化

口頭で確認して進めることがいちばんユーザー側として楽です…本当にそれが一番楽だけど、認識齟齬率№１です！

とにかくドキュメント化することで認識齟齬を発生させないようにしましょう。

これ、基本です。とにかく口頭でのやりとりで、空中戦にすることだけは避けるように意識してください。口頭で決まったことは、ドキュメント化し、お互いに確認できるようにすることで認識齟齬を予防してくださいね。

クイズ形式で質問しよう！

システム開発で、これもかなり効果的な方法です。

クイズ形式で、在庫がない状態で受注が来た時には、どうなりますか？ ➡予約状態となり、納期未定と表示されます

これが共通認識が取れているかを確かめることで、認識齟齬の予防になるんですね。

テーブル一覧（ER図）から認識相違がないかみる

テーブル一覧を見ると、ユーザー側が自分たちが欲しいシステムが、どんなデータをためることで実現されているかが集約されています。

リレーショナルデータベースの考え方が理解できていないと難しいですが、テーブル構成を見ると考慮不足、機能不足、パターン不足が分かります。

最初は、何がどうしてこうなっているのかがわからないところもあると思いますが、１テーブル３分ぐらい、なので、３０テーブルあるシステムなら、９０分ぐらいは、最低でも見ましょう！

ごろうは、３０テーブルで4～6時間ぐらいは見ていますねー

コードから認識齟齬を発見

コードは、著作権の問題もありまし、コード管理をユーザー側に見えるようにしてもらう必要があるのでひとつハードルがあります。さらに、ユーザー側がコードを読める必要があります。

ユーザー側がコードを読めると、認識齟齬を見つけることができますね。処理のパターンで実際に必要なパターンが、全然考慮されていない。なんてことが、テストする前からわかっちゃいますからね。

ごろうは、コードにコメントをつけることで認識齟齬の発見を実際していきました。

オススメ度は、高いんですがスキルがかなり求められちゃうところが欠点ですね

テストは、すべてユーザー側の仕事ってする

もうこれが一般的にしていない方法だけど、一番のおすすめの方法です！

まずは、システム会社が行うテストの、

について、ごろうは、総合テストからユーザー側で行ったパターンと、単体テストからすべてユーザー側で行ったパターンを経験しました。

で、実際稼働した時にバグも少なくスムーズに、システム稼働出来たのは、単体テストから行ったパターンでした。

最初にしたことは、

なのですが、ここですでに認識齟齬を見つけたりします。まだテストしていない段階ですよ！

このボタンを押したら、こうならないとこの業務できないですよ～、この順番で入力しないと帳票と順番が合わないなぁ。なんてことが見つかります。

そして、次は単体テストの実施です。当然ここでも実際にシステムを操作するので認識齟齬を見つけることができます。

システム会社がテストを行う場合は、結合テストっていうものするのですが、ユーザー側がテストに入り込む際は、結合テストはしませんでした。受入テストも、

をします。受入テストは、具体的に注文を受けて、在庫が確認できて請求書が印刷できる。など、流れまでを書くので、システム会社が受入テストをチェックすることで早めに認識齟齬を見つけることができるんですねー

この方法のいいことは、システム会社としても、テストしなくてよく、バグや見つかった認識齟齬に対応していくことに専念できることですね。システム会社としては、本来自分たちがやるべきことって思っていることが多いので、チームワークも育ちやすいこともメリットです。

そして、ユーザーさんがここまで頑張ってくれているから、システム会社さんも、自分たちも精一杯がんばるぞ！という、動機づけに役立ちます。

そして、受入テストの実施。

小規模システムでも、単体テスト項目数５００×１回、受入テストシナリオ数２００×３回

このぐらいすることになりますねー！でも、システムの完成度のレベルは全く違いました！

テストは、システム会社の仕事でしょ！っていうシステム会社とユーザー側（情シス）としての固定概念をすてちゃってください。

システム開発の目的は、『システムで業務を改善したり、売り上げに貢献する』ことですよね？

だから、目的が達成しやすくなるなら、今までの当たり前をすてちゃってください。ごろうは、請負でもこのような対応してシステム開発を成功させていっています。

システムは、ユーザーとシステム会社の共同作品です。

お金払ってるんだから、とか、言われてないことは一切しません！とかより、お互いが協力し合えるところを見つけていくことが大切だと思います。