DevelopersSummitに参加してきた
今日参加したDevelopersSummitの個人的なメモ
あまりにも個人的過ぎて役に立たない可能性が大きい。
プレゼン資料とかも公開されたら追加する予定。
-
-
-
- -
-
-
ソーシャルで発言される軸は、単純な時間的上下の流れではなく、単発的/多発的な同時多発で動的なものとして認識する必要がある
- -
対話→行動
パルスパターン 0.01% 話題性
クオリティパターン 0.6% 話題の継続性からの行動
ブレークパターン 2.3% 対話の中から派生する行動
- -
ソーシャルグラフ
花火パターン 瞬間的な広がり
数珠つなぎ 時間差があり議論が持続する
・複数のコミュニティが対話を続ける
中心的な大きな広がりを発生点とした
異なる議論の発生を促す
小規模コミュニティ→大規模コミュニティ
関連性の中からピックアップされる可能性を引き出す
外コミュニティからの流入
同一性の高さ中心から差異の大きい場へ持ち込むことで活性化を促す
- -
ストリームの変化を検知
streambase
Jubatus
-
-
-
- -
-
-
エンタープライズ開発とJIRA
プレゼン資料@slideshare
全体のフローが確定しやすいシステムはウォーターフォールでも高効率
- -
新規開発で全体観の見通しが立ちにくいプロジェクトをアジャイルで進めるのも難しい
既存のシステムに機能を追加していくのはやりやすい
- -
不確定性が高く大規模になりやすいシステムを作るにはどうしたらいいのか
- -
作業の管理
・成果物を作成するための行為/タスク
・何を/誰が/いつまでに/どのように
・管理規模が小さければタスクと人ベース
・管理規模が大きいと日程や進捗率で見る
コミュニケーションの管理
・作業の明確化
・検証のやり取り/バグ、変更の管理
・短期的サイクル/高密度なコミュニケーションが発生している際は対話の管理は少ない
・長期的サイクル/低密度なコミュニケーションが発生する場合は過去に遡れる蓄積を作る
- -
対象とするシステムを見極めた上でプロセスを決定する大切さ
1システムであっても複数のプロセスが必要になる
プロセスの本質を理解してシステムを作る上での最適解を求め続けるべき
- -
コラボレーション管理
・利害関係者の増加/分散=窓口型コミュニケーションは無理
・単一のISSUEに対して複数の利害関係者がコミットする
・多対多のコミュニケーションを行うと信頼関係が大切になる
・マネジメントの透明感がコミュニケーションの潤滑化につながる
・コミュニケーションの空間を分化してバランスを取る
・個人に直接責任を負わせない
- -
Bonfire
バグ報告プラグイン
- -
-
-
- -
-
-
エンジニアのスキルセット
1.ソーシャルって？
2.活用例
3.どんなエンジニア？
- -
山本祐介氏
長期的視野のみに基づいた仕様変更がし辛い仕組みでは柔軟性を保てずに普及に問題が発生する
システム的な仕様がビジネスのモデルに制約を加えるようでは普及しない
-
コードはできる限りオープンにしてる
オープンソース推進の部門がある
JIRA, Github, Cofuluence, Yammer辺使ってる
TLは見なくていいんじゃないのってゆるめの認識がいい
-
ソーシャルな中で気軽なやり取りを
ソースももっとオープンに
- -
藤本真樹氏
ソーシャルは度合いの問題（全ては元々ソーシャルである）
内部的な集約性と外部に対して拡散する要素、そのバランスを見極めるのが大切なのでは？
-
社内で人が増えると共有が難しい
社会的な情報の流れに合わせないと無理
情報の流し方-つながりの作り方
情報公開の度合いはチキンレース
-
- -
大沢良樹氏
情報流通的なソーシャルの視点
人同士をつなげる視点
-
社内で繋がっていない部分を繋げられる
TL, Feedは標準になる
コンセプトとしての共通概念を元にシステムを作りたい
-
情報発信力高い
スケーラビリティに対応できる力
