Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (16)
Andere mochten auch
Mehr von Yoshihito Kuranuki
Mehr von Yoshihito Kuranuki (20)
070829 intra-SNS case-study
- 1. 第４回エンジニア交流勉強会「gungi」 テーマ：「イントラHacks」 社内SNS開発 - 事例紹介 チーム開発は【コミュニケーション】がキモ！ ＴＩＳ株式会社 日本ＸＰユーザグループ 倉貫義人 kuranuki_at_gmail.com 2007/08/29
- 2. はじめに 私たちの目指す開発とは・・・ ユーザに 品質の高いアプリケーションを 常に提供できる ＆ 開発者たちが プログラミングを中心に 楽しく開発できる
- 3. 品質の高い？常に？ ユーザに 品質の高いアプリケーションを 常に提供できる バグが少ない 保守しやすい Web2.0 → Software as a Service １度リリースしておしまい、ではない
- 4. プログラミング？楽しく？ 開発者たちが プログラミングを中心に 楽しく開発できる エンジニアの本懐 動くソフトウェアが重要 作業がクリエイティブであること プロジェクトを通じて成長できること
- 6. そのためには
- 7. コミュニケーション 重要
- 8. なぜ？
- 10. コミュニケーションは 多ければ多いほど 良い
- 11. ・・・わけではない
- 12. 無駄の無い 効率的な コミュニケーション
- 13. ただし
- 16. 全部ひっくるめて 共有したい
- 17. コミュニケーション 重要
- 18. どうやって コミュニケーション していくか 重要
- 19. ということで・・・ 今日ご紹介するのは、 ソフトウェア・サービス開発時の コミュニケーションについて どのように実践してきたか、 という・・・ 私たちの事例です。
- 20. 事例 • 社内ＳＮＳの開発・運用 • SNSの特徴 – 企業ユースに特化 • 全文検索機能 • 社員ブックマーク機能 • イベント管理機能 • 質問回答機能 ….etc • 開発・運用の特徴 – ゼロからスクラッチで開発（当初２人） – 開発者自身が、業務運用・システム運用を担当 – ユーザニーズに応じた機能改修と定期的なリリース • 開発のゴールは、システムの完成ではないため
- 21. 社内SNS導入の経緯 経営からのミッション 現場技術者の思い ・技術情報の共有による業務効率化 ・部門を超えたコミュニケーションの実現 ・社内の有識者の有効活用 ・個人で情報を発信できる場の存在 SNS 外部環境の変化 ツールの選択 ・W eb2.0の流行の兆し（05年当時） ・個人ごとに書き込みができる（ブログ） ・利用者のプロフィールが見える ・CG Mによるデータ生成の仕組み
- 22. 運用状況 2005年12月15日：運用開始 利用者は口コミにより順次拡大 (2007/8/28) 利用者数： 約1593名 総記事数： 約13213件 アクティブユーザ： 約700名 （10日間以内にアクセスしたことがある人）
- 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
- 25. Railsといえば・・・ 設定より規約 convention over configuration
- 26. 重要なポイント チームにおける 約束事（規約）は コミュニケーション にとても有効
- 27. 開発体制 倉貫（サービスマネージャ＋プログラマ） アプリケーション インフラ ＯＪＴ • プログラマ（設計＆プログラミング）・・・全工程を担当 • 開発・システム運用・サイト運営・・・全業務を担当
- 28. コミュニケーションと体制 参加する人数は 少なければ少ないほど コミュニケーションのロスが 少ない
- 29. コミュニケーションと工程 作業の工程は 少なければ少ないほど コミュニケーションのロスが 少ない
- 30. 会議 • 定例 – 朝会（スタンドアップＭＴＧ） ・・・毎朝１５分 – 週計画＆振り返り ・・・毎週１．５時間 • あとは必要に応じて個別実施 無駄な会議はしない 参加者は必要な人だけ
- 31. ふりかえり • 週に１度実施 • Keep / Problem / Tryで共有 – よかったこと / 問題点 / 次にやってみること
- 32. ふりかえりをすることで 個人の持つ よかったノウハウや 抱えている問題が チームのものとなっていく
- 33. ファシリテーターがいると良い • 会議をスムーズに進行 • 参加者の会議への参加を促す マネージャの負荷軽減 チームの潤滑油 投資効果の評価が難しい
- 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. ソースコードの共有 • 個人ごとにソースコードを管理しない • 全員がソースコードの変更点を知れるように プログラム・ライブラリの前提を共有できる リリースまでの情報共有を減らせる Subversion svk and を活用
- 36. 開発環境の共有 • 本番環境と開発環境をそろえる • プログラマ同士の開発環境をそろえる 問題発生時の前提を共有できる 新しいプログラマーとも前提を共有できる VM W are Player or X en を活用
- 37. 具体的に使っている環境 • VMWarePlayer 2.0 – Debian – Emacs << rails.el + psvn.el … – screen + zsh – Ruby on Rails – MySQL • putty
- 38. タスク・不具合の共有 • すべての作業を予定と記録として残す • いつでも進捗状況を誰でも把握できるように 進捗の打ち合わせ時間を短くできる 誰が関係者かの前提を共有できる redM ine T rac を活用 or
- 39. redMineて？ • Tracに似たプロジェクト管理ツール – 課題・不具合・タスク管理 – Wiki – Subversionとの連携 • Ruby on Railsで作られている（オープンソース） • 複数プロジェクトを管理できる • ガントチャートで表示できる 参考ＵＲＬ http://gihyo.jp/dev/serial/01/redmine http://groups.google.com/group/redmine-users-ja
- 40. その他の情報共有 • RSSリーダー – redMine（かTrac）の出力するタイムラインを取得 – チームで起きたことのすべてをRSSで読める • SNSのグループ機能 – グループの掲示板機能を利用して情報共有 – メーリングリストは使わない →情報の一元管理 – 「ドッグフードを食べる」意味もある • ＳＮＳのブログ機能 – 日報がわりのブログを投稿する
- 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. ツールとコミュニケーション ツールを使って 知識の前提を揃えることで 普段の コミュニケーションの 質が向上する
- 43. ペアプログラミング 二人で一緒に開発 ディスプレイを用意すると便利 詳細設計も同時に行う 新人に一人で作業させない（重要でない仕事は無いのだから）
- 45. コードレビュー＆リファクタリング 「人月の神話」（外科手術チーム） チーフプログラマと助手 外部設計（仕様）も同時に行う
- 46. ツールとコミュニケーション ドキュメントによる コミュニケーションは コストパフォーマンスが悪い 人で補完 人を補完
- 47. さいごに
- 48. 今日お話したことは・・・ • XPと呼ばれる【開発の進め方】の一部です – ＸＰ = eXtreme Programming
- 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. ありがとうございました それと・・・ Railsプログラマ探してます 今日紹介したようなプロジェクトで一緒に仕事してみませんか？ ＴＩＳ株式会社 日本ＸＰユーザグループ 倉貫義人 kuranuki_at_gmail.com