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

このブログでは私の今までの経験をまとめて、参考になりそうなことを記載していますが、このカテゴリはちょっと毛色を変えて、私が今実際に直面している課題をどうやって解決していくか。 について、書き連ねていこうと思います。 その方が、ケーススタディとして使えるかもしれませんし、 生々しい話や「そうそう」と感じる話も、随所に出てくると思いますので そちらも併せて参考にしてもらえればと思います。 さて、早速ですが 私は少し前に、3年ほど勤めた会社を退職し、 今は新しい会社で社内SEとして仕事をしています。 規模としてはいわゆる大企業と言われる会社ですが、 ITについては新しいソリューションや考え方に積極的で そういうところは大企業っぽくない会社です。 入社時期は年末で、いわゆる管理職という立場で入社しました。 会社は大規模プロジェクトのカットオーバーを4月に控えており、 みんな目まぐるしい勢いで働いています。 また、周りのメンバーはこのプロジェクトに長いこと関わってきた人たちばかりで 私は唯一、右も左もわからないという状況です。 そして、問題のプロジェクトの状況はあまり芳しくなく 本当にカットオーバーできるのか？ と思っている古参メンバーも、チラホラいるというような結構切迫した状況でした。 実際、私の経験上でも4月に無事にカットオーバーを迎えようとしているプロジェクトにおいて、1月段階で不具合をバンバン出しているものは見たことがなかったので 入社して早々ですが、 このプロジェクトはヤバいかもな と感じましたし 過去にコンサルとして携わった炎上プロジェクトにかなり近い匂いが漂っていました。 そんな中、私は リーダー1名 メンバー5名 という構成の、あるチームに参加することになりました。 仮にAチームとします。 4月カットオーバーに向けてのタスクにおいて即戦力として活躍するということは、さすがに期待されていなかったはずですが、時を経るごとにプロジェクトの状況は一進一退の様相を見せるようになり、いよいよ猫の手も借りねばカットオーバーできない という状況になっていきました(笑) こういった状況の中、入社したてである私がすべきことは プロジェクト全体の中でAチームが関わっているタスクは何で そのタスクについて、Aチームの誰がどう動いているのか という事を把握したうえで 今時点で自分の価値...

私の経験では優秀なプロジェクトリーダー（以下、PL）は大きく分けて2種類いると思います。 【カリスマ型】 秀でた能力で、プロジェクトをぐいぐい引っ張っていくタイプ 【調和型】 できるだけ周りのメンバーと調和しながら、着実に進捗していくタイプ それぞれにメリットデメリットというか特性があります。 カリスマ型の メリットは 予定納期内にプロジェクトが完了する確率が高い リーダーのスペックにつられて、今まで隠れていた実力者が表に出てくる。もしくは、頭角を現す デメリットは リーダーの能力（求める成果）にメンバーがついていけず、脱落者が出る。最悪、メンバーの能力が低すぎると脱落者が多すぎて、プロジェクトが崩壊する。 かろうじてついていけるというレベルでも、自身の能力にコンプレックスを抱いてしまう可能性が高い。 チーム内に摩擦を生みやすい 調和型の メリットは メンバー脱落者が少なく、プロジェクトの成功体験を多くの人間が享受できる。 デメリットは メンバーフォローの為、リスケが多くなる傾向がある。 前者よりもプロジェクトリーダーの負荷が高くなる傾向がある。 どちらを良しとするかは会社の文化によったりするので、一概に言えませんが 現在プロジェクトを任せているPLがどちらのタイプか？ という事を理解した上で、プロジェクトオーナーやプロジェクトマネージャーが接するというのは非常に大事です。 見当違いな接し方をすると、無用な負担をPLにかけることになり、最悪PLがつぶれて、プロジェクト失敗 となりうるので気を付けましょう。 さて、優秀なPLは大きく分けると２タイプと書きましたが その前にそもそもPLに向いている人というのはこんなタイプです。 ・責任を負うことをやりがいと感じられる。 ・面倒事を解決することを煩わしいと感じない ・人に指図されるよりも、自分で意思入れをしたい ・人とコミュニケーションを取ることを煩わしいと思わない その上で、最初に述べた2タイプのPLに向いている人は もう少し細かくなって、カリスマ型の場合 ・周囲の雑音が気にならない（気にしたくない） ・気にしないといけない相手にだけ集中できる ・大事の前の小事をドライに切り捨てられる ・あらゆる意味でフラットに人を評価できる（外部・内部・ベテラン・新人問わず） 調和型の場合 ・相手を取り巻く環境を無視できない（スキル、...

理想とする社内SEというか、求められる社内SE像というのは、 日々の暮らし方が難しいです。 というのも、導入済みのシステムに対しての造詣を深める一方で 新しい技術にも手を伸ばしていく事を求められるからです。 それは社内SEという存在が、その 会社にとって唯一のIT世界との窓口 だからです。 どんな新しい技術が世の中に出回っていて、それが他の企業においてどういう効果をもたらしているか？ 自分たちが既に使っているシステムのその先に進んだシステムがリリースされ、それがどういったものか？ といった事は社内SE以外に仕入れることができる人は会社にはいません。 その為、展示会や企業の新製品の説明会などに参加したりをするのですが、この行為自体は直接生産性を上げる活動ではないため、経営側からするとイマイチな反応しか返ってこないこともあります。 もちろん、会社として 新しい技術なんて興味なし 永遠にこのシステムを使っていく！（そんなことは不可能ですが） というスタンスでいるのであればそれでもよいですが それはおそらく会社にとっても、所属する社内SEにとってもあまりいいことではありません。 実際に社内SEをやっていくなかで 現在稼働しているシステムに習熟する 世間に新しくリリースされた技術をキャッチアップする この二つの両立が如何に難しいか という事と共に、 経営者側としても 社内SEが新しい技術にアンテナを張っていないと何が起こるか？を書いてみます。 まず、 運用保守をしながら新技術のキャッチアップをすることが如何に困難か？ という点ですが、これはシンプルな話で、 ① 運用保守をしてるだけで忙しくて時間が取れない ② インシデント（事件）の発生が時と場所を選ばないので、まとまった時間を確保しづらい という2点に集約されると思います。 ①については、IT部門の宿命ともいえますが、仕事の主導権を握っているのがIT部門ではなく、業務部門であるという事が原因の一つです。 つまり、自分たちで仕事量のコントロールがしづらいという事です。 業務側の仕事のサイクルでインシデントが発生し、それをIT部門に投げてくる為、 基本的に仕事に対する姿勢が受け身になりがちになってしまうので、コントロールするといっても限界があります。 経営陣がITに対して理解があり、IT部門の社内的立場をある程度保証してくれてい...

①社内SE→他職種への配置転換 ②他職種→社内SEへの配置転換 仮にこの二種類の異動を行おうとした場合、 そのハードルの高さにはかなり違いがある という話をしたいと思います。 ちなみに ①社内SE→他職種への配置転換 のところは厳密に言うと、 社内SE自身が担当していたシステムにおける業務部門への異動 という意味で 全くの畑違いの職種への異動に関しては ②と同様のハードルになるという事は補足しておきたいと思います。 さて、ではなぜ上記のようなことが起こるのか？ という点ですが、 社内SEがシステム開発や運用保守をしていると嫌でも業務に詳しくなるが、業務の人はシステムを使っていても、システム自体には詳しくならない。 というのが理由です。 社内SEがシステムの面倒を見る際、業務のことがわからないと、 課題点も見つけられないし、適切な要件定義もできないため、 満足な保守ができません。 結果として社内SEとして働いていく上で 業務知識は必要不可欠なものになる為、業務に詳しくなっていくことになります。 もちろん、それを専業にやっている人には及ばないとはいえ、 それに近しいレベルまで近づくことは実際にありますし、 フラットな目線から 現場が気が付いていない課題に気が付く ことさえあります。 逆にシステムを使う側であるユーザーは システムがどういう仕組みで動いているか？ という事を理解している人は皆無だと思います。 ( SE経験者がやっている場合を除く) ユーザーからすると、システムにおいて大事なのは 何をインプットして、何がアウトプットされるか？ そのアウトプットは信頼に足るものか？ ということであって どういう理屈でシステムが動いているか？ というのは二の次ですし、実際業務を遂行する上ではそれでいい というのが実態ですが、社内SEはそうもいきません。 例えば、私が過去に携わった人事給与システムなどはわかりやすい例の一つだと思います。 人事部の人たちは、給与計算がどのように行われているか？その詳細まで抑えている人はあまりいません。社会保険料計算がどういうロジックで処理されていて、年末調整がどういうロジックで処理されているか？などその詳細を把握することはありません。 しかし、システム担当はそうはいきません。 毎年といっていいほど、改正される所得税法や社会保険制度について 詳細を理...