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

たけこうの意識低い系ブログ

@talfi121 意識低い系エンジニアのブログです。時々思いついた時に書きます。極稀にエンジニアっぽい技術系を書きます。

Regional Scrum Gathering Tokyo 2017(1日目) 参加してきた

2017/01/12, 13 の2日間にかけて開催されている
Regional Scrum Gathering Tokyo 2017 1日目の参加レポートというか自分用メモです。

酒飲んで帰宅した直後に書いてるので色々見にくいところがあるかもですm(_ _)m
スライドは公開され次第、更新していく感じで
あとKeynoteは朝仕事してたので、参加してないです。。。
(決して寝坊したとかそいうやつではない。。。)

セッション一覧、スライドなどはこちら
ハッシュタグ#RSGT2017
togetterhttps://togetter.com/li/1069660

参加したセッション一覧

  • シン・未来会議 - スクラムチームを支える組織づくり -
  • つらい問題に出会ったら
  • ゲーム開発を盛り上げる技術とチームを支え続ける原動力
  • 学生がチーム開発のメンタリングを改善したひと夏の話
  • エンジニアの技術力評価は難しい? - 5年間運用してきた相互評価制度の改善の歴史 -
  • アジャイル・メトリクス実践ガイド

シン・未来会議 - スクラムチームを支える組織づくり -

及部さん OYB48 (@TAKAKING22) | Twitter

スライドはこちら

メモ

  • 組織は変わるべきか
    トレンドの移り変わりはかなり激しいし、変化のスピードの加速
    生き残るためには変化とスピードが重要になってきた
    スピード感がでてなさそうなもの
    • 年間計画
    • 評価制度
    • 採用サイクル

シン・未来会議

最初はエンジニアリーダが集まってのふりかえり
でも自分達ではどうしようもないProblem(人・モノ・カネ)がでてきた
→ 組織としてのふりかえりが必要なんじゃない??
因果関係図を創った
問題の見える化 エンジニアのモチベーション低下の因果ループを見つけて、解決しやすそうな突破口を見つけた
ってことで シン・未来会議 開催(詳しくはスライド参照)

「うちは〇〇だから無理」とか「組織はこうあるべき」とかは違うでしょ

変えるのか変わらないのか、何を優先するのかは「自分達」で決める
これを飛ばしていっては、組織づくりなんてできないよ

いちばん大事なのはシン・未来会議の後、そのまま飲みに行くこと

つらい問題に出会ったら

開原さん kaihara (@155gta) | Twitter

スライド公開されてない模様

メモ

つらい問題に合っている時に自分を立て直す対話という本を進められた

  • ロジカルに解決できない問題もある
    →ロジカルは切れ味がよすぎる
  • 全員視点が違うので100%分かり合えることなんてない
    →対話を通してお互いに理解し合えるポイントを見つけていく

智慧の車座 で対話をしていった(詳しくは本に書いてあるらしい)

  • 自分の問題を自分で語ってみると自分が気付いてなかった問題が見つかることがある
  • 自分主体の物語に変えていくことが出来る

対話しましょうと誘うのではなく、ワークショップしましょうといって開催した
飲みに行こうかってなってもただ愚痴になったり、別の話になったりするけどこれなら 短時間で深い本気話 になりやすい
仕事上近い人だと、問題解決脳になってしまってこうすればいいじゃんになってしまうので、仕事上関わりが薄い人達で行うことをお勧め

ゲーム開発を盛り上げる技術とチームを支え続ける原動力

田口さん Ta╭( ・ㅂ・)و グッ chi (@masahirotaguchi) | Twitter

スライド公開されてない模様

メモ

自分のパフォーマンスを上げてもたかが知れてるが、チームのパフォーマンスを上げたほうがユーザに早くいいゲームが届けられる
みんなの愛の力を価値に!!!

ゲーム業界は他のソフトウェア業界よりもプロダクトを愛している
ただ愛の表現方法が、残業、休日出勤、徹夜という。。。
愛している故に、廊下で殴り合い

現場は既に盛り上がっているが、
拳で語るのではなく、 安全な場 で開発することが必要

ゲームの会社って意外とレビュー会やってない
やってたとして偉い人が偉そうに座ってて話しづらいので 意見が出せる雰囲気のレビュー会 を用意
→ 付箋に意見書いて匿名で出すとか
雰囲気のいい開発現場を目指して「モスバーガーのカンバン」
→1日1個小ネタを書く

いくら安全にしても転ぶことはあるから、 転んでも(そこまで)痛くない 場所
大怪我しないために作る練習の場を自分で積極的に開いている

  • 勉強会
  • ワークショップ
  • ディスカッション

学生がチーム開発のメンタリングを改善したひと夏の話

筑波大学大学院 M2 4人
もりや さん
こでら さん
むとう さん
おばた さん

スライド公開されてない模様

メモ

enPiT

筑波大学が行っている全国の大学から参加する2週間の開発合宿
学生メンターと技術メンターがいる

始める前のキックオフで昨年のProblem

  • メンターへ質問がしづらい
  • 技術メンターの関わり方が明確ではなかった

enPiT Go

昨年の問題を解決するために開発した
メンター呼び出しシステム

  • ちょっと来てよーぐらいで呼び出せる気軽なもの
  • ホントにポケモンの戦闘画面みたいで面白いww
  • 全員が見れるプロジェクタに写すことで他のチームが相談している内容見れたりして呼びやすい
  • 困っていることが明確になってメンターが適切にサポートに入れた

マジで他のハッカソンとかでも使えるものだと思った
というより使って欲しい

エンジニアの技術力評価は難しい? - 5年間運用してきた相互評価制度の改善の歴史 -

小賀さん Masanori KOGA (@makoga) | Twitter

スライド公開されてない模様 スライドはこちら

メモ

チームを超えた技術力評価制度
実績評価は同じ部署の人が行い、能力評価は他部署の人が行う
被評価者は1時間半のプレゼン + Q&Aを行い、評価してもらう

抱えていた課題がどうなったか

  • 短期的なスピードを重視しすぎている
    様々なエンジニア、グレードの高いエンジニアからのフィードバック
    中期的な視点、技術的な視点での評価
  • エンジニア評価の納得感
    リスペクトできるエンジニアからの評価
  • 採用・育成・評価の価値観の統一 軸を作っていたとしても捉え方は色々あるので、Q&Aを通して価値観共有 早い段階で評価する立場に

5年間のカイゼンの歴史

  • 評価軸 テストやセキュリティ周りを評価軸に入れた
    テストがないコードはなくなった
    セキュリティの脆弱性があるコードも減った

    全体的に技術力が上がってきたので分かりやすいコードがなくなり、評価軸を変更
    実現力、改善力を追加

    一般的な用語を使ったことで、定義を狭く捉える人がいたので自分達の言葉で文章に変更
    社内でよく使われている言葉に変更していった
  • 全体ふりかえり
    評価フローに追加
    当初はグレードが高いエンジニアを集めてやっていたが、今は全員でオープンなディスカッション
  • 評価結果の公開
    評価結果のコメントを全社に公開した
    点数制をやめて、総評とアドバイスをしっかり書くようにした

制度を改善していくコツ

  • ステークホルダーとゴールイメージ、期間を合わせる
  • CTOが主体でやっているということを見せて、能力評価は人事でやることではなく自分達でやることだと示す
  • 最初は評価軸を指摘しやすいもの等小さい挑戦から始めてカイゼンしていったもので自分達用のものだからコピペは危険!!

Q&A
Q:若いエンジニアとかから人を評価したくないとか意見はありませんでしたか??
A:CTOが全て間に入って、フィードバックも評価も全てCTOがやるから責任はCTOにあって評価者はそのサポートしてるだけというところから始めた

アジャイル・メトリクス実践ガイド

伊藤さん The HIRO (Hiro Ito) (@hageyahhoo) | Twitter

スライドはこちら

メモ

メトリクスとアクションの共通化・標準化が進み、プラクティスが一般化している

メトリクスの基礎

ソースコードの品質を「数値化して定量的に評価すること」、評価手法や基準などの体系のこと

  • 取得のポイント
    厳密性よりも有用性、メトリクスは事実に基づく必要はあるが厳密である必要はない
  • 活用のポイント
    何か問題について考えることのプラスになる情報を得る
    数値の変化に意味を見出す
    データを基に、アクションを考える

メトリクスは仮説検証に使用するため、従来にないものを創造する。 世の中に基本的なメトリクスはあるが、自分達に適したものがない場合は創っていこう 経営層には時間を絡めたメトリクスをネタにすると良い

プロダクト開発で必要なメトリクス

  • POにとって必要なもの
    プロセスメトリクス
    プロダクトメトリクス
  • SM・開発チームにとって必要なもの
    プロセスメトリクス

  • プロセスメトリクス
    開発作業などのプロセスから取得するメトリクス

  • プロダクトメトリクス
    プロダクトそのものから取得するメトリクス
    プロダクトが提供できる「体験」
事例

ステークホルダーに対して自動化する前の時間と自動化後の時間を具体的に報告
→ 自動化へのハードルが下がり、さらに進めてくれと言われた
チーム内外全員に対してプラスになるアクションを起こせた
欲するものが見つけやすくなる
→距離が近くなり、協働につながる
メトリクスで「仲間」になろう

メトリクスの実践的活用法

コードカバレッジを使用したYahoo内の事例

問題

  • コードカバレッジをアクションの指標にしていたが、カバレッジを上げることが目的になってしまいテストの目的が消えた
  • 基本メトリクスしか見ておらず、他の基本メトリクスも欠如していた
  • そして、その基本メトリクスを人事評価に使ってしまっていた

アクション

  • 導出メトリクスを取得
  • 単体テストの目的とメリットを再共有
  • 人事評価に使用しないように調整

メトリクスを測定しているチームは測定していないより自己評価が高い
→チームが停滞している場合はメトリクスを測定してみるのも良い

メトリクスの原則

  • 計測するものはゴールに直結すべき
  • 会話を促すものであるべき
  • 行動につながるものであるべき
  • 計測するものは少なくすべき
  • チーム・プロダクトを成長させるために使用すべき

感想

スゲー楽しかった(小並感)

今のプロジェクトもスクラムやってるけど、正直停滞感というか何かモヤモヤを抱えているので刺激になった
1度別のプロジェクトのスクラム見学させてもらった時も感じたけど外を知るって大事!!
でも、丸コピってダメだとは思うので後は自分でどう自分のプロジェクトに当てはめて色々やってみるかなんだろうなーと改めて感じた日だった

他にも色々あるけどたださえ長い記事がさらに長くなりそうだし、眠いし寝る(2日目もあるし)