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

まず、前提として私は内製化についてはあまり肯定的ではありません。 ここでいう内製化とは、正社員としてプログラマーを抱えて、自社の人間で開発自体を行う事を言っています。 システム開発を内製化する目的は ・このご時世、何をするにしてもシステム開発は必要にならざるを得ない。 その度にコンサルやSIベンダーにお金を支払っていくのはバカバカしいから、内部にシステム開発部隊を作って、コストを抑えよう という考えですね。 これに対し、私は 内製化はコスト削減にはならない と思っています。 その理由は以下のものです。 ①内製化によるコスト削減のメリットが最も現れるのは、システム導入時であり、運用保守のフェーズに入るとコストメリットが表れにくい。 ②システム導入よりも、運用保守の期間の方がはるかに長い。 ③コストメリットの出る、システムの導入プロジェクトは絶え間なく企業内で発生するものではない。 つまり、システムのライフサイクルのうち、内製化によるコストメリットの出やすい部分は一部分でしかないのにも関わらず、多額の人件費を抱えることになる為、よくてトントン。 それどころか、不景気になった場合のコスト削減が容易ではなくなるリスクを抱え込むということになると思います。 ※景気が悪く、システム投資をいったん控えようと思っても、人件費は掛かり続ける。 実際に、システム開発ができるほどの人員を抱えようと思うと、それはもはやシステム会社を社内に抱えることと≒になります。 一昔前、企業は社内の情報システム部をシステム子会社に移管させていましたが、それはつまり 本社の人件費として抱えたくなく、いざとなれば「自分たちの食い扶持は自分たちで稼ぎなさい。以上」としたいがため だったはずです。 そもそも、「システム子会社は社内SE(情報システム部門)の代わりにはなりえない」とも思っていますが、その理由は以下の記事を読んでみてください。 システム子会社が社内SEの代わりになりえない理由 つまり、過去に社内にシステム開発のコストを抱えるのはリスクだと判断したにもかかわらず、今度はそこから逆行しようとしているわけです。 確かに企業におけるシステムの重要性は一昔前に比べると、比較にならないほど上がっていますが、上記①～③の事実は何も変わっていないはずです。 にも関わらず...

この記事では、優秀な社内SEになるには 転職が必要になる ということを書こうと思います。 社内SEに限った話ではないですが、まず考えるべきは 自身のキャリアを 「会社に所属する」　or　「職種を選ぶ」 ここを考えないといけません。 前者はいわゆる終身雇用が生きていた日本企業の考え方 一方、後者は海外企業のイメージですね。 今の日本は徐々に後者に移行しつつあるように思えますが 日本の終身雇用、年功序列の考えは根強いので 当面、前者の選択肢は残るのではないかと思います。 そもそも日本の労働人口が減っていくという、逃れようのない事実がある中で 企業も、より優秀な人材を確保したいという考えはあるはず。 だから、後者の考えはもっと加速度的に進むのでは？という考えもあると思いますが そこまで思い切った判断ができる経営者は多くないと思っています。 今の日本の経営者は終身雇用、年功序列の世界で育ってきている人が まだまだ多いので、外的要因として上記の物があるとわかっていても、 マインドが切り替わらず、 ・優秀であればなんでもいい！！ ・そもそも転職できない人間は優秀なのか？ といった考えまで振り切れない。 そんな状況が続くと思います。 結果、若い経営者のベンチャー企業や外資企業に人が流れて行く中で どこかのタイミングでパラダイムシフトが起こると思いますが、 当面は前者と後者の間での綱引きが続くと思います。 そこで話は最初に戻りますが、 じゃあ、まだまだ日本企業は生え抜き重視で行くのであれば 「会社に所属する」方向でキャリアを考えたほうがいいな と考えた場合、 優秀な社内SEになるのは困難です。 何故なら その志向で進むとすると、転職回数は当然少ないほうがいいので （というか少ないのが大前提） できれば転職一回、どんなに多くても二回という制限が付きます。 そうなると、システムの専門家として異なる立場で経験を積む機会が制限されてしまいます。 優秀な社内SEは、プロジェクトをコントロールする上で、 プロジェクトに関わる様々な立場の観点と思考を身に着け、プロジェクトを俯瞰することができなければいけません。 それができないと適切なリスクコントロールができず、プロジェクトを管理することが非常に難しくなります。 その為、優秀な社内SEになろうと考えるのであれば、 後者の「職務に従事する」という方...

 社内SEという存在を社内SE当事者の目線から考えてみる という話は [box06 title="あわせて読みたい"] 社内SEってどういう人？社内SEの立場で考える [/box06] で書いてみました。 一方、社内SEを使う側、社内SEにスペックを発揮してもらわないといけない側である 雇用者側では社内SEをどう捉えるべきか？ ということを書いてみたいと思います。 まず、自社にシステム部門はあるでしょうか。 もし既に存在している場合は想像してみてください。 自社の社内SEが突然 「キャリアアップの為に辞めます」 「もうこの会社でやれることはないと思うので転職します」 と言って、みーんないなくなったら会社は運営できるでしょうか。 細かい話だと 「このエクセルってマクロが組み込まれてるみたいで、 エラー出ちゃったんだけどどうしたらいい？」 大きな話だと 「なんか、朝来たらシステムが動いてないんだけど、どうするの！？」 こんな質問に対応してくれる人が誰もいなかったら・・・ 会社は運営できるでしょうか。 社内SEは社内の全ITを司っています。 そして今や、どの業務もITを使わないシーンがないといっても過言ではありません。 [box02 title="もし、社内SEがいなくなったら？"] 【影響範囲】 社内の全業務 【影響の深刻さ】 ものによっては業務が完全に止まる。 その瞬間は何も起きてなくても、何か起きた時にだれも対応できない。 【解決手段】 専門スキルのため、SE以外誰も解決できない。 外注などで慌てて技術者を連れてきても、システムごとに実装経緯がある為、一朝一夕で解決できないことが多い [/box02] 社内SEって、ここまでITが浸透する前の時代は あまり光を浴びる部門ではなかった為に その印象を引きずってしまっていますが、 今は社内のあらゆる業務に関係し、しかもその業務遂行の為には なくてはならない存在になっていることは上述した通りです。 この状況下において、雇用者側はその存在価値を見直す必要があると思います。 たまに「ITって何ができるの」って聞かれることがありますが その時、私は「 お金に糸目をかけなければ、何でもできます。そういう時代です。 」 ...

 結果的にですが、社内における重要性が高まったことで 社内SEはいろんなことを求められます。 その中で最も重要なものがコミュニケーション能力であるというのは 既に書いていますが、 社内SEに必要な能力：コミュニケーション能力 他にも様々な能力が求められます。 その中にはいわゆるシステム屋さんとしてベタな プログラミングの力も当然ながら必要です。 ただ、ここでは プログラミング能力を身に着けてガシガシシステムを作りましょう というつもりはありません。 というか 個人的には内製化（システム開発を自社の社員で行う。またはそういう体制を組む）については反対です。 それが何故かという話は別の機会にするとして、 システム開発をしない（内製化しない）と言っているのに、 なぜプログラミング能力（経験）が必要なのか？ という点について書きたいと思います。 プログラミングができると色々と良いことはあるんですが、 その全てを一記事では書ききれないので、この記事では ・ブラックボックスを怖いと感じれるようになる という点について書きたいと思います。 ちなみにブラックボックスとは どういう動きをするシステムか？ということは動きを見て何となくわかっているが、中でどういうプログラムがどういう意図を持って動いているかはよくわかっていない状態。 ということです。 具体的に言うと こんな感じで入力Aに1、入力Bに２を入力すると答えのところに3が出る というシステムがあったとします。 パッと見、入力Aと入力Bの値を足し算した結果が答えの欄に表示されるシステム という風に見えます。 しかし、実際に中で行われている処理は （入力A ×100-入力A×99 ）＋（入力B ×100 -入力B×99 ）＝答え という処理かもしれません。 中の処理を見る能力がなければ、この裏付けを取ることはできません。 このように 仕様の裏付けを取ることができないけど、見かけの動きで動作を予想している状態 これをブラックボックス化しているといいます。 （すごく端的に話してます。） ここで 「ふーん、結果は同じなんだからいいじゃないか」 と考えるか 「ん？なんでこんな無駄なことやってるの？」 と考えるか これが社内SEとしてのクオリティを分け...

社内コンサルとしての働きが求められる社内SEに必要な能力は多岐にわたります。 その中でも、もっとも重要な能力はコミュニケーション能力です 一昔前は、社内でも 「 なんだかよくわからないことをやっているマニアックな集団 」 で済んでいたのに、徐々に経営側の方でも ・ITを使えば抜本的な社内の問題解決ができるかも ・ITのことを「よく、わからない」ではすまない時代なのかも ということに気が付き始めた為、 社内SEに ・対外的にも対内的にも問題解決の為の活動をしてもらいたい と思い始めてきました。 こうなると社内SEは「職人」という殻の中に閉じこもることは許されず、 様々な人と折衝を始めなくてはいけません。 社内SEが問題解決活動して人と折衝をしないといけないシーンは様々ですが 例えば ・新しいシステムを導入するために現場に業務要件をヒアリングする ・システムの更新時期が迫ってきたので、経営陣に必要性を説明して 予算を獲得する などが代表的なところです。 この場合、社内SEがコミュニケーションをとる相手は 現場で動く人（営業、工場、フロント等）予算管理者（中間管理職）、経営層 などですね。 こういった人たちとコミュニケーションをとるときに私が特に大事だと思っている能力は ①相手の警戒心を解く物腰、態度 ②IT用語ではなく相手の言葉でわかりやすく説明できる言葉の能力 この二つです。 社内SEが社内コンサルとしての役割を求められてきている一方で 周りの社内SEを見る目線は変わっていません。 相変わらず 「なんだかよくわからないことをやっているマニアックな集団」 のままです。 なので、相手からすると 「なんか気難しい、よくわからない言葉を言ってくる人間が話しかけてきた」 というのが第1印象になってしまいます。 たまーーーーーーーーーーに 「あ、システムの人だ。なんか難しいことがわかってる人だから下手に出ておこう」 と思ってくれる人もいますが、これは ごく少数 だと思います。 なので、まずは相手の警戒心を解くことから始めなくてはいけません。 職人のように、いきなり気難しそうな顔で現れたり、 いかにもコミュニケーションとるの下手ですといわんばかりに目を合わさない とかはもってのほかですね。 今から仲良く...

 過去に幾度も語られた題材だと思いますが IoTだ、DXだ、という言葉が飛び交っている昨今、 いまだかつてないほどに、その価値が高まる もしくは高付加価値を求められるポジションになってきていると思うので 改めて、社内SEという立場から考える、社内SEってどういう事する人なの？ という点についてざっくり書いてみます。 まず社内SEは読んで字のごとく、 社内のシステムを開発、導入したり、保守運用する人 です。 これについては、どなたも異論はないと思いますが、 問題はこの「社内のシステム」ですね。 一昔前ならいざ知らず、社内のシステムと一言で言っても その種類は多岐にわたります。 大枠でも 基幹システム（会計システムとか生産管理システムとか） 業務システム（営業支援システムとか、ビッグデータとか） 業務支援システム（ワークフローシステムとかグループウェアとか） に分類され、 さらにそれぞれの製品群がすごい数になっています。 基幹システム（SAP、Dynamics365、OBIC7、NetSuite等々） 業務システム（BigQuery、AnalyticsCloud、セールスフォース等々） 業務支援システム（Gsuite、Office、kintone、slack、chatwork等々 ちょっと粒感がバラバラですが、体系立てて整理するとそれだけで とんでもなく時間がかかるので、そのあたりは容赦してもらうとして 何が言いたいかというと、製品というレベルで数え始めるとキリがないほど 社内システムって数が増えているんです。 それはつまり、過去に比べて 社内の業務のいたるところにITが浸透している ということですね それが社内SEという立場において、どういう影響があるかというと 上に書いた通り、社内SEは 社内のシステムを開発、導入したり、保守運用する人 なので、以前に比べ、その守備範囲は極限まで拡大され、 結果的に、 社内の全業務について精通していなくてはいけない。 少なくとも相手の言っていることがわかるレベルには業務を理解している ということになります。 （もちろんこれは一人の社内SEに求められている というよりもシステム部門全体としてという話です。） ・・・・・これって異常にハードルが高いと思いませんか？ 冷静に考えてみてください。 会社の全業務について理解している部門...