mono(0w0)ログ

読んで、体験して、自分でやってみた記録

Scrum Fest Osaka 2019 1日目

Agile scrum

参加しました。1日目で学んだことを活かして、なるべく時間かけずに気持ちを吐き出しておきます。 2日目になっちゃいましたけど。

「アジャイルやりたい！」って言うてるニワカ(おっさん)が足掻いた結果

  • みうらさんとバックボーンが重なる部分が多いのでシンパシーを感じる
    • 僕もアジャイルに触れたのは36歳の時
    • トラディショナルな開発を経験してる

お堅い企業でスクラムチーム

  • 後でお話を聞いたらスピーカーの上司にあたる人がスクラム導入を推進していたそうです
  • 大企業から事例が出てくるのはとても良い
    • お世話になっています

"評価の魅せ方" 駆け出しマネージャー風 少し斜に構えて

  • 自分のチームで評価おざなりだったのは反省
  • ちゃんと評価されたいし、評価してあげたい
  • 成長のための評価と報酬のための評価を分けて考えよう

コミュ障仕事術 - Customer Interaction Patterns から学ぼう -

  • 過去を振り返るとできてなかったなーと思い当たることがいっぱい
    • すぐ返事する
    • できないと言う。ありのままを伝える
  • チームとしての信頼を貯める
    • POを助けたい。やっていき。

プラクティス厨から始めるアジャイル開発

2019/02/25 スライド追記

  • 原点ってツイートしてるけど原典でしたね
  • セッションに引き込まれる。凄い！
  • 個人的1日目ベストスピーカー

感謝のKPT 5000枚 -基盤チームのレトロスペクティブ-

完全にコレ

  • でも、なんかやれそう
  • 気持ちを吐き出す

説教「お前のそれ、スクラムじゃないから」

  • 描いたやつツイートするか悩んだけどやってよかった
  • 返信もらえて壁打ちしながら考察できた
  • 理想と現実のギャップを捉える
  • スクラムのフレームワークに沿って何を大切にして、どうやって、何をなすのかを構築していく感じ
  • 深い

Networking Party!!!

  • 昨年のScrum Boot Camp OSAKAの同期に会えた
  • スピーカーの方にもお話伺えたり、感想を伝えたりできたのは良かった

まとめ

さあ、今から2日目。楽しみー。

スクラム道関西 第117回オープン・ジャム に参加しました

Agile 勉強会 scrum

初参加でした。 昨年Scrum Boot Camp OSAKA in June 2018に参加してから結構経っていますね。

参加者とか雰囲気とか

  • 参加者は20名強（正確に覚えてない…）
  • 参加者の半数くらいが初参加
  • 参加者の1/3から1/4くらいがこれからスクラム始めたい
    • わりと堅めのことをやっている方々（僕もどちらかというとそっち系）
  • 今回の会場は株式会社ラクスさまのご提供
    • 綺麗で広くてとても快適でした

やったこと

Lean Coffeeによる対話形式でした。

最初に対話したいテーマを個人で付箋に書いて提示します。テーマを出したらドット投票により話してみたい・聞いてみたいテーマの優先順位をつけていきます。優先順位の高いテーマから順に各テーブル（今回は3つ）で対話開始します。

対話のタイムボックスは7分。7分経過したらハンドサインで継続するかやめて次のテーマにうつるかを決定します。継続したときは+2分の時間が設けられました。

僕が参加したのは以下のテーマです。

  • 品質管理はどうしてる？どんなメトリクスを取る？
  • スプリントプランニングどうやる？
  • 認定スクラムマスターについて
  • 社内勉強会や読書会どうしてる？どう続ける？
  • デイリースクラム時間オーバー問題
  • どんなドキュメントを残す？
  • 予算の見積もりどうしてる？

やってみた感想・学び

とりとめなく列挙します。

  • 7分って結構短い
  • タイムボックスが切られているので集中する
  • 自分が抱えている課題に向き合う感覚
  • 実は問題は別のところにあったとか
  • 問題箇所を探索している感覚
  • 本質を考えさせられる
  • コンテクスト大事
  • スクラムガイド読み直そ
  • 湧いてくる新たな疑問
  • 要約して話すとかうまく問いかけるの難しい

おわりに

誰かのお話を聞くのではなく、積極的に対話に参加して自ら学ぶのは大変だけど面白いです。

あー、そういえばできてなかったなーとかマンネリ化あるあるーとか、他の人のお話を聞くことで自分のチームの良くないサインに気づく。自分のチームを外から検査してる感覚。中にいるとなかなか気づけないのだなぁ。あるいは目を逸らして気づかないふりしてるだけなのか。

継続して参加していきたいなと思いました。

起きている問題をきちんと把握する 職場の問題地図読んでみた

読書

職場の問題地図 ?「で，どこから変える？」残業だらけ・休めない働き方

職場の問題地図 ?「で，どこから変える？」残業だらけ・休めない働き方

子供と図書館に行ったら見つけたので読みました。 基礎的なことですけどわかりやすくまとまっていて、良いふりかえりになりました。

仕事を５つの要素で捉えるのはメンバーに説明しやすくて重宝しています。

5つの要素で仕事をとらえる
  1. 目的
  2. インプット（情報・材料・ツール・スキル）
  3. 成果物（完成物・完了状態・期限・提出先）
  4. 関係者（巻き込むべき関係者・協力者、インプットは誰（どこ）から入手するか、成果物は誰のためか）
  5. 効率（スピード・生産量・コスト・人員・不良率）

また、サービスレベルについても思い当たるところが多くて、思い込みではなく擦り合わせが重要だよなーと過去の辛い時期を思い返していました。ついついあれもこれも自らやっておいて、相手のせいにしてしまっていました。

８．「何を」「どこまでやればいいのか」が曖昧

サービスレベルを設定する
  • その仕事をどんな条件で、どんなレベル（品質・スピードなど）で提供すべきかを設計する
  • 設計したサービスレベルを告知・浸透させる
  • 浸透させるには、「目に見えること」「定期的なリマインド」が不可欠

自分はマネジャーやリーダーの役割ですがメンバーとの調整の場づくりやプロセスの設計・改善をしていかなければと思いました。

はじめに

本当のワークライフバランスとはどうあるものか？ 殆どの企業は、プロセスと場へのアプローチが足りない。

今のアプローチとしては、とにかく対話する時間を増やすこと。デイリーミーティング、ふりかえりを習慣にし、1日数分でもいいので話しかけるようにしています。3〜4年前は雑談も無かったプロジェクトですが、今ではチーム内の対話や雑談もかなり増えています。

10．誰が何をやっているのかわからない

こんな状態になっていないか？
  1. 会話がない
  2. 話しかけづらい雰囲気
  3. 常に時間がない
  4. 他人のやり方を知る場がない

個人でも少しずつ始められる考えや行動なので、自分の職場の問題に向き合っていくに良い本だと思います。手戻りが多いメンバーには報連相のタイミングを細かく行うようフォローしたり、会議やミーティングでの決定事項が忘れられたりしていたので、markdownのフォーマット作ってメンバーに使ってねーと配布しました。

会議のやり方を設計する
  1. 目的とアウトプットを確認する
  2. 出席者を選定する
  3. 議事録を取りやすい発言を意識する（報連相の4つのポイント）
  4. 会議の三本締め「決定事項」「宿題事項」「次回予告」

タイトルの通り「問題地図」であるため、自分の職場の問題を探したり、向かい合った上で歩き方は自ら決めて実行しなければならないよねとも感じました。 次はマネージャーの問題地図を読んでみようかな。

マネージャーの問題地図 ?「で、どこから変える？」あれもこれもで、てんやわんやな現場のマネジメント

マネージャーの問題地図 ?「で、どこから変える？」あれもこれもで、てんやわんやな現場のマネジメント

2018年　ふりかえり

ふりかえり

やってみたこと

個人やお仕事

2018年は何をやるのか（やらないのか）・チームを活かすにはどうするのかを考えた。

  • 4月から色つき星取表・一行日記・ニコニコカレンダーつけるようにした
  • ブログ8回更新
  • 社内にJJUG CCCのレポートを発表
  • Redmineでチケット駆動＋カンバン
  • 1on1を始めた（部下2名）
  • AWSやAIについての社内ワーキンググループに参加

コミュニティ・カンファレンス

前半は結構参加してる。後半は控えめ。学びをお仕事に活かすことができている。

読書

17冊購入、3冊図書館、計20冊。読了したのは12冊。

2018年のベスト3冊はこれ。

www.shoeisha.co.jp

gihyo.jp

www.oreilly.co.jp

家族で

長男が小学校に入学し、長女もそれなりに大きくなったので行動範囲が増えた。

わかったこと

  • ふりかえりのふりかえりは重要
    • ふりかえるためには、記録・測定・データはすごく大事。
    • やったこと・発生したことだけでなく、やってみてどうなったとか感情とかあると良い。
    • ふりかえりのふりかえりができていない。
  • 慢性的にニコニコカレンダーが低い。
    • 睡眠不足。
    • 体調が悪いと怒りっぽく、イライラしている。
  • マネジメントのあり方・考え方が変わった。
    • マネジメントを技術・スキルとして認識し、チームやプロセスを設計する感覚を得た。
    • 視野・視点・視座が初めて広がった感覚を得た。
    • マネージャーという役割を意識するようになった。

次にすること

  • 心身ともに健康
    • 7時間睡眠確保
  • データ収集と見える化
    • 自分、家族、メンバー個人、チーム全体、プロダクト
    • できるだけ楽に収集して楽に見えるような仕組みを作る
  • チームが学びを最大にする活動
    • ふりかえりのふりかえり
    • 1on1
    • 自分がやってきたことのまとめ
  • 好奇心を持つ
    • やってみる
    • 首を突っ込んでみる

Developers Summit 2018 KANSAI に参加しました

devsumi

今回は会社お休みして参加してきました。
同僚二人に遭遇するハプニングありましたが(ΦωΦ)
とても充実した1日になりました。

TD;DR

  • 今年のデブサミ2018関西では「未来をはじめる」というテーマ
  • 自分が取り組む／プロセス改善／アジャイル／クラウド／機械学習／に関連するセッションを聴講
  • 届けたい価値、解決したい問題に向かい合うことの重要さを再確認
  • それを実現するための方法や手段をエンジニア個人としても習得したいし、組織にも浸透させたい
  • （ブログにまとめるのにいつも1週間以上かかってるのなんとかせな。。。）

Mackerelの200週連続リリースの舞台裏とこれから

  • ユーザーにとって価値のある"機能"を毎週リリース
  • ミニマムな状態からスタートし、機能開発スピード自体が価値となる
  • OSS部分もあって、ユーザー（外部エンジニア）によるコントリビュートリリースもあった
    • 【感想】オープンでありとても素晴らしいと感じました。
  • 少人数なアジャイルチームでCI/CDをさらっと実現している（風に聞こえた）
  • 長期タスク／短期タスク／作りおきをうまくコントロールして連続リリースを実現
  • No マイクロマネジメント。自律したチームには余力が必要
    • 【感想】そんなチームを作り・維持できるマネジメントに興味があります。
  • チーム全員が同じミッション・価値を共有してコミットメントする
  • 結果として機能開発スピードの価値が相対的に低下したので連続リリース止めた

改善を重ねるリモートスクラム開発 〜kintone開発の現場から〜

  • スプリント期間を2Wから1Wに変更
    • 【感想】僕も全く同じ理由で1Wスプリントに変更したのでめっちゃ頷いてました。
  • スプリントプランニングで大枠の設計を実施
  • タスクの実施は全員でモブプログラミング
  • バックログリファインメント毎日30分全員で
    • 【感想】僕は週の半ばくらいにまとめて時間をとっていましたが、毎日少しずつというのも試してみたいです。
  • リモート改善について
    • 【感想】「リモート」でのスクラムをどう実現しているのだろうと期待していたため、1スライドに詰め込まれていて少し残念
    • 【感想】もう少し「リモート」観点で深掘りしたお話を聞いてみたかったです（ツールの選定とかなぜリモートやるのかとか）

今日から始める機械学習〜はてなの事例〜

  • 吉田 康久さん [はてな]
  • 3つのタイプ
  • 世間のイメージ　VS　お手軽機械学習
    • 【感想】勇気をもらえます。何事もミニマムスタートですね。
  • アプリケーションエンジニアのメリット
    • データをきちんと見る
    • いい特徴量のありかを知っている
    • 問題解決の手段として使える
  • 汎用ではなく固有・制約を活かす。全部機械学習で解決しようとしない
  • 大事なのはデータ量・特徴量。解決したい問題やドメインをしっかり捉えること
  • 困ったときは
    • Kaggle
    • Machine Learning Meetup KANSAI

意外と知らない？！GitHubの新機能を紹介します

  • 鈴木 順子さん [GitHub]
  • ビジネス向けGitHub
  • 【感想】Git/GitHubの基礎知識からちゃんと学ぼう(´・ω・｀)
    • 【感想】Git/GitHubの何がどのようにメリット／デメリットになってどんなチーム・組織・プロセスにフィットするのか説明できたらなぁ

クラウドネイティブなアーキテクチャを設計する次世代の現場力

  • 北山 晋吾さん [レッドハット]
  • クラウドネイティブ＝クラウドリソースを意識することなく活用できること
  • KubernetesはクラウドのKernel
  • クラウドを活用するために意識を変える
  • クラウドネイティブな設計
    • 柔軟かつ効率的なシステム運用
      • マネージドサービス活用によりカスタム運用を減らす
    • 迅速かつリスクの少ないアプリデプロイ
      • 必ずしもマイクロサービス化が正義ではないがモノリシックは分割する
      • 【感想】マイグレーションについての基礎知識を見ることができて嬉しい
      • サービスメッシュ活用によりアクセスに応じたデプロイ実現
    • 信頼性を維持する運用体制
      • 組織とプロセスの意識改革

Javaを活用したマイクロサービスのためのKubernetes活用

  • 寺田 佳央さん [日本マイクロソフト]

  • 会社・開発者は二極化する

  • すべての企業はソフトウェアカンパニーにならなければならない
  • 「変化することのリスク」「変化しないことのリスク」
  • 技術の見極め・最適化が大切
    • とりあえずマイクロサービスだ！コンテナだ！　はダメ絶対
  • サービスごとにリポジトリは作るべき
  • 並列処理をしっかり理解する
  • 障害は起きる
    • 1個のサービスを切り離して残りの99個を活かす
  • Release It！ 本番用ソフトウェア製品の設計とデプロイのために オーム社
  • HelloWorldレベルは簡単

勝てる「開発プロセス」の作り方 ―そのプロジェクト計画、本当に成功を確信して書いていますか？

  • 岡 大勝さん [ゼンアーキテクツ ]

www.slideshare.net

  • 開発プロセス＝プロジェクトの見通しを立てる
  • プロジェクトの三態
    1. 価値探索
    2. 試行錯誤
    3. 製品化
  • 実現性トライアングル
    1. チーム・環境
    2. テクノロジー・アーキテクチャ
    3. スコープ
    4. 中心にコスト・スケジュール
  • トライアングルを使ってリスクを見る
    • 【感想】「物差しを当てる」という表現と感覚がすごく腹落ちしました
  • ウォーターフォールのメリット
    • 未経験者が習熟しやすい
    • 【感想】ちょっと疑問が残る。プロジェクト期間とかにもよるけど、習熟度合いが早いのはアジャイルかなと思う
    • 【感想】ウォーターフォールをすべての工程通して経験できれば深く習熟できると思う
  • アジャイルとは
    • 暗黙知の再評価
    • 暗黙知を活かすために必要なたったひとつのこと＝「信頼」
  • Work Together

Agile Japan 2018に参加しました　#agilejapan

勉強会 Agile

www.agilejapan.org

会社の支援（参加費＆交通費）を得て参加してきました。 去年の大阪サテライトに参加してアジャイルに触れて、実際に少しずつ始めてみて試行錯誤している状況で実践されている人のお話を聞いてみたいと思っての参加です。

基調講演がとても素晴らしかった！

片やモブプロのお話、片や経営に関するお話にもかかわらず共通した部分があると感じました。

基調講演１（モブプログラミングと”フロー”の力）：Woody Zuill 氏

  • Woodyさんが出した３つの条件
    1. 邪魔するな
    2. 見積りしない
    3. 延期する権利
  • よく問われる「生産性あがるの？」問題
    • わからない！
    • 正しくない問いに対して頑張って答えても意味がない
    • 正しい問いを見つけることが重要
    • 「モブプログラミングは効果的なのか？」としてみる
    • 少し逆から考えて「バラバラに仕事する場合に効果的に働くにはどうしたらよいか？」と問う
    • 今回の内容は氏の体験を紹介しただけであり"あなた"に合うかどうかはわからない
  • モブプログラミングは仕事のフローに対して最適化されている
    • フローについて
      • 個人のフロー
      • チームのフロー
      • リーンフロー
    • フローを阻害するもの
  • 「大事なのはアートを作ることではなく、自然にアートを作れる素晴らしい状態にいること」

氏の講演については、及部さん（@TAKAKING22）のレポートがとても参考になります。 takaking22.com

基調講演２（JapanTaxiの挑戦）：川鍋 一朗 氏／漆原 茂 氏

  • スマホの普及によって起きた変革
    • 黒船襲来（Uber）
  • 日本交通の社長->JapanTaxiへフルコミット
    • エンジニアと目線／ゴールをあわせる
    • エンジニアがパフォーマンスを出せる環境を作る
    • ビジネス VS エンジニアになるのではなく両方大事。リスペクト重要。
    • トップは言い続けなければならない
  • 相乗り実証実験
    • やってから謝るのは日本文化では難しい
    • 政・民・官のバランスをとって新しいルール・イノベーションを起こす
  • グローバルローミング
    • 全国タクシーを海外で利用可能に
  • 電子決済
  • コラボレ－ティブモビリティ
    • タクシーのUI/UX
    • ライドシェア
    • 移動データ
      • 位置情報
      • IoT
      • 画像解析
      • センサ
      • 自動運転

氏の講演については、木下さん（@fkino）の記事にとても共感しました。
Agile Japan 2018 川鍋氏の基調講演に思ふこと

Whyで思い出せた原点

今回のテーマである「Why Agile?」に向かい合うことができ、アジャイルに取り組んだ一年間のふりかえりになりました。

Why Agile?〜Whyからはじめるアジャイル〜：森 一樹 氏

  • 100人超のワークショップをタイムボックスを守りつつ完遂されているのが凄い
  • ゴールデンサークル（えんたくん）の距離感が絶妙
  • 同じような悩みをもつ人同士で話すことで勇気をもらえる
  • 共有によってフィードバック（緑の付箋）がたくさん貰えたのがとても嬉しい！
  • 最後に挙げたWhatは、「よくあるWhatだけど実現は難しいもの」だったので、少しずつ良くしていきたい！

開発プロセスだけ「アジャイル」で良いの？～アジャイル導入で変わった人・組織・世界～：株式会社アプレッソ（土岐 拓未 氏／野村 俊介 氏／伊藤 真仁 氏）

  • be Agile
    • 「あなたは、どう組織を変えましたか?」
    • 情報の共有ではなくプロセスを共有する
  • バーチャルチーム
    • チームが機能する可能性を上げるよう働く
    • SpotifyモデルのGuild
    • 機能横断型チーム
  • WoWゾーン
    • WhatとHowの中間（造語）
    • プロダクトオーナーは、What。スクラムマスターは、How。
    • What/How判断に時間がかかるとPO依存→POがボトルネックになる

単に知識を得るだけでは足りない！ 組織で取り組む体系立った理想のアジャイル人材育成とは？：渡会 健 氏

チームワークとしてのアジャイル -強いチームの作り方-：倉貫 義人 氏／仲山 進也 氏／天野 祐介

今のチームについてどのような状態にいるのか改めて考えるきっかけになりました。フォーミング体質は抜けきらないですが、少しは変われていると思います。
仲山さんのジャイキリ本買いました！

f:id:msts0w0:20180727085138j:plain

  • Q：チームとは
    • 天：共通の目的を持ったメンバーの集合
    • 倉：気軽に雑談できること
    • 仲：グループからチームに変わる。ジグソーパズル。70点→赤点→120点。
      • チーム成長ステージ
        • フォーミング
        • ストーミング
        • ノーミング
        • トランスフォーミング

f:id:msts0w0:20180727085203j:plain

  • Q：チームメンバーで意見を言わない人がいたらどうすればよいですか？
    • 倉：言いやすい場かどうか。人数を絞る（最大４人まで）
    • 仲：フォーミングを進めるだけ。
  • Q：アジャイル導入。何から始める？
    • 天：コーチから学ぶ
    • 倉：バズワードから入らない。
      • 実践させて、効果を見せてから、実はとネタばらし
      • 新卒から育成。それが当たり前にする
    • 仲：誰か一人が指揮命令するのではなくみんなでやる。
  • Q：雑談を無駄だというメンバーに対して
    • 天：雑に雑談していないか？
    • 倉：報連相よりも雑相。何を無駄と感じているか。
      • きっかけとしての雑談はチームのパフォーマンスあげる
      • 評価をやめたら「できないこと」の共有が進んだ
    • 仲：フォーミング状態へ戻りやすい（メンバー増減、やることが変わったり）
      • フォーミングを進めるためにも雑談は必要
  • Q：アジャイルに変える必要性を聞いてくる上司
    • 倉：やり方が上手くいっているのであれば帰る必要はない
      • 上手くいっていないのであればありのままを伝える
      • それでだめなら転職
    • 天：上手くいく方法を探して結果としてアジャイル

まとめ

とても充実した1日でした。モダンアジァイルの原則の中に「人々を最高に輝かせる」とありますが、まさに誰もがやりたいこと・目的に向かってキラキラしていました。
僕にとってのWhy Agile?は「人々を最高に輝かせる」ためです。

  • 楽しく働きたい
  • 成長するチームを作りたい
  • 家族の笑顔を増やしたい
  • 越境に挑戦する
  • 仲間を見つける

Scrum Boot Camp OSAKA in June 2018 に参加しました

勉強会 Agile

参加のきっかけ

2017年のAgileJapan大阪サテライトでアジャイルに触れて、今の業務でスクラムを取り入れて半年くらい経ちました。 スクラムガイドや本の知識だけで突き進んで来たので経験者の知見をきちんと学びたいと思い参加しました。

タイムテーブル

  1. オープニング
  2. スクラム概要（座学）
  3. スクラムイベント体験（ワークショップ）
  4. ふりかえり・問題解決
  5. ビアバッシュ

丸一日かけてスクラムを体験できます。ワークショップによる体験が中心のため、色々とメモを取っていたのですがネタバレすると体験による学びが減ってしまうので割愛します。

気づき・学び

  • タイムボックスを意識すること
  • メンバーとの認知共有の難しさ
  • 言うは易く行うは難し
  • スプリントレビューとふりかえりを混同しないこと
  • スクラムへの適性はスキルの高さよりも意欲の高さ
  • 講師陣の問題を解決する・学びを得ることへの意識の高さ・貪欲さ
  • おやつ大事
  • とにかく楽しい！
  • ストロング0はヤバイ

フィードバック

得た学びはすぐに業務へフィードバックしました。 チームが集中できる・コントロールできる・リズムができるようにスプリント期間を短くしたり、タスクの粒度を小さくしたり。 少しずつ良くなっているかなと思います。

スクラムガイドにも

スクラムの理論 スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。

とあるように、ビッグバン的な改善はできないし、やろうとすると失敗するのだと思います。

講師の方々へ質問した時も当事者（私）のコンテキストをとても気にされていました。チームの状態を観て、何が課題か・何を解決するのかを明らかにしながら、少しずつ良くしていきたいと思います。

おわりに

それでも困った時、悩んだ時は相談したいです。