Developers Summit 2014 (2日目)
初めてデブサミに参加したのでレポートを。
公式サイト
http://event.shoeisha.jp/devsumi/20140213/
雪の中、珍しく殆ど迷わずに会場となる目黒雅叙園に到着。
外観
内装1 廊下からふと見上げると貫禄のある看板が
内装2 これ屋内なんですよ
1コマ目の会場に入ってビックリ。
椅子がパイプ椅子じゃない!!
■１ やる気を引き出す組織風土の作り方 (藤田 晋 氏)
資料 (見当たらず)
開始時のスライド写真取り忘れました...orz
自分の業績を伸ばす ▶︎ 会社の業績がのびる ▶︎ 社員への対価に繋がる
（１） 組織
CAは社員数3000人近くいて、40代は3％程度。ほとんど20-30代。
会社の雰囲気が大学の研究室の感じ。
世代間コミュニケーションのストレスがほとんどない。
今の時代珍しく、終身雇用を目指している。
男女比7:3 理想は5:5 技術者は男の比率が高いのは仕方が無い
新卒は定期的に採用している。
部署に新卒が配属 ▶︎ 部署が活性化する これ大事。
もちろん新卒が取りやすいという理由もある。
ポジティブな社員がマジョリティ
ネガティブが伝染する前に手を打つべし。
抜擢は実績以上に人格を重視する
実績を重視した場合、人格駄目な人がリーダーになると下をつぶしてしまう。
実績がなくても人格者を上にすると、下をうまくリードしてくれる。
（人事）
[CA8]制度
2年に1回、1〜3名の取締役を入れ替える。
外れたくないから取締役がみんな頑張る。
会社は上が働くと下もついてくる。
上がやらないと駄目。
[CAJJ]制度
新規事業の開始 ▶︎ J5からスタート
J5, J4, J3, J2, J1とあがっていく。サッカーみたいな感じ。
粗利や営業利益に応じて昇格、降格する。
例えば、今期は必ずJ1へ昇格する！といった目標設定が行える。
CAは事業がおおいので、撤退ルールを決めておく事が必要。赤字が○月続くなど。
初めから撤退基準が決まっているので、突然やめろ、という心配がない。
[あした会議]制度
取締役と選抜社員でビジネスプランや課題解決を提案する合宿。
1泊2日などで実施。
意思決定の場にエンジニアが参加できるというのは大きい。
役員会で決まった事が上から下におりてくるだけでは、下に伝わりにくい。
意思決定の場に巻き込む事で、キーマンにしっかりと意思を伝える事ができる。
[社内キャリアエージェント]制度
社内で人材紹介している。
適材適所をおこなうため。
やりたいことをやる ▶︎ パフォーマンス上がる
[合宿]制度（あした会議とは別に合宿もやっている）
役員合宿、開発チーム合宿、プロジェクト合宿など。
会議室で済む内容でも、合宿することを勧めている。
仕事場で会議すると、目の前にやらないといけないことが山積していて気が散る。
お台場に合宿所を持っていて、渋谷本社からお台場に場所を変えるだけでも違う。
合宿が終わると必ず食事・飲みに行く。
そうすると仲良くなる。
[福利厚生]
力を入れている。
IT業界は採用が難しい。
エースを1000万出して採用するよりも、
今居る社員に「この会社を辞めたくない」と思わせるほうがコスト抑えられる。
[2駅ルール]
会社から2駅以内に済むと家賃援助が出る。通勤ストレス低減。
[その他]
有給以外にも休みがある。
部活も支援している。
せっかくある制度なのに「使われない」というのは避けたいのでネーミング重視。
（３）社風
半年に1回社員総会を行う。半期に活躍した社員を表彰する。
社内ポスター・トピックスメール
オープンなSNS活用
社内の活性化のため。
SNSの使い方を注意した事はない。
飲みニケーション
飲み代の支給＋翌日半休の制度もある。
社内結婚が多い
昔はそうではなかったが、今は社内結婚が多い。
安心して働ける会社でないと、社内結婚に至らない。
若手の抜擢
抜擢に怯まない。まだ無理だ、と思わずにやる。
入社1年目でも子会社の社長にすることも。
新卒入社の子会社取締役数42名。
効果がありそうでないもの （世の中に誤解されているもの）
離職率が低い会社は良い会社
離職率が極端に低い会社は逆に危ない。
働かない社員と差が出ないと、できる社員のやる気が落ちる。
ストックオプションやるから頑張れというのは危ない。
会社を辞めるタイミングを作ってしまう。金目当てになる。
美人が多い
一時的に社員のやる気があがるかも知れないが、それは継続しない。
にんじんボーナス
やりたいことに対する意欲を削ぐ。金目当てになってしまう。
仕事とプライベートの切り分け
家でも職場でも同じぐらいがちょうど良い。
まとめ
自分の働きが会社の成長に寄与している、という実感を持てることが大前提。
ネガティブは早く断て。
組織の空気は山の天気のように変わりやすい。普段からよく見ておく。
空気感、雰囲気が大事。ポジティブな人を増やす。
金で人をひっぱることは逆効果になりやすい。
金でつれてくると、金が原因で去っていく。
■グリーを支えるデータ分析基盤の過去と現在 (橋本 泰一 氏)
資料 (見当たらず)
困った事
人が増えるにつれてデータの提供がおいつかなくなった。
サービス改善が進まない。
データ分析の基盤を改善することで対応。
コンセプト
データは誰でも自由にアクセスできるようにする。
サービス増えてデータが増えてもスケールアウトできること。
ゲーム部分は Treasure Data という外部サービス。
【ゲームのデータ分析基盤】
Treasure Data
ログデータをゲーム改善のアクションにつなげる
・アクセス遷移分析
・一般的なWEBサイト分析手法をソーシャルゲームに導入
・ページ遷移
・離脱
・クリック
ジョブ管理をしっかりする
・ジョブ管理ツール
・データを社内に開放
非効率なジョブが大量に投げ込まれて、パフォーマンス劣化。
リソースは限られている。
・ジョブのモニタリングと管理が重要
クエリの先頭に、誰が投げたクエリかコメント埋め込む。
/* write by monokurotamago!! */
SELECT 〜〜〜〜〜〜〜〜
【GreePlatformのデータ分析基盤】
Hadoopベースで自作。
JDK7 + CDH4 + Apache Hive (v0.12+α)
・Hive Serer2
・追加パッチ
・独自拡張
利用状況
1日で大体5000ジョブ、数ヶ月のデータで60TB（圧縮した状態、レプリカを除く）。
全体だと180TBぐらい。
利用ユーザは100人ぐらい。大半が非エンジニア。
データへのアクセス方法
・直接アクセス
SQuirreLSQK
・グラフ化
Macaron (自社製)
・その他
Shell, Python, R, PHP, etc... ◀︎ エンジニアはこれらでバッチ作る
HQL(Hive Query Language)の中にRubyでスクリプトを埋め込んだりしている。
[近い未来のお話]
コンセプト
より速く、より高度に。
クエリの高速化、機会学習を利用したデータの活用
■越境する開発 ～あの日開発していたサービスの名前を僕たちはまだ知らない～ (市谷 聡啓 氏)
資料 (今回の資料が見つからなかったので、少し前の資料へのリンクを記載)
http://www.slideshare.net/papanda/ss-28953302
開始直前にこんな呟きが。
なんのことかと思っていたら、スライド120枚を40分でやります！ということだったw
アジャイルソフトウェア開発
うまくできてますか？できてない ▶︎ 何故駄目になるのか？
理由は様々。
正しいものを正しく作る ▶︎ 難しい
ユーザ、カスタマー、開発者間で、意図がうまく伝わらない
長く使ってもらうためには、きちんと作らなければならない。
正しいものを作る？
▶︎ 正しいとは何か。 誰かが明確な正解を持っているわけではない
▶︎ 正解を探す必要がある
注意
100人マネージャがいても何も作れない。
でも100人開発者がいれば、何か作る事ができる。
正しいものを正しくつくるには？
期待、リスクの２つのレバーが存在。
（１）期待マネジメント
関係者が互いに持っている暗黙的な望み ： 期待
期待を明らかにして適切に調整する ： 期待マネジメント
期待マネジメントは、立場・時間をこえて実施する必要がある。
期待マネジメント に関して、PMBOKには第3版までは明記なし。
4版以降から載った。
インセプションデッキ
これ使うと良い。まずはアジャイルサムライ読みましょう。
（２）仮説検証型と最短距離型
プロジェクトの開始から終了までの流れはざっくりこんな感じ。
1. プロジェクト開始時は、目的実現のための選択肢が多くある。
2. 何を選ぶべきか検証する。
3. 検証結果から、進むにつれて、選択肢はへっていく。
4. 最後はゴールまで一直線。
▶︎ 1, 2が仮説検証型フェーズ。 3, 4が最短距離型フェーズ。
開始時に「考えながら○月末までにサービスをつくりたい」
▶︎ 何も決まってない状態でこれは危ない
目的に適した方針と建付けを適用する必要がある。
仮説検証型と最短距離型で戦い方が異なる。
[仮説検証型]
リーンキャンバス（仮説）
誰のために何を提供するのか企画書を検証する。
エクスペリエンスマップ（検証）
キャンバスの課題が現れるか？提供価値が顧客の感情を変えられるか？
ユーザーストーリーマッピング（仮説）
ソフトウェアとして必要なストーリーは何か。検証したいことは何か。
インセプションデッキ（検証）
プロジェクトが開始できる状況かを確認する
ここまでできて初期コンセプト完成。
※途中で実際のユーザにインタビューを行い、フィードバックをもらいましょう！
かんばん
仮説検証型フェーズ ▶︎ タスクボード
最短距離型フェーズ ▶︎ かんばんボード
として使える。
仮説検証型から最短距離型へ変わるタイミングはインセプションデッキを見て決める。
期待マネジメント(仮説検証重視)からリスクマネジメント(最短距離重視)に重要度が移行する。
お客さんは最短距離型でやりたい
ユーザへのインタビューなど不要だ！
こんな感じで作ればよいから早くやってくれ！
でも 正しさは誰も決められない。一緒に探すしかない。
▶︎ インタビューしてフィードバックもらう事は重要
相手とどんな関係を結びたいのか。
一時的 ▶︎ 取引
長期的 ▶︎ 関係
ソフトウェアを作り上げるもの：ユーザ、顧客、プロジェクト、チーム
（３）越境する開発
自分と相手の中にぶれない軸を作る。
お客様がこういったからやれば良い ▶︎ そうではない
どちらも「そうだよね」と思える軸を持つ。
リーン開発の現場 109P
"理想とは辿り着くべき場所のところではなく、ありたい姿に向かい続けることなんだ！"
これからやりたいこと
日本全国の開発者とチームを組んで、全国で開発チームを作る事業をやりたい。
▶︎ 永和システムマネジメントやめてこれやります
アジャイルという姿勢をこれから来る人と分かち、ともに育みたい。
大事な事
開発とはたのしいものである
■デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣 (長沢 智治 氏)
資料
http://www.slideshare.net/tomohn/14d4
アトラシアンとは？
ソフトウェア開発者向けにソフトウェアを作っている会社。
ソフトウェアを愛しています。
ソフトウェアの力でこれまでできなかったことが出来るようになる
▶︎ デベロッパーはそこで活躍できる職業。
欧米ではソフトウェアデベロッパーは人気職業。 日本では...
アトラシアンの製品は多くが無料版がある。
小ユーザー向けに安い(10人未満は10ドルなど)価格で使ってもらう、スタータープログラムというものがある。
スタータープログラムでの売り上げは全てチャリティにいれてます。
公表している製品の使用ユーザー数にもカウントしていません。
アトラシアン(日本)はマリノスタウンにある。
オフィスからサッカー見れる。
イタリアンレストラン跡地なので、ピザも焼けるオフィス！
ここから本題。
ソフトウェアの世界もだいぶ変わってきている。
ビジネスを上回るスピードでテクノロジは進化する。
その中でより良いものを作る ▶︎ 活躍できる！但し辛い！！
BMLモデル
創造 成果 変革 のサイクルを１ヶ月などのスパンでまわす。
Build Measure Lean
長い時間をかけて作る要件(これまでのやり方)がこれからも通用するかは不明。
開発現場に求められる資質
開発現場だけよければよいわけではない
ユーザが使う ▶︎ ビジネスが潤う
フィードバックを受けながら開発を変えていく必要がある。
これまではアサインされたタスクを行うだけで良かった。
作ってできて動いているものが、どのように使われているか。
それを知る必要がある時代になっている。
試行のプロセス 継続的な価値提供 が重要に。
ソフトウェアを取り巻く環境の変化 (画像は公開資料を抜粋)
これからの時代は青色になっている現場（複雑）が増えてくる。
建物の建築はこれ。
ソフトウェアもこれで出来るが...
同じモデルで出来るなら、パッケージ導入で済むのでは？など。
定型で作れる物は減ってきている。
実測駆動なプロセスモデル
新製品開発
ソフトウェア！ （新たなチャレンジが多い） マッチする。
これからの開発現場
・やったことないやり方
・知らない技術
・短く定期的なサイクルタイムでつくる
（時間かけて大きく作る、ではなく、小さいものを早く作る、できたら次を作る）
力を発揮できる環境
・モチベーション
・目的、規律の見える化
・よりよいものを取り入れる勇気
自分を変える事はできる。でも人を変える事は難しい。
人を変えるには時間がかかる。年を取るごとに期間がのびる。
小学生なら数ヶ月。大学生なら半年。大人は１年。
大人を変えるには１年以上かかるが、それを待っていることはできない。
環境を変えることでアシスト
・変わりたい、と思えるような環境を作る事で、自立的に変わる。
開発のツールも環境の一種。ここを改善することで、人を変える事ができる。
確証バイアス
一度うまくいったもの、どうせうまくできないと思うもの、それから人はなかなか抜け出せない。
自分が思ったものにたいして、過去の経験にとらわれて流される。
建設的相互作用
複数人で問題を解決しようとすると、
・自分の考えを見直す機会が増える
・相手の解を一般化しようとする
・繰り返しにより応用力となる
ツール進化の3つのポイント
・作業間の受け渡しの自動化
・テスト自動化の範囲拡大
・透明性の推進と省力化
今までは成果物ごとにツールがあった。
設計はこのツール、開発はこのツール、テストは〜
これからのツールは、フェーズを越えて使えるものが必要になる。
▶︎ アトラシアンはそういう製品つくってます
[アトラシアンの製品のデモ]
Confluence
wiki.
ドキュメントを書いて、簡単にチケット埋め込みができる。
こうすると、担当者と、ステータスがドキュメントのなかに埋め込まれる。
■エンジニアだからできる自由な生き方
資料
http://sssslide.com/speakerdeck.com/masuidrive/14-a-5-enziniadakaradekiruzi-you-nasheng-kifang
▶︎ 見た事無い人は一度目を通すと良いですよ
テキストwebサービス：wri.pe
▶︎ こんなものを作りました
プログラマ35歳定年説
▶︎ 年をとってもコードを書き続けるには何が大切か？
環境が大事。
朝早くから夜遅くまで働くのは年取ってからだとつらい。
自分で働く時間を決める、勉強する時間を決める、とすることで、
年取っても若い人と同じ（＋経験では上）コードがかけるのではないか。
一日中プログラムを書いていられるほどプログラムが好きだが、
その泉源が分からないことが不安。
例えば家が火事になって、全部燃えて消えても、その翌日からなんらかの仕事ができる状態にある。
▶︎ 自分を雇ってくれそうな人、もらえる額などを把握している
特定の分野のみではなく、幅広くドットを打っておく
▶︎ 自分の世界を広げよう
日本と海外で「大人」という意味の違い
日本 ▶︎ 大人しい 大人になる
物事を荒立てることをしない。
現状維持で当たり障り無く目立たないようにする。
海外 ▶︎ 大人になる
自立した個人として自分の意見を持ち、周囲に影響を与えて社会に関わる
オマケ
DevLOVE甲子園やアジャイルサムライで見かけて気になっていた、
Ameba waterが1コマ目の会場で配布された。
中身は普通のミネラルウォーター？だったけれど、感慨深いw
以上。
