社長BLOG

全開発プロセスの公開を目指す。

規範
・手嶋屋の中だけにとどまっている情報が無いようにする
・一時的に留める情報はセキュリティ、脆弱性関連のみとする
・開発プロセスや意思決定プロセスがオープンであるようにする

以前セッションを聞いた、TheApacheWayを規範としている。

公開の手法としては、日々開発日記としてこのブログに記載する。
開発に関わる柏木、木村の二人もこのスタイルで進めてもらうことにする。

プロジェクトの準備

・redmine.openpne.jp上にHOUOUサブプロジェクトを作成、タスクはここにまとめる
・OpenPNE本線からHOUOUで一旦Forkする。木村のレポジトリへ
・手嶋、柏木をコラボレーターとして追加
・OpenPNE本線にコミットできる作法が身につくまでは、フォークしたHOUOUで開発する

・TimeLinePluginの先行
コアの仕様策定は研究に時間がかかるので、先にキラープラグイン（ゴルゴンハニー）のTimeLinePluginをつくる。
ここでの研究により、スマートフォンの対応や、AJAX系の共通APIを整備する。うまく行ったらHOUOUに取り込む。

柏木レポジトリで実行中。
https://github.com/kashiwasan/opTimelinePlugin

HOUOUのキラープラグインとして開発中だが、3.6でも動作するように設計している。
3.6のユーザーに対して、HOUOUの未来をイメージしてもらうためのプラグインに発展させたい。

プロジェクト運営のやりくり。
安定版の進行と開発版の進行の予算割合を６０：４０ぐらいで運営する。安定版の運用体制も本バージョンに限り、かなり絞り込む必要がある。

最初の仕事
最小OpenPNEでの稼働
・プラグインを全くロードしないOpenPNE3.6をつくる。
・HOUOU+TimelinePluginで日常的に利用する。
・不具合の列挙

ここからスタートだ。

このような開発方式にし、どんなに遅れてもミニマムサクセスまでは確実に完了できるようにする。
キラープラグインはHOUOUと深く連携するが、独立して進行する。

ゼロからつくるキラープラグインの設計は、HOUOUにもうまく役立てられると思う。

HOUOUは少ないリソースで開発をすすめるため、あまり実現性の無い高い目標は設定しない。しかしながらあまり進歩しないのも魅力がないので、３つのサクセスレベルを定める。

※2012/01/31追記 サクセスレベルの進捗表をリンクした。

【サクセスレベルの設定】

「ミニマムサクセス」この項目をクリアしないとリリースを行わないという最低限のレベル。スケジュール内で十分に実現可能な内容で設定する。

「フルサクセス」通常のリリースとして目標とするレベル。4ヶ月の開発期間で順調に到達できる水準を設定する。

「アドバンスドサクセス」チャレンジングな目標値として定める。順調に開発が進むことをみこして、OpenPNEの魅力をさらに高める戦略的な項目を盛り込む。

レベルの分類は次のようなイメージで行った。
ミニマム、フルサクセスまでは、OpenPNEをソーシャルネットワークのためのミドルウエアとして使うための整備を行うということを目標とする。

アドバンスドで、エンドユーザー向けのソーシャル・ネットワークそのものとして、活用できるようにする。
アドバンスドサクセスの決め手は「キラープラグイン」。※コードネームは検討中（ナマハム、ゴルゴンハニーなど、ピザにのせて上手い食材で考える）

開発中は途中で追加の要件や、急な仕様変更が発生したりする可能性もある。そこでミニマムサクセスを死守しながら、フル、アドバンスドを狙っていく開発スタイルにする。

チャレンジングな目標である、アドバンスドサクセスまでを達成したら、安定版のバージョン番号を4.0にする。
ミニマム、フルの場合はリリースバージョンを3.8とする。

サクセスレベル一覧

一覧はGoogleSpreadSheetで共有している。

ミニマムサクセス

◆スピード
スピードアップ+15%

◆シンプル
認証以外の全プラグインの非バンドル化
プレーン状態での完全動作
インタラクティブをスキップするインストールオプション
コア不必要機能の取り外し（1割削除）

◆スマートフォン
【スマートフォン基盤対応】招待メール
【スマートフォン基盤対応】画像投稿メール
【スマートフォン基盤対応】キャリアIDを使わない新規登録、クッキー認証
【スマートフォン新規】コア機能UI対応（一部画面）
【スマートフォン新規】コアプラグインスマートフォンUI（一部画面）

◆ほか
フロント画面のprototype => jQuery化（管理画面は除外）
プラグインのバンドル化＋2個（opDiary opMessageなど）
認証プラグインの見直し、パスワード無しの運用を可能にする

フルサクセス

スピードアップ+15%
エンドユーザー向けキラープラグイン１つ（opTimeLinePlugin）
プラグインのバンドル化＋2個（opCommunityTopic opTimeLinePlugin）
コア不必要機能の取り外し（1割削除）

アドバンスドサクセス

スピードアップ+15%
スクリーンネーム、コミュニティスクリーンネームをコアに
AJAX&アプリを見据えたAPIの見直し
プラグインのバンドル化＋2個 [ ] [ ]
コア不必要機能の取り外し（プラグイン化）

３つの目玉に加えて番外編として、エンドユーザー向けの機能プラグインを作成する。

魅力的なキラープラグイン

Facebook、Twitterライクなタイムライン系の機能をひとつ加える。コアに含まれるActivityDataを利用しつつ、従来のアクティビティ機能を大幅に拡張したタイムラインをプラグインとして提供する。この開発がスムーズに進んだ場合は、本プラグインはOpenPNEに同梱して配布する。
コードネームは「ゴルゴンハニー」とする。

HOUOUはプラグインを取り外したり、不要機能を削減したりしてシンプルになるHOUOUはシンプルになる。
ただ、このままではエンドユーザー向けの魅力的な機能が不足する。
その部分をゴルゴンハニーが補う。

OpenPNEのコアは、ソーシャルメディアをつくるためのプラットフォーム、ミドルウエアとして存在する。
ゴルゴンハニーが、エンドユーザー向けの魅力的な機能を１つ提供するという位置づけにする。

最後の目玉はスマートフォン対応。OpenPNEのコアアーキテクチャとしてスマートフォンに対応し、コアと各プラグインが
スムーズにスマートフォン対応できるような基盤整備を行う。

〜〜OpenPNEをスマートフォン対応に〜〜

・新規登録、招待メール
新規登録や招待において、スマートフォンがうまく対応していない問題を解決する。これまでは@softbank.ne.jp @ezweb.ne.jp ならすべてガラケーなどと判断している部分があったが、例外が多く発生しているので、登録プロセスを改める。

・画像投稿
スマートフォンのブラウザからは画像が投稿できない問題を解決する。携帯メール投稿と同じ方式を採用する。

・認証関連
キャリア識別（UID)を利用せず、PCと同じクッキー方式で正しく認証を行えるようにする。

・コアアーキテクチャのスマートフォン対応
OpenPNEのコア、およびプラグインがスムーズにスマートフォンに対応できるようなコアアーキテクチャを決定する。mobile_frontendのようにsp_frontendを作ったほうが良いのかどうか？キャリア振り分けはどうするのか？PC画面がみたくなった場合の切り替えは？プラグイン側でスマートフォンのUIに対応していない場合の遷移はどのようにするか？
などを検討し、対応する。

・プラグインのスマートフォン対応
バンドルするプラグインも順次スマートフォン対応をする。逆に言えばスマートフォン化が間に合わないプラグインは、バンドルから除外する。

・スマートフォン用のAPI
スマートフォンでの操作を快適にするためのアクションAPIを用意する。
REST=>JSON形式のアクションAPI群。スマートフォンのWEBだけでなく、将来の対応用として、スマートフォンアプリからの通信にも答えられるようにする。

・OpenPNEのプラグイン
・サーバ間通信
・アプリ通信

HOUOUの目玉、二つ目の要素はスピード。
ソフトウエアの動作スピード、ユーザーの体感スピード、インストールや管理のスピード
をイメージしている。

〜〜OpenPNEをもっとスピードアップする〜〜

・最低15％のスピードアップ
スピードアップの目標を15% 30% 45%と段階的に定める。もっと抜本的にスピードは速めたいが、HOUOUシリーズの開発規模が小さいためスピードアップの目標値を最低15%とする。実測値だけでなく、体感レベルでもスピードアップできるように工夫する。

・デフォルトガジェット配置の見直し
これまでのOpenPNEは、デフォルトでたくさんガジェットがセットされていて、動作が重い状態からスタートする。
デフォルトのガジェットレイアウトをシンプルにし、体感速度をスピードアップする。

・AJAXスタイルの投稿、遷移方式の採用
サーバサイドでのテンプレートのレンダリング、HTMLタグの通信、クライアントブラウザでのレンダリングという方式を改める。一部ページの遷移をAJAXスタイルに変更する。AJAXスタイルのレンダリング方式に変更することで、サーバサイドテンプレートのレンダリングコストの削減、JSONの通信による通信量の削減、クライアントブラウザの画面レンダリング速度を向上させる。

なお、このプロセスをスムーズに行うためにユーザー画面で現在利用している、prototype.jsをjQueryに置き換える。

動作スピードの改善を第一とするが、セットアップのスピードも改善することで、トータルで「速いOpenPNE」を目指す。

リリースの目玉要素としてシンプル、スピード、スマートフォンを3要素を掲げる。
そのなかのひとつは「シンプル」だ。

OpenPNEをもっとシンプルにする

・Ver2追従路線の中止
Ver3.6により、Ver2ユーザーのための対応は十分だと判断し、Ver2機能追従対応は終了する。これにより、機能やプラグインの充実、Ver2からのバージョンアップスクリプト作成などの機構を取り外す。

・同梱プラグインの見直し
OpenPNEに同梱（バンドル）されたプラグインの数を見直す。まず、OpenPNEにプラグインが全く搭載されていない状態から開発をスタートし、完全動作を確認。開発スケジュールに間に合うように、人気の高いプラグインをひとつずつ追加していく方式を採る。

バンドルから外れたプラグインは、OpenPNEのプラグインとしては同梱しないが、これまでと同様に配布を続ける。
プラグインのサポートレベルは低下する。

・不要機能の削減
コアに含まれている不要機能も最低1割を目標に削減する。例えば管理画面のバナー機能は、Google DFPなどで完全に置き換えが可能なので削除対象とする。

・インストールプロセスの見直し
コンフィグファイルの設定、インストールコマンドの簡略化など、OpenPNEを今よりももっと簡単、シンプルに感じられるような細かい改善を行う。

現在のOpenPNEは難しさ複雑さ、サイズの大きさが目立つ。OpenPNEをシンプルにすることで、プラットフォーム、ミドルウエアとしてのシンプルさ、良さを目玉として表現できるようにする。

4+1ヶ月

HOUOUの開発スケジュールは、2011/11〜2012/03の4+1ヶ月。

全体的に4ヶ月で完了するスケジュールを立て、スケジュール調整のアイドリング期間を1ヶ月設ける。
1ヶ月間はテストやBeta期間に充てるので、実質の開発期間は3ヶ月間となる。

開発期間が短いので、非常にコンパクトな機能と時間でリリースする。開発チームも少人数で行う。

OpenPNE3.6がBeta期間だけで1年以上かかってしまった反省を踏まえて、HOUOUシリーズはとにかく短期間でリリースする。

OpenPNE3.7開発シリーズの方針について共有する。
第一弾は開発コードネームについて。

開発コードネームは　HOUOU　鳳凰

3.7の開発コードネームはHOUOU　鳳凰にしました。

3.0 い
3.2 ろ
3.4 は
3.6 に
3.7 ほ

ほで始まる鳥として鳳凰です。本当は実在の鳥の写真を撮る予定だったのだけど、
カッコイイコードネームのアイデアを出してくれたので、これを採用。

※いい絵や写真を募集します。

OpenPNE3.7シリーズでは３つのサクセスレベルを定義している。ミニマム、フル、アドバンスド。

フルを満たすことを目標とするが、ミニマムを突破すれば成功としてリリースするよ。という基準である。
さらに、アドバンスドまでバッチリいったら、OpenPNEのバージョンは4.0にする。
アドバンスドはそれぐらいチャレンジングな目標だということ。実現できないかもしれない高い目標は、このカテゴリに入れてしまう。

アドバンスド項目のひとつにAJAX用のAPI整備を項目として追加した。

AJAX用とは書いてあるが、もちろんAJAX以外から呼び出してもいい。
GET POSTで受けてJSONを返す、シンプルなアクション群ということになる。
通常のsymfonyアクションではHTMLで返却することになるが、JSONで返せば多目的で使えるだろう。

呼び出し方法は、３パターン考えている

１．OpenPNEのページ内からJavaScriptで呼び出す（クッキーセッション認証）
２．外部システムからサーバ間通信で（IPアドレス制限、TOKEN認証）
３．iPhone Android、デスクトップアプリから（OAuth認証）

認証の方式はそれぞればらばらだが、APIのフォーマットは全部一緒にする。

ひとつ作るだけで３倍に用途が広がるっていうのは、夢があるよね。
ということで、今回の開発シリーズ、アドバンスド項目として加えた。

OpenPNEを拡張しようとしている人が、symfonyを必ず覚えなければならない現状というのは何とかしたい。
symfonyなんて、Doctrineなんて、深く改造をしたい人以外は知らなくてもいいはずなんだ。

IKEAやニトリで家具を買ってきて家の改造はしたいけど、その基礎であるツーバイフォーの建築基準なんて知りたくは無いよね。っていう感覚かな。