第4回エンジニア交流勉強会「gungi」
                                テーマ:「イントラHacks」




             社内SNS開発 - 事例紹介
             チーム開発は【コ...
はじめに
私たちの目指す開発とは・・・

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

           &
開発者たちが
    プログラミングを中心に
                ...
品質の高い?常に?



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

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


      Web2.0 → Software as a Service
    ...
プログラミング?楽しく?



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

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


      作業がクリエイティブであること
      プロ...
しかも・・・

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


チームで開発
開発者たちが
    プログラミングを中心に
                楽しく開発できる
そのためには
コミュニケーション
    重要
なぜ?
ソフトウェアは
コミュニケーションで
 できているから
コミュニケーションは
多ければ多いほど
    良い
・・・わけではない
無駄の無い
   効率的な
コミュニケーション
ただし
共有したいのは
  「情報」
だけ・・・ではない
思いや感情、
チームの目標、
 考え方、理念
全部ひっくるめて
 共有したい
コミュニケーション
    重要
どうやって
コミュニケーション
  していくか
    重要
ということで・・・

   今日ご紹介するのは、
ソフトウェア・サービス開発時の
コミュニケーションについて
 どのように実践してきたか、
      という・・・
   私たちの事例です。
事例

• 社内SNSの開発・運用

• SNSの特徴
 – 企業ユースに特化
   •   全文検索機能
   •   社員ブックマーク機能
   •   イベント管理機能
   •   質問回答機能       ….etc

• 開発・運用...
社内SNS導入の経緯

経営からのミッション                現場技術者の思い
・技術情報の共有による業務効率化          ・部門を超えたコミュニケーションの実現
・社内の有識者の有効活用              ・個人...
運用状況



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




                                      (2007/8/28)
利用者数:         約1593名
  総...
ミドルウェア構成図
                                                                    Webサーバ層

                        Reverse Pro...
主要採用技術




Ruby on Rails
Railsといえば・・・




設定より規約
  convention over configuration
重要なポイント


 チームにおける
 約束事(規約)は
コミュニケーション
  にとても有効
開発体制
                    倉貫(サービスマネージャ+プログラマ)




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




              OJT

• プログラマ(設計&プログラミン...
コミュニケーションと体制




   参加する人数は
 少なければ少ないほど
コミュニケーションのロスが
     少ない
コミュニケーションと工程




   作業の工程は
 少なければ少ないほど
コミュニケーションのロスが
     少ない
会議

• 定例
 – 朝会(スタンドアップMTG) ・・・毎朝15分
 – 週計画&振り返り ・・・毎週1.5時間
• あとは必要に応じて個別実施




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

• 週に1度実施
• Keep / Problem / Tryで共有
  – よかったこと / 問題点 / 次にやってみること
ふりかえりをすることで




   個人の持つ
 よかったノウハウや
  抱えている問題が
チームのものとなっていく
ファシリテーターがいると良い

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




             マネージャの負荷軽減

              チームの潤滑油

            投資効果の評価が難しい
開発環境
                                                  開発者ごとの仮想OS
                                                        ...
ソースコードの共有

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


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

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



    Subversion        ...
開発環境の共有

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

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

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



  VM W are Player or X en を活用
具体的に使っている環境

• VMWarePlayer 2.0
  – Debian
  – Emacs << rails.el + psvn.el …
  – screen + zsh
  – Ruby on Rails
  – MySQL
...
タスク・不具合の共有

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


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

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



    redM ine        T rac...
redMineて?

  • Tracに似たプロジェクト管理ツール
      – 課題・不具合・タスク管理
      – Wiki
      – Subversionとの連携
  • Ruby on Railsで作られている(オープンソー...
その他の情報共有

• RSSリーダー
 – redMine(かTrac)の出力するタイムラインを取得
 – チームで起きたことのすべてをRSSで読める

• SNSのグループ機能
 – グループの掲示板機能を利用して情報共有
 – メーリング...
開発環境
                                                  開発者ごとの仮想OS
                                                        ...
ツールとコミュニケーション



  ツールを使って
知識の前提を揃えることで
    普段の
 コミュニケーションの
   質が向上する
ペアプログラミング


  二人で一緒に開発

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

 詳細設計も同時に行う




新人に一人で作業させない(重要でない仕事は無いのだから)
ペアプログラミングとコミュニケーション

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


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

引継ぎ・不在時のための情報共有を減らす
コードレビュー&リファクタリング




           「人月の神話」(外科手術チーム)

             チーフプログラマと助手

           外部設計(仕様)も同時に行う
ツールとコミュニケーション



   ドキュメントによる
  コミュニケーションは
コストパフォーマンスが悪い
     人で補完
     人を補完
さいごに
今日お話したことは・・・

• XPと呼ばれる【開発の進め方】の一部です
 – XP = eXtreme Programming
今年もXP祭り開催します!

XP祭り2007 ~XPブートキャンプだ!~
                 9月1日(土曜) 10:00開場 10:30開演
                 於 江戸川区総合文化センター
          ...
ありがとうございました
              それと・・・
        Railsプログラマ探してます
今日紹介したようなプロジェクトで一緒に仕事してみませんか?




                          TIS株式...
Upcoming SlideShare
Loading in...5
×

070829 intra-SNS case-study

3,618

Published on

第4回エンジニア交流勉強会「gungi」資料

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,618
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
265
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "070829 intra-SNS case-study"

  1. 1. 第4回エンジニア交流勉強会「gungi」 テーマ:「イントラHacks」 社内SNS開発 - 事例紹介 チーム開発は【コミュニケーション】がキモ! TIS株式会社 日本XPユーザグループ 倉貫義人 kuranuki_at_gmail.com 2007/08/29
  2. 2. はじめに 私たちの目指す開発とは・・・ ユーザに    品質の高いアプリケーションを                  常に提供できる & 開発者たちが     プログラミングを中心に                 楽しく開発できる
  3. 3. 品質の高い?常に? ユーザに    品質の高いアプリケーションを                  常に提供できる バグが少ない 保守しやすい Web2.0 → Software as a Service 1度リリースしておしまい、ではない
  4. 4. プログラミング?楽しく? 開発者たちが     プログラミングを中心に                 楽しく開発できる エンジニアの本懐 動くソフトウェアが重要 作業がクリエイティブであること プロジェクトを通じて成長できること
  5. 5. しかも・・・ ユーザに    品質の高いアプリケーションを                  常に提供できる チームで開発 開発者たちが     プログラミングを中心に                 楽しく開発できる
  6. 6. そのためには
  7. 7. コミュニケーション 重要
  8. 8. なぜ?
  9. 9. ソフトウェアは コミュニケーションで できているから
  10. 10. コミュニケーションは 多ければ多いほど 良い
  11. 11. ・・・わけではない
  12. 12. 無駄の無い 効率的な コミュニケーション
  13. 13. ただし
  14. 14. 共有したいのは 「情報」 だけ・・・ではない
  15. 15. 思いや感情、 チームの目標、 考え方、理念
  16. 16. 全部ひっくるめて 共有したい
  17. 17. コミュニケーション 重要
  18. 18. どうやって コミュニケーション していくか 重要
  19. 19. ということで・・・ 今日ご紹介するのは、 ソフトウェア・サービス開発時の コミュニケーションについて どのように実践してきたか、 という・・・ 私たちの事例です。
  20. 20. 事例 • 社内SNSの開発・運用 • SNSの特徴 – 企業ユースに特化 • 全文検索機能 • 社員ブックマーク機能 • イベント管理機能 • 質問回答機能 ….etc • 開発・運用の特徴 – ゼロからスクラッチで開発(当初2人) – 開発者自身が、業務運用・システム運用を担当 – ユーザニーズに応じた機能改修と定期的なリリース • 開発のゴールは、システムの完成ではないため
  21. 21. 社内SNS導入の経緯 経営からのミッション 現場技術者の思い ・技術情報の共有による業務効率化 ・部門を超えたコミュニケーションの実現 ・社内の有識者の有効活用 ・個人で情報を発信できる場の存在 SNS 外部環境の変化 ツールの選択 ・W eb2.0の流行の兆し(05年当時) ・個人ごとに書き込みができる(ブログ) ・利用者のプロフィールが見える ・CG Mによるデータ生成の仕組み
  22. 22. 運用状況 2005年12月15日:運用開始 利用者は口コミにより順次拡大 (2007/8/28) 利用者数: 約1593名 総記事数: 約13213件 アクティブユーザ: 約700名 (10日間以内にアクセスしたことがある人)
  23. 23. ミドルウェア構成図 Webサーバ層 Reverse Proxy / Load Balancer mod_ssl <Client/ブラウザ> OpenSSL mod_proxy_ balancer mod_proxy Webサーバ 社内連携システム Lighttpd Apache2.2 監視ツール mod_fastcgi MRTG 全社ドメイン Nagios Webアプリケーション層 コントローラ FastCGI Development Kit データベース層 Ruby on Rails MySQL 全社統合 mysql- ruby-fcgi ruby- Rails メールサーバ ruby ldap RubyGems Google Search Appliance Ruby Proxyサーバ Subversion SWIG
  24. 24. 主要採用技術 Ruby on Rails
  25. 25. Railsといえば・・・ 設定より規約 convention over configuration
  26. 26. 重要なポイント チームにおける 約束事(規約)は コミュニケーション にとても有効
  27. 27. 開発体制 倉貫(サービスマネージャ+プログラマ) アプリケーション インフラ OJT • プログラマ(設計&プログラミング)・・・全工程を担当 • 開発・システム運用・サイト運営・・・全業務を担当
  28. 28. コミュニケーションと体制 参加する人数は 少なければ少ないほど コミュニケーションのロスが 少ない
  29. 29. コミュニケーションと工程 作業の工程は 少なければ少ないほど コミュニケーションのロスが 少ない
  30. 30. 会議 • 定例 – 朝会(スタンドアップMTG) ・・・毎朝15分 – 週計画&振り返り ・・・毎週1.5時間 • あとは必要に応じて個別実施 無駄な会議はしない 参加者は必要な人だけ
  31. 31. ふりかえり • 週に1度実施 • Keep / Problem / Tryで共有 – よかったこと / 問題点 / 次にやってみること
  32. 32. ふりかえりをすることで 個人の持つ よかったノウハウや 抱えている問題が チームのものとなっていく
  33. 33. ファシリテーターがいると良い • 会議をスムーズに進行 • 参加者の会議への参加を促す マネージャの負荷軽減 チームの潤滑油 投資効果の評価が難しい
  34. 34. 開発環境 開発者ごとの仮想OS 開発用サーバ リポジトリサーバ M yA pp Em acs 連携 ソースコードの redM ine アップデート・コミット Rails ・・・・・・・ Subversion Ruby M ySQ L (仮想的に複数存在する) D ebian (Linux) D ebian X en ソースコードの    D ebian (Linux) アップデート・コミット ブラウザで 動作確認 M yA pp Emacs ターミナルで Rails ログイン Ruby M ySQ L D ebian putty IE / FF V M W are Player putty IE / FF W indows W indows 開発者A 開発者B (シンクライアント利用) (自前PC利用)
  35. 35. ソースコードの共有 • 個人ごとにソースコードを管理しない • 全員がソースコードの変更点を知れるように プログラム・ライブラリの前提を共有できる リリースまでの情報共有を減らせる Subversion svk and を活用
  36. 36. 開発環境の共有 • 本番環境と開発環境をそろえる • プログラマ同士の開発環境をそろえる 問題発生時の前提を共有できる 新しいプログラマーとも前提を共有できる VM W are Player or X en を活用
  37. 37. 具体的に使っている環境 • VMWarePlayer 2.0 – Debian – Emacs << rails.el + psvn.el … – screen + zsh – Ruby on Rails – MySQL • putty
  38. 38. タスク・不具合の共有 • すべての作業を予定と記録として残す • いつでも進捗状況を誰でも把握できるように 進捗の打ち合わせ時間を短くできる 誰が関係者かの前提を共有できる redM ine T rac を活用 or
  39. 39. redMineて? • Tracに似たプロジェクト管理ツール – 課題・不具合・タスク管理 – Wiki – Subversionとの連携 • Ruby on Railsで作られている(オープンソース) • 複数プロジェクトを管理できる • ガントチャートで表示できる 参考URL http://gihyo.jp/dev/serial/01/redmine http://groups.google.com/group/redmine-users-ja
  40. 40. その他の情報共有 • RSSリーダー – redMine(かTrac)の出力するタイムラインを取得 – チームで起きたことのすべてをRSSで読める • SNSのグループ機能 – グループの掲示板機能を利用して情報共有 – メーリングリストは使わない →情報の一元管理 – 「ドッグフードを食べる」意味もある • SNSのブログ機能 – 日報がわりのブログを投稿する
  41. 41. 開発環境 開発者ごとの仮想OS 開発用サーバ リポジトリサーバ M yA pp Em acs 連携 ソースコードの redM ine アップデート・コミット Rails ・・・・・・・ Subversion Ruby M ySQ L (仮想的に複数存在する) D ebian (Linux) D ebian X en ソースコードの    D ebian (Linux) アップデート・コミット ブラウザで 動作確認 M yA pp Emacs ターミナルで Rails ログイン Ruby M ySQ L D ebian putty IE / FF V M W are Player putty IE / FF W indows W indows 開発者A 開発者B (シンクライアント利用) (自前PC利用)
  42. 42. ツールとコミュニケーション ツールを使って 知識の前提を揃えることで 普段の コミュニケーションの 質が向上する
  43. 43. ペアプログラミング 二人で一緒に開発 ディスプレイを用意すると便利 詳細設計も同時に行う 新人に一人で作業させない(重要でない仕事は無いのだから)
  44. 44. ペアプログラミングとコミュニケーション • 常時コードレビューを実施している状態 • ソースコードを理解している人間をクラスタ ドキュメントによるコミュニケーションを減らす 引継ぎ・不在時のための情報共有を減らす
  45. 45. コードレビュー&リファクタリング 「人月の神話」(外科手術チーム) チーフプログラマと助手 外部設計(仕様)も同時に行う
  46. 46. ツールとコミュニケーション ドキュメントによる コミュニケーションは コストパフォーマンスが悪い 人で補完 人を補完
  47. 47. さいごに
  48. 48. 今日お話したことは・・・ • XPと呼ばれる【開発の進め方】の一部です – XP = eXtreme Programming
  49. 49. 今年もXP祭り開催します! XP祭り2007 ~XPブートキャンプだ!~ 9月1日(土曜) 10:00開場 10:30開演 於 江戸川区総合文化センター http://edogawa-bunkacenter.jp/ ※JR新小岩駅からバス、または徒歩だと16分です。 無料!!    参加費 • Agile2007レポート by 平鍋健児 • Rubyistドリームチームによるライブアジャイル開発 • 事例紹介 • 体験トラック • チュートリアル • ライトニングトークス   …etc http://www.xpjug.org/ http://jucalion.s66.xrea.com/xpjug2/modules/eguide/
  50. 50. ありがとうございました それと・・・ Railsプログラマ探してます 今日紹介したようなプロジェクトで一緒に仕事してみませんか? TIS株式会社 日本XPユーザグループ 倉貫義人 kuranuki_at_gmail.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×