tdtshのブログ

ほらね。今は、新しいサービスを作るには、絶好のチャンスなんですよ。わたしもトライするし、いろんな人にトライしてもらいたいなぁと思います。

こんなこと書いて、お前になんの得があるんだと思われる方、あるいは、どうしてそんなに必死なんだと思われる方もいるかと思いますが、理由は簡単。私が新たなサービスを立ち上げて仮に成功したとしても、その効果はたかがしれています(自分の周りだけ)。

行動力なある人がどんどん、次の成長分野に挑戦して成功するとで、日本も成長路線に戻れるかもしれません。ほっとくと日本は衰退するからね。

グローバルな社会なんだから、日本が貧乏になろうが、金のあるところから取ればいいだろうと思う方もいると思いますが、日本人である以上そこまでドライには考えられないのが、実際のところ。

だからこそ、次の成長分野に一緒に挑戦しようよということです。

新しいサービスを作るのになぜ今が絶好のチャンスなのか – ひがやすを blog

（´；ω；｀）ﾌﾞﾜﾜｯ
感涙。

トライしましょう。
Google App Engine と slim3 に感謝しつつ。
そして恩返しの為にもブレイクしたいものです。

さて、ひがやすをさんも言われる様に、WEBサービスを立ち上げるにあたって、クラウド、HTML5、スマートフォンと、天の時は今な訳です。

slim3やGAEやHTML5が書ける方は勿論、コードを書く意欲と能力があるなら、兎に角行動する事が可能です。

ただ、打率を上げる為には、UIとかのデザインとか企画とかコンテンツとか、自分にないものを補える仲間がいた方がいいと言う意味では、人の和が一番重要です。

それはさておいて、地の利について。

資金があるとか、人脈があるとか、一芸に秀でているとか、一部の優秀な人は除き、そうでない普通の人(私の様に)は、会社をやめて起業してWEBサービスを始めるというのはリスクが大きいです。

参入障壁が少ないとしても、新規WEBサービスなんてものは10個やって1個あたれば儲けモノ位に考えたほうがいいです。

覚悟を決めて打席に立つ事をしないとヒットは打てませんが、何度でも打席に立てるように自分のポジションをもっていくなどの工夫が重要です。

なので週末起業でも良いと思うんです。

それも難しいなら、今いる会社で稟議起案してみてはどうでしょう。

それも無理なら・・・転職もアリです。

WEBサービスを立ち上げたい、と思っていても、人材がなかなか見つからない中小企業も沢山有るはずです。

以前も書きましたが、エンジニアは中小のエンドユーザ企業にいた方が、資金、経営、プロモーション、法務などの色々なリソースを活用できて、得意分野に集中できるってモンです。

ただ、所詮雇われ、意思決定のスピードとかはスポイルされます。

勿論、勝算のあるビジネスモデルとサービスのアイディアの有る方は、起業してチャレンジして頂きたい。そして無力な僕を雇ってください。

エンジニアの時代｜渋谷ではたらく社長のアメブロ

この記事、

少し前に社内向けに作ったプレゼン資料と内容が凄くかぶっています。
だから、我が意を得たりと言うか、ちょっと嬉しくなりました。

特に、

・ネットサービスはローンチ後にスピーディーに改善を積み重ね
なければならないため、内製化が鍵。

ここは激しく同意です。
産み出す苦しみより、育て上げる難易度の方が遥かに高いです。
最初に外注で作ってしまうと楽だけど、内製できる技術力が無いからといってそれをすると、自分たちで保守出来ない様になる危険性が高いです。
極端な話、ボタン1個増やすのに見積もり取って稟議あげて・・・とかあほらしい事になる。
それならば少し遠回りでも、基本的に自分たちで作る、足りないパワーはうまく外のマンパワーを借りるとか、SaaSと連携するとか、コアな部分だけを内製する努力をする方が良い。

・twitterやiphoneの良さは企画書や口頭の説明では解らない。
プロトタイプ（試作品）を造れるのがエンジニアの強み。

これも激同です。
私の言い方ではWEBサービスは特にウォーターフォール型よりアジャイル型、スパイラルアプローチでの開発が向いている、となります。
反応を見ながら作っていく事が大事。時には壊して作る。
ユーザ自身も、経営層も、そして開発者や企画者も、実は何が欲しいのか、何がユーザに受け入れられるのか、事前に判っていない。

ユーザにニーズを聞いてから作ると、極端な話しょーもないモンが出来る。
大勢で相談しながらみんなで仕様を練り上げると、無駄が多く高機能な割には焦点がぶれまくりとか性能が悪いとかのアホなシステムになってしまう危険性が高い。

プロトタイプか、最低でもモックアップがありきで、それをたたき台にしてブラッシュアップしていく方法の方が良いです。この方法で議論を大勢でするのは大いに結構。

それでも、ユーザが知覚する情報、デザイン、コンセプトの一貫性は、誰か一人が責任を持つ事で担保した方が良いです。

船頭が多いと船が山を登る事があると聞いたことがあります。

・ソーシャルアプリ、クラウドによってより小資本でスピーディーに
事業を立ち上げられるようになった。

ですよね。
だからといって起業する程身の程知らずではありませんが、中小企業ほどクラウドを活かさない手は無い。

・スマートフォンの急激な伸びによる新たな事業機会

スマートフォンに加えてiPadのようなタッチパネルでタブレットなデバイスが伸びるでしょう。何故なら、情報を消費するだけの普通の人々にとって、パソコンなんて判りにくいモンを使わせようと言う事自体が間違ってます。
これらのデバイスの普及は、デジタルデバイドがある程度解消されるチャンスです。
もうちょっと普通の人向けのサービスが求められるんじゃ無いですかね。

最大の問題は、どうやってマネタイズするかですね。
WEBサービス単体で利益を上げるのは、バンドマンがメジャーデビューする事よりも難しい。

保守できなくなり、塩漬けにしたままのオープンシステム—。いま“オープンレガシー”が情報システム部門を苦しめている。
…
　1990年代から2000年代の初め、オープンシステムは「早く安く作れる」「新しい技術が使える」「1社のベンダーに縛られない」といった輝きを放ち、“自由”の象徴だった。このメリットを追って、多くの企業がメインフレームからオープンシステムへと開発の軸足を移した。
　だが今、その輝きは色あせ、輝きの裏に隠れていたデメリットが情報システム部門に重くのしかかっている。「早く安く作れる」というメリットは「作りすぎて保守できない」というデメリットに裏返された。「新しい技術が使える」というメリットの裏には「選んだ製品が廃れる」というデメリットが、「1社のベンダーに縛られない」の裏には「組み合わせの制約で更改しにくい」というデメリットが存在した。
…
　メリットを追い続けてとにかく作り続けた結果、振り返ればオープンシステムはレガシーとなって企業を苦しめている。しかし、開発コストとスピードを考えるとメインフレーム時代には戻るのは現実的ではない。

今そこにある「オープンレガシー」 – 記者の眼：ITpro

同記事は、「オープンレガシーを救う七つの鍵」をこの様に挙げています。

1. 運用を立て直す (ISMS、ITILを導入する等)

2. 保守切れソフトを更改する

3. 標準化で範囲を狭める

4. 技術マップを持つ

5. 陳腐化させない努力を続ける

6. 仮想化は一時避難所と考える

7. 所有か利用か、スタンスを明確にする

この中で出来ていないとすれば最優先すべきは、「3. 標準化で範囲を狭める」でしょう。

このご時勢ですしIT投資は抑制気味でしょうから、オープンレガシーがどんどん増えていく状態ではないかもしれませんが、ハードウェアやミドルウェアのリース契約更新、耐用年数、保守期限など、ハードウェアやOSやミドルウェアのマイグレーションは定期的にやってくるでしょう。

これ以上増やさない為にも、情報システム、特にハードウェア、OS、ミドルウェア、インターコネクト（ネットワーク）などのインフラストラクチャ部分の「社内標準化」と、情報システム部門による稟議フローへの積極的介入が必要です。

何より、最適化するチャンスでもあります。
モノによっては、SaaSに移行した方がええやん、と言うモノも結構あるでしょう。
特にコモディティ化が顕著なモノは沢山あるでしょう。
例えばDNS、メールサーバ、勤怠管理、グループウェア、等など。

運用系の人は、世の中の技術トレンドをよくウォッチして、積極的に経営層に具申していかなければいけません。
そのためには、まずなんでもオンプレミスでやりたとか言うこだわりは捨てましょう。
あと、レイヤの違う人と話をするスキル、プレゼンテーションをするスキルを身につけないといけません。
最初はなかなか判って貰えないでしょうけど、場数も必要でしょう。
相手に理解してもらうには、辛抱強く訴え続ける事も必要かもしれません。頑張りましょう。

それにしても、どうも「システム運用」系の人々は地位が低い事が多い。

アプリケーションを作る開発系の人々は元より、運用系にも開発系にもどちらにも生息するインフラストラクチャを設計・構築する構築系の人々よりも、一段下の扱いを受ける事が多いです。

原因は色々あるんだけど、運用系は「売り」に直結して無い事で経営層から軽視され、「技術スキルと単価」から相対的に開発系と構築系から下に見られがちです。（あくまで一般論です）

あと、職責上どうしても「安全側」に偏った考え・発言が多いのも運用系の特徴です。それが仕事の一部だから当たり前だけど、嫌われ者役にならざるを得なかったりします。

運用上見つかった不具合を報告するのも仕事なので (ITIL的に言うと RFC、Request For Changeですね)、これまた喜ばれる事は少ないです。開発者の方々、フィードバックをくれる運用系の人にはちゃんと感謝しましょう。

不具合の対処といえば、原因究明できれば治ったも同然なんですが、それが一番難しいんです。
オープン系のシステム、特にオープンソースを多用していると、何が起こっているかを正しく知る事はあまり重要でないというか、難しいんです。それよか怪しい所を交換してみようとか、そういう運用になる事が多いです。Googleのハードウェアに対する考え方がそうですね。

で、原因がアプリケーションだと判明した時、それを直そうと思っても最新のソースコードどこにあるねんとか、ビルド環境ってどうやったけとか、その言語はもう使える人いませんよとか、ドキュメントないですけど直したとして他との影響が無いかどうやってテストすりゃええねんとか、ステージング環境なにそれとか、なんかガッカリな状態だったりする訳ですよ。

結論として「運用対処の方が安くつくよね」と言う事が結構あります。
それはそれで良いんですけど、運用系の人はちょっとだけ傷つきます。
私もその台詞良く言いますごめんなさい。

運用系側の視点に立つと、開発・構築系の方々の担当するフェーズ（企画、設計、開発、実装、試験）での短納期でやっつけちゃったね的な事とか、コスト制約とか、大人の事情とかでの、ムリのしわ寄せ出てるでしょう的なシステムが大半な訳です。ぶっちゃけた話。

何色々ケチってクライアントや上の言いなりになってテキトーにつくってやがんだこのやろうドキュメント出せやとか、本音では思ったりする事もしばしばなんですよ。

それでも運用系の方々の大半は、開発系の方々を技術的にリスペクトしているんです。自分には出来ない事が出来るから。開発系が良いモノを作ってくれた時なんか、我が事の様に喜ぶもんです。

どうです。愛おしい気持ちにさえなってきませんか。

逆に開発系の方々は運用系の仕事が出来るか？と言えば、オペレーションはある程度は出来ちゃうんです。良くも悪くもドキュメンテーションが運用管理の基本だから。

開発系の方々は、なんとか頑張って研修制度とかを設けて3ヶ月位やってみたらえーんですよ。マジで。運用フェーズの経験が無い開発者の方は特に。

なぜなら、運用フェーズがイメージ出来ない人には保守性の高い成果物なんて作れないからです。さもなくば座禅組んでTCOについて72時間位考えて見てください。

Twitterでは大量のサーバを運用しており、それらのサーバに対してのアップデートは素早く行わなければならい。しかしGitサーバに対するアクセスによってデプロイを行うことには非常に問題があった。

そこでBitTorrentを使ってデプロイする「Murder」というツールを開発をした。Murderは、BitTorrentを包含して内部ネットワーク用にオプティマイズしたもの。これまで約900秒かかっていたデプロイの時間が約12秒になり、75倍も速くなった。

なぜBitTorrentをベースに選んだかといえば、多くのライブラリがあることが理由の1つだ。
…
Murderはオープンソースで作られており、基本的にはPythonのスクリプトとCapistranoスクリプトでできている。
TwitterがBitTorrentで高速にデプロイしている仕組みについて － Publickey

このLarry Gadea氏と言う人も頭が柔らかい人ですね。

優れた技術力を持ちながら、かつ既に有るものは最大限利用すると言うマインドのある開発者には、なかなかお目にかかれません。

加えて、比較的ネガティブなイメージが強いBitTorrentを利用しよう言う自由な発想と、それを許容する企業風土が無いと、こういうシステムは具現化しないんでしょうね。

請負開発がメインの日本のSIerとかでは絶対に生まれないモノだと思いました。

逆に、こういった大規模システム運用技術は、ネットワークゲームとかを手がける企業こそ得意分野なんじゃ無いでしょうかね。

うーん。ネットワークゲーム屋と大規模WEBアプリーケーション屋。なんか似ているぞ。

「いままで企業内のコラボレーションといえば、メッセージング、スケジュール管理、電子掲示板、ドキュメント共有といった機能を備えるグループウェアが主役でした。しかし、いまそれが大きく変わろうとしています。
いま開発中の企業内コラボレーションツールの多くが、TwitterやFacebookのように、つぶやきとタイムラインを中心としたマイクロブログ的なユーザーインターフェイスを備えているのです。画面を並べてみましょう。」

企業内コラボレーションのTwitter化 － Publickey

以下の企業向けコラボレーションツール（サービス）の画面が比較されています。

・セールスフォース・ドットコムの「Salesforce Chatter」（現在β公開中）

・IBMが開発中と伝えられている「Project Vulcan」

・マイクロソフトの「Office Talk」（開発中）

・シスコの「Cisco Quad」

・SAPが開発中の「SalesOnDemand」

企業向けSNSはイマイチ浸透しなかったけど、今度はソーシャル機能単体じゃ無くて、ビジネス支援のアプリケーション又はサービス群と協調するTwitterライクなミニブログ、という位置づけである事が大きな違いでしょうか。

企業向けSNSがイマイチ浸透していない理由の一つに、既存システムとの親和性があると思います。既にOpenIDでSSO（シングルサインオン）を実現してます、とかいう先進的な企業は、あまり聞いたことがありません。

最も企業内で普及している認証サービスは、多分Microsoft社のActive Directoryでしょう。
ただActive DirectoryはWEBサービスとの連携という意味ではイマイチです。

殆どの企業は、グループウェアを導入していたらそのアカウントは別に持っているんじゃないでしょうか。そこに仮に後付けでSNSをポンと立てても、アカウントを覚える数が増えるので面倒くさくなって使わなくなってしまうんじゃ無いでしょうか。

そういう意味では、Salesforce.comのChatterにはちょっと期待しています。