プロジェクトアドバイザー

プロジェクト,アドバイザーメイン画像

新たにシステム開発を行いたい側をユーザー、システム制作を行う側をベンダーと呼びますが、ユーザーとベンダーには住む世界の違いから中々相容れない問題があり、途中で新規プロジェクトは頓挫することがあります。
なぜ相容れない問題が起こるのか?
その問題の一つとして、システム開発を真剣にやればやるほど、通常の生活や業務では経験したことの無い大量の仮説・リスクを検討しなければならないことが生まれてくるからであります。
まじめなシステムエンジニア(以下SEと表記)は、真剣に真摯に業務に取り組むにあたり、かなり細かいリスクや仮説も検討するべきと考えます。
なぜ彼らがそう考えやすいのか?
それは、従来のシステム設計がウォーターフォール型のため、一度決められた作業工程は戻せないというルールがあるからなのです。
一度決められた作業工程は戻せないから、初期にかなり慎重にあらゆることを検討しておくという業界特有の慣習があるからです。
一方ユーザーの視点に立ちますと、かなり細かくいろいろ調べるということは時間も掛かりますし、時間が掛かるということはその分費用も掛かります。そしてそもそもベンダーは仕事をしているようだけれども、本当に仕事をしているの?とさえ疑問に思うかもしれません。
なので、このユーザーの要望をベンダーが聞いて実現可能性を模索する作業である上流工程(要求分析)を行っているときに、ユーザーとベンダーの間が不信感があるまま進むと、質の低い要件定義が行われ、それを元に制作を行ったプログラマーは求められた通りに作ったつもりなのに、クレーム&修正の嵐になってしまうことが起きるのです。後でもめるのです。

ユーザーとベンダーの間に入るアドバイザーとして

ユーザーにとってもベンダーにとっても元々もめたいと考えている人はいないと思いますが、この業界特有の慣習よりお互いの意思疎通がうまくいかないことが起き得ます。お互いの意思疎通がうまくいかないと新規システム開発のプロジェクトはどんどん遅れていきます。またコンセンサスが不能と判断したベンダーは「いいシステムを作る」という目的から「納品すること」がゴールに変わってしまいます。ユーザーもシステムを良くするのに、ベンダーに対して何をどう伝えたらいいのかもわからなくなってきます。もしシステムが出来上がっても、そのような間柄でできたシステムは、確かに動くけど、とても使いづらい、面倒なことが多いなどで実際使用されることは少ないでしょう。
当社はそのようなことの無いように、上流工程(要求分析)からアドバイザーとして参加するサービスをご提供させていただいております。
アドバイザーとして、IT知識が不足気味のユーザーの側に立ってベンダーと交渉します。

  • 下流工程(プログラム等)にも詳しい
  • サーバー環境に詳しい
  • データベースに詳しい
  • セキュリティに詳しい

ことは当然として新たに

  • ユーザーの事業を理解している。現状がどうで何を改善し何を変えることを目的としていることを理解している。

ことをベンダーとの交渉前に徹底的に行います。

アドバイザーが入ることによって何が変わるのか?

当社が入ることにより、ユーザー側がベンダー側に本当に伝えたかった核心部分が、IT業界に精通している私たちの言語でベンダーに伝えられるので、ベンダー側もはっきりと何を実現したらいいのかを理解しやすいし、核心部分を理解するためにいろいろと調べるという行動も減るので、制作に打ち込めます。ベンダー側も意思疎通がしやすいので、不明点があればすぐに話し合いができ、どうすべきか、何をすべきかを決めやすく進めやすくなるので、納期に関してもソフトランディングしやすくなります。

アドバイザーだけでもお任せください

「プログラミングを行う下流工程は知り合いのプログラマーにお願いしたいけど、言ったことはやってくれるけど全く想像力が無いから不安」「自社で新システム開発で担当を任命したけど経験が浅くて心細い」「今のベンダーの信頼関係が正直いまいちで提案が的を射ているのかを自社の視点から判断をサポートしてほしい」「ベンダー側に説明する仕組みの図式化などを行って関係者にプロジェクトの本懐部分をイメージしてもらえるようにするのにバックアップしてほしい」などの弱点を補う上での補強として、当社のアドバイザー業務はお役に立たせていただけると思います。仮にですがもし今のベンダーが作業が出来なくなった場合でも、当社の下流工程を行うスタッフもおりますのでそういう点でもご安心いただけると思います。