社内SNS開発 - 事例紹介

チーム開発は【コミュニケーション】がキモ！

第４回エンジニア交流勉強会「gungi」

テーマ：「イントラHacks」

ＴＩＳ株式会社日本ＸＰユーザグループ

倉貫義人

2007/08/29 kuranuki_at_gmail.com

はじめに

私たちの目指す開発とは・・・

ユーザに　　　品質の高いアプリケーションを　　　　　　　　　　　　　　　　　常に提供できる

開発者たちが　　　　プログラミングを中心に　　　　　　　　　　　　　　　　楽しく開発できる

＆

品質の高い？常に？

ユーザに　　　品質の高いアプリケーションを　　　　　　　　　　　　　　　　　常に提供できる

バグが少ない保守しやすい

Web2.0 → Software as a Service１度リリースしておしまい、ではない

プログラミング？楽しく？

開発者たちが　　　　プログラミングを中心に　　　　　　　　　　　　　　　　楽しく開発できる

エンジニアの本懐動くソフトウェアが重要

作業がクリエイティブであることプロジェクトを通じて成長できること

しかも・・・

ユーザに　　　品質の高いアプリケーションを　　　　　　　　　　　　　　　　　常に提供できる

開発者たちが　　　　プログラミングを中心に　　　　　　　　　　　　　　　　楽しく開発できる

チームで開発

そのためには

コミュニケーション重要

なぜ？

ソフトウェアはコミュニケーションで

できているから

コミュニケーションは多ければ多いほど

良い

・・・わけではない

無駄の無い効率的な

コミュニケーション

ただし

共有したいのは「情報」

だけ・・・ではない

思いや感情、チームの目標、考え方、理念

全部ひっくるめて共有したい

コミュニケーション重要

どうやってコミュニケーション

していくか重要

ということで・・・

今日ご紹介するのは、ソフトウェア・サービス開発時の

コミュニケーションについて

どのように実践してきたか、という・・・

私たちの事例です。

事例

• 社内ＳＮＳの開発・運用

• SNSの特徴– 企業ユースに特化

• 全文検索機能• 社員ブックマーク機能• イベント管理機能• 質問回答機能 ….etc

• 開発・運用の特徴– ゼロからスクラッチで開発（当初２人）

– 開発者自身が、業務運用・システム運用を担当– ユーザニーズに応じた機能改修と定期的なリリース

• 開発のゴールは、システムの完成ではないため

社内SNS導入の経緯

SNS

経営からのミッション・技術情報の共有による業務効率化・社内の有識者の有効活用

現場技術者の思い・部門を超えたコミュニケーションの実現・個人で情報を発信できる場の存在

外部環境の変化・W eb2.0の流行の兆し（05年当時）

・CGMによるデータ生成の仕組み

ツールの選択・個人ごとに書き込みができる（ブログ）・利用者のプロフィールが見える

運用状況

利用者数： 約1593名総記事数： 約13213件アクティブユーザ： 約700名　（10日間以内にアクセスしたことがある人）

2005年12月15日：運用開始利用者は口コミにより順次拡大

(2007/8/28)

ミドルウェア構成図

FastCGIDevelopment Kit

Subversion

MySQL

Google Search Appliance

<Client/ブラウザ>

Lighttpd

mod_fastcgi

Webサーバ

RubyGems

Railsruby-fcgi ruby-ldap

Ruby

mysql-ruby

Apache2.2

Reverse Proxy / Load Balancer

mod_proxy

mod_proxy_balancer

mod_ssl

SWIG

Nagios

MRTG

監視ツール

全社統合メールサーバ

全社ドメインコントローラ

Proxyサーバ

Ruby on Rails

OpenSSL

Webアプリケーション層

Webサーバ層

データベース層

社内連携システム

主要採用技術

Ruby on Rails

Railsといえば・・・

設定より規約convention over configuration

重要なポイント

チームにおける約束事（規約）は

コミュニケーションにとても有効

開発体制

倉貫（サービスマネージャ＋プログラマ）

•　プログラマ（設計＆プログラミング）・・・全工程を担当•　開発・システム運用・サイト運営・・・全業務を担当

アプリケーション インフラ

ＯＪＴ

コミュニケーションと体制

参加する人数は少なければ少ないほど

コミュニケーションのロスが少ない

コミュニケーションと工程

作業の工程は少なければ少ないほど

コミュニケーションのロスが少ない

会議

• 定例–朝会（スタンドアップＭＴＧ）　・・・毎朝１５分–週計画＆振り返り　・・・毎週１．５時間

• あとは必要に応じて個別実施

無駄な会議はしない参加者は必要な人だけ

ふりかえり

• 週に１度実施

• Keep / Problem / Tryで共有– よかったこと / 問題点 / 次にやってみること

ふりかえりをすることで

個人の持つよかったノウハウや抱えている問題が

チームのものとなっていく

ファシリテーターがいると良い

• 会議をスムーズに進行• 参加者の会議への参加を促す

マネージャの負荷軽減

チームの潤滑油

投資効果の評価が難しい

開発環境

開発者A（自前PC利用）

　　　D ebian （Linux）

X en

・・・・・・・（仮想的に複数存在する）

開発者ごとの仮想OS

D ebian

Ruby MySQ L

Rails

MyA pp Emacs

D ebian （Linux）

Subversion

redM ine

W indows

putty

W indows

D ebian

Ruby MySQ L

Rails

MyApp Emacs

VMW are Player putty

開発者B（シンクライアント利用）

IE / FF IE / FF

ソースコードのアップデート・コミット

ソースコードのアップデート・コミット

ターミナルでログイン

ブラウザで動作確認

開発用サーバリポジトリサーバ

連携

ソースコードの共有

• 個人ごとにソースコードを管理しない• 全員がソースコードの変更点を知れるように

プログラム・ライブラリの前提を共有できる

リリースまでの情報共有を減らせる

and を活用svkSubversion

開発環境の共有

• 本番環境と開発環境をそろえる• プログラマ同士の開発環境をそろえる

問題発生時の前提を共有できる

新しいプログラマーとも前提を共有できる

X enVMW are Player or を活用

具体的に使っている環境

• VMWarePlayer 2.0– Debian– Emacs << rails.el + psvn.el …– screen + zsh– Ruby on Rails– MySQL

• putty

タスク・不具合の共有

• すべての作業を予定と記録として残す• いつでも進捗状況を誰でも把握できるように

進捗の打ち合わせ時間を短くできる

誰が関係者かの前提を共有できる

or を活用TracredMine

redMineて？

• Tracに似たプロジェクト管理ツール– 課題・不具合・タスク管理

– Wiki– Subversionとの連携

• Ruby on Railsで作られている（オープンソース）

• 複数プロジェクトを管理できる• ガントチャートで表示できる

http://gihyo.jp/dev/serial/01/redminehttp://groups.google.com/group/redmine-users-ja

参考ＵＲＬ

その他の情報共有

• RSSリーダー– redMine（かTrac）の出力するタイムラインを取得

– チームで起きたことのすべてをRSSで読める

• SNSのグループ機能– グループの掲示板機能を利用して情報共有– メーリングリストは使わない　→情報の一元管理– 「ドッグフードを食べる」意味もある

• ＳＮＳのブログ機能– 日報がわりのブログを投稿する

開発環境

開発者A（自前PC利用）

　　　D ebian （Linux）

X en

・・・・・・・（仮想的に複数存在する）

開発者ごとの仮想OS

D ebian

Ruby MySQ L

Rails

MyA pp Emacs

D ebian （Linux）

Subversion

redM ine

W indows

putty

W indows

D ebian

Ruby MySQ L

Rails

MyApp Emacs

VMW are Player putty

開発者B（シンクライアント利用）

IE / FF IE / FF

ソースコードのアップデート・コミット

ソースコードのアップデート・コミット

ターミナルでログイン

ブラウザで動作確認

開発用サーバリポジトリサーバ

連携

ツールとコミュニケーション

ツールを使って知識の前提を揃えることで

普段のコミュニケーションの

質が向上する

ペアプログラミング

二人で一緒に開発

ディスプレイを用意すると便利

詳細設計も同時に行う

新人に一人で作業させない（重要でない仕事は無いのだから）

ペアプログラミングとコミュニケーション

• 常時コードレビューを実施している状態• ソースコードを理解している人間をクラスタ

ドキュメントによるコミュニケーションを減らす

引継ぎ・不在時のための情報共有を減らす

コードレビュー＆リファクタリング

「人月の神話」（外科手術チーム）

チーフプログラマと助手

外部設計（仕様）も同時に行う

ツールとコミュニケーション

ドキュメントによるコミュニケーションは

コストパフォーマンスが悪い人で補完人を補完

さいごに

今日お話したことは・・・

• XPと呼ばれる【開発の進め方】の一部です– ＸＰ = eXtreme Programming

今年もXP祭り開催します！

http://www.xpjug.org/http://jucalion.s66.xrea.com/xpjug2/modules/eguide/

XP祭り2007 ～XPブートキャンプだ！～

9月1日(土曜) 10:00開場 10:30開演

於 江戸川区総合文化センターhttp://edogawa-bunkacenter.jp/

JR※ 新小岩駅からバス、または徒歩だと16分です。

　　　参加費 無料！！

• Agile2007レポート by 平鍋健児 • Rubyistドリームチームによるライブアジャイル開発• 事例紹介• 体験トラック• チュートリアル• ライトニングトークス　　　…etc

ありがとうございました

ＴＩＳ株式会社日本ＸＰユーザグループ

倉貫義人

kuranuki_at_gmail.com

それと・・・Railsプログラマ探してます

今日紹介したようなプロジェクトで一緒に仕事してみませんか？