DeLOVE現場甲子園（日本シリーズ） - kou-ishizaki/DevLOVE GitHub Wiki
[DevLOVE現場甲子園 日本シリーズとは？]
考トラック東日本 : 市谷聡啓選手
- ビジネスモデルを変えるか受託開発自体を捨てるか？
自ら意思決定をする。その責任を自分が背負う。
『旗揚げ』ジブンでジブンのハンドルを握る
WHYが見つかるまで開発しない
『その時、その目的に適したチームを組む』
『正義と結成に命を懸ける』
仮説検証と最短距離
『正しいものを探す』と『正しいものを正しくつくる』
お互いの場所を問わない現場
『人と人のネットワークに振り切る』
『人と人のネットワークに振り切る』
仮説キャンバスと検証キャンバス
『ツールをカスタマイズ』
全員で考えて、全員が動く
- スプリント事業ミーティング
- 事業バックログは『ツール』でマネージ
- 重なりをつくる（PJ、事業）
- チャット朝会(リモートワーク)
- 事業的負債はまとめて払拭する(合宿とかまとまった時間を取る)
考トラック西日本 : 川畑雄補選手(サイバーエージェント)
今日、言いたい事 『例外は現場の外で発生する』
ロールモデルが見えない
- アプリマーケティングを始めてみた。
- 当初は市場が小さかった。
- CAへ転職。受託から自社サービスへ
- 受託脳から抜け出せなかった
- 権限が拡大したが、うまく利用出来なかった
- 広告代理店へ
- 事前の営業イメージ >< 実態は違った
- 需要と供給のミスマッチを見た エンジニア >< 非エンジニア
- jsタグとか修正してあげるとありがたがられる
- テクノロジーの理解なしに、マーケティング活動ができない
- マーケターとかが技術を知らない
- 技術とマーケターの「間」が必要
- 数値管理から導出される資源の最適配置問題を解決してあげる
- エンジニアがエンジニアリング外から取り組める事
- PJの外からやってくる例外をキャッチする
- エンジニアが取れる数値から課題解決にエンジニアが取り組む
創トラック東日本 : 黒田樹選手
98 という数字 → リファクタ 106枚
cameran → 大ヒット御礼
初期の失敗談
カイゼン
- チームを小さく
- 『しないといけない症候群』（やり始めアルある）
- 『大事な事を決める』（何が最重要か決める）
- 『acunote』（マネージメントツール）
- かなり細かく管理（人日）
- バクトリアージという考え方
- 日付最優先の時は、次の開発で絶対にリファクタにリソース確保する事を決める
本当にやるべきものなのか？
- 効果、成長、価値が正しいものなのか？
- 必要な教育にコストを惜しまない
- ダミーの仕組みで『具体的な数値(価値）』を取る
- 実証済み ／ 未実証 を明確にする
- ABテスト ／ コホート分析
LEARNとIDEAS
- 学びからアイディアを出すのは逆向き
- [MVPキャンバス](http://www.slideshare.net/aerodynamic/mvp-canvas)
創トラック西日本 : 山本学選手
人の生活に触れ、沢山の人と対話するのは良い事だ
チーム
- エンジニアとデザイナー
- 所属メンバーは13人
History
- 5打数0安打 ／ 月イチ
- 現在(6安打目)のは安打確定
5打席0安打
- ジブン発のアイディアは当たらない(顧客・課題が違う)
- 能動的に課題解決に進まない(課題感が浅い／企画案→MVPによる体験まで必要)
Knowledge
- 少人数が良い。熱量が伝わりやすい
- 失敗を許容する組織文化
- 検討よりも検証・体験の検証が重要
- 沢山の人と話す、フィードバックを得る(共創)
- 5人のユーザを集めれば *ユーザビリティ課題の85%* を見付ける事が出来る(テストノウハウ)
副次効果
- 検証段階でファンを作れる
- アーリーアダプターを集めれる
- ファンは広告塔になってくれる
守トラック東日本 : 廣瀬 一海選手
ブラックな話しかもしれない。。。
クラウドの徹底活用
- Azure Web Sites(Git/Ftp)
- WordPress(コーポレートサイト)
- RemoteDeskTop(リモートワーク)
- 徹底したオートスケール(余剰インフラの廃止) ※現場での課題
- 自動化の果て・・・ 人が減る → 人減らしの手法になりかねない
インフラエンジニアが守るべきもの 『何か？』
- 人
- エンジニアリングは人がやる事。なので
守トラック西日本 : 山口陽平選手
エンジニアの健康を守る
まったくの初心者が始めた
- 認識技術『座学と演習』『実践』
- 座学 とっかかり
- 演習 エンジンでやってるような事も実装して理解する、性質の説明・比較
心トラック東日本 : 松浦洋介選手
エンジニアの健康を守る
Change
- メンバ間の期待マネジメント
- 相談頻度のUP 全体のスピードアップ
- 『数字大事!!』 同じゴールを目指せる
- 『数字ワカル!!』ボトルネック明確に Analytics／ヒートマップ
- 数字の説得力
- カイゼンのポートフォリオ → 効果的かつ効率的なところからカイゼン → 成功体験を積む
心トラック西日本 : 染田貴志選手
IT業界のTOKIO
リモート問題あるある
- 課題は何となく同じようなものが。。。
- 多くはコミュニケーションに起因する(個人の資質はあんまり)
- チーム（組織構造）に起因する課題（主従関係）
- リモート側『取り残されてる （疎外感）』 本社側『もっとグイグイ来いよ』
- 本社側が気付きにくい。暗黙のコミュニケーションが結構重要な
施策
- [施策]リアルに会う＆在宅勤務の実験
- [施策]巻き込み型オフィス改修 ヌーラボTOKIO & IT業界のTOKIO(ローカルならではのブランディング)
Enjoy
- 個人の嗜好だけでなく、組織へのプラスアルファを目指す
- リモートで働き、ローカルにねざす
技トラック東日本 : 西見公宏選手
待望のコードの時間 "もっと良いコードを書きたいなら、スゴいプログラマに読んでもらえ!!"
何故、「コード改善」に関心を持つのか？
- コードは読まれるまで分からない
- [改善]
- 1.人にコードを読んでもらう
- 2.『その』ためにコードレビューをしよう
コードレビュー
- サイズの少量化と頻度を増やす（習慣化）
- 良いコードの『共通認識*コストを減らす』を持つ
- 『何となく』→ NG 『人格否定』ではない
- 指摘は素直に受け入れましょう
コードレビューを行う意義
- 1.プログラミングは問題解決の手段
- 2.抽象化によって問題解決のスピードは上がる
- 3.良い抽象化＝良いコードを支援する
良いコードが拡がれば世の中は良くなる!!
技トラック西日本 : だいごろう選手
動けばいいから → モノ作りに拘る
ガウディの言葉 『第一に愛 第二に技術を』
現場のコード意識
- 仕様通りに動けばイイでしょ!! 『動く優先』が問題
- 読みやすい／引き継ぎ易い
- リーダブルコード
サグラダ・ファミリアの不幸
- 主要エンジニアが消える／アウトプットの消失
現場のコード意識
- 仕様通りに動けばイイでしょ!! 『動く優先』が問題
- 模型ベース(見て、取って触れるもの → 伝える) コンポ図（全体増を抑える）
- 設計思想を残す。コメントに（オモイ）残す
どうやって導入
- 『手本』になるつもりでアウトプットする
- 口頭説明が必要 → コメントが必要
- 違和感が有る → 納得するまで話す
- 積極的なペアプロ
- コードレビュー
次に求めるもの
- 組織風土とチーム作り
隊トラック東日本 : @kentana20選手
It takes two(Derak Sivers)
大事な事
- モダンな開発現場であるか
- 顧客へ価値をケイゾク的に届けられてるか
やった事
- 現在地を知る
- CMMIをやってみた(現在地と目標の見える化)
- キックオフ／ プロジェクト体制 ／ CMMIの項目毎にチーム化