読者です 読者をやめる 読者になる 読者になる

なからなLife

geekに憧れと敬意を抱きながら、SE、ITコンサル、商品企画、事業企画、管理会計、総務・情シス、再び受託でDB屋さんと流浪する人のブログです。

ブコメとコメントについての回答


そろそろ内製回帰について一言いっておくか。 - なからなLife
について、結構いろいろな反響をいただきましたので、そのいくつかについて、こちらにまとめてレスしていきたいと思います。

開発者は、自分たちが作っている製品なり商品をもっと分り易く伝えなくてはならないね。
http://b.hatena.ne.jp/imai78/20091225#bookmark-18144775


内製でも外製でも、アピールはもっとやっていい(やるべき)と思います。
ござ先輩のエントリにも

経営は基本的に技術屋のことなんかわかるわけないんですよ。
http://d.hatena.ne.jp/gothedistance/20091226/1261808023

という一文があるとおり、相手が勝手にわかってくれるようになるのを待つんじゃなくて、こちらからわかってもらうためのアクションが大事だと思います。


経営者に伝わるようなアピールができるようになれば、それは多分、つくるシステムが経営にどう関係するかがうまくまとめられているアピールでしょうから、提案力は相当高いんじゃないかと思います。
そんなスキルを自分も身につけたいですが、私もまだまだ精進が必要です。


アピール怠っていて?いきなり国からもらっていた予算バッサリ切られる事例がどこかにアリましたね。
あれが民間企業で起こると、いわゆる部門単位での子会社化、譲渡、事業整理解雇、という話になりかねませんし。

SIer中途の人がこのようにコンバートすることは稀だが、そうしたときかなりのパフォーマンスが出る。魔法戦士みたいな。
http://b.hatena.ne.jp/steelman/20091226#bookmark-18144775

SEやITコンサル経験者は、こっちの道に入るのも面白いですよ。
なかなか採用枠は少ない世界ではあるものの、ゼロではないですし、潜在的なニーズはもっとあるはずです。


面白いように案件回せたり、受託側にいる時代に当然の事としてやっていること*1が「すげー」と評価されたり。
逆に、いきなり外部のやり方を持ち込んでも周りが合わせられないケースもあるでしょう。


そんな時は、段階的に広めるようにしてレベルをあわせ、全力を出しきらないという、ちょっとズルい方法もアリだと思います。8割位のパワーで仕事を回せるポジションを確立し、残り20%は自分を磨くために、読書に回したり、新しい技術要素を学んだり、勉強会に出てみたり。これができるようになると、忙しさ故にスキルを磨く時間がない、とか言っていた負のスパイラルが逆回転し始めます。


求められているものを提供し、自分を磨く時間も確保できれば、まさにwin-winですね。


ただし、本質的にラクな世界ではないです。受託側にいると、クライアント側の接点は内製エンジニアというか、いわゆる情シス部門の人となることが多いですが、彼ら情シスみて「ラクそう」と思っていたら大間違いです。


そこは勘違いしてはいけないです。大変さの中身が違う。ラクそうに見えていたら、多分、その情シスの業務の一面しか見て無いです。
目の前にいる情シスの人の業務もちゃんと理解せずに、情シスの向こう側にいるエンドユーザーの業務効率化提案とか、夢物語もいいところです。


ただ、受託でツラい思いをした経験をちゃんと身に染み込ませ体系的に理解していれば、内製部隊があまり持っていない業務効率化のノウハウとして活かせたりしますので、もし内側の人となったら、そこで差別化することができます、という話です。


あと、ござ先輩のエントリのブコメ絡みで気になったのが
「できるからやる。できないからやらない。」についての話。


「できないで片付けたら先がない、が、どうしたらいいか分からない」ということが多いんじゃないでしょうか。


私の考えはこんな感じです。


人が何かの問題について「できない、手に負えない」と感じてしまうとき、問題の分解が甘いことが多いです。
手に負えないレベルの大きさで問題を見ていて、いきなりそれを解決しようとするからできない。


問題の構成要素をしっかり分解して把握して、自分の扱える大きさにすると、いくつか解決できる問題が含まれるハズです。


そこから手を出つけていくと、絡まった糸がほぐれるように次の問題解決の糸口が見つかったり、が問題解決スキル自体が上がって次の問題が解決出きたり、そうした活動を認めて協力してくれる人が出てきて、その人が問題解決の鍵を握っていたりといった新局面が出てきたり。


正直なところ、私もめちゃめちゃ動きが早い訳ではありませんが、それでも「動いてみたら、思っているよりなんとかなった」という小さな経験を積み重ねて、「うごかなきゃ、何も変わらない」という思いを強くしています。


あと、「できないからやらない」と言って何もしないのは、まったく評価に繋がらないので、何かしらやっているように見せるという、ややひねくれたテクニックも必要です。
ビジネスの現場では、ベクトルゼロの動き=静止状態、というものが、それがどんなに正当な理由で、実際に合理的であっても、恐ろしいことに、まったく評価対象としてもらえません。間違っていても動いたヤツが評価されます。止まっていると、間違った方向に動いたヤツのとばっちりさえ受けます。そうしたことからの回避行動としても、何かしら動いている方が害が少ないです。



最後、ブコメではなくコメントいただいた件について。(長いので引用割愛します。)


究極的には

「内製か外製かの違いはどちらでもよい」
「ROIの高低だけが問題」

であることについて同意です。


そのROIの最大化という目標に対して、
「内部にエンジニアを抱えていることの目的を明確にし、そのメリットをちゃんと活かせば、外部に委託するよりもバリューを出せるはず」というのが、今の私の思想・志向的ポジションになります。


外部に委託することによって「会社間取引であることによって生ずる色々なプロセス」を内製にすることで省ける、それだけでもかなりメリットがあるので。

「システム提供者がうまく(早く少ない工数で)システムを作ると売上/利益が減ってしまうため、システム提供側が早く安くシステムを作成するモチベーションを持ちえないことが癌」

というのも、会社間取引だからこそ発生するところであり、内製で自社システムをつくるということは「早く完成させた方が売上/利益に貢献」するため、こうしたムダな発想が入る余地がないはずです。


また、ROIを語るとき、投資(Investment)した額が同じで、その回収額(Return)が同じであったとしても、そこには「時間」に関する評価指標が含まれません。
「早く回収出来ること」が経営において非常に重要である、ということは議論の余地はないと思います。
その「時間」について、内製によってプロセスを省略できることによるメリットは非常に大きいはずです。


ただし、現実には、そううまくいってないケースが多数あります。
そして、コスト面だけじゃなく、時間の面でも「内製<外製」になる場合があり、そうした場合「時間をカネで買う」という経営判断が下されるシーンもたくさん見ています。


そんな経営判断を下されたとき、内製エンジニアには「悔しい」と思う気持ちを持って欲しいと思っています。
つまるところ「頼れない」といわれているに等しいからです。

今回のエントリは、内製エンジニアとして働いている人、これから内製エンジニアになろうとしている人への応援、激励の想いが込められています。


「提供するシステムの価値によって対価を決めるサービス化」という言葉、概ね賛成で昔からそういう想いをいだいてはいるのですが、「システムの価値」で測るようになった場合、「要件、仕様を取りまとめる」という部分は、何で測るんでしょうね。システムの良し悪しを決めるのは、じつはこっちのスキルにかかっていたりしますが、実態としては分割して契約していたりするので、個別に評価して価値を定めなくてはならないという。。。


私の中にはまだ答えがないです。



受託SI業界は確かに厳しい状況にあり、それは一時的なものではなく、傾向として進んでいくものであるとおもいます。
コスト構造の改革も重要ですが、とにかく仕事が取れないことにはやせ細る一方です。
競争相手になるであろう新興国SI企業、ユーザー企業内の内製エンジニア、SIへの業務拡大を進めるべく上流から降りてくるコンサルファーム、そして、そもそも専門知識をもつエンジニアを不要すべくパッケージングされたソフトやWebサービスの多様な試みを仕掛けてくる企業に比べて、よりクライアントに認められる価値を提供することですね。

端的に言うと勝負するポイントは「受託SIとしての、その企業ならではの強み」です。
たぶん、クライアントはそれを買うんです。
ヨソに発注したのでは手に入らないそれを。
その差別化要因がない場合、比較対象は値段しかないので、否応なしに価格競争に陥るでしょう。


こんな感じですね。
なにをエラソーに、って事も言ってますが、「そうありたい」という想いを書き表すことも、変化に向けた第一歩、ということで。

*1:それでもなお、あれがダメ、これがダメ、とかいわれてたりする。