OmniAICreator/Qiita-1.07M huggingface dataset:
Regional Scrum Gathering Tokyo 2021 Day 1 「なぜ私はチームにい続けるのか。あるいは、エンジニアとしての成長のためのチームの活用について。」

# Regional Scrum Gathering Tokyo 2021 Day 1 「なぜ私はチームにい続けるのか。あるいは、エンジニアとしての成長のためのチームの活用について。」
 
2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/15017
 
# チーム参加してきました
 
[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。
 
# なぜチームに居続けるのか？
##なぜ今のチームに入ったのか
- 2016/8ごろ、情シスでひとりプロジェクトにいた
- 別組織のPOと良好な関係であり、成果は出していた
- ひとりぼっちの良いところ
    - スコープが決めやすい
    - 情報の同期が不要
    - やりたいことに集中できる
- 一人ぼっちの良くないところは、よいところの裏返し
          
レガシーな技術ばかり触る状況にあった
成果はあるが自分の成長はない
 
## 転職活動で考えた
- 2つの基準
    - よかったチームの経験（ひとりぼっち前）をもとに考えた
        - ４人での小さいチームで言いたいことを言い合える。小さいけれど、ユーザに感謝されるサービスの開発
        - 残念ながら解散
            - 予算の都合
            - 政治的な理由
            - 組織変更による文化の違い
 
チーム解散にあらがってみたが、連敗
 
## 転職の際に定めた条件
- 言いたいことを言える人がいるか
- チームを守ろうとする人がいるか
 
## なかなかうまくいかなかったがよい話が身近にあった
- コミュニティのつながりの信頼に賭けた
 
## なぜチームからでていかないのか？
- 居心地がよいから
    - 安心感と緊張感
    - 「勝手に感じていた後ろめたい雰囲気」感じていたが結局仮説でしかない。まずは言いたいことを言ってみることで議論が始まり、自分にとってのヒントや気づきなどがでてくる。
    - 「空気を読まない発言をしてしまった・・・」
        - やんわりと注意してくれた
        - 個人の批判でなく、気持ちを理解してくれた上での注意
        -　これにより安心感を得ることができた
    - メンバーの得意を合わせることでチームの総合力があがる。背中を預けられる安心感がある。ひとりだと苦手なことも、やりたくないことも自分で成長させる必要がある。
    - ただし、背中を預かる責任感が発生する。チームを安定させるために自分がボトルネックにならないように気を付ける。
- チームへのフィードバック
    - 副業などして、チームにない知識を持ち帰ることをした
 
# チームに居続ける理由
- 成長を助ける安心感と緊張感

# チームの感想
- 悪意がないように振る舞う。気をつけないとなぁ
- なぜいけないのか？を伝えるのは大事
- 自分がボトルネックにならない。意識も大切
- 勝手に頭の中で仮説を立ててしまうのは大いに共感。まずはやってみようが大事。何かあれば謝罪すればいいと思えば気持ちのハードルはかなり低くなる。
RSGT2021 セッションメモ ～なぜ私はチームにい続けるのか。あるいは、エンジニアとしての成長のためのチームの活用について。～

RSGT(https://2021.scrumgatheringtokyo.org)
で自身が参加したセッションのメモ&ふりかえりです。
ふりかえりの手法は、びばさんが配信しているPodcastである、ふりかえりAM ep.4(カンファレンス用のふりかえりをする例)で紹介されていたFun Done Learnを参考にしています。

# 概要

- satoryuさん

- 1日目(2021/1/6) 11:25～

- 2016年夏、あるチームが解散となりました。そのチームのうち、社内に残ったエンジニアは一人。当時、彼は一人でプロジェクトをこなしていました。ステークホルダーから感謝されていたので一人で開発を続けていました。しかし、エンジニアとしての成長は殆どありませんでした。切っ掛けでとあるチームでエンジニアを募集していることを知りました。技術スタックもそれまでの事業領域も異なるところでやっていけるのだろうか？と彼は悩みました。そのチームにいるエンジニアと一緒に働きたいという想いからそのチームへ入ることにしました。それから3年あまりが経ちました。あの時の彼の決断は正しかった、と今の私なら言えます。

  このセッションは、RSGT2020で発表された「[Team-Based TEAM - 会社を越えるチーム](https://speakerdeck.com/takaking22/team-based-team)」に対するアンサーセッションです。RSGT2020当日に初めてこのセッションの内容を知りました。それでも「あぁ、わかる。これは自分たちだ。」と思える内容でした。このセッションでは、Team-basedチームの一員として得られたものが何かについてお話します。

## 気になったことメモ

- チームと個人の成長を考えるきっかけを提供したい
- 一人で開発
  - いいこと
    - スコープコントロールのやりやすさ
    - 情報同期コスト0
    - 自身の成果として認められる
  - 悪いこと
    - 雑多なものに時間を取られる
    - 作れるプロダクトに限界
    - 成果を出しているが、自身の成長を感じにくい
    - 苦手なことも全部やらないといけない。苦手なことを伸ばさないといけない。

- チームで開発したい。でも良いチームじゃないとダメ。良いチームってなんだろう？
  - サービスやチームのためなら何でも言いたいことが言える
  - ユーザーから感謝のメールがくる。(ユーザーとの距離が近い)
- でも良いチームは結局解散した。。
  - 政治的理由
  - 価値観の相違
  - チームを守ってくれる人いなかった
- 今のチームは居心地の良いチーム
  - 何かあったら助けてくれる
  - 悪いことをしたら注意(どういう風に思われるのかを説明)してくれる。一方で個人の批判はしない。いつも同感。
    - このおかげで実験を積極的にできる。(個人事業主としてのけいけんをチームに還元できる)
    - 考えるよりも行動してみようと思う。
  - 自分が得意な部分については__背中を預かる__緊張感がある。また、自分が得意なことはメンバーもできるようにしないといけない。(自分がボトルネックになる)
- アンサーセッション(今のチームで開発するという選択をしたことが正解だった。感謝したい)

## 楽しかったこと

- やや似ている江端さんのものまねw
- satoryuさんの紆余曲折話
- 及部さんとの出会いの話(新卒同期だけど一緒に仕事していなかった。でもカンファレンスでどういう人なのかを分かっていた)

## やったこと

- アウトプットを意識しながら話を聞いた

## 学び

- 勝手に後ろめたい空気を感じて個人で悶々と考えるのではなく、言いたいことを言ってみるのも大事かも。

- 自分ができることは皆もできるよね、と認めることが大切だと感じた。
- 自分はチームで開発することがやっぱり好きで、チームをより良いチームにすることに強い関心があることが自覚できた。
【Normalization】Group Norm : Batch sizeを大きく取れない庶民の味方

<h1>Group Normalization</h1>
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482094/634f1538-6405-a19f-851d-0d3c1bd53905.png)


Group Normは
Channel=1であればInstance Norm
Channel=CであればLayer Norm

Instance NormはChannelに対するNomalizationが弱い
Layer NormはChannelに対するNomalizationが強すぎる

この中間を取れるのがGroup Norm


<h1>結果</h1>
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482094/a4c6cb86-9b42-b572-574f-3a2febbd5a26.png)
Batch Size32の時の精度は
Batch Norm ≒ Group Norm >> Leyer Norm >> Instance Norm

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482094/e5b3c82f-9eb3-9aa4-0150-00c60e372a2e.png)
Batch Norm(左側)はBatch sizeが小さくなると精度が著しく下がる
Group Norm(右側)はBatch sizeに影響されない

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482094/317ad90f-bbba-c8e5-1cb9-6209899f8bcb.png)
Layer NormやInstance NormよりGroup Normの方が精度が高くなってる。

<h1>結論</h1>
・Batch sizeを大きく取れない自分にとってはGroup Normは超ありがたい。

<h1>参考文献</h1>
Group Normalization
https://arxiv.org/pdf/1803.08494.pdf
RSGT2021 セッションメモ～「変わりたいのに変われない」チームがアジャイルで変わった話～

RSGT(https://2021.scrumgatheringtokyo.org)
で自身が参加したセッションのメモ&ふりかえりです。
ふりかえりの手法は、びばさんが配信しているPodcastである、ふりかえりAM ep.4(カンファレンス用のふりかえりをする例)で紹介されていたFun Done Learnを参考にしています。

# 概要

- Tomoko Emiさん

- 1日目(2021/1/6) 11:00~

- 我々楽天のECインキュベーション開発部（略してECID）では、改善グループという部署横断でサポートするチームがあります。
  改善グループはプロダクト開発グループには所属せず、それぞれの高いスキルをもっていろんなチームの難しい課題を一緒に解決することをミッションにしています。

  そんなECIDに去年の５月新しく仲間が増えました。
  このチームはマネージャも含めてチーム運営と開発に関する経験が浅く、ちゃんと開発をしたいのに思う通りにできない状態が続いていました。

  当時の彼らは、

  - 仕様変更をリクエストされても突発対応が入ってもProjectの納期は変えられない
  - 色々とシステムの作りがよくないのが分かっていてもどう手をつけていいかわからず悩む
  - そしてバグもいっぱいでる
  - 結果、残業が常態化

  という状況でした。

  そこに改善グループから派遣されたメンバーがもたらしたいくつかの変化とは？
  この変化によって今チームがどのように変わったかも含めてお話させていただきます。

## 気になったことメモ

- PRをきっかけに課題が顕在化
  - 単体テストない...
  - PR溜まりすぎ
  - 資料がないPR
  - 手戻りの大量発生
- 改善グループの神、椎葉さんが降臨
- 最初はひたすら観察してもらう
  - 前向きなメンバーが多い
  - すべてのロールを2人が担っているから、メンバーが何を目指すのかはっきりしなそう
    - 何でもできるっていいことだと思っていたので、Emiさんがうっとなった新しい気づき
  - PJMロールが不在なので、役割が明確に定義されていない
  - 特定の人が助けすぎ。特定の人が本来やらないといけない仕事を定時後にしていた

- バラバラなチーム
  - 責任範囲を明確化した, RACIチャートの導入
- 成長速度を上げたい
  - モブプロ
    - 副次的に資料不足や手戻りの発生という問題も解決した
- Emiさん個人の気づき
  - 井の中の蛙だった
  - マネジメントできていると思っていたが、外から見てもらうと全然マネジメントできていない部分もあった

## 楽しかったこと

- スライドのイラストが綺麗で分かりやすい

- 神や蛙など、独特だけど的を射ていて面白いメタファー

## やったこと

- アウトプットを意識しながら話を聞いた

## 学び

- なんでもできるは危険な側面もある
- 外部からフィードバックしてもらうことで、今まで気が付けていなかったことに気が付けるかも
- 何にでも責任を持つことは聞こえはいいが、危険性も孕んでいる。
  - 一回責任範囲を明確に定義して、その後に皆が責任を持つ状態に戻す取り組みもあり(責任範囲を定義すると自分の責任範囲外のことに無関心になってしまう恐れがある(チームの結果に責任を持ちにくくなる恐れがある))
RSGT2021 セッションメモ ～アジャイルを忘れるチーム Unlearn Agile～

RSGT(https://2021.scrumgatheringtokyo.org)
で自身が参加したセッションのメモ&ふりかえりです。
ふりかえりの手法は、びばさんが配信しているPodcastである、ふりかえりAM ep.4(カンファレンス用のふりかえりをする例)で紹介されていたFun Done Learnを参考にしています。

# 概要
- kyon_mmさん
- 1日目(2021/1/6) 10:00～
- 「チームが生き生きしつづける予感はどこからきますか？」
  予告編動画 => https://www.youtube.com/watch?v=5Ro5_c5kFaY
  アジャイルをUnlearnし、生き生きとした開発を見つけたチームがいました。そこにはアジャイルマニフェストもスクラムガイドもなく、自分達のパタンランゲージがありました。開発するシステム、立ち居振る舞い、プロセス、価値観、イベント、成果物などありとあらゆるものが記述されていました。パタンランゲージの語彙は200を超え日々編纂されていました。
  私達チームが新しい形に変化していくこと自体が漸進的で、自然で、納得しやすい必要がありました。Unlearnしていくこと、アレグザンダー理論を導入していくこと、実践していくことは一見難しくおもえました。ですが、私達は徐々にできてきました。この漸進的な変化こそが私達が見つけたかったものです。これこそがチームにおける決定の遅延であり、漸進的変化でした。これらの具体例そして考察をおとどけします。
  時を超えた開発の道とは何かを考えるきっかけにどうぞ

# 心に留まったことのメモ
- まずはこれまでの47機関(kyonさんが所属するチーム)のふりかえり
  - 生物の進化論的プロセスを取り入れて成長してきた(2019)
  - チームのパタン・ランゲージを定義した(チームとしての性質と向き合い続けた) (2020)
  - いくつかのパタンが生まれた
    - つよくてニューゲーム
      - 繰り返し作業は効率が良いから
      - 一度はまったことが解決できるから
    - 脊髄感謝(一言目にゆっくりと感謝を述べる)
      - ネガティブフィードバックが萎縮を生むから
      - ゆっくりとした口調は大切なものとして聞き取れるから
    - ついでの一仕事
      - 変化は小さいほど簡単だから
- 心地よいチームが大切なのでは？心地よいチームとは？(ワーク)
  - (会場の意見)モブプロ/お互いに褒め合う
    - 課題に対して全員で向かえるから
  - (自分の意見) 異なる価値観があるが、チーム全員が一つの場所に進んでいる状態。チーム全員がその目標を言語化できている状態
- 自分たちのパタン・ランゲージを考えて、コンテキストが分からない人にも伝える必要性がある
- 一方、パタンを使うことに執着すると良い建築になっていない
- 規範の中にいるときは、それを窮屈と感じるけど、規範なき行為はまた行為として成立しない(攻殻機動隊)
- 生き生きとしているチームは存在する
  - オキザリスやenpitは生き生きとしている
  - 超個体的側面を持っているチームが生き生きとしている(複数の生命体が一つの生命になる)
- きょんさんのチームでは直感によって何かに導かれる(直観は客観的にも観察可能である。直観に対しては深い共感もある)という仮説がでた
- 各パタン(プラクティス)について、コミットメントの量/コミットメントのパス数というのを定義することが重要では？
  - ポイント数(量)とパス数両方が大切なのでは？
  - XXXというパタン(プラクティス)があったとする。この時、「メンバーの何割が合計で何Pt以上のコミットできる」かが分かれば、プラクティスの導入は上手くいくはず。
  - コミットメントの量/コミットメントのパス数が分かればパタンは導入できる
- 原則から入るのではなく直感から入るべき
- 秩序マップ
  - 直観&客観(+深い共感)⇒実験⇒原則&ルール&ガイド
  - 直観&客観(+深い共感)がチームのセンターになる

# 楽しかったこと
- きょんさんの生演奏を聞けた
- 普段勉強しているアジャイルの原則とは全く違う観点の話が聴けた。上手く言語化できている自信はないが、学びが壊れた感覚が楽しかった。

# やったこと
- アウトプットを意識しながら話を聞いた
- 心地よいチームについてのワークを実施した
  - 異なる価値観があるが、チーム全員が一つの場所に進んでいる状態。チーム全員がその目標を言語化できている状態
- 上記の__心地よいチーム__についてきょんさんの提案した秩序マップのどの状態にあたるのかを考えてみる
  - 直感&客観(+深い共感)？

# 学び
- この発表を聞いている時の自分は生き生きとしていた気がする。この発表を聞いている時の状態を言語化することは、自身にとって学びになる可能性が高い
- 参考になるかもしれない話(下にまとめておいて後で読み返す)とこの発表をつなげることで学びが深化されるかもしれない
- 秩序マップ

# 参考になるかもしれない話
- 認知リソースの分配
- 組織パタンの「信頼で結束する共同体」
- ミーム
Regional Scrum Gathering Tokyo 2021 Day 1 「Remote Work Native な働き方を志向した結果、Agileな状態に爆進しているとあるHRチームの話 - 組織全体への波及を添えて」

# Regional Scrum Gathering Tokyo 2021 Day 1 「Remote Work Native な働き方を志向した結果、Agileな状態に爆進しているとあるHRチームの話 - 組織全体への波及を添えて」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/15023/remote-work-native-agilehr-

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

# 
非開発系でもリモートワークで効果的な働き方を続けると、透明性・検査・適応を柱として強いチームへ進化できた
チームにとどまらず、文化を組織や会社全体に普及させるための具体例

# NTTの人材部のイメージは？
- チームというよりも俗人に依存
- ブラックボックス
- 雑談は×
というイメージ・・・半分くらいは正解


# エピソード
- 新人研修を振るリモートに
- 海外研修生４０名を一斉帰国
- 自分たちも原則在宅勤務

このようななか、いままでの働き方では通用しないのではないかという思いに至った。

# リモートネイティブ
- リモートワーク率
    - 世の中的には 25%（意外と低い）
    - NTTでは 80%
    - 我々のチームは 90%
    - リモートワーク中心のなかでどうパフォーマンスを高めるかが重要

- リモートワークでのパフォーマンス
    - DX Summit 2020 特別賞をいただくなど効率的に仕事ができた

- 効率を上げる仕事の仕方
    - カンバンによる見える化とタイムボックス

# アジャイルという言葉をつかわずに
- 最初にやったこと
    - ITツール利用の高度化
        - コミュニケーションをメールからチャットへ
        - オンプレからクラウドへドキュメント管理を移行
    - 非開発系だと上記をやるのも以外にタイヘン
- 普及するためにやったこと
    - リモートワークハンドブックを作成して共通言語化
    - 社外にも公開中

- 激しい外部環境の変化
    - 小中学校の一斉休校
    - 海外のコロナ状況
    - これらにうまく対応していく必要があった

- これらの外部環境の変化に対応するためにやったこと
    - 「カンバン」でチームのタスク・課題を見える化した
        - 透明性が向上
        - カンバンに起こす作業は「全員でやる」ことが重要
    - 「朝会」を導入
        - 困っていることを共有。相談を気軽にできる仕組みを作り、透明性を継続しつつ検査することができる。
        - リモートワークにメリハリがでる効果も。
    - 「リファインメント」
        - 形骸化しないように毎週30分、カンバンを更新
        - 透明性も高いレベルで継続
    - ふりかえり
        - いままでふりかえりの文化がなかったので、２週間単位で１時間程度で固定
        - 雑談ベースでゆるく始めることで気軽に始められるように
    - アジャイルという言葉を使っていないが、効率的なチーム運営を模索すると結果としてスクラムのプラクティスになった

# 透明性・検査・適応には順序性がある
   - 透明性が一番！
   - 透明性をいかに向上させるか・・・
       - 背中を見せること
           - 社内向けのYammarでつぶやいて全社に公開。
           - 社内ニュースメディアで幹部が全社施策の思いなどを語る
           - Slackベースで社内イベントを継続開催

# 感想

**「背中を見せることが大事」**
めちゃかっこよかったです。私も背中を見せられるように精進します。
Regional Scrum Gathering Tokyo 2021 Day 1 参加レポート「“あざとくて何が悪いの？”建設的であり続けたいだけの､人たらしチームマネジメント」

# Regional Scrum Gathering Tokyo 2021 Day 1 「“あざとくて何が悪いの？”建設的であり続けたいだけの､人たらしチームマネジメント」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14889

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

# どんなセッション？
- とあるチームで、リモートワーク×合意形成合意形成の鈍化がプロジェクトの難航化を引き起こした
- それを変えるためになにを実践したか？あざといプラクティスを紹介！

というセッションでした。

# コロナ禍での課題
- リモートワークに不慣れ
- ステークホルダー間で合意形成が難しく...

## リモートワークのやりづらさTOP3
- 得られる情報が対面より減って、思惑が読み取りづらい...
- 会食や雑談などのおたわむれが減ってしまった
- 家庭の事情もろもろ

## 信仰が滞るとどうなる？
- **「罪悪感」は遅効性、「しらけ」は即効性の毒に... [^1]**
- 特に「しらけ」は一発KOで離職の可能性も...
- モチベーションも限りあるもの。だんだんゼロに近づいていく

# やってみたこと
## 挨拶をする
- コミュニケーションを円滑にする目的。人として、社会人として。
- ＋αで、相手のコンディションを確認したいという意図も。
- 挨拶の時は、元気を音のトーンで測ってみる！
	- ファとかソとか...

## 奥行きを活用する
- リモートワーク中の画面の写り方を意識する
    - 大きく映ると積極的・肯定的に見える
    - 小さく映ると消極的・否定的に見える
- 伝えたいことは前のめりになって伝えてみる！

## リアクションは大げさぐらいに！
- オンラインだとオフラインより情報がかけてしまって、合意形成に時間がかかる
	- うなずき、目の動き、など非言語的な情報などなど欠けてしまう
- 大袈裟ぐらいのリアクションが議論の質を高める

## プレゼン時には参加者の反応を見る
- オンラインだからこそできること！
- オンライン発表中どこみてますか...？

# あざといプラクティスにこめた思い
## どんな状況でも建設的に
- 困難な状況で「すねる」のは自分が一番損する
- 早く状況に適応したもん勝ち
- 成功確率にとらわれずにチャレンジ回数を増やす

## 堂々と計算高くあればいい
- 何のためにやってる？に胸を張って
- 言い訳してやらないのはもったいない
	- そういうキャラじゃないとか...
	- 何の準備もいらないしやってみる価値あり
- 習慣になったら丸儲け

# チームはどう変わったか
- 相互作用がおきた！
    - チームは相互作用するものなんだと実感したそう
    - 他のメンバーにもよいところが伝搬した！

## 副次的にこんな効果も
- メンバー間での絆・愛情がふかまった
- 相手をおもんばかるスキルが向上

# まとめ
- リモートワークと合意形成合意形成の鈍化でプロジェクトが難航化した
- それを変えるためになにを実践したか？を紹介
- 実践の結果、チームのメンバーにも相互作用を起こすことができた！

# 感想	
個人的にタイトルに惹かれてこのセッションを聴講しました。キャッチーなタイトル、プレゼンでの言葉選びがとても印象的でした。
そしてプレゼンで紹介されていた内容は、私ひとりからでも実践できる技ばかりでした。
特に奥行きの活用方法、発表中に相手のリアクションに注目する点はすぐ反映させたいなあ...
他のプレゼン内容も取り込みつつ、堂々とあざとく生きていこうと思います！
~~実践してたらいつか田中みな実さん、弘中アナのようになれるはず~~

[^1]: スピーカーさん的にこのセッションでお気に入りワードだそう。こういう言葉の選び方が素敵な方だなと思いました！
EC2 on MacでiOSビルド環境の夢を見た

※個人の感想です
※2021-01-06時点での情報と調査結果をもとに書いているので今後変わる可能性たかし君です

## やろうと思ったこと
2020年12月頭くらいに発表された、EC2でmacが起動できるって話で、
ついにiosビルド環境をクラウドで完結できる日が来たかと思いいわゆるCI/CD環境を構築しようかと思った。

=> 断念

## 苦しい
mac1.metalインスタンスは専有ホストでしか利用できない。これが運用面・料金にダイレクトに響く。

### 起動が結構長い
us-west2でやりましたが、30分近くかかった。

### 1度起動すると24H解放されない
物理マシンを借りてるみたいなもんらしいから致し方なしとは思いますが…

### 専有ホストはインスタンスが起動しているかによらず課金される(多分)
これもし認識違ったらそっと教えて欲しい…けど
専有ホスト作成しようとしたときのコンソールの
`インスタンスごとではなく、割り当てられた専有ホストごとに請求`
って文言や、そもそも物理マシンを借りるって性質である以上、使ってない時間は課金されないなんて虫の良い話があると思えないので…

## 断念理由まとめ
上記3つがジェットストリームアタックのように襲い掛かってくるので、
・1回起動すると必ずおよそ3000円かかる(us-west2)
・使う時だけ起動して終わったら即解放って運用もかなり苦しそう

というわけでクラウドでのios CI/CD環境として利用するのは現在のところ厳しいかなあという印象でした。
2-3か月フル稼働でまっくぶっくが買えてしまう…
月に1-2日だけピンポイントで使いたい日がある、みたいな特殊な要件でならあるのかなあ？
Sassの３Dアニメーション　〜　キュービックのボタンを作る。

#はじめに

はじめに
一例としてキュービックのボタンのようなものをScssで表現してみたいと思います。
Scssの導入方法については、ここでは詳しくのせていません！
予めご了承ください！

こちら完成画像です！
https://gyazo.com/0bc2b2268fa39096696fd0176c047a0e


hoverするとくるっと回転するボタンです。オシャレですね！

さっそく始めます！！

```index.html
<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <meta http-equiv="X-UA-Compatible" content="ie=edge" />
  <title>Document</title>
  <link rel="stylesheet" href="style.css" />
</head>

<body>
  <div id="container">
    <div class="try">
      <a class="btn cubic"><span class="hovering">Now, Hovering</span><span class="default">Button</span></a>
    </div>
  </div>
</body>

</html>
```
htmlでは、"Now, Hovering"という文字列と"Button"という文字列が定義されています。
完成のイメージはデフォルトで"Button"が表示されていて、カーソルをホバーすると、クルッと９０度回転して"Now, Hovering"に変わるイメージです！

```style.scss
$cWhite: white;
$cBlack: black;

#container {
  text-align: center;
}
.try {
  .btn {
    position: relative;
    display: inline-block;
    transform-style: preserve-3d;
    perspective: 300px;
    width: 150px;
    height: 50px;
    margin: 0 auto;
    cursor: pointer;

    &.cubic {

      & span {
        position: absolute;
        top: 0;
        left: 0;
        width: 100%; 
        height: 100%;
        border: 1px solid $cBlack;
        line-height: 48px;
        text-align: center;
        transition: all 0.3s;
      }

      & .hovering {
        background-color: $cBlack;
        color: $cWhite;
        transform: rotateX(90deg);
        transform-origin: center center -25px;
      }
      & .default {
        background-color: $cWhite;
        color: $cBlack;
        transform: rotateX(0);
        transform-origin: center center -25px;
      }

      &:hover {
        & .hovering {
          transform: rotateX(0);
        }
        & .default {
          transform: rotateX(-90deg);
        }
      }
    }
  }
}
```
・& spanにはホバーしているときと、離したときで共通しているスタイルを記述しました。親要素なので、transition: all 0.3s;とすることで適用している全てのプロパティを０．3秒で変化させるという意味です。

・& .hoveringにはホバーするまえの状態を記述しています。hoveringのほうはデフォルトでX軸のほうに−９０度の状態なので、rotateX(90deg);としてあげます。
transform-originはホバーして回転する軸を設定できます。X軸方向はcenter。Y軸方向はcenter。Z軸方向には -25pxとしてあげます。
X軸は横軸。Y軸は縦軸。Z軸は奥軸です。

・& .defaultはデフォルトでは回転させなくて良いので、rotateX(0);としています。こちらも同様に、transform-origin: center center -25px;としてあげます。

・&:hover {}とすることでボタンをホバーした状態を表現できます。
ホバーしたときに正面をむくことになりますので、& .hovering {transform: rotateX(0);} とします。
同様にホバーしたときに& .default を９０度回転して隠したいので、& .default {transform: rotateX(-90deg);}としました。

・３Dを表現したい親要素に、transform-style: preserve-3d;とつけてあげるのもお忘れなく！！

#おわりに

transformの使い方次第で色々なボタンを作れるんだなと思いました。
また色々試してみて、アウトプットできたらと思っております。
Regional Scrum Gathering Tokyo 2021 Day 1 「患者さんや顧客に最大の価値を提供するために ～外資系製薬企業が組織全体の変革を目指しアジャイル導入～」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/15015/online-interpretation

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。



## 背景

製薬会社MSDさんの、アジャイル導入のお話です。前提は下記のとおり。

- コマーシャル組織（マーケティング中心）を対象とした変革
- 2018~2019年の1.5年間
- 日本支社が独自で行っている
- COVID-19の影響下でも変革維持

また、下記のような問題に直面していた。

- 薬価に関する圧力：厚労省が定期的に見直すことで変動する。
- 研究開発の高騰：そもそも研究費用が高いうえに、結果が出るのに時間がかかりリスクも大きい。

こうした問題に対処しながらも、首尾よく研究開発や商品化を進め、ヘルスケアのトップを走り続けるためには？というのがアジャイル導入の始まり。

## アジャイル組織への道

最初は限られた人数で、社内カフェスペースを使いながら始めた。外部のスクラムマスターの力も借りながら、チーム規模を広げていった。チームメンバーの皆はもともと興味をもってくれており、難なく拡大できたことは助かった。

得られた成果は

- スピード：資料作成は4倍、新しい業務への順応は3倍くらいのスピードに。
- 社員エンゲージメント：共有、連携、権限移譲、試行錯誤、自ら学ぶなどのエンゲージメント指標が上昇

など。また、他企業へ見学に行った際に「中途半端にアジャイルを取り入れるとうまく行かない」ことを聞き、全社への導入を決断した。

アジャイル開発宣言を参考にしながら「社内のアジャイル組織の主要な価値と原則」を作成。1人ではなく、各リーダーが集まって作成した。


## 何が変わったのか

例えば

- プロセス面：OBR・OKR研修を実施して導入
- 人財面：T型成長の促進やアジャイルブートキャンプへの参加

などなど。

スクラムマスターは、所属部門やキャリア経験の違うメンバーの中から社内で選定のうえ、育成した。

## Scrum Master Journey

例として、スクラムマスター1年目の方のjourneyの話。もともとマーケターでシステマチックに仕事を進めるタイプだった方が、スクラムマスターを学びながら業務に取り入れる上での気落ちの変化がリアルに語られていました。

## 学び

スプリントレビュー実施、QBRやそれに伴う事業見直しなど、各イベントを多くこなしてきた。
その中で、アジャイルに取り組んだ1年のキーワードとしてメンバーからは、試行錯誤、心理的安全性、スピード、などが上がった。
また、アジャイル組織への変革が、COVID-19状況下での即日リモート移行やそのごの生産性向上の維持に貢献した。

## 最後に

変革はまだまだ続いていく。アジャイルが本格的に全社の組織文化として定着するために挑戦を続ける。



# 感想

ヘルスケアにもともと興味を持っており聴講しました。
また、アジャイルのイベントにはIT業界の方が多い一方で、製薬業界からの参加というのも目を引きました。開発を行う組織でなくても、これだけアジャイルを取り入れ成果を出すことができる、という実話は大変勉強になりました。
Pythonでボードゲーム「バンカース」の家の止まりやすさを計算した

#はじめに
年末年始にボードゲーム「バンカース」をプレイして、明らかに止まりやすい家があるなと興味を持ち、シミュレーションして、止まりやすさを計算することにした。
環境はiPhoneのPythonistaで行った。

![bankers](https://images-na.ssl-images-amazon.com/images/I/51ZKQTYT3SL._AC_.jpg "bankers image")
出典：[Amazon | バンカース(復刻版) | すごろく | おもちゃ](https://www.amazon.co.jp/%E3%83%8F%E3%83%8A%E3%83%A4%E3%83%9E-HANAYAMA-%E3%83%90%E3%83%B3%E3%82%AB%E3%83%BC%E3%82%B9-%E5%BE%A9%E5%88%BB%E7%89%88/dp/B0002YNBM8)

##実行結果
結果のみ知りたい方のために、まず実行結果を示す。横軸はシミュレーションで止まった回数である。
![89A0A821-CE31-4BA4-8075-0ADDE64B2D21.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/537682/ad2e307b-6ea8-bd05-319b-0855ba1dd671.jpeg)

#コード解説
##シミュレーションの方針
シミュレーションを行い、家に止まった回数をカウントし、それを十分大きな数だけ繰り返すことで収束した値を比較する。

##盤の実装
盤には40マスあり、40番目の次は1番目に戻る。
したがって、総移動数をカウントし、剰余演算でどこのマスにいるかを判定する。

##実装しないマス
止まりやすさ(移動の仕方)に影響しないマスについては特に細かいところは実装せず、何も起こらないマスとして扱う(実際にはお金を取られたりもらったりする)。

##止まったことの判定の仕方
止まったと判定するのは1ターンの最後に止まったマスとしている。なぜなら、家に泊まった場合は必ずそこでターンが終了するため。また、このシミュレーションの目的は家の止まりやすさを計算し、比較することにある。

##マスの評価の仕方
マスを移動する関数を作成し、それを介して移動することで、マスの評価を行う。

```py:マスの評価関数
def stepEval(steps, count, card):
	if (count + steps) % len(BOARD) == 18:
		if steps == 7:
			return steps
	if steps == 0:
		return 0
	else:
		count += steps
		next_steps = BOARD[where_board(count)].getMove(card, where_board(count))
		return steps + stepEval(next_steps, count, card)
```

#参考文献
https://www.amazon.co.jp/%E3%83%8F%E3%83%8A%E3%83%A4%E3%83%9E-HANAYAMA-%E3%83%90%E3%83%B3%E3%82%AB%E3%83%BC%E3%82%B9-%E5%BE%A9%E5%88%BB%E7%89%88/dp/B0002YNBM8

#ソースコード
[GitHub - PyBankers](https://github.com/huwns/pybankers)
[PyPI - PyBankers](https://pypi.org/project/pybankers/)
Java   Word文書で段落の文字色を変更

<p><strong>この記事ではWord文書で段落の文字色を変更する方法を紹介します。前のようにSpire.Doc for Javaというライブラリが必要になります。</strong></p>
<h4><strong>下準備</strong></h4>
<p><strong>1.E-iceblueの公式サイトから<a href="https://www.e-iceblue.com/Download/doc-for-java-free.html">Free Spire.doc for Java</a>無料版をダウンロードしてください。</strong></p>
<p><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/l/lendoris/20210106/20210106114703.png" alt="f:id:lendoris:20210106114703p:plain" title="" class="hatena-fotolife" itemprop="image" /></p>
<p><strong>2.IDEを起動して新規プロジェクトを作成してから、インストールされたファイルにあった相応しいSpire.doc.jarを参照に追加してください。</strong></p>
<p><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/l/lendoris/20210106/20210106114719.png" alt="f:id:lendoris:20210106114719p:plain" title="" class="hatena-fotolife" itemprop="image" /></p>
<h4><strong>元のファイル</strong></h4>
<p><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/l/lendoris/20210106/20210106114800.png" alt="f:id:lendoris:20210106114800p:plain" title="" class="hatena-fotolife" itemprop="image" /></p>
<h4><strong>コード</strong></h4>
```JAVA
import com.spire.doc.*;
import com.spire.doc.documents.*;
import com.spire.doc.fields.TextRange;

import java.awt.*;

public class ChangeFontColor {
    public static void main(String[] args){
        //Document　objectを作成します。
        Document doc = new Document();
        //Wordをロードします。
        doc.loadFromFile("FontColorExample.docx");

        //初めのsectionを取得します。
        Section section = doc.getSections().get(0);
        //初めのsectionで二つ目の段落をを取得します。
        Paragraph p1 = section.getParagraphs().get(1);

        //二つ目の段落をループします。
        for (int i = 0; i < p1.getChildObjects().getCount(); i ++)
        {
            //二つ目の段落のテキストの色を変更します。
            if ( p1.getChildObjects().get(i) instanceof TextRange)
            {
                TextRange tr = (TextRange) p1.getChildObjects().get(i);
                tr.getCharacterFormat().setTextColor(Color.green);
            }
        }

        //三つ目の段落を取得します。 
        Paragraph p2 = section.getParagraphs().get(2);

        //三つ目の段落をループします
        for (int j = 0; j < p2.getChildObjects().getCount(); j ++)
        {
            //三つ目の段落のテキストの色を変更します。
            if ( p2.getChildObjects().get(j) instanceof TextRange)
            {
                TextRange tr = (TextRange) p2.getChildObjects().get(j);
                tr.getCharacterFormat().setTextColor(Color.blue);
            }
        }
        
        //保存します。
        doc.saveToFile("ChangeFontColor.docx", FileFormat.Docx_2013);
    }
}
```

<h4><strong>完成例</strong></h4>
<p><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/l/lendoris/20210106/20210106114855.png" alt="f:id:lendoris:20210106114855p:plain" title="" class="hatena-fotolife" itemprop="image" /></p>
<p> </p>
Floating Cloud Licensesを使う

Build 2020.28110 のリリースと一緒に新ライセンス形態 `Floating Cloud Licenses` が出た。インターネット環境があればどのPCでもライセンス認証が通る。職場1・職場2や家それぞれの場所での開発用に、1ライセンスでドングル抜き差し無しでTDインスタンスを起動出来て大変うれしい。
https://docs.derivative.ca/Floating_Cloud_Licenses

## 導入方法

近日中にDerivativeのストアに登場するらしい。ストアに無い現時点（20210106）で購入する為にはメールで問い合わる必要がある。

※値段を書いていいか不明なので値段は伏せます

0. DerivativeにメールをしてFloating Cloud Licenseの値段を聞く
1. $███分のPayment TokenをDerivativeストアで買う
    - 新規ライセンス購入ではなく、既に持っているCommercialライセンスをFloatingに切り替える場合は差額分のPayment Tokenを買う
2. Floatingライセンスを買いたい旨をDerivativeにメール。既に持っているライセンス情報（= Floatingに切り替えたいライセンス情報）と「Payment Token買ったよ～」という旨を伝える
3. Nadineから `.wbc` という拡張子のクレデンシャルファイルが送られてくる
4. クレデンシャルファイルをCodeMeter Control CenterにImportする。ドラッグ&ドロップして完了
![スクリーンショット 2021-01-06 114730.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/86490/772d2022-e15b-6d53-b4d2-f0c11ccbb618.png)



## 早速使い始めたメモ
- ライセンスが固有PCに紐づく形ではなく、USBドングルもいらないので便利がいい
- 違うPCで同時にTDインスタンス立ち上げは出来ない
- 同PC内で複数TDインスタンスを立ち上げは出来る
- ドングルを使ったライセンス認証の場合、20秒に1回ライセンスチェックが走る。Floating Cloud Licenseの場合は起動時 "CodeMeter License check" の時1回だけ走る。この時にインターネット環境が必要・同ライセンスを使って他PCでTDインスタンスを立ち上げて無ければ認証が通る


## おわりに
人柱としてFloating Cloud Licensesを今朝から使い始めました。
注意点見つけたら追記します。


## 使い始めてからの追記
- クレデンシャルファイルをインストール済のネット接続済PCだったら、なにも考えずTDを起動出来て最高に便利
- 作業場PC, 家PC, ラップトップで本当にちゃんと動いた。「1日のドングル抜き差しx2回の手間省略 & ドングル持ち運び忘れ保険」に1日$1弱掛けてると考えれば全然元を取れるぞ という体感
- Build 2020.28110 以降じゃないと動かない。昔のバージョンを使わなければいけない理由がある場合は要注意
- PC1でFloating Cloud Licenseを使ってTDインスタンスを起動した場合、このインスタンスを閉じるまでPC2ではライセンス認証が通らないので注意。（ラップトップでTDを使った後、ちゃんとTDを終了せずラップトップをパタッと閉じる --> 他PCでTDを起動出来ないので注意....）
RSGT2021 セッション参加レポート“あざとくて何が悪いの？”建設的であり続けたいだけの､人たらしチームマネジメント（Day1 11:25-11:45）

# はじめに
このページは、RSGT2021で参加したセッションのレポートを書いたものです
https://2021.scrumgatheringtokyo.org/


# このセッションの概要
【タイトル】
“あざとくて何が悪いの？”建設的であり続けたいだけの､人たらしチームマネジメント
Day1 11:31～11:51

【Confgineのセッションページ】
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14889


# 感想などのピックアップ
### 【感想】
 - 実践的な内容が多くて、さっそくTeamに帰ったらやってみようと思った！

### 【気になったキーワード】
 - 挨拶の声のトーンを「音階」で捉える

# セッションのメモ
## 1. inntoro 
リモートワークのやりづらさ

コロナ禍においてのチームの課題
やりにくくなったTOP3
　・思惑を読み取りづらい（得られる情報が減る
　・おたわむれが減った（雑談するタイミング。移動時間とか
　・家庭の事情（子どもが周りにいる環境


ステークホルダー間の合意形成の鈍化
事が進まなくなった
・「罪悪感」は遅効性、「しらけ」は即効性の毒
　罪悪感
　　スキルが足りないとか
　　→早く手が打てれば回復も早いかも

　しらけ
　　今作ってるもの、本当に使われるのだろうか？となると「しらけ」ていく
　　最悪、離職にもつながる
　　モチベーションは限りあるもの、いずれ尽きる

プロジェクトの進行が難航化
状況が変わったならやり方を変えよう！いくつかプラクティスを紹介！

## 2.プラクティスの紹介

#### あいさつ
＋αの狙い
相手のコンディションを知る
・返しに元気が無い人、無言の人がいたら状態に気を配る
・ありのあまが表れる

とはいえ、元気を定量的にいうと？？
→音階でとらえる！
　「ソ」は結構高いらしい？
　いつもの会話のトーンの１つから２つ


#### オンライン会議で絶対活用するべき「奥行」
顔が大きく写ってると積極的な印象
遠い・小さいと、消極的・否定的な印象になる

大事なときは40～50％くらいで映る！


#### リアクションは大げさに！
うなずきなどの情報が欠けてくる
読み取りづらくなる
→合意形成に時間がかかる

情報の渡しあいが必要。議論の質を上げるためにやる！

#### オンラインプレゼン時に見るべきは参加者の反応
自分が説明するとき、どうしても資料に目がいきがちだけど…
これだけは、対面よりオンラインの方がやりやすいかも


## 3.あざとさのすすめ
実験したプラクティスに込めた想い

#### どんな状況でも建設的であること
困難な状況で「すねる」のは自分が一番損する
早く状況に適応したもん勝ち
成功確率にとらわれずチャレンジ回数を増やす

#### 堂々と計算高くあればいい
なんのためにやってる？に胸を張っていこう
言い訳してやらないのはもったいない


## チームの変化
####相互作用だ！
何かが変われば反応して変わっていく

#### 副次的効果
エンゲージメントが向上した
おもんばかるスキル


～おわり～
Cloud9でLaravelの環境構築の方法

#手順
###PHPをインストール

```
$ sudo yum -y update
$ sudo yum -y install php72 php72-mbstring php72-pdo php72-intl php72-pdo_mysql php72-pdo_pgsql php72-xdebug php72-opcache php72-apcu
$ sudo unlink /usr/bin/php
$ sudo ln -s /etc/alternatives/php7 /usr/bin/php
$ php -v
```

###composerをインストール

```
$ curl -sS https://getcomposer.org/installer | php
$ sudo mv composer.phar /usr/bin/composer
```

###Laravelをインストール

```
$ composer global require "laravel/installer"
$ composer create-project laravel/laravel アプリ名 6.* --prefer-dist
```
SlackでGithubのlink previewをやめた

# GithubのLink Previewとは
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37718/9f530a96-d978-d68b-60d8-5b0c6830531f.png)

[integrations/slack: Bring your code to the conversations you care about with the GitHub and Slack integration](https://github.com/integrations/slack#link-previews)

SlackにGithubのリンクを含めるメッセージを送ると、以下の様に表示されます。

![Screen Shot 2021-01-06 at 7.36.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37718/d061895d-1650-a7a7-8b88-1c76466441c9.png)

# やめた理由
最初にとても良い機能と思いましたが、最近要らない且つプレビューが長すぎて、画面を大幅に奪われてしまうことに気づいた。

やっぱり簡潔のほうが良いなので、やめました！

# やり方
- Slackに`/github settings`を入力して、実行する
- やめたいチャンネルを選んで、無効にする
  - ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37718/9e57880b-e2b8-11e1-419e-81d73c46fbce.png)

# スッキリした
![Screen Shot 2021-01-06 at 7.38.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37718/ba8c2b2a-c625-3c58-c09b-36b20255873a.png)
Regional Scrum Gathering Tokyo 2021 Day 1 「たった一人からはじめて70人の縦割り組織にスクラム導入した話」

# Regional Scrum Gathering Tokyo 2021 Day 1 「たった一人からはじめて70人の縦割り組織にスクラム導入した話」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/15028/70

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。


# 1.プロジェクトの体制と抱えていた課題
細分化された専門性
- 多種多様な職種
	- 一つの施策をリリースするために全員が関わる

## 1.1 リーダとの連絡で1日が終わる
- リーダーが各チームのサブリーダと一緒にスケジュール管理してた
- ものすごい数のタスクをガントチャートで調整してた

## 1.2 他のチームが何をやっているかわからない
- なにが起こったか
	- デザイナーチームが一切話を聞かなくなった

# 2.一人からスクラムを始める
- 権限・権力がない
- 戦略が必要
	- タイミングを見計らう
	- 権力者に直談判する　→　そこから徐々に話を広げていく
		- 信頼の残高は必要（７つの習慣より）
	- 難しい用語は使わない

# 3.いざ、体制変更
- ABテストでスクラムの有効性を示す
- ティーチングができていない
- スケーリングが難しい

# まとめ
- 何の権限がなくても一人で組織をかえる
- 信頼の残高は必要
- スケーリングするなら仲間が必要
Kubernetesで作成したPodのCPU使用量，Pod名，IPアドレスを表示させる方法


#はじめに
Podを使った実験の評価をする上でデータ取得は重要な作業である。
この記事ではPodの名前とIPアドレス、CPU使用率を取得するプログラムを書いていく。


#Podの作成
kubernetesのDeploymentを使ってPodの複製をする
`reprica.yaml`はレプリカ数を4に設定。コンテナはnginxイメージでWebアプリを表示させるプログラム。

```reprica.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: replicas-deployment
spec:
  replicas: 4
  selector:
    matchLabels:
      app: server-app
  template:
    metadata:
      labels:
        app: server-app
    spec:
      containers:
        - name: nginx-container
          image: nogisora/serverimage
          ports:
            - containerPort: 80
~                              
```

作成したPodはこのように表示できた。

```
kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
replicas-deployment-5b669df64c-wnfbp   1/1     Running   2          34d
replicas-deployment-5b669df64c-csscv   1/1     Running   2          34d
replicas-deployment-5b669df64c-fj6kr   1/1     Running   2          34d
replicas-deployment-5b669df64c-l8k7x   1/1     Running   2          34d

```


次にこのPodのデータを取得するプログラムを書く。
`api_cpu.py`ではCPU使用率、IPアドレス、Pod名を取得できるようにしている。
さらに、CPU使用率の一番低いPodを下に表示させるようにもなっている。
※jsonの部分はコメントアウトになっているのは実験上必要がなかった為



```api_cpu.py

from kubernetes import client, config
import json

config.load_kube_config()
api = client.CustomObjectsApi()
v1 = client.CoreV1Api()
resource = api.list_namespaced_custom_object(group="metrics.k8s.io",version="v1beta1", namespace="c0118220", plural="pods")

all_array = []

#print(json.dumps(resource,ensure_ascii=False, indent=4, sort_keys=True, separators=(',', ': ')))
for pod in resource["items"]:
    s=pod["metadata"]["name"],pod['containers'][0]["usage"]["cpu"].replace('n','')
    all_array.append(s)
    print(s)

max=None
max_name=""
for container in all_array:
    if max is None:
        max = int(container[1])
    elif int(container[1])<max:
        max=int(container[1])
        max_name=container[0]
print(max_name,max)

# Configs can be set in Configuration class directly or using helper utility
print("Listing pods with their IPs:")
ret = v1.list_pod_for_all_namespaces(watch=False)
for i in ret.items:
    if 'replicas-deployment' in i.metadata.name:

        print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))
~                                                                                ~                                                            
```

実行結果は以下のようになった。
負荷は負荷実験ツールのLocustでかけている。
取得したデータは表示できている。


```
('replicas-deployment-5b669df64c-fj6kr', '28540182')
('replicas-deployment-5b669df64c-l8k7x', '30169433')
('replicas-deployment-5b669df64c-wnfbp', '31286353')
('replicas-deployment-5b669df64c-csscv', '27848575')
replicas-deployment-5b669df64c-csscv 27848575
Listing pods with their IPs:
10.42.1.112     c0118220        replicas-deployment-5b669df64c-wnfbp
10.42.1.113     c0118220        replicas-deployment-5b669df64c-csscv
10.42.2.191     c0118220        replicas-deployment-5b669df64c-fj6kr
10.42.2.198     c0118220        replicas-deployment-5b669df64c-l8k7x
```

以上でこの記事を終わりとする。
今後は、ＣＰＵ使用率の一番低いPodのみを表示させられるようなプログラムを追記したいと考えてる。
RSGT2021 セッション参加レポート R&Dチームが歩むスクラム守破離ジャーニー（Day1 11:00-11:20）

# はじめに
このページは、RSGT2021で参加したセッションのレポートを書いたものです
https://2021.scrumgatheringtokyo.org/


# このセッションの概要
【タイトル】
Day1 11:00～11:45

【Confgineのセッションページ】
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14643/r-d


# 感想などのピックアップ
### 【感想】
 - 簡潔で分かりやすいストーリー
 - 図解も豊富。スライドをオンラインで見返したいなぁ

### 【気になったキーワード】
 - 内発的動機
 - なんでこうも元の状態に戻ってしまうんだろうか



# セッションのメモ
## 1.まだ守になっていない
・タスクリストの共有だけでPBLｎ優先順位付けができていない
・ふりかえりKPT、Tにたどり着かない
・作り上げたものが課題とずれてリリースできない
　　↓
これって、かつて、見様見真似で始めたスクラムが冷凍保存されていた
「適用」の心が出来ていないまま
内発的動機に駆動されてチームになろう！

## 2.形から入る
機能していなかったのは「検査」と「適用」
→ふりかえりを機能させる

事前記入式のふりかえりのメリデメ
→おだなかさんのチームでは、個人の課題に入りすぎる。文字数も増える。
　共有に時間がかかってしまう

つぎは、カンバン＆ファイブフィンガー、スキルマップ で「透明性」を高める

そうすると、PBIが雑多だ！整理しよう、とか。この先どの行きたいのか？インセプションデッキやろう
スクラムよくわかってない、ということばが出てきた


## 3.チームでハンドルを握る
プランニング
「できること」ベースのプランニングになりやすい状態だった…
　↓
ベロシティ駆動！プロダクトのゴールから次のPBIを選ぶ

一方で、チームからのフィードバックは「達成しなきゃという圧を感じる」
「達成したいことを達成する」マインドだと、なかなかDoneにならない。精神的にツライ。

スプリントの半ばで「リプランニング」を実施
敢えてこれに特化したイベントを設けることで意識が集中する
→DONEが増えた

けど、コミットメントを達成するために残業が増えていた
コミットメント減らしても残業が減らない…なぜ？？？

対話が減ったことで透明性が低くなってしまっていた
→ふりかえり１時間から１．５時間へ。スキルマップ更新

コロナで突然のリモートワーク
→自分たちで何とかしたい、という思いが出てきた


## 4.長い踊り場を乗り越える
手戻りが起こりにくくなっていた
コロナ禍で混雑エリアマップを作った
２か月で出すことができた
周囲の期待よりも早くリリースすることができた

一方で、バーンダウンしない問題が出てきた
→これが当たり前、仕方ない、になっていた
→バーンダウンに向き合うようになった


## 5.自分たちの意思で進む
朝会で一人ずつ共有
→個人で仕事してるんだなぁ、と言われた

人ではなく期待するインクリメント・PBI単位で話すようになった

疑問に思ったこと
「何度となく元の状態に戻ってしまうのか？」
・個人とチームのせめぎあい
・組織における評価は個人単位
・チームの基本ポジションを設定しても、組織・個人のモメンタムで引き戻される
・だからこと「検査」するのが大事！

うまくいったパターンを記録始めた！

そんな中、スクラムガイドが改定され、読み合わせた。
自分たちが、スクラムに適応していたことに気づく！！



～おわり～
VSCodeのスニペット設定のスニペット

この記事 https://qiita.com/282Haniwa/items/82828c6a566e3e7e047d を見てスニペット作ろうと思ったので手始めにスニペット設定オブジェクトのスニペットを作ってみた。

```
{
	"Snippets template": {
		"scope": "",
		"prefix": "snippets",
		"body": [
			"\"${1:name}\": {",
			"    \"scope\": \"${2:javascriipt,typescript}\",",
			"    \"prefix\": \"${1}$3\",",
			"    \"body\": [",
			"         \"$4\"",
			"     ],",
			"    \"description\": \"${1/^(.)(.*)$/${1:/upcase}${2}/}$0 template\"",
			"},",
		],
		"description": "Snippets template"
	},
}
```

参考にした記事では `*.json` となっているけどVSCodeで作ったら `*.code-snippets` というファイルだったのでスコープの指定の仕方が分からなくて未指定にしています。
Regional Scrum Gathering Tokyo 2021 Day 1 「R&Dチームが歩むスクラム守破離ジャーニー」

# Regional Scrum Gathering Tokyo 2021 Day 1 「R&Dチームが歩むスクラム守破離ジャーニー」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14643/r-d

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

# 守にたどり着くまで

2年前に導入したやり方が塩漬けになって、変わっていなかった。
事前記入型のふりかえりでは、個人の話ばかりになっていた。

ふりかえりを機能させて透明性を担保するためにすることとして、

- モブ相談の時間を設ける
- 全員でインセプションデッキをつくったり

など色々な検査と適応を繰り返しながらカイゼンしていき、守にたどり着いた。

# 守から破へ

アジャイルな見積もりと計画づくりに書かれている「コミットメント主導」のプランニングへ変わっていった。
スプリントの先にあるものへと意識が変わっていった。

プリントの半ばでリプランニングを実施して、後半の計画を修正していった
コミットメントを死守するように残業するようになっていった

コミットメントを減らしたら、成果は減って残業も減らない。
互いの状況が分かりにくくなっていた。

**対話の欠如**が起こっていた。

そこでカイゼンを続けていったところで、初めてのリモートワーク。

変わりゆく世界に対応するために、こういう時だからこそ「ふりかえり」だ、という風になっていった

## バーンダウンしない問題への対処

バーンダウンしないのは仕方ない、と現状に甘えていたのを、若手が活をくれた。

## インクリメントにフォーカスした朝会

**「朝会は一人一人話しているから、仕事も個人個人になりますよね」**

## 個人とチームのせめぎあい

- 評価は個人単位
- チームで動こうとしても、組織のモメンタムに引きずられてしまっていた

うまくいったパターンを記録するようにしていった

## スクラムへの適応

いつの間にか、チームがスクラムに適応していることに気付いていた

# そして、離へ

これからも旅路は続く

# 感想

先に進んでは戻って、の繰り返しがすごくリアルでした。チームとして前に進んでいけるように、根気強く問題の根源へと対応していけるよう意識していきたい。
Regional Scrum Gathering Tokyo 2021 Day 1 「本当に大切なものは余白から生み出される。ゆるい1on1のススメ」


# Regional Scrum Gathering Tokyo 2021 Day 1 「本当に大切なものは余白から生み出される。ゆるい1on1のススメ」

2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14796/1on1

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

# 1on1 を始めた背景
- 長南さんの場合
  - 社内での1on1に不満はない
  - むしろ2on1など新しい1on1の形に取り組むこともあった
  - 一方で、時間の制約やアイディアの点と点もつなげたいなど気になるところもあった
- Akiさんの場合
  - この人と話したいなという人を見つけてお話する活動をしていた
  - この人のこともっと話したいな、よく知りたいなという単純な衝動だった

# 1on1開始当初の状況
- 最初はなんか共通点ありそうな、なさそうな
- わかってくると共通点がたくさんあったり互いの関心ごとに興味津々だった
  - パーソナルコーチング、システムコーチング、エグゼクティブコーチング
など

# 1on1にはさまざまな形がある
今回お話しする1on1はひとつのカタチで、こうするべき！みたいな話ではない。
いろいろな1on1があると思うので、書籍も参考にしてみてください。

# 1on1で起こりやすいモヤモヤ
- 時間の制約があると雑談にするのが難しい
- どうしても力関係があるよね
- 問題解決にいきがち
- ソフトスキルに影響している

# 興味範囲が近しい人との1on1は？
- 緊張状態にある話もいいし、そこを抜けて脱緊張状態にある話もよい
- 価値を提供しているか？をそこまで気にしなくて良い

# ゆるい1on1から分かった5つのこと
## その1. 私たちの1on1にあるもの、ないもの
**始め方**

- 「私たちの1on1」
    - 自分たちで創った関係
- 「もしそうだったら私たちには合わない1on1」
    - 作られた関係（仕事でも創り出した関係ならそうならないよね）

**口癖**


- 「私たちの1on1」：
    - 「そういえば～」
    - 「全然関係ないんですけど～」
    - 「話変わるけど～」
    - 話始めにはどんな終わりになるか把握できてない

- 「もしそうだったら私たちには合わない1on1」
    - （はやくおわらないかなぁ・・・）
    - （この時間はなんなんやろ？）
    - （この人は自分をどうしたいんだろう？）
    - と考えてしまう

# その2. 雑談、脱線の重要性
- 私たちの場合盛り上がって脱線することを本懐としている
- 脱線したら本望
- 雑談トピックの一例
    - 人生の目的
    - zoomハートエクササイズ
    - VAK
    - ワークショップデザイン
    - などなど
- 1on1の相手によって雑談の内容は変わる

### なぜ雑談が盛り上がるのか？
- 共通点と相違点のバランス
 - 弱い紐帯
- DTA
- 心理的安全性
    - 一見ムダとも思えるようなことでも話せる関係性
    - だいたいのことは許せる
- 初対面だと仲良くなれない。雑談できない。
  - みたいな意見もあるけれど、それは初対面だからではないような...
  - 何か共通点やきっかけがあると、初対面や出会って数日でも雑談は盛り上がる

## その3. 余白に溶け出していく情報ってあるよね
- 「情報・感情の浸透圧」という考え方
- 場の圧力が低いと、思いつきや突拍子もないことが出やすい。そして、それが意外と本質的ななにかだったりする…

## その4. 弱い紐帯の強さ
- 社会学における「弱い紐帯の強み」

- 強い紐帯である家族・親友・職場の同僚のように、生活環境や価値観が似ている人は、新しい情報が入ってきづらい。
- 弱い紐帯である友達の友達や知り合いはライフスタイルや価値観が違うことが多いので、受けてにとって価値の高い情報が多くなる。

- 弱い紐帯によってコミュニティがより強くなるのでは？

## その5. DTA, Working Agreement
- DTA：チームやパートナー感の意図的な協力関係の構築
- DTAがあることのメリットは**心地よさ**
- 心地よさはチームによって違う
    - 互いの多様性をどう認め合うか
    - お互いをどう認め合い、その場にコミットし、意図的な協働関係を築くのか
    - という話ができればいい
- 「ふたりは...」「チームにとって…」
  - 「この場をどんな雰囲気にしたいか？」
  - 困難な時「お互いにどんな責任を持ちますか？」
  
- Working Agreementとは
  - ともに活動するうえでの合意事項
  - 創る過程で様々な対話が生まれて便利

- Working Agreementもさまざま
  - ルールとか決め事が多い世界は自分にとってはツラかった

- Working Agreementを、なぜ創っているのか？
- Working Agreementを創るときにどういう事を話し合えていればいいのか？

- **「ビジョンがなんであるかではなく、ビジョンが何をするか大切なんだ」 by ロバート・フリッツ**

# まとめ
実際に1on1を1年間やってみて...  

- 仕事以外のふとしたつながりが活力になることもある
  - 仕事で行き詰ったとき
  - 専業主婦、入院、産前休業
- 社会と隔絶されそうなこの瞬間に、この場はありがたい

## この人と話したい!!駆動
ただただこの人と話したいなぁという人を見つけて、お話すればよい  
1. 前々から会うたびに「またお話しましょう」と言ってたけど、実現できてなかった人とか
2. ちょっとこの人の雰囲気いいなぁと思っていた人とか
3. 日程決めちゃえ！

# 感想
- 1on1 で何か成果を出さなければと勝手に考えていましたが、ゆるさも大事だなと気が付くことができました。
- こんな1on1だったら楽しそうと思える内容でした。
- 創られた1on1だけではなく、自分が話したいと思う人と1on1してみようと思います。
ターミナル、行単位で文字を一気に消したい時

# ctrl + u
カーソルより後の文字列を全て削除する。

```
例
｜aaaaaaaaaaaaaaaaaaaaaaa

↓

｜
```

# ctrl + k
カーソルより前の文字列を全て削除する。

```
例
aaaaaaaaaaaaaaaaaaaaaaa｜

↓

｜
```
【注意】mecabでシステム辞書やユーザー辞書を指定する【Windows】

MeCabをpythonで利用していて辞書指定で引っかかったことがあったので備忘録として残しておく。
1つの処理の間でユーザ辞書を切り替える必要があったことが背景になっている。

mecabの公式ページは以下。
https://taku910.github.io/mecab/
大体のことはここに書いてあるが、懇切丁寧に書いてあるわけではないので別途調べる必要がある。
mecabはWindowsを前提に作られているわけではなく、調べて出てくるドキュメントもWindows向けのものが少なかった印象。

# 結論
パスは`¥`や`\`で区切らずにせずに`/`で区切れ
**辞書へのパス指定時にスペースを入れるな**

**※追記※**
mecab-python3の場合はスペースがあってもクォーテーションで囲えば正常に動作します。
`pip install mecab-python3`
@palm23さん教えていただきありがとうございました。

# 解説
ここではpythonコードから辞書指定をするときについて解説する。

ちなみにコマンドラインから実行する場合はスペースがあっても問題ない。
ただ、スペースで区切りとみなされるためパス全体を`""`で覆うこと

```
# システム辞書指定
mecab -d "C:\Program Files (x86)\MeCab\dic\ipadic"

# ユーザ辞書指定
mecab -u "C:\Program Files (x86)\MeCab\dic\ipadic\user.dic"
```
※ユーザ辞書は自分が作成して置いたパスを指定する（作成方法は別途調べてください。）

## pythonコードから辞書指定
辞書指定するときにはTagger作成時に引数に渡す必要がある

```
import MeCab

tagger = MeCab.Tagger("-d [システム辞書へのパス]")
tagger = MeCab.Tagger("-u [ユーザ辞書へのパス]")
```

Windowsの場合、多分`C:\Program Files (x86)\MeCab\dic\ipadic`に辞書があるはず。（x86じゃない方の可能性も）

それを上記の[辞書へのパス]に書くのだが2つ注意点がある。

1. パスは`/`で区切らなくてはならない
2. スペースを入れてはならない

どちらもMeCabの仕様ではなくpythonの仕様によるもの。

### パスは`/`で区切らなくてはならない
文字列のダブルクォーテーション`""`の中で`¥`や`\`を使うとエスケープ文字とみなされてしまう。

```
import MeCab

tagger = MeCab.Tagger("-d C:\Program Files (x86)\MeCab\dic\ipadic")
tagger = MeCab.Tagger("-u C:\Program Files (x86)\MeCab\dic\ipadic\user.dic")

ではなく

tagger = MeCab.Tagger("-d C:/Program Files (x86)/MeCab/dic/ipadic")
tagger = MeCab.Tagger("-u C:/Program Files (x86)/MeCab/dic/ipadic/user.dic")
```
※ユーザ辞書は自分が作成して置いたパスを指定する（作成方法は別途調べてください。）

これはVSCodeなどのエディタを使っていればエラーとして表示してくれるためすぐに気付ける。

※追記※
他の解決策として
`r"-d C:\Program Files (x86)\MeCab\dic\ipadic"`
のように文字列の前にrをつけることで`¥`や`\`のままでも問題なく動作します。
@palm23さん教えていただきありがとうございました。

### スペースを入れてはならない
デフォルトだと`C:\Program Files (x86)\MeCab\dic\ipadic`に辞書があると思うが、`Program Files (x86)`にスペースが入っているとエラーになる。

辞書指定したいのならば、パスにスペースを含まない別の場所に辞書をコピーし、その辞書を指定する必要がある。
例えばC直下にmecabというフォルダを作成して辞書を配置し、以下のように指定する。

```
import MeCab

tagger = MeCab.Tagger("-d C:/mecab/ipadic")
tagger = MeCab.Tagger("-u C:/mecab/ipadic/user.dic")
```

※スペースがあるのがだめならクォーテーションで囲んでやればいいのでは？
`tagger = MeCab.Tagger("-d 'C:/Program Files (x86)/MeCab/dic/ipadic'")`
残念ながらこれでもエラーになる。

# まとめ
mecabに限らず、pythonでパスを指定するときは、

* パスは`¥`や`\`で区切らずにせずに`/`で区切れ（もしくは`r""`）
* **辞書へのパス指定時にスペースを入れるな**（もしくはmecab-python3を使う）
Unity 2019.4 でコマンドラインから sln, csproj ファイルを作成する。


# 目的

CI から sln ファイルを扱いたかったのですが、通常 Unity プロジェクトの git リポジトリに sln ファイルは含めないです。

コマンドラインから sln ファイルを作成することで CI で sln ファイルを扱うことが出来るようになります。

## sln ファイルでやりたいこと

sln ファイルがあれば msbuild が利用できます。
たとえば `msbuild project.sln -warnAsError` を CI 中に仕込むことで、Unity プロジェクトに警告があった場合に CI を失敗させるなどで利用できます。

# 方法

batchmode で UnityEditor.SyncVS.SyncSolution メソッドを実行します。

以下が実行例です。

```sh
Unity.exe -batchmode -nographics -logFile - -executeMethod UnityEditor.SyncVS.SyncSolution -projectPath . -quit
```

# 参考

- forrum
  - https://forum.unity.com/threads/any-way-to-tell-unity-to-generate-the-sln-file-via-script-or-command-line.392314/
Regional Scrum Gathering Tokyo 2021 Day 1 「アジャイルを忘れるチーム Unlearn Agile」


2021/01/06に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14735/unlearn-agile

# チーム参加してきました

[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。


2020年まで、チームにミームを残す仕組みづくり
アジャイルからNature of Teamへとたどり着いた


パタンランゲージ
- **つよくてニューゲーム**
	- 繰り返し作業は効率がよい
- **脊髄感謝**
	- ネガティブフィードバックは萎縮をゆっくりとした口調は大切に聞こえる
	- なぜうまくいくのか、という会話につながる
- **ついでの一仕事**
	- 変化は小さいほど簡単、なにかをやり始めるのはコストがかかる

良い共同作業から**心地いい共同作業**へ
心地いい共同作業、その理由をオンサイト、オフサイトで意見を出し合い。
- お互いの知識経験をぶつけ合い成長していくところ
- お互いリスペクト
- 下の中華（最後は飲みに行く）
- 安心する感じ
など、約3分間でみんなの意見が集まった

移籍先にパタンランゲージを持ち込む
- パタンを使うことに執着してしまい、良い建築になっていません
	- 手法を使うことを意識しすぎると、アジャイル開発はできない

47機関のミームをもつ生き生きしているチームは、何がその要因なのか
- チーム[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)
- 筑波大学　チーム　エンピット

超個体としての
- 攻殻機動隊
- キノコアリ
- 軍隊蟻

[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)やエンピットは客観できるくらい深い直観や深い共感を大切にするマインドが47機関と共通していたのかもしれない。

パタンの成立にはコミットメントの量、コミットメントのパスがあると考えている
パタン導入の失敗は成立条件を知らないから

原則から入るではない、直観を大切にする

チームの秩序マップ
ルール、原則、ガイド ＞ 実験 ＞ 直観＆客観、深い共感　の順に含まれる

深い直観の共感を中心に構えるチーム

# Q&A
- 秩序マップの「実験」とは？
	- 言葉遣いに注意するとか、フィールドワークするとか
	- なぜフィールドワークするのか？といった共感は持っている。
	- 共感が中心にあることが重要だと考えている

# 感想
- 途中のワークショップで近くの方と話し合った、「心地いい共同作業」で、チームの共感性が高いと感じました。
- 同じようにモブプロをしているメンバーであっても、個々人のモチベーションに違いが出たりすることや、個々人でのコミットメントのキャパシティが違うということが、ワークショップで会話する中で学びになりました。
斎藤さんゲーム


![saitousa Diagram.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481470/f288e006-75c9-3915-7181-3231b72538dc.png)

ランダム関数を使って
・0から3の時→何もなし
・3から6の時→ぺっぺぺー
・6から10の時→斎藤さんだぞぉ

をアラートで表示

こちらから遊べます！
↓
https://u-hoshi.github.io/saitousanGame/

ソースコードはこちら
https://github.com/u-Hoshi/saitousanGame
AWS管理コンソールにIP制限をかける

## AWS管理のセキュリティの向上
AWSの管理コンソールに対して社内IPからの制限をかけることにした。これによりAccessKey/SecretKeyが万が一漏れても社内IPからしか接続できないためセキュリティの向上を行うことができる。
ただし、デメリットもあり会社が入っている建物が定期点検のためにルータを落としたりする場合は一切接続ができなくなってしまうのでいくつかのアカウントはIP制限をしないようにする必要がある。


## グループに適用する
一つ一つのユーザに対してポリシーをアタッチするのはナンセンスなためグループを作成してそのグループに所属したメンバーはIP制限が適用されるようにする。

## ポリシーの作成
以下のポリシーを作成する。 `aws:SourceIp`で許可するIPを記載する。

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AdministratorAccess",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Sid": "SourceIPRestriction",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "111.222.333.444/32",
                        "1.111.222.333",
                        "2.111.222.333"
                    ]
                }
            }
        }
    ]
}
```

## ロールの作成
適用なロールを作って上記で作成したポリシーを適用する。

## グループの作成
グループを作成してロールを適用する。

## メンバーを参加
メンバーをグループに参加させる。


## 確認してみる
AWSの管理コンソールに対してかけたIP以外からログインしてみるとログイン後、以下のようなAPIエラーが出る。

![ScreenShot 2021-01-06 10.46.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/79473/de139537-8f67-1362-3c6b-d4dbddd99739.png)

次にAWS CLIでS3コマンドを叩いてみる

```
# aws s3 ls
An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied
```

次に社内からアクセスすると上記のようなエラーが出ないことを確認できた。
GASとスプシで仮想通貨の価格を取得＆記録

# 課題
仮想通貨の取引では、なんやかんやで**行き当たりばっかり**の取引をしがちである。
数字や理論に基づいた取引の練習がしにくい。

# 解決策
タイムスタンプ、取引価格をボタンクリックで取得し、その横に、自分の現在の市場に対する仮説をメモできる仕組みを作った。
これにより、これからは取引に失敗or成功しようと、その時の自分の仮説を検証でき、徐々に仮説の精度をあげる練習を**継続的**に行えうる。![スクリーンショット 2021-01-06 10.44.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/614389/90c34213-781a-12a2-7880-e28f99ff7702.png)

デモはこちら
https://youtu.be/-6Mb4v2YSpk

# 使用技術
Google Apps Script
Google Spreadsheets
bifFlyer Lightning API　（詳細： https://api.bitflyer.jp/ ）

# GASソースコード

```js:GAS

function setValues() {
  const spreadsheet = SpreadsheetApp.getActive()
  const lastRow = spreadsheet.getLastRow()
  const response = JSON.parse(getResponseFromBitflyerAPI())
  setTime(spreadsheet, lastRow)
  setBTCPrice(spreadsheet, lastRow,response)
  setVolume(spreadsheet, lastRow,response)

}

function setTime(spreadsheet, lastRow) {
  const date = new Date()
  spreadsheet.getRange(`A${lastRow + 1}`).setValue(date)
}

function setBTCPrice(spreadsheet, lastRow, response) {
  const ltp = response.ltp
  spreadsheet.getRange(`B${lastRow + 1}`).setValue(ltp)
}

function setVolume(spreadsheet,lastRow,response){
  const volume= response.volume
  Logger.log(volume)
  spreadsheet.getRange(`C${lastRow + 1}`).setValue(volume)
}

function getResponseFromBitflyerAPI() {
  const getURL = 'https://api.bitflyer.jp//v1/ticker'
  const response = UrlFetchApp.fetch(getURL).getContentText()
  return response
}

```

# 解説
この記事見てる人はGASには詳しいと思われるので、詳しい説明は割愛します。
以下、端的にコメントをします：
・SpreadsheetAppのAPIの呼び出し回数を少なくする必要がある
・API利用はURLFetchAppを使い、それをJSON.parseでJavaScriptのオブジェクト形式にする
・スプレッドシート側では、時刻には表示形式を時刻に、価格には価格と明示的に設定しましょう。
→そうしなければ、BTCの価格が時刻と認識されたりして、おかしな表示になります。
・図形描画にスクリプトを割り当てればGUIで操作できる

# GASで楽しい毎日を！
GASを使えば、GUIで外部サービスとGoogle Appsを連携させ便利な操作ができます。
業務効率化として使わないという選択肢はありません！
それでは、素晴らしいエンジニアライフを！後、cryptoライフを！
RSGT2021セッション参加レポート：アジャイルを忘れるチーム Unlearn Agile（Day1 10:00-10:45）

# はじめに
このページは、RSGT2021で参加したセッションのレポートを書いたものです
https://2021.scrumgatheringtokyo.org/


# このセッションの概要
【タイトル】
Day1 10:00～10:45
アジャイルを忘れるチーム Unlearn Agile

【Confgineのセッションページ】
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14735/unlearn-agile


# 感想などのピックアップ
### 【感想】
 - 動画がかっこいい！
 - 講演＆参加者同士の会話 の構成で、学びが深まる
 - オンラインとオフラインのハイブリット、良い感じ！
 - パタンランゲージアレグザンダー、勉強してみよう！！！


### 【気になったキーワード】
 - KPT as ART：感性と向き合うようなふりかえり！？
 - パターンランゲージ
 - 心地いい共同作業
 - コミットメントポイントとコミットメントパス
 - 深い直観でみちびかれる共感
 - 直観はなぜ「観」を使うのか→アレグザンダー由来
 - 原則から入るのではない、直観から入る


# セッションのメモ
ここからはセッションのメモを書いていきます
47機関 ってのはきょんさんのチーム名みたい

## パターンランゲージ
きょんさんのチームでのお話
##### つよくてニューゲーム
・２回目にやるのはやりやすい
　これをチームでは「つよくてニューゲームだね」と言っている
　なぜこれが成り立つのか？
　→うちのチームでは、繰り返し作業は効率が良い

##### 脊髄感謝
・ネガティブフィードバックは萎縮を生む
・ゆっくりとした口調は大切に聴こえる

##### ついでの一仕事
新しい習慣をつくるのは大変
小さい変化ほど簡単

なぜこれが成り立つのか？
→心地いい共同作業


## 心地よい共同作業
★ワーク★
いろんなここちよさを参加者が出しあう

※これが、後述の「直観」とか「深い共感」とかにつながっている


## コンテキストをどうやって他のひとに伝える？
アレクザンダーさんの言葉
　”パタンを使うことに執着してしまい良い建築になっていません”
攻殻機動隊
　"規範の中にいるときはそれを窮屈と感じるけど、規範なき行為はまた行為として成立していない"

47機関の「ミーム」をもつ
活き活きしているチーム
何がその要因なのか？

きょんさんのプレゼンのキーワード
・超個体としての
・攻殻機動隊
・軍隊蟻
・キノコアリ
　→これらを理解し、自分たちのチームに取り込んできた
　→これが良いと思い、この状態を目指したいと思う「直観」

　直観できた
　客観できるような深い直観
　チームで深い共感が出来ている


うまくいっているパタンがあった
・コミットメントの量（コミットメントポイント）
・コミットメントパス（チームメンバのうちコミットメントする割合）
　↓
パタンの成立条件がある

なんでもやればよい？ってわけじゃない。コミットメント量には実質上制限がある
制約の中で組み合わせる

チームの生命構造
チームのセンター

チームの秩序マップ
ルール 原則 ガイド
　実験
　　直観＆客観 深い共感

★ここでワーク★
さっきあげた心地よい共同作業は、チームの秩序マップのどこにあたる？

## QAコーナー
・直「観」は、アレグザンダー由来
・共感だけでは秩序は生まれにくいのかも。実験して秩序に至る。これをぐるぐる繰り返す


おわり
Building for iOS Simulator, but the linked and embedded framework 'XXX.framework' was built for iOS + iOS Simulator. に対応した

Xcodeを12.3にした所、
「Building for iOS Simulator, but the linked and embedded framework 'XXX.framework' was built for iOS + iOS Simulator.」
が発生する様になってしまったので対応したメモ

#ググってやった事
・Build Settings - Architectures - Excluded Architectures - Debugに
Any iOS Simulator SDKを追加し、
[arm64 arm64e armv7]を設定

・Build Settings - Build Options - Validate Workspace - Debugの設定をNoからYESに変更

この変更でエラーから警告に変わって取り合えずデバッグ出来る様にはなった。

参照先　https://stackoverflow.com/questions/65303304/xcode-12-3-building-for-ios-simulator-but-the-linked-and-embedded-framework-wa

Archiveを実行した所上記設定だけだとエラーとなってしまったので、
・Build Settings - Build Options - Validate Workspace - Distributionの設定をNoからYESに変更

この変更でエラーから警告に変わって取り合えずArchive出来る様にはなった。

#追記その１　エラーも警告も無くなった
今まで変更してきた設定を元に戻し、
Build Settings - Architectures - Excluded Architectures - Debugに
Any iOS Simulator SDKを追加し、
[arm64 arm64e armv7]ではなく[XXX.framework]を設定した所、
エラーも警告も無くなった。

#追記その２
追記その１では[XXX.framework]を設定したが、
今は[arm64]としているが自分の環境では特に問題ない。