今ある既存の事業だけではなく、ITの力を駆使して自社の隣接市場や新規事業を立ち上げる、また社内業務をシステム化し人的コストを下げながらアウトプットの質とスピードを上げる。そのようなビジョンを抱いている経営者は多いと思います。IT化のメリットは、今まで人が何人もかけて行っていた作業をシステムを用いて一気に機械化するのと同時に、人が大勢で行う際に発生する「ヒューマンエラー」も無くしていきます。電源が止まる、ウィルスでシステムが止まる等のよっぽどな何らかのトラブルが発生しない以上、機械化されたシステムは２４時間３６５日機能し続けます。また人とは違い働く人たちからクレームも出ることはありません。
このITの力、システムの力を借りて新しい事業を創造する、社内システムを効率化するという方向性は時代的に今後多くの経営者、マネージャーに求められるようになってきました。
また、稀に今でもいらっしゃる「私はパソコンが苦手で、、、」という経営者であってもこのIT化、システム化の流れは時代的に無視できない状況になってきたと言えます。人材確保が難しくなってきたことや、かかるコストを適正に制御する視点からも、全ての経営者やマネージャーが未来の事業創造において真剣にIT化、システム化を考える時代に入ったと言えます。
では簡単に既存・新規ビジネスをシステムを用いて成功できるのか？と言いますと答えはNOです。
取り組むだけなら誰でもできます。
しかしシステム開発の世界は年間多くの訴訟が行われています。
システム開発を行いたい企業を「ユーザー」、システム開発を請け負う企業を「ベンダー」と言いますが、ユーザーがしたいことをただ言った通りに行えばいいのか？、システムを作っている最中にもっといいアイデアをベンダーが思いついたとした場合、制作業務を一時的に止めてでもユーザーに伝え、議論する場を持つべきなのか？、いや必要ないからそういうのは要らないなのか？ということがあります。
社内の一般常識ですと、制作中にいいアイデアがあれば仕事を止めてでも上司にそのことを伝えるべきとなりますが、ベンダーは事前に制作予定表を完成してそれに準じて制作を開始していたのであれば、魅力的な新しいアイデアが発見されたとしても、ユーザー側が制作中に起こる魅力的なアイデアに理解が無いと、いいアイデアを伝えたら簡単にじゃぁそれをやってくれ、コストはアップできない（コストアップを承認してもらえる空気で無い）、新たな業務が増えたのに、納期は後ろに延びる事はなくそのまま等で、ベンダー側のモチベーションは著しく低下するなどの問題が事実発生し、ユーザーとベンダー間のトラブルは尽きないというわけです。
また、ユーザーの視点から見ますと、あまりにも専門用語が多い、聞いたことの無い世界の単語が多すぎるということでベンダ側からちゃんと説明を受けてもユーザ側がピンとこないため、結局「言ったことをやってくれ！」的な要求をベンダ側に突きつけてしまい、ベンダー側のモチベーションが落ちてしまうということもあります。
ちなみに上記のようなシステム開発の流れはウォーターフォール型開発と言われ、長年この業界で行われてきた開発・設計手法ではあります。
最近はウォーターフォール型開発に対抗してアジャイル型開発というものがあり、ウォーターフォール型開発で起きうる問題点を解決すべく、業務を小さなユニット内で”設計→実装→テスト”を行うという開発手法もありますが、ここでもベンダーが話す内容をユーザが理解できないため、その場では業務の話し合いがまとまった風に見えても、最後の最後で”何か違う”などユーザが思い出してトラブルになることがあります。
いずれにせよ、自社が求めるシステム開発を行うためには、開発はウォーターフォール型またはアジャイル型？とか、また現存しているパッケージ型をベースに使うのか、それとも基本的に一からオリジナルで作るカスタム型か、などの事前の決め事がちゃんと決められていないと、ユーザー側、ベンダー側相当にとっていい結果にならないのです。
またパッケージ型は既に存在しているシステムであり、ソフトウェアがあったりするのでカスタム型に比べ廉価ですが、パッケージ型の場合ユーザーの望むものに仕様上改良できないものもあり、安いからと言ってパッケージ型に飛びついて開発を始めたものの、途中で越えられない壁が見つかり、改良に改良を重ねたものの、改良コストが高いものの自由度の低いシステムに成り下がって使いづらいなど、結果カスタム型の方が安くていいのが出来たと笑えないことになりかねませんので、ベンダーは事前にリサーチを入れておくことが重要です。
システム設計に取り掛かる前の上流工程（要求分析）→要件定義が命！
ウォーターフォール型開発であろうが、アジャイル型開発であろうが、いずれにせよユーザーが何をしたいのか？をまずは信用できるベンダ－にしっかりと話すこと（上流工程（要求分析）と言います）から始まります。
そしてその案件に対し、ベンダー側がしっかりと細部に渡ってヒアリングすること、起きうる可能性のある出来事について疑問が出た場合はすかさず聞いておくことから双方の関係は始まります。
当社でも明らかにフィーリングが合わないと判断した場合は、見積を出す以前に正直にお断りさせていただきます。
そして直感的に双方がそれなりに信用に値すると判断した場合、先に進み”要件定義”に入ります。
今ある情報と方向性を元に想定できるあらゆる可能性を元に吟味して、現時点で作りたいシステムについての設計ルールつまり要件定義の作成に入るのです。
システム開発・設計において、ものすごく大事な要件定義。どの程度まで大事なのか、果たしてどんな業務なのか？とお思いになる方も多いので参考までに業務のイメージがどんななのかお伝えいたしますと、大体将棋における”詰将棋”のような感じです！
「ゴールを明確に意識して、そこから逆算する」ということです。
プロの棋士の方々が試合中に長考するように、ゴールから逆算してあれがこうな場合どうなるのか？、これがああな場合どうなるのか？」をユーザーの代わりにIT知識のバックグラウンドを元にベンダーは事前に考え倒します。
またシステムエンジニアの人々の世界には、システムを設計することが天才的であっても、ビジネスというか商売に精通していないエンジニアもいます。なので指示されたテーマは機能するという意味でクリアできたとしても、元々の設計書に使い勝手のことが全く書かれていない、またアバウトに書かれていた場合には、とりあえず機能はするが、いまいち使い勝手が良くないシステムが出来上がってしまいます。
このようなユーザーにとっても、ベンダーにとっても不幸にならないように、この上流工程（要求分析）と要件定義が非常に大事です！
ここがほぼ全てと言ってもいいくらいです！
信用できるベンダーを
ベンダー以上にIT化に詳しいユーザーは多分いません。またユーザー側の新事業にユーザー以上に詳しいベンダーもいません。ユーザーとベンダーがシステム開発で手を組むことになれば、ある程度のシステム開発における専門知識がユーザーにも求められますし、またベンダーはシステム設計の前にユーザーの日常業務が何であり、これからやりたいことは何であり、また時にはなぜこれをやろうと考えたのかのその背景まで知る必要があります。そこまでベンダーはユーザーを知らないと本当の意味でいいシステムは作れません。ユーザーの会社のIT部門の社員になりきってユーザーの会社業務を理解する気概が必要です。ユーザー側からベンダーを見て信用に値しないとなれば契約は前には進みませんが、逆にベンダー側からみてユーザーの姿勢や人間性が信用置けないと、フラフラになるまでユーザーの事業を分解・分析しても、資料と見積だけ出して契約にまとまらない、つまり”骨折り損のくたびれ儲け”になるのは避けたいのでベンダーも乗り気にならない交渉になります。
さらに資料を提出したのに折り返しの連絡もなくフェードアウトする可能性がありそう（連絡が雑）、そもそも実現するまで問題が起きてもユーザーは忍耐強く対処できるのか？（早い段階でイライラしがち）など判断させていただいて、ベンダー側が厳しいと判断すればお互いにとって契約は前には進めない方がいいと思います。
最後にシステム開発を発注したいユーザーにとって深く知っておいていただきたいことは、
- 何を目的としているのか？、なぜそうしたいと思ったのか？
- これが実現することにより何が達成されるのか？
- いいものを作るというために、スケジュールはあるものの一時的に業務を止めてでも吟味検討する気があるか？、それに伴い費用の増加は飲めるのか飲めないのか？
- いいものを作るというために、スケジュールはあるものの一時的に業務を止めてでも吟味検討する気があるか？、それに伴い費用の増加は飲めるのか飲めないのか？
- いいのをつくろうとすると初期予算とは別に追加予算が掛かりますよ？
ということを大体知っておいて欲しいということです。
またベンダーのあるべき姿は
- ユーザーはIT化、システム開発に精通していないから、できる限りわかりやすく専門用語を限りなく少なくして説明しようとする姿勢
- 何を実現したいのか？、何を達成したいのか？を聞く
- 納期と質についての文面化。作業を止めて、納期を遅らせることは状況により可能か、不可能か？
- ユーザーのIT部門の社員になり切ったつもりでユーザーの行っている現事業、新システム事業を掘り下げる。ユーザーの顧客の視点も理解する
- 想定される費用、追加で発生する可能性のある費用に関し、わかる範囲内で事前に告知しておく
ということです。
そしてお互いが信用の下に「任せて任せず」で既定のタイミングで都度業務を確認していくことができれば、大きく逸れることもなくユーザーにとっても、ベンダーにとってもハッピーなシステム開発・設計が実現することと思います。