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

優秀な社内SEとしてのキャリアを考えた上で転職というものは不可欠です。 というのは以下の記事でも書きました。 あわせて読みたい 社内SEのキャリアってどう積むの？ では、実際に転職する際のノウハウというか注意点も書いておこうと思います。 まず、 ポイント① 転職の際に転職エージェントは使った方がいいか？ 使わない方がいいか？ これを気にしている人は 「転職エージェントを利用すると、マージンが発生するし、それなら企業の採用サイトで直接応募した方が通過率高いんじゃないか？会社からしたらそっちから採用した方がお金かからないし」 と考えている人だと思いますが、これは 考えなくてよい です。 気持ちはわかります。 私もそう考えていました。 同じ人を採用するのであれば、コストがかからない方が企業的にも都合がいいだろうし 同一線上に並んでいるのであれば、直接申し込んできた人間を採用したほうがお得っていう心理が働くのでは？ と考えていました。 しかし、採用しようと思っている会社からすれば 少しでも優秀な人間を採用したいと思っているわけですから そこのコストは気にしていない。というのが答えです。 多少コストがかかっても、より優秀な人間が獲得できるのであれば必要経費である と考えています。 むしろ、山ほど来る応募書類の全てに目を通すことは非現実的なので、なんらかの基準で足切りして適正な数にする必要があり、その意味でもエージェントに依頼する意味はあると考えていると思います。 それに そもそも同一線上にならんでいるというのは、応募する側の勝手な思い込みで 書類や1次審査時点で、同じランクに並んでいるかどうかなんて、採用側には判断できません。 むしろ違いが判ってもらえるフェーズまで進むために、エージェントに推してもらう必要があります。 これも採用側の気持ちになればわかることで、 書類上は「イマイチかなぁ」と思っている人でも、プロであるエージェントから 「いや、こういうタイプの人はそうそう出るもんじゃないです。絶対1回会った方がいいです。」と推されれば「そこまで言うなら会ってみるか。」となってもおかしくないのはわかるはずです。 もちろん、自身に他の人とは違う明確な特徴があるのであれば話は別ですが。 これは私も最近、転職のアドバイスを求められた機会があったので、よくよく考えたらそうだなと気が付...

別の記事で優秀な社内SEを目指すという事を考えた場合、 コンサルティングファームの経験は決して必要ではない と書きました。 あわせて読みたい 社内SEのキャリアってどう積むの？ この記事では具体的にどこら辺がそう言える根拠なの？ という事について書きたいと思います。 結論から先に言うと、 ・「リスクヘッジ」の考え方が根本的に違う ・「当事者意識」が違う ・スキルが偏る という所です。 一つずつ見ていきます。 【「リスクヘッジ」の考え方が根本的に違う 】 これは言い換えると発注側と受注側の違いとも言い換えることができます。 Sierでも同じなんじゃないの？と思うかもしれませんが違います。 説明がちょっと難しいですが、大事な所なのでちゃんと説明したいと思います。 まず、仕事の立場としてコンサルもSierも発注側の人間の一部として働くことはあり、 企業のIT部門の一員として、別ベンダーに指示を出したり、管理をすることはあります。 しかし、コンサルはあくまで「お手伝い」というスタンスは崩しません。 それはなぜかというと、コンサルにおけるリスクヘッジが「自責にしない」だからです。 ここでいう「自責」とはその字面の通り、自分の責任という事になります。 なので、その作業の中で何か問題が起きても、かならず自分が責任を負うような事態にはならないように立ち回ったりします。自責になりそうなタスクについては 「それについては我々では責任取れませんので、御社でお願いします。」 といったように線引きをしたりします。 一方、Sierはそのスタンスは取らないことが多いです。 それは発注側のほうが立場的に圧倒的に強いことや、企業規模も大きなことが多いからという事もありますが、Sierは、いかに発注側に寄り添えるか？いい会社だと思ってもらえるか？という事に評価を見出す傾向が強いからです。 その思いの中に、「あわよくば食い込みまくって、切れなくしてやろう」というような思いが働くからでもあります。 この為、 そこにクビを突っ込むと、将来的に自責になるような事態に発展しかねない という事がわかっていても、そこに手を出したりします。 この違いが出る理由の一つとして Sierは発注企業と長い付き合いを目指す一方、コンサルはプロジェクト単位で利益を出そうとする という所があると思います。 Sierは発注企業とそ...

プロジェクトを進めていくうえで必ず登場するテストですが これって会社によって定義がまちまちだったりします。 例えば転職した時に前の会社では 「単体テストといっていたのが、ここではUTと呼んでいる」 とか 「前の会社で結合テストといったら、ここまでの範囲だったのに、この会社では全然違う」 とか よくある話ですが、最近転職した知り合いに質問されたので、今回はそれをまとめてみます。 転職する予定のない人も参考ぐらいにはなるかなと思います。 ちなみにこの記事はプログラム開発をしたことがある人向けに書いていますので、 開発経験がない人はわかりづらいかもしれません。 もし、もう少し噛み砕いて知りたいという人は問い合わせフォームやtwitterで聞いてください。 （開発未経験者にもわかるように書くとなると、だいぶ記事が冗長になってしまうので・・・） まず、テストの大まかな流れですが 一般的には 単体テスト→結合テスト→インターフェーステスト という流れで進むのが一般的だと思います。 ※他にも受け入れテストというのがありますが、これは納品のためのテストになるので、ここでは少し省いて、最後に捕捉します。 上記のテストの呼び名が会社によってまちまちなので、まずはテストの単位を以下のように細かくしてみます。 ①共通機能のテスト プログラムの中には、単体で動作するプログラムと、 他のプログラムから部品として呼び出されて、初めて動作する共通のプログラムがあります。 クラスライブラリとか共通関数、ファンクションモジュールなどと呼ばれているものですね。 身近なものに置き換えると、 スマホのカメラとかをイメージしてもらえばいいでしょうか。 それだけでスマホ用カメラとしては完成品ですし、メーカーはそれを商品として スマホメーカーに出荷しますが それだけでは何に使えるわけでもなく、 最終的にスマホに組み込まれて、初めて機能する このように、それ単体で一つの完成品ではあるものの、他のプログラムに組み込まれて初めて機能するようなプログラムのことを言います。 これがおそらく最小のテストの単位になると思います。 ②単体のプログラムのテスト 単体で実行して、動作するプログラムです。 先ほどの例で言うと、スマホそのものになります。 単体でスマートフォンという商品ですし、それだけで役割を果たすことができるものになり...

プロジェクト管理という仕事はとても大事です。 その名の通り、プロジェクトの成否はここにかかっています。 しかし、このプロジェクト管理はとても難易度が高く、 たくさんのプロジェクトリーダー（以下、PL）がこの難問に取り組み、 そして、良い答えが出せず、 俺ってPL向いてないわ・・・。 と頭を抱える日々を過ごしています。 その苦しみの果てが、世に溢れている炎上プロジェクト達です。 そもそもプロジェクト管理という言葉自体は 様々なタスクを包含している言葉ですので、 いざ、「このプロジェクトのPLは君だ。よろしく」といわれたときに 初心者PLは何をどうすればいいのか困ってしまうと思います。 実際、PLがやらなくてはいけない仕事は多く、多岐にわたる上、先輩PLにアドバイスを求めても、経験則な回答や場当たり的な助言しかもらえず なんとなくはこなすものの、プロジェクトが無事にゴールできたとしても 本当に自分がうまくやれたのかどうか、いまいち実感がわかない。 失敗しても何が間違っていたのかよくわからないまま・・・ そんな状態になってしまいがちですが、 PLの仕事の本質を突き詰めると、その役割は２つのタスクに集約されると思います。 それは ・タスクを洗い出すこと ・妥当なWBSを引くこと この２つです。 WBSとは 簡単に言うとスケジュールです。洗い出したタスクをだれがどのタイミングで、どういう順番でこなしていくかという予定表になります。 これを聞くと 「ふーん。それのどこら辺が大変なんだろう？」 「それだけ？」 「それができれば苦労しない」 と、感じ方は現状置かれた立場によって様々だと思います。 ただ、いずれにせよ、私が見てきた数々の炎上プロジェクトの大半は ・タスクの洗い出し方が雑すぎる ・スケジュール（WBS）を引いた時点で既に無理筋 というプロジェクトが占めています。 実際、システムエンジニアをやっていると 「こんな無茶なスケジュールで、できるわけがない！」 とか 「このフェーズで今更そんなこと言うの？そんなのわかってたことじゃないの？ そんなのねじ込んだら後続の作業全部破綻するよ？」 とか、誰もが一度は経験したことがあるのではないかと思います。 WBSとは洗い出されたタスクをもとにスケジュールを引くので そもそもタスクの洗い出し作業が荒かった場合、 作業が進むにつれ 「あ、...

タイトルの話をする前に もし、自社のIT部門が問題解決に動けていないのであれば 育成を間違えているので、抜本的に考え直した方がいいと思います。 抜本的に考えるというのは、 IT部門が頼りにならないから、外に答えを見出そうとする のではなく、 IT部門の役割を再定義し、あるべき姿へどう持っていくかを経営陣が真面目に考える という意味です。 そしてもし、現時点でIT部門が力不足だったとしても、外の世界に答えはありません。 例えば、コンサルに解決してもらおうと思ってもあまり意味がありません。 経験のある方も多いかと思いますが こういった種類の問題をコンサルに解決を求めても以下のような問答になるケースが多いのが実態です。 偉い人➡実はこういう事に困っているんだが、何かいい案はないかね コンサル➡なるほど、ではこういうやり方はどうでしょう？他社ではこうやってることが多いです。 偉い人➡なるほどね。しかし、それだと我が社では合わないんだよね。そこの部分は古参の人間が職人技でこなしているからね コンサル➡なるほど、それはよくないですね。ただ、人に依存しているとなるとどうにもならないので、まずは作業を標準化することにしましょう。 偉い人➡差し迫った問題のことを言っているんだが？ 作業を標準化して、属人化を防ぎ、二度とこういう事態にならないような体制にする という根本的な対応については、正直誰でもわかっていて 難しいのは、 それを今の属人化しきっている状況のまま、標準化までもっていく方法と、目の前まで起きている差し迫った問題をどう解消するか？を並行して進めないといけない ということなのですが ここにアプローチする為には、「なぜ属人化してしまっているのか？」という問題の真の原因を探らなければならず、現場にヒアリングするだけでは簡単に答えを導き出せないことが多いです。 現場では「その作業の難易度自体が高くて、熟練者だけしかそれをこなせず、その熟練者自体を何人も育てることが現実的ではないから、結果的に属人化してしまう。」という事を言っていたとしても、その作業を難解にしている本当の理由は、別にあったりします。（例えば工場内の動線の問題とか） こういった類のものは自社における経験と、細かいヒアリングを行えるだけの人間関係の構築など、いろいろなものがあってようやくたどり着けたりするものだったりす...

コンサルティングファーム（以下、コンサル）の立ち位置は別記事でも述べました。 ※あわせて読みたい 社内SEとSier、コンサルティングファームの違いは？ では、実際にコンサルと契約する時って、どういうタイミングでどういう風に選べばいいんですか？という質問を受けたので、これについても書いてみたいと思います。 具体名は書けませんが、参考になればと思います。 【どういう時にコンサルを利用する？ 】 いろんなシーンが考えられますが、一番多いのは ・コンサルが得意とするようなシステムを導入するとき です。 例えばSalesforceなど、使いこなせれば効果は大きいが、その使いこなしがとても難しく、いわゆる普通のアプリ感覚で導入しても、なかなか使いこなせないような製品などがそれに該当します。 また、このような巨大IT企業が提供しているようなサービスは、その企業自身が直接売ったり、導入したりすることはあまりなく、基本的にパートナー企業と言われる企業を間に挟んで導入することが多く、そのパートナー企業になっているのがコンサルティングファームだったりするので、導入したければ結果的にコンサルを経由することになります。 他には プロジェクトをリードする人間が自社の人間にいない場合 は そのサポート役として雇うこともありますし、 業務改善をする際に、自社以外の目線のチェックを入れたい場合 など いわゆる「べき論」を現行業務にぶつけたいとき等などに契約することもあります。 【どういう形で利用する？ 】 プロジェクトによって形態はさまざまになりますが 基本的にはチームとして契約することが多い と思います。 Sierであれば、技術力を提供してもらうという事で、1人とか2人と契約して常駐してもらうというようなことはありますが、コンサルではあまりそういった契約を見たことはありません。 ここもSierとコンサルの違いが出ますが、コンサルはSierのように技術力を売るというような営業はしないからともいえます。 結果、チームの維持費だけで1月、1,000万円以上になることも珍しくありません。 契約期間はプロジェクト単位になるので、1年～3年ぐらいのケースが多い と思います。 それ以上となると、おそらくコンサルの使い方を誤っているので、諸々見直した方がいいかもしれないです。 【利用する基準は？ 】 コンサルは...