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

社内SEとSier、コンサルティングファーム（以下、コンサル）というのは同じIT業界にいてもその毛色はかなり違います。 （ちなみにここではコンサルティングファームというのはITコンサルのことを言っています。） あわせて読みたい 多重下請け構造の各社はどういう思惑でプロジェクトに臨んでいる？ 特に社内SEとコンサルは、かなり違います。 同じプロジェクトにいるだけで役割と目的が両極端にいるイメージです。 一方、Sierはその間に位置するという感じなので、Sierから社内SEになったり、コンサルになったりはそこまでハードルは高くないですが、 ・社内SEからコンサルに転職 とか ・コンサルから社内SEに転職 は結構ハードルは高いです。 ここでいう「ハードルが高い」は転職できるか否かというよりも、転職できたとしてモノになるか？という意味です。 コンサルから社内SEへの転職自体は行けると思います。 「コンサルにいました」ということ自体が、「仕事できそう」につながる経営者や採用担当者が多いからです。 ただし、上に述べたように、その役割はかなり違うので実際に働き始めると 採用した側は 「あれ？もっと優秀なんじゃないの？」 となることも多いし 採用された側も 「え？なにこれ、思ったのと全然違う」 ということになりがちです。 これはどちらかがいいというわけではなく、 ものすごく切れ味の良いハサミで釘を打とうとするかのように、目的と用途が食い違っているからです。 では、具体的に何がどう違うのか？ですが 社内SEは企業の一部であり、コンサルはスペシャリストにサービスを提供するスペシャリストであり、Sierはその中間に位置する という違いになります。 もう少し掘り下げると まず、立場が違います。 社内SEはあくまで企業の一部です。ITソリューションを売るというのが仕事ではなく、自社の課題を解決するのが仕事です。 コンサルはITソリューション(ITの製品)を売ること自体が仕事です。 SierはITソリューションを売ることだけではなく、役務(技術力)を提供することもあります。形を問わず、問題解決の手段を提供するのが仕事です。 ですので サービスを提供する相手も違います。 社内SEがサービスを提供する相手は、その企業で仕事をする仲間達 いわゆるエンドユーザーといわれる、本当にそのシステムを利用す

ITプロジェクトは必然的に多重下請け構造になりがちなのは別の記事で述べたとおりです。 あわせて読みたい プロジェクトを構成する人たち プロジェクト管理をする上で、この多重下請け構造の中にいる それぞれの人たちの立場や思いを汲み取れるようになると プロジェクトの成功に大きく近づきます。 少し悲観的な部分もありますが、踏まえていて損はない話だと思いますので、 ぜひ参考にしてください。 まず、前提として プロジェクトのオーナーである発注側の人間の目的は プロジェクトの成功です。 導入したいと思っているシステムを ・限りなく希望通りの形で ・予算内に ・遅滞なく ・リリースする これが唯一無二の目標です。 ただ、ここで忘れてはならないのが プロジェクトに参加しているメンバー全員がこう思っているかというと 全然そんなこと思ってない という所です。 では、各企業がどう思って参加しているかをまとめてみます。 【１次請け企業 】 プロジェクト開始時期は、発注側と同じ方向を向いています。 ただし、 ・プロジェクトの雲行きが少しでも怪しくなる ・発注側とのコミュニケーションが悪くなる こうなると 「どうやったら瑕疵にならないでプロジェクトを終えられるか？」 こういうことを考え始めます。 ちなみにどんなプロジェクトも一度も波風立たずに終わるなんてことはないので 放っておけば99%の確率でこの考えに至るといってもよいです。 そうなると何が起こるかというと できるだけ自責にならないように振る舞い始めるので、 各タスクの判断や結論は発注側に出させるように仕向ける しかも、できるだけ発注側の言質が残るような形にする。 とか 意図的に自責部分を隠した報告書を仕立て始める などといった妙なリスクヘッジをし始めます。 本来、プロジェクトにおけるリスクヘッジとは、 プロジェクトを成功させるための物ですが こうなってくるとただの保身ですね。 一次請けというのは、 そのプロジェクトの成否の責任を負う立場にいるからこその一次請けなのですが それ故に、最悪の事態を想定して、 保身の為のリスクヘッジを取り始めることが往々にしてあります。 勿論、プロジェクトが失敗すると自身の評判にもつながるので、 できれば成功したいとは思っていますが 「瑕疵になる」というリスクと比較したら、些末な問題だと考えています。 プロジェ

プロジェクトを構成する人たちとして、主な構成は前に書きましたが その他にも色々な立場の人がいます。 その中で「PMOって何する人なんですか？」という質問を受けたので 今回はPMOについて少し書いてみます。 PMOは「プロジェクトマネジメントオフィス」の略で プロジェクト全体の品質チェックだったり進捗確認をしてくれる人達になります。 ただ、ちょっと立ち位置が他のポジションと違う事が、 この役割をわかりにくく、活躍させにくくさせていると思います。 プロジェクトを進めていると突然、PMOを名乗る人たちから ・手順書の品質が悪いから是正してください ・WBSの引き方がおかしいので、妥当な線を引いてください ・開発プロセスは省略せずに、手順を守って下さい。 等々のダメ出しメールを受け取ったことがあるかもしれません。 「なんだ？突然現れたこの人たちは？いきなりメール送ってきて」 と思うのは、当たり前といえば当たり前で この人たちは、プロジェクトの当事者という扱いではありません。 設計をするとかユーザーにヒアリングをするとか、 そういうプロジェクトの進捗を進める実務に携わるリソースとしてはカウントされない 言わば、お目付け役のような人たちです。 そんな彼らが設置される目的は プロジェクトの健全性を保つこと です。 平たく言うと、次から次へと湧き出るタスクに押されておろそかになりがちな 品質問題や、プロセスの健全性 をチェックして、 システムがブラックボックス化するのを防いだり、 誰も承認していないような機能のリリースを防いだりする といったところです。 会計監査のプロジェクト版みたいな感じと言ったらわかりやすいでしょうか。 プロジェクトに携わった人なら誰しも経験があると思いますが カットオーバー間近になると、みんな最後の総仕上げでタスク山盛りで 一分一秒も無駄にできないような空気感が満載です。 そうなるとどうしても、 「あー、これチームリーダーに話を通しとかないといけないけど、そもそもプロジェクトリーダーに直接言われた奴だし、もういっか、端折っちゃお。」 とか 「あー、これ先に手順書作らないといけないんだけど、もう時間ないから手順書は後！どうせ誰も見ないでしょ」 っていう状況になりがちです。 この状況に対してストップをかけるのがPMOです。 【PMO】いや、ちゃんと手順書書いて、

プロジェクトを構成する人というのは、役割も立場も様々な人が入り混じっていますが、 その中でも「プロジェクトを成功させる、キレイに着地させる」 という意味であれば 一番大事なのはプロジェクトマネージャー ではなく、 プロジェクトリーダーです。 プロジェクト運営の旗を振る、いわゆる現場監督のような立ち位置がプロジェクトリーダーです。 このプロジェクトリーダーが力不足だと、 プロジェクトマネージャがプロジェクトリーダーの仕事を兼務し始める というようなことがおこります。こうなった場合のデメリットは ➡プロジェクトマネージャがプロジェクトリーダーの職務を補えるほど優秀だった場合 　 プロジェクトマネージャがマイクロマネジメントし始めるので、 　 本来のプロジェクトマネージャが行うべき、「決めるべき問題に決を下す」 　 というタスクがこなせなくなります。 　 これはこれで大問題で、プロジェクトマネージャ自身が 　 プロジェクトのボトルネックになってしまいます。 ➡プロジェクトマネージャにプロジェクト管理の経験がなかった場合 　 単純にプロジェクトが終わります。 　 下記のケースに展開するか 一方、以下のようなケースに派生することもあります。 メンバーがプロジェクトリーダーの仕事を担い始める こうなった場合のデメリットは ➡そのメンバーがプロジェクトリーダーの職務を補えるほど優秀だった場合 　 プロジェクトマネージャとは逆ですね。 　 手を動かさないといけない人たちが管理業務までし始めるので、 　 タスク過多になり、本来のメンバーの職務である設計作業や開発作業など 　 が遅延し始めたりします。 　 また、１チームの中に複数のリーダーが立ったりすることになったりもするので、 　 「船頭多くして船山に登る」状態になります。 ➡メンバーではプロジェクトリーダーの穴を埋められなかった場合 　単純にプロジェクトが終わります。 私の経験上、実はプロジェクトマネージャは替えが効きます。 プロジェクトマネージャは決断を下してくれさえすればいいので、合致する立場の人をアサインすればそれで解決することも多いです。 勿論、プロジェクトマネージャも優秀であることに越したことはありません。 優秀なプロジェクトマネージャと、プロジェクトリーダーが組み合わ

プロジェクトを構成する人たちをちょっとまとめてみました。 と言っても、会社ごとにそれぞれの立場の人が担う役割というのは 違ったりするので、あくまで一例としてになりますが、 このブログの記事内ではこういう前提で捉えているという風に考えてもらえればと思います。 プロジェクトオーナー 開発されるシステムの持ち主となる人です。 主管部門の部長等が任命されることが多いです。 (例えば経理システムだと、経理部長とか) 作ろうとしているシステムそのものに意思入れをする人と言い換えることもできます。 プロジェクトマネージャ (PM) プロジェクトを進める上での障害や承認事項について 諸々の決定権を持つ人 IT部門の部長が務めることが多いです。 よくある「決めの問題」という所を決める人。 プロジェクトでは、良し悪しだけで判断できず、「好み」とか「政治的な理由」でないと判断できないような事柄がちょくちょく発生します。そういった問題に対して調整、決定を下します。 プロジェクトリーダー (PL) プロジェクトを成功させる為の具体的な管理作業を行う人 プロジェクトのフェーズごとに現れるリスクを検知して、その解決手段を講じたり、ステークホルダーといわれる関係者（つまり偉い人）に対してPMが説明するための資料を準備したり、報告するべきこと、しなくていいこと、しない方がいいことを取捨選択したりします。 メンバー プロジェクトにおいて、手を動かす人。 要件定義をしたり、設計をしたりします。 以下のような構成になることが多いです。 発注側 発注側企業の社内SE １次請け ビッグベンダーやコンサルティングファーム ２次請け 中小SIer ３次請け 中小SIer という感じです。 他にもよくあるケースとして、1次請けの会社がプロジェクトリーダーを立てることも多いです。ただ、この場合のプロジェクトリーダーはあくまで発注側のプロジェクトリーダーの補佐という立ち位置になることが多いので、概ね上記のような構成になっていると考えて齟齬はないと思います。 ここからメンバーと記載した部分について、少し掘り下げていきます。 いわゆる多重下請け構造になっているといわれる部分ですね。 まず、システムのプロジェクトが立ち上がるとします。 規模は5億円ぐらいと仮定したとして、 発注側

企業のシステム開発の内製化はあまり現実的ではないのでは？ ということについては別記事で書いていますが、 あわせて読みたい システム開発の内製化について　その１ 今回はその第2弾です。 その1では内製化はコスト削減にはならない（と思う） という点について書きましたが、 この記事では 内製化してしまうと、最新IT技術のキャッチアップが難しい という点を書きたいと思います。 まず、内製化の目的ですが、IT関連のプロジェクトの全て、ないし大部分を社内で賄いたいということがあると思います。 その思いの中には当然、プロジェクトで最新技術を利用したいというものもあると思います。 しかしながら、IT技術の進化・変化のスピードは、とても速く 目まぐるしく移り変わる技術を追いかけるのは大変の労苦を伴います。 スマホでも使っている方が多いであろうクラウド技術 Netflixでもおなじみのサブスクリプションなど いまやすっかり当たり前の技術として定着しつつありますが 少し前まではこんな技術が、ここまで普及するなんて、誰も夢にも思ってなかったと思います。 では、その技術革新のスピードの速さと社内SEではそれを追いかけられないという事実がどう相反するのか？ということですが、それを語る前にまず社内SEの本分を整理したいと思います。 社内のSEに求められている役割は様々ありますが、 IT初心者であるユーザーとIT専門知識の橋渡しの役割 というものがあります。 社内SEはただでもわかりづらいITの話を素人であるユーザーに メリット・デメリットを説明して、効果の最大化を図ったり、 リスクの最小化を図らないといけません。 そんな社内SEに必要な知識はIT知識よりも、むしろ自社の業務知識です。 自社の業務が何をしていて、どこに問題があり、どうアプローチしたら問題解決に有効かを考えなくてはいけないので、なによりも業務知識が最優先です。 必要最低限のIT知識はある前提で、最新技術は・・・という意味です。 この役割に「 技術革新のスピードに追い付かなくてはいけない 」 という役割を社内SEに課すと、社内SEは自社で起こっている課題や業務について精通しつつ、なおかつ自社の外で起きている技術革新も追いかけるということをしなくてはならなくなります。 これは例

IT業界は多重下請け構造になっています。 他の業界ではさほど一般的な仕事のやり方ではないので、 他業種の方に話をしてもピンと来なかったりしますが ITで仕事してる人達には至極当たり前の構造だったりします。 多重下請け構造とは ある会社が受注した業務を、別の企業にさらに発注する。場合によってはその業務が更に別の企業に発注されるというような仕事の仕方の事です。 丸投げする場合もありますし、自分たちで補えない部分だけを外だしする場合もあります。 この多重下請け構造というのは、建築業界のニュースなどから 得てして批判されがちですが、IT業界では致し方ない部分もあります。 何故かというと、一口にIT業界といっても、必要となる知識が多岐にわたり、一括りにできないからです。 ・ゲーム業界の仕事をしているIT会社 ・製造業界の仕事をしているIT会社 ・web制作の仕事をしているIT会社 いずれもほぼ全く違う知識を使います。 いずれかの会社で経験を積んでいても、他の2社ではまた1からキャリアを積みなおすことになる、そのぐらいの違いがあります。 このブログの他の記事でも何度も言っていますが、ITと一口に言ってもありとあらゆる業界で使われており、そんなあらゆる業界の技術について、一社ですべて賄えますというような会社などない為、様々な得意分野を持つ会社を組み合わせて一つのプロジェクトに臨むことになるのですが、それが結果的に下請けの階層化を招くことになるわけです。 さて、そんな前提を踏まえた上で、ここからが本題になるのですが システム投資はとてもお金がかかります。 最近はサブスクリプションサービスが増えてきたので、 だいぶ導入費は抑えられるようになりましたが 既製品をまるまま使うということでもなければ、 どうしても導入のエンジニアを雇ったりするので、やっぱり導入費用は膨らむ傾向にあります。 物によっては数億円というような規模に膨らむことも珍しくありません。 そうなると、この1つのプロジェクトにたくさんの業者が参加することになります。 結果、多重下請け構造になることが多々あります。（というかほぼ間違いなくなります。） しかし、面白いことにITプロジェクトで多重下請けになった場合 発注側の企業と直接コミュニケーションをとるのは1次請けの会社だけで

今回の題材については、すでに痛い目を見ている会社もあると思うので 今更感はありますが、改めて記載しておこうと思います。 情報システム部門をシステム子会社として外に出した場合のメリットは ・固定費削減 ・あわよくばグループ全体の売り上げ貢献 というところだと思います。 言葉を飾らず言うと、 固定費を削りたいので別会社にします。 仕事はあげるけど、足りない分の食い扶持は自分で稼いでね。 です。 固定費は削れるわ、子会社として頑張ってくれればグループとしての売り上げは上がるわ 一石二鳥を狙ったわけです。 そして、ご存じの通りこの思惑はうまく行かず 子会社化した情報システム部門を呼び戻すことになったり それができずに圧倒的にITに弱い会社になったり という結末を迎えてしまいました。 なぜこうなってしまったか。 という理由ですが、つまるところ 子会社は別会社である ということです。 子会社になってしまえば、「された」側はまさに「した」側の思惑通り 自分の食い扶持は自分で稼がなくてはいけません。 そうなったら当然、親会社のことばっかり考えてられません。 もちろん、親会社のいう事は優先度が高いので、無碍にすることはありませんが 親子関係を盾にコストダウンを迫ってくる上、自分たちの生活の保障をしてくれるわけでもない人達のいう事を本気で考える訳はないのです。 「本当はこうやったらいいんだけどなぁ。まぁけど売り上げになるわけでもないし放っておこう。なんだったら困って泣きついてきて、新たな案件になるかもしれないし。」 こう思っても不思議はありません。 そんなお金にならないことばかりに気を使ってもしょうがないので 親会社以外のもっとお金になる顧客がいればそっちの方を熱心に考えはじめます。 そして、 発注元自身が「発注先がそういう風な思考に進んでいるかも？」ということを判断できる人達を手放して、当の発注先にしてしまっている のですからどうしようもありません。 一方、社内SEは違います。 社内で起こるシステム課題は我が事であり、それを解決するサービスを提供することが職務ですから、課題に臨む姿勢が根本から違います。 課題を解決できなければ存在理由がないですし、実際それによって会社の売り上げが下がって困るのも自分なのですから、当たり前