Webサービスやスマートフォンアプリでは先行者有利と言われます。多くの場合、先行者が最大のシェアを一気に獲得し、二番手以降が残りをシェアするといった形になります。しかし、時には後から参入したサービスが大手になることもあります。
例えばYouTubeは決して最初にリリースした動画共有サイトではありませんでしたし、Facebookも同様です。彼らの戦略を学ぶと、二番手以降で市場参入したサービスの生き残り方法が見えてくるでしょう。
セグメンテーションする
Facebookは元々学生向けのSNSでした。そしてFriendsterやMyspaceなどは特に利用者を区別しないSNSでしたが、成長する中で頭打ちになり、次第にFacebookが追いつき、追い越していきました。
同様にLinkedInのようにビジネス特化型のSNSもあります。特化することでビジネスモデルの差別化が生まれ、ユーザにも受け入れられやすくなります。十分な市場性さえあれば、汎用的である必要はありません。
　

人は元来ずぼらなもので、楽な方に流れる傾向があります。そのためプロジェクトの積み残されたタスクがちゃんとこなせなかったり、やらなければならない仕事を後回しにしてしまったりします。しかしそのままで良いわけはありません。
そこで今回はタスクがちゃんとこなせる人になるための方法を紹介します。これは性格の問題ではなくテクニックです。
計測可能な範囲まで砕く
タスクは雰囲気ではなく、明確な範囲まで絞り込んで登録しましょう。必要であればサブタスクにしていきましょう。「提案書を書く」がタスクではなく、そのために必要な材料を集めることや上司に確認を求めると言ったことまですべてタスクに落とし込まなければなりません。
プロジェクトで進捗が40%などと報告するのではなく、あるタスクにおけるサブタスク4/10が終わったと報告するべきです。定性的な評価はせず、定量的に管理しましょう。雰囲気で話をしていると大抵抜けがあったり、思わぬトラブルで遅延します。
　

先日から何回かに渡って書いているブロックWebですが、企業によってはすでにそのような施策を行っているかと思います。一つの技術について突き詰めてサービスを提供する中で、次にどういった施策を打っていくべきか悩むことがあるでしょう。
そんな時にダメな施策を打つと、本体のサービスすら危うくなるケースがあります。今回はそんな実例を紹介します。
水平展開でも垂直統合でもない第3の選択肢とは？
これまで多くのサービスが成長する中で水平展開または垂直統合を図ってきました。水平展開の例としては、自分たちの強みを活かし、別な分野に打って出るケースがあります。GoogleがWeb検索からGmailを提供するのはそんな例です。検索という軸はぶれずに提供しています。
垂直統合としては自分たちのサービス上に作られているサービスを取り込んでいくパターンです。Amazonで言えばマーケットプレイスは垂直統合と言えるでしょう。AppleなどもiOS上でこのようなやり方を展開しており、その結果としてAppleに市場を食われてしまったサービスも数多く存在します。
　

日々の仕事に追われていると、ついつい打算的になってしまって、目の前の仕事を期日までに片付けるのに必死に（または適当に力を抜きつつ）行うようになってしまいます。タスクを片付けることが最優先されるので、そこにかかったコストが無視されます。
そういった仕事の仕方はよくありません。朝、昼と適当に過ごし、夕方から本気を出すと言った働き方になってしまいます。もっと能率を意識した仕事の方法に取り組みましょう。
能率とは？
能率は仕事を時間で割った物です。同じ仕事であっても短い時間で仕上げた方が能率が高いということになります。一つのタスクを片付けるにしても、なるべく短い時間で片付けていった方が能率が高いということです。
この単位時間での作業量を意識して仕事に取り組みましょう。
　

これまで何回かに分けて紹介しているブロックWebについて、今回はベンダー側の立場で考えてみたいと思います。現在、一つのベンダーですべての機能を満たすのは不可能で、複数のツールを組み合わせて一つの価値を提供します。そうした一部品になる方法について紹介します。
Web API/WebHooksによる連携
サービス同士の連携を行う際の肝になるのがWeb APIです。今新しいサービスを立ち上げるならばWeb APIを提供しない手はまずないでしょう。デファクトスタンダードとしてはRESTful、フォーマットはJSONで行われます。
また、もう一つキーになるのがWebHooksです。Web APIは基本的にプル型で、相手からのリクエストを待っています。しかし、Web API同士を連携させる場合にお互い待ちの状態では一向に通信がはじまりません。そこでデータを受け取った側が連携するサービスに対してデータをポストする必要があります。これがWebHooksです。
WebHooksはポストされる側がURLを登録します。そしてシステム側に何らかのアクションがあったタイミングでURLを呼び出します。PubSubに近いですが、ブロードキャストではなく特定のURLをコールすること、PubSubのように常時接続する必要がないのがメリットです。
有名なところとしてはSlackやGitHubが挙げられるでしょう。Slackのメッセージを別なシステムへ投稿したり、GitHubにコミットするとCIサーバに連絡がいくといった使い方がよくあります。
　

前回紹介したブロックWeb（筆者の造語）を掘り下げて紹介します。今回はブロックWebを使って、自社や個人のサービスを素早く構築していくために必要な技術要素を紹介します。
部品はそこら中にある
現在、Web APIやマイクロサービス、BaaSと呼ばれるサービスなど、あらゆるコンポーネントが用意されてきています。自社で一から開発する必要性があるのかと考えてしまうくらいです。現状ではもはや車輪の再発明ではなく、すでに優れた車が存在する中で木製の輪を作り始めるようなもので、すでにあるものの方が圧倒的に品質も価格も優れているような状況です。
日本ではSIerと呼ばれる企業が多数存在します。彼らはすでにある素材を組み合わせて（インテグレートして）システムを構築しますが、それでもまだ開発する工数は大きいように感じます。現代ではもっとデベロップレスな手法が求められるようになっています。
　

2014年01月の時に今後のITで大切な·BLOCKという考え方(1)というプレミアム向けの記事を書いているのですが、そこから3年（！）でさらに傾向が進んでいるのではないかと思っています。多くの技術が生み出されている一方、廃れていくものも多く（その中には生まれてトレンドになってすぐに忘れ去られていったものを含めて）、単にトレンドを追いかけるだけでは意味がないと思わされます。
そうした中では大きな潮流を掴むことが大事になります。今回はその一端を担うであろう、ブロックWeb（筆者の造語）という考え方を紹介します。
ブロックWebでは情報が「小さく」繋がっていく
インターネットではあらゆる情報が繋がっていくと言われてきました。その大きな要因はGoogleに代表されるWeb検索でしょう。調べるという能動的な行動は必要なものの、Googleを起点としてオンライン上で「公開」されている情報が繋がっていきます。ソーシャルがもてはやされるようになってからは、クローラーではなく人の手によって情報が繋がるようになっていますが、大きな違いはありません。フィルタがGoogleなのか、友人関係なのかと言った違いでしょう。
ブロックWebでは情報を使いたいと考える人（開発者など）が能動的に他社の情報を取得してつなぎ合わせて一つのコンテンツとしていきます。個々の繋がりは決して大きなものではなく、ごく小さな塊同士がつながって大きなコンテンツに仕上がっていきます。情報をつなぎ合わせるのはクローラーでも人でもなく、システムになります。
次にブロックWebを構成する技術要素について紹介します。