【勉強会メモ】スクラム道関西 第117回オープン・ジャム
- 日時： 2019/02/12(火) 19:00 〜 21:00
- 場所：株式会社ラクス 大阪オフィス
いつもお世話になっているスクラム道関西のオープンジャムを弊社にお招きすることになりました。昨年秋にオフィスが移転してイベントができるスペースができて、駅からの近くなったのでいつかこのようなイベントに使ってもらえるといいなと思っていましたが、こんなに早く実現できるとは思いませんでした。 今後もタイミングが合えば利用して頂けると嬉しいです。
今回のテーマはこちら。
品質管理
- 品質検査、カバレッジ、エビデンス取得など社内ルールが厳しい会社がある
- 社内基準を満たすためにはやることが多くスプリントの枠組みで終わらせるのは難しい
- スプリントでまとめて作ってまとめてテストしてしまうとミニウォーターフォールになってしまう
- 出荷前に社内基準に合わせた作業を行うリリーススプリントというやり方もある
- 出荷可能な状態を維持することを考えるとスプリントごとに社内ルールに合わせるしかない
メンバー増やす時の注意点
- 同時に増える場合も少しずつ増える場合も9人以上は厳しい
- 増員が頻繁にある会社でも一度に2人までにして、3ヶ月は間隔をおくようにしている
- 増えたメンバーの立ち上げが大変
リファインメントで毎回同じことを話してしまう
- 定期開催しているリファインメントで既に開発T内で合意済みのことを再度議論してしまうことがある
- 定期的な開催をやめて日々少しずつリファインメントしてみたら良いかもしれない
- POが議論に絡めているか？
- 何度も議論になるなら誰かが合意事項に納得できていないのかもしれない
レビューが通らない
- チームの熟練者から必ずレビューの差し戻しを受ける
- 何度か差し戻されたらペアプロ、モブプロに切り替える
- 品質に影響がない内容ならいったんレビューは通して後日モブプロでリファクタリングする
- 熟練者の知識・知見を共有することが大事
- 答えを教えると身につかない、何度も教えることになる
- 自分で気づいて学ぶまで時間を与える教育法もあるが時間がかかる
- 時間を与えても学べるとは限らない
- 時間を与えた結果意図しない方向に学習が進むかもしれない
- 時間を与えるよりも、何度も教えるほうが結果的には早く学習するのではないか
ドキュメントの残し方
- 社内ルールが厳しく残さないといけないドキュメントがたくさんある
- 監査のために必要で作らないわけにはいかない
- 会社によってまちまちで、なるべく作らない会社もある
- 特にルールは決めていないが知識の共有のために最低限必要なものはドキュメントを作る
- 新しいメンバーなど、引き継ぎのためにドキュメントは必要
- 新しいメンバーが必要なのがドキュメントなのか？知りたいことが分かればドキュメントでなくても良いかも
スクラムでやる場合の予算をどうやって見積もるか？
【勉強会】Scrum Masterの現場
- 日時：2019-02-08（金）19:30 - 21:30
- 場所：MonotaRO 梅田オフィス (ハービス大阪6F)
スクラムマスターをテーマにした勉強会というのは今まではあまりないテーマの気がします。アジャイルやスクラムが世の中に浸透してきて関心が高まっているのを感じました。
2つのセッションとも、スクラムをやりたいという想いはあるものの、実際にやってみると様々な課題に直面し、チームをうまく巻き込みながらより良いやり方を模索してきたことが非常によく伝わってきました。また、結局はスクラムの原則にある目的を理解して正しく実践していくことが大事であることを学びとしていると感じました。
ちなみに、スクラムクイズは私たちのチームも実践していますがスクラムに取り組むチームの成熟度を上げていくには良いプラクティスだと思います。
スクラムマスターとは
@yohhatu さん
導入として以下のような書籍やサイトが紹介
0から始めた！スクラム導入から今日まで～初心者スクラムマスター奮闘記～
www.slideshare.net
スクラム導入
どんな想いで広めますか？
1度目
- 憧れ
→思いが弱く、広め方もわからず、メンバーの入れ替わりで自然消滅
2度目のきっかけ
- 現プロセスの課題⇒ユーザーに寄り添った開発
- ビジネス感覚を持ったソフトエンジニアを目指す⇒PDCAのCAを強化
- 同じチームでも知らないことが多い⇒チームで成長
- 憧れ
情熱と目的を持って広めていく⇒エバンジェリスト
どうやって詳しくなるか？
- 本を読んでも今の自分にぴったりな答えは書かれていない
- 経験がないと課題にも気づけない
経験豊富な方々の意見を聞きにいく⇒社外コミュニテイ
- 同じように頑張っている人と話せることで勇気をもらえる
どんな方法で広めるか？
勉強会の開催
- 月1開催を半年間
- 対話しやすいように少人数
- 内容
- ポイント
- 自分ごととして考えられるように
- 参加者もアウトプットする場
- 忙しい時間を割いていただくので感謝を忘れずに
まとめ
- エバンジェリストとして
- 広めるためにはフオロワーが重要
- 社外にも目を向ける
- 勉強して終わりにしない
- 対話の時間を設ける
- やろう！とはならない
- 実験しよう→やらないとわからないことも多い
スクラム実践
スプリント
目的を理解する
スクラムクイズ
例題
忘れる頃に質問することで記憶に定着⇒目的を再認識する場
- スプリントレビューの目的は？
- 答える
- あれ？できていないね？どうしたらできる？
効果が出た点
- 透明性が高まって自己組織化が進んだ
- プランニングで作業漏れを予防
- プランニングで認識のズレを修正
- 負荷の偏りの把握
- 成果物の価値について意識が高まる
- プロダクトバックログの順序によって価値を考慮
- 定量的なデータが取れる
- ベロシティでこなせる量が把握できる
スクラムマスターの力不足だった点
実感したこと
- スクラム自体は何も解決しない
- 支援は難しい
- 色々な経験がないと支援は難しい
スクラムガイドは忠実に
- 今のプロセスに合わないからといって一部でも変えるとそこは失敗する
- 目的が大事
今後
- 開発全体を巻き込んだスクラムにしたい
- そのためにも今を徐々に良くしていく
3年間の失敗から学んで、やっとスクラムに向き合う準備ができた話
遠藤 良さん
スクラムと出会い、「うまくいかない」を繰り返して 価値観やマインドはどう変化した？
経歴
こんな価値観
- 計画主義
- 計画通り終わらせる
- リソース効率
- 人月工数
- 費用対効果
- 指示に従う
Ep.1 プラクティスに出会う
- 新しい環境への期待
- いままでの価値観
- はじめてのWeb業界
上長から
- チームをまとめてみようか
- プロジェクト計画
- 取締役会で説明しよう
- ふりかえりやってみたら？
- 看板作ったら？
- 計画は更新すればいいから
不安
- 新しいプラクティス
- 中途のプレッシャー
- 新しい環境への期待
中途のプレッシャー
↓
今までの価値観→増
- 過去のやり方を踏襲
- MTGの時間は増加
- パフォーマンス低下
（うまくいかないぞ…）
銀の弾丸はなかった！
（価値観を変えていかないと失敗する）
Ep.2 POもSMもいないチーム
運用チームリーダー
- 大量の残タスク
- 着手中タスクだらけ
- 常に割り込み発生
上長から
- 1週間スプリントでリズム作るといいよ
- バックログ運用してみたら？
- スプリントレビューは参加するよ
⇒今度こそスクラムだ！
- PBI…SpreadSheet、Jira
- スクラムイベント…ふりかえりを定期的に実施して改善
- プロセス改善…現実をみた上で改善
現実
- これ、最終誰が決めるの？
- お客さんに言われたのでやってください
- これはｘｘさんタスク
（これがアジャイル？チーム開発？）
Ep.3 学びを捨てたスクラムチーム
上長から
（スクラムマスターがんばるぞ！）
- リリースは10ヶ月先
- POはスクラム初心者
- 毎回スプリント完了しない
ドン勝！
- スプリントを完了できるチームに
- スクラム理解も深まる
- 順調にアルファ版リリース
実際
- POがスコープ削ってくれるでしょ？
- やってみないとわからないけど一旦オッケー（プランニング）
- ベータ版リリースを乗り越えよう
（まあスプリントは完了しているし…）
- POとの対立
- リリース直前トラブル
- 燃え尽きるチームとPBI
現実
- エンジニアのSMを0.5借りられない？
- 社外コミッターの皆さんに協力してもらおう
- 今週の土曜だけがんばりゃリカバリできそう
結果
- 便利な人
- SMがハンドリング
- 毎週土曜出勤
何がまずかった？
気づいたら開発メンバーの仕事をしていた
「チームは何を学んでいるの？」
- 不確実性に向き合ってる？
- 何を学んだ？
- チームの認識あってるのかな？
- チームはどうありたいの？
エピローグ
こんな価値観に変わった
- 実験してみよう
- 行動からチームが学ぶことが大切
- ユーザー価値
- チームの中だけに目を向けない
- あるべき姿
- どうありたいか？の最初の問いかけ
試してみることに失敗はない
- デイリースクラムに集まらない⇒怒ってみる
いまやるべきことに集中するための場をつくる
チームが変わるきっかけを一緒に探す
- 2チームに分かれてふりかえりして発表
- 心理的安全性ゲーム
【勉強会メモ】関西Node学園 5時限目
- 日時：2019/02/01(金) 18:40 〜 21:00
- 場所：サイボウズ株式会社 大阪オフィス
いつの間にか5時限目のNode学園。関西も回を追うごとに盛り上がっているように感じます。最近あまりこの領域の技術に関われていないので付いていくのがやっとというか、なんとか食らいついていますが、ハッシュタグ #kng5 を追いかけるだけでも、とても勉強になります。
Design Mistakes in Node & Deno
@shisama_ さん
Node.jsの設計ミスを設計者自身が改善しようとしている
※参考
yosuke-furukawa.hatenablog.com
Deno
TypesScriptをV8で実行
- トランスパイルする必要ない
- TSファイルを直接実行できる
- 実行時にDenoがビルド
ES Modulesによるモジュール解決
- CJSではなくSDMを使ったmoduleローディング
- package.jspn不要
- importでインターネット上のリソースを読み込める
Secureな実行環境
- 安全でない環境では実行できない
- 実行オプションをつける
- 許可しなかった場合はパーミッションエラー
Node.jsからの改善
- Node.jsはCallbackベース
- DenoはPromiseベース
Deno Core
- Privilgedな領域とUnprivilegedな領域がある
3つのレイヤー
Deno for Users
まだ試行段階
TypeScriptとVue
@Daikids2 さん
vue-cliはdeprecatedになった→@vue/cliを使う- TypeScriptとscssを選べる
TypeScriptのサポート
Class-Style ComponentでTypeScriptそのものの型が使える
Callbackを撲滅した後に ~ Promise化だけでは終わらない
@Ajido さん
↑Promiseを撲滅した後に残った課題の話
CallbackとPromiseのインターフェースを両立させる
- Callbackを省略した時にPromiseが返る→オススメ
- 段階的なPromise化が可能
- 将来的なCallbackの廃止
- Promise型のモジュールを返す
- ライブラリを一気にPromise化する必要がある（段階的にできない）
- メソッドチェーンからPromiseを返す
.promise()
- Suffix月の関数からPromiseを返す
- 実装が楽
- 互換性への対処が難しい
性能
- パフォーマンスを計測→現時点ではCallbackが最速
- async/awaitはPromiseよりも速くなる
- V8 7.2以上ではawaitの仕様変更に伴う最適化
- Node-v12に入るかも
現代的なフロー制御は高速なのか？
- async/awaitはNodeのバージョンアップに伴い速度が向上
- 速度はCallbackに迫りつつある
- Promiseよりもasync/waitを
- async/awaitを使うならメジャーバージョンアップは積極的に
ストリーム対応
Streamをフロー制御にどう組み込む？
- Streamとフロー制御は相性が悪い
- Streamのエラーハンドリングは独特
- EventEmitterのエラーハンドリングは独特、ハンドリング漏れはクラッシュにつながる
AsyncIteratorを使ったStreamのフロー制御
- ES2018の新機能
- 統一的なエラーハンドリング
エラー処理
非同期処理のスタックトレースはどう見える？
- 課題1
- 呼び出し元エラーの発生箇所が特定できない
- 課題2
- awaitで中断した関数はマイクロスタックキューから処理
課題への対処
ブラウザで使えるnpmライブラリ
@mochiya98 さん
Asynchronous Modle Definition
- CommonJS
- サーバ向け
- nodeでお馴染み
- ES Modules
- ECMAScriptに組み込まれたWeb標準
- import/export
- 従来型
<script>
- 全部のせ
- 1つのファイルでAMD、CJS、従来型として使える
- ESMは構文だから古い環境への互換性を失う
- 基本的にmain
- ESMを活用するツールはmodelを見てくれる
- mainにUMD、moduleにESMを指定
{
"main": "hoge.umd.js",
"module": "hoge.esm.js"
}
Managing multi-package repositories
@kamiyam さん
www.slideshare.net
Lernaについて
gitとnpmを使ってマルチパッケージリポジトリを管理するワークフローを最適化するツール
※参考
モノレポ化
- メリット
- 依存関係がある複数レポジトリ管理
- モノレポ内で共通モジュールを作成
- packages以下の各プロジェクトをそれぞれ独立してnpm publishすることも可能
- デメリット
- コマンドが若干煩雑
- ファイル構成が大きくなる
- デプロイ（公開モジュールが複数あるなど）
始め方
$ npm install $ lerna init
package以下にプロジェクト配置
- packagesフォルダの下に各プロジェクト
- その下にpackege.json
管理モード
- 固定モード
- 独立モード
モードの違い→packages以下の管理バージョンを固定/独立選べる
$ lerna add xxxx →基本 npm installは使わない
--scope で対象プロジェクトを絞る
各プロジェクト間の依存モジュール
$ lerna add @others --scope xxx
モジュール全体
$ lerna run xxxx
各モジュールの依存関係を解決
lerna bootstrap
たまにモジュールのロードがおかしくなる
$ lerna clean $ lerna bootstrap
- 導入は難しくない
- 大規模開発環境を細かくbuild/publish
分散データの基本
Node.jsで分散ストレージ
同じデータ？
- ハッシュする
- 正しいファイルであることと誰が開発したかがわかる
Buffer.compare()
繋がりがなくなったら？
- IDをつけたほうが良い
crypto.randomBytes(32)
分散する
bitfield- ブロック単位でどれを持っているかわかる
bitfieldは3種類、メモリの使い方などが違う
すべてのブロックが揃っているかをどうやって確認する？
- ハッシュをつける
- 順番が確認できない
- 前後のブロクのハッシュからハッシュを作る
- さらにそのハッシュと次のハッシュでハッシュ→回帰的に
- 正しい順番かどうかを確認できる
merkle-tree-stream
誰が情報を更新したか？
- publickKey, privateKey
- signatureを作る
hypercoreというモジュールがある
- これらすべてのことができる
※参考
【勉強会メモ】Mix Leap Joint 特別編 - スクラム道関西 第116回オープン・ジャム
- 日時：2019/01/29(火) 19:00 〜 21:30
- 場所：ヤフー株式会社 大阪グランフロントオフィス
いつもお世話になっているスクラム道関西のオープン・ジャムが、これまたいつもお世話になっているYahooさんのMix Leapとの共催で行われました。 今回は参加者多数ということもありオープン・スペース・テクノロジーという方式で、参加者同士で出し合った課題を議論しました。あらかじめ参加者が出し合った複数のテーマごとにグループをつくり、参加者は好きなグループに参加してディスカッションをする方式です。
今回は4つのグループに分けて30分×3回議論しました。
私自身が議論に参加したものはメモを追加しています。
見積もりのメリットとデメリット
ペアプロやろうぜ
ワーキングアグリーメント作ってますか？
- チームの状況が変わってもルールが更新されず放置されている
- チームとして大きな問題になっているわけではない
- チームが安定しているので問題になっていないだけで、メンバーが変わると問題になるかもしれない
- 下記のようなルールはワーキングアグリーメントではなくDoneの定義に入れている
- PBIをリファインメントしてReadyにする手順
- POレビュー前にするテストに関するルール
- Doneの定義はスプリント計画のたびに見直し
- ワーキングアグリーメントに追加することでチームが安心して仕事ができるものもある
- 昨年の災害が多い時期に「災害で仕事に集中できない時は自己判断で作業を中断しても良い」というルールを作ったことでメンバーが安心して仕事できるようになった
- メンバーが変わった場合、ワーキングアグリーメントを更新するのではなくゼロから作り直しても良いかもしれない
割り込みが多い！どうする？
チームの技術的意欲の向上
- メンバーがすぐに質問に来て自分から学ぶ意欲があまり見られない
- 意欲が高く知識のあるメンバーに負荷が集中
- ふりかえりで話し合ってみる
- 社内で勉強会をしてみても良いかも
- ペアプロやモブプロをしてみる
- 質問する方もある程度知識が必要で理解に繋がる場合がある
スクラムの開発メンバーの人事考課について
チームに新しい人がどんどん入ってノウハウシェアが大変
- チームメンバーの入れ替えが多い
- 古株と新人をペアにしたペアプロを行ってみる
- モブプロも良さそう
- 定期的にノウハウを共有するストーリーをバックログに追加してスプリントで実施する
- チームで共有するドキュメントをメンバーに割り当てて手順を実行できるか、理解できるかを確認する
- ドキュメントがどこにあるかわからない
- 新しいメンバーがドキュメントを自分で探せるか、自己解決できるかも一つの判断材料
スクラムを学びたい人が少ない
ほか
以下は写真を撮り忘れましたがテーマだけ紹介します。
次回
次回は2/12です。なんと、弊社で開催することになりました。お声がけ頂き光栄です。会場提供だけではありますが、たびたびお世話になってるので少しでも貢献できて嬉しいです。
【読書メモ】リーダー論
- 作者: 野村克也
- 出版社/メーカー: 大和書房
- 発売日: 2013/07/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
最近、スポーツのチームマネジメントに興味を持つようになって色々読み漁っています。野球が多いのは完全に自分の好みによるものですが。
この手の本を読むならノムさんは欠かせないだろうということで読んでみたのがこの本でした。ノムさんの書籍の中では比較的新しいということもあり、読みやすくてあっという間に読むことができました。
プロフェッショナル集団を率いるリーダーに必要なもの
ほんとうのプロフェッショナル集団を率いるリーダーに必要なのは、技術力やすでに持っている能力を超えて闘いを挑むための知恵なのである
プロフェッショナルであるなら何よりも「知力」を重視する必要があるとしています。プロフェッショナルは専門家なのでその仕事の深い知識を持っているのは当たり前であり、プロフェッショナルを束ねるリーダーは部下を圧倒するだけの知識や理論を持っていなければならないと述べています。これはエンジニアに置き換えても同様の事が言えます。プロフェッショナルとしての知識や理論を持ち、「知力」を使ってエンジニアが納得できるビジョンを示すことがエンジニアのリーダーに求められると言い換えることができるのではないでしょうか。
また、決断をするか否かが監督とコーチの根本的な違いであり、リーダーは判断力だけでなく、決断力も持たなければならないと述べています。
判断が正しかったとしても、決断しなければそれは絵に描いた餅にすぎない
決断とは一種の賭けなのである
瞬間的な決断を求められるのがチームのリーダーなのです。
一方で、チームを発展させるうえで欠かせない条件のひとつに「未来想像力」という言葉をあげています。これはチームの将来あるべき姿を明確にイメージし、具体化していく能力のことです。
チームを発展させるために行う監督の仕事を以下の3つに分類しています。
- チームづくり
- 人づくり
- 試合づくり
中でも「人間教育」こそが強い組織のもととなると述べています。
人間を磨かなければ、すなわち思考を変えなければ、進歩も成長もない
技術だけを磨くことには限界があります。思考は行動を決めるため、意識を変えることで日々の過ごし方や仕事に対する取り組み方が変わり、仕事の質が高まるということです。これもエンジニアに置き換えると自己組織化やメンバーとのメンタリングに繋がるマネジメント論に置き換えることができるのではないでしょうか。
ドラッカーの『マネジメント』に通じる理論
P.F.ドラッカーは『マネジメント』の中でマネジャーの役割は次の2つだと言っています。
![マネジメント[エッセンシャル版] - 基本と原則](https://images-fe.ssl-images-amazon.com/images/I/41AY8WEF74L._SL160_.jpg "マネジメント[エッセンシャル版] - 基本と原則")
- 作者: ピーター・F・ドラッカー,上田惇生
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2001/12/14
- メディア: 単行本
- 購入: 210人 クリック: 8,094回
- この商品を含むブログ (433件) を見る
- 投入した資源の総和よりも大きなものを生みだす生産体を創造すること
- あらゆる決定と行動において、ただちに必要とされているものと遠い将来に必要とされるものを調和させていくこと
ノムさんのリーダー論はドラッカーにも通じるマネジメント論であると感じました。
リーダーは「未来想像力」を持って人を遺すべし
最後は以下の一文で締めくくられています。
その人のもとからどれだけの人材が育ち、羽ばたくことができるか。その人のリーダーとしての価値は、最後はそこで決まると言ってもいいのではないだろうか
技術と知識で専門性の高い成果物を生産するのがプロフェッショナルであり、プロフェッショナルを継続的に生産する仕組みをつくるのがプロフェッショナルな組織のリーダーであると言えます。
