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

ちょっと今更感はありますが、 DXの定義について、改めて知る機会があったので 書いておこうと思います。 私はITの世界に生きて20年ぐらいになりますが、 敢えて積極的にIT用語を取り入れるようなことはしてきませんでした。 理由はいくつかあるんですが、 一つ目は、ユーザーやお客さんとお話をするときに、 ITの専門用語は 障壁にはなってもコミュニケーションの糧にはならない からです。 メリットがあるとしたら、相手を煙に巻く、もしくは「凄そう・・・・」と思わせる という所ぐらいで基本的には胡散臭さを増すことが多く、仕事の役に立たないことが多いです。 それよりもユーザー側の専門用語を知る方が10倍大事で 今までの部下にも IT用語なんかより、お客さんの業界用語を覚えなさい といってきました。 二つ目はITの世界は時代の移り変わりが早く 泡沫的に流行り言葉が出てきて、いつの間にか消える ということが多く、その中には 呼び方を変えただけで中身一緒 みたいな用語も多いので、捨て置いている という事もあります。 当初、DXもそういった泡沫的な用語の一つだと認識していましたが 今やどこのシーンでもDX、DXと叫ばれており、 ある程度、市民権を得てきたので改めてちゃんと捉えることにしました。 さて、そもそもDXって何？っていう所なんですが これとよく一緒くたにされるのがIT（デジタル）化です。 DXも大きな枠で言うと IT（デジタル）化に含まれるかなと思うのですが、 ちゃんと整理すると、向いている方向というか見ているところが違います。 DXというのはITを使って売り上げを伸ばす事を言います。 一方、IT化とかデジタル化というのは今ある業務をIT（デジタル）に置きなおし、省力化することを言います。 なので、 うちは紙帳票を全部電子化しました！ というのはIT（デジタル）化であってDXではないですが、 一方で マーケテイングにSNS分析を導入し、売り上げを前年比120%にしました！ とかはDXです。 なので、「うちもDXしましょう！」 というのは通訳すると「うちもITを使って売り上げ拡大しましょう！」です。 別にSNSを使っているからDXとか、新しい技術を使っているからDX とかの仕切りではないということもポイントです。 さて、ここからは蛇足になってしまいますが 私がIT用語を...

コロナによる影響は我々の社会に激しく影響を与え、大きな変革を強いてきました。 その一つがリモートワークの異常なスピードでの浸透です。 かくいう私もフルリモートワーカーです。 とはいえ、私のように 完全にリモートワーカーとなってしまった人 コロナ禍が落ち着きを見せ始めるにつれ、出社し始めた人 ずっとリモートワークとは無縁だった人 様々あると思いますが、一旦リモートワークについての良し悪しを整理してみたいと思います。 2，3年後、この記事を読み返したときに、どう思うか楽しみでもあります。 さて、リモートワークによるメリットですが ぱっと考え付くだけでも 通勤時間が無くなった 雑務に時間を取られなくなり、集中できるようになった 場所を問わず、優秀な人間を捕まえることが出来るようになった 田舎に引っ込んでも、今までの仕事を継続できる とかが考えられます。 特に都心に住む人に取って、通勤時間が無くなったというのは相当なメリットだと思います。 何しろ毎日、往復で2時間ぐらいつかっていた移動時間がなくなり 自由に使える時間が増えたのですから。 単純に考えても1日24時間の1/12時間ですから、1日の10%弱の時間が生まれたことになります。 これがあれば、今までやりたくてもできなかった勉強もできるし、家族との時間も増やせます。 また、場所を問わずに仕事ができるというのも大きいですね。 都心の給料を維持したまま、土地の安い地方に住むことすら可能なのですから 狭いながらも楽しい我が家 なんて事を言わなくてもいいわけです。 勿論、 「うちの会社テレワークだから、地方に引っ越してもいいでしょ？引っ越しまーす」 とまで思い切った行動をとる人はまだまだ少数派ですが、 全く聞かない話ではありません。 一方、デメリットとしては コミュニケーションがとりづらくなった 仕事とプライベートの区別がつきづらく、オンオフが切り替えにくい 隙間なく会議を入れられるようになり、過密スケジュールになってしまっている。 親近感を得にくい為、仲良くなるのに時間がかかる が、考えられます。 コミュニケーションがとりづらいというのは慣れてないからでしょ？ という人もいるようですが やはりテレビ会議と同じ会議室にいるのでは、全く違うと思います。 その為、今度はバーチャルオフィスの製品が増えたりしているわ...

なんとか打てる手を打って、このボロボロのプロジェクトを立て直そうと頑張っていましたが事態はさらに悪化します。 次々と発生する案件に蓋が出来ないので その案件を処理できる体制を作ろうと苦肉の策を打ったところが前回まででした。 前回書いたように、これで状況が解決すると考えるほど楽観主義ではありませんでしたが、 多少の状況改善にはなるだろうと思っていたところ、実際にこれによって 少し 状況は良くなりました。 特によかったのは、プロパー（社員）しかやれないことになっている仕事の1部を 名実ともに協力会社さんにお願いできるようになったという所です。 これまでは、人が足りていようが足りてなかろうが、少ない社員でなんとかせねばと キュウキュウになっていたのですが、これを人に振れるというだけで 精神衛生上、だいぶマシになります。 勿論、いきなり渡しても処理できなかったりするので、実際のところ、負荷は減っていなかったりするのですが いつか楽になるかもと思えるだけで、人は気力を振り絞れるものです。 先の見えない真っ暗なトンネルを歩き続けていると気分が滅入るけれど 向こうに豆粒ほどの光が見えただけで、どこにこんな力が潜んでいたのか？と思うほど、力が湧いてくる そんな効果もあります。 そのように四苦八苦しながらなんとか打開策を打っていたのですが そんな状況にとどめを刺したのは、やはり例のプロジェクトリーダーでした。 この人自身は とても頭がいい人なのですが、やはりリーダーには向いていない とつくづく思いました。 彼がこんな状況のプロジェクトに次に求めたのは 「システムについてプロパーが理解していないのはまずい。 せめて言っていることがわかるレベルには達していないとまずいので なんでも協力会社に投げる前に、自分たちでまずは処理できるように」 といってきたのです。 毎度の事なのですが、彼の言っていることは決して間違ってはいません。 しかし、状況はそれを許していないのです。 人づてに聞いたのですが彼の上司は昔 「あいつは正論で人を潰してしまう」 といっていたのらしいのですが、まさにそれによりプロジェクトが潰されようとしていました。 彼の言っていることは正しい。 私も状況が許すなら同じことを言っていたと思います。 しかし、この状況でそれを言うというのは あたかも 点差がついた試合でどうしても起死回...

キャリア構築を考える上での心構えを一つ書いておこうと思います。 これも経験談になりますが、おそらく嘘は書いていないと思います。 それは 今の自分の実力よりも少し難易度の高い仕事をする。そんな機会が巡ってきたら決して逃してはいけない です。 これを続けないと人は成長できません。 キャリアを構築する＝実力をつける という事を考えた場合、 「自分のできること」という事は、「今までと同じことをする」 という事であるということを強く意識したほうがいいと思います。 よく、 現状維持は退化と同じだ みたいなことが言われますが、まさにその通りで ITの世界は、とどまることなく先へ先へと進んでいきます。 そんな世界の中で、同じことを続けるという事は 時代に取り残される。すなわち退化してしまうという事です。 新しい製品だけでなく、新しい手法もどんどん開発される中 同じことをし続けるというのはキャリア的なリスクとも言えます。 しかし、厄介なことに、背伸びをした仕事をする機会というのは なかなか自分の意思では巡り合う事が出来ず どうしても運に寄る部分が多いです。 （そのチャンスを人為的に作り出すために転職をするという側面もあるのですが） もしそのチャンスが巡ってきたら 勇気を出して一歩踏み出して、新しい仕事に取り組みましょう。 それがまた一つあなたの「できること」に加わるわけです。 それを繰り返すことであなたのできることはどんどん広がっていき、 気が付けば、多様なスキルを持った人材になっているわけです。 ただ、ここまでいろいろ述べてみましたが これは考えてみれば当たり前のことで 将来野球選手になろう！と思ったとしても同じことで まず、 ストレートを打てるようになろう！ と決意して、ある程度打てるようになったとします。 しかし、そこで満足してただひたすらストレートを打ち続けるという事はないはず よし！次はフォークを打てるようになろう 次はカーブを打てるようになろう となるはず。 いやー、フォークは打てる自信がないので、手を出しません。 ストレートなら得意なんですけどねぇ なんて野球選手はいないはず。 だから、これも特別なことを言っているわけではないんですが 何故か仕事になると、強く意識しないと忘れがちです。 チャンスが巡ってきたら、恐れずにチャレンジしましょう！ ちなみに少し話は...

前回の記事に引き続き、 プロジェクトリーダーがシステム導入の際に 運用保守の事も考えて実装をしないといけない という話をしたいと思います。 当たり前といえば当たり前なのですが、 フェーズが進むにつれ、運用保守を意識するシーンは増えていきます。 【テストフェーズ】 テストフェーズの辺りから、頭の半分ぐらいは運用保守の方に使っていかないといけません。 一般的にテストフェーズでは 今迄に検討・作成したプログラムがちゃんと思惑通りに機能するように作られているか？ という点をテストを通して確認するのですが、 「ここまでの流れで、しっかり運用保守の事を考えてプロジェクトをコントロール出来てきているのであれば、運用保守の事を意識するというよりも、設計通りに動くかどうか？に力を集中した方がいいのでは？」 と思われるかもしれませんが、それは違います。 そもそも テストフェーズというのは、「想定通り動かない」という前提で行うもの です。 「想定通り動くはず」なんて意識でやっていると、拾えるはずのバグを見落としてしまう程度のテストケースしか考えないので、そもそもこのフェーズの意味を失ってしまいます。 これと同様に、今までしっかり運用保守を意識して設計を進めてきたけど、 テストフェーズではそれが裏切られると思ってテストを行わなくてはいけません。 どういう事かというと、 設計の段階では機能単体の動きを想定しながら作りこみますが それらを一連の機能としてテストシナリオを考える際に プロジェクトリーダーが想像もしないようなシナリオが生まれていたりするので それをチェックしないといけないという事です。 例えば機能の前後関係のあるOとPという機能があったとします。 要件定義の段階では 機能O→機能Pの順番で処理される という事がわかっています。 各機能を設計する際に 機能OではアウトプットとしてKとLを生み出します。 機能PはLを基にZを出力します。 と設計したとします。 そしてテストの際に 機能Oをまず実行し、Lを生み出します。その後、機能Pが実行され、LからZが出力されます。 というテストケースを考えたとします。 で、このシナリオは終わり。 すると、ここで「 あれ？機能Oで生み出されたKはどうなるの？ 」 という事に気が付きますが、周りの開発者に聞いても、機能Pの前提処理は機能Oしかなく、機能O...

プロジェクトリーダー(以下、PL)は プロジェクト全体を管理し、無事にゴールできるように 様々なタスクをこなさなくてはいけませんが、 その役割はプロジェクトを通して、一定のものではありません。 プロジェクトのフェーズごとにその役割を微妙に変えていかないといかないといけないのですが、そのお話を書こうと思います。 まず、そもそも何故そのようなことをしなくてはいけないのか？という理由ですが それはプロジェクトには大きく分けて、 システムを導入する という事を考えるフェーズと 導入したシステムの運用保守をどうやって行くか を考えるフェーズが 混ざる からです。 コンサルやSierであればシステム導入の事だけ考えればいいのですが 社内SEとなるとそれだけ考えればいいという訳にもいきません。 というか、むしろ導入よりも運用保守している期間の方が圧倒的に長いので そちらの方が重要です。 そして、導入後のイメージを膨らませながらシステム実装する唯一の立場が社内SEであり、それをコントロールするのが社内SE側のプロジェクトリーダーになります。 プロジェクトリーダーを外部の人間に任せてはいけないという大きな理由の一つです。 さて、プロジェクトのフェーズをざっくり分けると以下のようになります。 要件定義フェーズ 開発フェーズ テストフェーズ 移行フェーズ 各フェーズでのプロジェクトリーダーの役割の移り変わりを見ていきます。   【 要件定義フェーズ 】 導入するシステムで実現したいこと、それをどういう形で実現するか？という青写真を描くフェーズです。 システム導入というのは社内SEにしてもそんなに年中やっていることではなく、規模が大きくなるとそれはなおさらです。 ユーザーからすると、そこに輪をかけて稀な経験になり、「How要件定義？」どころか「What要件定義？」という感じになります。 一方、コンサルやSIerはそれを仕事として幾度となく繰り返してきていますので、発注側と受注側において、 プロジェクトの「慣れ」具合に天地の差があります 。 そこを社内SEは埋めないといけませんし、ちゃんと溝を埋められているのか？をプロジェクトリーダーは注視しなくてはいけません。 要件定義フェーズとして定められたスケジュールの中で、きちんと終わらせるためには ある程度スピード感をもって臨まなくてはい...

では、キャリアを構築する為の手段である転職について書こうと思います。 社内SEとして必要な経験値は多岐にわたり その為にはどうしても転職という手段を取らなくては経験できないものがある というのは別の記事で書きました。 あわせて読みたい 社内SEに必要な能力：システム開発における様々な立場の経験 じゃあ、転職する上で、どういう転職をしたらよいのか？を書いてみます。 あくまで経験によるものですので、絶対解ではありませんが一つの参考にはなるかなと思います。 まず、社内SEとして必要なキャリアとして以下のものを挙げましたので それぞれ、どのような場所で経験したらよいかを書いておきます。 1.開発者として 2.システムエンジニア（上流工程）として 3.コンサルタントとして 1.開発者として についてですが、社会人になって初めての会社がその経験の場になると思いますが 初めの会社を選ぶ際に キャリアを考えて選ぶことが出来る人というのはそうそういないと思います。 なので、これについては最初に入った会社が「どうも違うなぁ」 と思った時に考えるので良いと思います。 初社会人でいきなり上流工程に携わることはないと思うので 開発経験は詰めるはずです。 なお、「どうも違うなぁ」というのは「俺はもっと上流工程がしたいのに」とかではなく「ちょっと業界がニッチすぎないか？」とか 仕事をしていく中で、この方向に進みたいなぁというのが見えてきた際に、 このプログラム言語に習熟しても足しにならないかも と思った時です。 もう少し補足すると、例えばwebの業界に進みたいかもと思っているのに、 ひたすら、銀行系の開発案件に入っても意味がないというような意味です。 開発経験を積むという意味では、いわゆる独立系SIerとか技術者派遣をしている会社とかであれば問題ないと思います。 情報システム子会社とかでも大丈夫だと思いますが、 独立系SIerの方が2次請け、3次請けとして仕事をするシーンが多いので そちらの方が最初の経験値としては良いと思います。 逆にいきなりコンサルとかにはいると、開発経験なしで 上流工程をやらされるかもしれませんので、危険だと思います。 いきなり上流工程に組み込まれることで、なんだか選ばれたような気になるかもしれませんが、 これは基礎体力もつけないで、いきなりパルクールをさせられるようなも...