Developers [Social Enterprise] Summit 2012

日時:2012/07/27
場所:東京コンファレンスセンター品川
URLDevelopers [Social Enterprise] Summit 2012

B-3 社内ソーシャルメディア開発トライ&エラー おれたちの4tate(株式会社インターネットイニシアティブ 原島 法子 氏 / 岩永 義弘 氏)

開発の契機

会社を合併し、人員増加
→使っているツールなどが合わず水と油のように

そこで、社内コミュニケーションツールの開発指令が下る

プロジェクトゴール

  • 組織を横断
  • スタッフがコラボレーションできる
  • 社内コミュニケーション基盤で
  • イノベーションを起こす

しかし、いままでコミュニケーションツールは流行らなかった。

  • システム自体の問題
  • 心理の問題

そこで、システムを提供すると同時に実例・実績も提供することにした。
→開発チームがコラボしてイノベーションを起こすことにした

開発チーム

4人チーム(2人+各人の上司)
生きた事例となるように

やるからには効率良く

  1. ファシリテーション
  2. アジャイル
  3. UX

1.ファシリテーション

仕様を詰めたいが時間が足りない

ミーティングでファシリテーションを採用

課題の共有
ふせんを書いた 1時間
課題の分類
みんなで話し、付箋を分類 1時間
課題から機能を抽出
課題を解決する機能をイメージしてもらい、詰めた 2時間
機能の優先度をつける
縦軸に重要度を3段階・横軸に難易度を3段階の9分割して仕分け 2時間

実質6時間であっさり決まった。この過程はまさにプロジェクトのゴールでやろうとしたこと

「これをシステム化したらいいのでは」

2.アジャイル

しかし問題発生

チームは2人

  • 経験がまるで違う
  • スキルは未知数

⇒少し進めては調整してみよう

お試し期間で3週間。実質38時間でどれくらいできるか測った

その後3ヶ月かけて本格開発

本格開発ではお試し期間のふりかえりから以下を実践

  • 開発する際には一緒に作業
  • とにかく連絡しあう
  • やるやらないをきっちり分ける

リミットから60日を残して、必須機能が実装できた。

でもチーム2人での開発はお勧めできない。(多数決がとれないから)

3.UX

50人でアルファリリース
→最終的に使い続けた人は1人

期間中にもらったフィードバックを取り入れるとアクティブユーザは増えるのか
→ユーザ数は増えない

そもそもどうしてこうなった?

  • ふせん方式は馴染みのないコンセプトだった
  • 機能の見せ方(あったら便利だが邪魔。作った機能が使われない)

つまりUX視点が欠けていた

そこで、UXのプロの力を借りて、UX強化

フロー
a.いつ、どのように使われるかを調査
コミュニケーションの手段と内容・人数
そのコミュニケーションがどうなったら嬉しいか

b.ペーパープロトタイプテスト

c.実システムで使用感テスト

結果、UX改善でアクティブが30人に

このプロジェクトで得られたもの

  • これらの実績が注目された(勉強会で聞く方から話す方へ)
  • 同じ志の仲間に出会えた
  • システムを面白いと言ってもらえた

B-4 グリーを支えるソーシャルコーディングのすべて(グリー株式会社 大場 光一郎 氏)

greeの開発の課題

  • 急激な増員
    • 2010年から毎月50人増えた計算
    • 1人あたりskypeのチャットルームが200個とか、1チャットルームの最大人数を上回るように
  • 業種の増加
  • 国際化
    • 世界に9拠点

周辺の動向

バージョン管理がSubversionからgitへ

GitHubの登場。forkとpull request。
これらにより従来はコミッターしかコードを修正できなかったが、誰もがプロジェクトをforkでき、変更を還元できる

greeの開発

Subversion→Gitosis

gitは分散repoによって複数人開発をより良くしたが、プロジェクトを超えて開発するための機能が足りない。

Gitosis->GitHub

github導入の目的
  • OSS開発で良いソされている手動の導入
  • プロジェクト間のコラボレーション
  • 埋もれているプログラムの発掘
  • 国際化対応
導入効果
  • Gitosisは管理者が必要でリポジトリ作成の申請が必要だったが、GitHubは各人が好きなようにリポジトリ作成可能になった
  • 誰が何を開発しているのか(メンテナやチームメンバーがわかる)
  • 手元で書き捨てるようなコードも共有できる(Gist
  • メンテされないプログラムも使いたい人が修正して使い続けられる
    →プログラムの寿命が伸びる
現在の課題

業種を超えてのGitHubの使い方

GigHub導入の壁

ソースコードを外に置くということ

GitHub Enterprise – Install GitHub on Your Servers

githubのオンプレミス版
自分たちで運用する

Q&A

pull requestの使用頻度は

プロジェクトによるが、ワークフローで取り入れているところもある

pull requestのマージ方法は

メンテナは置かずチームでレビューする

ツールを作っているところもある

Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineers’ Blog

GitHub Enterpriseでの成果物はgithub.comので公開することは?

greeというOrganization名でunityプラグインなどを公開中 → gree · GitHub

yumdownloader

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中