中小企業に最適なITソリューションって何？

前回の記事では チームの運用保守体制を整える為の 最初のアプローチとして、基本的な知識を机上で学ぼうとしたものの、 上司の意向でそれをなすことが出来ず、業務に参画していく事になった というお話をしましたが、 次に私が直面したのは 異様に多い会議体 でした。 この会社では会議が本当に多く、それによって手を動かす時間が大幅に削られ 結局、定時後でないと作業が出来ず、残業がかさむという事が常態化していました。 この「会議体が多い」というのは、 もっと根本的な、この会社の風潮というか体質に起因するところが大きいので 会議体が多いの話の前に、そこの話をしておこうと思います。 要参加扱いの会議体がどんどん増える理由は以下の通りです。 1.会議に参加することに意味があると考えている（いるだけで学べると思っている） 2.一度参加すると、立場が変わったり、会議の目的が変わっても参加し続けないと何故か「逃げた」扱いされる 3.役割分担が明確になっていないため、とりあえず手当たり次第に参加メンバーを広げる 私が今まで経験してきた中で、特に上記の傾向の強い会社ではありましたが 多少はその傾向があるという会社は多いと思います。 ちなみに、上の3つの理由のいずれも会議に呼ぶ理由にはなりません。 1.会議に参加することに意味があると考えている（いるだけで学べると思っている） 会議は何かを決める場であり、OJTの場ではありません。ここに参加するだけで学べるものがあるとしても微々たるもので、優先度の高いことは他にいくらでもあるはずです。 2.一度参加すると、立場が変わったり、会議の目的が変わっても参加し続けないと「逃げた」扱いされる これは言うまでもないと思います。この風潮のせいで、会議が減らず、増える一方となります。おそらく少しでも知見のある人間を確保しておいて、何か起きた時のためのリスクヘッジや、責任分散を意識してこうなっているのだと思います。 3.役割分担が明確になっていないため、とりあえず手当たり次第に参加メンバーを広げる これももっと根本的な問題が潜んでいますね。誰に何を聞いたらいいかわからないというのは、組織の中にどういう役割があって、それに誰がアサインされているか？という事が明確になっていないという事で、リソース管理もままならない状態だと言えます。 この3つの要因のせいで、ただでも少な...

システムの仕事はサッカーのようなチームスポーツと似ています。 チームワークが非常に求められる点や 監督にあたるプロジェクトリーダーの資質で成否が大きく変わる部分などです。 どんなに優秀でも１人が２役こなせないということもあり、 チームワークを求められるシーンは多めです。 例えば、炎上プロジェクトをなんとかしようと考えた場合、 スーパープレイヤーを一人投入したぐらいではどうにもならないことがほとんどで （要因にもよりますが） 監督を変える、もしくはチーム単位でゴッソリ人を入れ替えるなどの荒療治をしないと 解決できないことが大半です。 今回はこのチームワークにおける 会社間の協調性の重要さについて書いてみたいと思います。 ITプロジェクトには様々な立場の人間が集まっているというのは 以前の記事に書いた通りです。 あわせて読みたい 多重下請け構造の各社はどういう思惑でプロジェクトに臨んでいる？ それぞれに立場も思惑もあるというのは記事に書いた通りですが、 そもそもプロジェクトを成功させるために集められているわけですから 心中はどうあれ、プロジェクトを成功させるというのが表向きの共通ゴールではあります。 で、その共通のゴールに向けて 全員の目線を合わせるというのが、非常に大事なのですが やはりそこはそれぞれの思いがあるために、容易にはいかないというのが実情です。 ちょっと話をイメージしやすくする為に簡単な絵を描いてみました。 ある程度の規模のプロジェクトになると、こういうチーム構成になることが多いのですが、メンバー間の思いよりも、会社間での思惑が前面に出始めると炎上プロジェクトの兆しです。 例えば ・社内SEがコンサルにすべてをゆだねて思考停止し始める ・コンサルが守備範囲をこれ見よがしに線引きし始める ・SIerが品質ではなく、納期のみ考え始める 勿論、それぞれの会社に思惑があるのは当然なのですが プロジェクトの只中で実際に働いているメンバーからすると、 そこを超越したスタンスで仕事に臨まないと自分の首が締まることになります。 例えば コンサルであれば、あからさまな線引きをし始めることで、ユーザーから強烈にプレッシャーをかけられ、胃が痛くなるのは現場のメンバーですし、 SIerであれば品質を度外視して、不具合を呼び込んでしまったら、残業を強いられるのは自分たちです。 社...

さて、火中の栗を拾ってしまった私ですが この運用は想像以上に大変でした。 ここからのStoriesはしばらくFoxシステムのキャッチアップをどうするかという話が続きます。 このFoxシステムの面倒を見る際の一番のネックは 過去の記事でも書いたように、このシステムの全容を理解できているのが 自社に一人もおらず、外部の人間だけという点です。 【あわせて読みたい】 Stories　9話：カットオーバー後の問題点 これに加えて、 私が関与しないところでいつのまにか発生する新規案件 何故か新しい仕事をよそから持ってくる元リーダー 移管しようという意思が薄い（やり方がわからない？）コンサル 次々と新しい環境を作り、連携先も目まぐるしく変えるインフラ部隊 言う事が相反する二人の上司 といった形で問題山積です。 後から思えば、システムの内容をキャッチアップすることは後回しにして プロジェクト管理の部分だけをコンサルから巻き取って、 リソース管理、進捗管理だけでも手元に手繰り寄せるというやり方をとるのがおそらく唯一の正解だったのだと思います。 ただ、この時は 1.引継ぎを受ける社員メンバーが私を含め二人しかいなかった 2.経営からは、一刻もはやくノウハウを自社メンバーで吸収せよという催促がきていた という要因もあり、 システムの事がわからないまま、管理業務だけ巻き取るというやり方では2点目の要求を満たせないと判断したので いわゆる真っ当なアプローチで臨みました。 急かされてるとは言いつつも、メンバー含めてこのFoxシステムの事が全く分かっていないので まずは、このシステムについての知識を得なくてはいけません。 幸い、構築したコンサルのメンバーはまだいるので、当座の案件についてはコンサルに任せて、メンバーにはドキュメント類の読み込みを始めてもらいました。 勿論、ドキュメントを読むという事で動いているシステムの深いところを理解するのはできませんが 何しろ、飛び交う単語の意味すらわからないので、まずはそのレベルから追い付かなくてはいけません。 それが終わり次第、案件に入り込み、徐々にコンサルから仕事を巻き取っていこうと思っていました。 しかし、この最初のアプローチから、いきなりプロジェクトリーダーから物言いがつきました。 曰く ドキュメントを読んだところで、実務には役に立たないからなんでも...

今まで社内SEとして働いてきて、これもあるあるの一つになるのですが、 DXとかIT推進とかでまず最初に手掛けられるのが紙の電子化です。 そして、いきなり 今ある帳票類は全部電子化！入力もタブレットを導入してそれで済ませる！ まで突っ走る上層部の人が多いのですが、 大体失敗します。 で、その失敗を導入ベンダーのせいにしたり 自社の人間にはITは難しいと従業員のITリテラシーの低さのせいにしたり というように結論付けちゃったりすることがあるのですが、 これは大きな誤りですし、そんなことを繰り返していると、 いつまで経っても、IT推進できません。 気持ちはわかるのですが、これはこの間までミニカーで遊んでいた子供にいきなり業務用ドローンを渡して こっちの方が絶対面白いからやってみ？ ↓ なんで出来ないの？ ↓ ラジコンとか向いてないのかもね！ みたいな論調で迫るのと変わりません。 世の中にドローンというものがあるから、ドローンを導入しよう という発想が許されるのは、今までにIT投資を継続的にしてきていて、 ラジコンヘリコプターまで導入済み というような会社です。 でないとハードルが高すぎて、お金をどぶに捨てることになります。 それにそもそもドローンを導入したら自社の問題解決が図れるか？ という点をしっかり検討せずに、ドローンありきで導入を検討しているようなことが多いので よしんば使えたとしても、それによって何が解決できたのか、なんかよくわからない みたいなことになることもあります。 IT投資を行うという事は、当然そこに問題があるからやろうとしているわけで その問題を解決するためにはそれ相応の手段をもってあたるべきです。 例えば、DIYを始めようとしたとします。 ①【課題】素材に穴を開けるのが大変 　 →【解決】電動ドライバーを購入 ②【課題】硬い素材を取り使うので、今までの電動ドライバーでは穴があけられない 　 →【解決】インパクトドライバーを購入 ③【課題】断面が荒いので、組み立てたときにがたつく 　 →【解決】鉋を購入 というように徐々に課題自体も難易度が上がり、解決策も上級者向けになっていくものです。 しかし、何故かIT投資となると、 素材に穴を開けるのが困っているのに、鉋を購入しようとしがちです。 そして、鉋を購入しても当然、穴を開けること自体は解決しないので 効果...

今回のRPAのお話は 先の記事であるEUCのお話とシャドーITの話と関連します。 3つで一つみたいな感じです。 【あわせて読みたい】 社内SEがシャドーITを嫌がる理由 EUC（エンドユーザー・コンピューティング）とは 過去の記事で書いたように シャドーITの存在は情報システム部門としては看過しがたいものです。 一方、EUC目線で言えば、自前でツールを作ることを許容しなければ浸透させることが出来ません。 このように二律背反を起こしているような状況なので、どう折り合いをつけるかという点で各企業、非常に頭を悩ませています。 この二律背反に更に付け加える要素として、今回の記事のRPAが加わります。 RPAはEUCの一環として考えてよいと思います。 ・RPAとは 平たく言うと作業の自動化をしてくれるツールの事になります。 定型的に決まっている作業を、ボタンを一つ押すだけですべて自動でやってくれる。そんな機能です。 例をあげると、 1.他の部署からもらったテキストファイルを開く 2.EXCELを起動する 3.EXCELの決められたセルに、1.のテキストファイルに書かれている数値を張り付ける 4.関数で出た結果をコピーする 5.テキストファイルを作って、そこにコピーする みたいな一連の作業をボタン一つでやってくれるようになる。 そんな機能です。 さて、このRPAですが、どういう風に作るかというと ・上に書いたような作業を、一旦画面上で実際にやって、それをRPAツールに覚えてもらう というのがベースになります。 「画面で再現しただけで覚えてくれるなんてすごい！！」 と思われると思いますが、これでなんとかなるのは、非常に単純な作業だけで 結局、これだけでは足りず、簡単なプログラムみたいなものを追加しないと求めた動きはしてくれないことが大半です。 ですのでRPAを導入するという事は、多少なりともプログラムっぽいものがかけなくてはいけない もしくはその概念が理解できていないといけない という点がRPA導入において見落としがちな点です。 これを考慮せずに RPAいれれば自動化が簡単にできる！作業効率もアップして、いいことづくめだ！ と思って導入すると、失敗します。 RPAが簡易に作業を自動化できるという触れ込みなのに対し、 世間に導入の成功事例が溢れていないのはこういう理由の為です。 さ...

今、情報システム部門は一つの大きな転機を迎えようとしていると思います。 それがEUCです。 この言葉自体は古くからある言葉なのですが、以下の2点から改めてこの考え方について、真面目に考えないといけない局面に来ていると思います。 1.ITというものが会社のほぼすべての業務に深く浸透し始めている 2.コロナウィルスの影響でテレワークが浸透し、従業員に対し、強制的にITリテラシーの向上が求められている。 今まで、いわゆるユーザーといわれている人たちは 社内SEから提供される新しい機能やサービスについて その使い方だけを聞いて、業務で使うというスタンスでよかったのですが、 ここにきて上の2つの理由から、自分自身もITについて、ある程度理解をしていかなくてはいけない時代になってきています。 特に2番目の理由は大きいです。 コロナによって、どうしても現場に出ないといけない職種以外は 半強制的にリモートワークの導入がすすめられたと思います。 今まではパソコンやネットワークの事なんて気にしなくてよかったのに 突然、 「家のわいふぁいにつなぐ？」 「ぶいぴーえぬ？」 「プリンタつなげるってどうしたらいいの？」 「え？領収書ってスキャン？するの？」 等々、様々な問題に直面した人も多かったはず。 今まで社内SEはある程度限られたユーザーに向けてシステムの導入を行っていました が、それにしても使い方を教えたり、マニュアルを作ったり、質問を受けたりと 相当な労力を費やしてユーザーに対して落とし込みをしてきました。 それが、コロナウィルスを起因とする一斉リモートワーク導入のせいで その対象は一気に全社員となり、しかも今までのように、ある程度時間をかけてユーザーに落とし込みをするような暇はない という状況に突然なってしまいました。 ユーザーも新しい事をいきなり短期間で覚えないといけない苦労をしましたが 社内SEもまた、膨大な量のユーザー（しかもITの知識レベルは千差万別）に対して、説明資料を超短納期で作り、これまた膨大に寄せられる質問に対応したりと相当な苦労をしたはずです。 こういった混乱を経た結果、企業が再び持ち出してきたのがEUCという考え方です。 これは平たく言うと、 業務に特化したシステム以外、専門性の高いシステム以外、つまり利用者が不特定多数にわたるような汎用的なITシステムに関しては...