A Day In The Boy's Life -200ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

Open Source vs SaaS @ Casual Thoughts


この辺りの話題って、


・ 自社開発 vs パッケージ(ASP)

・ 社内運用 vs レンタルサーバー(ホスティング)

・ 社内要員 vs コンサルティング


という構図でも成り立つと思います。

コストや導入期間、カスタマイズの容易さなどは、ここで挙げられているメリット、デメリットがそのまま適用できるかと。

3番目は人ですが、その特性はよく似ているものかと。


まだ、Open Source vs Saasという構図は私は経験したことが無いのですが、ここで挙げた3つの例はシステム化施策が持ち上がった際に、必ずといって良いほど出る話題です。

このレベルならわざわざ社内で決裁をあげて、サーバーを調達しなくてもレンタルサーバーの方が運用コスト含めて安くね?とか。


情報システム部門は、基本ベクトルが内を向いているわけで、そこで提供できるサービスレベルなどたかが知れていたりもするわけです。

グローバルに展開している企業で、昼夜問わずアクセスがある社内システムを運用しているならまだしも、国内の拠点を結ぶだけのようなシステムであれば、情報システム部員が24h/365d張り付いて監視するメリットというのはほとんどの場合ありません。

他の社員同様に就業時間が過ぎれば返りますし、土日も普通に休むわけです。(トラぶれば連絡がきますが)


個人的な意見ですが、私はこれらの社内調達 vs 外部調達という構図に対しては、自社ですることによさを感じている方です。

コストや導入期間では、場合により外部から調達してきた方が早いことが多いですが、それを外部から簡単に持ってきてしまう事で生まれる弊害も大きいと感じています。


まずは、社内のスキルレベルの低下。

外部から調達してきた場合、社内のリソースが費やす時間の大部分は上流工程です。

技術的な要因がもとより、それにかかるコストを懸念して外部から調達するわけですから、社内の人がその技術的な領域に足を踏み入れる要因はほとんどありません。

あるとすれば、社内でそれを展開するにあたって必要な月並みで局所的な技術要素のみ。

例えば、社内でサーバーを運用するに当たってのポリシーとか、社内ネットワーク利用に関する制約とか。

これでは人が育ちません。

せっかくシステム関連の部門に勤めているのであれば、技術的な要素に触れて日々精進したいというのはエンジニアの願いでもあるかと感じます。

なので、そのスキルが社内ではありきたりであり、それを誰かに任せることにメリットが無く、かつ時間的な制約からコストをかけてもよいと判断できた場合、外部からの調達を考えたいと。


次に、外部から調達したものの場合、そのスキルが局所的でしか使えない場合が多く、エンジニアのキャリアパスを描く事ができない。

あるパッケージを導入した場合、それがメジャーで広く世界に通用するものであればよいですが、そうではない場合、それを運用する事で得られるものはほとんどありません。

基幹系のシステムであったりした場合、そのパッケージのライフサイクルは相当長くなったりもしますので、それを運用する人は、極端な表現をすればそのパッケージと心中する羽目になります。


最後に、引継ぎコストとシステムの愛着の低下。

外部から調達した場合、その展開までの期間は社内で作り上げるものに比べれば著しく短く済みます。

ただ、そこからのコストが結構あって、それを運用に持っていくまでの引継ぎのコストが結構かかる点。

また、外部から持ってきたシステムであった場合、そのシステムに対する愛着というものがでません。

それが仕事なのに何をそんないいかげんな感情で、と仰るかもしれませんが運用部隊にとってはそのシステムに愛着を感じるかどうかもモチベーションにつながったりするものです。

愛着が出過ぎるのは困りもの ですが、適度の愛着を持っていれば、いやいや運用するシステムよりは効率的にその業務を回していく事ができます。

生みの苦しみを経てリリースしてシステムはやはり愛着が出るものです。


ビジネスのスピードが加速を続けていく中で、社内のリソースを使ってというのは足枷になる場合も多いのですが、それを導入する事の弊害というのも考えてみる必要があるかと。

逆を言えばエンジニアはその外部のサービスに抵抗しうる武器を持ってないと厳しいとも言えると思います。




SI業界の老害が若手と下請けを蝕む理由 @ ひがやすをblog


この老害がプログラミングを分かってくれない理由は、「あの時」で頭の中の時間が止まってしまっているためかと。

「あの時」というのは、その人がプログラミングを「わかった」(少なくともその人にはそう感じられた)そのときからで、そこからの思考が止まっており、それ以降の情報を受け入れていていません。


プログラミングの世界に関わらず、ネットの凄いとこを語ってもまるで相手にしてくれません。

少なくともネットの凄さというのは分かっています。

分かるといっても、周りで「ネットは凄いよ」と騒いでいる噂を聞きつけて知っている程度で、本質的に何が凄いのかという点は理解していない事は言うまでもありませんが。


このネットが凄いというのは、インターネット黎明期に見られた技術的な点での凄さ(世界中のコンピュータがネットワークを解してつながり、もう一つの仮想空間を作った)に対してだけ感心しているだけで、その中でどのような事が起きているのか、それが何故凄いのかという点は理解しようともしていません。

今までに無い技術だから凄いというだけで、インターネットが生み出した物理的な制約を飛び越えたコミュニケーションや人知の集合、そしてそこから生み出された人類の新たな進化など、技術の枠を超えた凄さというものには気づいていもいません。

技術的な凄さ以外に感じていることは、情報を即時に交換・発信できるマーケティングツールという捉え方ぐらいでしょうか。

ここでも、ネットの凄さを理解した(ように見えた)「あの時」からその人の脳の中では時間が止まっています。


梅田望夫氏と茂木健一郎氏の共著である「フューチャリスト宣言 (ちくま新書 656) 」の中で、梅田さんが「リアルな世界で満足している人ほどネットに関心を持たない」と言っていたのはよくわかります。

「あの時」から思考が止まるのは、リアルな時間を無駄にしたくないためかと。


話を戻してプログラミング界での老害についてですが、こういう人たちと話すと必ず出てくるのが、まさに「あの時」の話題です。

若い頃を回顧して、あの時はこんな事件がおきてそこから毎日徹夜して・・・、そして最後に続くのが、「今の君たちじゃなかなかできない事だよ」と。

まず、時代の軸が大きく違っているので簡単に比べる事などでき無いことに、その人たちは気づいていません。

苦労話なんてしだすと、その時代や状況から着地点など見出す事はできません。


大事なのは「あの時」ではなく、今どうなのかという点。

そういう意味で、重鎮にとって必要なのは経験のある・なしではなく、今をまさに体験しようとする感性ではないでしょうかね。

ただ、これは誰にでも同じこと。体験しようとする向上心を忘れるとそこからの進化が止まる事になるのだと思います。




ウェブを変える10の破壊的トレンド


ただし、読んだわけではありません。聴いたんです。

IBMが開催する渋谷テクニカルナイト のセミナーの音声データがPodcastとして配信されており、その中でこの本の著者である渡辺 弘美紙が、公演を行っている音声データを取り込んで聴いたわけです。

(公演資料もあわせてダウンロードできます)

ほぼ本の内容にそって話を進めているので、本をまだ読んでないけど興味がある方は是非聞いてみてはいかがでしょうか。(著者が風邪を引いていたため、多少聞き取りづらいのはご愛嬌)


本のタイトルとなっている10のトレンドをアメリカの先進事例などを元に、流行っている技術やサービスについて分かりやすく解説しており、エンジニアのみならず、IT系の仕事に従事している方であれば深い興味を持つ内容だと思います。


しかし、Podcastの技術ってやっぱりすばらしいと思う。

2時間近くの公演の音声データですが、本を読むよりすーっと頭に入ってきますし、Podcastを聴けるデジタルオーディオプレイヤーを持っていれば、満員電車でも気にならずに情報を取り込むことができます。

今回のようなセミナーは、時間や地理的関係から参加が難しくとも、ネットを通して何時でも何処でも聞く事ができるようになり、そんな制約を飛び越えさせてくれるところがそのよさです。

ただ、この技術があまり浸透していないことが非常に残念ですが・・・。