味の素スタジアムでJリーグ観戦Tips 缶・ビンは持ち込み禁止だが、入ったあとに紙コップとホルダーがもらえる

2019/4/14 人生で初めてJリーグを観戦した。
FC東京 vs 鹿島アントラーズ。
すごい人の数で、39000弱くらい入っていた。
もっと過疎ってると思ったら大間違い。
場所は、味の素スタジアム。
京王線の飛田給から人の数がすごくて、なかなか前に進まない。
サッカーってこんなに人気があるんだ！

FC東京は現段階で首位だからなのか、”東京”のクラブだからサポーターも多いのか、よくわからない。

で、観戦中にお酒を飲みたいじゃないですか。
でも公式サイトには、缶・ビン持ち込み禁止と書いてある。
スタジアムの中のお酒は、普通の缶、たとえばトリスハイボールが355mlで400円でちょっと高い。
今回はじめてだったので、それを買ったが、缶を外のコンビニとかで買って、
入場前に紙コップに移し替えるサービスが（おそらく無料で）あった。

なので今後はこの方式でいったほうが少し安くなる。
ちょっとした観戦Tips。

ちなみに座った場所は、ホームセンター自由という場所で、B35とかいうところなので、飛田給から行くと反対側で結構歩く。

Scala ちょこっと Tips

Scalaで絶対値をとる

import scala.math._

object Main {
  def main(args: Array[String]): Unit = {
    println(abs(-1)) // 絶対値   1が出力される
  }
}

Scalaで型変換( String -> Int )

object Main {
  def main(args: Array[String]): Unit = {
    println("100".toInt)
  }
}

ボクらのScala ~ 次世代Java徹底入門

Scalaスケーラブルプログラミング第3版

WindowsユーザがLinuxを学ぶ良い方法

以下の４分野を学習しなおしている。

1. Linux
2. Scala
3. 機械学習
4. AWS

Linuxとにかく使おうと思っているのだが、WindowsユーザがLinuxを学ぶには以下の方法がお手軽。

Oracle VMをWindowsに入れる。

www.oracle.com

CentOSまたはUbuntuをVM上で動かす。

www.centos.org

Linuxどこからーって感じだと以下の本を買って一通り操作すると、表面的なことはわかる。
起動方法から、よく使うコマンド、シェルスクリプト、パッケージ管理まで。

新しいLinuxの教科書

コーチング資格の代表的なパス

コーチングの資格パスを整理してみました。
すごいお金かかります。少なくとも150万はかかります。
時間もかかります。

他にもいろいろやり方があるみたいですけど、代表的なパスとういことで。

あと、ACC以降は基本英語で読み書きが必要で、MCCは英語でコーチングしていないとだめかもしれません。結構な英語力は必須。

複数チームでスクラムを実践する際の注意点

最近徐々にですが、日本のソフトウェア開発においても、アジャイル開発が採用されることが増えてきました。 2018年のAgile Japanは（私は参加しませんでしたが）参加者400名ほどのうち、250名ほどが新規参加者だったようです。

Agile Japanは日本の大手メーカーも参加するようなイベントになっています。 アジャイル開発が注目されつつある、ということなのでしょうか。

アジャイル開発で最もよく活用されているのが、スクラムです。6～7割。

http://www.agile247.pl/wp-content/uploads/2017/04/versionone-11th-annual-state-of-agile-report.pdf

1チームでのスクラムはうまくいくけど、複数チームになるとうまくいかなくなる、ということがあります。
これだからアジャイル開発は…と言われそうですが、アジャイルは大規模でもスケールしますし、組織や会社を変えていくチャンスとなります。

１チームでのスクラムを実践し、うまくいったのでスケールさせたい、複数チームでスクラムを行いたいと言った際の注意点をまとめます。
（『ドキュメンテーションをしっかりする』、とかじゃないからご心配なく！）

前提の確認ですが、ここで言う『複数チーム』は、2～8チームを想定しています。開発人数は合計で10～70人程度。
（それ以上になってくるとプロダクトバックログの扱いが変わってきます）


注意事項は7つです。

1. 1人のPO。
2. 1つのプロダクトバックログ。
3. ユーザ体験ベースのプロダクトバックログアイテム
4. スプリントの期間を（なるべく）各チーム同一にする。
5. 各チームのスクラムのイベントは同じ時間に実施する。(振り返り・朝会は除く)
6. スプリントバックログはチーム毎に作成する。
7. スプリントレビューは全員で行う。

それぞれ見ていきましょう。

1人のPO。

プロダクトオーナーは1人です。チーム数が多くなったからといってプロダクトオーナーが増える訳ではありません。
1プロダクト、1プロダクトオーナー。これは揺るぎないです。
もし複数人になってしまった場合、優先順位付け時に混乱が生じる可能性が高まります。
『決定』の迅速性も失われます。プロダクトオーナー全員の予定をあわせる必要が出てきます。
大きなプロダクトを作っているプロダクトオーナーだから非常に忙しいと思います。
それをチームとスクラムマスターでサポートしましょう。プロダクトオーナーは、プロダクトに関する『最終』意思決定者です。

チームは、プロダクトオーナーが迅速に決定ができるようにサポートをします。
複数案あったとして、どんなメリット・デメリットがあるのか、技術的な視点だけではく、マーケットやコストなど様々な視点で土俵に載せましょう。
そうしないとプロダクトオーナーは『迅速に』『最終』決定できないかもしれません。
あくまで『最終』です。逆にいうと、決定に至る過程からプロダクトオーナーは介入すべきではないかもしれません。
そして、忙しいんだから敢えて、どんどん密にプロダクトオーナーと連携しましょう。
忙しいと声をかけづらくなるというのはわかります。プロダクトオーナーもそれに応えるべきです。

スクラムマスターは、プロダクトオーナーが忙しいのであれば、忙しさを除去できるために何かできることがないかを検討します。
プロダクトオーナーが行っている意思決定の種類を分析し、可能であれば、チームにより権限を移譲します。
また、プロダクトオーナーとチームがより密に連携できるような場作りも大切な仕事です。

プロダクトオーナを複数人にすることはお薦めできません。

1つのプロダクトバックログ。

プロダクトバックログが複数あると、一意な優先順位がつけられません。
一意な優先順位がつけられないと、チームが何に注力するべきかがわからなくなります。
チーム毎にプロダクトバックログが存在すると、各チームがそれぞれの目標に向かって進むことになります。
結局全体性が損なわれます。チームをまたいだ助け合いもしづらくなります。

ユーザ体験ベースのプロダクトバックログアイテム。

プロダクトバックログが、仮説検証型になっているかどうか、それがユーザ体験に基づいているかどうかがキモになります。
INVESTを意識して。
これが一番むずかしいかも。 INVESTは以下の記事を参考に。

appresso.hatenablog.com

スプリントの期間を（なるべく）各チーム同一にする。

以下のような状態を避けようということです。

チーム名 スプリント期間
Aチーム 2週間
Bチーム 3週間
Cチーム 4週間

この場合、最悪なのは、AチームとBチームのスプリントレビューで顔をあわせる機会が6週間に1回になってしまうことです。
複数チームの場合、どれだけコミュニケーションの密度を増やせるかが鍵となります。

Bチームが1週間スプリントになった場合は、AとBは2週間で同期が取れますが、Cチームは以前4週間またなくてはなりません。
キツイです。疎遠となります。
経験的には、苦しくてもスプリント期間は1週間か2週間が良いと思います。集中力が続くプランニングしきれる範囲となります。

チーム名 スプリント期間
Aチーム 1週間
Bチーム 1週間
Cチーム 2週間

本当は全チーム同一期間が良いとは思いますが、上記も許容できるかもしれません。

各チームのスクラムのイベントは同じ時間に実施する。(振り返り・朝会は除く)

振り返りと朝会はチームのためのものですので、チーム毎に時間を決めて頂いて構いません。
スプリントプランニング、プロダクトバックログリファインメント、スプリントレビューは各チーム同じ時間にやることが望ましいです。
なぜなら、チームをまたがる相談事項というものがでてきた際に、全チームがプランニングやリファインメントをしていれば非常に聞きやすくなりますし、
複数人同士での議論にも発展させやすいです。
これが時間がバラバラだと、会議招集をする必要が生じたり、会議の時間をとったりと、会議が増えていきます。
チーム間の壁って、スクラムだとしても出てきてしまいます。それを出さないようにする工夫は必要ですね。

5.スプリントバックログはチーム毎に作成する。
これはあまり間違わないと思いますが、念の為出しておきました。
チーム毎に、このスプリントで実施するプロダクトバックログ・アイテムを取ってきて、チーム毎にプランニングします。
当然、スプリントバックログはチーム毎に作成されます。

スプリントレビューは全員で行う。

スプリントレビューは全員で行い、様々な知見をプロダクトに反映させます。
プロダクトオーナーとチームだけではなく、ステークホルダーも含めて行いたいところです。
人数が多くなると会議形式だと非効率・かつ眠くなる・内職が多くなるので、なるべくワークショップ化しましょう。
LeSSでは『バザール』という形式をとって、見本市のようなやり方でスプリントレビューを行う手法が紹介されています。

Sprint Review - Large Scale Scrum (LeSS)

イメージはこんな感じ。
www.safaribooksonline.com

以上、複数チームでスクラムを実践する際の注意点を記載してみました。
可能であれば、Large Scale Scrum (LeSS) などの大規模スクラムのフレームワークを守破離の『守』として活用したほうがいいと思います。

次回は、LeSSを活用する上での注意点をまとめます。

英会話まったく続かないどうしよう

超悩んでいることがあります。 英会話がまったく続かないです。

Best Teacherは1ヶ月でやめちゃったし。 やめちゃった原因は、なんかテキストの読み合わせみたいな感じになっちゃうんですよね。

会話もネタがないし、なんかつまんなくなっちゃって。

難しいことはわかりませんが、英語が話せる方法を教えてください!

で、上記を読んでみた。

やるべきことは以下３つ。

1. 定期的にスピーキングテストを受ける
2. 海外ドラマを見る。
3. オンライン英会話を毎日続ける

だそうです。

オンライン英会話毎日続かなかった。。 でもたしかに定期的なスピーキングテストは受けていなかった。 ネタにも苦労する。

コーチ・エイとCTI Co-Active コーチングの違い

お久しぶりです。

毎日が慌ただしく過ぎていくので、ほとんどブログが更新できておりませんでした。

CTI JapanのCo-Active Coachingのコアコースも受講しています。
7/14,15,16とCo-Active Coachingの基礎編を受講しました。

www.thecoaches.co.jp

続いて応用コースも受講予定です。
コースでは多くの仲間が増えました。感謝です。皆モチベーション高し。
コーチングの凄さも体験できました。いろいろフラッシュバック。昔の自分を思い出す。

Co-Activeでは『コーチングとはこう進めるべきだ！』という教科書はほとんど存在せず、
『今、この瞬間から創る』
とか
『その人すべてに焦点をあてる』
とか
そんな感じで割とフワッとしているので、受講者の中には戸惑いを隠せない方もいらっしゃるようでした。
私は割とフワッと系なので馴染みました。応用コースが楽しみです。
コーチングは筋力と瞬発力だなと思いました。
なので早速トレーニング。

コーチング・フェローズ

コースとはほぼ関係ないのですが、コーチ・エイとCTIの違いは面白くて、以下、全くの個人の感覚ですが、
コーチ・エイ
　Business型
　コンサル型
　計画主導（ゴールから考える）
　ウォーターフォール
　IBM型
　ネクタイ
CTI
　Life型
　シンクタンク型
　先の未来を考えすぎない（今、ここ）
　アジャイル/スクラム
　Google型
ラフ
という感じです。
どちらが優れいているというのはなくて、おそらくリンゴとみかんぐらい違うのではないかと思います。
私は断然CTIのほうが好み。

基礎編ではクライアントにこんな質問をしたらいいじゃないということは教えてくれませんでしたが、
私は魔法の質問をたくさん探しているのです。

なので The Great Scrum Masterから引用します。

The Great ScrumMaster: #ScrumMasterWay (Addison-Wesley Signature Series (Cohn))

・あなたは何を達成したいのですが？
・あなたは何を変化させたいのですが？
・あなたは何を得たいのですか？
・今あなたにとって重要なことはなんですか？
・何がよく機能していますか？
・これまでにどのような進歩がありましたか？
・あなたのゴールを達成するために変えなければならないことは何ですか？
・それについてあなたが何ができますか？
・あなたは何を違うことができますか？
・あなたはなにかをやめる必要がありますか？
・他には？
・次は何ですか？