松田軽太のブロぐる

企業の情シスで働いています。会社の中では何をしてるのかナゾな職場の情シスあるあるなどや読んだ本のことなどを思いつくままに書いています。

【スポンサーリンク】

情シスに配属されたけど、仕事が上手くいかなくて悩んでいる人は『システムを「外注」するときに読む本』がオススメ!

【スポンサーリンク】

最近の情シスの主な仕事ってITベンダーと自社部門の間のつなぎ役がメインの仕事になってませんか?

こんにちは! 松田軽太です。

 

しかし、これ、けっこう辛いですよね。

 

発注主の会社がどんな作業をしているのかITベンダーは分からないし、自社部門の人たちはシステム開発のことが分からないので、情シスってその間で板ばさみになってしまいますからね。

 

話の通じない人たちの間で通訳をするのってけっこう精神的にキツイものがあります。

なんとシステム開発の5割は失敗プロジェクト

今の時代、それなりの規模の会社であれば、なにがしかの業務システムが運用されていることでしょう。

 

販売システム、在庫管理システム、生産管理システム、会計システムなどなど、様々なシステムが稼動しているはずです。

 

これだけたくさんの会社で導入されている業務システムですが、システム開発の実に5割は失敗プロジェクトになっているのです。

 

「え?そんなに失敗してるの?」と思うかもしれませんが、数年前は7割が失敗プロジェクトだったので、これでも良くなった方です。

 

でも、なぜこんなにたくさんのシステム開発が失敗するのでしょうか?

 

それは「正しいシステム開発の外注管理の方法を知らないから」なのです。

 

よく「情シスの仕事はベンダーコントロールだ」とか言われていますが、果たして本当にコントロールできていますか?

 

実際のところ、ITベンダーの出した見積もりに「もうちょっと値段を頑張ってくれないと役員に稟議を出せないよ」と根拠のない値引きを乞うのがベンダーコントロールだと勘違いしている人もいるのではないでしょうか?

 

そしてゴネた値引き額をコストダウンした実績だと業績評価として報告してたりしませんか?

 

でもそれってコントロールではなく、ただの値引き交渉です。

 

なので、システム開発をITベンダーに発注する仕事を担当している人は

『システムを「外注」するときに読む本』を読んでみるといいでしょう。

 

システムを「外注」するときに読む本

システムを「外注」するときに読む本

 

 

 本書の主な内容は以下の8つ

①要件定義に欠かせない「業務フロー図」の書き方

②「プロジェクト管理能力」でベンダを見極める方法

③ベンダが一緒に仕事したくなる発注者、見捨てたくなる発注者

④プロジェクトメンバーの「モチベーション」の上げ方

⑤社員の意識を変えるために「経営トップ」がやるべきこと

⑥みんながシステム担当者に 協力してくれる「しくみ作り」

⑦トラブルを回避する「リスク管理プロセス」

⑧ダメージを最小限に抑える「セキュリティ対策」


これらのどれも大切な内容ですが、個人的には⑤の『社員の意識を変えるために「経営トップ」がやるべきこと』が印象的でした。

 

この章では社長が最近流行のデジタル・トランスフォーメーション(DX)に取り組んだものの、経営陣も業務担当者も「他人事」と捕らえており、ITベンダーと社内部門の間に挟まれて情シスの課長が右往左往するという状況から物語が始まります。

 

特にDX案件ではこういう事例って多いのではないでしょうか?

 

人口減少や超高齢化という日本の未来を考えると、経営陣が不安になるのは理解できます。

 

しかし問題は不安の解消するための手立てとするDXの具体的なイメージを経営陣自体が理解できていないフワフワした状態で「とにかくなんとかしろ!」と掛け声だけが大きくなってしまって、結局、すべてが空回りしてしまうという。

 

DXというのはその名のとおり「デジタルで経営を変革させる」ということです。

 

つまり今までやってきた勝ちパターンのビジネスモデルとは全く異なった方法で事業を行うことです。


だから経営陣にも社内部門の人たちの全てが覚悟を持って取り組まなければ成しえないハズです。

 

しかし過去の勝ちパターンから抜け出すことは難しいのが現実です。

 

このような場合、往々にして間に入った情シスにしわ寄せがくるのです。

 

一番、大切なのは何をしたいのかを明確にすること

①の『要件定義に欠かせない「業務フロー図」の書き方』の章では、要件定義のやり方について物語が展開します。

 

システム開発をする場合、まず大切なのは要件定義になります。

要件定義とは『システムを使って何をしたいのか?』を取りまとめることです。

 

しかしDX案件では、これが思った以上に難しいのです。

 

在庫管理システムや生産管理システムであれば、今現在も作業効率が良いか悪いかはともかく、現在も自分たちで行っている業務だから、何がしたいのかを業務担当者自身がイメージすることは可能でしょう。

 

しかしDXのように「まだ自分たちが使ったことがないシステム」だとイメージが漠然としてしまいます。

 

それをいかに具体化するのかという部分が大切になるのです。

 

日本ではユーザー企業にIT技術者が少ない

情シスの中で内製する技術や環境があれば「自分たちで業務システムを作る」という

経験をしているのでDXであっても、システム開発に必要な要素を洗い出すことはしやすいかもしれません。

 

しかし、多くの会社でパッケージシステムが導入されるようになってからは自社で内製して業務システムを作ることは少なくなりました。

 

事実、IT技術者の割合は海外と日本では大きく異なります。

 

海外ではIT技術者の多くはユーザー企業に所属しています。

 

しかし、日本ではIT企業の多くがSIerと呼ばれるシステム開発会社に所属しているのです。

 

そしていつしか情シスは業務システムを開発するのはなく、ITベンダーから見積もりをとることが仕事になってしまったのです。



情シスの役割が「ITベンダーと社内部門の間を取り持つ」のが仕事となったのであれば、是非、本書『システムを「外注」するときに読む本』を読んで、自分の職場環境を重ね合わせてみると良いでしょう。

 

きっと大きなヒントをもらえるハズです。

 

システム開発についての問題点はこちらの記事にも書いてますのでご覧ください。

 

www.matudakta.com

 

  

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

 

 

モメないプロジェクト管理77の鉄則

モメないプロジェクト管理77の鉄則

 

  

紛争事例に学ぶ、ITユーザの心得【ユーザとベンダの役割分担・信頼関係・他編】 (EnterpriseZine Digital First)

紛争事例に学ぶ、ITユーザの心得【ユーザとベンダの役割分担・信頼関係・他編】 (EnterpriseZine Digital First)

 

 

【スポンサーリンク】