sample blog

ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。ブログの説明です。

はてなブログのテーマのサンプル記事です。

f:id:nasust:20170110150654j:plain

こんにちはnasustです。
本日で今年最後の記事です。読者様やブロガー様にはお世話になりました。

今年最後の記事の内容ですが、ITで生産性向上の話です。 僕は昔の正社員の頃やフリーランスになってからも組織運用効率化の為に、 フルスクラッチシステム開発する事があります。

日本人の低すぎる生産性と、IT打ち壊し百姓一揆 – Hideto Ishibashi – Medium

この記事でITシステム導入で抵抗勢力が居る為にシステム導入しても、うまく生産性向上出来ない事が書いてあります。ちょっと極端ですけどね。

何故、オーダーメイドで開発したシステムで生産性向上できないのか、それは様々な要因があります。 開発側から、その話しをして行きます。

そもそもシステム導入の熱意があるのか

大体のお客さんはITでシステム向上ということがピンと来ていない事が多いです。 上層部から部下に「ITシステム導入で生産向上しろ」という命令で担当となり、それから担当者からシステム開発の相談される事があります。 しかし担当者自身がITシステム導入で本当に生産性向上するのか把握出来ない為に熱意が薄い場合があります。

何故、把握できないのかはITの技術など分からないからです。分からないから生産性向上の想像も出来ずに、とりあえず命令だから進める事もあります。

それで失敗する場合もあります。

では熱意を高めて貰うにはどうするかは、事例や技術の概要をプレゼンすることです。

事例や技術の概要をプレゼンする

担当者に、「こういう事例や技術があるから生産性向上できるんだよ」とプレゼンすると「へー」という感じで、参考になって生産性向上のシステムを想像してくれます。

それから、担当者がこういう事やりたいと話は弾みます。それを繰り返してヒアリングして要求要件が分かってきます。

このヒアリングが上手く固めないと失敗します。

要求要件を固めたら、新しいシステムの概要を文章にしてプレゼンします。

新しいシステムの概要をプレゼンする時は簡単に分かりやすくすること

プレゼンの時にITの人がプレゼン失敗しがちなのが専門用語で説明してしまう事。 専門用語でプレゼンしたら理解できずに??となります。

単純に、この業務を自動化しますよ。業務処理のスピードが上がりますよ。 グラフや数字で分かりやすくプレゼンすると良いですね。

出来れば生産性向上の事例を説明して、それと同じ様な事しますよと話した方が理解が進みます。

そしてプレゼンが終われば質疑応答して、疑問点や問題点など改善して行きます。

もし専門用語だらけでプレゼンしても、プレゼン自体が分かりませんという反応を見せずに進む場合があります。自分で分かりませんと言う人は少ないからです。なので分かっていないのに、分かった振りして進む場合があるので注意です。

そして設計書を書いて、承認してもらえば開発スタートです。

開発して早い段階でデモした方が良い

いくら分かりやすくプレゼンしても、所詮人の想像力なので思い違いや、実際に動いてから要求と違う事があります。

その問題を早期に解決するには、出来た一部分だけでもデモしてくことです。そうすると担当者はシステムが開発されている事に実感を持ち、問題点や改善案など出してくれます。

よく開発で全体的に出来てからプレゼンが多いですが、その段階で問題発見だと改善の為に大きな負担が掛かりますし、デモまで期間が空くと担当者の熱意が薄れてしまう可能性があります。これで失敗する場合もあります。

なので、開発、デモ、改善のサイクルを短時間で回した方が失敗しないです。どうしても時間が無い場合はスクリーンショットを送るだけでも効果はあります。

後続して開発することを約束すること

システム開発して導入してもらっても、導入して初めて分かる問題などありますから導入後でも改善できるように約束して置きましょう。

担当者には一発の導入だけでは100%満足しない事を予め相談しときましょう。一発勝負では失敗します。

改善の為の継続的な契約でも良いですし、改めて改善開発の案件にするにも良いです。

お客さんの予算の都合で、次の開発は半年後か来年になる場合があるので、開発のプログラムソースなどは、しっかりとバージョン管理しときましょう。

ここまでしても成功しない場合がある

担当者と開発の間は上手くいっても運用の面で失敗する場合があります。僕が知っている極端な事例ですが、そもそも運用で使う人がパソコンを使えないという致命的な場合があります。あるWEBページのフォーム入力で30分以上時間が掛かり、システムから「タイムアウトしました」という典型的なうまく行かない例があります。

こういう場合は勉強会など行います。場合によっては自分が講師となって勉強会を開いたりします。こういう新しいシムテムは根付くのに多大な努力が必要です。ほとんどの社員にとっては他人事なので、時間と根気を掛けて根付かせてもらうように担当者は努力しなければなりません。

開発側から離れますが、他のも失敗する原因として、担当者より権限が強い上層部の人が抵抗する場合です。この場合は味方の上層部の人から説得してもらいましょう。もし味方の上層部が動いてくれないなら失敗したような物です。

ですのでシステム導入では味方を増やした方が良いです。担当者だけで完結していると空回りになります。色々な部署に味方が居ると良いですね。

システム導入しても、この辺の根付かせる努力していないか、しても成功していない場合が生産性向上の失敗します。ですのでシステムを会社の一部にするという行動をしなければなりません。

最後に

いきなり大規模なシステム導入じゃなくて、小さなことから改善した方が時間が掛かりますが導入しやすいですね。その方が運用も慣れていくので根付きやすいです。