英語のプロフィール(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 は省略してます)。

クラス名の後にコンストラクタ風にメンバー変数を渡すと便利なメソッドやらが色々生成されます(後述)。
Scalaの case 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) {}

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

$ 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 インスタンスを直接書き換えることはできません。
ということで、 Pocket と Furniture にリメイクに必要なメソッドを生やしてみました。
慣れない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

*1:プレビュー機能とは: プレビュー機能

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

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

要らない主語は省こう

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

英語は日本語に比べると主語を明示しがちですが、それを忠実に翻訳する必要はありません。特に、一般論を語るときや大衆を相手にしたときの we や you は典型的な省略対象かなと思います*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 ~みたいに訳す必要のない it や this、 thatなどを使った慣用表現がたくさんあるのでそれも注意しましょう (ふたつめの例)。

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

• (例) 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.

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

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

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

表現の曖昧さ。結局スマホはいくつあるんだ？

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

Each of them has a smartphone.

とか

They are sharing a smartphone.

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

---

参考文献

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

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

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

---

はじめに

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

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

ふりかえりのやり方

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

ふりかえりで書き出すものと配置

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

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

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

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

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

(∩´∀｀)∩ﾜｰｲ
KPTやって、YWTやって、FDLやって、どれもいいよねー、いいとこ取りするとこうかなー？な感じでこうなりましたー！あとは、KPTの中の「Keepしたいわけじゃないけど良いなと思ったこと」と「解決したいわけじゃないけど何か嫌だったなーと思ったこと」もあるよねーって。 https://t.co/UtIfOCjUdR

— Mitz Shiiba (@bufferings) February 16, 2019

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

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

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

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

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

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

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

実際のホワイトボード

5象限の意味

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

おわりに

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

参考にした書籍

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

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

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

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

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

こうなりました。

('_')！？

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

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

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

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

1on1は必ず議事録を残す(ときどき公開だってする)

これはFOLIO Advent Calendar 2019 16日目の記事です。
昨日は@grimroseさんのScala.jsとcatsとその仲間たち - Qiitaでした！

---

昨年の秋から、リーダーとして採用とかチームの健康診断(?)とかをやっています。
難しいしなかなか上手くいきませんが、自分よりずっとベテランなメンバーの皆にアドバイスや見守りをいただきつつ1年生を終えました。

書籍や先人のブログ、周りからの声なんかを参考に見よう見まねでやってきましたが、何をするにも意識していたのは「前回との繋がり」がなくならないようにすることです。
ふりかえりや月次報告会のように、数週間に1度行うようなアクティビティはどうしても前回の記憶が薄れがちです。それでも、毎度新しい気持ちで望むのでなく、あくまで連続したイベントの中の1回と意識することで

• よいことや成長の積み重ね
• 課題やもやもやの経過観察

を大事にしてきました。

些細で当然のことなようですが、忙殺されると後手になったりもするので、小さなことでも1年続けられてよかったかなという感想を抱いています。
さて、このエントリでは、中でも工夫した1on1についてちょっとだけ詳しく書いてみます。

やったこと

• メンバーごとに議事録をとり、いつでも過去を引き出せるようにした
• 1on1前に前回分を見て、引き続き取り扱った方がよさそうな話題があるかチェックしてから望んだ

(便宜上、リーダーやエンジニアリングマネージャーががやる方を1on1のホスト、メンバーを1on1のゲストと呼びます。一般的な呼称があったら教えてください)
ゲスト専門だった頃は共有ドキュメントとしてオンラインに1on1の議事録がある状態を体験したことがなかったし、自分にとってはそれを残すこと自体が新しい試みでした。
過去の経験から、自分でメモを取ると「雑すぎて見返してもよく分からん」「そもそも話すのに夢中で何もメモできなかった！」なんてことになりがちだったので、はじめから「ホストが記録を残すよ」という体にすることで、ゲストには話すことに集中してもらいつつそこそこ意味の分かる記録を残すことができたように思います。

1on1はフォーマットを大体決めていたのですが、その中に「前回との差分」という項目も入れていました。
ちょっとだけ準備に時間はかかりますが、必ず前の議事録を見返してから1on1に望むことで、「この前より状況よくなったね」「多分これ未だに解決してないよね、すまん」と経過観察を行っていました。

副次的な効果

「前回の繋がり」のみならず、1on1の記録は他にも役立ちました。

ホストとゲストで認識の齟齬が減る

ゲストが話したことをホストが書き起こすことで、ホストの理解がゲストの思いから乖離していないかを確認することができました。
実際、「これはどちらかというと○○という意味です」「さっきはそう言ったけどやっぱりこうでした」みたいな、訂正のコメントを貰うこともあって助かりました。

希望に応じホストとゲスト以外にも公開し、便利に用いることができる

せっかくドキュメントができるということで、希望者の分だけ、希望する範囲で公開もしていました。
もちろん完全自由にしたので、人によって毎度全社に公開したり、同じ職能の人にだけ見せたり、基本は非公開でときどきチームに公開したり、様々です。
公開された分は、チームメンバーが閲覧して共感コメントを残したり、他チームのリーダーとか経営メンバーが見て状況を把握したりするのに使われています。
個人的には、私だけで解決できない課題の相談相手と目線を合わせたり、リーダーの引き継ぎをしたりする際に役立ちました。

↓議事録を公開してみようと決めたとき社内wikiに書いたもの。1番思想がまとまっているので貼っておきます。おとうふっていうのは我がチームのことです📛

1on1の運用について思いを語ったポエム

1on1って、やってみるまでは「何かいいことを言わないといけないんじゃないか」「相談されたらスマートに解決しないといけないんじゃないか」ととても緊張していたのですが、回数重ねるにつれ、とにかく相手に喋ってもらって、後からアクションへ移せたらいいかなと考えるようになりました。
それ以降は気持ちとしても楽になり、純粋に尊い時間として1on1を迎えられています。 まぁ、後からでも、聞いたことを日々の行動や意思決定に反映させるのはとっても難しいのですが…。

プログラミング始めた頃「わたしなら初心者の心を忘れずにいられるのに」→どうしても忘れる。リーダーになった頃「メンバーの気持ちでい続けるのに」→どうしても視点が違って気付かないことがある。
あの頃の気持ちを忘れないことより、今話を聞いて理解することをがんばろー

— よこな / Ayana (@ihcomega) August 27, 2019

よく聞く「メンバーが気持ちや意見を話してくれるのはありがたい」っていうのはリーダーのポジショントークやろって思ってたんですが笑、本当にありがたいことなんだと心から思った2019年…

勘違いしちゃいけないのは、リーダーのため(だけ)の1on1じゃないので、私が満足するだけじゃ意味ないんですけどね！
引き続き精進！！

---

明日は@krrrr38さんです！