プログラミング的なSomething

プログラミング的なSomething

ITエンジニア(?)目線で生活・自転車・トレーニング話を綴ります

ユーザ視点で読む「なぜ、システム開発は必ずモメるのか?」から地方IT利活用に思いを馳せる

「なぜ、システム開発は必ずモメるのか?49のトラブルから学ぶプロジェクト管理」を読みました。

登場人物5人の登場人物の会話形式で進んでいきます。主人公はIT紛争を専門にした弁護士の女性「有栖川塔子」、そしてSIerの男女、ユーザ企業の社員、その社長らが、日々の仕事の悩みを主人公にぶつけるフォーマットで進んでいきます。

なぜ、システム開発は必ずモメるのか?  49のトラブルから学ぶプロジェクト管理術

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

ユーザーに求められることは多くて当然

信頼と契約の上に成り立つ二者の関係は、仕事結果と請求書処理の積み重ねによってしか構築されない。のだということを痛感させられます。

筆者がベンダ出身であるため、本書にはベンダを叱責するように感じてしまう記述が散見されますが、信頼関係の構築に欠かせない「ユーザーが満足するベンダの仕事」はユーザーの手助け、ベンダの仕事への理解がなければ絶対に達成しえません。ゆえに、本書の章毎にまとめられている「プロジェクトを円滑に進めるチェックシート」に準ずるものは、ユーザー側でも内容とその背景を理解する必要があるのでしょう。

本書に「(ベンダは)正当な費用を理解できないところとは商売してはいけない」旨、記述があります。ユーザーは座して待つ存在ではなく、ベンダのサービスを受けるために動ける人間である必要があるのです。「(ITが専門外で)理解できない、わからない」と一点張りするのはかなーり危険信号。ベンダが正当な費用を請求できないところと商売しなくなれば、ある時誰からも相手にされなくなる恐れありです。

モメても他人の責にすることを考える前に、モメないメソッドを本書から取り入れましょう。

そして感じるSIの違和感

本書で言う正当な費用を理解できない相手というのは、この場合スキル不足のユーザーと捉えられます。この場合は本書なりで知識を付ければ「商売相手」になれるのでいいのですが、最初から費用を支払う予算がないとどうなってしまうのか……。

gothedistance.hatenadiary.jp

丁度ホッテントリにあがっていたこちらの記事に思いを馳せました。ITは誰にでも使える利器であって欲しいと願います。事実、一般消費者向けのWebサービスは人々の生活を(地方だろうがなんだろうが)便利に変えています。

地方のIT利活用が「そもそもお金がない」+「(スキル不足で)商売相手にならない」の二重苦で遅々として進まない状況は地方出身者として心が痛い。

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

最近はSIにかわる別のビジネスモデルも登場しています。何かひと噛みできないか、なんてことを日々考えています。といったような取り留めもない終わりになってしまいましたが、「なぜ、システム開発は必ずモメるのか?」はユーザー目線でも読む価値ありです。