社長BLOG

会場にはいけなかったが、今回のmixiイベントはUSTREAMとTwitterで体験させてもらった。

Facebookと同じオープン化戦略という印象が一番強かった。

個人的な思いは、

今回mixiオリジナルのイノベーションは何だったのか？

ということ。ソーシャルグラフの開放、APIの提供、他社との提携。
いろいろすてきな発表はあったが、自分の感覚ではイノベーションと言えるものはなかった。

※流行る流行らないという軸とは全く別ね。自分がイノベーションを驚き、感動できるか？という視点。

自分が2004時点の最初のmixiに対して、これらのイノベーションに心底感動した。

・自分と、フレンド、コミュニティが同じレイアウト
・ROMをコンテンツに変えてしまう、魔法のあしあと
・毎週イベント、女性が使っていることを普通に言える出会い系サイト

だった。ここに他意は無い。全て心から素晴らしいと思っている。

今回のイベントで語られていたことは、ほとんどがFacebookのイノベーションであり、Twitterのイノベーションだった。

自分は、あしあとやレイアウトに続くイノベーションを期待していたのだ。

そんなことを考えて自分のブログを探してみたら、4年前にもmixiの変化というブログで、同じようなことを、記事に書いていた。

イノベーションは、自分がOpenPNEで起こす。

もしドラといえば

「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら 」

でも、こんな本も見つけた。

「もしドラえもんの『ひみつ道具』が実現したら　タケコプターで読み解く経済入門 」

もしドラえもんだから、略して「もしドラ」だ。両方とも署名が長い。略したくなる。

※ドラえもんの方の作者がTwitterで話していたので、話に参加したら、作者さん本人から薦められました。
ちなみにこの作者さんの本では「スリッパの法則」も読んでいます。

Twitterで特定のテーマを話すとき、#＋アルファベット形式のハッシュタグを使う。

自分の周りでは、#nhk と入ったつぶやきをよく見かける。

ただしこのハッシュタグにはクセがある。

まず日本語が通らない。#＋アルファベットでなければならないので、かなり使いにくい。

海外ではこのように文章の途中の単語としてハッシュタグが登場するケースがある。

こういう使い方ならかなりスマートだなと思った。

最近はハッシュタグをつけなくても検索にうまく引っかかるので、少なくとも日本語圏では、ハッシュタグよりも普通に書いていって、検索すればいいんじゃないか。

Twitterにはいろいろな側面があるが、その一つとして

ブログとブログリーダー（RSSリーダー）がセットになったサービス

と考えることができる。

ブログも今まさに書いているところだし、RSSリーダーは自分のようなITマニアに取っては、大量の情報を効率的に読むために欠かせない。
しかし便利でありながら、一般ユーザーまで広がったサービスだとは必ずしも言えない。

RSSリーダーの概念が、操作方法が、登録が非常に面倒だったのだ。
Twitterが登場してから考えてみると、なんで今までブログ投稿画面と、RSSリーダーは一緒になってなかったのか？と不思議に思ってしまう。

ブログ投稿画面

RSSリーダー

この二つをバラバラに登録し、利用していたのだ。

Twitterが出てから考えると、この二つの画面はいかにも使いづらい。
複雑だし、殺風景だし、投稿も、管理も面倒だ。こりゃ一般にまで流行るわけがない。
そりゃ、画像や動画を張り付けたり、複雑な文字装飾を行ったり、何百行にも及ぶ文章を書いたり読んだりするためには、それなりの複雑さが必要のなのはわかる。

それだけに、Twitterの潔さと、便利さは特筆すべきだと思う。

Twitterの画面を見てみよう。

ブログ投稿画面とRSSリーダーの機能が一画面に収まっている。自分で投稿したつぶやきは、RSSリーダーのすぐ上に表示されるから、投稿の表示画面も兼ねている。

ユーザーインターフェースとしてよくできているな、とつくづく思う。

OpenPNE3.4から3.6Beta4へのバージョンアップ手順ガイド。

バージョンアップ手順について

バージョンアップの手順は基本的にOpenPNE付属のドキュメントを参考にした。
http://github.com/openpne/OpenPNE3/blob/OpenPNE-3.6beta4/doc/ja/OpenPNE3_Version_Up_Guide.txt

データベースのバックアップ
バージョンアップ前には必ずデータベースのバックアップを取ること。
自分の場合はクラウドサーバを利用しており、OSごとスナップショットを取っている。

※ちなみに今回は、一度メモリーリミットでバージョンアップに失敗しており、スナップショット版に巻き戻した。

php.iniでメモリーリミットを増加

vi /etc/php.ini

今回は256MBにしたら、エラーが発生しなかった。

バージョンアップ途中でのメモリーエラーは、データーベースが中途半端な状態になってしまい、かなり都合が悪い。なるべく余裕を持った設定値にしておきたい。

OpenPNEのダウンロード

リンクアドレスをコピーし、サーバ内でwgetしてダウンロード。

cd /home/admin/OpenPNE
wget http://github.com/openpne/OpenPNE3/zipball/OpenPNE-3.6beta4
unzip openpne-OpenPNE3-OpenPNE-3.6beta4-0-g27edc0f.zip

ファイル名を適切なものにリネームする。

/home/admin/OpenPNE/site.com_3_6

自分はたいていこのようにしている。

設定ファイルの修正

OpenPNE.yml.sample
ProjectConfiguration.class.php.sample

をそれぞれコピーし

OpenPNE.yml
ProjectConfiguration.class.php

を作成する。

cd config/
cp OpenPNE.yml.sample OpenPNE.yml
cp ProjectConfiguration.class.php.sample ProjectConfiguration.class.php

※この時、移動をしてはいけない。sampleファイルとなっているが、OpenPNE側で初期値として利用するので。

Ver3.4のdatabases.ymlをコピー

databases.ymlはVer3.4時代のものをそのまま使う。
旧サーバのファイルを./config/databases.yml としてコピーする。

cd /home/admin/OpenPNE
cp site.com_3_4/config/databases.yml site.com_3_6/config/databases.yml

※旧サーバの設定値を使うということは、旧サーバのデータベースを上書きするということ。絶対にバックアップを取るのを忘れないように！失敗すると取り返しが付かないことになる。

プラグインディレクトリのコピー
Ver3.4時代に使っていた、もしくは追加したプラグインがあるかも知れない。
これらは新しい方にコピーしてあげる必要がある。

cd /home/admin/OpenPNE
cp -aur ./site.com_3_4/plugins/* /home/admin/OpenPNE/site.com_3_6/plugins
cp -aur ./site.com_3_4/plugins/.* /home/admin/OpenPNE/site.com_3_6/plugins

バージョンアップコマンドの実行

./symfony doctrine:build-model
./symfony cc
./symfony openpne:migrate
./symfony plugin:publish-assets

バージョンアップは4つのコマンドを実行することで完了する。
※この途中でエラーが起きたら、データベースを巻き戻してやり直すことをおすすめする。

旧サイト=>新サイトへのシンボリックリンクはりかえ

自分は、プログラムの設置場所とApacheからの参照先を分けている。

Apacheからは常に

/var/www/sns/[ドメイン名]

となるようにhttpd.confの設定を行っている。

したがって今回は

cd /var/www/sns/
rm /var/www/sns/site.com
ln -s /home/admin/OpenPNE/site.com_3.6 site.com

として、旧サイト＝＞新サイトのリンク張替えをおこなった。

動作確認
すべての作業が完了したら、管理画面にログインして、フッター部分のバージョン表記が

となっていればバージョンアップ成功だ。

※真っ白な画面になってしまったら、web/index.phpの

この部分をfales=>trueに変更し、エラー画面を表示させて原因を探って欲しい。
大抵の場合は、バージョンアップがうまく行っていないと思うので、
バージョンアップ前にロールバックし、バージョンアップ作業を繰り返してみてほしい。

手嶋屋とOpenPNEにとっての福音である、クラウドコンピューティング。
あまりにもバズワード化して乱立してきているので、自分の独断と偏見でまとめて見ることにした。

OpenPNE Ver3で極小規模から500万人レベルの大規模までの運用を行うことをテーマに、
評価軸を設け各社のクラウドサービスを比較する。

今回扱うのはクラウドの中でも仮想サーバを提供するクラウド、いわゆる HaaSやIaaSというものを対象にする。EC2が代表的。GoogleAppEngineのようなプラットフォームや、Gmailなどのサービスは範囲外だ。

運用条件

OpenPNE Ver3.6を使う
ユーザー数100名からスタート。
以後ユーザー数やアクセス、データ量の増減に応じて
・ネットワーク回線
・サーバ構成
・サーバスペック
・サーバ台数
これらの柔軟な構成変更に対応
オートスケールに対応
ソフトウエアからのスケールに対応

エントリー

Amazon EC2
Rackspace
Unit Hosting
Niftyクラウド

参考

さくらのVPS
TrueCLOUD

比較表

クラウドの比較表だけにクラウドソーシングで編集中！
http://bit.ly/aJsQ8R

現在のスナップショット※画像をクリックして拡大

※以降追記中

PHP Matsuriに協賛した。

PHP Matsuriは２日間に渡って夜通し開催される開発イベント。

手嶋もエンジニアとして参加予定だ。

モチベーションの高いPHPエンジニアと一緒になって、開発をしていきたい。

おそらくイベントでは、OpenPNE関連のプラグインを書くことになると思う。

まだ申し込みを受け付けているので、ぜひ参加して欲しい。

ネット対応のテレビはこれまでにもたくさん出ている。
アクトビラしかり、パソコン内蔵テレビしかりだ。

今日のニュースでもこのような発表があった。

これがGoogle TVだ！　ソニーが11月発売モデルを世界初披露… : ギズモード・ジャパン
http://bit.ly/aD72no

ただ、このこころみも、自分の予想ではうまく行かない。

それはなぜか？

答えは

「テレビ本体の使用年数と、パソコン、ネット部分の使用年数に差があるから」

これに尽きる。（地デジ化需要で少なくなってはいるかもしないが）テレビは平均で８年程度使用する。
一方でパソコンは長くて５年程度。使用年数に違いがあるものを、組合わせてひとつの製品として売ることは相当難しい。

それでも抱き合わせてひとつの製品としているのは、家電メーカーがどうしてもテレビをテレビとして売りたいからだろう。

消費者としてはテレビを「８年使うモニター」として売ってくれるのが一番だ。
８年使えるモニターを買って、４，５年ごとにパソコンを買い直せばいい。

本当はこんなパラダイムはずっと前から当たり前なのだが、
足を引っ張っているのはふたつ。

・家電のテレビ売りたい根性

と

・メディア向けのWindowsのできの悪さ

だ。Widowsは残念としかいいようがない。一番ひどいのはリモコン。

これ。

一応メディア用に設計されているのだが、対応アプリケーションがほとんど無いのと、一部キーボードやマウスに頼らなければならないので、ソファーでゴロンというわけには行かない。（たまに、キーボードに寄らないといけない）。

それなら、潔く、このような製品にすればよかったのだ。

フルキーボードでタッチパッドも搭載している。

残念なWindows側は、AppleやGoogleががんばってくれる可能性はあるが、使用年数の差はどうにもならない。ネット対応テレビはうまく行かない宿命を背負っているのだ。

「今いろんな組織（メーカー、企業、自治体、メディアなど）がSNSに対して行っていることは、情報組織、情報社会というゴールにたどり着くための試行錯誤なんだ」

ということ。

これは自分がOpenPNEプロジェクトで常に意識している

「OpenPNEが組織そのものになる」

という設計思想に起因している。サミットに参加し、あらためてこの思いを深めた。

EGMサミットは主に大企業の従業員が集まって、社内SNSのあり方について語り合うイベントだ。

ある会社では、福利厚生の道具として業務以外の使い方を奨励し、またある会社では、積極的に業務の中に取り入れようと努力している。

参加者の属性もまちまちで、自主的に参加する社員の一部だけが参加するケースもあれば、全従業員を強制的に参加させるケース（手嶋屋もそう）、社員管理システムとID連携をして自由にログインできるようにしている会社もあった。

そこで自分は「その社内SNSのゴールはなに？」と思った。なんだかどれもゴールがよくわからないのだ。

半年ほど前に地域SNSのイベントに参加した時も、同じような感覚を持った。

地域SNSの場合は、企業のSNSと同じように目的はなにか？誰が入るか？という要素に加え、誰が運営するか？どこまでのメンバーを対象とするか？という新たなパラメータが加わり、さらに複雑になる。

地域SNSのイベントにも、ゴールのヴィジョンが必要なんじゃないか？と、当時思っていた。

この二つのイベントに参加して、特にEGMサミットに参加して、改めて確認したのが

「今いろんな組織（メーカー、企業、自治体、メディアなど）がSNSに対して行っていることは、情報組織、情報社会というゴールにたどり着くための試行錯誤なんだ」

このこと。

組織が取り組むSNSのゴールは、情報ネットワーク上に組織そのものをつくること。これ以外のゴールは無いと信じている。

今はまだ、参加者の発想がリアルに寄り過ぎているのではないかな。オフィスはあるよな、工場はあるよな、仕事は机の上でやるもんだよな。という感覚を持った上で議論をしている。すなわち、軸足をリアル側においた上で議論や改善を進めているんだ。

一度これらの概念を取り去り、会社がSNSそのもので、会社の組織活動はすべてSNS上で行われると、考えてみて欲しい。バーチャル側に軸足をおいて、そちら側から社内SNSのあり方や設計を考える。

自分はOpenPNEの設計者の一人として、そのゴールは「OpenPNEが組織そのものになる」であると確信している。

好き嫌いにかかわらず、組織のバーチャル化は進み、ネットワーク上で組織の活動をするようになる。合理的に考えてそこから逃げるよりも積極的に取り組んでいったほうが得が多いと思う。

でも、どうせなるなら、人間らしく楽しいものを作りたいとも思う。その設計にしても、がさつなグローバルスタンダードではなく、日本の組織の繊細な部分も表現できる仕組みをつくりたい。そんな気持ちでOpenPNEを設計している。

自分のコンセプト「OpenPNEが組織そのものになる」は間違ってないと感じた。

ネイティブIDとゲストIDの話をした。
IDを発行するのは利用者にとっても運営者にとっても負担の大きい業務だ。できればやりたくない。

であれば、すでに組織によって作成、管理されているID体系をそのままネイティブIDとして使えればいいという考えにたどり着く。

そこで登場するがID連携。

大抵の企業は社員番号とメールアドレスの@以前の部分を管理している。
これらすでに発行されたIDを、OpenPNEにおける基本のID（ネイティブID）として、使うことができれば、組織を構成するSNSにとって非常に使い勝手がいい。

実際の連携はLDAPやActiveDirectoryなどで構成される社員のマスタとOpenPNEをつなぐことで実現する。OpenPNEの認証プラグインを拡張することで対応可能だ。現在のOpenPNE3では、認証プラグインを使うことでOpenID や GoogleAppsを外部の認証機構として利用することができる。

社員名簿とOpenPNEアカウント
学籍番号とOpenPNEアカウント
ゲームアカウントとOpenPNEアカウント

これらを連携すると便利。

ゆくゆくは住基ネットや免許証、今度できあがるらしい国民IDともOpenPNEを連携させていきたい。

「ネイティブIDはマスタ連携でつくる」が、今日のポイントだ。