勇気を出して、自分から一歩踏み出そう。笑顔で、ね！

私へ

「チャンスもハッピーも待ってたって来ないよ」
ようやく、そういうコトがわかってきたんでしょう？
なら、行動しなきゃね

勇気を出して、自分から一歩踏み出そう。笑顔で、ね！
冒険しよう。やっぱ楽しく、ね！

『笑っちゃいな　わっほーわっはー』


この記事は、@viva_tweet_xさんに影響されて書きました。
「私、能力は平均値でって言ったよね！」OPテーマ「スマイルスキル＝スキスキル！」の歌詞は、今の私には刺さりまくりで読むと泣けてくる
qiita.com

歌詞付きのフルバージョンのMVが公式で公開中
2020年1月1日から1週間限定公開らしく、あと2日くらい！（記事執筆時点）
www.youtube.com

もし限定公開が終わっても、TVサイズ版のMVが公開中
www.youtube.com

私、能力は平均値でって言ったよね！ オープニングテーマ「スマイルスキル＝スキスキル」

私、能力は平均値でって言ったよね！ オープニングテーマ「スマイルスキル＝スキスキル」

気持ちよくアウトプットするためのメモ

著作権やそれに類するものに配慮して、気持ちよくアウトプットしたいと思うものの毎回調べているため、メモしておく

楽曲の歌詞

はてなブログやFacebookは、JASRACと利用許諾契約しているため、JASRACで管理しているものを利用できる
例えば、TwitterやQiitaはしていない
利用許諾契約しているサイト一覧
https://www.jasrac.or.jp/info/network/ugc.html

あくまでJASRACで管理しているものだけであり、すべての楽曲の歌詞を利用できるわけではない
例えば、JASRAC以外にもNexToneという団体で管理されているものもある*1
JASRACで管理しているかを確認できる検索サービスがある。
ただし、「JASRACのサイトに乗っている＝はてなブログで利用できる」ではない
利用用途についての権利をJASRACが管理しているか（どの権利を委託管理しているか）がポイントであり、それは検索サービスの詳細で確認できる
一部の権利はJASRAC、一部の権利はNexTone、一部の権利は委託管理しておらず、著作者に直接確認が必要なケースもある
参考FAQ：作品検索(J-WID）に載っていれば、JASRAC管理作品なんですよね。 | OKBIZ

画像

ブログ、スライドで利用できるもの

困ったら@TAKAKING22さんのまとめを参考にさせてもらっている
qiita.com

いらすとや
注意：商用利用の場合、無償利用できるのは20点まで。21点以上は有償。

Generated Photos
AIで自動生成された実在しない人の顔写真
無料で利用できるが、リンクの掲載などは必要らしい（要確認）

マンガのコマ

出版社や作者に許可をとったマンガのコマが掲載されていて、ブログに埋め込み利用できるサービス「アル」
kensuu.hatenablog.jp
alu.jp

ためしに使ってみる

かぐや様は告らせたい〜天才たちの恋愛頭脳戦〜 / alu.jp
alu.jp

本の書影

どうすればいいの？？
どなたか教えて下さい

*1:2020年1月現在NexToneと包括契約しているのは、Youtubeだけにみえる

NGワード集

つい、使ってしまうから言語化した

「NGワードを使わない」こと！！

コンセプト

1st.

私と他の人で「言葉の意味」の認識のギャップがありやすいと感じる
共通認識の「阻害を促進する」モノ

2nd

相手が使っている時に「どういう認識で使っているか」を注視する
相手の認識を理解する
相手と私の理解の差分を認識する

「認識が合う」と思ってきたら、要注意
少しのずれに気付きにくい
私が「他人を理解できるなんておかしい」

3rd

他の言葉を使って、説明できるようになる
理解の解像度をあげる

NGワード集

NGワード

アジャイル
スクラム
DevOps
レトロスペクティブ
デイリースクラム
スプリント
イテレーション
心理的安全性
共感
マイクロサービスアーキテクチャ
SRE

NGワード(言っちゃいやすい)

朝会
カンバン
ペアプロ
モブプロ
CI
オンボーディング

NGワードにしたいけど、代替がない

ふりかえり

悩み中

マトリクス組織
ティール組織
見える化

よくわかってないけど、言わないほうが良さそう

DDD
クリーンアーキテクチャ

未だに意味がわからない

CI/CD

「自分の弱点を自分の技術でカバーできると思っている選手がいると、チームはうまく機能しないんだよ」

アニメのあひるの空を見ていたら、マネージャーのセリフが心に刺さった。

ゾーンディフェンスやスクリーンに絶対必要なものは、互いをカバーしあえる信頼関係でしょ？
自分の弱点を自分の技術でカバーできると思っている選手がいると、チームはうまく機能しないんだよ
このチームが勝つために必要なのは、個々が自分の弱点をしっかり受け止めて、それを支え合えるチームワークを作ること
チーム(TEAM)に”I(アイ)"、自分というスペルはない。
バスケットの基本だよ

そのあと

あー、またやっちゃった。
ちょっと力試しすればいいだけだったのに。
マネージャーが部員のやる気を削いでどうするのよー

帰り道に一人で反省しているマネージャー。見習いたい。

Spring Fest '19講演メモ「Reactive Spring」by Josh Long

springfest2019.springframework.jp

Josh Longさんの3時間コースのメモ。
とてもおもしろいセッション。
「美しい」と感じるライブコーディングを生で見たのは、はじめてかもしれない。
もう一度見たい内容。
ちなみに、英語で日本人を笑わせていているのすごい。

タイムテーブルから講演者のプロフィールを引用

Josh (@starbuxman) is the Spring Developer Advocate at Pivotal and a Java Champion.
He's host of "A Bootiful Podcast" (https://soundcloud.com/a-bootiful-podcast),
host of the "Spring Tips Videos" (http://bit.ly/spring-tips-playlist),
co-author of 6+ books (http://joshlong.com/books.html),
and instructor on 8+ Livelessons Training Videos (http://joshlong.com/livelessons.html).

メモ

  • APIリクエストが増えてきた時に、どう対応するか？
  • 需要が増えてきている
  • 簡単にやるには、今までは水平スケールアウト
  • 他にもオプションがある
  • CPUアイドル状態のアクティビティ多い
    • Input/Outputの待ち時間が多い
    • 本当はもっとコンピューティングできるはず
    • スレッドをたくさん使ってしまっていて、待ち状態になってしまっている
    • スレッドが問題
  • 持っているスレッドを効率よく使うという考え方。
  • Reactiveプログラミングはコンピューティングマルチスレッド
  • スレッドがデータを待っている状態に、他の人が待たなくていい
  • これが理想的
  • nioはjava 1.4 出てから18年経っている
    • 何故これを使わないのか？
    • ひとつは、使いにくい
  • Netty使っている方はいますか？
  • ここでやろうとしているのはリソースの効率化
  • そうなると、ロードバランサを使う
  • JDK9以降にReactiveStream入っている
  • Hibernate Entityがある
  • 1対多の場合、util.collectonを嫌っている
  • java.util.Setを使うと例外をthrowして、カーネルエラーになってしまう
  • そうなると、別のものを使っていく
  • これから改善する
  • ReactiveStreamが全てのものに対応する
  • ReactiveTimeが入っている
  • E2Eのサポートが入っている

Spring Initializr

  • jar or war
    • パッケージの選択肢わからない？
    • もしあなたが過去に急に飛んでしまったとしましょう。
    • その時は、warを利用してください。
    • そうではなく、2019年を生きているならjarを選んでください
    • 私にとっては大事な哲学 jar for all
  • Javaバージョン
    • 13,11,8 この中で正しいのは2つ
    • 私は答えを言いません。ヒントだけ言います。みなさん考えてくださいね。
    • (ここで画面拡大芸)
  • どれが正しくないJavaのバージョンか？
    • 正しくないのは8ですね
  • 8は安定しているが、よくないバージョン
  • あなたが意気地無しなら、Java11を
  • ベストな回答は、Java13
    • 最新版は、高速になってよりセキュア
    • 道徳的に倫理的に優れたバージョン
  • 子供に「Java8を使っている」と言えますか？
  • 言えないですよね
  • 恥だと思ってください
  • 13を使ってください


  • R2JDBC
  • Mongo
  • Mono
    • ReactiveStreamではなくReactiveからきている
    • フローコントールでは、バックプレッシャーとも言われる
    • マーケティングから言葉が出てきたんだと思う
    • 出すのは、Complete futureと同じ
    • 0 or 1
  • Flux
    • 0〜無限まで
    • Infinity Streamにも対応
    • Fluxのコードは9899行ある。
      • これを自分で書くのは大変ですよね？
      • 使った方がいい。
  • “Maki-san”
  • 「これはデモだからです。デモは常にうまくいきます」
  • 深刻なバグ
    • アートワークの無効化は誰も期待していない


  • Netty
  • 効率的な非同期のアプリ
  • RouterFunction
  • 例えば、株価は情報をすぐ知りたい
  • ユーザ数には限度がある
  • ソケット
  • Subscribe
  • スレッドスケジューラ
    • スレッドプール
  • CPUに負荷がかかる
    • 特にSlack
  • デフォルトでノンブロッキング
  • どこでブロッキングしているか知りたいのか
    • Reactor/BlockHound
      • CPUのスレッドをブロックしているものを見つけたら、例外にする
      • ブロックを検出してくれるので便利
  • konichiwa
  • sweet♪
    • (固定マイクから無線マイクに変更)
  • 私はこれからやらないといけないことがあります
    • みなさん、いい人なので失礼かなと思っている
    • 「JavaScriptを書きます」

空と同じ
海と同じ
星と同じ
皆さんとコードと同じでバグと同じ
無限に続く
宇宙の終わりまで続く

ここまで前半

  • セルフィーとっていいですか？
    • 15歳の娘がいる
    • 娘に「彼らは私の話聞いてくれる。あなたは私の話聞かないけど」と言いたい
  • エッジサービスの場合
    • 共通的なサービス
  • Api Gateway
  • RouteLocator
    • プロキシを作る
    • Host Filterでアクセスコントロールかける
  • RequestRateLimiter
  • Principal Name Key Resolver
  • パスワードのエンコーディング
    • BCrypeがデフォルト
    • MapReacitiveUseDetailServie
    • 私がこれをやる時、SpringSecurityの統括者は
      • @rob_winch becomes sad :-(
    • ハードコードされたユーザネームパスワードを使わないでください
    • (デモでパスワードをハードコーディング)
  • X-Rヘッダ
  • 429 Too many Request
    • 429 429 429
  • これまでは、ThreadLocalに依存していた
  • ReactiveTransactionManager
  • R2dbcTransactionManager
  • TrancationaOperator
  • 皆さんが、誰も見ていないところでも絶対やっちゃいけないことをします。
    • コピペです。
  • LBへのコール
    • 有効でなかったら onError
    • EEEK!
    • retryBackoff
  • ハロウィンはアメリカの祝日です
  • サーキットブレイカー
    • 使えるサービスがない場合、そこで止めるといい
    • 継続的にリトライするか、そこで諦めるか選べる
    • 4つくらいある
      • Resilience4j
      • Hystrix
      • Alibaba
      • Reactive Circuit Breaker
  • 仮にエッジサービスとしましょう
    • 依存サービスをコールしている場合、SLAはどうなるでしょう？
    • 実際半分
    • 私なら、デフォルトではタイムアウトは使わない。スケーラビリティがついてこない
  • “I hedged my bet.I put some money on red and some on black in the casino.”
  • Flux first( host1, host2, host3)
    • ３つすべてにリクエスト送って、レスポンスが早いものからとる。他はキャンセルする。これは、副作用がないサービスに限る
    • 副作用がないサービスに限る。
    • Http1 テキスト
    • Http2が解決した
  • RSocket
    • 真なるバックプレッシャーなリアクティブを実現する
    • 常にコネクションを有効にする
    • gRPCに変わる
    • gRPCはコードの生成が必要になる
    • Webソケットはヘッダがない
      • 例えば、トークンを利用できない
    • RSocketはNetflixからFacebookに転職した人が作った
    • ペイロードに異存はありません
    • ダウンストリームのサービス
    • WebSocketは途中で切れない
    • RSocketであればresumeが可能
      • モバイルでトンネルに入ってしまった時
      • RSocketの場合、ポインタを持っているため、再開できる
      • Facebookで、どれだけサーバーコストを削減できるでしょうか
  • Aribaba
    • 組織全部がSpringベース
    • 10年以上そんな感じ
    • 24時間で300億ドル儲けた
    • 6年前に「SpringBoot」
    • 次に「SpringCloud」
    • 一年前に「RSocket」の話した
    • 今多くのサービスがRSocketを使っている
  • ここにクレイジーなチャンスがあると捉えてください
  • KotlinにはCoroutineがある
    • 同期的書けるのに非同期
  • strong.io にYouTube動画がある。70本くらい・
  • Spring MVC
  • WebFluxをTomcatやJettyで使うことはできるが、メリットをフルに使えない
    • エンドポイントはいいけど、大変なのはデータアクセス部分
  • It’s OK
  • Fun!

GDG DevFest Tokyo 2019に参加しました #DevFest19 #GDGTokyo

GDG DevFest Tokyo 2019の講演メモ
tokyo.gdgjapan.org

ML Kit の最新情報/あんざいゆき

「見る」に特化していたため、メモはしなかったのですが、
ML Kitがあれば、機械学習わからない人でもいろいろ作れそうで、すごかった。
動画もたくさんあり、見ていて楽しかった講演。

マイクロサービスの開発とテストファースト/テスト駆動開発/柴田 芳樹

www.slideshare.net

  • 会場にアンケート：テスト駆動開発やテストファーストしてる人は少ない
  • 手でテストしていると、ソフトウェアがどんどん腐っていく
  • 開発費があがる
  • メルペイのマイクロサービス間通信はgRPC
  • 多くのマイクロサービスが同時開発
  • gRPCのAPI仕様をコメントで.protoファイルに書いた
  • API仕様をMarkdownに反映するCIの仕組み
  • 依存しているサービスの振る舞いをテストコードを書く
  • 最初はAPI仕様ばかり書いてた
  • 依存しているサービスのテストの振る舞いを定義できるテストフレームワークを作成した
  • 依存するマイクロサービスをFakeする
  • 外部サービスに依存する部分もFakeにした
    • 例
    • PubSub
    • Slack
    • Googleドライブ保存
  • 外部サービス用APIのソースを追って、ハックして、Fakeにするのすごいw
  • 次は、ゲートウェイ経由でから外から叩くテスト
  • 同時実行など、簡単な負荷テストもする
  • API仕様をきちんと記述する
  • 自分が作ったマイクロサービスのテストをきちんと行う
  • gRPCはFake作るのやりやすかった
  • Q.Webと組み込み、どちらが楽しかったですか？
  • A.組み込み。理由は、技術的難易度の高さ。今は週4勤務や労働時間に上限ある中で、如何に自分の成果を出すかに注力している。

還暦過ぎて、現役の現場エンジニアでコード書いてる。めちゃめちゃすごい方でした。
柴田さん翻訳のfective Java 第3版

Effective Java 第3版

Effective Java 第3版

  • 作者:Joshua Bloch
  • 出版社/メーカー: 丸善出版
  • 発売日: 2018/10/30
  • メディア: 単行本（ソフトカバー）

CloudNative 時代における GKE/Kubernetes ではじめる開発 / 青山 真也

  • 「おうちに手のひらサイズのk8sクラスタある人」はいますか？
  • k8s入門とCloud Native
  • ちょっとGKE
  • （会場に）Docker使ったことある人は多い。k8sを開発環境以上で使ったことある人は少ない。
  • サーバ1000台にコンテナを1個1個デプロイは大変
  • それを解決してくれるのがKubernetes
  • k8sは、Google社内のクラスタ管理ツールのBorgが元になっている
  • 今はCNCFに寄贈して管理している
  • 目的：Cloud Nativeな組織や時代を構築したい
    • 疎結合
    • 回復性がある
    • 管理しやすい
    • 可観測である
    • 堅牢な自動化
    • オープンかつスケーラブル
  • Cloud NativeはKubernetesか？
    • それは「違います」
    • 便利なものだが使えばいいというものではない
  • 疎結合性
    • 例：マイクロサービスアーキテクチャ。個人的にはミニサービスくらいでいいと思っている。
    • デプロイ容易
    • 特定のものだけをスケーリングできる
    • 障害波及を防ぐ。サーキットブレイク
    • マイクロサービスとk8sは相性がいい
  • 管理しやすい
    • Pod(コンテナ)の起動
    • 指定した数のコンテナを「維持」してくれる
    • LBとの連携。ラベルをメタデータとして付与できる
    • 自動的にL4LBを提供してくれる。GKEだと簡単にできる
    • L7LBもManifestで管理できる。証明書もSecretサービス管理してくれるので、書き換えて証明書は登録するだけいい。変更の生合成はk8sが管理
    • クラスタ内部通信は、IPアドレスを隠蔽して、管理してくれる。魔のエクセルからの解放。
    • 外部との通信もグローバルIP、DNS、証明書を自動化する昨日もある
    • k8sは、ネットワークやストレージなどを抽象化して、YAML管理できる
      • 逆にYAMLたくさん書かないといけないデメリットもある
  • 回復性
    • k8sのコアコンセプト
    • 自動回復・セルフヒーリング
    • 「あるべき状態」を維持する機能。リコンサイルループ
    • 状態を監視する機能がある
    • 3ステップのループ
      • Observe
      • Diff
      • Act
    • 例えば、理想がコンテナ3つだけど、コンテナ2つだけを発見する。1つ足りない。1つ追加する。をやってくれる。
    • これは、コントローラと呼ばれるもの。k8sの中に100個くらいある。
    • 今まで、人手でやっていた作業を自動でやってくれる
    • X as a Service基盤の側面もある
      • Platform for Platform
      • k8s上でデータベースやK8Sを動かしたり
      • 小さなクラウドに近いとも言える
      • ただし、使えるなら、クラウドのマネージドサービスのストレージを使ったほうがいい
    • 分散フレームワークとしての一面
    • 特定の事業ドメインに特化した、アプリケーションを作って任せることもできる
    • フレームワークなのでコントローラは簡単に書けることになっている
  • 可観測性
    • メトリクス
    • トレーシング
    • サービスメッシュ
    • ロギング
    • 周辺技術と連携して、可観測性を維持して下さい。あとから考えるので、システム設計
    • 可観測性だけで2時間くらい話できる
  • ローリングアップデート
    • マニュフェストを書き換えて再適用だけで、理想の状態に自動的に持って行ってくれる
    • VMが頻繁に落ちる。そのため、アプリケーション側で、シグタームのシグナルを処理できるように開発することが重要
    • 闇のスクリプトw
  • インフラストラクチャー
    • ビジネスバリューはここで作られるわけではない。オープンなもので作って行くのでいいんじゃないか？
  • k8sのリポジトリ
    • どのバージョンを使うのかを管理しておくのが主流
    • GitOps（とも呼ばれる）。例えば、PRによる差分チェックができる
    • ブランチ戦略を入れると、環境ごとに作ることもできる
    • ブランチの状態＝デプロイされているアプリケーション
    • リポジトリの状態＝k8sクラスタの状態
    • k8sはマニュフェストをベースに管理することができる。
  • スケーラビリティ
    • 水平スケーリングと垂直スケーリング
    • クラスタ自体のスケールはオートスケールの対象外（サーバ台数が自動手的に増えるわけではない）
    • ここでGKE
  • GKE
    • K8sクラスタの安定化
    • ノードオートヒーリング
    • クラスタ自体のバージョンアップ
    • クラスタのオートスケール
    • オンプレの人からすると一番つらいところだった。GKEを使うと任せることができる。
    • K8sの管理をCloudNativeでできる
    • クラスタの安定化
    • ノードオートヒーリング
      • 問題があった場合にまっさらな状態で作ってくれる
    • クラスタのオートスケール
      • GCPが自動的にクラスタを増やしてくれる。特定のアルゴリズムによる計算。何コアのCPU使うなどの事前の設定は必要。
      • ただし、GKEの場合は、自動ノードプロビジョニング機能がある
      • 「ノードの管理を一切しなくていい」
      • メリット：ノードの管理を一切しなくていい
    • GKEは他社のクラウドと比べて3年早くリリースされているため、機能が多い
    • 「K8sはLinuxのように当たり前に普及していく技術になっていく」と言及する方もいる

Perspective of Angular in 2020 / 稲富 駿

docs.google.com

  • 2020年のAngularの話
  • 2019年のAngular
    • 2.0.0リリースから3年経ってどうなったか？
      • あんまり変わってない
      • なぜなら、彼らは3のValueを決めている
      • 常に3つのどれかにフォーカスしているため、変わっていない


  • Googleにとっても簡単には捨てられない、重要なプロダクトになっている
  • 7.x
    • 「Size Budgets by Default」
      • バンドルサイズが一定量を超えた場合、警告やエラーにできる
      • 大きいバンドルにならないように、うまく使ってね
    • Budgets Types
      • Initial：最初に読み込まれるサイズを小さくする。遅延ローディングで解決できる
      • ビルド後のCSSのサイズがコンポーネント単位で大きくないことをチェックする機能もある
    • CDK Drag & Drop
      • 簡単にドラック中のCSSや話した時のCSSを簡単に表示できる
    • VirtualScroll
      • 実際に表示されるものだけを表示する。ブラウザのランタイムを抑えるためだけの提供される
      • CDKを使って簡単に書けるように
    • Bazel Support
      • Bazel：ビルドタスクランナー。スケーラブルのためのビルド技術
      • Googleと同じ環境を提供したいという意志。
      • 今は、既存のAngular CLIと相性がよくない。
      • オプトインでエクスペリメンタルで進行中
      • GoogleはBazelが好き
      • GCP Nextの話での一例。GCPのビルドコンテナ上でAnuglarビルドしてる話があった。キャッシュ使えるため早い。
  • 8.x
    • Differential Loading by Default
      • Traditional Loadingからの変化。
      • 新しいブラウザには、バンドルサイズを削減したものを送る。古いブラウザには今までと同じもの。20〜30%削減
      • 自動的にPolyfillingの追加をやってくれる
      • 型安全にDynamic importが書けるようになった
      • Webpackの人たちが頑張った。
    • Web Worker : Module Worker Support
      • ちゃんと型安全に書けます
    • ng deploy
    • ライブラリの場合はnpmにデプロイすることができる
      • production build問題が少なくない割合がある。本来望ましくない。
      • ng deoloyすると、必ず「ng build -prod」する。これが狙い
      • わざわざ使う必要はないが、新規に採用する場合は使うと良い
    • 2019年はパフォーマンス改善目的が中心
  • 2020年〜
    • 9.x
    • 10.x
    • 11.x
    • Ivy by Default
      • Iny（アイビィー）がデフォルトで入る
      • ng update で自動的に変わる
      • これまでも、機能はできていたが、後方互換性のために開発が遅れた
        • わかってない人向けの説明：中のリファクタリングなので知らなくて大丈夫。
        • わかってる人向けの説明：Angularの動画をみろ。文字媒体は古いことも。動画を見た方が理解できる。
      • ライブラリ作者に対してはIvyは我慢して、10.xからスタートしてくれ
      • 2020年は一年かけてIvyに移行する年
      • 11.xにはIvyしか残ってない
    • CDK Clipboard API
    • CDK TestHarness
      • コンポーネントをテストするための枠組み
      • テストの書き方を大きく変えようとしている。
      • まず、テスト用のハーネスを作る。
      • ページオブジェクトの概念に似てる。
      • 実際書いてみると「あーテスト書きやすいってなる」---コンポーネントのテスト書ける気がしてくる
      • 宣言的にテストをかける
    • Angular official components
      • Package：9.0と一緒にでる
    • Strict Template Type-Checking
      • IvyによってAOTコンパイルが劇的に変わる
      • 型を厳しく検査できる
      • いきなり変わると今までのものがコンパイルできなくなるため、オプトイン
    • 名前が変わったり、書かなくてよくなったりのAPI(?)もある
    • Breaking Changes
      • Ivy がデフォルト
      • AoT がデフォルト(JITに戻したい場合は指定）
      • Type Script 3.6以上
    • 今まではEnterprise利用が多かった
      • 2019年かけて、簡単に軽量に作れるようにした
      • よく使われるアプリをAngularでサクッと作れる世界を目指した
    • これからのAngular
      • よくあるユースケースではない、独自の個々のユースケースに寄り添う
      • For Customer
        • 例えば、Ionic対応を頑張っている
      • 国際化
        • あんまり使いやすくなかった
        • Ivyが入った後、完全に置き換える
        • ランタイムでの翻訳をサポートする
        • タグのテンプレートを使う
      • コンポート単位での遅延ローディング
        • もっとバンドルサイズ減らせる
      • Static Site Generator も動いている
        • 来週α版リリース
    • Project Photon
      • プログレッシブハイグソレーション
        • サーバーサイドレンダリングを究極に推し進めて、必要になるまで、JS実行しない
        • Reactは先に進めている
        • R&D中
  • Growing Angular Values

アジャイル導入はじめの一歩「自転車に乗れるようになるために何をしましたか？」 #agile_hiyoko

アジャイルひよこクラブに初参加しました。
「誰かブログ書いて」って言われたので書きます。
とにかく楽しかった！
agile-hiyoko-club.connpass.com

私は、もちろん「ひよこ」枠参加

LT1：MOON0401さん 「初めてのscrum。初めてのLT」

初LTとのこと！
一瞬で全スライドが終わるという、まさにライトニングなトラブルがありましたが、
おかげで場が和んだかなーと。

ふりかえりで単純接触効果があがったり、
突然変わった管理職を攻略したりと、
いいチームなお話でした。

初LTお疲れさまでした。

LT2：tommykwさん「スクラムガイドの理解を深めるためのeduScrumガイド」

eduScrumガイドの紹介でした。
教育分野用のスクラムガイドがあるそうです。
私は知りませんでした。
スクラムガイドには、書かれていない補足的な説明が書いてあり、
理解を深めるのにいいよーというお話でした。

たぶんこれかな。
eduscrum.nl
http://eduscrum.nl/en/file/CKFiles/The_eduScrum_Guide_1.2_japan.pdf

LT3：TsukuruSaitoさん 「アジャイル導入しくじり先生」

「会話がない。黙々と作業してる」からの成功＆失敗談
「続ける」ことのすごさを感じました。


発表 (メインスピーカー)：TAKAKING22さん 「アジャイル開発の練習のはじめかた」


  • はじめて自転車に乗る時にどうしました？
  • スポーツの世界から学ぶ
  • 練習と鍛錬（トレーニング）は違う
  • トレーニングは練習をやるために補助的にやること
  • サッカーはサッカーをすることでしか上達しない
  • 練習を繰り返し続けることが大事
  • 「上達すること」を練習
  • 経験学習モデル
  • これはまさにふりかえり
  • ふりかえりの４つのポイント
  • 1.受け身をとる
    • 誰かのせいにしない、システム思考
    • リフレーミング。学習、失敗に成功した
  • 2.自分たちで考えて行動する
  • 3.定点観測する
    • 一定期間で見直す
    • 期間を短く切る
    • 4.続けることが大事
  • ふりかえりが上達に必要だと思っている
  • そのチームがチームになってない。
  • やり方じゃなくてチーム自体に問題がある
  • 現実の言語化からは逃げられない
  • 最初からうまくいかないのは普通
  • 個人事業主はじめました。いつでも相談を！

AGILE-MONSTERのロゴかっこいい
ステッカーとかないのかな？

グラレコすごい

f:id:kobase16:20191214011105j:plain

お悩み相談会

各テーブルでいろいろ話しました。

次回のテーマ「小道具」

まさかのです！

テーマ決めの中にあった「ふりかえり手法を知りたい」という方は「ふりかえりチートシート」がおすすめです。
いろんなふりかえり手法が載っていて、目的ややりたいことに合わせた「ふりかえり」を知ることができます。
KPTやYWTだけでなく、たくさんあります。
qiita.com

懇親会も含めて楽しめた良いイベントでした。
参加してよかった。
ありがとうございました！