システム失敗の本質は、「業務システムの本質が判っていないこと」

 

 

前回の続きです。

 

前回、政府システム失敗の本質は、日経ホニャララが宣伝しているようなユーザ側の方針の問題ではなく、

「プロジェクト(事業)自体の構想」と、

「システムや業務の構想」

が、根本的に間違っている、的外れ、方向違い、見当違い、ってこと。

それが「失敗の本質」、と説明しました。

 

 

が・・・、

そもそも、そういったことを指摘する人自体がIT関連業界には誰もいません。

 

今回の特許庁の失敗に関連した記事を見ても、「役所側にSEが必要」とか、チンプンカンプンな意見ばっかりです。

 

はっきり言って、SEなんて100人居ようが1000人居ようが関係ありません。

業務とシステムを見て、プロジェクトの開始から(システムの使用)終了までを見透して、事業の構想とシステムや業務の構想を決めることができる「一個人」 が居るかどうか、です。

 

そういう一個人は、IT業界では滅多にお目に掛かれません。

 

大手ITベンダーのプロジェクトマネジャーなんていっても、

「自社製品をどうやって入れて、どうやってカスタマイズするか」

しか考えたことがありません~、なんてヒトばっかりですから。

 

 

この10年、20年くらい、スペシャリスト礼賛を続けたせいで、事業全体やシステム全体を観る人材は極端に減ってしまいました。

そういう意味で、日経ホニャララ系のIT専門誌の罪は大きいと思っています。

 

 

IBCSやアクセンチュアのような名前のある大手コンサルに発注すればいいや、という責任逃れ的な発想は良く判りますが、大手コンサルにもそういう人材はいません。

(というか、大手コンサルだからこそ、居ないとも言えますね。)

 

 

プロジェクトを成功させたければ、

事業全体やシステム・業務全体について、現実的に実行可能な構想を考えることができる

=業務システムの本質が判っている人材を確保しなければなりません。

 

 

あ、ちなみに、「失敗の本質はユーザが悪いこと」というのは間違ってますが、「ユーザが悪くない」とは毛頭思っていませんから。

 

そもそも、名前とコンサルフィーばっかりでコンサルを選んだのは特許庁が悪いです。

あと、設計と構築を分離して調達をしているみたいですが、アレは最悪の手法です。

 

構築を入札(総合評価でも結果は一緒です)で調達するってことは、

「大したことないベンダーでも作れるような設計をしなければならない」

という制約を設計に課すことになります。

 

世間の、多数の団体で似たような業務をしているシステムの調達ならまだ判りますが、特許庁のようにワンオフで作らなければならない業務システムの調達としては、失敗するリスクが非常に高くなります。

(設計を担当する会社、構築を担当する会社のどちらかが、ダメな仕事をした時点で失敗しますから。

調達額を分割したいんなら、サブシステム単位で発注を分割したほうがはるかにマシです。)

 

 

 

今後システムの再構築に再チャレンジするでしょうし、特許庁のHPを見たらCIO補佐官を募集しているみたいですが、またブランドでコンサルやベンダーやCIO補佐官を選定するようであれば、次の失敗も100%保障されたようなもんです。

 

 

ご愁傷さまですね。

(既に次も失敗するだろうという前提になっちゃってますが・・・(゜д゜;))

 

 

追記:弊社のこれまでのコンサルティング経験をまとめた、「公共団体のための情報システム調達ガイド」を作成しました。
システムの全てのフェーズで、リスクをコントロールし、マネジメントを行う手法をまとめています。

おすすめ

  • コロナ禍の今だからこそ、効率化やコスト削減で業務を劇的に見直すチャンス2020年5月11日
  • 情報システムプロジェクトの成功はマネジメントに依存しない?成功にとって本当に必要な「設計力」とはー2018年10月10日
  • ペイ多すぎ問題~「なんでもペイ」がやってくる日は来るのか?2018年9月20日
  • 第4次産業革命は、AIでもIoTでもなく、分散アプリケーション2018年7月2日

最新

コロナ禍の今だからこそ、効率化やコスト削減で業務を劇的に見直すチャンス
2020年5月11日
情報システムプロジェクトの成功はマネジメントに依存しない?成功にとって本当に必要な「設計力」とはー
2018年10月10日
ペイ多すぎ問題~「なんでもペイ」がやってくる日は来るのか?
2018年9月20日
第4次産業革命は、AIでもIoTでもなく、分散アプリケーション
2018年7月2日
マイキーと聞いて、真っ先に”油性ペン”を思い出す
2017年6月4日