最近久々に元気・ポジティブな状態で頑張れるようになってきた

1年半〜2年くらい前から「う〜ん疲れちゃった…」ってなって、省エネ状態で暮らしていました。
正直昔から頑張れるパワーには波がありますが、ここ2年くらいは人生で1番やる気がなくなっていて、「頑張っても周りの人の足元にも及ばない…」「仮に何かうまくいったとして、人類史に何が残るんだ…」「寝ていたほうがトータルの幸福度は高い」などと考えてふにゃふにゃでした。ちなみにここでいうやる気というのは主に趣味や自己研鑽、コミュニティ活動などオフ時間の頑張りに直結するものです。

かつては何の疑いもなく「頑張る」ことを正としていたにもかかわらず、段々とそのコスパに目がいってしまったこと、背伸びして頑張り続けるのが大変だと知ったことにより立ち止まってしまったようです。

永遠に布団にいる日もあったし、お医者さんにちょっと相談してみたりもしたけど、前職の友にもらった「長い人生だから立ち止まる時間があっても大丈夫」といった力強くありがたい言葉を胸に割とのんびりしていました。その間ちょうどコロナで家にいることも増えて、色々なことを考えました。

  • なんか何事も進捗がない感じがするな〜でも別にそれでも困らないな〜今後も一生この感じでいこうかな〜
  • コロナで大変な世の中だけど自分は何もできないな〜自分がやることが世にとってプラスになるかどうかもっと考えてみたいな〜
  • 今まで何故頑張ってきたんだろう〜これから何を目指して生きていくんだろう〜
  • とにかく好きな人達と関わりを持ち続けながら暮らすのが自分にとっては幸せだな〜そのためには時間やお金や色々な余裕があった方がいいのかな〜

ゆったりした生活による空き時間で、以前はあまりやらなかったゲームをするようになったり、久々な知人に積極的に「元気?」と連絡してみたり、行動にも小さな変化があった気がします。
いずれも「疲れちゃった…」とステイホームが重なったことによるものだと思われますが、「自分は何を考えているのか/大事にしているのか」を考える時間、やらなかったことや疎遠だった人に割く時間が増えたのは結果として良かったみたいです。

結局、立ち止まって色々考えているうちに具体的に実現したい目標ができて、最近漸く浮上してきました。

ということで、このツイートをしたあたりから自分でも驚くほどみるみる元気になってきて、省エネモードはいったん終わりを迎えたのでした。たまには自分との対話に集中してみるもの良いものですね。そして目指すものがあると何をすべきか分かりやすくてとても良い…。

自分の傾向をふまえるとこういうことなのかなという整理もできたので、適度に頑張り続ける生き方を今は選んでみます。

早速、前より起きている時間はめちゃくちゃ長くなったのにやりたいことが片付かなくなりつつあります。つまりはやはり波の大きい人間なんですが、今後は次のレベルアップとしてその波を小さくしていくところを目指します。安定感!

英語のプロフィール(bio)をネイティブな友人に添削して頂いた

biography。バイオ。カンファレンスとかで使うお仕事感あるプロフィールを添削してもらったので知見をメモしておこう。

私が書いたオリジナル

Ayana Yokota is a Developer Advocate at JFrog. Originally she was a web developer, having a background in backend engineering, and experienced various companies. These days developers community management is her favorite activity. She is a founder and organizer of Javajo (the Java Community for women in Japan), and also organizes Japan Java User Group. An author of "The easiest textbook of Git and GitHub".

添削してもらったバージョン

Ayana Yokota is currently a Developer Advocate at JFrog. She began her career as a web developer, having a background in backend engineering gained through experience at various companies. These days, management of the developers community is her favorite activity. She is a founder and organizer of Javajo (theJava Community for women in Japan), and also a board member of the Japan Java User Group. Co-author of "The easiest textbook of Git and GitHub".

教えてもらった/話したこと

私: ほとんどの主語がAyana(She)になってしまったけどどうしたらいい?一応These daysで始まる文は主語を変えたのと、最後の文にはくどいのでShe isを付けなかった。
友: ふつう同じ主語が続くことを避けた方が良いのは確かだけど、今回は短いしAyanaのbioなので問題ない。最後の文は主語がなくても明らかだし読みやすくなるので良い工夫だね。

.
友: いろんな会社での経験があることを表すためにgained through experience at various companiesとか付けてみるのはどう?
私: 素晴らしい…gained throughとか自分では思いつかない。

.
私: Java女子部もJJUGも運営メンバーだけど、Java女子部の方だけ設立にも携わってる。これをスマートに表現するのが意外と難しい。a founder and organizer of Javajo and an organizer of JJUGだとくどい気がするから後半をorganizesにして無理やり差を付けたけど…。
友: 違う名詞をつなげた方がシンプルでいいかもね。administratorはどう?
私: あ、board memberって皆よく言ってるかも!

.
私: 共著なんだけどこれでいいのか?
友: Co-authorだね。
(これはググれカスだったね。共著者のちむさんごめん・・・)

その他の知見とか小さい変更点とか

  • 名詞を繋げるのは良いけどdevelopers community managementはちょっと読みづらいのでmanagement of developers communityくらいにしておこう。
  • These daysの後のカンマはまぁなくても問題はないけど読みやすさのために入れよう。
  • bioは自分のことであっても第三者目線で書いて主観が入っていない感じにする。
  • 誰のbioか一目で分かるので、名前から始めるのはgood.

バイバイオ👋

セミコロンの使い方を知りたい(Javaじゃなくて英語の話)

セミコロンを使わないJavaの話はしないぞ!!

コロンは例示とか言い換えを便利にしてくれるものとしてたまに使うけど、セミコロンは何なのかすらちゃんと分かっておらずスルーしていた。ちゃんと調べてみたら要はカンマとピリオドの仲間。等位接続詞の代わりになったり、接続副詞と併せて使ったりするらしい。

例1

She is a programmer; she writes JavaScript code.

情報を付け加える等位接続詞の and の代わりにセミコロンを使ったパターン。

セミコロンなしバージョン

She is a programmer, and she writes JavaScript code.

彼女はプログラマーでJSを書いてるよ。

例2

It is written in Java; it runs anywhere.

こちらは等位接続詞 soセミコロンになっている。

接続副詞使ったバージョン

It is written in Java; therefore, it runs anywhere.

この書き方でもセミコロンが使えるらしい。

セミコロンなしバージョン

It is written in Java, so it runs anywhere.

Javaで書かれてるからどこでも実行できるよ。

感想

かんたんだね!今まで「セミコロンってなんだっけ」と思いつつ深く気にせず調べもせずやってきたがやっと学んだ。自分が使うことはあまりなさそうだけど、ネイティブの人はどういうときに使うのか今度お友達に聞いてみよう。

ちなみに、カンマで区切って何かを並べるときにセミコロンを混ぜることでカテゴライズとかもできるらしい。

Java, JavaScript; India, Indonesia; ham, hamstar

参考文献

Javaのレコード(Records)は入れ子にして便利に使える #javajo #java14

結論

タイトル通り。

前置き

先日Java女子部でこんなイベントを行いました。
javajo.doorkeeper.jp

型の基本から最新情報まで学べる豪華な会で、知らないことも多くとても面白かったです。
他の多くの参加者にとっても同様だったようで、満足度の高いイベントになりました。西川さんありがとうございました!

さて、Java 14からプレビュー機能として「レコード」が追加されました*1

特徴の一部を西川さんの資料から拝借しました:

  • イミュータブルである
  • recordは暗黙のうちにfinalである
  • recordクラスのメンバー変数はfinalである
  • 値がすべて同じならequals()ではtrueを返さなくてはならない

Java女子部のイベントではサンプル付きでレコードについて学んだのですが、
フィールドがint型やString型だけだったので、 「レコードは入れ子にできる?したらどうなる?」という疑問が湧きまして。実際使うときって入れ子にしたいし。
ということで、それを動かして調べてみるのが私の宿題となったのでした。

ソースコード付き実験と解説

レコードを定義してみる

大好きな「あつまれどうぶつの森」風サンプルにしました。実際のあつ森はこの何億倍も複雑ですが。

  • 名前と色の情報を持った家具がある
  • 家具はリメイクすることで色を変えられる
  • 家具は複数個ポケットにしまうことができる

を満たすクラスたちをレコードとして作ってみます (サンプルにおいて package とか import は省略してます)。
f:id:ihcomega:20200804095014j:plain:w300

クラス名の後にコンストラクタ風にメンバー変数を渡すと便利なメソッドやらが色々生成されます(後述)。
Scalacase class みたい。

/**
 * 家具の名前
 */
public record FurnitureName(String value) {}
/**
 * 家具の色
 */
public enum FurnitureColor {
    RED,
    BLUE,
    YELLOW,
}
/**
 * 家具
 */
public record Furniture(FurnitureName name,
                        FurnitureColor color
) {
    // 2021.09 追記: レコードには自動でgetterが生えるので本当はこのメソッド要らないですね…
    // しかし、これがある状態で後述の検証をしちゃったので残しておきます。
    public FurnitureName name() {
        return name;
    }
}
/**
 * 家具を入れるポケット
 * 入れる位置がkey, 中身がvalue
 */
public record Pocket(Map<Integer, Furniture> furniture) {}

FurniturePocketコンパイルされた後どんなメンバーを持つか見てみます。

$ javap -p Pocket.class
Compiled from "Pocket.java"
public final class com.example.animal_crossing.main_character.Pocket extends java.lang.Record {
  private final java.util.Map<java.lang.Integer, com.example.animal_crossing.item.Furniture> furniture;
  public com.example.animal_crossing.main_character.Pocket(java.util.Map<java.lang.Integer, com.example.animal_crossing.item.Furniture>);
  public java.lang.String toString();
  public final int hashCode();
  public final boolean equals(java.lang.Object);
  public java.util.Map<java.lang.Integer, com.example.animal_crossing.item.Furniture> furniture();
}
$ javap -p Furniture.class
Compiled from "Furniture.java"
public final class com.example.animal_crossing.item.Furniture extends java.lang.Record {
  private final com.example.animal_crossing.item.FurnitureName name;
  private final com.example.animal_crossing.item.FurnitureColor color;
  public com.example.animal_crossing.item.Furniture(com.example.animal_crossing.item.FurnitureName, com.example.animal_crossing.item.FurnitureColor);
  public com.example.animal_crossing.item.FurnitureName name();
  public java.lang.String toString();
  public final int hashCode();
  public final boolean equals(java.lang.Object);
  public com.example.animal_crossing.item.FurnitureColor color();
}

javapコマンドに詳しくなくてもかんたん!以下のことが分かりますね。

  • record で宣言をすると Record クラスを継承したクラスとなる
  • レコードクラス自体は final となる
  • レコードクラスのメンバー変数は private final となる (ので、setterは生成されない)
  • toString(), hashCode(), equals(), getter, コンストラクタが自動で生成される

レコードにふるまいを持たせてみる

さてここで「ポケットから家具をひとつ取り出してリメイクしてまたポケットにしまう」というコードを実行できるようにレコードを拡張してみます。 レコードはイミュータブルなので Furniture インスタンスを直接書き換えることはできません。
ということで、 PocketFurniture にリメイクに必要なメソッドを生やしてみました。
慣れないJavaですが、Stream API使いに改善の余地があったら教えて下さい

/**
 * 家具
 */
public record Furniture(FurnitureName name,
                        FurnitureColor color
) {

    /**
     * 家具の色を指定したものに変える(リメイクする)
     *
     * @param newColor リメイク後の色
     * @return 色の変わった新しい家具
     */
    public Furniture remake(FurnitureColor newColor) {
        return new Furniture(name,
                newColor);
    }
}
/**
 * 家具を入れるポケット
 * 入れる位置がkey, 中身がvalue
 */
public record Pocket(Map<Integer, Furniture> furniture) {

    /**
     * 指定した位置の家具を取り出す
     *
     * @param position 取り出す位置
     * @return 取り出した家具
     */
    // 余談なんですが、最初はOptional<Furniture>を返すようにしてたものの
    // 呼び出し元がmapやflatMap祭りになって見辛くなったので今回は強気のgetにしました
    public Furniture takeOut(int position) {
        return furniture.get(position);
    }

    /**
     * 指定した位置の家具を、別の家具と入れ替える
     *
     * @param position 入れ替える位置
     * @param newFurniture 入れ替え後、ポケットの指定した位置に入る家具
     * @return 入れ替え後の家具が入った新しいポケット
     */
    // これもうちょっとスマートに書けるのかな?
    public Pocket replace(int position, Furniture newFurniture) {
        Map<Integer, Furniture> replaced =
                furniture.entrySet().stream()
                        .map(e -> {
                            if (e.getKey() == position) {
                                return Map.entry(position, newFurniture);
                            } else {
                                return e;
                            }
                        })
                        .collect(Collectors.toUnmodifiableMap(Map.Entry::getKey, Map.Entry::getValue));
        return new Pocket(replaced);
    }
}

レコードの特徴を確認してみる

Java女子部と同じように equals() メソッドの挙動を見て、値が同じであればtrueを返すのを確認することにしました。
次のようなコードを -enableassertions オプション付きで実行してみます。

Furniture cuteTable = new Furniture(new FurnitureName("かわいいテーブル"), FurnitureColor.RED);
Furniture coolChair = new Furniture(new FurnitureName("かっこいい椅子"), FurnitureColor.BLUE);

// かわいいテーブル(赤)・かっこいい椅子(青)が1つずつ入ったポケットをつくる
Pocket myPocket = new Pocket(Map.of(0, cuteTable, 1, coolChair));

// かわいいテーブルを青にリメイクする
Pocket onceRemadePocket = myPocket.replace(0, myPocket.takeOut(0).remake(FurnitureColor.BLUE));

// かわいいテーブルを再び赤にリメイクする
Pocket remadeAgainPocket = myPocket.replace(0, myPocket.takeOut(0).remake(FurnitureColor.RED));

// 1回目のリメイクでPocketインスタンスが作り直される
assert myPocket != onceRemadePocket;

// 1回目のリメイクでPocketの中身が始めと異なる
assert !myPocket.equals(onceRemadePocket);

// 2回目のリメイクでPocketインスタンスが作り直される
assert onceRemadePocket != remadeAgainPocket;

// 2回目のリメイクでPocketの中身が始めと同じと判定される
assert myPocket.equals(remadeAgainPocket);

System.out.println("問題なくここまでくればOK");

実行結果は次のようになったので、想定通り!

問題なくここまでくればOK

今回はここまで。

余談

javap -p -c -v xxx.classの結果を見て、 equalsメソッドの生成についてもうちょっと細かいところも見てみたんですが
それも記事に入れようとすると公開まで時間がかかりそうなので諦めました。へへへ

このへんにたどり着いた↓ jdk/ObjectMethods.java at 827e5e32264666639d36990edd5e7d0b7e7c78a9 · openjdk/jdk · GitHub

パッと思いつく下手な英文和訳パターン5選

f:id:ihcomega:20200604213016j:plain

前回に引き続き、英語の小ネタです。英語を日本語にするときの「あるある」を思いつくがままに書いてみます。(あくまで私の感覚でより良い訳し方をオススメしている記事にはなりますが)気をつけよう!
なお、例文は不自然じゃない程度になるべく直訳しています。

要らない主語は省こう

  • (例) Before we talk about this issue, let's take a look at the handout.
    • △ 私達がその問題について話す前に、(お手元の)印刷物をご覧ください。
    • ○ その問題について話す前に、(お手元の)印刷物をご覧ください。
  • (例) This tool changes the way you manage bugs.
    • △ このツールで、あなたがバグを管理する方法が変わりますよ。
    • ○ このツールで、バグを管理する方法が変わりますよ。

英語は日本語に比べると主語を明示しがちですが、それを忠実に翻訳する必要はありません。特に、一般論を語るときや大衆を相手にしたときの weyou は典型的な省略対象かなと思います*1

要らない指示語は省こう

  • (例) There is a sweet apple on the desk. You can take it.
    • △ 机の上に甘いりんごがあります。それを持っていっていいですよ。
    • ○ 机の上に甘いりんごがあります。持っていっていいですよ。
  • (例) He was angry. This is because his brother ate all cookies.
    • △ 彼は怒りました。それは何故なら兄(弟)がクッキーを全部食べてしまったからです。
    • ○ 彼は怒りました。何故なら兄(弟)がクッキーを全部食べてしまったからです。

主語の省略に似た話ですが、要らない目的語は割愛しましょう (ひとつめの例)。
また、This is why ~, It is interesting to do ~みたいに訳す必要のない itthisthatなどを使った慣用表現がたくさんあるのでそれも注意しましょう (ふたつめの例)。

関係詞や修飾語で長くなった文・語は区切ろう

  • (例) Spring Batch provides reusable functions that are essential in processing large volumes of records, including logging/tracing, transaction management, job processing statistics, job restart, skip, and resource management.
    • △ Spring Batchは、ロギング・トレーシング、トランザクション管理、ジョブ処理の統計、ジョブの再実行やスキップ、そしてリソース管理などをふくむ大量のレコードを処理するのに不可欠な機能を再利用可能なものとして提供します。
    • ○ Spring Batchは大量のレコードを処理するのに不可欠な機能を再利用可能なものとして提供します。たとえば、ロギング・トレーシング、トランザクション管理、ジョブ処理の統計、ジョブの再実行やスキップ、そしてリソース管理などです。
    • ○ Spring Batchはロギング・トレーシング、トランザクション管理、ジョブ処理の統計、ジョブの再実行やスキップ、そしてリソース管理などの再利用可能な機能を提供します。これらは大量のレコードを処理するには不可欠です。

うーん、めっちゃあるあるなのにいい例が浮かばないよ〜。ひとまず一例をSpring frameworkのドキュメントから拝借しました (リンク)。
しかもこのくらいの長さなら一文でもそんなに問題はないですね。要は原文の文の数に引きずられる必要はないということです!途中で文を区切るのも翻訳者の自由なので、長すぎる名詞や文をそのまま訳す必要はありません。
英語は言葉の前にも後ろにも修飾語をいっぱい付けられるので、気をつけないと主語と述語が行方不明になりそうな長文が爆誕します。

和製英語は程々にしよう

  • (例) Checking emails is my daily routine.
    • △ メールチェックは私のデイリールーティーンです。
    • ○ メールチェックは私の日課です。

上の例文はまだ可愛らしいものですが、カタカナが大量に並んで理解しづらい文をしばしば見かけます。エンジニアは英語圏から来た言葉をそのまま使うことも多いので、技術的な文章ではなおさらありがちですね。
どうしてもカタカナにしかならないものは仕方ないですが、例えばinternationalとかglobalみたいな(似たような例しか浮かばなかった…)カタカナでも漢字でも表現できる言葉はどちらがいいか選ぶ習慣をつけたいものです。

呼びかけや問いかけは日本人が言いそうか考えてみよう

  • (例) Do you need more information?
    • △ もっと情報が欲しいですか?
    • ○ より多くの情報はこちらに掲載しています。
  • (例) Wanna watch the video?
    • △ ビデオが観たいですか?
    • ○ ビデオもご覧いただけます。

プロモーションやキャンペーンなどでよく見かけるのですが、相手を誘うような文言を正直に訳すと「失礼な!」「急に馴れ馴れしいぞ」といった印象を与える文になることがあります。
相手が日本人だったら、なるべく日本流のお誘いをしましょう。

終わりでーす。また思いついたら書きまーす😺

*1:逆に、和文英訳において文脈から判断した主語を補うのは難しさのひとつみたいですね。Twitterで翻訳をしてくれるGoogle translateくんなんかもしょっちゅう間違えてます。私自身について書いたツイートなんだけどHeって書かれていることがしばしば…

英語で「彼らはスマホを持っています」と言うとき、スマホは単数形でも複数形でもOK

って皆さん当たり前に知ってましたか…?知ってた方はもうこの記事を閉じてください(;▽;)
自分はというと単数の方が文法的に正しいと思っていたんですが、違ったようです。
どちらか一方が正解だったら記事にし甲斐があったのに、どっちでもいいなんて…。

具体例とともに説明すると、人が複数人いて各々がスマホを持ってるとき

They have a smartphone.

とも

They have smartphones.

とも表すことができるというわけです。

複数のスマホを「配分」すると捉えるか、複数のスマホの「集合」で捉えるかが異なるものの、いずれも同じことを表現できるみたいです。
この「配分」「集合」っていうのが文法的にキーワードだと初めて知りました。「配分単数」とかでググると色々ヒットします。

なお、この違いについてネイティブの方に聞いてみたところ、単数か複数かはどっちでもいいけど、意味がちょっと曖昧になるとのことでした。
どう曖昧かを図示してみると次のようになります。

f:id:ihcomega:20200528002320j:plain
表現の曖昧さ。結局スマホはいくつあるんだ?

ちなみに、『ロイヤル英文法』には「各々」という意味を出したいなら単数にすればOKとも記載がありました。
ただ、分かりやすさを重視するなら

Each of them has a smartphone.

とか

They are sharing a smartphone.

といった表現が良さそうですねー!


参考文献

綿貫陽『ロイヤル英文法改訂新版』(2000) p.726-727

コミュニケーションの方向に着目したふりかえりの方法

前職FOLIOではめっちゃいろんな経験をしたので、今更ながら少しずつブログに出してみることにしました。


はじめに

今回のテーマはチームの「ふりかえり」です。レトロスペクティブとか言ったりもするアレ、KPTとかやるアレです。
多くのチームと同じように、私の所属する開発チームも定期的なふりかえりを行っていました。会の構成を決めファシリテーションをするのは私です。

ふりかえりを進めるのは結構難しく苦戦しましたが、「これで上手くいってるのかな?」「どうしたらもっと良いふりかえりができるかな?」と考えながら色々試していくと、解決したい課題や改善点が段々と見つかってきました。そんな中、行き着いた*1方法があるので紹介します。

ふりかえりのやり方

道具はありきたりで、ホワイトボードとふせん(色の区別はしないので1色で十分。カラフルでも別にOK)です。
まずはホワイトボードを縦に1本区切り、左は「ポジティブなこと」右は「ネガティブなこと」のエリアとします。さらに、ポジティブエリアを3つ、ネガティブエリアを2つに分けます。

f:id:ihcomega:20200428031027j:plain
ふりかえりで書き出すものと配置

そして、各エリアに該当の付箋を貼り出し、皆で時計回りに見ていくというものです。

なぜこの方法を取ったか・解決したかった課題

課題に対するアクションの議論で時間足りない問題

過去にふりかえりの時間が足りなくなることがよくあったので、改善のひとつ*2として「議論しなくていいものは議論しない」仕組みを取り入れようとしました。
上下に分かれているネガティブエリアは、簡単に言うと要議論なもの(下)とそうでないもの(上)です。上半分はとにかく自分の中から外へ「出す」ことを重視して読み上げつつおしゃべりするだけとし、下半分はチームで受け止め時間をかけて話し合います。

この分類を思いついたきっかけは、たまたま目にしたばふぁ(@bufferings)さんのツイートでした。

「Keepしたいわけじゃないけど良いなと思ったこと」と「解決したいわけじゃないけど何か嫌だったなーと思ったこと」もあるよねーって。

「確かに今まで、ネガティブな内容というだけで、アクションを取らなくていいことにも検討の時間を割いていたかも?それって本当に必要?」とすごくハッとしたのを覚えています。

チームの頑張りに目を向けて欲しい気持ち

当時のチームは、新しいプロダクトをどんどん出すような作業より、地道で人目に触れない改善、歴史あるマイクロサービスのリファクタリング、金融業界特有の法的要件とじっくり向き合う静かだが激しい戦いなどが多いという特徴がありました*3
ただメンバーはハンパなく優秀で努力家で真面目で、すごすぎてすごかったので(語彙消失)、プロダクトという形とは違うところでも、チームの良いところをいっぱい見つけてワクワクして欲しい思いがありました。しかし、日々作業に没頭していると、そんなことを気にかける余裕がなくなったりもします。

そこで、「誰に対する」ポジティブな気持ちかを軸に、3象限に分けて丁寧に見直す習慣を作りました。

  • チーム(または個人) で続けたいこと
  • 自分 がドヤりたいこと
  • チームメンバー にお礼したいこと

軸について補足すると、漠然と「いいことを挙げてください」と言われたとき、チームの変化に気付くのか個の良さに目が行くのか、他人を褒めるのか自分の成果を堂々と表現できるのか、その結果にはかなり個人差があると感じます。それをふまえて、誰もが、チームも個も、他者も自分も見つめてみてほしいなと考えての工夫でした。
なお、いずれも議論が必要なことは少なく、簡単な読み上げとともに、皆で喜びの共有や拍手をしながら全部見ていって終わりです。

f:id:ihcomega:20200428041909j:plain
実際のホワイトボード

5象限の意味

それぞれの解説でも書きましたが、分かれた5つはどれもコミュニケーションの方向が異なると言えるのではないかと自分なりの整理をつけています。もちろん超正確に分類できるわけではないので話半分というか、なんとなくこんな気がするというだけですが😏

f:id:ihcomega:20200428055010j:plain

おわりに

ふりかえりはチームの数だけやり方や特徴がありそうですが、そうしたスタイルが確立された後も、マンネリ化させずに「今のベストなふりかえり」ができているか考え続ける必要があるなと思います。って、何事もそうですよね。ミーティングの場だけ設定してノー準備で「先週と同じ!」というのはなるべく避けたいですね。

参考にした書籍

ばふぁさんのツイートのみならず、大好きな『アジャイルレトロスペクティブズ』も大いに活用しました。いつもアイディア出しを助けてくれる素敵本です*4

今回書いたアクティビティは本にある「喜、怒、哀 (Mad Sad Glad)」をかなり参考にしています。
あと、紹介は割愛したんですが、「満足ヒストグラム」を参考にしたアクティビティも毎回やっていました。

手法の名前(どうでもいい余談)

先日、以前このふりかえりを一緒にやっていた奥田ニキ(@yoskhdia)から「あのふりかえり、名前ある?」と連絡もらったんですが、特に考えていなかったのでそう伝えたところ…

f:id:ihcomega:20200428044602p:plain

こうなりました。

('_')!?

*1:ゴールがあるわけではないのでもちろんいつまでも改善し続けるべきですが、数ヶ月はこのやり方で安定していました

*2:他に思いつくのはファシリテーションの質を上げる、開催時間を伸ばす、などですね

*3:こういう特徴がないチームでも同じやり方で問題ないと考えていますが、こうした特性はかなり気にしていました

*4:過去にこんな記事: 『アジャイルレトロスペクティブズ』を読み、ふりかえりで「KPT」以外の技を繰り出そう - よこなのへたのよこずきも書いています