1. SALESFORCE R&Dと
ソーシャルと
ENGINEER HAPPINESS
#natsumiB1

3. ソーシャル ENGINEER ???

4. “Optimizing for Developer Happiness”
Video of talk: http://www.youtube.com/watch?v=22EECFEk9Xs

5. ENGINEER HAPPINESS?

6. MY DEFINITION of “ENGINEER HAPPINESS”
開発した製品のユーザから感謝された時
技術的に困難なチャレンジを克服した時
革新的なイノベーションに触れた、関わった時
優秀なエンジニアと仕事した時
理不尽な業務、プロセスから解放された時
自分のアイデア・提案が実現した時

7. MY DEFINITION of “ENGINEER HAPPINESS”
HAPPYだと感じることができる環境

8. ENGINEER
開発現場 ソーシャル
HAPPINESS

9. SALESFORCE R&D
の経験から考えよう

10. YOUR COMPANY

12. 実績のあるスケーラビリティとパフォーマンス
50+ Billion Transactions per Quarter

13. 実績のあるスケーラビリティとパフォーマンス
54 Billion Transactions
in Q1 2012
236ms
Average Response Time

14. ワールドクラスのサービスを全てのユーザに
 6つのデータセンターからサービス稼動
 ディザスタ・リカバリ対応
 DRサイトへの常時リアルタイム・データレプリケーション
 800M Transactions/day、300ms以下の平均レスポンスタイム
 99.9%+ 稼働率、 システム、サービス状況をリアルタイムに提供

15. 1年に3回のメジャーバージョンアップ

16. SALESFORCE R&D

17. 1100人以上がSALESFORCE R&Dに所属

18. 700人程のエンジニアが
SFDCのシングルCODEBASEで開発作業

19. SALESFORCE R&D
2007年にアジャイル開発手法に移行
SCRUM
XP開発プラクティス
LEAN
150以上のSCRUM チーム

20. SFを中心にグローバルに分散されたチーム構成
San Francisco
Santa Monica
Colorado
Seattle
Austin
Tampa Bay
Vancouver
Toronto
Saint Jones
Fredericton
Halifax
Paris
Tel Aviv
Stockholm
Hyderabad

21. SALESFORCE OFFICE in SF

22. 2011年に250回以上のDEPLOYS

23. DEPLOYMENT @ SALESFORCE
完全に自動化されたプロセス
段階的なリリース
WEEKLY PATCH
OFF-CYCLE リリース

25. “Move Fast, but DON’T Break Things.”
@SALESFORCE

26. 開発環境 ＆ TOOLS @SFDC
MANY HOME-GROWN TOOLS!

27. GUS
“Grand Unification Strategy”

28. GUSって何?
SALESFORCE R&Dが使用するSALESFORCE
開発に関する全ての情報、タスクをGUSで管理
FORCE.COM プラットフォーム上で構築
DOG-FOODING カルチャー
まずは自分達で使う

29. SCRUM TEAM & USER STORY
SCRUM TEAM 情報
バックログの管理
USER STORYの優先度付け

30. WORK ＆ コミット関連情報
WORK = ユーザストーリ、バグ
VCS とのインテグレーション
コミット承認ワークフロー
コミット情報のトラッキング
SOURCE CODEへのリンク

31. コミット情報のレポーティング、分析

32. RELEASE 関連情報
リリース・サインオフの管理
リリース 承認ワークフロー
リリース・スタンプ

33. テストケース & コードカバレッジ

34. SALESFORCE R&Dの開発情報や
タスクは全てGUSで管理

35. SALESFORCE R&D内の
コミュニケーション、コラボレーションは
CHATTER を活用

36. SALESFORCE CHATTER
企業向けソーシャルコラボレーションツール
社員とつながる
ユーザ以外のレコードもフォロー
コメント、いいね
グループ機能
ファイルシェア
CHAT機能

37. 全ての開発情報をCHATTER FEEDですばやく把握
WORK
CHATTER
COMMIT SCRUM
FEED
RELEASE

38. CHATTER FEEDS @ GUS

39. CHATTER 使用統計 in GUS
1400+ CHATTER GROUPS
リリースマイルストーン
Week

40. CHATTERの利用率が高い要因 @ SFDC R&D
ソーシャルリテラシーが高い
GUS上に全ての開発情報がある
組織の規模（1000人以上）
グローバルに分散したチーム事情
DOG-FOODINGカルチャー

41. CHATTERの活用例
チーム／部門／組織間での情報共有&コラボレーション
HELP!
ナレッジ、ベストプラクティスの共有
問題提起、ディスカッション、アイデアを発信する場
フィードバック（Thanks!）
求人、新しいプロジェクトの告知
雑談

42. チーム、部門をまたいだ情報共有、コラボレーション
仕様／テクニカルドキュメントのレビュー
広範囲にインパクトがあるコード変更、DBスキーマ変更
リファクトリングの通知

43. HELP、テクニカルアドバイス
POPULAR CHATTER GROUPS
WHO SHOULD I TALK TO?
BUILD ISSUES
BUILD ISSUES
R&D CODE
WHO SHOULD I TALK TO?
DB & SQL TIPS
TEST AUTOMATION
SELENIUM
JAVA PERFORMANCE
JAVASCRIPT BEST PRACTICES

44. 良いことは活発に誉め、共有する
いいね！

45. ありがとう！
ゲーミフィケーションの要素
自分のプロフィール＆専門分野の構築

46. ありがとうの可視化
ゲーミフィケーションの要素を取り入れ
貢献者ランキングで社内貢献者の可視化

47. 自分の専門分野をプロフィールとして公開
（社内版LinkedIn）

48. 新しいポジション、プロジェクトの告知
OPPORTUNITY OPEN MARKET
• エンジニアが自由にチームを移動できる制度
• 毎リリースサイクル開始前の一定間内に移動
• 目的
• エンジニアの生産性、モチベーションの維持
• クリエイティビティの活性化
• 新しいプロジェクト、求人に対する可視化の向上
• エンジニアと所属チームのフィット最適化

49. OPPORTUNITY OPEN MARKET FAIR!

50. 雑談
Airing of Grievances
社内に存在する問題点の発見
改善に役立てる

52. ソーシャルを活用した結果SFDC R&Dにて
どういった効果があったか？

53. 1. チーム・部門間の壁を越えたコラボレーション
NO MORE “WE” vs. “THEY”

54. DEVELOPMENT vs. TECH OPS
CHATTERが気軽にコミュニケーションをする場に
GROUPを活用しお互いが活発に情報共有、意見交換
DevelopmentもTechOpsも同じ組織という意識

55. 2. 組織全体で会話、議論する共通プラットフォーム

56. あらゆるトピック、問題に対して活発に意見を発信、意見交換が容易に
組織に関わる問題／課題の見える化
各々のエンジニアが組織全体のことを日常レベルで考える
マネージメントも会話に参加、アクションへ

57. BOTTOM-UPでエンジニアリングカルチャー形成に貢献

58. TECHINCAL DEBT
(技術的負債)
例）
リファクトリング
コードクリーンアップ
テストカバレッジ
ソースコード内のToDo
ドキュメンテーション
開発環境／ツールの改善

59. “Doing things the quick and dirty way sets us up with a technical
debt, which is similar to a financial debt. Like a financial debt, the
technical debt incurs interest payments, which come in the form of
the extra effort that we have to do in future development because
of the quick and dirty design choice.”
– Martin Fowler.

60. コードクオリティの劣化
バグの増加
開発コスト、期間の増加
エンジニア、開発チームのモラルに悪影響（壊れた窓理論）
TECHNICAL DEBTを増やす原因
• ビジネス、競合からのプレッシャー
• 締め切りからのプレッシャー
• マネージメント層にTECHNICAL DEBTを解決する重要性の認
識が低い
• 機能拡張、追加に特化し過ぎるカルチャー、事情

61. TECHNICAL DEBT RELEASE
来年早々に行うメジャーリリースはTECHNICAL DEBTの解消／削減のみに
特化したリリースに決定
新機能は（原則的に）なし
TECHNICAL DEBTバックログの作成
各チームは自身が抱える問題の洗出し、優先度付け、作業を責任を持って行う
TECHNICAL DEBTが少ないチームは他のチームをHELP、または1つのチーム
に属さない問題、課題を担当（TOOLの作成）

62. TECHNICAL RELEASEを将来行わないために
今後リリースでは
少なくとも20％の作業はTECHNICAL BACKLOGから選択（検討中）
機能追加とコードクオリティの維持
パーフェクトなバランスを確保

63. 3. 社内向けのプロフィールの構築、公開
同僚からの評価
チーム／組織への貢献度
会社にとっての自分の価値
改善点の確認
社内ネットワークの構築

64. CHATTERを活発に活用
求人の定期的な告知
エンジニアへの浸透
4. NEW OPPORTUNITY
新しいチャレンジ
モチベーションの維持
適切な人材の発掘
キャリア・セルフマネージメント

65. 5. 新しいアイデアの創出

66. • 発明、イノベーションを生む環境に共通するパターン
• 小さなひらめき（SMALL HUNCH）
• SMALL HUNCHの結合
• インタラクション
TED TALKS - Steven Johnson’s “Where Good Ideas Come From”
http://www.ted.com/talks/lang/ja/steven_johnson_where_good_ideas_come_from.html

67. PTOn!
Google “20 Percent Time” Programのようなもの
1ヶ月に1日好きなプロジェクトに取り組む
CHATTER上でPTOnのアイデアを提案、意見交換

68. ENGINEER
開発現場 ソーシャル
HAPPINESS

69. ENGINEER HAPPINESS

70. THANK YOU!