読者です 読者をやめる 読者になる 読者になる

hiromitsuuuuu.log();

to see more to see.

DevLOVE現場甲子園2014 東日本大会に行ってきた

勉強会レポ

8/23(土)に開催された『DevLOVE現場甲子園2014 東日本大会』に行ってきた。6トラック(6つのテーマ)60セッションというカンファレンス並の規模…!

DevLOVE現場甲子園2014 東日本大会 - DevLOVE | Doorkeeper
DevLove現場甲子園2014プロフィール・発表概要

 

聞いたセッション

  • 【心】アジャイルな開発現場の変革事例〜よくあるアンチパターンと解決策〜
  • 【創】社内スタートアップでの組織の成長に伴い発生する痛みとその解決策(スクラム&顧客開発&リーンスタートアップ導入)について
  • 【技】私がドメイン駆動設計をやる理由
  • 【創】アジャイル開発の外側としての顧客開発。〜僕はプロダクトオーナーなんて出来ない〜
  • 【創】文化が混じり合う"潮目"こそ,デザインの問題が渦巻いている。と叫んでそこに身を投げた男がいた
  • 【技】安全なオペレーションをチーム全員で共有するための試み 黎明編
  • 【隊】やったことないアジャイルを無謀にも受託開発+業務委託の環境でやってみた
  • 【創】ワークショップデザインに期待されるもの
  • 【創】失敗上等!世にも奇妙な「旅行会社でのUXデザイン 裏話」
  • 【技】いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜

印象に残ったセッション

【LT】若手SEがチームのためにがんばってみた

http://syobochim.github.io/DEVLOVESlide/#/

ちょっと前に話題になった『Excelにエビデンス貼り付け』で、自分が自由にいじれる範囲で工夫して生産性を3倍にしたお話。スライドだけでは伝わらないかもしれないけど、コンテンツ力が半端無くてめちゃくちゃ面白かったです…!

社内スタートアップでの組織の成長に伴い発生する痛みとその解決策(スクラム&顧客開発&リーンスタートアップ導入)について

この話、めちゃくちゃよかったです。どうしたらこうなれるんだろう(´・ω・`)

【めも】

『1次ソースの人に教えを請う』のは職種が違っても大事なこと。リーンUXのジャニスさんなど、1次ソースの人を実際に呼んで教えて貰ってる実行力がすごいと思いました。
これまでのエンジニアの働き方が変わるという話も、本当に共感した。開発者も何故それ作ってるかとか、何の為の機能か納得した上で開発したいと思う。実際に仕事をして開発者が集まる場に行くと、これだけの開発者がコストかけて動いてるんだ、無駄だと思っちゃうものは作りたくないよねと思うから。仮称検証サイクルを上げるために、ビジネスサイドにはリーンスタートアップみたいな考え方があるし、開発者側ではそれを支えるために継続的デリバリーなんかがあるし、ひとつの目標に向かってみんなが地続きで進んでいってるように感じる。

やったことないアジャイルを無謀にも受託開発+業務委託の環境でやってみた

スライドは見当たらなかったので非公開かもしれません。某地図会社のステークホルダーが多い(協力会社4社、自社+得意先+関連会社etc...)プロジェクトでアジャイルを取り入れたお話。

f:id:hiromitsuuuuu:20140823171510j:plain

【めも】

  • 製品には生みの苦しみがある。
  • プロジュエクトでお父さんになるか、お母さんになるのか?お父さんではなく、お母さんになると決めた。お父さんは週末だけ(時々進捗や不具合を確認する程度)だけど、お母さんは四六時中一緒に居て面倒をみる。
  • 取り入れるにあたってのインプットとして、勉強会参加+関連本を読みあさった。
  • インプットしたら、できることからやる。
  • はじめは小さなホワイトボードで2人カンバンをやった。そして大きなホワイトボードへ。
  • カンバンには目標は何なんだ、ということを書いておいた。これがないと開発者が目標を見失ってしまうっぽかった。
  • これまではRedmine+SVN だった -> 開発環境を変えた。SVNからgitに移行するのが大変だった。
  • 上司にはアジャイルであるとか許可なんて取ってない。自社の風土。通すところさえ通しておけば良い。
  • はじめてなのに規模が大きくて、開発者と離れている状況ではアジャイルでやるのは難しい。プロパーと業務委託のエリアがあり、質問しにくいと感じたので業務委託エリアに足を運んだ。
  • KPTを考えたのはとてもよかった。
  • 自分次第で壊せる壁は壊す。だけど、過信しない(インプットをしないとかは駄目)。
  • 朝会だけではなく夜会も大事。メンバー間の壁をなくす。
  • いいことやってるのにおとなしいのはもったいない。アピールを!評価(目標管理)とつなげろ。そこは計算高く行くべき。


『外からスクラムマスターは呼ばなかった。なぜならプロダクトのお母さんになると決めたから。ベビーシッターはいらない!だけどママ友はいる!』めっちゃかっこよかった泣いた。

ワークショップデザインに期待されるもの

【めも】

  • 提供したいことの本質を忘れないようにする。可視化して、毎回のMTGで確認するようにしている
  • どう予想外の事態をファシリテートするか
  • 各職域で「いかに品質を上げるか」を考えた結果、各人の間で大事な物が異なってくる
  • 納得解と合意形成を得るための手段のひとつとしてのWS
  • なんとなくセッティングしたものはワークショップとして機能していない。場をセッティングするだけではワークショップと呼べない。

『場をセッティングするだけではワークショップと呼べない』がぐさっときました…。目的を決めてちゃんとファシリテートしないと引き出せないよね…。

いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜

  • クソコードとは「読む人を怒りの渦に叩き込むコード」
  • 優れたプログラマは1行1行の意図を説明できる
  • 優秀なプログラマに読まれる機会があれば、その人のコードは劇的に改善する
  • コードレビュー7つの秘訣
    • 1.レビューの観点を明確にすること
    • 2. 我が身に返ることを恐れずに指摘すること
    • 3. 何故悪いコードなのかを論理的に説明すること
    • 4. 良いコードについて共通認識を持つこと
    • 5. 小さい単位でレビューを繰り返すこと
    • 6. 指摘は素直な気持ちで受け入れること
    • 7. 指摘は人格否定でないことを理解すること

止まっちゃいけないフロントエンド開発

実際に聞いてはないけど、気になったのでメモ。Javaが主流なの意外だった。軽視されがちなフロントエンドに泣いた。

その他印象に残ったキーワード

  • 『おやつ神社』おやつコーナーを作り、ふせんで悩みをオープンに貼っておく。ふせんの悩みがお茶の話題になり、共有されることでそこに質が生まれる。
  • モチベーションチャート(モチベーションの可視化)を毎日つけてみる
  • 遠慮は成長への最大への敵
  • 持続可能で自分が最もパフォーマンスの出る時間と環境を見つける
  • 美術系に進学する学生が少なくなっている
  • チルドカップの赤いストローの話。何故赤いのか?答え>口紅がついても目立たないから。
  • 多国籍すぎるといじめがおきないらしい

かんそう

でぶらぶ甲子園面白かった(小並感) 。個人的に、なんかフェスみたいだって思った。違う畑を見に行きやすいし、そのほうが意外とおもしろかったかも。みなさん、限られた時間とコスト、自分達の環境のなかで、それでも良いものを作ろうと考えたり工夫してたりが素敵だった。共通しているなぁと思ったのは、多くのインプット(まずは勉強会で情報収集とか、関連書籍を読み漁る!とか)をして、できるところから取り入れていること。ツール導入を目的とせず、本質を見極めて、手法を自分たちに合うように工夫してること。あと、それまでの文化(Exelでのエビデンス作りとか、開発環境とか)を当たり前とせずに、より生産性や効率、良いものを作るために改善を進めていること。その改善のために挑戦をしていること。現場で前を向いて奮闘している人はかっこいい。さて、自分は現場でどうしよう?