投稿

ITにどう向き合う?どう向き合ってもらう?

いろいろな企業様とお仕事をさせていただくと ITに対する向き合い方は様々です。 当座をしのげればというスタンスのお客様もいらっしゃれば ITの持つ可能性を探りたいと考えていらっしゃるお客様も様々です。 私の仕事のスタンスというか、 独立してまで仕事を始めた目的は ITに対する価値と必要性を感じてもらい、 それを事業に生かし、最終的なお客様の企業価値向上につなげてもらいたい。 それも日本の経済を支える中小企業の皆さんに。 なので、入り口として当座をしのげればと考えていらっしゃるお客様に対しても プロジェクトを進めていく上で、そこに気付いていたけるように 理解を進めていただくというのも大きな目的の一つになっています。 しかし、あまりにこれをグイグイやっていくと ものすごく営業活動に熱心な人ととられかねないとも思っていて(^^; 今は、どうやったらそういった押しつけがましさを感じずに ITへの理解を進めてもらえるか?というのが大きなテーマの一つになっています。 今はITのサービスも少人数であれば無料ということもあって トライアルでの導入はしやすいのですが、 トライアルって経験上、本気で取り組まない ことも多く これに失敗すると入り口でコケることになり ITの価値について「大したことできないな」というイメージを抱かせてしまう という恐れもあります。 もちろん、実際に大したことができなければ そう思っていただいてもよいのですが、 ITに本気で取り組んで、まさにDXと呼ぶにふさわしい進化を遂げた企業も実際にある中 そういう思いを抱かせてしまい、企業の可能性の芽を摘むことだけはしたくありません。 なので、今考えているのは もっとわかりやすく、かつお客様に 「へぇ、ITってこんなこともできるんだ」 と思ってもらいやすいソリューションが何かないか? と探しています。 ITに慣れていると TrelloやJiraによるインシデント管理などや データ活用にも興味を抱いてもらえなくもないですが やはりそのあたりになると、ある程度本気で取り組まないといけない ある程度ITリテラシーが育っているというような企業でないと 価値が感じてもらえません。 chatbotなどもそうですね あれも「入れれば夢の世界が」みたいなことがよく謳われていますが 満足に稼働させるまでの下準備がとっても大変 です。 ラ...

カスタマーファーストはあるのか?

プロダクトアウトではなく、カスタマーファースト この言葉がよく聞かれるようになって久しいですが、 じゃあ、IT会社(ITベンダー、SIerともいいます)は本当にカスタマーファーストって考えているか? について書きます。 結論から書くと ほぼ考えていない です。 なので、事業会社の人はIT会社の言うカスタマーファーストなんて言葉を真に受けてはいけません(^^; ※この記事はちょっとうまく書くのが難しくて、何回も推敲しました(笑) まず、この記事におけるプロダクトアウトとカスタマーファーストの定義から書いておくと。 【プロダクトアウト】 作ってる側の都合で売るという事です。 作ってる側が「こんだけいいものが作ったんだから、これを使わない手はないでしょう?」 という思いで世に出して、売っていく。 プロダクト(製品)ありき、これがプロダクトアウトです。 【カスタマーファースト】 お客様が欲しい物を用意して提供するという事です。 マーケットインという人もいます。 まず需要ありきという考え方。 このカスタマーファーストですが 実際にIT業界でも非常によく口にされます。 お客様の事を考えて、お客様の必要とするサービスや製品を用意する。 こういう意味で使われることが多いのですが これが実際に口で言った通り実現できている会社は ありません。 その理由もいくつかありますが まずは、ITサービスを提供する会社にも様々なスタンスがあるので それを整理してみます。 問屋さんのように他の会社のシステムを仕入れて、お客さんに提供する会社 上に書いたように、数限りなくあるシステムをすべて把握するのは無理なので、ある程度売れそうなものに的を絞ってラインナップを作り、あくまでその中で「お客様に適切なのはこれです」といって売ることになります。 ただこれって、よく考えるとプロダクトアウトとあまり変わりません。 システムを導入する際にコンサルティングサービスを付けます。などと言って ちょっとカスタマーファーストっぽく言っていますが、結局そのコンサルティングの内容が サービスに寄せていく内容だったりするので、つまりはプロダクトアウトです。 システムそのものを作っている会社 では、そもそもシステムを作っている会社なら、自社製品なので如何様にもいじれるし、実現できるのではないか? というとそうでもありません。 確...

オペレーションをガイドするというソリューション

イメージ
今月はEXPOが幕張メッセで開催されたので お客様に情報提供できるように商材の情報収集に行ってきました。 その中でもちょっと面白いと思ったものを紹介しておきます。 別に紹介料とかはもらっていません(笑) ・リテラアップ(Litera App) https://litera.app/ このアプリはパソコン上で本人が行った作業を見ていて、 「それならこのショートカットキーが使えるよ?」 とリアルタイムで教えてくれるアプリです。 例えばExcelでセルの表示形式を文字列から数値に変えようとした場合、 セルを右クリックして、セルの書式設定を左クリックしますが それをした瞬間、常駐しているリテラアップが 「Ctrl+1を押せば一発だよ」 と教えてくれる。 そんなアプリです。 正直、このアプリを最初に聞いた時は 「これ、いるかなぁ・・・」 と思いました。 だってショートカットーキーなんて、別にググればいくらでも出てくるし わざわざ金払って教えてもらわなくても・・・・ね。 と思ったのですが よくよく考えてみると、それってずっとITの世界にいた人間の発想でしかなくて いわゆるITに不慣れな、世間一般の人からすると 「そもそもショートカットキーってなんですか?」 っていう話だということに気が付きました。 そんな人がわざわざ本読んで調べて、ショットカットキーを覚えるなんてするわけはないのに 安直にも「調べれば出てくるしねぇ」なんて思ってしまった辺りが、相手の立場に立ててないってことですね・・・。 このアプリを使えば、別に本を買わなくても、ショーtカットキーが何なのか何も知らなくても アプリが「こっちの方が近道だよ」と教えてくれるので、このアプリが常駐していると おのずとショートカットキーに詳しくなっていきます。 で、ショートカットキーに詳しくなると何がいいのか? というと、 作業のスピードが爆上がりします 。 これは実体験からいえるのですが、私がまだプログラマーとして働いていたころは 先輩にアドバイスしてもらったこともあり、 できるだけマウスを使わないで仕事をすることを心がけていました。 そのうち、ほとんどの作業をキーボード上でできるようになり その結果、同僚に説明をしたりするときも 「うん、ちょっと画面の切り替わりが早すぎて何が何だかわからん」 と言われるほどのスピードになっていまし...

ITの責任者にITを知らない人を起用してはダメな理由

一昔前ならいざ知らず、だいぶ当たり前といえば当たり前になってきた話題ではありますが いわゆる伝統的な内資系事業会社では、いまだに起きていることだったりするので 改めて書いてみます。 なぜダメなのか?の理由の代表的なものを書いておくと A. ITプロジェクトは建設業界のような重層下請構造になることが多い為、勝手がわからないとコントロールしにくい構造になっている B. ITと一口にいても分野が広すぎるので、なにかしらの専門分野やバックボーンがないと、コストに関するアタリがつけられない C. 会社のIT化が進まなくなる この3つかなと思います。 この3つをもとに様々な影響が派生してくると思っていて、 例えば、 A. のケースですと ・単純にプロジェクトが失敗する ・立ち上げ時点で無理筋なプロジェクトを承認してしまう とかです。 B. のケースですと ・妥当なコストなのにも関わらず、「高すぎる」と判断して、ベンダーを切ってしまい、運用が立ちいかなくなる またその逆もしかりです。 今回は特に C. について、言及してみます。 ・会社のIT化が進まなくなる とは ・IT技術者が定着しない と言っていいと思います。 そして、IT業界は他の業界に比べて転職のハードルが低い業界です。 これもだいぶ認知されてきた事実だと思います。 理由はいくつかあると思いますが ・IT技術者の絶対数の少なさ からくる ・年収の上昇 ・市場にあるポジションの多さ ・競争にさらされることによる技術者本人の危機意識の高さからくる、技術への貪欲さ などが相まって IT技術者の転職枠(需要の多さ)と本人のスキルアップの意思が、旨くかみ合って 転職へのハードルが下がり、なおかつ技術者も転職していくことになります。 そして、競争にさらされる中で、転職に臨もうとするIT技術者は ・一定以上、自分の実力に自負がある人 だったりします。 (あと、競争につかれて嫌になった人も一定数います(笑)) この自負が妥当なものか?自意識過剰なものなのか? はさておいて、こういうある種のプライドを持った人たちが転職先に求めるものは ・自分に対する妥当な評価 ・自分にふさわしい仕事 こういった点を求めます。 (繰り返しますが、妥当な評価が市場の評価であるかどうかは、ここではさておきます。) そしてこれがある程度満たされないと そもそも内...

独立します 追記

独立をしてお仕事をしていく中で 中小企業の皆さんのIT化を進める という私のミッションが順調に進んでいった場合 おそらく何度も頭をよぎるであろう注意点を記録に残しておこうと思います。 私は企業の中で働く過程で、扱いに非常に気を付けなくてはと思った言葉が一つあります。 それは ・スケールさせる です。 これは仕事の規模を拡大させるという意味ですが 私にとって、これは手段以外の何物でもありません。 しかし、これまでサラリーマンをやってきた中で このスケールさせるということが≒目的になっているシーンを数多く見てきました。 代表的な例で言うと 「その仕事ってスケール出来るの?」 っていう発言だったりします。 これが 「それって世の中に需要あるの?」 という意味だったらいいんですが、実際はそうではないことが多く 「それって売り上げ拡大できる仕事なの?」 っていう意味で使われることがすごく多いです。 (ちなみに「需要があるの?」を「大きな売り上げを期待できるの?」という意味で使っている場合もあります。) これは私の中では相当意味が違うと思っています。 世の中に需要があるの?っていう意味は 必要としている人がいて、それをやる意義がそこにあるのか? という意味なので、納得できるんですが 売上拡大できるの?は 会社の利益になるの? ですよね? 私は後者の発言があまり好きではありません。 何故かというと順番が逆になっていると感じるからです。 よくこういう議題が取り上げられるときは 「いや、売上が上がらないと事業が存続できないんだから、企業が売上を第一と考えるのは当たり前」 という理屈が使われると思うんですが 私はその理屈の大前提として 「その企業が社会にとって必要である」 が先に来ると思っています。 この前提がないと 「社会に必要のない企業が、ありもしない需要を作り出して売り上げを拡大する」 という妙なことになると思うからです。 私が独立すると決めた目的は 本当の意味での中小企業のIT活用を助けること というものですが、あまりスケールすることを考えていません。 何故ならスケールすることを第一に考え始めると 事業の違う中小企業に、標準化された画一的なサービスの提供をして効率化を図る というようなことを考え始めると思うからです。 すごくややこしい話ですが 標準化したサービスを提供するのはい...

独立します

この度、独立することになりました。 ちょっと長くなりますが、せっかくなので何故独立しようと思ったのか? を記しておこうと思います。 初心を忘れないために。 私が今回、独立に至った直接的な要因は2つだと考えています。 1つ目は 2019年から始まったコロナ禍により急速に浸透したリモートワーク 2つ目は 日本経済の低迷からくる(?)企業の副業推進 です。 この2つの出来事が全ての始まりです。 私が当時所属していた会社は、コロナ禍においてフルリモートワークに踏み切りました。 それまで私は自分が副業をするなどという事は全く想像もしていませんでしたが 会社がフルリモートワークを導入した結果 ・通勤時間が無くなり、自由に使える時間が増えた ・物理的な距離にとらわれず仕事ができる環境ができた この2点に加え ・会社の副業推進 が合わさり、少し副業をやってみようかなと思いました。 また、リモートワークが始まったことにより 規模の大小を問わず企業は打ち合わせをwebで行うようになり これまでIT投資をしてこなかった会社は自社にITの専門家がいない問題に直面し その打開策として、副業人材に答えを求める会社も現れてきました。 ここで私のITスキル(供給)と企業のIT人材不足(需要)がマッチし、 私の副業が本格的に動き出しました。 副業の内容自体は、私がこれまでやってきたことでもあるので 大きな問題は起きませんでしたが 私の心理的には大きな気付きを得ることが出来ました。 それは ITは本当に必要な場所に届いていない です。 私はこれまで情報システム部門を自前で抱えることのできる企業しか お客様としても、自身の所属先としても考えてきませんでした。 (勿論、仕事がそこにあるからなのですが) しかし、それは言い換えるとそれだけの資金力のある会社としか 仕事をしてこなかったという事です。 しかし、改めて副業人材としてお仕事をする場合 お相手をするのは、 情報システム部門という固定費を抱え込むのは難しい企業 になります。 私が仕事をしている中で気が付いたのは ITが必要なのはまさにこういった企業だ という事です。 ITは端的に言うと人を楽にするためのものです。 それを使う事で、今までの作業が楽になったり 新しい何かができるようになったりするものです。 そして、それが必要なのは 人手がなかったり、新し...

システム導入後の効果測定をしないわけ、したがらないわけ

一定程度の規模感のシステムを導入するとつきものなのが そのシステムを導入した結果、得られた効果の測定です。 しかし、これはとても現場に嫌がられます。 何故かというと システムを導入することで得られる効果として、考えられがちなのが 省力化 だからです。 となると、いわゆる偉い人達は 効果=どれだけ工数(稼働時間)が減ったのか? と考えがちです。 稼働時間=人件費だからです。 そうすると、 システムを使う側の人間からすると必然的に 効果が上がったと報告すると人を減らされる? と考えます。 これが今回の記事の全ての元凶になります。 これは、リーダーの立場からすると 「これ以上人を減らされたら、どんどんチームはきつくなる」 と考えますし メンバーの立場からすると 「え?削られるのは自分?」 と考えます。 ので、 効果があったとしても、効果ありましたとは言いたくない いわゆる偉い人は自身も働いていた側だったことがある人が多いにもかかわらず 何故か、この現実を見て見ぬふりをします。 自分が言われたら?言われた時にはどう思ったか?を忘れてしまったのでしょうか? (単純に自分に関係ないと思っているからだと思いますが・・) しかし、現場に嫌がられるからといって たくさんのお金を使ってシステムを導入したのに 「その効果のほどはわかりません」 では、あまりにお粗末です。 なので、効果計測はやはりしたい。 そこで大事になるのは経営側の想いです そもそもシステムを導入して何をしたかったのか? ・省力化を図りたかった ・そうではない別の効果を求めた そしてその思いが システム導入前にちゃんと謳われているか? です。 省力化を求めているのであれば 効果計測として、どれだけ稼働時間が短くなったか? を問うのは正しいですが、この場合大事なのは プロジェクト開始前にそれを関係者にちゃんと周知していたか?になります。 今から入れるシステムは省力化する為のものだから、 そのつもりでみんな参加しなさいよ と言わないと、システム導入の際にみんな省力化する為の活動をしません。 それをちゃんと落とし込まずに システムを入れ終わった後に、いきなりそれを言うのは従業員からすると不意打ちを食らうようなものです。 なので、省力化を目的としたシステム導入なのであれば プロジェクト開始前に、プロジェクトの目的の明確化とその周...