日時：2014-08-23（土）11:00 - 20:00
会場： オラクル青山センター
主催：DevLOVE
集え、現場の実践者たち。
今回のDevLOVEは、現場各地から 挑戦者 に集まってもらいます。
現場でのあなたの挑戦を発表しませんか。直面した課題と実践した工夫、挑戦の途上でも構いません。それぞれの現場を越えて一同に会し、互いに自分にしかできない話をする。そこで得られるフィードバックは明日の前進をあと押しする力に、きっとなることでしょう。
Togetterまとめ
DevLOVE現場甲子園2014 東日本大会のまとめ #devlove
http://togetter.com/li/711107
スライド一覧
https://docs.google.com/spreadsheets/d/1-dj_DTlVKfYWJE-8Su5nSm-XNXwcH_9HS_c2kKA1POA/
--
#所感
ちょっと遅い気もするけれど、スライド未公開の発表もあるので、メモ。
新卒すぐに起業した方から、還暦Rubyエンジニアの方までバラエティ豊かな登壇者さんが発表されていた。
「オフィスの社交場（おかし置き場）と併設する悩み事掲示板を作って問題を共有する」といったカイゼンから、「レガシープロセスからhipchat, Qiita Team, GitHubに移行」と言った大改造なカイゼンまで様々聞くことができた。
大雑把にまとめると以下の点を聞けたのが良かった
- 自らで会社のプロセスに手をいれるにはヴィジョンと根気が必要。
- アーリーアダプターが数人いないと、マジョリティを説得してカイゼンは難しい。トップオーダーやオーナーを利用して推し進めるのも一つの手段。
- 現場を変える可能性を一番持っているのは現場のエンジニア。管理者がWhatを与えても混乱するだけ。自発的に動けなくなる。WHYがないと現場のエンジニアは動けない。
- 動かなければ何も変わらない。異世界に思える開発現場もそんなに遠くない。
- 若いというだけで君たちは時間の資産家である
- やることやってるひとは会社にしっかりアピールする。評価（目標管理）などにつなげ、そこは計算高く。
- 同じレベルのエンジニア同士でレビューしても限界がある。優秀なエンジニアのレビューは限界を引き上げる。
- 大きな責任には大きな裁量を。会社に仕事を残すよりも新しい仕事を作り出す人を残す。
腐らず、根気よく。より良き現場を目指すにはスキルだけでなくメンタリティも重要だと気づけた1日だった。
--
DevLOVEとは
理想の世界を現実の現場にもってきたい。
一人一人が経験できるソフトウェア開発はたかだか300人月。
自分ができる経験値は知れている。限られた時間を拡張するために、他人の視点を借りる。
今日は東京以外にも関西、名古屋、広島、四国などでも開催している。
DevLOVE is hub for Gemba。日本全体で知識共有をして、少しでも現場を良くしよう。
#LTのメモ
Windows女子部のご紹介
現在会員207名。
Windows女子部と言いつつ、HTML5など手広くやっている！
Linux女子部の存在は知っていたけれど、Windows女子部の存在は初めて知った。
https://www.facebook.com/groups/WindowsGirls/
Android女子部もあるらしい。。。
http://jag-andronjo.blogspot.jp/
直近で行われたWindows女子部のセミナー。
夏祭り！つながる、広がる、IT女子
http://kokucheese.com/event/index/198070/
調べたら沢山あった！IT系○○女子部ご紹介
http://matome.naver.jp/odai/2132634807232551301
テストの自動化ツールつくるのツラくない
@syobochim さん
「若手SEがチームのためにがんばってみた」
http://syobochim.github.io/DEVLOVESlide/#/
社会人３年目だけどチームにテスト自動化とツールの展開
TeraTermやVBAで自動化したのにおじいちゃんが使ってくれない。
自動化してもそのあとの展開方法、フォローが大事。
問題意識を持っていること、定量的評価ができていてとてもよかった。
スライドがReveal.jsってところも意識の高さを感じた。
＃宣伝！
Reveal.js、Markdown、Githubでスライドを作成する。
http://qiita.com/budougumi0617/items/19b19019bbe01f86e251
##Applications made with twelve factor-app for dev love甲子園lt
@koudaiii さん
http://www.slideshare.net/ssusera9d121/applications-made-with-twelve-factorapp-for-dev-lovelt
CookPadのCIを自社でもやってみた話。
CIひと通りやったので次はblue-green deployment 、ChatOpsだ！
http://www.slideshare.net/ssusera9d121/applications-made-with-twelve-factorapp-for-dev-lovelt
waffle.ioでタスク管理を改善
具志堅さん
https://waffle.io/
GitHub Issueをカンバン化して営業、デザイナーと一緒にタスクを管理できるようにした。
waffle.ioを使うと、Issueの優先度管理、タスク管理ツールの一元化ができた。
たしかにIssueはプロジェクトマネジメント的には不足情報が多い。各担当が一箇所で進捗・課題確認ができるのは、情報の一元化としてとても有用である。
質を考える
https://waffle.io/
開発者それぞれの関心ごとが重なっていなければならない。
そのためには「場」を作ることが大事。
おやつ置き場の隣にお悩み相談掲示板を作った。
弊社もオフィスグリコを導入している事業所があるので、この取組みはすぐ真似できそう。。。
#「あなたの現場のInfrastructure as Code 進んでますか」
ふじもと( @r_fujimoto) さん
Infrastructure as Codeの歴史
DevOpsは2009年に初出。
2012年：継続的デリバリー出版。アメリカ大統領選でAWS
2013年：入門Chef Solo
2014年：GitHub実践入門。チーム開発実践入門など
私が経験した現場
2004 大学内ネットワーク、教育システム（発注側でインフラに関わる）
2008 ベンチャー社内インフラ
2013 官公庁のインフラ更改案件
2014 輸送システムの開発インフラ
私のインフラ現場
- エンジニアが60人いてもGitHubやバージョン管理を知っている人がいない。
- 手順書を書いても、自分で構築してもコード化する必要性を感じない。
- root権限を持っている神が多いので、設定が翌日グチャグチャになる。
Infrastructure as Codeの本質
なぜ生まれたのか
- DevとOpsが協力して、継続的にデリバリーしたい
- 職人芸エンジニアによるインフラ構築から脱却
- 属人化をやめる
Infrastructure as Codeの世界観
手順書があっても人はそれを再現できるとは限らない→codeで書いて人手を介さない
人がやると（環境は）壊れる、また、人は壊れる。（異動する、ミスする）
どうInfrastructure as Codeを進めるか
どう周りにエヴァンジェリストしていくか。
「空気」に向かって話す。伝え方や態度に注意して。
アーリーアダプターが数人いないと、マジョリティを説得してカイゼンは難しい。
トップオーダーやオーナーを利用して推し進めるのも一つの手段。
--
「システムインテグレーションの現場を変えるOSS開発」
村木 暢哉さん
クラウドによって変わるSI開発。投資先が変化してきている。
クラウドは安い→クラウドは利益を生める
従来のSIは属人化など、クラウドと相反する要素が多い。
ポイント部リリースではなく継続的にリリースするビジネスモデルに。
開発体制の標準化→Infrastructure as Code、オーケストレーション。
標準化をすることで、テンプレートを作成できる。別に応用もできるし、一定の信頼性を担保できる。
顧客の要求からチームで蓄積したデザインパターンを組み合わせて効率的に価値を提供する
パターンは例えばクラウドフォーメーションのパターンとChefのスクリプトの組み合わせ、serverspecなどをパッケージ化している、
中小企業のクラウド化は非常に遅れている。
専門家が作成したパターンを利用して比較的容易にクラウドを利用することができるようになる。
--
#「SIerのアジャイルとジレンマとパラダイムシフト」
てらひで (@terahide27) さん
SIerでアジャイルするのは難しい。
なぜSIerでアジャイルするのは難しいのか？
→開発プロセスのパラダイム・シフトが発生しているから。
| 従来 | アジャイル | |
|---|---|---|
| 固定 | 要求 | リリース・日程 |
| 調整 | リリース・日程 | 要求 |
アジャイル開発はSIに必要か？
会社的にも、上司的にも、同僚的にも抵抗が大きい。
エンジニアとしては、顧客に「価値」を継続的に提供することをミッションとするべき。
- 高い品質を維持
- 継続的にリリース
- 必要な時にリリース
しかし、会社がこれらを行える社員を評価してないと理想論にしかならない
--
「中間管理職がいなくなったらプロジェクトがうまく進みだしたよ♪」
管理する人がとつぜんいなくなったらどうなるのか？
西 秀和 さん
現状の把握
IT人材白書より統計情報を調査。
日本のエンジニアは約１１０万人。
プロジェクトマネージャーは約15％。
*開発者5人に対してプロマネが2人。。。？
IT人材が足りていないと82％の企業が回答
そして足りない職種はプロマネ。
経営者は管理能力（プロマネ）を不足としているが現場の認識と異なるのではないか？
管理者がいなくなったチームで開発したらどうなったのか
→うまく行ってしまった。なぜか。
現場のエンジニアだけで膝を突き合わせて何をスべきか話し合った。
全員でゴールを共有できた→全員が自発的に動き出せた。
What? How? Why?
中間管理職は何をすべきなのか？
現場を変える可能性を一番持っているのは現場のエンジニア。
管理者がWhatを与えても混乱するだけ。自発的に動けなくなる。
WHYがないと現場のエンジニアは動けない。
現場のエンジニアも本当はすごいんだぞ！
--
#「モダンな現場にするために実践したこと（仮）」
@kentana20 さん
https://speakerdeck.com/kensuketanaka/modannaxian-chang-nisurutamenishi-jian-sitakoto
一休.comの開発
一休の開発体制は開発部とインフラ部に分かれている。
現場改善のきっかけ
現場はモダンですか？
スピードを保って顧客に提供し続けていますか？
レガシーな開発現場で、提供スピードも下がってきた。。。
naoya_itoさんのWebサービス開発の記事を見て現場カイゼンを目指した
hipchat, Qiita Team, GitHubへの移行。
カンバン、朝礼、見える化など。またあえて情報発信の冗長化を行い、「知らない」「聞いてない」を作らない。
まとめ
動かなければ何も変わらない。
異世界に思える開発現場もそんなに遠くない。
スピード感を持って進めることが大事。
うまくメンバーを巻き込めても、効果を感じないとだめ。
--
「Gitによる多人数開発における切り戻し方法」
池田涼太郎（楽天）さん
Gitの使い方。force pushを使って戻すと他人がpullしてると事故る
revertのrevertはできる。
切り戻しはセントラルリポジトリに大きな影響を与えるので、周りのひとときちんと摺り合わせを行うこと。
--
#「やったことないアジャイルを無謀にも受託開発＋業務委託の環境でやってみた
@kimkimmymi さん
アジャイルにしようと思った理由
今までできなかったことはやり方を変えない限りできない。
いつも遅れるプロジェクトをドラスティックに変えるにはやり方をかえるしかない。
なにから始めたか
勉強会や本など。できることからやる。
まず簡単なところからカンバン採用。
イテレーションの目的はカンバンに書いておかないと開発者はブレる
CI環境構築。Redmine+SVN → Jenkins+git+Calaba.sh/Cucumber+deploygate
svnからgitに移行するのはとても時間がかかった。
KPTをイテレーション内の真ん中でやる。KPは出る。
Tは最後にでてくる。
ファシリテータは持ち回りするほうが教育となる。
大きく変わることは大事
やれることからやる
- 自分次第で壊せる壁は壊す
- 過信しない
- KPTめちゃくちゃ大事
- 任せる
- 夜会も大事。
やることやってるひとは会社にしっかりアピールする。
評価（目標管理）などにつなげ、そこは計算高く。
--
「執事と始めたチーム改善活動」
あさの (@uasano) さん
なぜJenkinsが必要だったのか
プロセスが原因なのに、担当者が責められる→反復作業は機械化
「枯れた手法」が最善→チームの状況に合わせて見直す
やったこと
リリースビルドの自動化
手作業のリリースビルドの失敗を撲滅する
顧客別にリリースビルド時のパラメータ変換をしていた。
ビルドスクリプトの整備とJenkinsによるビルド
1クリックデプロイ
検証環境へのデプロイマチイ時間を短縮する
検証お環境で様子を見てから本番環境のデプロイにも適応
振り返りの実施
チーム自身でチームを良くしていく基盤
開発速度を下げる要員を共有
自分一人で始められることから始めるのが簡単。
自分の得意分野でチームに貢献できることはなんなのか考える。
みんなの困り事を書いけるすると信頼貯金がぐっと増える。
地道な下準備が大事。
チームの問題を自分達でチームをカイゼンする仲間づくりが必要。
改善効果を定量・訂正的に測定していなかったので、予算圧縮で振り返りできなくなった。
--
「失敗上等！世にも奇妙な「旅行会社でのUXデザイン 裏話」」
和田あずみ さん
http://www.slideshare.net/azumiwada7/devlove-120823-38280665
UI、UXデザインのドロドロ話
1話：鳴り止まない電話
モバイルサイトに電話をかけやすいUIを作った
→めんどくさがりのユーザがすぐ電話をかけてきてカスタマーセンター混乱
放棄率があがり、成約率が下がった
第2話：工数もない 金もない ついでに権力もない あるのはやる気だけ♪
なにもないけど、手作りユーザーテストをやってみた
小さいけれど、成功体験を得ることができた。
第3話：無限増殖する 注意文言やバナー達 気づいたらいつのまにか増える、 注意文言やバナーの数々。 でもなかなか消せないんです…
組織にもユーザーテストの大事さが根付いてきた
無限増殖を食い止める合意形成を行なった。ABテストで定量的な証左を出した。
「スタンドプレーから生じるチームワーク：人に技術を残すということ」
あんざいゆき さん
2011年に会社を作った。Android歴2年、Androidの仕事がしたくて作った。
サラリーマンしている傍らで本を出版した。
出版は時給換算しないと割りに合わないが、自身のウリにするならばあり。
フリーランス集団が集まる会社。
- フルフレックス。
- 給料は各自で決める。5人なので、誰がいくらもらってるか知っている。
- 椅子と開発マシンは自分で選ぶ
- 本屋ガジェットを経費で購入する
大きな責任には大きな裁量を
その代わり責任も大きい！
SEとしての生存戦略は各自で決めてくださいというスタンス。
各自でマネージャを。フリーランス集団なので、セルフマネージメントで。
会社の生存戦略。誰と働くのか。
企業文化に合う人をどう採用するか。
- 採用には全員の承諾が必要。
- リリース力のある人。コードだけでなく、画像作成、問い合わせ対応など
Webサービスを独力で出すということは小さくてもビジネスを全て体験しているということ。 - 学び続けられる人
金よりも仕事よりも人を残す
会社に仕事を残すよりも新しい仕事を作り出す人を残す。
- 個人プロダクト推奨
- 執筆活動推奨
- 勉強会での発表推奨
フリーランスになる時に会社として作ったほうが得だったので、会社にした。
--
デキるプログラマだけが知っているコードレビュー7つの秘訣（DevLove版）
西見さん
http://www.slideshare.net/rootmoon/ss-38278479
クソコードとはなにか
読む人を怒りの渦に叩きこむコード。
読めないコード、要領の悪いコード、意図がわからないコードはレビューアを心を負の感情に突き落とす。
優れたプログラマの秘訣はクソコードを書く人の逆説。
どういう処理なのか？どういう意図で書いたのか？を質問するとわかる。
優秀なエンジニアによるコードレビュー
同じレベルのエンジニア同士でレビューしても限界がある。
優秀なエンジニアのレビューは限界を引き上げる。
コードレビューの心技体
今日は心だけ。
- 我が身に返ることを恐れないこと
- レビューの観点を明確にすること(スタイルの観点、セキュリティの観点、など)
- なぜ悪いコードなのかを論理的に説明すること
- 良いコードについて共通認識をもつこと
- 小さい単位でレビューを繰り返すこと
- 指摘は素直な気持ちで受け入れること
- 指摘は人格否定でないことを理解すること
聞いていないけど、スライドを見て思うところがあった発表
エンジニアの生きる道
http://www.slideshare.net/FUKUIOsamu/20140823-devlove2
福井修 （@iR3）さん
還暦超えても現役エンジニアの発表者の方。
Rubyが95年生まれなので、早くても40歳からRuby覚えたということ。
そのハングリーさにとても感銘を受けた。
若いというだけで時間の資産家。そのとおりと日々痛感する毎日。